I ran into an issue today where my office router somehow got blocked by fail2ban. I searched high and low to find an answer to unblock it so I did not have to wait for the ban to expire. Here is what I found: when I executed Code: iptables -L I saw that my IP was in the jail named postfix-spamers550 to remove it I executed the following command Code: fail2ban-client get postfix-spamers550 actionunban 111.222.333.444 Success
I am trying to do the same (manually un-ban a single IP address), but when I issue the command you cited, I receive the following in fail2ban's log: Code: fail2ban-client get sasl actionunban XXX.XXX.XXX.XXX Code: 2012-04-05 14:50:48,671 fail2ban.comm : WARNING Invalid command: ['get', 'sasl', 'actionunban', 'XXX.XXX.XXX.XXX'] (Note: the XXXs represent an actual IP address) To make matters more confusing, according to the fail2ban Wiki ( http://www.fail2ban.org/wiki/index.php/Features ), manual actions, including un-banning, are not possible in version 0.8 (these features are on the road-map for 0.9): Yet, the "fail2ban-client --help" output corroborates the availability of this command: I am using fail2ban 0.8.6. I know the jail name ("sasl") is correct, because the client throws a different error (e.g., "Sorry but the jail 'fail2ban-sasl' does not exist") when the jail name is incorrect. Am I missing the "unban" action in fail2ban's "action.d" directory? If so, from where did you acquire that file? And do you mind sharing it? Any thoughts? Thanks in advance.
Another option, though may not be for the best, is: Code: iptables -D <chain> <chain number> The information can be found by running this: iptables -L --line-numbers
Thank you for the reply, ehansen. My concern with that approach is that fail2ban will attempt to restore iptables rules whenever it is restarted. In other words, if I were to remove the banned IP address directly, and then fail2ban had to be restarted for any reason, the IP address would again be added to the blacklist.
fail2ban doesn't start/stop the firewall as far as I know. Even if it did, however, as long as the firewall rules are saved (iptables-save) before a shutdown the restore will just load up the most recent saved rules.
Right; I don't think that fail2ban starts or stops the firewall either. But as far as I know, fail2ban does re-parse logs when it is started, and adds any qualifying entries to the iptables rules (if not already present). If this is, in fact, how fail2ban behaves, wouldn't it re-add the IP address in question as soon as fail2ban is restarted?
I wouldn't think so but I don't know the inner workings of fail2ban. I mean I've had my server restarted after fail2ban put in some IPs and seemed like only the rules themselves were loaded. Someone who is more familiar with how it works wil probably be able to better answer it though.
As far as I know, fail2ban will not reload the rules and the firewall creates new rules based on its config files and not based on the iptables rules before the reboot. So when you unban a IP with iptables -D, it will not be added again after reboot automatically.
You are correct, restarting iptables clears out anything added by fail2ban, in fact thats how I used to unban myself
I checked with the fail2ban mailing list and here's the official word from Yaroslav Halchenko (current project maintainer, I believe): So, there is the potential for IP addresses to be re-banned after service stop/start/restart. I believe that this behavior was introduced in version 0.8.6.
A follow-up as to whether or not it is possible un-ban an IP address, manually, in fail2ban: the short answer is, "No." I'm not sure how drewb0y was able to un-ban an IP address, manually, with the command he cited, because according to an authoritative source (Yaroslav Halchenko), "actionunban" does not work that way (which explains why I received "Invalid command" errors). From Yaroslav's response to my mailing-list inquiry: So, there you have it, folks. As of fail2ban 0.8.6: a.) The recommended means by which to un-ban individual IP addresses is to use the "iptables -D" command. b.) There is a chance that if fail2ban is restarted after removing the rule, the rule will be re-added to iptables. (This will occur if "your original scanned logs still happen to have those entries within findtime from now".)
Given that this has become the authoritative thread on this subject, I thought I'd add an example, for my own reference, if no one else's. To unban an IP address manually, it is necessary to know the chain name and the rule number. As suggested elsewhere in this thread, the following command can be used to acquire this information: Code: # iptables -L --line-numbers The relevant bits are at the end of the output. Here is an example chain with attendant rules: Code: Chain fail2ban-ssh (1 references) num target prot opt source destination 1 DROP all -- 204.110.13.107 anywhere 2 DROP all -- 1.234.20.21 anywhere 3 DROP all -- gw-tair-rp.rel.com.ua anywhere 4 RETURN all -- anywhere anywhere In this example, three (3) IP addresses have been banned via the SSH jail (these are the DROP rules). To unban the IP address 1.234.20.21, the command would be: Code: # iptables -D fail2ban-ssh 2 Don't forget that if fail2ban is restarted after this change to iptables, there is the potential for the same IP address to be re-banned. The reason for this is discussed earlier in this thread. Good luck!
I prefer xt_recent instead of adding each banned ip using iptables -I (...). You need only something like $IPTABLES_BIN -A INPUT -j DenyAccess $IPTABLES_BIN -A INPUT -m recent --update --seconds 86400 --name DenyAccess --hitcount 1 -j DROP and can then add blocked ips with "echo 1.2.3.4 > /proc/net/xt_recent/DenyAccess" To remove a single ip, "echo -1.2.3.4 > /proc/net/xt_recent/DenyAccess" will do the job. Maybe you need to increase the amount of "/sys/module/xt_recent/parameters/ip_list_tot". regards Florian
although this post is over an year old, but i thought i should add to it. manual unban and ban works for sure (at least in new versions 0.8.x) for example use fail2ban-client status to get the jail names lets say the jail name is ssh-iptables fail2ban-client set ssh-iptables unbanip [ip_to_unban) similarly manual ban the ip manually use fail2ban-client set ssh-iptables banip [ip_to_ban) BR mazhar
I can confirm mazhar's comment; the inbuilt unbanning mechanism works in later versions (I'm not sure when it was implemented, but it works for me in 0.8.11). Example: Code: fail2ban-client set dovecot unbanip 1.2.3.4 (where "dovecot" is the name of the jail, per the fail2ban configuration) It is unknown whether or not the "findtime" caveat (the possibility that an IP address will be re-banned if fail2ban is restarted after the IP address was unbanned manually) discussed earlier in this thread still applies.