Listen to this Post
Introduction:
Containerized environments are often treated as trusted zones, but plaintext traffic, hidden services, and weak internal segmentation create blind spots that attackers actively exploit. This article breaks down a complete end-to-end exercise where a single Docker network was used to simulate internal reconnaissance, man‑in‑the‑middle (MITM) data theft, and the subsequent hardening steps—stateless port knocking, SSH deception, and real‑time alerting. You will learn how to replicate both the offensive and defensive phases using Python, tcpdump, iptables, and Docker native networking.
Learning Objectives:
- Build a Python‑based port scanner to discover live containers and open ports inside a Docker bridge network.
- Perform passive traffic capture with tcpdump and extract cleartext database credentials from an unencrypted internal connection.
- Implement a stateless port‑knocking sequence with iptables to hide SSH from casual scanners.
- Deploy an SSH honeypot that logs attacker behaviour, credentials, and source IPs.
- Understand how MITRE ATT&CK mappings can validate detection coverage.
- Offensive Discovery – Python Port Scanner for Docker Networks
A container‑to‑container internal network is flat by default, meaning any service bound to `0.0.0.0` is reachable from any other container. The first step an attacker takes is reconnaissance.
Step‑by‑step guide – Building the scanner:
1. Create a custom Docker network:
docker network create --subnet=172.20.0.0/16 attack-lab docker run -it --rm --network attack-lab --name attacker alpine sh
Inside the attacker container install Python:
apk add python3 py3-pip
2. Write the scanner (scanner.py):
import socket
import ipaddress
def scan_port(ip, port):
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(0.5)
result = s.connect_ex((str(ip), port))
s.close()
return result == 0
except:
return False
network = ipaddress.IPv4Network('172.20.0.0/24')
ports = [22, 80, 443, 3306, 5432, 6379]
for ip in network.hosts():
for port in ports:
if scan_port(ip, port):
print(f'[+] {ip}:{port} open')
3. Run the scanner:
python3 scanner.py
What this does:
It iterates through all possible hosts in the `/24` subnet and checks for commonly exploited services. Unlike an external scan, this internal sweep is rarely logged and exposes misconfigurations immediately.
2. Traffic Interception – Extracting Cleartext Database Credentials
Once open ports are identified, the attacker can listen to unencrypted traffic. Here we simulate a MySQL client and server communicating over plaintext.
Step‑by‑step guide – MITM capture with tcpdump:
1. Run a vulnerable MySQL container:
docker run -d --network attack-lab --name db -e MYSQL_ROOT_PASSWORD=secret mysql:5.7
2. From the attacker container, capture traffic:
tcpdump -i eth0 -w capture.pcap
- Simulate a legitimate client connection (run from another container):
docker run -it --rm --network attack-lab --name client mysql:5.7 mysql -h db -u root -psecret
4. Extract credentials from the PCAP:
tcpdump -r capture.pcap -A | grep -i "password|secret|root"
Or use `strings capture.pcap | grep -i pass`.
Why this works:
MySQL’s native authentication sends credentials in a challenge‑response format, but if SSL/TLS is not enforced, the entire session—including queries and results—is visible to anyone with access to the network segment. This demonstrates why internal encryption is non‑negotiable.
- Defensive Layer 1 – Stateless Port Knocking with iptables
Port knocking hides a service (e.g., SSH) behind a sequence of connection attempts. Only a client that delivers the correct “knock” on specified ports will have its IP temporarily whitelisted.
Step‑by‑step guide – iptables knockd alternative (pure iptables):
- On the target container (SSH server), install iptables:
apt-get update && apt-get install -y iptables
-
Flush existing rules and set default DROP policy on INPUT:
iptables -P INPUT DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i lo -j ACCEPT
-
Create the knock sequence (ports 1111, 2222, 3333):
iptables -N KNOCK iptables -A INPUT -p tcp --dport 1111 -m recent --name KNOCK1 --set -j DROP iptables -A INPUT -p tcp --dport 2222 -m recent --name KNOCK1 --rcheck -m recent --name KNOCK2 --set -j DROP iptables -A INPUT -p tcp --dport 3333 -m recent --name KNOCK2 --rcheck -m recent --name SSH_ALLOW --set -j DROP iptables -A INPUT -p tcp --dport 22 -m recent --name SSH_ALLOW --rcheck -j ACCEPT
4. Client knock script (bash):
for port in 1111 2222 3333; do nc -nvz 172.20.0.3 $port done ssh [email protected]
What this does:
The firewall drops packets to the knock ports but logs the attempt. Only after the exact sequence (1111 → 2222 → 3333) is the source IP allowed to connect to port 22 for a limited time. This effectively makes SSH invisible to `nmap -p 22` scans.
- Defensive Layer 2 – Deploying an SSH Honeypot
Deception technology forces attackers to reveal their tools and credentials. A low‑interaction SSH honeypot logs every brute‑force attempt.
Step‑by‑step guide – Cowrie setup inside Docker:
1. Pull and run Cowrie:
docker run -d --network attack-lab --name honeypot -p 2222:2222 cowrie/cowrie
2. Tail the logs to see attacks:
docker exec -it honeypot tail -f /cowrie/var/log/cowrie/cowrie.log
3. Simulate an attack:
hydra -l root -P rockyou.txt ssh://172.20.0.4:2222
4. Log output example:
2025-03-28T10:15:22 login attempt [b'root']/b'password123' failed 2025-03-28T10:17:01 login attempt [b'admin']/b'123456' failed
Why this matters:
The honeypot logs not just the password but the entire session, including any commands the attacker attempts. This provides threat intelligence on credential patterns and post‑exploitation tooling.
5. Detection Engineering – Simulating Intrusion Alerts
To close the loop, we need to detect the attacker’s behaviour during the port‑scanning phase—not just after a breach.
Step‑by‑step guide – Simple IDS rule with iptables logging:
1. Log any connection attempts to non‑standard ports:
iptables -A INPUT -p tcp --dport 1:1024 -m limit --limit 5/min -j LOG --log-prefix "PORTSCAN_DETECTED: "
2. Monitor the kernel logs:
tail -f /var/log/kern.log | grep PORTSCAN_DETECTED
3. For a more robust solution, integrate Suricata:
docker run -d --net=host --cap-add=NET_ADMIN --cap-add=NET_RAW jasonish/suricata -i eth0
Suricata will automatically flag port sweeps and SQL injection patterns based on its emerging‑threats ruleset.
- Hardening the Docker Host – User Namespaces and Read‑Only Root
Containers should never run as root inside the host context.
Step‑by‑step guide – Enable user namespace remapping:
1. Edit `/etc/docker/daemon.json`:
{
"userns-remap": "default"
}
2. Restart Docker:
systemctl restart docker
3. Run a container with read‑only root:
docker run --read-only --tmpfs /tmp --network attack-lab --name secure_app alpine sleep 3600
What this does:
The container’s root user is mapped to a non‑privileged UID on the host, preventing container breakout from directly giving host root access. The `–read-only` flag forces all writes to temporary storage, limiting persistence options for an attacker.
- Mapping to MITRE ATT&CK – Measuring Defense Coverage
Following the comment from Sai Parmani, we can formalise the exercise by tagging each action to a MITRE technique.
| Phase | Technique | ID |
|-|–|-|
| Port scan | Network Service Scanning | T1046 |
| Traffic capture | Network Sniffing | T1040 |
| Port knocking | Network Boundary Bridging | T1599 |
| Honeypot | Deception Environment | T1562.013 |
| Alert log | Log Analysis | T1562.001 |
Actionable step:
Create a simple spreadsheet mapping each defensive control to the attack technique it mitigates. This provides measurable “time‑to‑detect” and “false positive rate” metrics, turning a lab project into a defensible security architecture.
What Undercode Say:
- Key Takeaway 1: Internal container networks are not trusted zones—they are the new network perimeter. Plaintext protocols inside a Docker bridge network are trivially intercepted.
- Key Takeaway 2: Offensive skills directly inform better defense. Building a scanner and a MITM tool gave deeper insight into how iptables logging thresholds and port knocking can evade or detect those same attacks.
- Analysis: This project demonstrates that low‑cost, containerised exercises produce high‑fidelity security understanding. The combination of Python scripting, iptables state machine logic, and honeypot telemetry mirrors real‑world security engineering tasks. It also highlights a common gap: many practitioners focus solely on cloud-native security tooling while neglecting host‑based controls (iptables, auditd) that remain essential in hybrid environments. The next logical step—formalising detection metrics—would turn this lab into a continuous validation pipeline.
Prediction:
As organisations shift left into developer‑owned security, we will see the rise of “chaos security” exercises inside CI/CD pipelines. These will automatically inject malicious containers into staging environments to test if monitoring tools detect lateral movement. Port knocking and SSH deception, once considered exotic, will be packaged as Kubernetes sidecar controllers, giving ephemeral workloads the ability to hide from internet‑wide scanners while remaining accessible to authorised engineers. The line between attacker and defender tooling will blur further, and labs like this one will become the de facto training ground for platform security engineers.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Shruti Singh96 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
