a great way to get rid of some hackers from our web sites

installation on Debian 8

Step 1: Install

Method One
the default install method

First thing to do is find out what version of fail2ban would install using the default install method:

# sudo apt search fail2ban

         Sorting… Done
         Full Text Search… Done
         fail2ban/stable 0.8.13-1 all
         ban hosts that cause multiple authentication errors

The default install method goes like this:

# su
# apt-get update
# apt-get install fail2ban
# cd /etc/fail2ban/
# cp jail.conf  jail.local ( as jail.local will overrule jail.conf )

# vi jail.local  
( and enable ssh in the section headed [ssh],  setting “enabled = true” )

# service fail2ban restart

Run “iptables -S” 
to make sure that Fail2Ban has added itself successfully to the ip rules.

That is: for version 0.8.13, there would be an entry in the iptables of 
“-N fail2ban-ssh” when [ssh] is enabled 
in the configuration file “/etc/fail2ban/jail.local”.

If you want the multi-line functionality and other stuff from a later version of fail2ban, I suggest method two below ….. in continue reading the rest of the setup link following.

Step 1:  Alternate Install

Method Two
the alternate install method

The alternate method installs directly from the the latest source available:

The web page https://www.fail2ban.org/wiki/index.php/Main_Page contains the latest information on where the fail2ban software is located, such as: https://github.com/fail2ban/fail2ban/releases which, like anything in life, can change from the day of this writing.

(a) Download the source.

# su
# cd /usr/local/src
# wget  https://github.com/fail2ban/fail2ban/archive/debian/0.9.6-1.tar.gz
 ( current location as of this writing )

Some output messages may appear like this following, which is sort of normal

--2017-03-20 12:34:20--  https://github.com/fail2ban/fail2ban/archive/debian/0.9.6-1.tar.gz
Resolving github.com (github.com)...,
Connecting to github.com (github.com)||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/fail2ban/fail2ban/tar.gz/debian/0.9.6-1 [following]
--2017-03-20 12:34:20--  https://codeload.github.com/fail2ban/fail2ban/tar.gz/debian/0.9.6-1
Resolving codeload.github.com (codeload.github.com)...,
Connecting to codeload.github.com (codeload.github.com)||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: ‘0.9.6-1.tar.gz’
0.9.6-1.tar.gz                       [  <=>                                                      ] 371.54K  1.06MB/s   in 0.3s   
2017-03-20 12:34:21 (1.06 MB/s) - ‘0.9.6-1.tar.gz’ saved [380452]

(b) Install the source.

# gzip -d 0.9.6-1.tar.gz
# tar xf 0.9.6-1.tar
# cd fail2ban-debian-0.9.6-1

--------------- optional ------------------------

Check that no fail2ban is already running
# ps -ef | grep fail2ban
---> stop any running old fail2ban
# service fail2ban stop
 # apt-get remove 
--------------- end of optional ------------------------

---> build and install new version of fail2ban
# python setup.py build 
# python setup.py install ( this version installs in /usr/bin ) 

--------------- more optional ------------------------

Check that nothing of the old version still exists some place.
#  whereis fail2ban-server
eg: la /usr/bin/fail2ban-server
eg: la /usr/local/bin/fail2ban-server

What I do like to do  then is rm the old versions in /usr/bin,  
and just put a link there to the new version in /usr/local/bin, 
just to be sure for the time being anyway, 
having been burnt a few times in the past.

# cd /usr/bin
# rm fail2ban-server
# ln /usr/local/bin/fail2ban-server fail2ban-server
# rm fail2ban-client
# ln /usr/local/bin/fail2ban-client fail2ban-client
# rm fail2ban-regex
# ln /usr/local/bin/fail2ban-regex  fail2ban-regex
# rm faillog
# ln /usr/local/bin/faillog faillog

Also, the new 0.9 version of fail2ban uses f2b names in the iptables, whereas the old 0.8 version used fail2ban, so both names could still be there.

To be tidy, I also delete the old names in the iptables.

The new entry to keep is: -N f2b-ssh

The old entries can be deleted by the line numbers they are on.

# iptables -L --line-numbers
# iptables -D fail2ban-ssh 1 
     ( deletes the first line in fail2ban-ssh procedure )
# iptables -X fail2ban-ssh 
     ( deletes the fail2ban-ssh procedure )

——————— end of optional bit ————————————–

Step 2.  Configure Fail2Ban

