fail2ban_add_custom_rule

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
fail2ban_add_custom_rule [06.12.2020 08:39] – created Pascal Suterfail2ban_add_custom_rule [06.12.2020 09:05] (current) Pascal Suter
Line 4: Line 4:
 usually your favorite distribution comes packed with filters and all you may have to do is enable them.. however, sometimes you might want to write your own rule, be it for your own application or for some case which is simply not covered by the default rules..  usually your favorite distribution comes packed with filters and all you may have to do is enable them.. however, sometimes you might want to write your own rule, be it for your own application or for some case which is simply not covered by the default rules.. 
  
-here is an example of how I added a new rule for postfix which filters out some bots who try to brute-force smtpd accounts. most of those are covered by the default filter in ubuntu, however, i had a case of a bot which tried to authenticate on a smtpd which only allowed TLS but it did not use TLS.. so the bot will honestly never suceed with this method of course, but it still was flooding my logs, so i decided to do something against that.. +here is an example of how I added a new rule for postfix running on an **ubuntu server** which filters out some bots who try to brute-force smtpd accounts. most of those are covered by the default filter in ubuntu, however, i had a case of a bot which tried to authenticate on a smtpd which only allowed TLS but it did not use TLS.. so the bot will honestly never suceed with this method of course, but it still was flooding my logs, so i decided to do something against that..  
 + 
 +**NOTE** Please keep in mind, that path names and best practices on where to save your configs vary slightly from distribution to distribution.. debian and therefore ubuntu style is to not edit distribution provided config files and instead use the ''.d'' directory with the same basename as the config file you want to edit and then create a new ''.conf'' in there which overwrites the defaults you want to change or adds to the config.. this of course only works for apps that support includes and the necessary tools in their config parsing mechanisms, but luckily fail2ban is one of those, so we keep it debian friendly, which will help when you upgrade your system (it won't ask you if you want to keep your old config or overwrite it with the default)
  
 first let's look a the log entries which identify that sucker:  first let's look a the log entries which identify that sucker: 
Line 33: Line 35:
 s so you can see, the regex matched 9005 lines, that seems about right..  s so you can see, the regex matched 9005 lines, that seems about right.. 
  
 +next up is our **jail** for the filter we just created. we create a new file called '/etc/fail2ban/jail.d/postfix-ehlo.conf'
 +<code fal2ban /etc/fail2ban/jail.d/postfix-ehlo.conf>
 +enabled  = true
 +port     = smtp,465,submission
 +logpath  = %(postfix_log)s
 +</code>
 +I got the ''%(postfix_log)'' from an existing postifx jail in the same folder.. in any other case I would have simply hardcoded the actual log directory like ''/var/log/mail.log'' or whatever it is in your case.. 
  
 +there are many more options you could set, like ''action'', ''maxretry'', ''bantime'', ''findtime'' etc, but most of them are already set in the default config, so no need to adjust those
 +
 +so now lets reload our config to enable our shiny new rule: 
 +  fail2ban-client reload
 +if whoever you want to block is still active, you should see him blocked in a short time.. check your logs like
 +<code>
 +# grep Ban /var/log/fail2ban.log
 +2020-12-06 07:22:19,440 fail2ban.actions        [24010]: NOTICE  [postfix-ehlo] Ban 170.106.11.80
 +</code>
 +and yell "haha, gotcha"!
 +
 +or you can also see your success via the ''fail2ban-client'': 
 +<code>
 +# fail2ban-client status postfix-ehlo
 +Status for the jail: postfix-ehlo
 +|- Filter
 +|  |- Currently failed: 0
 +|  |- Total failed: 8
 +|  `- File list: /var/log/mail.log
 +`- Actions
 +   |- Currently banned: 0
 +   |- Total banned: 1
 +   `- Banned IP list: 170.106.11.80
 +</code>
 +
 +there you go :) 
 +
 +by the way, to activate any of the already existing jails, you need to set the ''enabled'' parameter to ''yes''. but rather than modifying the distribution supplied configs, I'd recommend to create your own config for example ''/etc/fail2ban/jail.d/activejails.conf'' with a content like so: 
 +<code>
 +[sshd]
 +enabled = true
 +
 +[postfix]
 +enabled = true
 +
 +[dovecot]
 +enabled = true
 +</code>
 +the names of the pre-configured jails can be found in ''/etc/fail2ban/jails.conf'' and are usually identical to the filter name and file name of the filter in ''/etc/fail2ban/filter.d/''
 +
 +after enabling your filters, reload and check with the ''fail2ban-client''
 +<code>
 +# fail2ban-client reload 
 +OK
 +# fail2ban-client status
 +Status
 +|- Number of jail: 4
 +`- Jail list: dovecot, postfix, postfix-ehlo, sshd
 +</code>
  • fail2ban_add_custom_rule.1607240353.txt.gz
  • Last modified: 06.12.2020 08:39
  • by Pascal Suter