I don't think you have seen my 2 contributions which have nothing to do with fail2ban nor the Plesk firewall....@mr-wolf and @OverWolf
Nice to read that you are busy with implementing Plesk Firewall extension and Fail2Ban, which can be a good combination.
However, there are some common "good practices" when it concerns Plesk Firewall and Fail2Ban together.
Amongst others:
- Fail2Ban is rather resource hungry: make sure that your Fail2Ban config is proper in the sense that the performance footprint is minimal
- Fail2Ban can allow some hack attempts to go undetected: keep track of your log files to establish whether Fail2Ban misses out on specific hack attempts
- Fail2Ban customization and Fail2Ban usage with Nginx can make the system very strong in terms of security
- Plesk Firewall can be used in combination with Fail2Ban, but there are some pitfalls, which I will explain below
I am focussing on the last point, since the usage of Plesk Firewall extension and Fail2Ban can have some unexpected consequences.
In the light of the above, the following has to be mentioned:
a) Plesk Firewall extension is essentially a GUI for iptables: having Plesk Firewall and Fail2Ban both altering and creatig iptable firewall rules can result in a huge firewall set, which can result in a (relatively) huge performance penalty, even in the case where ipset is being used, (and)
b) Plesk Firewall extension is a GUI that is not showing all iptabels rulesets: as a result, it can be the case that
- manually created firewall rule sets AND rules sets created with Plesk Firewall extension AND firewall rulesets created by Fail2Ban will cause a (lot of) double firewall rules,
- Fail2Ban has to "work harder" if the Plesk Firewall extension is not used to it's full potential and/or to the full extent,
and the overall result is often a significant performance penalty, (and)
c) firewall rulesets have to be persistent (across reboots) and
- Plesk Firewall extension uses a script that results in persistence
- Fail2Ban uses python code to rescan logs at reboot, resulting in persistence
- manual iptables entries are NOT persistent by default
and the overall result is that one has to be careful and take into account that one really has to have persistent iptables rulesets,
and all of the above is non-exhaustive summary of points that have to be taken into consideration.
However, a number of general rules of thumb can be introduced to make life more easy:
1 - use Fail2Ban to detect and temporarily block bad IPs,
2 - use Fail2Ban to detect recurring attempts from bad IPs AND add these bad IPs via the Plesk Firewall extension,
3 - do not OR try to prevent usage of manual iptables entries.
All of the above will result in
- a more efficient Fail2Ban process: most of the recurring attempts from bad IPs are blocked by (persistent!) firewall rules, Fail2Ban does not have to "work hard"
- the probability of double firewall rulesets is decreased significantly
- the chance that important iptables rulesets are non-persistent is almost non-existing
Finally, note that one can use Nginx or ModSec to make the whole system less vulnerable to hack attempts and/or make the entire system more efficient.
Hope the above helps a bit.....
Regards.........
I'm just helping overwolf to apply my script ipset-country.
Please check them out first and then comment all you like...