# cd /etc/fail2ban
# cp jail.conf  jail.local
# vi  jail.local   ( to contain the following added section )

       enabled  = true
       port     = ssh
       filter   = sshd
       logpath  = /var/log/sshd.log
       maxretry = 2

Step 3.  Creating a separate ssh log file ( to help speed up the filters )

The program rsyslog can be configured to use a single log file for ssh connections, say in /var/log/sshd.log.

Firstly, create a file /etc/rsyslog.d/sshd.conf containing the line:

                        if $programname == ‘sshd’ then /var/log/sshd.log

Lastly, restart the rsyslog and fail2ban service:

# service rsyslog restart 
# /usr/local/bin/fail2ban-client reload 
# fail2ban-client status ssh ( shows what log file fail2ban is now monitoring ) 

Edit the file /etc/logrotate.d/rsyslog and insert after the line containing “/var/log/auth.log”, these two lines:


Step 4. Start fail2ban

# /usr/local/bin/fail2ban-client -b start

Now add some more iptable rules ....

iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT 3 -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
iptables -I INPUT 4 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT 5 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
iptables -I INPUT 6 -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
iptables -I INPUT 7 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
iptables -I INPUT 9 -p tcp -m tcp --dport 22 -j ACCEPT
iptable -I INPUT 10 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -I INPUT 11 -p tcp -m tcp --dport 80     -m state --state NEW -j ACCEPT
iptables -I INPUT 11 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
iptables -I INPUT 12 -p icmp -m icmp --icmp-type 8 -j ACCEPT
iptables -I INPUT 13 -j LOG
iptables -P  INPUT  DROP

After adding these rules, you should have something like this:

 # iptables -L --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source    destination         
1    ACCEPT   all  --  anywhere  anywhere            
2    ACCEPT   all  --  anywhere  anywhere  ctstate RELATED,ESTABLISHED
3    DROP     tcp  --  anywhere  anywhere  tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
4    ACCEPT   all  --  anywhere  anywhere  state RELATED,ESTABLISHED
5    DROP     tcp  --  anywhere  anywhere  tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
6    DROP     tcp  --  anywhere  anywhere  tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
7    DROP     tcp  --  anywhere  anywhere  tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
8    f2b-sshd tcp  --  anywhere  anywhere  multiport dports ssh
9    ACCEPT   tcp  --  anywhere  anywhere  tcp dpt:ssh
10   ACCEPT   tcp  --  anywhere  anywhere  tcp dpt:http state NEW
11   ACCEPT   tcp  --  anywhere  anywhere  tcp dpt:http-alt state NEW
12   ACCEPT   icmp --  anywhere  anywhere  icmp echo-request
13   LOG      all  --  anywhere  anywhere  LOG level warning
Chain FORWARD (policy ACCEPT)
num  target     prot opt source    destination         
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source    destination         
Chain f2b-sshd (1 references)
num  target     prot opt source    destination         
1   REJECT all  --  anywhere  reject-with icmp-port-unreachable
2   RETURN all  --  anywhere       anywhere   

Step 5. save these new iptables rules

Now save the current iptable rules 
so that they persist on a reboot of the system. 

# mkdir  /etc/iptables  ( if this directory is not already there )
# apt-get  install  iptables-persistent
          or if already installed ...
# dpkg-reconfigure  iptables-persistent  ( enter yes at the prompt )

# tail -100 /var/log/sshd.log | grep "sshd"  ( shows what fail2ban is currently searching )

 # tail -20 /var/log/fail2ban.log  ( shows what fail2ban has found and its actions )
2017-03-03 15:26:00,791 fail2ban.filter         [4065]: INFO    [ssh] Found
2017-03-03 15:26:00,794 fail2ban.filter         [4065]: INFO    [ssh] Found
2017-03-03 15:26:00,794 fail2ban.filter         [4065]: INFO    [ssh] Found
2017-03-03 15:26:00,795 fail2ban.filter         [4065]: INFO    [ssh] Found
2017-03-03 15:26:00,795 fail2ban.filter         [4065]: INFO    [ssh] Found
2017-03-03 15:26:01,449 fail2ban.actions        [4065]: NOTICE  [ssh] Ban
2017-03-03 15:26:01,662 fail2ban.actions        [4065]: NOTICE  [ssh] Ban
2017-03-03 15:26:01,869 fail2ban.actions        [4065]: NOTICE  [ssh] Ban
2017-03-03 15:26:02,082 fail2ban.actions        [4065]: NOTICE  [ssh] Ban
# /usr/local/bin/ fail2ban-client status ssh ( shows fail2ban status )

