@Nomadturk,
Indeed, I can manually add my own iptables rules via the command line but why bother managing my rules from two different places whereas I can have only one script to rule'm all? Plesk firewall does suck. In some cases my rules didn't even know and I said that's it. Disable the whole thing and create my own.
As always, I provided the "moderate" answer.
In fact, an experienced sysadmin (i.e. not a Plesk admin, that is something else) should be using iptables directly.
In a sense, the Plesk Firewall will suffice, in particular for inexperienced and "not so advanced" admins (and the Plesk Firewall certainly prevents them from locking themselves out).
I wouldn't want to permanently block an IP. Sometimes even I get myself banned since my ssh client was set to use an old key file/port etc. Having a long ban time on fail2ban is sufficient enough. Along with ddos deflate it's a good suplement to iptables firewalls.
Really, some IPs
should be blocked permanently, since particular spammers and hackers are consistently working from specific IP address ranges.
In addition, any key file and/or port change should not result in blocking (i.e. permanent ban) or banning (i.e. temporary ban, very likely the result of Fail2Ban).
Start with whitelisting your IP in Fail2Ban and set a firewall rule "allow from... deny from all others" in order to have you granted root access with SSH all the time.
Note that you can create the firewall rule by hand (that involves multiple lines, if you want to do it correctly) OR use the Plesk Firewall (that involves creating a custom rule).
Also for fail2ban jails, the amount he has indeed is a lot but I am one of those who seperates all log files and tries to check them seperately. That might work in case the attacker is not using a regular method such as classic fail2ban jails. In such cases you do need more jails for it to be detected. Or altering the existing ones to fine tune. That also works.
Fail2Ban does not require multiple log files to function properly with a limited number of logs: you can add multiple logs to one jail.
Fail2Ban is rather flexible, but most people forget the complexity of Fail2Ban itself, including the inherent flaws in the current stable (and also future) versions.
Keep Fail2Ban usage simple, allow it to be the
second step in security, with a properly defined firewall being the first step.
In essence, if you get any IP bans from Fail2Ban, you have to conclude that your firewall is not properly defined and lets undesired traffic through.
And also note that one can use alternative measures, besides a firewall and Fail2Ban.
For instance, undesired traffic due to spam activities can be mitigated with a "fake" (i.e. non-existent) mail server with high priority (spammers do often fall for that trick).
Anyway, a lot of measures can and should be taken, in order to tighten up security.
Hope the above helps and/or explains a bit.
Kind regards.....
Facebook
Twitter
