The issue with DHCP is that most of it on RouterOS & Linux doesn’t go through the IP firewall/iptables. If you add some log rules to raw & mangle prerouting, mangle input, raw output, mangle output, logging UDP packets with dst-port 67 & 68, you’ll only see some incoming packets, but not those the clients really send to discover & request addresses (only some for renewal), and you’ll see none of the response made by the router (nothing on the output chain). Even if you block everything related to those UDP ports on the input chain, you’ll see that clients have no problem obtaining and renewing addresses.
It’s because the DHCP server creates packet sockets (a kind of raw socket that is not affected by the IP firewall) to handle the broadcast from the client and sends answers using those sockets, that is separate from the IP firewall flow that we have in the chart.
Yep, but once a packet has got to #9 it is OUT of the firewall and enters a mysterious black box that contains a bunch of things that may (or may not) cause a new packet to be generated in #15 and consequently get again IN the firewall.
To take it to the extreme, I could add inside the multipointed star PoE (that has nothing to do with firewall, and actually doesn’t even use packets).
I thinks DHCP in that place is a bit misleading. The typical implementations (at least on Linux and the like) operate outside of the purview of the firewall. Why DHCP is not filtered in the firewall is actually not an uncommon question on these forums, and generally on the web,
Just a question: Is not using a triangle (merge paths) symbol on the inputs to “input RAW” (from “incoming packet” and “lo out”) indicative of something?
You’re not actually missing it, just don’t agree with it But it’s true: the typical DHCP servers (and clients) use what’s called “raw” sockets. These tap into the packet flow before packets enter the firewall. (This leads to all sorts of strange things, e.g. DHCP servers/clients have their own UDP implementation, separate from that of the kernel, which is not available to them.)
You are correct that these types of services expose an attack surface, and have to be very carefully constructed and managed. Fortunately there’s a very limited number of them.
So, you’re saying ROS has some built-in, hidden special rule for DHCP standard UDP ports 67/68 that no one really understands how it works? But I agree, It’s about time some standards body like the IETF actually documented how DHCP really works, don’t you think!?
They are caught at an earlier point. Not just in Mikrotik, but all Linux/BSD-like systems. The ISC has a FAQ dedicated to this: https://kb.isc.org/docs/aa-00378
(specifically the boxed note about firewalls)
I didn’t make up the part about this being a “frequently asked question.”
OT: Raw sockets have nothing to do with which ingress or egress UDP port numbers are used for DHCP. It’s just a way for the program to tinker with the inner parts of the datagram.
As for the diagram, DHCP definitely belongs in the services circle, both as a client and a server managed by all levels of the firewall including the connection tracker.
What described in that ISC FAQ also applies to the DHCP server in RouterOS.
dhcpd’s raw sockets receive packets before the point at which most OS packet filters and firewalls operate
Like I wrote above, the DHCP Server process for IPv4 does not belong in that “cloud” thing at the middle of the chart. Because the things it consumes and generates don’t get through that flow chart.
If you absolutely need to have DHCP listed, you can list DHCPv6.
From the firewall’s point of view, it’s just regular UDP traffic like anything else. Just do a packet trace on port 67 or 68 and you’ll see for yourself.
Yeah, but that packet trace is not part of the firewall functionality or the flow chart above. Try to log that DHCP traffic with the firewall tool (log rules in raw/mangle prerouting, mangle input, raw output, mangle output) and see for yourself.
And add as many drop rules as you want on them, the clients will have no problem obtaining leases.
And AGAIN, the multipointed star is OUTSIDE the firewall and represent router’s internal processes, those do include ANYTHING that is processed on the router.
I will see how to make this more evident.
We don’t have a box with text “input RAW” (but we have one with “raw PREROUTING”, distinguished by number 2).
Of course yes, it is indicative of the fact that I didn’t put one there. (evidence of absence, NOT absence of evidence )
As a matter of fact I could also get rid of the triangle merging the Y outputs of #5 and #12, entering #6 from above and from the left..
But I cannot see right now a way to remove the one for #14 and #22 (the two vertical segments of the links would be too near one to the other.
Maybe I could increase the white space between chain=output and chain=postrouting reducing the space between chain=prerouting and between chain=output (which are now larger because of the triangles).
I’ll see what I can do.
@CGGXANNX
DHCP stays in the middle.
There won’t be any distinction between DHCP(v4) and DHCPv6, and I will add PoE, only to prove a point. the contents of that center star, is a representation of the router processess OUTSIDE the FIREWALL flowchart.
@Larsa:
It really doesn’t. Try blocking DHCP with:
/ip firewall raw add chain=prerouting action=drop protocol=udp dst-port=67
Clients will still acquire leases normally.
@CGGXANNX: You’re right about your main point. Just a minor note: Demonstrating this with logging requests in e.g. prerouting will not work. This is because a raw socket catches the packet, but in that stage in the kernel the selectors are not exclusive: even though the packet is sent directly to the DHCP server, the packet is also sent to the normal ipv4 handler and on to the firewall. (That’s why DHCP servers also register a normal socket on the port to catch this fall-through.) Demonstrating this by “we’re dropping it but it still works”, or through attempting to log the output works fine though. - Yes, I’ve been through this exercise a couple of times.
OT, just one last time, just to kill off the totally wrong idea that DHCP UDP traffic somehow gets special treatment by ROS. All you need to do is turn on filter logging for any firewall chain handling the DHCP client or server. You’ll see entries like:
firewall,info DHCP PORT 67/68 input: in:brwlt out:(unknown 0), connection-state:new src-mac 99:99:99:90:49:88, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 328
firewall,info DHCP PORT 67/68 input: in:brwlt out:(unknown 0), connection-state:new src-mac 99:99:99:26:ad:77, proto UDP, 192.168.100.230:67->255.255.255.255:68, len 328
It’s just standard UDP, nothing fancy going on.
We use filters and redirects with input and output chains for DHCP all the time, and it’s always worked fine. I’ve never had any reason to use raw, but I’ll give it a shot later.
Yes, that why in my previous post I wrote that you see some packets in prerouting, but not all, many are not displayed in the log, even in prerouting. Believe me, I already did a lot of tests . My VMs with DHCP clients have done tons of reboot and got DHCP leases after each reboot while the prerouting log has nothing! And there is never anything on the output chain.
Try adding rules to the output chains to see if you catch anything. You won’t because the DHCP server process is not in front of #15.
Also, our @anav usually gives firewall examples with “drop all on the input chain” except for icmp, established/related, DNS and MGMT interface list. Have you ever seen him including any exception for UDP 67/68 at all? Of course not. But in his configs the DHCP leases still work on LAN interfaces.
But it’s true: the typical DHCP servers (and clients) use what’s called “raw” sockets. These tap into the packet flow before packets enter the firewall. (This leads to all sorts of strange things, e.g. DHCP servers/clients have their own UDP implementation, separate from that of the kernel, which is not available to them.)
(evidence of absence, NOT absence of evidence 
. My VMs with DHCP clients have done tons of reboot and got DHCP leases after each reboot while the prerouting log has nothing! And there is never anything on the output chain.