OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Peter Backes - 31.10.2017
Last edited by Jo-Philipp Wich - 01.11.2017

FS#1132 - Default config exposes ipv4 UDP port 68 to the entire Internet

I am using the davidc502 LEDE Snapshot

I noticed LEDE comes with the following Firewall traffic rule enabled by default:

Name: Allow-DHCP-Renew

Match: IPv4-udp
From any host in wan
To any router IP at port 68 on this device

Action: Accept input

Apparently this rule was introduced in

I do not think it is a good idea to pass through port 68 for the entire Internet. This is not needed to solve the problem discussed at It should be sufficient to open port 68 only to the DHCP server’s network. This network is known when a DHCP lease is established.

Why is it not a good idea? udhcpc listens on port 68 only for as long as it needs it. Most of the time it does not. But that causes the kernel to reply to UDP packets sent to port 68, telling the source that it is closed. This thwarts stealth setups, where ping and all ports are dropped. Sending any UDP packet to port 68 will reveal to the source that the host is actually up.

Closed by  Jo-Philipp Wich
01.11.2017 09:17
Reason for closing:  Won't fix
Jo-Philipp Wich commented on 01.11.2017 09:17

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.

Peter Backes commented on 01.11.2017 10:23

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.

Arjen de Korte commented on 01.11.2017 10:34

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.

Peter Backes commented on 01.11.2017 10:49

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?

Arjen de Korte commented on 01.11.2017 11:25

It is very common for ISPs to block ports. See for the reason why they do that (paragraph 3.1.5).

Peter Backes commented on 01.11.2017 13:57

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.

Arjen de Korte commented on 01.11.2017 14:13

I'm not speculating, this is what actually happens widely. Not to protect customers, but to protect the network of ISPs. See

Peter Backes commented on 01.11.2017 15:08

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.

Arjen de Korte commented on 01.11.2017 15:29

To prevent customers accidentally (or maliciously) DHCP service providing to or using from other customers, also known as

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.

Peter Backes commented on 01.11.2017 15:41

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.

Arjen de Korte commented on 01.11.2017 16:11

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).

Jo-Philipp Wich commented on 01.11.2017 16:11

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.

Peter Backes commented on 01.11.2017 16:31

@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.

Arjen de Korte commented on 01.11.2017 16:44

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.

Peter Backes commented on 01.11.2017 16:57

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?


Available keyboard shortcuts


Task Details

Task Editing