track seen IP addresses and be able to match against them using some criteria.
This enables admins to identify and block traffic brute force attacks. In the following config will only allow 4 connections to port 22 within a 60 second time frame from a given IP address. Subsequent connections will be logged and dropped. The disadvantage of this approach is that iptables can not distinguish between successful and unsuccessful connections. This means that you potentially lock yourself out of your server! To help overcome this problem a whitelist of admin IP addresses is added.
# Create new chain
iptables -N SSH_CHAIN
# Accept all SSH connections from admin addresses
iptables -A INPUT -p tcp --dport 22 -s $WHITELIST -j ACCEPT
# Route inbound new connections via our SSH chain
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHAIN
# Create a dynamic list of IP addresses named SSH to match against
iptables -A SSH_CHAIN -m recent --set --name SSH
# Log any violations
iptables -A SSH_CHAIN -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-level info --log-prefix "SSH CHAIN blocked: "
# Drop the packet
iptables -A SSH_CHAIN -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
Since the Debian security advisory was published there has been plentyofdiscussion about who is to blame and how such a bug has gone unnoticed since September 2006. While they are important discussions that need to be had, I’ll focus on how to protect your Debian based PCs, laptops, servers, etc. First thing’s first, upgrade OpenSSH and the relevant packages.
$ sudo apt-get update
$ sudo apt-get upgrade
Where you have OpenSSH installed, the host keys must be regenerated.
$ sudo rm /etc/ssh/ssh_host_*
$ sudo dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.
SSHing onto the server will display a warning because the client’s host key in the known_hosts file does match what the server presents. Just delete the referenced line from known_hosts.
$ ssh server
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
It’s common practice to use self signed certs in development environments. Here’s how to do it for Lighttpd.
First we generate a certificate using openssl,
$ openssl req -new -x509 -keyout ~/cert.pem -out ~/cert.pem -days 365 -nodes
Generating a 1024 bit RSA private key
writing new private key to '/root/cert.pem'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) :.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SW Designs
Organizational Unit Name (eg, section) :SW Designs
Common Name (eg, YOUR name) :*.sw-designs.co.uk
Email Address :
Entering your password when SSHing onto remote machines gets very boring, very quickly. The good news that this is can be avoided by using public key authentication and without compromising security. In fact, this approach can prevent brute force attacks if password based authentication is turned off as well.
The first step is to generate a public/private key pair on the client machine. Due to the security problems with SSH-1, we’ll be creating SSH-2 keys.
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/simon/.ssh/id_dsa):
Hit enter to accept the default file. Next we’re prompted for a passphrase, I suggest you don’t leave it empty unless you have a requirement for completely passwordless access.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/simon/.ssh/id_dsa.
Your public key has been saved in /home/simon/.ssh/id_dsa.pub.
The key fingerprint is:
Now we add the public key from the client into the authorised keys file on the sever, creating the file if it doesn’t already exist. Multiple keys can be added file if necessary, just append them to the end of it.
Verify that the keys work. You should now be prompted for a passphrase instead of a password. If not, check that DSAAuthentication is enabled in /etc/ssh/sshd_config on the server.
$ ssh server
Enter passphrase for key '/home/simon/.ssh/id_dsa':
Okay, so we’re now using public key authentication, good times, but still having to enter a passphrase, bad times. By using ssh-agent, you just need to enter your passphrase once per session. For security reasons I suggest using the -t option to periodically expire passphrases. For example, at work I use ssh-add -t8h at the begining of the day in order to have is expire shortly after I finish work.
Enter passphrase for /home/simon/.ssh/id_dsa:
Identity added: /home/simon/.ssh/id_dsa (/home/simon/.ssh/id_dsa)
Now you can just type ssh server and you will be automagically logged in to the remote machine.
Like most technically minded people, okay then, geeks, I spend a lot of time (too much?) reading about and playing with new technologies and the latest software releases. Before now I’ve used my private wiki as a dumping ground for links, code samples, howtos and it’s become a huge mess. I’m hoping that setting up this blog will encourage me to write-up the more interesting stuff and that it maybe of some use to others. That’s it for the first entry, I’m off to look for a new theme.