File	Date	Author	Commit
etc_fail2ban	2011-03-12	Andrey Filippov	[c54a84] more text
LICENSE	2011-03-12	Andrey Filippov	[a774e0] Initial commit
README	2011-03-14	Andrey Filippov	[302360] more typos fixed
allowSites	2011-03-12	Andrey Filippov	[a774e0] Initial commit
blockSites	2011-03-12	Andrey Filippov	[b2f2d9] clean-up
firewall3	2011-03-14	Andrey Filippov	[553447] added logging banned sites

Read Me

These files are used to secure Asterisk-based phone server. They are used to setup a combination of the pure iptables
firewall that limits the SIP attack rate, and the fail2ban (www.fail2ban.org) that scans the log files (not just the
kernel messages) and blocks intruders by adding rules to the iptables. Fail2ban is slower to react (as it need to read
log files), but it can be configured to block different types of intruders, it can send email notifications when attack
happens.

Files:

  firewall3 - Script to setup iptables based firewall that limits control access to the server (ssh, http, https) to
              only the specified sites, limiting the rate of SIP connections (i.e. brute force extension passwords
              breaking). This script tries to make some guesses and has reasonable configuration values, but you may still
              need to edit it. It needs access to the following two files, paths should be specified in the script body.
              This script is based on the original one by Gordon Henderson -  http://unicorn.drogon.net/firewall2

  allowSites- IP list of the sites that are granted full access to the server (on all ports), needed for the firewall3.
  blockSites- IP list of the sites that are denied any access to the server, needed for the firewall3.

  etc_fail2ban - directory with the files that should be copied to the fail2ban configuration directory (normally it
              is /etc/fail2ban. You may find installation notes in
              http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk
  etc_fail2ban/filter.d/asterisk.conf - fail2ban filter for asterisk loig file (taken from
              http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk .
  etc_fail2ban/filter.d/firewall3.conf - fail2ban filter to detect SIP attacks reported by iptables.
              
   - main fail2ban configuration file. It specifies what log files to process, which of the filters
              to use, where to send email notifications, for how long should the intruder be banned, some other parameters.


 Installing firewall3:

 You may copy the firewall3 script to /etc/init.d , copy the templates allowSites and blockSites to /etc/network (at least
these paths are specifiec in teh firewall3 body. If you chnage the paths, you'll need to change them in firewall3 accordingly.
You may leave /etc/network/blockSites in default (empty) state, but you will definitely need to put some trusted IP
addresses in /etc/network/allowSites (unless you only plan to administer the server from the local console). You may allow
additional services in the body of the firewall3 (by uncommenting some lines or adding new ones). In the default state you
will be able to ssh to the server, use Freepbx or Trixbox web control panel, Flash Operator Panel only from the specified
IP addresses. You do not need to put too many addresses there - if you'll find yourself far from all of them and will need
emergency access to the server, you should be able to ssh to one of the other machines (listed in /etc/network/allowSites)
and then ssh from them to the server, edit /etc/network/allowSites to include your current host and restart the firewall
(with /etc/init.d/firewall3 start).

To be able to use fail2ban you need to make sure that the logged lines from the firewall are stored. They may already go
to /var/log/messages, but here we add additional file where we record kernel messages (including those from the firewall)
of level "warning" and higher to /var/log/iptables.log. For that you need:
1) - edit /etc/syslog.conf file and add the following line there

kern.warning                                            /var/log/iptables.log

After that - restart syslog with

/etc/init.d/syslog restart


To test the firewall (IMPORTANT: MAKE SURE THAT YOUR IP IS "WHITELISTED" IN /etc/network/allowSites IF YOU ARE WORKING
 REMOTELY !!!. It may help to use cron to automatically disable firewall after some time in such case), run
/etc/init.d/firefall3 start

It will list the white-listed and black-listed IPs, as well as the interface it used (eth0, eth1,...). It determines the
interface by reading the "route" output, You may overwrite that quess my specifying the interface in the firewall3 body.
There is another option that the script tries to determine automatically that may be needed to set in the script - differences
in the iptable syntax for different versions. Older version uses "--hashlimit" parameters, while newer - "--hashlimit-upto"
instead. So the script just runs "man iptables" on the server and looks for these parameters. If manual entries are missing
from the server, you may uncomment appropriate line in the firewall3 and watch that there are no errors reported when
script executes iptable commands.

When the firewall is started, you may run iptables with the predefined set of parameters to see the status:

/etc/init.d/firewall3 status

It will show current iptables rules, number of packets (and bytes) detected by those rules. you may also run 
cat /var/log/iptables.log
to see the dropped packet info, make sure data there is what you expect. You may try to ssh to the server from some other
IP and make sure the /var/log/iptables.log has "DROPPED: ..." lines with the IP of the "intruder". You may also test the
simulated SIP attack using sipvicious, as described in
http://sysadminman.net/blog/2009/hacking-and-securing-your-asterisk-server-592

Turning firewall off:

/etc/init.d/firewall3 stop

Note: Currently firefall3 is not nice to fail2ban and deletes all of it iptable rules. So if you (re)start firewall3 after
fail2ban, you need to restart fail2ban also.

will turn the firewall off, enabling full access from anywhere. If you had fail2ban running, it iptables rules will also
be deleted, so fail2ban should be started after firewall3.


Installing fail2ban: For the fail2ban itself, you'll find the information on www.fail2ban.org,
http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk has asterisk-specific additions.  It seems
              though that current version of fail2ban reads native asterisk timestamps, you just need to enable asterisk
              to log warnings to /var/log/asterisk/messages (may be disabled by default), so fail2ban will not have to
              read the full asterisk log (/var/log/asterisk/full). You may copy etc_fail2ban/filter.d/asterisk.conf and
              etc_fail2ban/filter.d/firewall3.conf included here to /etc/fail2ban/filter.d directory after fail2ban
              itself is installed.
              You may also copy the included etc_fail2ban/jail.conf to /etc/fail2ban , but this file will need editing,
              at the minimum you'll have to put there your email for notifications (or disable them). You may also need
              to enable/disable other service log processing, change the paths to the log files.

Starting fail2ban:
/etc/init.d/fail2ban start
will start fail2ban. If you now run "/etc/init.d/firewall3 status" it will show additional rules related to fail2ban.

Making firewall3 and fail2ban start at boot time.

After you tested both services manually, you need to make them start automatically at boot time. And firewall3 should start]
first, before fail2ban. It may differ on different systems, but on the standard Trixbox installation this level is 3, so you
may read /etc/rc3.d:
ls -all /etc/rc3.d/
and find the unused Sxx number to use. I had S39 and S40 unused, in that case

cd /etc/rc3.d
ln -s ../init.d/firewall3 S39firewall3
ln -s ../init.d/fail2ban  S40fail2ban

did the job, and "ls -all /etc/rc3.d/" should now include these 2 new services. You may now reboot the system and make sure the
firewall is up and fail2ban is running. You should also receive some emails from it if you set jail.local correctly.


Other protection measures:

There are several other steps needed to be done to harden the phone server, one of the good pages is
http://blogs.digium.com/2009/03/28/sip-security/. If you are using FreePBX web control panel (or derivatives, like in
Trixbox), some important settings are not available inside the web interface, you need to edit the configuration files. And
as there is hierarchy of the overwrites of the setting in different files, you need to put your setting so they will stay
in place after you may make sojme changes through the interface.

