Sharenet_Docs/avoid_docker_exploits.md

● Given the exposed Docker API and high CPU usage, I strongly recommend starting with a fresh Linode. The privileged container access means attackers could have gained full system control.

Why fresh start is safer:

1. Persistent access: Attackers often install backdoors that survive container removal
2. Rootkit detection: Sophisticated compromises are hard to fully detect and remove
3. Time vs security: Rebuilding is faster than forensic analysis for production systems

If you must keep this instance:

1. Immediate isolation: Disconnect from network, change all credentials
2. Full forensic analysis: Requires security expertise to ensure complete cleanup
3. Higher risk: Potential for undetected persistence mechanisms

For a production CI system, the clean rebuild approach is more secure and time-efficient in the long run.

What simple steps can I take in the future to make sure this won't happen even as I am setting up my podman containers and testing them?

● Critical Security Steps for Future Setup:

1. NEVER Expose Docker/Podman API Publicly

UNSAFE (what caused the issue):

podman run -p 2375:2375 --privileged ...

SECURE Alternatives:

Use UNIX socket (local only)

podman run -v /var/run/podman.sock:/var/run/podman.sock

Or use SSH tunnel for remote access

ssh -L 2375:localhost:2375 user@host

2. Firewall First Approach

Block all incoming by default

sudo ufw default deny incoming sudo ufw default allow outgoing

Only open specific needed ports

sudo ufw allow ssh sudo ufw allow 80,443 # web only if needed sudo ufw enable

3. Avoid Privileged Containers

Instead of --privileged, use specific capabilities:

podman run --cap-add NET_ADMIN --cap-add SYS_ADMIN ...

Or use security opts:

podman run --security-opt=no-new-privileges ...

4. Test in Isolated Network

Create internal network

podman network create ci-network

Run containers on internal network only

podman run --network ci-network ...

● 5. Monitoring During Setup

Watch CPU/memory during testing

htop

Monitor network connections

sudo ss -tulpn

Check container processes

podman top

6. Use Temporary Testing Environment

• Test container configurations on local machine first
• Use development Linode that can be easily rebuilt
• Never expose testing containers to public internet

The key is: never expose container management APIs (Docker/Podman ports) to the internet, and always start with a deny-all firewall policy.