Hacker News Reader

Comment by txutxu | Hacker News Reader

I use to restrict ICMP to echo/reply using -m icmp on iptables, but this uses just that kind of packets...

Is there anyway to stop things like this at the corporate firewall?

High end firewalls will monitor ICMP and can restrict the size of the payload. They'd probably also notice the large number of ICMP packets.

Big corporate places can completely restrict things and prevent any traffic from internal hosts to the internet. You can use proxying for web browsing etc. and then monitor that to check for any unauthorised traffic.

Out of curiosity, why would you drop echo requests or replies? I know the normal thought is "So no one will know if the IP is in use or not," but that argument doesn't hold water. Scanning toolkits have been fast enough for the past decade to skip ICMP altogether. They know you're home even with ICMP blocked.

Edited for spelling

They said they only allow echo and reply, not drop them.

That's even worse. PMTU detection is OK but not perfect. Fragmentation needed but DF bit set ICMP messages are important.

https://rachelbythebay.com/w/2015/05/15/pmtud/

ahem.

Yes. In my opinion they should restrict the payload size of an ICMP message. Blocking all echo/reply can have adverse impact on other applications as well.

A couple of million small packets in a short timeframe will still eat up your resources. If an application needs ICMP echo to pass transparently through your firewall then you should probably review your need for that application, you're one step away from becoming a partner in someone else's amplification attack.

ICMP echo isn't amplification, as long as you don't respond to multicast/broadcast addresses. It's still 1:1 reflection, so you probably want to rate limit if it's simple (FreeBSD and Linux come out of the box with sane default rate limits).

It is amplification if you allow the packets through transparently because all the hosts behind your firewall will respond if you send an echo request to the broadcast address.

So you're going to have to do a little bit more configuration than just allow a maximum packet size if you're going to allow ICMP to transit at all you should also limit the allowed set of addresses (you should do that regardless, but echo can be used for amplification requests by virtue of the broadcast feature of the IP protocol). Hence the 'one step away'.

This was known as the 'smurf' attack. Fortunately this is now mostly a thing of the past. But poking holes in your firewall for ICMP is a delicate affair.

Sorry, I had lost the context that it was a network firewall (not a host firewall), and missed the 'one step away' as well.

Ah ok. It was only a one line context switch so that was an easy mistake to make.

OK, I see "length" extension in man iptables-extensions (Debian 8), so for example, to drop pings with a packet size greater than 85 bytes:

    # iptables -A FORWARD -p icmp --icmp-type echo-request -m length --length 86:0xffff -j DROP

Still, until someone checks the code of this tool, or a working test environment, we won't know if the rule stops this tool.

Update: as for the number of packets, there is -m limit and other recipes.

If you're going to do that, set the maximum length to 128 bytes. Different ping tools use different sized payloads - I know of some common ones that generate packets by default that would be blocked with that limit.

Also, instead of using the plain limit match, check out hashlimit. It can apply a rate limit on a per sender, destination, or sender+destination basis. The recent match may also be of interest.

Reply on news.ycombinator.com