Container image scanners check what's inside the box. Defensia secures the machine the box runs on. If the host is compromised, every container is compromised — instantly.
Trivy, Snyk, Grype, and Docker Scout are excellent at scanning container images for vulnerable packages. But they stop at the image boundary. The Linux machine running Docker daemon — with its SSH service, kernel, Docker socket, and host filesystem — is entirely outside their scope.
of container breaches involve a host-level vulnerability or misconfiguration (CNCF survey, 2023)
for an attacker to mine crypto once they reach an unauthenticated Docker API on port 2375
in the container image scanning category monitor SSH brute force or host CVEs
The Docker daemon runs as root. The socket at /var/run/docker.sock grants full host control to any process that can reach it. SSH on port 22 gives attackers a direct path to the host OS. These are host-level concerns — and no container image scanner addresses them.
These are the six most common entry points attackers use to compromise a Linux machine running Docker.
Docker CE listens on a Unix socket by default. If configured to expose TCP — even "just for testing" — any process that can reach it gains full root access to the host. Port 2375 is unauthenticated. Port 2376 requires TLS client certs but is routinely misconfigured. Attackers scan for 2375/2376 globally within minutes.
Docker containers don't protect the host SSH service. A successful brute force or credential stuffing attack on port 22 gives an attacker a root shell on the host — from which they can stop all containers, exfiltrate volumes, or pivot into internal networks. SSH is the most common entry point for Docker host compromise.
Many containerized tools (Portainer, Watchtower, monitoring agents) mount the Docker socket as a volume. Any container with access to docker.sock can launch new privileged containers, read secrets from environment variables of running containers, and escape to the host filesystem. Equivalent to giving the container root on the host.
Containers launched with --privileged or with capabilities like CAP_SYS_ADMIN can break out of the container namespace. Even without --privileged, unnecessary capabilities (NET_ADMIN, SYS_PTRACE) expand the attack surface significantly. Docker CE 24+ still requires explicit opt-in to restrict these.
Bind mounts like -v /etc:/etc or -v /:/host give containers direct read/write access to host filesystem paths. A compromised container with a host mount can overwrite /etc/cron.d, /etc/passwd, or SSH authorized_keys — achieving host persistence without exploiting any kernel vulnerability.
Container image scanners report CVEs in the container OS. They do not report CVEs in the host kernel, the Docker daemon binary, or the host OpenSSH version. Kernel privilege escalation CVEs (e.g., Dirty Pipe, Dirty COW, OverlayFS escape) are host-level — and they can be reached from inside a container.
Apply these steps to every Linux server running Docker CE 24+ or 25+. Each step reduces a concrete attack vector.
Check your daemon.json and any systemd drop-in files for tcp:// listeners. If you need remote Docker API access, use SSH tunneling instead.
# /etc/docker/daemon.json — safe configuration
{
"hosts": ["unix:///var/run/docker.sock"]
}
# Verify nothing is listening on 2375/2376
ss -tlnp | grep -E "2375|2376"
# Expected output: (empty)
Disable password authentication and root login over SSH. Use Defensia to detect and block brute force attempts automatically.
# /etc/ssh/sshd_config — critical settings
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
# Apply without disconnecting existing sessions
sshd -t && systemctl reload sshd
User namespace remapping causes container root (UID 0) to map to an unprivileged UID on the host (e.g., 100000). A container process that escapes the namespace lands as an unprivileged user on the host. Available in Docker CE 24+.
# /etc/docker/daemon.json
{
"userns-remap": "default"
}
# Restart Docker to apply (containers will restart)
systemctl restart docker
# Verify remapping is active
docker info | grep "Docker Root Dir"
# Root dir will move to /var/lib/docker/100000.100000/
Docker CE 24+ supports --cap-drop=ALL --cap-add=<SPECIFIC>. Most web applications need no Linux capabilities at all.
# docker run — minimal capabilities
docker run -d \
--cap-drop=ALL \
--security-opt=no-new-privileges \
nginx:alpine
# docker-compose.yml equivalent
services:
app:
cap_drop: [ALL]
security_opt: [no-new-privileges:true]
Mount the container root filesystem as read-only. Use tmpfs for paths that need writes (e.g., /tmp, /run). This prevents attackers from persisting scripts or binaries on a compromised container.
# docker run — read-only with tmpfs
docker run -d \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
--tmpfs /run:rw,noexec,nosuid,size=32m \
nginx:alpine
Install Defensia on the host to get real-time SSH brute force detection, exposed port alerting, and automatic IP blocking via iptables/ipset — without modifying Docker daemon configuration.
# Install Defensia agent on the Docker host
curl -sSL https://defensia.cloud/install.sh | bash -s -- --token YOUR_TOKEN
# Verify it reads auth.log (SSH) and Docker metadata
systemctl status defensia-agent
Install Defensia as a systemd service on the Linux host running Docker. It operates alongside the Docker daemon and monitors threats at the host level — not inside images.
Monitors /var/log/auth.log (Debian/Ubuntu) and /var/log/secure (RHEL/Amazon Linux). Detects 15+ attack patterns and blocks IPs via iptables/ipset within seconds.
Periodically checks whether ports 2375, 2376, or 9000 (Portainer) are listening on 0.0.0.0 — not just localhost. Alerts immediately if the Docker API becomes publicly reachable.
Scans the host OS for vulnerable packages including Docker CE, the Linux kernel version, OpenSSH, and libc. Matches against NVD CVE database and CISA KEV catalog. Reports findings to the dashboard.
Scans the host filesystem (not container layers) for web shells, crypto miners, rootkit artifacts, and known malware signatures using YARA rules. Identifies compromised host files that could affect all containers.
All Docker hosts in your fleet appear in one dashboard. View SSH attack frequency, CVE exposure, scan results, and malware findings across all machines from a single interface.
Reads Nginx/Apache access logs from containerized web servers (auto-detected by port or Docker label). Detects SQLi, XSS, path traversal, and OWASP Top 10 attacks — and blocks attacker IPs at the host firewall.
Container image tools and host security tools solve different problems. Here is what each covers.
Run this on the Linux machine where Docker is installed. Defensia installs as a systemd service and starts monitoring immediately — it does not touch Docker daemon configuration or container networking.
curl -sSL https://defensia.cloud/install.sh | bash -s -- --token YOUR_TOKEN
Works on Ubuntu 20.04+, Debian 11+, RHEL 8+, Amazon Linux 2023. Installs the agent binary to /usr/local/bin/defensia-agent and enables a systemd unit.
# Check systemd service status
systemctl status defensia-agent
# Verify Docker daemon is still running normally
docker info | grep "Server Version"
# Defensia reads host logs — confirm log access
journalctl -u defensia-agent --since "1 min ago"
Container security focuses on what runs inside a container — its OS packages, application dependencies, and runtime behavior. Host security focuses on the Linux machine running the Docker daemon — the kernel, SSH service, Docker socket exposure, host filesystem, and installed system packages. If the host is compromised, an attacker controls all containers regardless of how well the images are hardened.
No. Defensia installs as a systemd service on the host OS and operates entirely independently of Docker. It reads log files (auth.log, web server access logs), queries Docker metadata via the socket (read-only), and manages iptables/ipset rules on the host. It does not modify daemon.json, container networks, or image pull behavior.
Yes, and this is the recommended setup. Image scanners (Trivy, Snyk, Grype) find CVEs inside container images at build time. Defensia monitors the host at runtime — detecting SSH attacks, exposed ports, and host-level CVEs. The two layers are complementary and do not conflict.
The agent periodically scans listening TCP sockets on the host (equivalent to ss -tlnp) and checks whether ports 2375, 2376, or common management ports (9000, 9090, 8080) are bound to 0.0.0.0. If any Docker-related port becomes externally reachable, Defensia raises an alert in the dashboard immediately — without waiting for an actual attack.
Yes. The Defensia agent communicates outbound to defensia.cloud over HTTPS (port 443) to send telemetry and receive configuration. It does not require inbound connections. This means it works on hosts behind NAT, inside private VPCs, or accessible only via VPN — as long as the host has outbound internet access.
Free tier available. One install command. Monitors SSH, exposed ports, host CVEs, and malware — without touching your containers.
Get Started Free