> I'm not aware of any actual attack that ping allows?
DoS.
There may have been a time once, when some of us may have been minors, that using a command like "ping -f -s 1000" from a well-connected host to a specific dialup user's IP address may have been able to completely obliterate their connection to the point that it would fuck up their network stack enough to reliably disconnect their PPP session and send them back into redialing the local ISP's busy modem pool.
Maybe.
And that kind of thing might still work today for devices that respond to ICMP pings. (I'm no longer an angsty teenager so I wouldn't know, but angsty teenagers are still things that get made in factories every day.)
Believe it or not, blocking ping at your router would have done absolutely nothing to prevent this, as those packets would likely have still been delivered to the router and possibly saturated the link anyway, regardless of whether the recipient was dropping them or not. That is why nearly all DoS flood-style attacks are UDP-based — unless you are behind a CGNAT or an upstream restrictive firewall, you can't really opt out of those packets being routed to you.
Believe it or not, blocking pings at the router prevents said router from responding to pings, and this eliminates 50% of the problem on symmetric connections (and >50% on asymmetric connections).
Better: Don't base your decisions on imaginary scenarios that haven't been relevant for decades.
There's no "good" in blocking ICMP packets and especially ping. You won't protect yourself from DDoS attacks but you might summon some obscure, hard to diagnose networking issues.
If you gave me your IP and your consent, I could rent a DDoS-for-hire service for lunch money and take you offline. They don't rely on their victims taking themselves offline with response packets.
Yep, having been a recent victim, the cheap 'booter' services are still doing NTP & DNS reflection attacks. They're easy to do and require very few resources on the part of the attacker. Flooding a 1G service to the point of total uselessness is trivial and cheap.
Sadly there's absolutely nothing you can do on your own firewall/router to block or mitigate them - your connection's downstream just gets flooded with UDP packets and becomes totally useless. The only mitigations/blocking can be done by your ISP and their connectivity partners.
> Believe it or not, blocking pings at the router prevents said router from responding to pings, and this eliminates 50% of the problem on symmetric connections (and >50% on asymmetric connections).
But if your downlink to clogged, it probably won't matter that much that your uplink is clear.
I've self-DoSed when 'downloading Linux ISOs' because the downlink was 100% saturated and I couldn't do much anything else because the ACKs for TCP packets couldn't get down easily (this was for something as basic as SSH sessions that suddenly got laggy when typing). I had to tell the software in question to only use ~90% of my downlink speed (DSL at the time).
And that kind of thing might still work today for devices that respond to ICMP pings.
Not so much any more aside from your example of saturating a really tiny link. Most routers are either based on Linux or BSD and ICMP is rate limited using a few knobs and masks icmp_ratelimit, icmp_msgs_per_sec, icmp_msgs_burst based on icmp_ratemask. Enterprise routers have even more rate limiting that factor in back plane CPU load and other vendor specific controls. Enterprise routers will appear to stop responding or appear to have packet loss but they are just silently dropping ICMP when the rate is over their set thresholds as defined by the vendor defaults or by the network administrator.
Give it a shot some time on Linux or BSD. Install iftop to watch network usage and htop or btop to watch CPU usage and flood yourself with one of the ping tools fping, hping3, nping, blitzping, etc... Ideally blizping but you may have to compile it. Just for fun start loosening the sysctl restrictions on ICMP rate limits and find the spot where your CPU load is undesirable to the point where applications lag.
On the topic of security it is a good idea to block ICMP redirects unless one knows they need it. Or conversely a more restricted approach would be to allow Echo Request, Echo Reply and maybe Destination Unreachable outbound for pmtu discovery. Address Mask Request/Reply can be considered information disclosure to some organizations. It is also a good practice to disable responding to ICMP broadcasts in the OS via sysctl unless you know you need it.
DoS.
There may have been a time once, when some of us may have been minors, that using a command like "ping -f -s 1000" from a well-connected host to a specific dialup user's IP address may have been able to completely obliterate their connection to the point that it would fuck up their network stack enough to reliably disconnect their PPP session and send them back into redialing the local ISP's busy modem pool.
Maybe.
And that kind of thing might still work today for devices that respond to ICMP pings. (I'm no longer an angsty teenager so I wouldn't know, but angsty teenagers are still things that get made in factories every day.)