diff --git a/How-fail2ban-works.md b/How-fail2ban-works.md index 289aa25..df575b7 100644 --- a/How-fail2ban-works.md +++ b/How-fail2ban-works.md @@ -6,10 +6,14 @@ Fail2Ban comes out-of-the-box ready to read many standard log files, such as tho **But fail2ban is just a tool, so it should be [properly configured](Proper-fail2ban-configuration).** *** -**[Q]** Fail2ban does not detect some authentication failures resp. banning does not occur +**[Q]** Fail2ban does not detect some authentication failures or ban doesn't occur
Answer -**[A]** There can be many reasons: +**[A]** Fail2ban is monitoring log-files or journals and searching for matches corresponding `failregex` or `filter` rules specified in jail. Every found match will be logged (in `fail2ban.log` or its journal), for example `[jail] Found 192.0.2.25`. After several attempts (`maxretry` failures within a time windows of `findtime` seconds) from the same intruder it will be banned and every ban will be also logged, for example `[jail] Ban 192.0.2.25`. + +If there are `Ban` messages in fail2ban log, but the intruder is still able to connect or continue an attack, then rather take a look for the answer to next question. + +If there is no such `Found` or `Ban` messages logged: - corresponding jail for scanning the log file or systemd journal is not enabled (or idle). See [here](Proper-fail2ban-configuration) how the jail can be enabled. - the proper parameter `backend` (for example `auto` for log files or `systemd` for journal), proper path to the log files (parameter `logpath`) or proper journal control parameter `journalmatch` should be set for this jail. - the IP goes to ban if it makes at least `maxretry` failures within `findtime` seconds. So if you've configured `maxretry=5` and `findtime=10m` (default values) then it needs at least 5 failures (5 attempts) within 10 minutes to ban an IP.
@@ -17,6 +21,7 @@ Each failure (attempt) will be logged in `fail2ban.log` as:
` INFO [jail] Found 192.0.2.25`
First if you'll see at least 5 such lines with this IP address within 10 minutes, the IP goes banned and you should see:
` NOTICE [jail] Ban 192.0.2.25`
+(the solution could be to increase `findtime` or decrease `maxretry`); - no matching date-time pattern or wrong date-time pattern specified for the jail resp. filter via `datepattern`, thus it does not match the log-line at all; - be careful with `%` character in fail2ban configurations (because of the python-config, it should be dual-escaped `%%`); - note the time of values that fail2ban recognizes from the log-file will be converted using the system time zone (if not specified different) - be sure that the times, written from the corresponding service into the log, are not too old for the fail2ban; @@ -51,7 +56,34 @@ You should then see something like that: *** -**[Q]** Fail2ban detects resp. incorrectly blocks some authentication attempts as failure (e. g. bans my IP address). +**[Q]** Ban takes place but does not work, the intruder is still able to connect and continues an attack +
Answer + +**[A]** If there are `Ban` messages in fail2ban log, but the banning seems not to work, so that the intruder continues an attack and mostly there are many messages `Already banned` (also several minutes after ban occurred), it could have many reasons: +- there is no banning action (mostly set as parameter `banaction`) or the action is not suitable to ban this ticket: for instance cannot ban this IP family (such as not IPv6 capable), or trying to ban not IP-based ticket (like user or session-ID) with IP-based action, etc
+ (firstly check for errors in fail2ban log immediately after ban and at start of fail2ban); +- firewall or net-filter based action does not work at all or for some constellation: + * port-based action gets wrong port, for instance service `sshd` listening to port 2222, but in jail the `port` is still set default value 22
+ (solution is to specify `port = 2222` for this jail or to switch to all-ports banning action, like `banaction = iptables-allports`); + * multiport action doesn't cover all ports the service is listening for, e. g. service `nginx` listening to port 80 and 443 but also 8080 for some reason, but in jail the `port` is still set default value 80,443
+ (solution is to extend port `port = 80,443,8080` for this jail or to switch to all-ports banning action, like `banaction = iptables-allports`); + * your action bans only TCP protocol, but the failures are generated by UDP connection (incoming UDP packets are bypassing net-filter rules for TCP traffic); + * firewall or net-filter the action is based on does not work (for instance action uses kernel module which is unsupported on the system, or some feature is unsupported or not properly configured in container or virtual environment); + * firewall or net-filter subsystem has some configuration preventing fail2ban ban properly e. g. ignores already established connections, so intruder is able to continue over established keep-alive socket unless it timeouts (or server/client closes the connection) + (solution is to remove such whitelisting firewall rules for established connection or to extend action with some special handling dropping or rejecting the active established connection of intruder, using something like `tcpkill`, `killcx`, `ss`, etc); + * there are some other firewalls/net-filters yet or even some white-listing rules with higher precedence than fail2ban, allowing banned connections or forwarding them somewhere (e. g. to docker container) before fail2ban rules would have an effect;
+ (check all native tables and chains of lowest level net-filter sub-system, e. g. `iptables -Ln`, `nft list`, etc and resolve possible conflicts, e. g. remove rules allowing banned connections or reorder them below the fail2ban tables or chains, or switch to another banning action using net-filter better suitable for your system); +- everything is correct with banning action, but there are no rules in chains or tables of net-filter at some point: + * some service or tool may remove fail2ban tables or flush its chains accidently (for instance using `iptables-restore` without `-n` or `--noflush`) etc; + * your net-filter sub-system is not multi-processing safe, for example changing of some tables from two processes i. e. fail2ban and some service simultaneously loses modification of fail2ban (last wins); +- there are `Unban` messages in fail2ban log immediately or short time after the intruder gets banned (so it gets unbanned too early): + * either your `bantime` is too small (increase this value); + * or the fail2ban or the monitored service are affected by the time-zone issue (times are different in those logs); +
+ + +*** +**[Q]** Fail2ban detects resp. incorrectly blocks some authentication attempts as failure (e. g. bans my IP address)
Answer **[A]** It may be, that the expression is not good enough or the matching just occurs in pre-authentication step (e. g. by handshake) and so even per success login you have one failure (in sense of your configuration of fail2ban), so normally for the "fix" in this case, it will be enough to increase `maxretry` resp. to decrease `findtime` for this jail.