Status for the jail: ssh
|- Filter
|  |- Currently failed: 2
|  |- Total failed: 175
|  `- File list: /var/log/sshd.log

`- Actions
  |- Currently banned: 4
  |- Total banned: 61
  `- Banned IP list:

Step 6.    Check what fail2ban is finding ( or not finding )

/usr/local/bin/fail2ban-client -d  | grep [ ssh | target ]  ( will list off its settings )

The [sshd] section in /etc/fail2ban/jail.local monitors the sshd log files in /var/log/sshd.log

Fail2ban uses Regex filters to search this file.  These Regex filters can be changed to match the types of lines occurring in the sshd logs, as spammers find newer ways to be annoying.

Firstly, change the log level for sshd connections, if not already done so:

        # cd /etc/ssh
        # vi  sshd_config ( change the log level to VERBOSE )
                LogLevel VERBOSE
                ##LogLevel INFO

Secondly, check the sshd filters.
        # cd  /etc/fail2ban/filter.d
        # vi  sshd.conf

For example: adding a line to failregex to match lines in the sshd log files
containing, for example “Received disconnect from ”:

failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error|failed) for .* from <HOST>( via \S+)?\s*$       
                  ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
                ^%(__prefix_line)s(?:error: )?Received disconnect from <HOST>: .* (?:\[preauth\])?$

Check what the regular expressions are now finding, by doing this :

#  fail2ban-regex    /var/log/auth.log   /etc/fail2ban/filter.d/sshd.conf
#  fail2ban-regex  print-all-matched    /var/log/auth.log   /etc/fail2ban/filter.d/sshd.conf

Note: if the system date has changed, say from a change in timezones from universal time to local time, the whole operating system needs rebooting after these changes  so that the log files have the new dates, which fail2ban relies upon.  That is: the date command needs to return the same time as the dates appearing in the log files.  The timezone can be set with dpkg-reconfigure tzdata

After changes to the fail2ban configurations, restart fail2ban:

# /usr/local/bin/fail2ban-client reload

 Step 7. Auto restart fail2ban on a system boot

(a) The Sys V initial system boot method :

# cp /usr/src/fail2ban-debian-0.9.6-1/files/debian-initd  /etc/init.d/fail2ban

# chmod +x /etc/init.d/fail2ban

Check that the script file “/etc/init.d/fail2ban” contains the current locations for the installed fail2ban ( a bit tricky for anyone not an expert at script programming ).

# update-rc.d  fail2ban  defaults

Now test this new start up script by stopping any running fail2ban ( with “fail2ban-client stop” ) and using this script to start it up…..

# /etc/init.d/fail2ban start

Starting Fail2Ban…done.

# /etc/init.d/fail2ban status

daemon:  fail2ban is running (pid 12345)

# ps -ef | grep fail2ban | grep -v grep

root     12345  1  0 11:02 ?    00:00:00  /usr/local/bin/daemon –respawn –name Fail2Ban –pidfiles  /var/run –stdout daemon.info –stderr daemon.e  rr — /root/fail2ban.sh

# /etc/init.d/fail2ban stop

Stopping Fail2Ban…done. 

(b) The other initial boot method:

#   cp  /usr/src/fail2ban-debian-0.9.6-1/files/fail2ban.service   /etc/systemd/system

#  chmod 664  /etc/systemd/system/fail2ban.service

Change the locations in the file “fail2ban.service” of fail2ban to where it is installed ( ie /usr/local and also /var/run/fail2ban )

Description=Fail2Ban Service
After=network.target iptables.service firewalld.service
PartOf=iptables.service firewalld.service

ExecStart=/usr/local/bin/fail2ban-client -x start
ExecStop=/usr/local/bin/fail2ban-client stop
ExecReload=/usr/local/bin/fail2ban-client reload


Lastly, reload systemd :

# touch  /var/run/fail2ban

# systemctl  daemon-reload
# systemctl enable fail2ban.service
# fail2ban-client  stop
# systemctl  start fail2ban.service

that’s it
we have now reduced spam and hacker traffic,
... for the time being at least.

© 2017, James Harry Burton. All rights reserved.

2 thoughts on “a great way to get rid of some hackers from our web sites

Leave a Reply

Your email address will not be published. Required fields are marked *