DHCP is not blocked by ufw/iptables

This bit me the first time I deployed using docker.

Everything but 80/443 blocked by the firewall. "Surely it is safe to run my app server on port 8000 because no one can access that port externally."

Docker stepped in to help by making sure people could access that port.

Developers learning how their system actually works? I'll believe it when I see it... ;)

More seriously, I believe nftables has the capacity to help here: now there can be several chains which all attach to the same hook. So docker can put rules into the FORWARD base chain of the filter table (belonging to iptables, mine is empty because I don't use iptables):

    # nft list chain ip filter FORWARD
    table ip filter {
            chain FORWARD {
                    type filter hook forward priority filter; policy accept;
            }
    }

    # nft list chain inet firewalld filter_FORWARD
    table inet firewalld {
            chain filter_FORWARD {
                    type filter hook forward priority filter + 10; policy accept;
                    ct state { established, related } accept
                    ct status dnat accept
                    iifname "lo" accept
                    ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } log prefix "RFC3964_IPv4_REJECT: " reject with icmpv6 type addr-unreachable
                    jump filter_FORWARD_POLICIES_pre
                    jump filter_FORWARD_IN_ZONES
                    jump filter_FORWARD_OUT_ZONES
                    jump filter_FORWARD_POLICIES_post
                    ct state { invalid } meta pkttype host log prefix "STATE_INVALID_DROP: "
                    ct state { invalid } drop
                    meta pkttype host log prefix "FINAL_REJECT: "
                    reject with icmpx type admin-prohibited
            }
    }

But docker doesn't ignore iptables, it adds iptables rule to forward packets to docker table in iptables.

It's probably ufw putting its rules in INPUT and OUTPUT chain and docker needing them in FORWARD.

Don't blame ufw incompetence on iptables.

There is separate issue with bridging aptly described here

https://wiki.libvirt.org/Net.bridge.bridge-nf-call_and_sysct...

but IIRC docker doesn't work in that config by default.

IIRC Centos/RHEL comes with bridging iptables pre-broken because they're bad at making firewall rules there.

Not just docker, either. If you configure a NodePort on your kubernetes cluster, you'll run into exactly the same issue: ufw-sourced iptables rules are overriden by kubernetes-sourced rules.

Here's the only fix I was able to find, which doesn't seem well documented. Run

    kubectl -n kube-system edit configmap kube-proxy

    nodePortAddresses:
      - 192.168.0.0/16

They can learn about what Docker does with iptables the traditional way, by reading Docker’s networking documentation.

https://docs.docker.com/network/packet-filtering-firewalls/

It says explicitly that docker and ufw should be considered incompatible. Docker also has a configuration key to prevent it from modifying iptables.

This helps https://github.com/chaifeng/ufw-docker

Isn't that simply because Docker adds its own firewall rules, in order to realize its docker networks?

A classic on *nix networking fundamentals: https://beej.us/guide/bgnet/

It includes a further reading list: https://beej.us/guide/bgnet/html/split/more-references.html#...

These don't cover iptables and other firewalls themselves, but they give you enough knowledge that you can read the iptables manpage and other manuals and understand them.

Do you specifically want to learn networking for Linux? If not, the Network+ and/or CCNA certifications are a great place to start for generic network education.

I was about to ask a similar question.

I don't know much about Linux networking. But recently I dove into it a little to let my laptop connect to my desktop via Ethernet (when present), but use Wifi for everything else.

I got it working-ish using "nmtui". But I'm left pretty confused about the relationship between all the network-related tools / services / files.

E.g., is "nmtui" just a convenience wrapper around thinks like iptables and resolved? Does it work around them? Which tools are mean to be used together, vs. which ones are redundant / incompatible? And then there's systemd as well.

https://www.dbooks.org/computer-networks-0128182008/

Linux Firewalls: Enhancing Security with Nftables and Beyond

It's one of those things where the more I learn just makes me better realize how little I understand.

If you used Linux like you would a true firewall and filtered a bridged or routed packet it should filter fine. It's really an interaction of giving low level network access to an application on the same box you're trying to do high level filtering on, then being surprised the high level filter misses the low level data.

