1

I've recently spun on a new droplet on Digital Ocean with Ubuntu 22 and enabled UFW and allowed only SSH, which reports being active even after a reboot:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)

This is the entirety of UFW for now, I just installed everything from scratch.

I downloaded a personalized Django from this repository https://github.com/GamesDoneQuick/donation-tracker and created a docker-compose.yml to aid me with the build and the deployment, exposing the port 8000:

docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                         NAMES
0ebec5094df0   tracker   "sh -c 'python manag…"   43 minutes ago   Up 22 minutes   0.0.0.0:8000->8000/tcp, :::8000->8000/tcp     tracker

Just a bunch of seconds after Django finished with the migrations and started accepting connections, I've been hit with a suspicious request:

tracker    | 2023-07-15 22:53:41,817 WARNING Not Found: /SDK/webLanguage
tracker    | [15/Jul/2023 22:53:41] "PUT /SDK/webLanguage HTTP/1.1" 404 9

I know DO's IP ranges are constantly target of scans and such, but I can't understand how a request can reach the server with everything barred.

I've found this script https://github.com/mcw0/PoC/blob/master/CVE-2021-36260.py that checks for the vulnerability in question, thinking that the framework maybe checks for some vulnerability automatically, but that file is not found in the codebase or on my server.

I've also tried searching for some of the contents in all the files of the project but nothing came up.

find . -type f -exec grep -P "\-\-rhost" {} +
find . -type f -exec grep -P "CVE-2021-36260.py" {} +

I'm no expert of iptables but I have no reason to think that contains errors, here is the output of iptables -L: https://pastebin.com/P4uZMXw8

Bottomline is: should I be worried? I'd really like to understand why and if UFW failed. Too bad Django's logs don't come with IP logging to understand from where the request originated.

1 Answer 1

1

I've not tried this explicitly with ufw but I expect what you're seeing here is a common side-effect of using Docker where the host is protected by a local firewall (as opposed to a network firewall). There are some references for this behaviour here and here amongst others.

Part of Docker's standard operation is to manage iptables rules to allow traffic to route to containers and you can see in the iptables -L output it has added some rules for your containers

Chain DOCKER (3 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:mysql
ACCEPT     tcp  --  anywhere             172.19.0.3           tcp dpt:8000

One wat to confirm this would be, from another host you could run nmap or another port scanner to connect to port 8000/TCP and check if it reports as open.

To fix this there's a couple of options. One would be not to tell docker to expose the ports. You'll still be able to reach them locally (connect to 172.19.0.3:8000) but they won't be available from remote hosts.

Another option is to stop Docker modifying iptables rules altogether docs here but that will mean if you want to expose a port from a container, you'll need to manually run iptables commands.

1
  • Wow, I see it now. I had a hunch when I saw the Docker part of iptables but jumping over all the other blocking rules? That's wild! I can confirm that stopping exposing ports effectively stops docker messing with iptables. Now the port is reported as unreachable by nmap: 8000/tcp filtered http-alt. This should be advertised more, and port exposing is overrated anyways. Thank you for the super-clear answer!
    – Fanu
    Jul 17, 2023 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .