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?
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.
> If you used Linux like you would a true firewall
Host-based firewalls are, indeed, fake firewalls, and it's unfortunate that they chose to use the same term for functions that superficially look like they do the same thing, but are way less effective, and encourage bad network design.
The classic architecture for security was: edge router -> firewall -> DMZ -> bastion -> DMZ -> office router
You could put more firewalls, and switches and stuff, in there, but it is really important to have a bastion host as a chokepoint in the DMZ. You could have an IPS doing this instead. Or you could have a proxy server such as SOCKS.
But your firewall is pretty far away from any host that could get bright ideas about messing with it. (Because it is possible for client hosts to mess with router "firewall" settings via UPnP.)
This collapsing of topology also happens with other stuff, like NIDS/HIDS intrusion detection. Yeah, IDS can be more effective in certain ways when it has access to host-based logs and resources. But it's different than an isolated IDS listening on a TAP/SPAN where nobody logs into it and doomscrolls Facebook.
What is the DMZ, physically? I've always heard of putting your bastion in a DMZ but is that a conceptual layer or some sort of physical box sitting between the firewall and the bastion, and the bastion and the office router?
A DMZ is a buffer zone network. The DMZ is intended to be physically protected, and sparsely populated, and only by security-hardened systems with no user accounts and no data of consequence.
Acting 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.
Packet 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.
What is a "direct" socket in this context? If it's something that gives me a restricted packet socket context from a user space context then sure, call it what you'd like as long as it does that. If it's not that then I'm not sure it really helps. E.g. my last problem was with implementing 802.1Qcj draft extensions in a cross platform daemon, so some predefined concept about how to send/receive anything more than that EtherType with custom payloads doesn't really help (particularly if it lets other things bind to that EtherType at the same time, as LLDP is a "what the last packet said" protocol).
It's a similar story in the ARP use case you mention when maybe you want to e.g. anonymously probe if a VIP is actively in use by using a 0.0.0.0 source (useful for redundant responder setups). DHCP and ICMP I could see the case for similar improvements to the RAW IP sockets (AF_INET in Linux) type as packet sockets (e.g. ability to request and permit limited scope sockets or the other enhancements mentioned above). Just that is still too limited though as the world has more than IP protocols, e.g. AF_INET gets you OSPF but not ISIS.
The idea that "no, you can't possibly mean you'd like to send Ethernet packets while still caring about what the rest of the OS network stack is doing as if you mean to just extend it instead of take its place" is precisely the issue I've found myself annoyed with. No, I don't want to use DPDK to make a custom IP forwarding stack, I just want to be registered as the app to send and receive a certain EtherType without saying I want full rights to all packets.
Sorry, I could have spoken more precisely here. What I'm saying is that it's very annoying that there is first-class socket support for TCP and UDP, but not for ICMP; there isn't a set of sockopts and sockaddrs you can plug in to send and receive specific patterns of ICMP, or OSPF, or DHCP. There could be, but there aren't, and so to do those things you generally bypass large chunks of the stack.
On the other hand, you might take away from this that the near universal limitation on first-class programmatic access to raw Ethernet (or even raw IP) has constrained the evolution of the protocols themselves --- if it were easier to code directly to IP rather than to UDP or TCP, we might have a greater diversity of IP protocols. And that might not be a good thing! We might have benefited from how clunky the socket interface is. :)
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.
> The question then should be why is ISC DHCP server using raw sockets?
I don’t know much about Linux network stack, but probably it’s because DHCPDISCOVER messages sent to ff:FF:FF:FF:FF:FF, and Linux network driver only accepts frames sent to the interface address? Not sure if that’s true though.
But I just thought about it some more.. In a normal unix socket, you don't set the destination mac address when sending a packet. You just set the destination IP address and the kernel figures out the destination MAC address using a static, cached or dynamic ARP lookup.
But since the dhcp client has not been assigned the IP yet, ARP would fail.
The DHCP server would need to set a static ARP entry before sending the response, and hope the kernel properly fills the destination MAC. This causes more problems..
Its much easier and reliable to just craft the exact headers required as-per the RFC, especially in a cross-platform piece of software like the ISC dhcp server.
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.
