Differences

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

--- computing:fail2ban [2019/11/02 23:04] – created oemb1905
+++ computing:fail2ban [2024/12/13 16:22] (current) – oemb1905
@@ Line 1: / Line 1: @@
-action = %(action_mw)s
+-------------------------------------------
+  * **fail2ban**
+  * **Jonathan Haack**
+  * **Haack's Networking**
+  * **oemb1905@jonathanhaack.com**
-sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
+-------------------------------------------
+//fail2ban//
+-------------------------------------------
+This tutorial is designed to help you install fail2ban and get a basic set of configurations in place.
+  sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
+  sudo nano /etc/fail2ban/jail.local
+Once inside the configuration file jail.local edit the destination email and the action parameter. Read the conf file and decide which combination of m, w, l is right for your situation.
+  <destemail = email>
+  <action = %(action_mwl)s>
+If you attempt to log in via ssh and fail within any 4 hour period 4 different times, then you are immediately blocked for a week.
+  [DEFAULT]
+  bantime  = 1w
+  findtime  = 240m
+  maxretry = 4
+TheIf over the last 3 weeks the ip address in question was banned at least twice, then the stricter ban of 20 weeks takes effect.  If you plan to review 3 weeks of information, with up to three violations each for a week, then you probably need at least 21 days of data.  I rounded to 30 for slightly more granularity.
+  [recidive]
+  enabled = true
+  logpath  = /var/log/fail2ban.log
+  banaction = %(banaction_allports)s
+  bantime  = 20w
+  findtime = 3w
+  maxretry = 2
+In order for this to work, the database purge parameter needs to be adjusted to be greater than or equal to what you specify for the find time in recidive.
+  sudo nano /etc/fail2ban/fail2ban.conf
+  <dbpurgeage = 30d>
+Okay, so far, fail2ban is installed, configured, and its service might even be running post-installation, but it it is not doing anything.  In order for fail2ban to take effect, you need to insert ''enabled = true'' within each element below.
+  [sshd]
+  enabled = true
+  port    = ssh
+  logpath = %(sshd_log)s
+  backend = %(sshd_backend)s
+After enabling the elements you are in need of, and once all of your other basic configuration changes are done, restart the service, and then check the logs to verify functionality and debug as needed.  Verify what fail2ban has done to your iptables in order to enact the policies above.
+  sudo systemctl restart fail2ban.service
+  sudo tail -f /var/log/fail2ban.log
+  sudo iptables -L f2b-sshd
+  sudo fail2ban-client status
+Hope this helps!  Oh yeah ... here is how to remove a false positive!
+  fail2ban-client set ssh unbanip 10.xx.15x.12x
+  fail2ban-client unban --all
+Another method that does more than individual services, and instead zaps all records:
+  sudo systemctl stop fail2ban
+  sudo truncate -s 0 /var/log/fail2ban.log
+  sudo rm /var/lib/fail2ban/fail2ban.sqlite3
+  sudo systemctl restart fail2ban
+Systemd log issues. Change the sshd jail as follows
+  sudo nano /etc/fail2ban/jail.local
+  backend = systemd
+  #backend = %(sshd_backend)s
+Some recommend adding backend = systemd into jail.conf, but I've found that does nothing. The error over ipv6 not being set and using auto can be removed as follows:
+  sudo nano /etc/fail2ban/fail2ban.conf
+  'allowipv6 = auto'
+ --- //[[alerts@haacksnetworking.org|oemb1905]] 2024/12/13 16:22//

Haack's Wiki

User Tools

Site Tools

Differences

Page Tools