ICMP type 3, blacklisting clients, and NAT


#1

In the interests of not causing anyone problems, my NTP server has firewall rules which look for ICMP type 3 (unreachable) packets, and add any IP address which sends such a packet to my timeserver to a temporary blacklist for five minutes. Any NTP packets originating from a host on that list are dropped with no reply.

My assumption is that any host sending an ICMP type 3 to my timeserver is probably the victim of a reflection attack (i.e. the request packets are most likely forged), and doesn’t want to be receiving NTP responses from me. Currently, traffic with such a blacklisted source IP accounts for about 6.5% of all inbound NTP traffic to my server.

It’s occurred to me, however, that with the current prevalence of NAT, my assumption may no longer be true, and that even though an IP originates such an ICMP packets, there may be other hosts behind that IP which do want to use my timeserver, even though there is clearly something there which does not.

Noting this, is maintaining this firewall rule a good idea, or should I remove it, and send responses even though they may be undesired?


#2

This is an interesting observation. On my server I see about 1-2% of incoming packets to be ICMP. I’m not sure what is the answer to your question. I suspect at least some of the messages are from firewalls that allow NTP requests (or UDP packets) from local network, but block responses from the Internet.


#3

On my server I see about 1-2% of incoming packets to be ICMP.

Mine is significantly less than that, but only because I don’t reply to blacklisted hosts. If I remove that rule and send NTP replies to those hosts, then the volume of incoming ICMP packets goes up significantly, and it’s all type 3. Those IPs are pretty clear that they don’t want my traffic.

I suspect at least some of the messages are from firewalls that allow NTP requests (or UDP packets) from local network, but block responses from the Internet.

I don’t really care about those ones - they’re broken anyway, and any reply I send won’t make it to the intended host. There’s no point in me doing the networking equivalent of bashing my head on a brick wall and hoping they’ll let my packets in.

My main concern is whether, given that NAT is a thing, my firewall rules are doing more harm than good. I don’t want to send traffic to anything that doesn’t actually want that traffic, and dropping it seems like a pretty good way to help alleviate some of the load on reflected DDoS victims. However, it’s a fairly broad measure that effectively prevents every host that might be behind that IP from using my server, even if they legitimately want to do so, just because something caused their IP to send me an “I don’t want your traffic” message.

Unfortunately, there’s no way I can tell the difference, because NAT. This is effectively a judgement call regarding which is the least-bad option. On one hand, I assist with DDoSing some innocent victims. On the other hand, I potentially deny some innocent bystander(s) behind the same IP the ability to use my NTP service.


#4

Additionally, anyone can send you forged ICMP packets and prevent clients from accessing your service.

On the other hand, the same issue applies to common rate limiting systems.

On the third hand, a single packet blocking for 5 minutes is even more efficient.


#5

You make a good point.

Is this more harmful than flooding people with unwanted reflection traffic? For my own network, I’d rather be temporarily unable to access a timeserver, than have my link saturated with DDoS NTP traffic.


#6

What would an attacker gain by using your server for reflection? The timekeeping modes of NTP don’t allow any amplification, even if rate limiting is disabled. If the attacker can send a packet with a spoofed source address, why not send it directly to the victim?


#7

Source diversity, and legitimacy. If you’ve got a small number of large pipes, bouncing it off pool servers is a pretty handy way to improve things, and makes the attack harder to block without causing problems for others as well - pool NTP servers are legitimate sources of NTP traffic.

As vectors go though, non-amplified NTP isn’t exactly a stunning one.


#8

Here’s an example of what’s currently in the blacklist, with associated AS. There are some patterns there that look like misconfigured networks, or firewalls which just don’t want NTP traffic.

The number of hosts in the list varies significantly; watching it over the course of a few minutes I’ve seen it go as low as ~1,000 and as high as ~40,000.


#9

After studying that IP / AS list in more detail, I have decided to disable my block rule. Noting the degree to which this appears to be correlated with specific large operators, I suspect that on balance, it’s probably less harmful to just send replies, despite the ICMP responses.

I’m not entirely convinced, so if anyone thinks that the block rule is still a good idea, I’d love to hear from you, and why.