Protecting an Asterisk server from brute force attacks with fail2ban

Recently, the server hosting my Asterisk setup started to get laggy and eventually it even died a few times on me. Checking the logs it turned out that unknown IPs tried to initialize calls through my contexts. The log file carried gigabytes of stuff like this:

NOTICE[1110] chan_sip.c: Call from '' (IP_ADDRESS_REMOVED:5070) to extension '000972597103443' \\rejected because extension not found in context 'maincontext'.

It was pretty obvious that some hijacked clients tried to initialize calls trough my system. Luckily, my setup does not accept calls from unknown parties. Yet, the massive amount of connections filled up my logs entirely and opened that many connections that the system collapsed at the end.

In order to secure other systems in my environments, I’m using fail2ban, e.g. for securing ssh logins. Therefore I will do the same for the sake of my Asterisk health.

  • So as always, you may want to trigger the tool installation:

    aptitude install fail2ban
    
  • Next create a local configuration:

    cd /etc/fail2ban && cp jail.conf jail.local
    
  • Now an individual filter description for the according Asterisk log entries has to be added in a new file called /etc/fail2ban/filter.d/asterisk.conf:

    [Definition]
    _daemon = asterisk
    failregex = NOTICE.* .*: Call from \'\' \(<HOST>:.*\) to extension \'.*\' rejected because extension not found in context \'incoming\'.*
            NOTICE.* .*: Registration from \'\".*\" \<sip:.*\>\' failed for \'<HOST>:.*\' - No matching peer found
    ignoreregex =
    
  • For these filters to take effect they have to be introduced to fail2ban in /etc/fail2ban/jail.local. Assuming there is a default Asterisk setup on your system, the follwing lines have to be added at the end of that file:

    [asterisk]
    enabled  = true
    filter   = asterisk
    action   = iptables-allports[name=asterisk, protocol=all]
    logpath  = /var/log/asterisk/messages
    maxretry = 1
    findtime = 600
    
  • Restart fail2ban to activate these changes:

    service fail2ban restart 
    

Setup squeezeslave on Intel Atom-based Synology NAS

 

Motivation

It’s a very decent feature in Syology’s DSM 4.1 having Logitech Media Server at the tip of your finger as an official 3rd party package. It offers the possibility to stream your own music library to any Logitech Squeezebox around your house. In addition, it is controllable by different IR-remotes as well as by very handy Android and iPhone apps.

Yet, Logitech decided to discontinue the whole Squeezebox lineup. That’s quite unfortunate, as those devices offered nice build quality together with an amazing centralized setup. But that’s not a complete showstopper.

As the whole Squeezebox project is open source, there is a sweet comandline tool called squeezeslave that acts as a software client. It can be run as a daemon on Windows, OS X, Linux, OpenWRT-based routers and several other devices – among them NAS devices. As my Synology NAS sits just next to my stereo, I had the idea of using it as the Squeezebox server as well as a softclient.

Hardware setup

To be able to output sound from the Synology NAS, an external USB sound card is needed. I’m using a Terratec Aureon Dual USB. It features a digital s/pdif output which I was looking for. Any other USB sound card should do just fine, too. When looking for different hardware, it can be helpful to check for OS X-support, as the necessary sound modules for OS X usually derive from Linux – and we need those modules for Linux.

Software prerequisites

In order to be able to stream actual sounds to the USB sound card, some modules and libraries are needed. To install those the Synology box needs bootstraping. This is explained in the earlier article Bootstraping an Intel Atom-based Synology NAS.

After the bootstrapping process is done, the necessary packages can be installed by using the following line:

ipkg install alsa-lib alsa-utils libusb usbutils

Those modules won’t load themselves unless you’re using Synology’s Audio Station package. If so, you need to execute the following lines once:

modules="soundcore.ko snd.ko snd-hwdep.ko snd-page-alloc.ko snd-seq-device.ko snd-timer.ko snd-pcm.ko snd-rawmidi.ko snd-usbmidi-lib.ko snd-usb-audio.ko snd-mixer-oss.ko snd-pcm-oss.ko"
for i in $modules;
do
insmod /lib/modules/$i
done;

The correct setup can be tested by running lsusb which should list your USB sound card. Another good indication for a proper setup is to run alsamixer. It’s supposed to show a commandline volume mixer.

