WAN Ping Response & Security...

[justinmann]

Does leaving your firewall set to respond to ping increase your vunerability, or probability to be attacked?

We have a vpn that someone, who shall remain nameless, set up to respond to a keep alive ping on its wan port, rather than on the internal network... Does this represent a security concern?

Thanks!

Justin

 

[spidey07]

not really.

-edit-
What I mean is you don't normally turn of pings on internet facing network devices. You just always assume you will be probed, scanned and proded. A VPN device or firewall should be pretty dang secure out of the box anyway.

The box already has open ports and would respond to scans anyway.

 

[p0lar]

I'll second that -- there's not much point to blocking ICMP echo, it's harmless. In fact, dumping it can occasionally chew up more processing power than replying. If you can, monitor your average ICMP load to see what is 'normal' white noise from the internet, so you can establish some baselines. Under duress, you can dump all ICMP and not significantly impact network performance or diagnostics.

By default, I only permit between 3 and 5 types of ICMP, depending on what the network is used for. You might consider this if performance of your firewall is of no consequence. (i.e. you're not running a 486 @ 2000pps.)

 

[spidey07]

Yeah, forgot about that.

Its bad mojo to block ICMP. Can break all sorts of things and cause headaches.

I always allow echo and destination unreachible. Having path MTU discovery borked can cause all sorts of weirdness.

 

[p0lar]

Originally posted by: spidey07
Yeah, forgot about that.

Its bad mojo to block ICMP. Can break all sorts of things and cause headaches.

I always allow echo and destination unreachible. Having path MTU discovery borked can cause all sorts of weirdness.

Yeah, you can cause some odd issues with things you never thought were related. 99% of the time, most people don't need more than few types.. echo/reply, source-quench (careful!), traceroute, and (maybe) unreachables.

Past that.. feh.. I'd have to look at a few firewall rulesets I've crafted lately for more specific examples.

 

[spidey07]

I wrote a white paper on fragmentation problems and path mtu discovery. I'll have to dig it up on exaclty what type is used.

The router that had to fragment but couldn't will send a "host unreachible" to the source with the recomended packet size. Better not block these, they're real important.

Some meat from the paper...
Background
The default MTU on Ethernet interfaces is 1500 bytes. This represents the largest packet that can be put on the wire before Layer 2 headers are added. Tunneling endpoints are responsible for encapsulating a packet, adding a header and readdressing. For GRE this results in an additional 24 bytes (20 bytes IP header. When a router attempts to encapsulate a packet that will be larger than the interface MTU it must fragment the packet or notify the sender that the packet is too big via an ICMP message. This decision is dictated by the DF flag, Don?t Fragment, in the IP layer. The flag is commonly set by application and transport layers ? TCP. Different actions can result depending on this flag.
1) DF Flag set ? router drops packet and sends ICMP Destination Unreachable, fragmentation needed and DF set (type 3, code 4) to sending host. Also included in the ICMP message is the suggested MTU.
2) DF Flag NOT set ? router fragments packet and encapsulates each fragment.

The scenarios described are all part of normal IP operation. Normally there is no trouble if the DF flag is set and fragmentation must occur as Path MTU Detection will take care of this.
PMTUD
1) Router attempts to send IP packet that is too large with DF set
2) Router sends ICMP type 3, code 4 to host with acceptable MTU
3) Host receives ICMP message and lowers MTU for this conversation
4) Host retransmits IP packet with lower MTU
5) Router receives packet and can now send it without fragmentation

......

difficulty with some applications using GRE tunnels is a direct result of fragmentation and PMTUD. If the ICMP messages used for PMTUD never reach the sending host then the router will continually drop the ?too big? packets. Eventually TCP will break down as the receiver never gets the packets requested. With security devices, firewalls, access lists, layer 7 switches and load balancers in the path ICMP messages may not reach the sender.

Solutions
There are four different approaches to fixing fragmentation and PMTUD problems.
? Adjust MTU on clients.
? ?Fix PMTUD? by ensuring ICMP messages reach the sender.
? Use the ip tcp adjust-mss command on tunnel interfaces so the router will reduce the TCP MSS value in the initial TCP 3-way handshake.
? Use policy routing on ingress interface to clear the DF bit.

 

[p0lar]

Originally posted by: spidey07
I wrote a white paper on fragmentation problems and path mtu discovery. I'll have to dig it up on exaclty what type is used.

The router that had to fragment but couldn't will send a "host unreachible" to the source with the recomended packet size. Better not block these, they're real important.

It would help if modern (sic) operating systems emerging from Redmond would exhibit some forthright intelligence with regard to packet fragmentation and proper packet construction in the first place. Some of my firewalls block anything originating from M$ regardless D); this subset of the ICMP protocol has not been necessary. Some firewalling software can mitigate this without the need for the ICMP messages, though -- PF has some functionality, maybe even netfilter's iptables? The older PIX firewalls were notoriously horrible, but I can't speak for the 7.x(x) series, or for Nokia's IPSO.

 

[spidey07]

see edit.

 

[n0cmonkey]

Some TCP/IP stacks are beginning to ignore source-quenches for TCP. Some of OpenBSD's other improvements are kinda neat too.

 

[p0lar]

Originally posted by: n0cmonkey
Some TCP/IP stacks are beginning to ignore source-quenches for TCP. Some of OpenBSD's other improvements are kinda neat too.

Yeah, there are some very interesting things that will be released in 3.8, and even more on the horizon for 3.9. Good stuff.

Their dynamic routing support has gone through the roof, not to mention PF functionality, (stateful firewall/ipsec) failover, wireless support, etc. IMHO, it's a quality OS that consistently produces quality software with an even better license.

Happy 10th birthday, OBSD!

 

[cmetz]

spidey07, destination unreachable, fragmentation needed and DF set. A.k.a. too big. Per RFC 792.

Blocking those is bad. Many operating systems do not properly implement the path MTU discovery protocol, and so if they don't get back those ICMP too big messages with a correctly filled in new MTU to try (and that field is *optional*), they don't move bits.

As far as I know, source quench has almost always been ignored by every stack. The problem is that it was never really well defined when you send it and what you do if you receive it, and it's a security disaster.

Allowing ICMP TTL exceeded through is also pleasant, that allows traceroute to work.

Always make sure your firewall has some sort of rate limiting on ICMP messages. Legitimate ICMP messages come in slowly. Lots of ICMP messages in a unit time are usually indicative of someone up to no good.

 

[spidey07]

Originally posted by: cmetz
spidey07, destination unreachable, fragmentation needed and DF set. A.k.a. too big. Per RFC 792.

Blocking those is bad. Many operating systems do not properly implement the path MTU discovery protocol, and so if they don't get back those ICMP too big messages with a correctly filled in new MTU to try (and that field is *optional*), they don't move bits.

As far as I know, source quench has almost always been ignored by every stack. The problem is that it was never really well defined when you send it and what you do if you receive it, and it's a security disaster.

Allowing ICMP TTL exceeded through is also pleasant, that allows traceroute to work.

Always make sure your firewall has some sort of rate limiting on ICMP messages. Legitimate ICMP messages come in slowly. Lots of ICMP messages in a unit time are usually indicative of someone up to no good.

Again you make very good points.

Just trying to teach folks that "blocking all ICMP" is a bad idea. There are some you don't want to block - echo being one of them.

Unless of course somebody tries to overwhelm you with them. Hopefully a high rate (pps) of ICMP would flag the sensors.

You can alway tell a secure network because they let echo, echo-reply. Its one of those "go ahead and ping away at me"