13 ms·
DHCP is not blocked by ufw/iptables
- yomlica8 3y agoCan anyone recommend a decent book on linux firewalls, iptables and the like? Every time I wade into this I feel I'm missing to much base knowledge to make good decisions.
- CoastalCoder 3y agoI 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.
- seba_dos1 3y agonmtui is just a console UI for NetworkManager. Similar UI is most likely provided by your desktop environment of choice as well. It has nothing to do with iptables.
- CoastalCoder 3y agoThanks, that's helpful. Any suggestion for something explaining how all these tools and service fit together (or don't)?
- seba_dos1 3y agoNot sure what exactly are you asking about. iptables/nftables is an interface for in-kernel packet filters. NetworkManager... well, manages your interfaces and connections. systemd-resolved/dnsmasq handle DNS. They mostly just do their own thing, with NM sometimes using the other ones as needed (for example, it will set forwarding rules up and run dnsmasq when you choose a "Shared to other computers" option in NM).
- nick__m 3y agoFor a complete but not up to date guide have a look at https://tldp.org/LDP/nag2/index.html https://tldp.org/LDP/nag2/index.html . And for more up-to-date but less complete guide https://wiki.archlinux.org/title/Network_configuration https://wiki.archlinux.org/title/Network_configuration .
- zokier 3y ago"Not up to date" is putting it mildly, idk if there is anything in nag2 that's still relevant these days; I get the feeling that it will just confuse more than inform at this point unless you already know the stuff and history.
- vaylian 3y agonmtui is a terminal user interface (tui) to control Network Manager (nm). Network Manager is a complete solution for networking that takes care of all the individual parts of networking. But as far as I know it does not change your firewall rules. You would need to use iptables for that directly, because this is not something that can be reasonably automated without actually knowing what the user wants. systemd is an init system with a lot of bells and whistles. One of the whistles is systemd-networkd, which is also a complete networking solution, but it also delegates some work to systemd-resolved. It also doesn't take care of firewalling. If you want to get a better understanding on how networks are set up, then you should rather look for more low-level tools like iproute2 (which provides the "ip" tool) and dhclient/dhcpd. For wireless you should look at wpa_supplicant (which is afaik used by Network Manager under the hood). And then there is of course iptables which is used to manipulate the flow of packages through the network. It should be noted that eBPF is intended to replace iptables but knowledge of iptables will still prove useful for many years to come.
- dharmab 3y agoA classic on *nix networking fundamentals: https://beej.us/guide/bgnet/ https://beej.us/guide/bgnet/ It includes a further reading list: https://beej.us/guide/bgnet/html/split/more-references.html#more-references 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.
- beeburrt 3y agohttps://www.dbooks.org/computer-networks-0128182008/ https://www.dbooks.org/computer-networks-0128182008/
- wjholden 3y agoDo 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.
- rfmoz 3y agoLinux Firewalls: Enhancing Security with Nftables and Beyond
- le-mark 3y agoThat 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?
- zamadatix 3y agoIf 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.
- tptacek 3y agoActing like the whole networking stack doesn't exist is the whole purpose of packet sockets, because sometimes you want to override the things the networking stack does. You need privileges to open a raw socket (or a packet socket, or anything else that would let you program at the IP layer) because otherwise unprivileged processes could hijack traffic for other applications on the system.
- zamadatix 3y agoPacket sockets as-is are a great option if that's your use case but if I just want to bind to ethertype 0x88CC I shouldn't need to ask for the same permissions I can use to bind to 0x0800 or to capture all traffic. Sure, that's how things like AF_PACKET are implemented but there is nothing about being lower level that requires this all or nothing game of read/write-full-access-to-all-packets-ignoring-the-rest-of-the-os-stack-state vs bind-a-single-TCP/UDP-port. Just look at the way shared binds and privileged ports are handled for TCP, there is no reason the same concepts couldn't be applied to lower layers for more granularity. All of that aside, none of this would explain why I need to write a custom network driver in Windows to send more than a couple predefined ethertypes from user space at all or why, in Linux, the network filter layer can't apply to any family used in the sendto() syscall instead of just sendto() calls with AF_INET set. These kinds of decisions aren't rooted in a limited scope of what packet sockets can be for or how they must interact with the rest of the network stack, it's just how they are currently built and exposed. This is great if your use case is to ignore the OS stack, but that doesn't mean doing so is the only conceivable way of packet sockets being built. If BPF were treated slightly differently in terms of how/when certain abilities were exposed it could be a great answer to all of this. As of right now, it's just a better way to ignore the OS network stack even more than normal though.
- SamuelAdams 3y agoWait until they learn about Docker ignoring iptable rules. https://www.baeldung.com/linux/docker-container-published-port-ignoring-ufw-rules https://www.baeldung.com/linux/docker-container-published-po...
- Muromec 3y agoBut docker doesn't ignore iptables, it adds iptables rule to forward packets to docker table in iptables.
- yjftsjthsd-h 3y agoOkay, docker doesn't ignore firewall rules, it bypasses them. Still annoying.
- masom 3y agoIt does not bypasses them, it uses the firewall to add forwarding rules to the container. If you read https://www.baeldung.com/linux/docker-container-published-port-ignoring-ufw-rules https://www.baeldung.com/linux/docker-container-published-po... there's a bunch of ways to prevent this from happening. By enabling port forwarding and exposing, you're essentially asking docker to configure the host for it. It's likely a surprising behaviour, but seems like ufw has a bug if you have multiple chains and groups instead of just the default one.
- 3abiton 3y agoFor the average users, it goes over the head
- deleted 3y ago[deleted]
- yjftsjthsd-h 3y ago> It does not bypasses them, it uses the firewall to add forwarding rules to the container. ... yes, it adds a forwarding rule. Which skips over the rest of my firewall rules. One might even say that it bypasses them. > By enabling port forwarding and exposing, you're essentially asking docker to configure the host for it. No, I'm asking docker to listen on that port and pass it through to the container. If I tell nginx to listen on port 80, would you expect it to take that as a "do anything you can to make sure you get port 80, including rewriting the firewall tables to ignore the rule that blocks port 80"?
- binkHN 3y agoFWIW, this is the same behavior on OpenBSD—DHCP listens directly on bpf, which sees traffic before the packet filter.
- allanrbo 3y agoEven within iptables / nftables / nft there's a ton of places to hook in. I always need to take a long hard look at this diagram to get it right: https://en.wikipedia.org/wiki/Iptables#/media/File:Netfilter-packet-flow.svg https://en.wikipedia.org/wiki/Iptables#/media/File:Netfilter...
- tambourine_man 3y agoIt’s these kinds of things that makes me realize I don’t really know what I’m doing regarding networks. I would never have imagined. Even FreeBSD’s stack, which was always much more straightforward to me, behaves like this, it seems. There’s no hope.
- ktm5j 3y agoIt's one of those things where the more I learn just makes me better realize how little I understand.
- tambourine_man 3y agoCan you imagine trying to debug this? I pity the poor soul. Hopefully all this debate will raise it to the heights of Google search results.
- anfractuosity 3y agoIntriguing, so there's no way to block DHCP from Linux at all as all firewalls such as ufw/nftables/iptables, would use netfilter behind the scenes?
- jeroenhd 3y agoNot 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 https://github.com/Asphaltt/iptables-bpf
- anfractuosity 3y agoThanks a lot, will have a look at your link.
- ilyt 3y agoebtables can, it inspects ethernet frames.
- ilyt 3y agoYou 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.
- tenebrisalietum 3y agoDHCP 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.
- Joel_Mckay 3y agoif you have systemd/Netplan/docker, than expect chaotic firewall states. Each can drop some nasty use-case specific assumptions that cause odd issues in other areas. Happy computing =)
- ilyt 3y agothat 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
- Joel_Mckay 3y agoAll mentioned items have side-channel borked firewall and route rules in the past. Some bugs intermittently silently block local daemon instances from (re)loading like magic (some bugs only happen when the system is brought up). If your daily tasks include something less borked, than consider yourself very lucky you live without systemd. If I recall, ufw was intended for simple workstation rule sets. Personally, for home stuff I tend to use a heavily customized rule-set that interoperates with fail2ban. And a very old repeatably stable approach to setting up the interfaces from a known default state... https://shorewall.org/ https://shorewall.org/ Best of luck, =)
- ilyt 3y agoI remember hating shorewall and similar ones because, well, I know iptables, and I know exactly what I want so using anything that tries to abstract it into it's own approach is torture as I need to take the rules I want and translate it to whatever mediocre paradigm shorewall (or ufw, or near-any other firewall manager in the wild) decided to put on top of iptables. I ended up using ferm http://ferm.foo-projects.org/ http://ferm.foo-projects.org/ which is basically a convenience layer over iptables, the keywords are named the same and the rules map nearly 1:1 and the changes of mapping are essentially macro and variable expansion. So it's basically iptables but a lot of tedium removed. Our biggest one is around 1.5k rules and very manageable, using ferm with rule files generated via Puppet. Every entry gets a comment allowing us to track where it came from too. > If your daily tasks include something less borked, than consider yourself very lucky you live without systemd. If I recall, ufw was intended for simple workstation rule sets. Systemd has little to do with any of that
- josephcsible 3y agoFor people who wish this weren't the case, would you want tools like tcpdump and Wireshark to also only see packets that the firewall allows? If not, then what change would you propose exactly that changes the former without breaking the latter?
- xuhu 3y agoDistinct socket types for monitoring vs receiving/sending.
- jas- 3y agoARP? Don’t you need arptables for this? OSI model 101
- m463 3y agoI've just disabled those exceptional rules when dhcp isn't required. I'm wondering if this is: - a default configuration situation (which I think I rectified) - DHCP exception hardcoded in the firewall binaries
- 1vuio0pswjnm7 3y agoBut could it be blocked using eBPF https://docs.kernel.org/networking/filter.html https://docs.kernel.org/networking/filter.html
- pseudosavant 3y agoHad an interesting exchange with chatgpt/gpt4 about this. Initially gets it wrong, but then explains it really well after being corrected with this link. Apparently Windows has similar default behavior too. Me: Is DHCP affected by iptables firewall rules on Linux? GPT: Yes, DHCP (Dynamic Host Configuration Protocol) traffic can be affected by iptables firewall rules on a Linux system. iptables can be used to filter network traffic, and it does this by checking each network packet against a set of rules. If a rule matches the packet, a specific action is taken (such as allowing the packet through, dropping it, or logging it). For DHCP, which uses UDP, the communication usually happens over port 67 for the DHCP server and port 68 for the DHCP client. If there are iptables rules that block these ports, it could prevent the DHCP from functioning correctly. For instance, if you want to allow DHCP traffic, you might need to include rules such as these in your iptables configuration: ``` iptables -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -A OUTPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT ``` The exact rules you need will depend on your specific setup and requirements. Always remember to test your configuration thoroughly to ensure it's working as expected. Me: This suggests that answer is incorrect. https://unix.stackexchange.com/questions/447440/ufw-iptables-not-blocking-dhcp-udp-port-67#447524 https://unix.stackexchange.com/questions/447440/ufw-iptables... GPT: I apologize for the confusion. The interaction between DHCP and iptables is indeed more nuanced than my previous message indicated. When a machine requests an IP address using DHCP, it doesn't have an IP yet, so the DHCP server sends the reply to the broadcast IP, which is typically 255.255.255.255. Linux has a kernel parameter called `rp_filter` (Reverse Path Filtering), which by default allows these broadcast packets through, bypassing any iptables rules. This is because the kernel recognizes that these packets are part of a legitimate IP address assignment process, so it allows them in despite any firewall rules. So in practice, while DHCP does technically use ports that could be blocked by iptables, the Linux kernel generally ensures that DHCP traffic is allowed through anyway. This behavior is fundamental to the operation of DHCP, and trying to change it could break your system's ability to obtain an IP address. Me: How does the Windows firewall handle DHCP filtering, or not? GPT: The Windows Firewall handles DHCP traffic similarly to other traffic, but with some built-in allowances because of how critical DHCP is for network connectivity. By default, Windows Firewall has predefined rules to allow DHCP traffic. DHCP uses UDP port 67 for servers and UDP port 68 for clients. The firewall rules permit these inbound and outbound connections so that a DHCP client can obtain an IP address from a DHCP server. However, unlike typical firewall rules, the rules for DHCP are handled a bit differently because, at the time of the DHCP process, the client does not yet have an IP address. For this reason, the DHCP process cannot be subject to standard IP address-based filtering rules. In the default configuration, Windows Firewall will not block DHCP traffic because this would disrupt network connectivity. But a user could technically create custom rules to block DHCP; this would likely cause significant network problems, and therefore it's not recommended. As a reminder, DHCP is a fundamental protocol for IP networks, enabling devices to request and receive an IP address and thus communicate on the network. Blocking DHCP traffic would typically prevent a device from obtaining an IP address, thereby blocking network access. https://chat.openai.com/share/6e02686c-a330-4efe-b261-1e0d09ac54ed https://chat.openai.com/share/6e02686c-a330-4efe-b261-1e0d09...