Squeezeslave setup

Now that the general conditions are met, squeezeslave itself needs to be set up. The appropriate package can be found on Sourceforge. It is advised to use the lnx24-package of the most recent version (at the time of writing it is v1.2-311). The following lines help doing so. Beware to adjust the respective links and file names to the ones you downloaded.

cd /tmp ; wget "http://downloads.sourceforge.net/project/softsqueeze/squeezeslave/squeezeslave-1.2.311/squeezeslave-1.2-311-lnx24.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fsoftsqueeze%2Ffiles%2Fsqueezeslave%2Fsqueezeslave-1.2.311%2F&ts=1356280037&use_mirror=freefr"
cd /opt/bin; tar xzf /tmp/squeezeslave-1.2-311-lnx24.tar.gz

In order to start squeezeslave on boot, a new start script is necessary. It has to be placed in /opt/etc/init.d/. I named the script S70squeezeslave.

#!/bin/sh

# load sound modules for squeezeslave to work
modules="soundcore.ko snd.ko snd-hwdep.ko snd-page-alloc.ko snd-seq-device.ko snd-timer.ko snd-pcm.ko snd-rawmidi.ko snd-usbmidi-lib.ko snd-usb-audio.ko snd-mixer-oss.ko snd-pcm-oss.ko"
for i in $modules;
do
insmod /lib/modules/$i
done;

# wait a few seconds before starting the squeezeslave daemon
sleep 10
/opt/bin/squeezeslave -N -o0 -R -M/var/log/squeezeslave.log

To make the script executable, run the following:

chmod u+x /opt/etc/init.d/S70squeezeslave

Now, the setup should survive a reboot just fine. If everything worked out a new device called “squeezeslave” should appear in you Logitech Media Server. On your other squeeze devices you should be able to control the output now as if it were any other squeezer.

Bootstraping an Intel Atom-based Synology NAS

A SoHo-NAS is a handy device that can store loads of data and acts a central home server all at once. Just recently I had the chance to play around with one of those toys in order to learn about their capabilities.

To be able to install some useful and common Linux commandline tools on a Synology NAS, it needs to get bootstraped. This article assumes that a remote shell SSH access is already established. The rest of the process is fairly simple.

First, change to a directory for temporary data:

cd /volume1/@tmp

Now, the relevant data is supposed to be retrieved – in this case for an Intel Atom-based NAS:

wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

This file is a self extracting container that contains the relevant packages and at the same time creates the necessary file and directory structure. It gets executed like this:

ash syno-i686-bootstrap_1.2-7_i686.xsh &amp;&amp; rm syno-i686-bootstrap_1.2-7_i686.xsh

To get the most recent package list and also the latest packages themselves, the following command has to be run:

ipkg update &amp;&amp; ipkg upgrade

The install script modifies the current PATH variable so that ipkg can be found. However, to make the change permanent, the PATH variable in root‘s .profile needs to look like this:

PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin

Insight on MX-Entries

Recently, I gained some insight on the intended nature and its implications of the interaction of DNS with mail services.

It seamed that rather suddenly, my mail server was no longer able to receive mails from certain mail service providers like web.de. Those sending mail servers were only little verbose about what the source of the problem was:

domain has no mail exchangers

That was rather strange to me as I had some good experiences so far regarding the reliability of the DNS servers I was using. The original configuration I used was the following:

$ dig mx grosseosterhues.com
[...]
;; ANSWER SECTION:
grosseosterhues.com.    120     IN      MX      10 mx.grosseosterhues.com.

and

$ dig mx.grosseosterhues.com
[...]
;; ANSWER SECTION:
mx.grosseosterhues.com. 119     IN      CNAME   mail.grosseosterhues.com.
mail.grosseosterhues.com. 120   IN      A       46.4.78.23

So my MX record was a CNAME pointing to an A resource record. No problem with that — I thought. Doing some web research I learned from RFC 2181, Section 10.3 that there is a certain regulation prohibiting an MX resource record from being an alias (CNAME):

10.3. MX and NS records: The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

I don’t know if some providers just adjusted their MTA to use more restrictive policies on sending mails to foreign mail servers of if I just never realized a problem. Anyway: after changing the MX record over to an A resource record everything works flawless (again).

