Service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery"

Security Gateway Discussions
Post Reply
SECOIT GmbH
Posts: 39
Joined: 13 Feb 2018, 16:20
Contact:

Service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery"

Post by SECOIT GmbH » 05 Jul 2018, 16:27

Hi All,

The two service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery" are unchecked for the predefined services by default.
But for customers using an own DSL connection (MTU 1492 instead of 1500) or connecting with other services with a MTU less than 1500 this is causing massive internet performance loss due to retransmits (no ICMP unreachable comes back to the client) and fragmentation.

Modern Windows clients by default most of the time send the "don't fragment" flag on TCP packets so they rely on the answer in case of fragmentation which is blocked by default when the two settings are disabled.

Is there any security implication if these two settings are checked (enabled) for all services?
Also is there a way for all predefined services to enable the settings so that customers have a fast and stable internet connection in case the IT company (like mine ;) ) forgets to activate the settings?

Thanks,
Michael
Best Rregards
Michael

Rob
Posts: 5
Joined: 11 Jan 2016, 10:52

Re: Service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery"

Post by Rob » 11 Jul 2018, 13:14

Hi Michael,

Interesting question, one for which I can hopefully give an equally interesting response :). I'd say in this day and age, the settings you mention here aren't really considered to be as big a security hole as they once were, depending of course on how a network has been configured. In older times when firewalls were a lot more basic and less widely used, having a network with few security restrictions in place which also sent replies on ICMP could give away many details of the network.

One method would-be attackers can use is to perform a network sweep with tools such as Nmap, which will attempt to ping whatever it can and analyse the ICMP response packet. Each OS implements ICMP packets in a slightly different way - still following RFC and giving all relevant details in that reply, but constructed differently enough to reveal which OS is sending that ICMP reply. So, what attackers can potentially gain from ping sweeping a network, is to see which machines reside where, and what OS they run, thus giving clues on potential attack vectors.

As for Forward PathMTU Discovery, this hasn't really been so much of a security issue. There are some techniques which can exploit it, but they are incredibly complex and hard to implement, and typically rely on Man-in-the-Middle and replay style attacks, which typically need direct exposure to the target network or a means of intercepting traffic directly before it reaches the network. What PathMTU Discovery does rely on however, is Forward ICMP Errors in order to function, as it relies on a specific type of ICMP response for the technology to work.

In other words, you can't have one without the other, and if you rely on PTMU, then you need ping response. Even if you aren't using PTMU, there are various other standardised technologies which make use of ping response in order to adjust how packets are sent, which you seem to be encountering issues with when ICMP isn't allowed through.

Given that you are considering the possible security risks of allowing ICMP through however, I'd imagine that you likely have a tightly tuned network, allowing only what should be allowed through. This would likely involve restrictions on who gets to send traffic to whom, which ports should be allowed, and possibly using UTM features such as anti-virus and IDP. If you are using such features and have a network configured like this, even if an attacker can see what a network looks like, they can't do anything with it since they'll never be allowed past the firewall. To make things even harder for attackers, most web traffic is encrypted nowadays, be it through HTTPS, TLS or some form of IPsec tunnel.

So, with this in mind, if you feel safe enough to allow ICMP through (and/or PMTU Discovery), there are some things you can do to help secure the network from potential attackers. The first is to make sure you have a sufficiently high TTL value configured, which should prevent attackers from making it past the first few hops. If you consider most attackers will typically come from outside, likely another ISP and/or country, they will have reached at least our default TTL of 3 (likely more like 10-20 hops), and exceed the MinTTL value and thus not respond. Second, you could make use of threshold rules to ensure any aggressive ping sweeping is temporarily blocked.

As for predefined settings, the only way to configure PTMU Discovery and Forward ICMP Errors is to enable it per-service. This is easy enough to do though, as you just need to enable the 2 checkboxes for whichever service you wish to use with an IP Rule/Policy. You can find services under Objects > General > Services under cOS WebUI, then you simply go into the service in question and enable the settings. The only reason we don't have a "cover all" setting is due to flexibility, as there may be some occasions where it's desirable to disable PMTU for example.

So, hopefully this addresses your questions, but if there's anything more you wish to know or something I can help you with, just let me know.

Best Regards,

Robert

SECOIT GmbH
Posts: 39
Joined: 13 Feb 2018, 16:20
Contact:

Re: Service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery"

Post by SECOIT GmbH » 12 Jul 2018, 14:14

Hi Rob,

Thanks for your reply.

But there is one question I still have:
Rob wrote:
11 Jul 2018, 13:14
The first is to make sure you have a sufficiently high TTL value configured, which should prevent attackers from making it past the first few hops. If you consider most attackers will typically come from outside, likely another ISP and/or country, they will have reached at least our default TTL of 3 (likely more like 10-20 hops), and exceed the MinTTL value and thus not respond.
I'm lost here. Even after reading it several times I don't get it - likely I'm missing something.
When an IP packet gets transmitted it usually starts with a TTL of 128 for both UDP and TCP (on my Windows machine).
But since I do not know if other clients or server always start with 128 (some use 64 or 63 for example) and I don't know how many hops a router removes on the way (it SHOULD be one) - how is that a security feature?
For me TTL was always a measure to prevent packets circulating the www until the end of days in case of routing errors. But right now I'm not getting why this is a security measure in this context.

Thanks,
Michael
Best Rregards
Michael

Rob
Posts: 5
Joined: 11 Jan 2016, 10:52

Re: Service settings "Forward ICMP errors" and "Enable IPv4 Path MTU Discovery"

Post by Rob » 25 Jul 2018, 08:00

Hi Michael,

Ah, my mistake. You are correct in thinking something was missing, and that's in how I delivered the part of the response you quoted regarding Min TTL. When I wrote it, I had in mind a security aspect of allowing traceroute responses from remote hosts (or in this case, masking traceroute responses).

The reason I mentioned setting a "sufficiently high TTL" as a security precaution is less to do with pure ICMP response, and more with how it is leveraged in traceroute. As you know, an IP TTL is set initially by the system sending the packet. It can be set to any value between 1 and 255; different operating systems set different defaults. Each router that receives the packet subtracts at least 1 from the count; if the count remains greater than 0, the router forwards the packet, otherwise it discards it and sends an Internet Control Message Protocol (ICMP) message back to the originating host, which may trigger a resend.

With this in mind, traceroute takes this concept and continually increases TTL lifetimes until ICMP packets reach their target, thus calculating the number of hops and measuring how long it takes to receive them. By setting a TTL value to greater than 1 on the firewall, it will discard packets with a TTL of 1, as these are commonly used in traceroute attempts.

To address any concerns regarding applications or appliances which may send packets with a TTL of 1 toward the firewall, and thus dropping them due to Min TTL being set to 1, there should be no real risk of unintended drops. Since the firewall should be placed directly at the front or edge of any given network, and applications will generally set a TTL far greater than 1 (as you mention, normally 128, or as low as 63 or 64), the firewall should have plenty of hops remaining before the TTL ever reaches 1 to continue forwarding packets. The only time a TTL should be received by the firewall with a value of 1 should be in the majority of cases, due to traceroute. In the minority of cases of course, this could be due to a huge network topology, but this can be accounted for in where the firewall is positioned in that network, and as a last resort just increasing Min TTL as needed.

So, my apologies for the confusing response in regard to Min TTL, and hopefully this should help explain my intention behind Min TTL usage :)

Best Regards,

Robert

Post Reply