I've never liked the way packet sockets are exposed on any operating system though. Exposing them is such an afterthought that the only way to use them is to basically act like the rest of the networking system plain doesn't exist. I shouldn't have to have raw network permissions to send and receive any packet just to be able to mark that I want to send and receive e.g. LLDP (or, on Windows, make a driver that even allows me a way to send such packets from user space in the first place). Operating systems truly offer "TCP/IP" (and UDP and maybe a few other select protocols, depending what you load) stacks not "network stacks" which give you access to each piece equally. Even plain raw IP sockets are increasingly ignored.

/rant of a network guy.

Iptables (aka linux's netfilter) processes DHCP packets like any other packets.

The ISC DHCP server though listens for raw packets and thus completely by-pass the netfilter rules.

This is similar to how you can use wireshark to see raw packets received on the physical port, before any filtering.

Any Linux process running with CAP_NET_RAW can by-pass the firewall in such a way, this includes your typical DHCP server running as root.

The question then should be why is ISC DHCP server using raw sockets? That is probably because DHCP sits in-between OSI layers, it bridges the gap between the mac address world and IP address world.

I'm not sure of the exact technical reason though. The linked SO answers talk about some case where NAT rules could be altering packets, not sure how common NAT+DHCP is used...

In the case of a DHCP client, you do need raw sockets because the Linux IP layer will not let a normal socket send packets with a NULL IP source address.

It's well known that iptables operates on the normal sockets layer. It would similarly be surprising behavior if you could not see packets that are present but dropped when running tcpdump. Note that this distinction only applies to packets handled locally, not forwarded.

Applications such as tcpdump and dhcp require special privileges to open raw sockets. Note that ebtables (and now by extension nftables) can be used to operate at this level.

> That is a surprising revalation; that iptables filters traffic depending on Linux implementations details. One could imagine the outcry if firewall vendor X suffered a similar “feature”. Or is this well known for Linux iptable users?

All of these major Linux firewall features have been around for over two decades and the use of multi-stage rule routing with filters is day-to-day for anyone in network ops. Cisco switches I messed with in the 90s had DHCP helpers for relaying packets across VLANs among other similar features. FTP helpers were extremely common before SSL/TLS/sftp became standard due to NAT and how the port directions work in that protocol.

iptables (well, netfilter at least) is part of Linux, so obviously it depends on Linux implementation details. Or rather its all Linux implementation details and nothing else.

that has nothing to do with any single of those tools, just the fact of trying to manage firewall by more than one tool at once.

Netplan technically could solve it but I have zero trust in Ubuntu not fucking it up or abandoning it in few years. And starting with YAML is already begging to fail

Distinct socket types for monitoring vs receiving/sending.

You could probably via ebtables as they inspect ethernet frames directly. That can be used for example to not allow VMs on host to spoof mac addresses.

But easiest way is just don't allow app to run with permission to access raw socket. That's it.

The problem is really that there is no way to get UDP interface that also gives you mac address of the packet so raw sockets are only way to do it.

Similarly there is no interface to send ICMP packets other than raw sockets.

Not through iptables, and probably not through nftables (though I can't find much documentation on nftables).

eBPF should still work, though. You can also configure iptables to filter based on a bpf program, combining the two. Here's an example: https://github.com/Asphaltt/iptables-bpf

DHCP relies on Ethernet broadcasts to function - meaning DHCP messages are received by every NIC on the subnet. So ... already not private.

PF_PACKET is needed to look at those broadcasts because the system might not have an IP, so it can't use TCP or UDP sockets.

PF_PACKET on Linux evidently ignores iptables.

Good news: PF_PACKET requires root to use (more precisely, CAP_NET_RAW capability).

So root processes can totally ignore your firewall. This doesn't matter because:

- a firewall is really for managing external communications. If you have stuff running on localhost sending or receiving unwanted stuff, and you don't trust it, why is it running on your machine then?

- root can already simply disable the firewall by removing iptables rules or adding ones.

You can always move to IPv6 which uses multi-cast and self-generated link-local addresses, meaning PF_PACKET isn't necessary.

The netdev and bridge tables' hooks run early enough I think?

What does it even mean to block DHCP? A firewall sits between networks and filters what gets passed between them. Linux can absolutely block DHCP packets being passed between networks. But it has to see them itself, obviously. So you don't want other processes being able to see them too? Well don't run those processes. Why on earth would you run a DHCP server that you hope can never receive any requests?!