Syntax Error - Press Play on Tape -


UFW with fail2ban

At the end of Part I we quickly setup a basic iptables config just to get the firewall up and doing its job.  The problem with iptables, isn’t actually a problem with iptables itself, but rather the administrator running it.  Iptables is a great firewall and like any great firewall there is a lot you can configure it to do.  The more configuration options open to the user, the more complicated a piece of software can get.  What I’ve witnessed is a well intentioned user will configure and run iptables on Day 1 of their server, just as we did in Part 1, but as time moves on and they need to run more applications or find themselves with something not working just right that seems to behave fine once iptables is stopped, then iptables either gets turned off or mis-configured with larger holes than what is needed.  Unless you are a linux administrator of some sort you probably are going to learn just enough of iptables to get it running on that initial setup.  After that you don’t really touch a firewall on a day to day basis so by the time you have this new application installed that isn’t playing nice with your current iptables you don’t want to take the steep learning curve plunge to figure out the correct  configuration you would need.  Therein would lie your chink in the security chain.

Starting with UFW for the first time check the UFW Ubuntu Wiki.  The introduction on this page explains perfectly why one would want to use UFW over iptables.

The Linux kernel in Ubuntu provides a packet filtering system called netfilter, and the traditional interface for manipulating netfilter are the iptables suite of commands. iptables provide a complete firewall solution that is both highly configurable and highly flexible.

Becoming proficient in iptables takes time, and getting started with netfilter firewalling using only iptables can be a daunting task. As a result, many frontends for iptables have been created over the years, each trying to achieve a different result and targeting a different audience.

The Uncomplicated Firewall (ufw) is a frontend for iptables and is particularly well-suited for host-based firewalls. ufw provides a framework for managing netfilter, as well as a command-line interface for manipulating the firewall. ufw aims to provide an easy to use interface for people unfamiliar with firewall concepts, while at the same time simplifies complicated iptables commands to help an adminstrator who knows what he or she is doing.

You may also find useful the Ubuntu Community page on UFW.  There are helpful links at the bottom of that page to continue reading.  Some quick google searches will get you moved to UFW quite easily.  Remember you are using the same backend as iptables just using a less complicated front-end to get the rules going.  So if you flush your current iptables and put in some basic ufw rules for your ssh, apache, and in my case NTP your ufw status output could look like this:

activeTo      Action   From
--------      ------   ----
OpenSSH       LIMIT    Anywhere
Apache Full   ALLOW    Anywhere
123           ALLOW    Anywhere

Now recall we changed our OpenSSH port in Part I, so to keep UFW simple I’ve edited the openssh-server file in /etc/ufw/applications.d to reflect our custom port. For any custom ports you find yourself opening or blocking consider creating an application profile for it, it’ll be easier to read your rules and if you don’t touch them for months, easier to remember when you have to re-visit them. You can easily see your apps and their configuration with ufw app list and ufw app info OpenSSH. Once you have your basic UFW configuration in place you should install fail2ban: aptitude install fail2ban.

Fail2ban is a very simple yet very useful application that simply looks at the log files you tell it about, parses them for certain errors or failures and then inserts a firewall rule to block the IP that caused that error or failure.  Trust me when I tell you that you want this.  Every server I’ve ever put on the internet gets scanned by scripts looking for open ports, trying ssh or ftp logins, attempting urls for various mysql, php, remote access URL’s, etcetera etcetera etcetera….  Here is a small example of ports that were scanned on my server:

Service: ms-sql-s (tcp/1433) ([UFW BLOCK])
Service: ssh (tcp/22) ([UFW BLOCK])
Service: sip (udp/5060) ([UFW BLOCK])
Service: 3389 (tcp/3389) ([UFW BLOCK])
Service: 27977 (tcp/27977) ([UFW BLOCK])
Service: radmin-port (tcp/4899) ([UFW BLOCK])
Service: 5900 (tcp/5900) ([UFW BLOCK])
Service: http-alt (tcp/8080) ([UFW BLOCK])
Service: loc-srv (tcp/135) ([UFW BLOCK])
Service: mysql (tcp/3306) ([UFW BLOCK])
Service: ms-sql-m (udp/1434) ([UFW BLOCK])
Service: 49153 (udp/49153) ([UFW BLOCK])
Service: 1022 (tcp/1022) ([UFW BLOCK])
Service: socks (tcp/1080) ([UFW BLOCK])

