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 

This post documents how to add ModSecurity protection in Ubuntu's Apache. It has been tested on Ubuntu 11.04 but might work on earlier or latter issues with few modifications.

Installation of base packages

ModSecurity is a open source Web Application Firewall (WAF). It offers an array of request filtering and other security features to the Apache HTTP Server.

Fortunately, ModSecurity is already part of the Ubuntu package repositories. Therefore, installing the necessary stuff is rather straightforward:

apt-get install libapache2-mod-security mod-security-common
a2enmod mod-security
/etc/init.d/apache2 force-reload

Activation of the core rule set

The mod-security-common-package contains the core rule set (crs) which will not be configured automatically. In order to activate the crs, /etc/apache2/conf.d/mod-security.conf has to be created with the following content:

    Include /usr/share/doc/mod-security-common/examples/rules/*conf
    Include /usr/share/doc/mod-security-common/examples/rules/base_rules/*conf

Now the web server has to be restarted by the following line:

service apache2 restart

Testing the setup

In order to prove the setup is working, a test file called test.php with the following content can be used:

It's supposed to be placed in the root of your web server, so that it can be accessed by http://yourserver.tld/test.php. To run the actual test, the following address will do:

http://yourserver.tld/test.php?secret_file=/etc/passwd

If the content of /etc/passwd is displayed, ModSecurity is not working. A working installation will show a "403 Forbidden" error message.

This post documents how to enable the Suhosin protection system for PHP on Ubuntu installations. It has been tested on Ubuntu 11.04 but might work on earlier or latter issues with few modifications.

Apparently, Ubuntu repositories already contain the patches as an additional package. They are installed by the following line:

aptitude install php5-suhosin

After that, the patches are available but not yet configured. The central config file for the protection system is located at /etc/php5/conf.d/suhosin.ini. For a basic configuration uncomment the following lines:

[suhosin]
suhosin.executor.include.max_traversal = 4
suhosin.executor.disable_emodifier = on
suhosin.mail.protect = 2

; Filtering Options   
suhosin.cookie.max_vars = 2048
suhosin.get.max_array_index_length = 256
suhosin.post.max_array_index_length = 256
suhosin.post.max_totalname_length = 8192
suhosin.post.max_vars = 2048
suhosin.request.max_totalname_length = 8192
suhosin.request.max_varname_length = 256

Defining the latter options keeps phpMyAdmin working. After editing the file, the changes are activated by restarting the Apache daemon:

service apache2 restart

Now you may play around with the other config options in order to harden your webserver even more.

There are some situations in which it becomes useful to store important and crucial data in non-trustworthy environments. One example can be an off-site backup at an external hoster where full control over the infrastructure can not be maintained. Then, encrypting your files comes in handy so that in an emergency the data can be restored and only the according key has to stay save.

Key creation

A new public/private key pair is generated by running

gpg --gen-key

Just follow the prompts. Depending on the use case and level of later automation it can be useful to skip the definition of a passphrase. Keep the key ID in mind for the next step (you can display it again with gpg --list-keys). The keys are now stored in the user's home directory in ~/.gnupg/secring.gpg and ~/.gnupg/pubring.gpg. Remember to keep these files save.

Encryption of data

Now, tar is used to archive directories and files and pipe the resulting package into gpg:

tar -c {dirs_and_files_to_backup} | gpg -r {gpg_key_id} -e -o backup.tar.gpg

The resulting backup.tar.gpg can savely be stored at some non-confidential place. If your data can be compressed, it may be useful to replace tar -c by tar -cz in order to compress the data during archiving.

Decryption of data

To retrieve your data from the encrypted archives, the previous process is basically reversed:

gpg -d backup.tar.gpg | tar xf -

If you compressed your data in the encryption process you need to replace tar xf by tar xzf.

In order to have automatic and unattended security updates in Ubuntu, one needs to install the according package:

sudo aptitude install unattended-upgrades

Due to a missing file in the Ubuntu 10.10 package, the file /etc/apt/apt.conf.d/10periodic needs to be created with the following content:

APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "5";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::RandomSleep "1800";

Also, change the first few lines of /etc/apt/apt.conf.d/50unattended-upgrades as follows so that only security updates are considered:

// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
//      "${distro_id} stable";
        "${distro_id} ${distro_codename}-security";
        "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed-updates";
};

It is vital to redo these setting after a global upgrade to a new distro release.

If configured correctly the following command should produce this output:

$ apt-config shell UnattendedUpgradeInterval APT::Periodic::Unattended-Upgrade 
UnattendedUpgradeInterval='1'

• Install fail2ban:

  aptitude install fail2ban

• Create local configuration:

  cd /etc/fail2ban && cp jail.conf jail.local

• Edit /etc/fail2ban/jail.local and enable ssh-ddos by changing the according enable line to true

• Restart fail2ban daemon:

  service fail2ban restart

• Since Ubuntu version 10.04 rsyslogd is used; one of its default setting is to reduce the log output by compressing recurrent messages, which breaks the fail2ban-mechanism. Therefore, changing the following line in /etc/rsyslog.conf is vital:

  sed -i ‘s/RepeatedMsgReduction\ on/RepeatedMsgReduction\ off/’ /etc/rsyslog.conf

• Restart fail2ban and rsyslog daemon:

  service fail2ban restart && service rsyslog restart 

Handling several servers in different concurrent ssh sessions can lead to confusion. This is explicitly dangerous when it comes to unintended reboots. Here, molly-guard jumps into place by adding a confirmation dialog to each reboot command that is executed from a remote shell.

You can install molly-guard in Ubuntu with the following command:

sudo aptitude install molly-guard