FreeBSD SSH port security 3

From JonDonym Wiki
(Difference between revisions)
Jump to: navigation, search
Line 8: Line 8:
 
  make install</code>
 
  make install</code>
  
At the time of this writing, the fail2ban version in the ports collection was 0.8.4 and through installation it relies on python 2.5.  
+
At the time of this writing, the fail2ban version in the ports collection was 0.8.4 and during installation it relies on python 2.5.  
  
However, with some older versions of fail2ban there's a bug occuring when python 2.6 gets used (as python 2.5 and python 2.6 are not compatible). However, try to use python 2.5 to avoid any issues. But usually, python 2.5 will get built too by building fail2ban (managed by the dependency mechnism of the ports collection).
+
However, with some older versions of fail2ban there's a bug occurring when python 2.6 gets used (as python 2.5 and python 2.6 are not compatible). Therefore, try to use python 2.5 to avoid any issues. But usually, python 2.5 will get built anyway by building fail2ban (managed by the dependency mechanism of the ports collection).
  
 
After installation through „make install“, the fail2ban server once needs to get started with
 
After installation through „make install“, the fail2ban server once needs to get started with
 
  <code>fail2ban-server</code>
 
  <code>fail2ban-server</code>
  
Stop then the server again by
+
Then, stop the server again by
 
  <code>/usr/local/etc/rc.d/d/fail2ban stop</code>
 
  <code>/usr/local/etc/rc.d/d/fail2ban stop</code>
(from now on, the program can get controlled by /usr/local/etc/rc.d/fail2ban start | stop | restart)
+
(from now on, the program can be controlled by /usr/local/etc/rc.d/fail2ban start | stop | restart)
  
 
Fail2bans configuration files reside in /usr/local/etc/fail2ban and its subdirectories.
 
Fail2bans configuration files reside in /usr/local/etc/fail2ban and its subdirectories.
Line 36: Line 36:
 
  <code>vi /usr/local/etc/fail2ban/jail.conf</code>
 
  <code>vi /usr/local/etc/fail2ban/jail.conf</code>
  
Make sure, the following lines are included (and nothing else):
+
Make sure the following lines are included (and nothing else):
  
 
  <code>[DEFAULT]
 
  <code>[DEFAULT]
Line 67: Line 67:
 
  maxretry = 3</code>
 
  maxretry = 3</code>
  
Ensure again, nothing else is in the file (or comment out the other lines). Then save and exit.
+
Ensure again nothing else is in the file (or comment out the other lines). Then save and exit.
  
 
Next, create a new file in the action.d subdirectory:
 
Next, create a new file in the action.d subdirectory:
 
  <code>vi /usr/local/etc/fail2ban/action.d/pf.conf</code>
 
  <code>vi /usr/local/etc/fail2ban/action.d/pf.conf</code>
  
Make sure, the following lines get inserted there:
+
Make sure the following lines get inserted there:
  
 
  <code>[Definition]
 
  <code>[Definition]
Line 85: Line 85:
 
  localhost = 127.0.0.1 </code>
 
  localhost = 127.0.0.1 </code>
  
Please make sure you got the right „ticks“ for the actionunban line !
+
Please make sure you got the right „ticks“ for the actionunban line!
  
 
Save and exit. Surely you did recognize both of the pfctl commands as we had something similar in the chapter about PF.
 
Save and exit. Surely you did recognize both of the pfctl commands as we had something similar in the chapter about PF.
Line 92: Line 92:
 
  <code>/usr/local/etc/rc.d/fail2ban start</code>
 
  <code>/usr/local/etc/rc.d/fail2ban start</code>
  
Watch the fail2ban logfile to check for any issues occuring via:
+
Watch the fail2ban logfile to check for any issues occurring via:
 
  <code>tail -f /var/log/fail2ban.log</code>
 
  <code>tail -f /var/log/fail2ban.log</code>
  
Last work: We now also want fail2ban to automatically startup at boot time.
+
Last work: We now also want fail2ban to automatically start up at boot time.
 
  <code>vi /etc/rc.conf</code>
 
  <code>vi /etc/rc.conf</code>
  
Line 104: Line 104:
 
It will get automatically started and go ahead working at boot time.
 
It will get automatically started and go ahead working at boot time.
  
Hints for production usage
+
===Hints for production usage===
  
IMPORTANT:
+
====IMPORTANT====
Please do in no case forget to uncomment the line in /etc/crontab which we earlier used to regularly switch off PF !  
+
Please do in no case forget to comment the line in /etc/crontab which we earlier used to regularly switch off PF!  
 
  <code>vi /etc/crontab</code>
 
  <code>vi /etc/crontab</code>
  
