Difference between revisions of "Talk:Fail2ban"
(Moved here from main how-to page) |
(No difference)
|
Revision as of 06:30, 20 September 2014
With many thanks to the author for his work templating the install of Fail2Ban into SME8/9 here are some notes for introduction:
- F2B adds to SMEserver's own high security after SME has already reported forbidden access, file not found or a relaying denied error. F2B filters read appropriate logs and associated jails implement timed bans (by dropping all packets arriving from the culprit IP). Another F2B action sends a notifying email.
- Restarting the contrib clears existing bans but a suitable 'findtime' results in a reban. Be aware that the restart delay can be unexpectedly lengthy, I've noticed a variation of between a few seconds to one that extended to nearly 40 minutes! YMMV
- The 'out of the box' install's given filters are *already* completely capable of detecting most problems without any user templating being necessary.
- Parameters are passed using db commands. On my SME8.1 and with only www & email expectations (no SSH) I used:
db configuration setprop qpsmtpd Fail2Ban enabled
db configuration setprop httpd-e-smith Fail2Ban enabled
config setprop fail2ban MailRecipient root
config setprop fail2ban FindTime 1200
config setprop fail2ban BanTime 604800
config setprop fail2ban MaxRetry 1
signal-event fail2ban-conf
- don't use MaxTry=0 (apparently it is a special Perl value)
- required www triggers need to have appeared in /var/log/httpd/error_log
- required email triggers need to have appeared in /var/log/*qpsmtpd/current
I broke the master template by making the internal multipliers ($MaxRetry/$max) equivalent to unity.
The expanded jail.conf then showed only my own db command value for MaxRetry=1:
see /etc/e-smith/templates/ect/fail2ban/jail.conf/*
On installation and eventual configuration I have observed automatic immediate bans
for all 'relaying denied' email and iterations of semalt referer spam within 'findtime':-)