Enable ActiveSync push for Cyrus IMAP-Servers using z-push

 

Regular desktop mail clients support push notifications when communicating with IMAP servers. In order to achieve this, IMAP IDLE is being using. Unfortunately though, the current generations of smart phones such as Apple’s iPhone or Android-based phones do not support the IMAP IDLE feature but prefer ActiveSync to achieve Push services.

One way to make use of IMAP IDLE e.g. on Android is to use a different mail client like K9 Mail. Yet, that may not be an option to everyone due to software installation policies.

In case modifying the phone’s software setup is not an option, it is possible to insert an emulation layer from IMAP to ActiveSync on the mail server. This layer is provided by Z-Push, an open source implementation of the ActiveSync protocol, developed by the Zarafa team.

Z-Push is run by an Apache webserver using PHP and the php-imap module in order to provide the bridge between mobile device and IMAP server. This article documents how to set up a running ActiveSync emulation using Ubuntu Linux, Apache webserver, and Cyrus IMAP-daemon. A running Apache with working PHP and SSL configuration on an Ubuntu Linux is presumed.

Download and config of Z-Push

This article assumes all Z-Push files to be places in /var/www/z-push. First, the according sources are to be downloaded. They can be found either here http://z-push.sourceforge.net/ or here http://zarafa-deutschland.de/z-push-download/final/.

In the file /var/www/z-push/config.php the BACKEND_PROVIDER has to be changed:

define('BACKEND_PROVIDER', "BackendIMAP");

For syncing problems in previous versions of Z-Push, it helps to increase the value of MAX_EMBEDDED_SIZE as follows:

// define('MAX_EMBEDDED_SIZE', 1048576);
define('MAX_EMBEDDED_SIZE', 10485760);

By default Z-Push expects the directories /var/log/z-push and /var/lib/z-push to exist. In Ubuntu, this is not the case. Therefore, they have to be created and the according ownership needs to be set:

mkdir /var/log/z-push /var/lib-z-push
chown -R www-data:www-data /var/log/z-push /var/lib/z-push

Apache and PHP configuration

If not already present, the proper php5-imap module needs to be installed:

aptitude install php5-imap

Now in Apache config, the file /etc/apache2/sites-enabled/default-ssl gets some addition:

Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
<Directory /var/www/z-push>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Order allow,deny
     allow from all
     php_flag magic_quotes_gpc off
     php_flag register_globals off
     php_flag magic_quotes_runtime off
     php_flag short_open_tag on
</Directory>

If the Suhosin patch for PHP is used, the following setting has to be changed to off in /etc/php5/conf.d/suhosin.ini:

suhosin.executor.disable_emodifier = off

Mobile Device Setup

The mobile device should address the emulated ActiveSync server just by it’s hostname. It is not neccessary to add the Apache alias into the address.

On Android phones, the user might have to accept certain security policy warnings before the actual sync starts.

Debugging Information

Useful debugging information can be found in Apache’s logs in /var/log/apache2 and in Z-Push’s logs in /var/log/z-push. Cyrus IMAP logs its information into the mail system’s log in /var/log/mail.log.

Update: FlexGet Installation and Upgrade in Ubuntu

This is an update to my previous article on how to set up FlexGet in Ubuntu. In this post, FlexGet v.1.0r2733 will be used on Ubuntu 11.10.

The reason for this new post is that the install and update processes have changed from using easy_install to pip, an alternative Python package installer. Both installation as also upgrading can be done with this tool.

Still, there have to be certain packages around:

aptitude install python2.6 python-setuptools python-pip

Now, the installation can easily take place:

pip install flexget

In case of an upgrade, the according line would be:

pip install --upgrade flexget

The following step is optional. In case an interface to transmission-daemon is of use, the according FlexGet-plugin is installed like this:

pip install transmissionrpc

Configure German Spamassassin Update Channel in Ubuntu

Spamassassin already ships with the nice feature of running automatic updates to its core rules by using sa-update. Customisation of this update process is not well documented though. So it will be described in this article.

At http://wiki.apache.org/spamassassin/CustomRulesets quite some additional channels are listed. As an example the configuration of the German Language Ruleset will be outlined.

