jow-:

The default firewall rules are not aimed at providing a "stealth" setup (which would actually be an RFC violation). If you want such a setup you are required to implement the required changes yourself.

rtc:

You are completely missing the point. This is not about stealth setups. It is about port 68 being exposed to the entire Internet. This is not necessary, so it shouldn't be done, period. Only the DHCP server needs to talk to port 68, not some skript kiddies dynamic IP address from some shady ISP.

The fact that stealth setups are broken is merely a side-effect of the issue. It is by no means the only or the main point.

Should there be a remotely exploitable bug in udhcpc, the current standard config does not prevent that from being abused. You definitely do not want that.

This should definitely be fixed.

arjendekorte:

Have you actually seen UDP packets with source port 67 and destination port 68 being routed across the internet? I have my doubts that this attack vector will work at all in practice.

rtc:

Of course such packets are routed! Why shouldn't they? Routing decisions are taken based on target IP, not based on Ports. Before raising doubts, how about simply trying yourself by experiment?

Even if such packets were filtered by the ISPs (which they aren't), one should never rely on this. Tomorrow they might not be filtered.

Exposing the port is not necessary, so should not be done. I do not understand why there is a discussion about it?

arjendekorte:

It is very common for ISPs to block ports. See [[https://www.bitag.org/documents/Port-Blocking.pdf]] for the reason why they do that (paragraph 3.1.5).

rtc:

What you say misses the point entirely.

1. It is not necessary to expose the port to the entire internet. It is a potential security risk. Thus, it should not be done. It's that simple.

2. One should not rely on the ISP to block ports for security. Even if some ISPs block ports today (which has nothing to do with routing), they might not do tomorrow and most don't do it today. LEDE is for everyone, not just for those with port-blocking ISPs, a highly questionalbe practice.

And BTW, the rule passes through all UDP packets to port 68, not just those with source port 67.

You have not even given a single example of an actual ISP that actually blocks port 68. Not that things would be different if you had, but you're merely speculating. I don't see why you're basing your argument on mere speculations.

arjendekorte:

I'm not speculating, this is what actually happens widely. Not to protect customers, but to protect the network of ISPs. See [[https://business.comcast.com/help-and-support/internet/ports-blocked-on-comcast-network/]]

rtc:

I don't see how the network of ISPs can be protected if customer's ports are blocked.

Anyway, I already stressed it doesn't make a difference whether some ISPs actually block the port or not. One should not rely on that. LEDE is for everyone, not merely for customers of ISPs with questionable and controversial port-blocking practices.

arjendekorte:

To prevent customers accidentally (or maliciously) DHCP service providing to or using from other customers, also known as [[https://en.wikipedia.org/wiki/Rogue_DHCP]].

Having said that, you still have not convinced me that this is a real world problem. See my initial reply. I have literally never seen any malicious traffic on UDP port 68. I have been monitoring this port since I first switched my ISP provided router to bridge mode sometime in 2007 and used a Linux box as router/firewall. Either I'm the luckiest man in the universe, or this traffic is filtered out routinely by the half dozen or so ISPs I went through since then.

rtc:

So it's a paternalistic measure to protect customers from their own stupidity (such as running LEDE in its default configuration with port 68 open to everyone), and has nothing to do with protecting the ISP's internal network. The ISP can protect its own internal network any way it wishes. Blocking customer's traffic in transit to the internet or to other customers is not necessary for that.

My ISP is one of the largest in Germany and does not block inbound ipv4 UDP traffic to port 68.

arjendekorte:

So what do you suggest to fix this then? Source filtering will not work for UDP traffic, since source addresses can easily be spoofed, so this will not protect your presumably vulnerable DHCP client from receiving malicious traffic from all over the internet (filtering on your ISPs edge routers will, but apparently you're less lucky than me in this respect).

jow-:

I fail to see the security benefit of removing the rule.

Initial DHCP discovery is performed using raw sockets bypassing netfilter entirely. When no DHCP state change (such as renew) is pending, udhcpc does not listen to port 68 at all.

When port 68 inbound is denied and the conntrack tuple initially established by the DHCP request/offer transaction is timed out (which is common for long DHCP lease times), then renew replies will not make it to the client, forcing udhcpc into the netfilter-bypassing, broadcast-using full discovery cycle which causes a complete interface teardown as side effect.

Furthermore your server pinning iptables rule suggestion would break roaming scenarios between different DHCP servers.

Your server-pinned iptables rule would only protect against unsolicitated DHCP renew replies which manage to both provide the proper random XID and to spoof the server source IP. A hypothetical attacker being in such a situation (most likely same segment) could simply exploit the initial DHCP discover handshake.

That leaves the side effect of making a port non-stealth, but stealth mode operation is not the objective of LEDE's default configuration and already requires config tweaks elsewhere in the firewall.

rtc:

@arjen: Source filtering does work for UDP traffic. It is the ISPs responsibility to block any traffic that spoofs addresses that are under the ISP's control. Even for ISPs that doesn't do that, source filtering is a huge step forward, since, in addition to sending packets to UDP4 port 68, the attacker has to use the correct source address.

@Jo-Philipp: I am not saying the DHCP server should be pinned, but its network. If the network is not known, /24 can be assumed. If that's not the case, it must be a very special situation in which, for the benefit of security of many others, it is reasonable to demand from users to customize their configuration.

For figuring out whether the XID is correct, the dhcp client already has to receive and process the incoming packet. Blocking the packet from the Internet before it reaches the client also protects against bugs in that code.

arjendekorte:

There is zero reason to route DHCP traffic to/from outside your own network boundary. I'm afraid that the ISPs that don't filter this on the edge routers will also not filter packets with an address under the ISPs control, so filtering on source address makes little difference here.

rtc:

It is a huge difference whether you block a packet with a clearly spoofed source address, or one with a legitimate source address destined at a certain port. It is the customer's responsiblity to decide which ports to filter and which ports to accept.

As I already said, the security benefit is substantial even for ISPs that don't filter such spoofed traffic, since the attacker must then use the correct source address. Your argument is completely fallacious, and goes along the absurd line of "good security is not possible in all cases, so let's not take any security measures at all".

I simply do not understand what you want to achieve with your arguments. What is the benefit of not fixing this security problem? What is the drawback? Why are you arguing for exposing the port?