One of such files is /etc/asterisk/sip_custom_post.conf - this you can use to specify/overwrite settings automatically generated
by there web control panel. Here you can put per-extension rules, that will limit the range of IP addresses from which the
particular extension can register ("deny" and "permit" lines below, 0.0.0.0/0.0.0.0 means "any"). In the example below extension
1236 is allowed to register from a single IP address 192.168.0.12. Next line is "cal-limit" - by default in the auto-generated
file /etc/asterisk/sip-additional.conf this limit was set to "50", so somebody who cracked your extension password could
theoretically run up to 50 calls simultaneously, and if each was directed to a satellite phone destination, it could cost you
hundreds of dollars every minute.
Each extension settings start with the line [<EXTENSION>] followed by (+) - that means that the settings after will apply to
<EXTENSION> in addition to (possibly overwriting) those that are specified before (i.e. in /etc/asterisk/sip-additional.conf ).
If needed you may add "[<EXTENSION>] (-)" section - that will delete the following parameter settings.

/etc/asterisk/sip_custom_post.conf :
...
[1236](+)
deny=0.0.0.0/0.0.0.0
permit=192.168.0.12/255.255.255.255
call-limit=1
...
Another setting that you would like to overwrite is "alwaysauthreject=yes" (it is "no" by default). That means that the server
would ask for a password even for the non-existent extension (of course, it will reply as "wrong password" for any password),
that makes scanning for the extensions significantly more difficult - see link below.

This is a global setting that applies to all extensions. The right place for it is in /etc/asterisk/sip_custom.conf file - just
add (in my case the file was empty) the following line there:

alwaysauthreject=yes

After changes in the configuration files you need to restart the Asterisk server to apply them. You may do it differently,
including pressing "Submit" button in the web interface, on the page were you edit some extension, and then pressing 2 more
buttons that will appear. More clicks than running "amportal restart", but you do not need to remember the command name

Testing that you are now protected:

I would strongly recommend to test your server after you hardened it, following the instructions on this site:
http://sysadminman.net/blog/2009/hacking-and-securing-your-asterisk-server-592
You may want to selectively undo some of the protection steps, create insecure extension and subject your server to a simulated sip
attack. If "alwaysauthreject=yes" is applied, scanning for extensions with svwar.py will not give much, so you can try breaking
into test "insecure" extension (with the password, but without IP limitation) using svcrack.py. This is when the firewall3 should
kick in (make sure that you run sipvicious from the IP not listed in /etc/network/allowSites). You would be able to watch the
attack in the last lines of the output of the
/etc/init.d/firewall3 status
(or service firewall3 status )
First column will show number of packets, second - bytes. The last line with DROP (it belongs to the chain "sipAttack") show total
number of packets dropped as identified to be malicious, the previous line with LOG - reduced number of lines that went to the
file /var/log/iptables.log (you may change the LOG rate in the body of the firewall3)

You may also view the log file - it will have the line(s) including prefix "SIP: ", and these lines will include the IP of the
"offender" as well as the timestamp of the "attack". You may test it both with and without fail2ban running. Without it the attack
will be significantly slown down. In my case it was hundreds times slower (than without the firewall), so it took svcrack more than
10 seconds to just scan only 10 different passwords, less that 1 per second.

If the fail2ban is enabled, it would notice the "SIP: " patterns in the log, ban the offender IP for a long time (setting of
"bantime=259200" in /etc/fail2ban/jail.custom will ban it for 3 days). And if the email server is configured properly (FreePBX
uses it to email voice mails as attachments, so if you receive them you have a working mailserver) and the /etc/fail2ban/jail.custom
has the correct destination addresses specified (in the included sample there are "dest=PUT-YOUR-EMAIL-HERE" templates), you
should receive email notifications about the detected attack (and action).

You may verify that the server does not allow ssh, http and https access from the unauthorized IP, watching response both on the
"offender" side, and on the server (over the ssh from the allowed site) with "service firewall3 status" and
"cat /etc/var/iptables.log"

Hope these steps may help you to save on some unexpected VoIP phone bills.

Andrey Fililppov