The Spamassassin Channel is documented on that website and says:

Available at: SpamAssassin Channel: 70_zmi_german.cf.zmi.sa-update.dostech.net

In your local Spamassassin’s setup the update rules reside at /var/lib/spamassassin/{SA_VERSION_NUMBER}. There, you may want to add the new channel definition by introducing the according gpg-key as follows:

wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY
sa-update --import GPG.KEY

Now, a manual channel update for that particular channel can be run:

sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

In order to have the cron-triggered nightly sa-update-run also update the new channel, a hook for sa-update has to be defined in /etc/spamassassin/sa-update-hooks.d/. There, create a file called german-rules-updates with the following content:

#!/bin/sh
sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

The German rules should now be updated each day and become active thereafter.

Squid config with NCSA Authentication in Ubuntu

This article describes a quick and easy way to implement a web proxy with most basic user authentication. The authentication mechanism uses an NCSA-style htpasswd file, well known also for other basic authentication purposes. The proxy server in use will be Squid proxy.

To install the necessary software, this line will do:

aptitude install squid

Now, a new file containing usernames and password hashes needs to be created:

htpasswd -c /etc/squid/passwd USERNAME
chmod 400 /etc/squid/passwd && chown proxy /etc/squid/passwd

The file /etc/squid/squid.conf has to be modified. The following lines have to be uncommented while the first of them needs adjustment as to the whereabouts of the passwd file. By default it points to usr/etc/passwd but we want it to be /etc/squid/passwd:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic casesensitive off

In the ACL section two lines have to be inserted. The ACL section can be found by searching for “# ACCESS CONTROLS“.

acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

In case you want Squid to not reveal your client’s real IP address in HTTP requests it forwards, the follow option has to be disabled:

forwarded_for off 

A restart of Squid’s daemon will activate the recent changes:

service squid restart 

Exim 4 and ClamAV Malware Scanning in Ubuntu

Although virus scanners are installed on virtually all regular client systems nowadays, it’s nice to have the mailserver pre-scanning mails for malware. This article describes the configuration of ClamAV in conjunction with Exim 4 in Ubuntu Linux.

Assuming a working Exim 4 environment, the fist step is to install the necessary ClamAV package:

aptitude install clamav-daemon

To tell Exim which anti-virus scanner to use, the file /etc/exim4/exim4.conf.template needs to be customized. The default config already brings the necessary lines. They just need to be adjusted and uncommented:

av_scanner = clamd:/var/run/clamav/clamd.ctl
[...]
deny
  malware = *
  message = This message was detected as possible malware ($malware_name).
warn
  message = X-Virus-Scanned: (${readsocket{/var/run/clamav/clamd.ctl}{VERSION}{2s}{}{AV Not running}})

In order for ClamAV to access the mail spool it has to become a member of Exim’s group:

usermod -a -G Debian-exim clamav && service clamav-daemon restart

Now, sending a testmail like the one from EICAR should give you the appropriate malware rejection.

Greylisting in Exim 4 with Greylistd on Ubuntu Linux

In this article the approach of greylisting as a protection against spam in Exim 4 is being described. The concepts of greylisting temporarily rejects mails at SMTP time. A regular MTA without spamming intent will try to send mail again after a certain period of time. The average trojan or worm on the other hand usually sends spam in waves. It will try to send its load only once and won’t try again later. This concept facilitates spam reduction to a huge extent.

Setting up greylisting in Ubuntu Linux using Exim 4 is a breeze. To work, it simply needs the following lines.

Firstly, the installation of the package greylistd:

aptitude install greylistd

To activate the new package in Exim’s configuration, the following command will do some magic:

greylistd-setup-exim4 add

The default configuration of greylistd is a bit too paranoid from my point of view. Therefore I adjust /etc/greylistd/config as follows (usually the last two existing entries in that file):

singlecheck = true
singleupdate = true

This has the effect that a domain that has already been verified won’t become greylisted again if a different user sends from that particular domain. Also, it enables for manual manipulation of the whitelist by just adding IPs of “good” MTAs.

The whitelist file that is supposed to be edited by admins resides at /etc/greylistd/whitelist-hosts. The predifined whitelist can be found at /var/lib/greylistd/whitelist-hosts.