With Fail2Ban before v0.8.8:
fail2ban-client get YOURJAILNAMEHERE actionunban IPADDRESSHERE
With Fail2Ban v0.8.8 and later:
fail2ban-client set YOURJAILNAMEHERE unbanip IPADDRESSHERE
The hard part is finding the right jail:
- Use
iptables -L -n to find the rule name...
- ...then use
fail2ban-client status | grep "Jail list" | sed -E 's/^[^:]+:[ \t]+//' | sed 's/,//g' to get the actual jail names. The rule name and jail name may not be the same but it should be clear which one is related to which.
It sounds like you are falling victim to the "ICMP IS EVIL" mantra.
ICMP is NOT evil, merely misunderstood. The sad reality is that many admins fear what they do not understand, and so they cast ICMP out of their network universe, shunning it at the edge firewall level and preventing it from taking its right and proper place for the benefit of their network.
Having said that, let me address your questions:
Which types of ICMP messages can be harmful, and why?
Pretty much all of them.
Echo packets can be used to disrupt services (especially for systems with badly implemented IP stacks); Used legitimately they can give information about your network.
Destination Unreachable can be maliciously injected ; Used legitimately they can give information about * your firewall/routing structure, or about a specific machine on your network.
Source Quench can be maliciously sent to make your server effectively sit in a corner and suck its thumb.
redirect can be used as the name implies.
router advertisement and router solicitation requests can be used to create "interesting" traffic topologies (and facilitate MITM attacks) if your hosts actually pay attention to them.
traceroute is designed to give network topology information.
…etc...
The names of the various ICMP messages pretty much detail what they are capable of doing. Exercise your innate paranoia in dreaming up nightmare scenarios :-)
How should I layout an iptables ruleset to handle each type of ICMP packet?
Absent a good reason to mess with ICMP traffic, leave it the hell alone!
Mucking about with ICMP traffic prevents the appropriate uses of ICMP messages (traffic management and troubleshooting) - it will be more frustrating than helpful.
Should I rate-limit any of these types of ICMP packets? And how?
This may be the only legit exception to the "leave it the hell alone" philosophy -- rate- or bandwidth-limiting ICMP messages can be useful in helping you evade illegitimate uses of the ICMP messages. FreeBSD ships with ICMP Bandwidth / Rate Limiting by default, and I assume Linux has similar functionality.
Rate/Bandwidth limiting is far preferable to a blanket firewall rule dropping ICMP traffic: It still allows ICMP to serve its purpose on the network, and also partially mitigates attempts to abuse your server.
The above represents the opinions of one sysadmin, who for his part is FREAKIN' TIRED OF HAVING TO TROUBLESHOOT NETWORKS WHERE ALL ICMP TRAFFIC IS DROPPED -- It's annoying, frustrating, and makes it take longer to find and fix problems. :-)
Best Answer
--reject-with icmp-admin-prohibitedUsing
icmp-admin-prohibitedwith kernels that do not support it will result in a plain DROP instead of REJECT