So I am using the basic two line “allow limited ping” filter rules outlined in the Wiki and other places. The rule works and begins to hit the drop rule when the threshold is met.
My question is - what should the “pinger” or generating device see? I thought I would get timeouts but it appears to continue to work. Is that normal? I seem to remember some discussion about wether it was actually better to allow a response vs some response then none.
There is a tremendous amount of nonsense floating around w.r.t. blocking ping or even blocking all ICMP.
I would advise against blocking ICMP without knowing about ALL the disadvantages.
Don’t let you lure into “being stealth is better”, this is really nonsense.
I’m thinking about putting in a blackhole network with some of our unused public ranges just to see what sort of scan packets enter it… my suspicion is that pings will be in the minority - requests for DNS, NTP, SSH, HTTP, and SMTP will be the majority along with lots of “random” ports.
(I started blocking the spamhaus drop/edrop ranges on my server and logging just to see what sort of traffic is being sourced, and amazingly, it’s been mostly strange random TCP ports up in the high ranges.)
I have a /16 on internet. The majority of incoming crap is the replies on requests that were sent by others spoofing
these addresses as source address. Mainly DNS replies but also SYN ACK or RST from port 80 and 443
(sometimes with source port number also 80 or 443). Of course there is pinging but there is no indication whatsoever
that replying to ping results in more scanning. Also indeed scanning of the services you mention.
I have a long list of “scanning systems” like shodan.io and “research” from universities that are permanently blocked,
but of course the majority of crap comes from random addresses.
A reasonably-sized botnet can scan the entire IPv4 space in pretty short time, so they’re not going to waste time trying to ping and then scan - they’re just going to scan. I bet that by now they’ve gotten clever enough to shuffle the target hosts/ports among their entire botnet and slow it down to take longer but fly under the radar.
At any scan target, you’d just see various requests for various ports from various unrelated sources and over the period of days, if you were to compile a list, you’d find that all 65000+ ports of TCP and UDP (as well as things like IKE/IKEv2, etc) have all been scanned but by a large array of sources over a long enough period of time so that the rate of the scan packets wouldn’t cross any normal threshold.
TLDR: blocking pings doesn’t help - they just “nuke the site from orbit because it’s the only way to be sure.”
More important is detecting and blocking brute-force attempts / SQL injection attempts / probes for known exploits / etc
I’d also say that blocking OUTGOING attempts by LAn hosts is going to become a much more necessary function - if you have a botnet client on your LAN, it would be good to stop it from being able to go out and do evil things…
I mean - everyone knows where NSA headquarters is - but I dare you to try to break in unless you like having water poured over your face.
Thanks for this - I agree with most of you sentiments on the matter. But… I am curious what the rule is supposed to show to the attacker. I am just curious if it should timeout on them?
I suspect that you have an allow state=established,related rule that comes before your “allow ICMP” rule - so once one ping gets through, all of them will as long as connection tracking considers the connection “active”
If your allow ICMP rule has a rate limit, then as long as the threshold isn’t crossed, it will work. If the threshold is crossed, the rule just stops matching and some later rule in the policy will apply. In your case, if there is an accept/fasttrack rule for established/related, then you’ll want another explicit drop all icmp packets rule before the established/related rule, or else the threshold won’t matter.
Consider this chain:
accept established/related
accept icmp (rate-limited)
accept other stuff you want to accept
…
N) drop all packets
first ping packet will match on rule 2.
Second and all subsequent pings will match rule 1 - no threshold checking will happen
Now consider this chain:
accept icmp (rate-limit)
accept established/related
accept other stuff…
…
N) drop all packets
Now first ping will match rule 1.
Second and further will match rule 1 if below the rate limit.
packets beyond the rate-limit will match rule 3 (accepted)
That’s why you need to insert a “drop all icmp” rule between 1 and 2 above if you want the rate-limit to work.
It toes not make much sense to send another reply to “ping” than “ping reply”.
When you want to block ping, just drop it, don’t send “unreachable” or something like that, because then you still
send a reply that makes you visible, which is what those ping-blocking people want to avoid.
When filtering other protocols, it can sometimes be reasonable to send something back, like “unreachable - admin blocked”
or “tcp reset” in case of a TCP match.
However, that is to help the innocent who attempt to connect a service you do not want to offer, or to make traceroute
work, or similar. This does not really apply to ping.
But whatever you do, do not just block all ICMP (as sometimes is advised), you will regret it!