search

docker / for-mac

Bug reports for Docker Desktop for Mac
https://www.docker.com/products/docker#/mac
2.43k stars 118 forks source link

Docker network bottleneck when crafting certain network packet #5167

Closed mgp25 closed 3 years ago

mgp25 commented 3 years ago

Expected behavior

When connected to a VPN in the host, docker container using nmap should be able to perform the network analysis.

Actual behavior

When connected to a VPN in the host, docker container using nmap is unable to make a network analysis. It seems nmap is crafting some network packet that makes a bottleneck in the docker network making it imposible to do any further analysis with that container on any interface. After a while, the container becomes network responsive again, but it is only able to make requests to the default interface, when done to an IP running a specific service on the VPN, the same issue will occur.

Information

Diagnostic logs

Docker for Mac: 3.0.3, also happened in prior releases

Steps to reproduce the behavior

For reproducing this issue you can use any of these Dockerfiles:

FROM alpine:3.12

# Install dependencies
RUN apk add --update --no-cache \
            ca-certificates \
            libpcap \
            libgcc libstdc++ \
            libressl3.1-libcrypto libressl3.1-libssl \
&& update-ca-certificates \
&& rm -rf /var/cache/apk/*

# Compile and install Nmap from sources
RUN apk add --update --no-cache --virtual .build-deps \
        libpcap-dev libressl-dev lua-dev linux-headers \
        autoconf g++ libtool make \
        curl \
&& curl -fL -o /tmp/nmap.tar.bz2 \
         https://nmap.org/dist/nmap-7.91.tar.bz2 \
&& tar -xjf /tmp/nmap.tar.bz2 -C /tmp \
&& cd /tmp/nmap* \
&& ./configure \
        --prefix=/usr \
        --sysconfdir=/etc \
        --mandir=/usr/share/man \
        --infodir=/usr/share/info \
        --without-zenmap \
        --without-nmap-update \
        --with-openssl=/usr/lib \
        --with-liblua=/usr/include \
&& make \
&& make install \
&& apk del .build-deps \
&& rm -rf /var/cache/apk/* \
           /tmp/nmap*

ENTRYPOINT ["/usr/bin/nmap"]

Or:

FROM kalilinux/kali-bleeding-edge:latest

RUN apt-get update && \
    apt install iputils-ping python3-pip sslscan nmap nikto joomscan wpscan smbmap enum4linux dnsrecon odat gobuster -y
RUN apt-get -y autoremove && apt-get -y autoclean

RUN python3 -m pip install droopescan

RUN wget https://raw.githubusercontent.com/vulnersCom/nmap-vulners/master/vulners.nse && \
    mv vulners.nse /usr/share/nmap/scripts/

RUN wget https://raw.githubusercontent.com/21y4d/nmapAutomator/master/nmapAutomator.sh && \
    chmod +x nmapAutomator.sh && \
    mv nmapAutomator.sh /bin/nmapAutomator.sh

WORKDIR /data

ENTRYPOINT ["/bin/nmapAutomator.sh"]

I am connected to the HackTheBox VPN, I guess any VPN should work for this. The VPN has the following configuration:

client
dev tun
proto udp
remote edge-us-free-2.hackthebox.eu 1337
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
cipher AES-128-CBC
auth SHA256
key-direction 1

I am using an alias for running the container: alias nmapautomator='docker run -it --rm -v $(pwd):/data nmapautomator'

Test on the default interface (OK!):

nmapautomator 140.82.121.3 quick

Running a quick scan on 140.82.121.3

Host is likely running Unknown OS!

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 15:24 UTC
Nmap scan report for lb-140-82-121-3-fra.github.com (140.82.121.3)
Host is up (0.031s latency).
Not shown: 996 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
9418/tcp open  git

Nmap done: 1 IP address (1 host up) scanned in 5.13 seconds

Test on an IP in the VPN (OK!):

nmapautomator 10.10.10.219 quick

Running a quick scan on 10.10.10.219

Host is likely running Unknown OS!

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 15:26 UTC
Nmap scan report for 10.10.10.219
Host is up (0.089s latency).
Not shown: 996 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
8888/tcp open  sun-answerbook

Nmap done: 1 IP address (1 host up) scanned in 6.70 seconds

Test an IP which is running a service that makes nmap craft some packet that makes a bottleneck in the docker network:

nmapautomator 10.10.10.220 quick

Running a quick scan on 10.10.10.220

Host is likely running Unknown OS!

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 15:26 UTC
Nmap scan report for 10.10.10.220
Host is up (1.8s latency).
Not shown: 990 filtered ports, 9 closed ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 102.25 seconds

Notice how much time this took! 102.25 seconds After running this test, if I try to do any of the tests we did before, it will fail:

nmapautomator 10.10.10.219 quick

Running a quick scan on 10.10.10.219

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 15:29 UTC
Nmap done: 1 IP address (1 host up) scanned in 56.87 seconds

---------------------Finished all Nmap scans---------------------

Completed in 60 seconds
nmapautomator 140.82.121.3 quick

Running a quick scan on 140.82.121.3

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 15:32 UTC
Nmap done: 1 IP address (1 host up) scanned in 61.36 seconds

---------------------Finished all Nmap scans---------------------

Completed in 1 minute(s) and 4 second(s)

Time increased in both cases and neither of them are working now. Going inside the container:

┌──(root💀c9179ef3586b)-[/current]
└─# ping 140.82.121.3
PING 140.82.121.3 (140.82.121.3) 56(84) bytes of data.
From 192.168.65.3 icmp_seq=1 Destination Host Unreachable
From 192.168.65.3 icmp_seq=2 Destination Host Unreachable
From 192.168.65.3 icmp_seq=3 Destination Host Unreachable
From 192.168.65.3 icmp_seq=4 Destination Host Unreachable
From 192.168.65.3 icmp_seq=5 Destination Host Unreachable
From 192.168.65.3 icmp_seq=6 Destination Host Unreachable

Any connection now is unreachable in the docker container and after a while it becomes reacheable again. Trying to restart the docker in this state makes the docker app stuck in "Docker desktop is starting..."

I have the default docker network configuration and no modifications were applied to them:

❯ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
0392a079b7bf   bridge    bridge    local
064319624beb   host      host      local
8fe9dc3d2a38   none      null      local

I run the nmap which makes the self-DoS/bottlenick with higher verbosity leve:

nmapAutomator.sh 10.10.10.220 quick

Running a quick scan on 10.10.10.220

Host is likely running Unknown OS!

---------------------Starting Nmap Quick Scan---------------------

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-21 16:10 UTC
Initiating Parallel DNS resolution of 1 host. at 16:10
Completed Parallel DNS resolution of 1 host. at 16:10, 0.02s elapsed
DNS resolution of 1 IPs took 0.02s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating SYN Stealth Scan at 16:10
Scanning 10.10.10.220 [1000 ports]
Discovered open port 22/tcp on 10.10.10.220
adjust_timeouts2: packet supposedly had rtt of 9134322 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9134322 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9134151 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9134151 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142629 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142629 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142580 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142580 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9134115 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9134115 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142775 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142775 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142591 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142591 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142606 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142606 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142674 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9142674 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9782266 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9782266 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9782226 microseconds.  Ignoring time.
adjust_timeouts2: packet supposedly had rtt of 9782226 microseconds.  Ignoring time.
SYN Stealth Scan Timing: About 15.85% done; ETC: 16:13 (0:02:45 remaining)
SYN Stealth Scan Timing: About 53.05% done; ETC: 16:12 (0:00:54 remaining)
Completed SYN Stealth Scan at 16:13, 166.28s elapsed (1000 total ports)
Nmap scan report for 10.10.10.220
Host is up, received user-set (1.7s latency).
Scanned at 2020-12-21 16:10:41 UTC for 167s
Not shown: 989 filtered ports, 10 closed ports
Reason: 782 host-unreaches, 207 no-responses and 10 resets
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 37

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 166.37 seconds
           Raw packets sent: 1831 (80.564KB) | Rcvd: 1267 (90.784KB)

Attached an image of the CPU usage, which seems com.docker.backend might be the problem here. It stays like that even when the execution finished.

Screenshot 2020-12-21 at 17 13 53

Best regards

docker-robott commented 3 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

docker-robott commented 3 years ago

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle locked