On the web server side various URL’s for web administration are always attempted like: /phpMyAdmin, /myadmin, /mysql, etcetera. Without Fail2ban in place these scripts can run until they’ve exhausted every login attempt they want, or every URL in their list. WITH Fail2ban we can give them 3-5 attempts and then realize they are a script kiddie and ban their IP from the server for X amount of time.

Out of the box Fail2ban works with iptables rules, however these don’t play nice with our simpler UFW commands so we need to make a couple edits to have Fail2ban block the IP’s with UFW.

First lets go into /etc/fail2ban/jail.conf and change a few default ban actions for ssh and apache to use ufw actions we will create:

enabled = true
banaction = ufw-ssh
port = 2992
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

enabled = true
port = http,https
banaction = ufw-apache
filter = apache-auth
logpath = /var/log/apache*/error*.log
maxretry = 4

enabled = true
port = http,https
banaction = ufw-apache
filter = apache-nohome
logpath = /var/log/apache*/error*.log
maxretry = 3

enabled = true
port = http,https
banaction = ufw-apache
filter = apache-noscript
logpath = /var/log/apache*/error*.log
maxretry = 6

enabled = true
port = http,https
banaction = ufw-apache
filter = apache-overflows
logpath = /var/log/apache*/error*.log
maxretry = 2

In this file we are enabling the sections we want fail2ban to monitor and take action on. You’ll want to make sure your logpath points to your apache error logs and take note of the filter names as each of those corresponds to a file within the filter.d directory. All the filters are simply a regular expression to pattern match some error condition in the logfile, once matched fail2ban will execute the banaction. So if you look at the apache-auth filter, it will match for any user authentication failures to your websites. The only filter I’ve modified is the apache-nohome I’ve edited to match for any file not found error, not just checking for home directory attacks as the default.
The original regex was:
failregex = [[]client []] File does not exist: .*/~.*
and my modified version for any file not found errors is:
failregex = [[]client []] File does not exist: *
BE CAREFUL if you chose to also make this change. There are many things that will cause file not found errors that may not be attacks at all. Search bots looking for robots.txt, normal users can trigger on favicon.ico if you don’t have, etc. So if you make that change check your logs frequently and fix any valid file not found errors. The reason I turned this on is the constant attempts at bogus URL’s as I mentioned above where the scripts look for web GUI admin pages.

Now we simply need to create the valid banaction files we specified in our jail.conf. First is /etc/fail2ban/action.d/ufw-ssh.conf:

actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from <ip> to any app OpenSSH
actionunban = ufw delete deny from <ip> to any app OpenSSH

and /etc/fail2ban/action.d/ufw-apache.conf:

actionstart =
actionstop =
actioncheck =
actionban = ufw insert 2 deny from <ip> to any app "Apache Full"
actionunban = ufw delete deny from <ip> to any app "Apache Full"

As you may see the ufw command here is quite simple. The actionban says to deny the offending IP for the specified application. The only gotcha here is we have to specify the line the rule is being inserted into as the order matters. Our original rules allow these apps so we must ensure that any denies to these apps come BEFORE the allow rule. As rules are processed in order if we have the allow first the offender will continue to hit our server as it will never hit the deny rule. So we make sure the denies get inserted before the allow lines and all is well. The great thing about UFW rules is that you can almost read them and understand what they are doing, as opposed to the standard iptables banaction which could look like this:

actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP

As you can see UFW provides for much more readability without that learning curve hit you’d have to go through to get a good grip on the iptables rules.

If you have logwatch configured as in Part I then you’ll see the bans that took place in the logwatch email for the day prior. For example the fail2ban section in one of my logwatch emails had this:

--------------------- fail2ban-messages Begin ------------------------
Banned services with Fail2Ban:                 Bans:Unbans
apache-filenotfound:                            [ 3:3 ] (   1:1 (  1:1                                    1:1
---------------------- fail2ban-messages End -------------------------

As I mentioned earlier, for the first week with this configuration you should check your apache error log and make sure those file not found errors were scripts looking for /phpmyadmin or some other page that truly doesn’t exist and not a normal user getting file not found errors because of favicon.ico or something else.

That’s it! ufw status will show you any of the rules in effect on your system. After these first two parts are executed you’ll have a server configured securely with nothing unnecessary open to the internet, and those ports that are open now are blocking some bad guys from messing with them too much. For Quick Secure Setup Part III, the last in the series, we’ll tighten everything up even more and end up with server security that is second to none.

Filed under: linux, Security 1 Comment

sshfs and autofs – The perfect marriage

Creddz go to Thomas Jansson at

What is sshfs and why is it so great?

sshfs is a file system in userspace (FUSE) and can be used to mount a remote ssh account locally in a folder. This is absolutely great – If I need to work on files from my server I can use the simple command:
sithson@dagobah:~$sshfs sithson@dagobah: sshfs/

which mounts the remote file system on over a encrypted connection to the folder sshfs/ – none of the programs is aware the files are remote and working on a file in the folder sshfs/ is the same as for local files – at least if the connection is fast enough.

What is autofs and what why is this even better than plain sshfs?

The great thing thing about autofs is that the line above is no longer needed. The mounting of the remote file system is done in the moment I try to access the folder by the autofs daemon. sshfs and autofs together makes a encrypted remote file system available to the user and the system in a totally transparent way. Once the setup is complete the user will never need to know that the files are actually on a remote server.

Installation of FUSE

The installation is pretty straight forward. First the packages needs to be loaded.
root@dagobah:~# apt-get install sshfs fuseutils autofs

Second the module needs to be loaded into the kernel:
root@dagobah:~# modprobe fuse

and since this module should be loaded on every startup of the computer the line:
should be added to the file /etc/modules. The last part of setting up FUSE is to add the users which should be able to use FUSE to the FUSE usergroup.
root@dagobah:~# usermod -a -G fuse sithson

This will work when logged out and in again.

Configuring ssh and autofs

First I need to create a set of ssh-keys so I don’t have to write my password every time the connection is established.
root@dagobah:~# ssh-keygen -t dsa

Next the public key needs to be transported to the remote server ( with the login "sithson".
root@dagobah:~#ssh-copy-id -i .ssh/ sithson@dagobah

Now I need to create a folder where the remote folder should be mounted.
root@dagobah:~# mkdir /mnt/sshfs

The next thing is to add a line to the file /etc/auto.master but before this is done. I need to know the userid, so I run:
sithson@dagobah:~$cat /etc/passwd | grep sithson

So my userid is 1000. The file in /etc/auto.master now needs the line:
/mnt/sshfs /etc/auto.sshfs uid=1000,gid=1000,--timeout=30,--ghost

And finally we need to create the file /etc/auto.sshfs and add lines similar to this:
bar -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#sithson@dagobah\:

This will mount the remote system in the folder /mnt/sshfs/bar/ every time I access that folder. If I’m not using the folder for 30 seconds it will be unmounted. Absolutely amazing and very very useful.


If you have several servers you just need to add line for each in the file /etc/auto.sshfs. Finally it should also be stated that the are some security considerations to take into account. If this done on a laptop and the laptop is stolen the burglar could gain access to the remote systems.

References - In danish on sshfs, encfs and FUSE.

Tagged as: , , No Comments

Asus Xonar DSX: Patching linux kernel v3.x driver to recognize sound card

Supposing you have the linux kernel source in /usr/src/linux.

1. Make changes to the following two files:

  • sound/pci/oxygen/virtuoso.c
  • sound/pci/oxygen/xonar_wm87x6.c

2. Compile kernel and modules

3. Install new kernel and modules and reboot using the recently installed kernel

4. Ét voila! =)


static DEFINE_PCI_DEVICE_TABLE(xonar_ids) = {
Add this line if it does not exist: { OXYGEN_PCI_SUBID(0x1043, 0x8522) },


static const struct oxygen_model model_xonar_hdav_slim
Locate and delete the line with the typo .adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST,
There should already be a line with .dac_i2s_format = OXYGEN_I2S_FORMAT_LJUST,



int __devinit get_xonar_wm87x6_model(struct oxygen *chip,
Add a new case right before the default case.
case 0x8522:
chip->model = model_xonar_dsx;


Here is the full git diff file:

diff --git a/mirror/sound/pci/oxygen/virtuoso.c b/mirror/sound/pci/oxygen/virtuoso.c
index 3d71423..8104eab 100644
--- a/mirror/sound/pci/oxygen/virtuoso.c
+++ b/mirror/sound/pci/oxygen/virtuoso.c
@@ -52,6 +52,7 @@ static DEFINE_PCI_DEVICE_TABLE(xonar_ids) = {
{ OXYGEN_PCI_SUBID(0x1043, 0x835d) },
{ OXYGEN_PCI_SUBID(0x1043, 0x835e) },
{ OXYGEN_PCI_SUBID(0x1043, 0x838e) },
+ { OXYGEN_PCI_SUBID(0x1043, 0x8522) },
{ }
diff --git a/mirror/sound/pci/oxygen/xonar_wm87x6.c b/mirror/sound/pci/oxygen/xonar_wm87x6.c
index 63cff90..af91016 100644
--- a/mirror/sound/pci/oxygen/xonar_wm87x6.c
+++ b/mirror/sound/pci/oxygen/xonar_wm87x6.c
@@ -1321,6 +1321,40 @@ static const struct oxygen_model model_xonar_hdav_slim = {
.adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST,

int __devinit get_xonar_wm87x6_model(struct oxygen *chip,
const struct pci_device_id *id)
@@ -1331,6 +1365,9 @@ int __devinit get_xonar_wm87x6_model(struct oxygen *chip,
case 0x835e:
chip->model = model_xonar_hdav_slim;
+ case 0x8522:
+ chip->model = model_xonar_dsx;
+ break;
return -EINVAL;


Debian 6.0: Encrypt /home post installation

Debian installer provides an easy way of creating encrypted disk volumes during installation, including encrypted root partition. However, if you skip this step and decide to encrypt a disk partition later, you need to perform manual setup.

Fortunately, it's not too difficult. The following steps cover creating an encrypted /home, so you need to have a separate disk partition for it. Encrypting root filesystem is more sophisticated and it's not covered by this tutorial.

  1. Install cryptsetup:
    apt-get install cryptsetup
  2. Backup current /home contents and unmount the partition
  3. Create encrypted LUKS partition:
    cryptsetup -y --cipher aes-cbc-essiv:sha256 --key-size 256 /dev/sdb2
    (replace sdb2 with your partion name)
  4. Open LUKS partition and map it to 'crhome' (this name can be arbitrary):
    cryptsetup luksOpen /dev/sda2 encHome
  5. Format encrypted partition, e.g.:
    mkfs.ext4 /dev/mapper/encHome
  6. Mount it:
    mount /dev/mapper/encHome /home
  7. Restore /home contents from the backup
  8. Recreate initrd:
    update-initramfs -u
  9. Create /etc/crypttab entry for encrypted volume:
    encHome /dev/sda2 none luks
  10. Change /etc/fstab entry for /home, .e.g:
    /dev/mapper/encHome /home ext4 defaults 0 2
  11. Reboot!

During system startup you will be prompted for password to access LUKS volume. If you have Plymouth installed, you'll see a nice graphical password prompt.

For more documentation, including Debian-specific docs, got to /usr/share/doc/cryptsetup and cryptsetup/crypttab man pages.