2

Problem

I'm investigating SYN flood attacks for a university project, but I'm facing an interesting challenge: the same attack that successfully saturates a Raspberry Pi fails completely in a Docker environment. Despite extensive testing and configuration adjustments, I cannot replicate in Docker the network saturation effects that are easily observable on physical hardware.

Environment Details

-> Docker environment :

  • Host machine: MacBook Air M2 (ARM64)
  • Docker network: Custom bridge network (etu-net)
  • Target container: Ubuntu 22.04 with Apache2 (exposed on port 80, also a mariaDB is running (for future tests))
  • Attacker container: Python 3.12 DevContainer with scapy, hping3, pytest
  • Both containers are in the same Docker network
  • All tests are launched from VS Code via pytest in the attacker container

-> Raspberry PI 5 environment :

  • Target: Raspberry Pi 5 (16GB RAM) running Apache2 (on Pi OS-Lite 64-bit)
  • Attacker: Same Python DevContainer as Docker tests
  • Tests executed identically through the same code, from VS Code, in the DevContainer but by using the raspberry pi IP

Results (on Raspberry)

When attacking the Raspberry Pi from my DevContainer:

  1. The SYN_RECV queue quickly fills up to 64 entries (or 511 depending on configuration)
  2. TCP retransmissions are visible in metrics
  3. HTTP requests fail with Connection refused or timeout errors
  4. Attack is effective using both hping3 and my custom Python scripts "syn_flood" using Scapy
  5. Server configuration: tcp_syncookies=0, tcp_max_syn_backlog=64, somaxconn=64

The successful test output:

Running pytest with args: [...test_syn_flood_custom_with_http_request_on_raspberry]
[+] Test SYN flood Python on 192.168.1.40:80
[+] HTTP before attack: {'status': 200, 'time': 0.02106}
[+] Launching custom Python flood (100000 packets)
[+] HTTP during attack: {'error': "HTTPConnectionPool(host='192.168.1.40', port=80): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xffffb0063aa0>: Failed to establish a new connection: [Errno 111] Connection refused'))"}
[✓] HTTP request failed → effect confirmed
============================== 1 passed in 11.57s ==============================

Also, after my initial tests, I restored the Raspberry Pi to default security parameters for apache2:

  • net.ipv4.tcp_syncookies = 1 (enabled)
  • net.ipv4.tcp_max_syn_backlog = 1024
  • net.core.somaxconn = 4096

Even with these default, the attack continues to work effectively on the Raspberry Pi, successfully preventing HTTP connections during the flood.

Results (on Docker)

The exact same attack code launched against the Docker container:

  1. SYN_RECV queue never increases (stays at 0 or 1 connections)
  2. HTTP requests always succeed without any slowdown
  3. Setting tcp_syncookies=0 and minimizing tcp_max_syn_backlog and somaxconn has no effect...

Important detail: While the attack doesn't impact the server's ability to accept connections, the kernel metrics do show that the SYN packets are being received and processed. Specifically, the EmbryonicRSTs counter in "/proc/net/netstat" increments significantly (over 6 million RSTs observed during testing). This indicates that the Docker container is receiving the SYN packets and rejecting them, but somehow this process doesn't consume the resources needed to saturate the backlog queue.

I've tried this :

• hping3 -S --flood -p 80 --rand-source <target_ip>

• hping3 -S -p 80 -i u10 --faster <target_ip>

• Custom Python Scapy script sending SYN packets with random source IPs/ports

• Running from multiple threads with different attack variants

• Setting Docker to run with --privileged and --cap-add=NET_ADMIN,NET_RAW

• Explicitly minimizing all related settings (sysctl -w net.ipv4.tcp_max_syn_backlog=1, sysctl -w net.ipv4.tcp_syncookies=0, sysctl -w net.core.somaxconn=1)

==> In all cases, despite millions of RST packets , the backlog never saturates and HTTP requests always succeed.

Questions

  1. Is it fundamentally possible to saturate the TCP backlog (SYN_RECV queue) in a Docker container?
  2. Are there specific Docker network configurations needed for SYN floods to work properly?
  3. Could the host OS (macOS ARM) be affecting the container's network behavior?
  4. Are there any workarounds to force Docker to more accurately simulate the behavior of a physical network interface?
  5. Could there be specific protections in Docker networking that prevent this type of attack from working as expected?

More Details for questions

  • Here is the output for docker network inspect <net> :
    docker network inspect reseau-test
[
    {
        "Name": "reseau-test",
        "Id": "e52ad096927629becaccb2e9724ba3f10e59694d994cc8b2abc717790919b885",
        "Created": "2025-04-16T22:17:30.640921094Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "86502f3ee8edc7886b173448ba1b9b6cea263f068876f850c01a8736d7436d32": {
                "Name": "lamp-server",
                "EndpointID": "c369edba0f585fb2eeb6cfcdb68241e9fa02fb843f277fae358fd0ada0f0ccd2",
                "MacAddress": "0a:86:9c:2f:5e:ea",
                "IPv4Address": "172.19.0.2/16",
                "IPv6Address": ""
            },
            "c430d8df697d9724773433952dc1d6fc84df73df44c631719ce3303013a3e6ea": {
                "Name": "flamboyant_wilbur",
                "EndpointID": "226ab35b647352b8a44cd8bd7c917180a0b3bc9d3456549c367a6fbe8a8c1ccb",
                "MacAddress": "ce:ba:ce:f7:bc:1e",
                "IPv4Address": "172.19.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]
  • reseau-test : name of the network
  • lamp-server : container where Apache and MariaDB are running
  • flamboyant_wilbur : attacker container name provided by Docker
Evox
  • 21

0 Answers0