Search for the entry disabling PF every two minutes and insert a comment sign (#) in the first column. Do NOT uncomment the other line (writing the table content to disk every minute).  
+
Search for the entry disabling PF every five minutes and insert a comment sign (#) in the first column. Do NOT comment the other line (writing the table content to disk every minute).  
 
Save the /etc/crontab file again and exit the editor.
 
Save the /etc/crontab file again and exit the editor.
  
  
On lifetime of IP entries in the table of banned IP addresses:
+
On the lifetime of IP entries in the table of banned IP addresses:
  
 
The setup described above bans IP addresses „forever“. There is no mechanism included to release banned IP addresses from the ban table. But as the host we are talking about is a host dedicated to run mixes we almost certainly do not need to take care for dynamic IP addresses. That way, banning IP addresses forever is no problem.
 
The setup described above bans IP addresses „forever“. There is no mechanism included to release banned IP addresses from the ban table. But as the host we are talking about is a host dedicated to run mixes we almost certainly do not need to take care for dynamic IP addresses. That way, banning IP addresses forever is no problem.
  
  
System maintenance:
+
====System maintenance====
  
The FreeBSD „periodic“ mechnism wills send you Emails about the systems health in defined intervalls. Some sort of information on PF will be enclosed by default when PF is working.
+
The FreeBSD „periodic“ mechanism will send you Emails about the systems health in defined intervals. Some sort of information on PF will be enclosed by default when PF is working.
  
You additionally can watch the growing collection of banned IPs from the fail2ban table by a cronjob driven shell script regularly counting the number of lines in the ''/etc/pf.table.fail2ban'' file (which equals the number of banned IP entries).
+
Additionally, you can watch the growing collection of banned IPs from the fail2ban table by a cronjob driven shell script regularly counting the number of lines in the ''/etc/pf.table.fail2ban'' file (which equals the number of banned IP entries).
  
Example shell script:
+
====Example shell script====
  
 
  <code>#!/bin/sh
 
  <code>#!/bin/sh
Line 147: Line 147:
  
  
Enhanced configuration for additionally protect services ran within jails:
+
====Enhanced configuration for protecting services run within jails additionally====
  
 
As fail2ban runs on the host system and as such it can „reach“ also logfiles from within Jails you easily could enhance fail2ban's configuration to also scan further logfiles residing in the filesystem of Jails. That does not make sense as long as you have only Mixes running in your Jails but there might be additional Jails with other services running. This way you can use the whole setup very easily to also protect services running in Jails. The fail2ban wiki and the default configuration files contain a list of adaptions for various well known server daemons. You also could build your own fail2ban scanner if you are familiar with Regex.
 
As fail2ban runs on the host system and as such it can „reach“ also logfiles from within Jails you easily could enhance fail2ban's configuration to also scan further logfiles residing in the filesystem of Jails. That does not make sense as long as you have only Mixes running in your Jails but there might be additional Jails with other services running. This way you can use the whole setup very easily to also protect services running in Jails. The fail2ban wiki and the default configuration files contain a list of adaptions for various well known server daemons. You also could build your own fail2ban scanner if you are familiar with Regex.
  
  
Using blacklists of earlier banned IP addresses from other sources:
+
====Using blacklists of earlier banned IP addresses from other sources====
  
In case you have lists of earlier banned IPs from other sources you easily could start the /etc/pf.table.failban file with filling those IPs in the /etc/pf.table.failban file. To do so, first prepare your list – it is needed in the form with one IP per line and no content else. Please take care for identical charsets when preparing the file.
+
In case you have lists of earlier banned IPs from other sources you easily could start the /etc/pf.table.failban file with filling those IPs in the /etc/pf.table.failban file. To do so, first prepare your list – it is needed in the form with one IP per line and no content else. Please take care for identical charsets when preparing the file.
  
 
Then stop PF
 
Then stop PF
Line 166: Line 166:
  
  
Merging ban lists from various hosts:
+
====Merging ban lists from various hosts====
  
In case you run various hosts, each protected by the setup described above you also could merge all the different /etc/pf.table.fail2ban files from all hosts into one file and then redistribute the resulting file back to all hosts.
+
In case you run various hosts, each protected by the setup described above, you also could merge all the different /etc/pf.table.fail2ban files from all hosts into one file and then redistribute the resulting file back to all hosts.
  
Command line to get the merged file:
+
Use the command line to get the merged file:
 
  <code>cat file1 file2 | sort | uniq  > mergefile</code>
 
  <code>cat file1 file2 | sort | uniq  > mergefile</code>
  
To automatically collect the files from all hosts, merge them and redistribute them again you of course will need some sort of certificated based SSH or VPN authentication.
+
To collect the files from all hosts automatically, merge them and redistribute them again you, of course, will need some sort of certificate based SSH or VPN authentication.
  
  
==== Geolocalization of banned IP addresses ====
+
==== Geolocalization of banned IP addresses====
  
Finally, you of course could geolocalize the list of IP addresses by a script using any GeoIP service. But this is more for entertainment. It depends on /dev/random which bunch of script kiddies at a given time gets your hosts IP in their hands. Serious attackers anyway will spoof or hide their own IP address the one or other way.
+
Finally, you could geolocalize the list of IP addresses by a script using any GeoIP service. But this is more for entertainment. It depends on /dev/random which bunch of script kiddies at a given time gets your hosts IP in their hands. Serious attackers anyway will spoof or hide their own IP address the one or other way.
  
  
Attacks for which this setup is sufficent:
+
====Attacks for which this setup is sufficent====
  
 
The setup in this HowTo is a solid measure against the vast majority of attacks against hosts. You can easily protect your machine against those attacks. However, in case you expect serious and heavy attacks by experienced blackhats focused on your host, FreeBSD offers a wide range of additional security measures strictly recommended then.
 
The setup in this HowTo is a solid measure against the vast majority of attacks against hosts. You can easily protect your machine against those attacks. However, in case you expect serious and heavy attacks by experienced blackhats focused on your host, FreeBSD offers a wide range of additional security measures strictly recommended then.

Revision as of 15:56, 23 March 2010

navigation: Main Page | FreeBSD and Jails | Setting up fail2ban

Contents

Setting up fail2ban

Fail2ban can be installed from the ports collection. Enter:

cd /usr/ports/security/py-fail2ban
make install

At the time of this writing, the fail2ban version in the ports collection was 0.8.4 and during installation it relies on python 2.5.

However, with some older versions of fail2ban there's a bug occurring when python 2.6 gets used (as python 2.5 and python 2.6 are not compatible). Therefore, try to use python 2.5 to avoid any issues. But usually, python 2.5 will get built anyway by building fail2ban (managed by the dependency mechanism of the ports collection).

After installation through „make install“, the fail2ban server once needs to get started with

fail2ban-server

Then, stop the server again by

/usr/local/etc/rc.d/d/fail2ban stop

(from now on, the program can be controlled by /usr/local/etc/rc.d/fail2ban start | stop | restart)

Fail2bans configuration files reside in /usr/local/etc/fail2ban and its subdirectories. We need to edit and adapt some of them now.

First edit the main configuration file.

vi /usr/local/etc/fail2ban/fail2ban.conf

Make sure, the following four lines are included (and nothing else):

[Definition]
loglevel 	= 3
logtarget 	= /var/log/fail2ban.log
socket 		= /var/run/fail2ban/fail2ban.sock

Save and exit.

Then, edit the „jail“ file (please do not get confused with this naming and the BSD jails, both are completely different things).

vi /usr/local/etc/fail2ban/jail.conf

Make sure the following lines are included (and nothing else):

[DEFAULT]
backend 	= auto
# bantime of -1 means forever, otherwise insert a time period in seconds
bantime	= -1
# time span for which to increment the counter for login failures, 604800 seconds equals 1 week
findtime	= 604800
maxretry	= 5
# replace by the email address to which you'd like to get notes
destemail	= <youremail@yourdomain.tld>
# replace by your own IP addresses you do not want fail2ban to apply to, CIDR format possible too
ignoreip	= 127.0.0.1 <Another IP> <Yet another IP>
logtargets	= /var/log/fail2ban.log
[ssh-pf]
# this „fail2ban-jail“ is switched on and it combines the filter.d/sshd.conf with action.d/pf.conf
enabled	= true
filter		= sshd
action		= pf
logpath	= /var/log/auth.log
maxretry	= 5
[ssh-ddos]
# this „fail2ban-jail“ is switched on and it combines the filter.d/sshd-ddos.conf with action.d/pf.conf
enabled	= true
filter		= sshd-ddos
action		= pf
logpath	= /var/log/auth.log
maxretry	= 3

Ensure again nothing else is in the file (or comment out the other lines). Then save and exit.

Next, create a new file in the action.d subdirectory:

vi /usr/local/etc/fail2ban/action.d/pf.conf

Make sure the following lines get inserted there:

[Definition]
actionstart	= 
actionstop	=
actioncheck	=
actionban	= pfctl -t fail2ban -T add <ip>
actionunban	= pfctl -t fail2ban -T delete `pfctl -t fail2ban -T show 2>/dev/null | grep <ip>`
[Init]
port		= ssh
localhost	= 127.0.0.1 

Please make sure you got the right „ticks“ for the actionunban line!

Save and exit. Surely you did recognize both of the pfctl commands as we had something similar in the chapter about PF.

You may now start fail2ban again:

/usr/local/etc/rc.d/fail2ban start

Watch the fail2ban logfile to check for any issues occurring via:

tail -f /var/log/fail2ban.log

Last work: We now also want fail2ban to automatically start up at boot time.

vi /etc/rc.conf

Add the following line there:

fail2ban_enable=“YES“

Done. The combined setup of PF and fail2ban is up and working. It will get automatically started and go ahead working at boot time.

Hints for production usage

IMPORTANT

Please do in no case forget to comment the line in /etc/crontab which we earlier used to regularly switch off PF!

vi /etc/crontab

Search for the entry disabling PF every five minutes and insert a comment sign (#) in the first column. Do NOT comment the other line (writing the table content to disk every minute). Save the /etc/crontab file again and exit the editor.


On the lifetime of IP entries in the table of banned IP addresses:

The setup described above bans IP addresses „forever“. There is no mechanism included to release banned IP addresses from the ban table. But as the host we are talking about is a host dedicated to run mixes we almost certainly do not need to take care for dynamic IP addresses. That way, banning IP addresses forever is no problem.


System maintenance

The FreeBSD „periodic“ mechanism will send you Emails about the systems health in defined intervals. Some sort of information on PF will be enclosed by default when PF is working.

Additionally, you can watch the growing collection of banned IPs from the fail2ban table by a cronjob driven shell script regularly counting the number of lines in the /etc/pf.table.fail2ban file (which equals the number of banned IP entries).

Example shell script

#!/bin/sh
pfstat=$(pfctl -s info 2>/dev/null | grep „Status:“ | awk '{ print $2 „ „ $3 „ „ $4 „ „ $5 „ „ $6 }'  )
echo „Packet Filter: $pfstat“
bannedIPs=$(cat /etc/pf.table.fail2ban | wc -l | awk '{ print $1 }' )
echo „banned IP entries: $bannedIPs“

Save this script in a directory included in $PATH for root and make it executable.

chmod 700 filename
chown root:wheel filename

Then add a line to /etc/crontab:

0	8	*	*	*	root	/path/scriptname


From then on, you will each day at 8 a.m. get a status Email about PF looking similar to this:

Packet Filter: Enabled for 17 days 05:57:03
Banned IP entries: 326


Enhanced configuration for protecting services run within jails additionally

As fail2ban runs on the host system and as such it can „reach“ also logfiles from within Jails you easily could enhance fail2ban's configuration to also scan further logfiles residing in the filesystem of Jails. That does not make sense as long as you have only Mixes running in your Jails but there might be additional Jails with other services running. This way you can use the whole setup very easily to also protect services running in Jails. The fail2ban wiki and the default configuration files contain a list of adaptions for various well known server daemons. You also could build your own fail2ban scanner if you are familiar with Regex.


Using blacklists of earlier banned IP addresses from other sources

In case you have lists of earlier banned IPs from other sources you easily could start the /etc/pf.table.failban file with filling those IPs in the /etc/pf.table.failban file. To do so, first prepare your list – it is needed in the form with one IP per line and no content else. Please take care for identical charsets when preparing the file.

Then stop PF

pfctl -d

Concatenate, sort and merge both lists:

cat /etc/pf.table.fail2ban /path/oldfile | sort | uniq > /etc/pf.table.fail2ban

Then re-enable PF

pfctl -e


Merging ban lists from various hosts

In case you run various hosts, each protected by the setup described above, you also could merge all the different /etc/pf.table.fail2ban files from all hosts into one file and then redistribute the resulting file back to all hosts.

Use the command line to get the merged file:

cat file1 file2 | sort | uniq  > mergefile

To collect the files from all hosts automatically, merge them and redistribute them again you, of course, will need some sort of certificate based SSH or VPN authentication.


Geolocalization of banned IP addresses

Finally, you could geolocalize the list of IP addresses by a script using any GeoIP service. But this is more for entertainment. It depends on /dev/random which bunch of script kiddies at a given time gets your hosts IP in their hands. Serious attackers anyway will spoof or hide their own IP address the one or other way.


Attacks for which this setup is sufficent

The setup in this HowTo is a solid measure against the vast majority of attacks against hosts. You can easily protect your machine against those attacks. However, in case you expect serious and heavy attacks by experienced blackhats focused on your host, FreeBSD offers a wide range of additional security measures strictly recommended then.

Personal tools