Automatically prevent SSH DOS attacks on Linux using denyhosts

There's a really nice python based package named "denyhosts" which scans for repeated authentication failure from certain IP addresses and denies SSH access from those IP address into your machine.
This is really good if you have SSH port open on your live servers. I tried this on a Debian server that I have.

Although its very easy to implement it, I'm going to blog the steps.

1. Install the software

apt-get install denyhosts

2. Edit the /etc/denyhosts.conf

In case of my debian system, the authentication failures were getting logged in /var/log/auth/auth.info, hence I changed the following line from its default.

SECURE_LOG = /var/log/auth/auth.info

3. Restart the denyhosts service.

/etc/init.d/denyhosts restart



Now test if this really works

1. On a separate Linux system (attacker), create a script named brute.sh (ensure you have package `expect` and its dependencies installed: apt-get install expect) with following contents

#!/usr/bin/expect -f
set timeout -1
spawn ssh -l user1 10.1.0.200
set pass xyzRANDOM
expect {
password: {send "$pass\r" ; exp_continue}
eof exit
}

Here, 10.1.0.200 is the IP address of the system under attack (target). The target system may have a user "user1" but not the same password "xyzRANDOM".


2. Now from shell run the brute.sh in infinite loop like this

while true ; do /root/brute.sh ; done

Keep the script running for sometime and parallely monitor, /etc/hosts.deny on the target Linux box.

3. Once the loop above starts showing the following line "ssh_exchange_identification: Connection closed by remote host" , it means denyhosts software has detected brute force attach from attacker IP.
The /etc/hosts.deny file will contain the IP address of the attacker machine. In my case it appeared like this

sshd: 10.1.254.200


Note:
1. The first time denyhosts service ran, it took longer. I think it parsed through the auth.info file for already logged authentication failues and simply put those IP addresses in the /etc/hosts.deny file.
2. The brute.sh is a simple script meant to check if the denyhosts is really working. In real world, brute force attack may use different sets of username and passwords. However, since denyhosts works on the principle of IP address, it would detect the failures and deny those IP addresses.

Pretty neat!

Why can't you mount /etc as a separate partition in Linux

When you start installation of Linux (say RHEL), during partitioning try to create a separate partition for /etc - the installer wont let you do that. Linux doesn't like some important partitions like /etc, /sbin to be mounted on a different partition - Question is why?

This can be answered in two steps:

1) /boot/grub/menu.lst has "kernel" line with parameter like "root=/dev/sda2"

During the boot up process the kernel needs to be told the device of the / partition. In the above example its /dev/sda2. There's no way to specify separately the device like /dev/sda1 or /dev/sda3 for /etc.

2) /sbin/init needs a file named /etc/inittab.

Once kernel is loaded, it executes the /sbin/init script. Now the man page for this script says "Its primary role is to create processes from a script stored in the file /etc/inittab".
Uptil the point of executing /sbin/init, the kernel knows device only of one partition i.e. "/" . So, hypothetically speaking, if there were no /etc (folder etc inside /), then init would not know where the inittab file is. As a result, the booting will fail.

In other words, if there was a way to tell the kernel or /sbin/init the device where /etc files are present, then we could have created a separate partition for /etc.


Note: When I mention that you can't mount /etc as a separate partition, I'm assuming that you're not interested in being anal about it. We all know programming/scripting language can be used to modify almost anything in Linux and make it deviate from its "normal" behaviour. Here's a blog on how you can actually make /etc mount on different partition http://power-of-linux.blogspot.com/2010/03/booting-with-etc-in-separate-partition.html

Running VMware ESX 4 inside VMware Workstation 6.x.

There are lot of posts which describe how to install VMware ESX inside a VMware workstation, for eg: http://vmblog.com/archive/2007/11/01/more-on-installing-vmware-esx-server-inside-a-workstation-6-vm.aspx

This is easy and can be done very quickly. The next step of course is to create a VM. In my test bed I tried to install a RHEL4 OS inside VMware ESX using vCenter. I could create the VM very easily using the Create New Virtual Machine wizard however, the VM wouldn't power ON!. When you try to power the VM ON, the error that it would throw is

"you may not power on a virtual machine inside a virtual machine"

The reason why this happens is that when you installed VMware ESX inside a virtualized environment, you chose to install it as a "Red Hat Enterprise Linux 5" OS. As a result the VMware virtual machine configuration file stores parameter guestOS as follows:

guestOS = "RHEL5"


What you have to do is, edit the VMware virtual machine configuration file (.vmx file inside the folder where you've created the ESX VM) using notepad/wordpad and change it to:

guestOS = "vmkernel"

Now, power ON the OS and voila, it boots. Connect it to your installation CD/ISO and install the system!