2

I'm absolutely newbee to Ubuntu and ufw. I' want to close everything except the modified ssh port. so i set up ufw like this:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp

and ...

sudo ufw status verbose

gives that:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
2222/tcp                  ALLOW IN    Anywhere
2222/tcp (v6)             ALLOW IN    Anywhere (v6)

for my surprise i still can access docker containers with random port numbers?! Am i missing something? To my understanding, "incomming" traffic means accessing a webservers port from the outside?

system has also been rebooted after setting up ufw.

another check with ...

nmap -p8888 example.com

gives that output:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-05 20:48 CET
Nmap scan report for example.com (XXX.XXX.XXX.XXX)
Host is up (0.10s latency).

PORT   STATE    SERVICE
8888/tcp filtered hosts2-ns

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

thanks for your help.

2
  • 1
    if the docker containers are on your computer itself, then you're not traversing the 'deny' for 'inbound' rules - the devices and nets on your system itself go through a local link and NOT through the firewall ACLs, that's why you can reach your docker and other local services even with the deny.
    – Thomas Ward
    Jan 6, 2021 at 16:33
  • ahh, good to know. thank you! Jan 7, 2021 at 23:11

1 Answer 1

1

This is By Design.

When you are testing from your local machine, the system will directly send on the 'interface' the network traffic.

For example, this is my system with LXD containers on a subnet called "InternalDHCP":

2: wlp59s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 172.18.1.0/16 brd 172.18.255.255 scope global dynamic noprefixroute wlp59s0
5: InternalDHCP: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.73.252.1/24 scope global InternalDHCP
       valid_lft forever preferred_lft forever

If I am sending any traffic to the LXD subnet here of 10.73.252.1 and I don't have any DROP rules in the INPUT chain to block the traffic to that subnet then the routes are obeyed. The routing table looks like this for these two interfaces:

default via 172.18.0.1 dev wlp59s0 proto dhcp metric 600
10.73.252.0/24 dev InternalDHCP proto kernel scope link src 10.73.252.1
172.18.0.0/16 dev wlp59s0 proto kernel scope link src 172.18.1.0 metric 600

Basically, what this means in plain speech is:

  • If INPUT and OUTPUT chains do not have any rules dropping traffic to the destination IP address, obey routing rules.
  • If the destination is in the 172.18.0.0/16 subnet: send directly through wlp59s0 device link
  • If the destination is 10.73.252.0/24 subnet: send directly through InternalDHCP device link
  • For all other traffic, route traffic to destination via 172.18.0.1 (router).

So if I am pinging 10.73.252.25 (which is a container on my system running a Debian system image), then because I don't have a rule denying transmission or receiving from that subnet in the OUTPUT and INPUT rulesets in iptables, it takes the packet of the ping and drops it directly on the InternalDHCP device/bridge on my computer, and bypasses all other behavior.

This would be analogous to my pinging 127.0.0.1 (localhost) in that it never leaves the system and in a default ufw setup you will not be forbidden to reach local subnets (whether actually physically on your network/wifi or whether they're virtual and exist solely within your computer) and as such never is blocked.

The UFW DENY INCOMING rule is for packets originating from outside your device's direct network connections in which no permit rules have been added - but what Docker does is it adds UFW rules to allow your device to communicate with the containers without affecting your traffic (transparently!) and that is why you can still reach your internal device (and why when you send PINGs out to other devices you receive messages back - RELATED,ESTABLISHED traffic is permitted under the hood). (LXD does similar behavior allowing communication with the bridges on my computer as well)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.