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.

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.