How to Secure SSH server from Brute-Force and DDOS with Fail2ban ( Ubuntu )

Fail2ban is a security tool used for preventing brute-force attack and Distributed Denial of Service (DDoS) attack to your GNU/Linux box.

Fail2ban monitors failed login attempts and subsequently blocks the ip address from further logins. Although Fail2ban can also be used to secure other services in Ubuntu server, in this post, I will only focus on securing SSH server.

Step 1: Install Fail2ban and (optionally) sendmail

sudo apt-get install fail2ban
sudo apt-get install sendmail-bin

Step 2: Setting up Fail2ban

Next, you need to configure fail2ban by creating a copy of ‘jail.conf’ to ‘jail.local’

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

Step 3: General fail2ban configuration

Edit fail2ban configuration file using your favorite text-edito (I personally use ‘nano’)

sudo nano /etc/jail.local

You can set IP address for fail2ban to ignore, IP addresses can be separated by space.

Bantime is the duration of time that you want fail2ban to block suspicious attempt, the value is in seconds
Maxretry is the number of failed attempts before fail2ban block the IP-address, in this case 3600 means 1-hour ban

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 192.168.1.1
bantime  = 3600
maxretry = 3 

Step 4: Enabling ssh and ssh-ddos protection
Find ssh configuration under [ssh] heading, and enable it.

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3 

Similarly, you can also enable [ssh-dos] protection by changing the enabled value to “enabled = true

[ssh-ddos]
enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 2

Step 5: Enable Sending Notification Email (optional)
Optionally you can have fail2ban sends you notification email in case of suspicious login detected. To do that, you need to locate destemail settings and changed it to your email

destemail = security@mypapit.net

Fail2ban can use ‘sendmail’ and ‘mail’ application to send notification email

Step 6: (Re-)start Fail2ban
After all is done, you may save the file, and (re)start the fail2ban service

sudo /etc/init.d/fail2ban restart

You can test the configuration by trying to login into your box. You may also check fail2ban log in /var/logs/auth.log (or in other directory specified in jail.local)

For more information about fail2ban, you can read : the official fail2ban manual

Recommended Reading

How to Setup SSH public-key or password-less authentication in Ubuntu

Here’s how to setup public-key (or passwordless) authentication in Ubuntu or any other Linux based operating system that use OpenSSH.

First make sure you’ve remote SSH server running and accepting connection. Then you need to generate ssh key on local server (I prefer RSA). You can enter passphrase for added security, or leave it blank for passwordless authentication.

local:~$ ssh-keygen -t rsa
Enter passphrase (empty for no passphrase):

The command will generate id_rsa and id_rsa.pub files. The files will be save in ~/.ssh/ directory. Then copy id_rsa.pub file to the remote server using SCP. Read How to use SCP on Linux or other UNIX-based Environment for more information about SCP

local:~$ scp id_rsa.pub username@remote.host:~/

Then you have to connect to the remote host and append the id_rsa.pub public key file to the list of “authorized_keys“. Don’t forget to chmod the authorized_keys file and .ssh directory, or OpenSSH won’t work correctly

local:~$ ssh username@remote.host

#now we are on remote server!
remote:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
remote:~$ chmod 644 ~/.ssh/authorized_keys
remote:~$ chmod 700 ~/.ssh

Make sure you have edited the “/etc/ssh/sshd_config” file to allow Public key authentication and RSA authentication.

#sshd_config file

PermitRootLogin no
...snip...
RSAAuthentication yes
PubkeyAuthentication yes
...snip..

Save and restart sshd server daemon by running the following command.

remote:~$ sudo /etc/init.d/ssh restart

After that, logout from the remote host to test the Public-key authentication


remote:~$ exit
local:~$

Testing the SSH public-key authentication
To test the public-key authentication, simply connect to remote server normally using ssh, and if things have gone smoothly you’ll be prompted to enter your passphrase, instead of password.


local:~$ ssh username@remote.host
Enter passphrase for key '/home/username/.ssh/id_rsa':

Note that you will not be prompted to enter passphrase/password if you’ve generated a key with “blank passphrase“, effectively making your login “passwordless”. For added security, it is advised that you disable normal interactive-keyboard password option and rely fully on public-key authentication by changing sshd_config line from:

PasswordAuthentication yes

to


PasswordAuthentication no

p/s: this tutorial was adapted from Shortest passwordless ssh tutorial, ever with updated notes for latest OpenSSH release

How to setup Secure Webserver HTTPS (SSL) on Apache in Ubuntu

Secure HTTP (SSL/TLS) has become a must if you are planning to setup a website which includes user authentication (ie. login box) or sensitive data. HTTPS prevents the sensitive data from being transfered across the network in clear text where it is susceptible to being sniffed or altered. Here is the tutorial on how to setup a secure HTTP on Apache web server in Ubuntu 10.04 (Lucid Lynx).

What do you need?

  • apache2 (Web Server)
  • openssl
  • A bit patient, because it will take some time to learn

Step 1: Create a self-signed certificate
You need to create a self-signed certificate with openssl. To do that you will need to generate the server key.


openssl genrsa -des3 -out server-sec.key 4096

…and certificate signing request (CSR)


openssl req -new -key server-sec.key -out server.csr

After that, generate the server certificate by signing it with the server key.

openssl x509 -req -days 365 -in server.csr -signkey server-sec.key -out server.crt

Keep the server-sec.key in a secure location, with read/write permission assigned only to root. Then generate a password-less copy of the key for Apache use.

openssl rsa -in server-sec.key -out server.key

By this time, you should have :

  • server.key (passwordless key for Apache)
  • server.csr (certificate signing request)
  • server.crt (certificate)
  • server-sec.key (server key)

Continue reading “How to setup Secure Webserver HTTPS (SSL) on Apache in Ubuntu”

ssh-vulkey : How to test weak SSH keys on your server

This might be stale news by most security alert people, but I felt compelled to write this post nevertheless. Byy this time most security alert people have realised that a serious security vulnerability has been discovered in the random number generator used by OpenSSL on Debian and Ubuntu systems, and there are a lot of sites have published information about it. [1] [2] [3] [4] [5].

This vulnerability caused OpenSSL to generate “common” and predictable keys, which is easily crackable by using brute-force algorithm. In the extreme case, some of the keys are successfully cracked in 2 hours time. Longer keys 8192-bit RSA keyset might take as short as 129 days to generate as opposed to hundred of years if the keys were generated securely.

Which Ubuntu Linux system are affected ?
As Ubuntu linux operating system is based on Debian, it inherited Debian vulnerability problem. Users who has generated keys under (before updating to the new OpenSSL package via automatic updates, which is before May 13 2008) — Ubuntu 7.04 Ubuntu 7.10 Ubuntu 8.04 LTS are all affected by this vulnerability

Other system which uses the keys generated by Debian and the above mentioned Ubuntu system is also affected as the keys might allow malicious 3rd party user to abuse the system. SSH login which uses these keys will not be considered secure anymore, and are advised to update their SSH keys immediately.

How to check against weak SSH keys ?
A system is as strong as its security measures (in this case, the key) to protect it. By using ssh-vulkey as detailed in Ubuntu Security Notice 612-2, you can detect weak keys in your system, and updates them accordingly.

Run “sudo ssh-vulnkey -a” command to check against weak keys :

ssh-vulnkey -a

ssh-vulnkey -a
Not blacklisted: 2048 fa:2e:1d:a6:84:64:a1:80:c4:31:68:5a:b0:1a:cb:fe /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 f4:34:04:85:58:a0:6b:0a:a1:b9:2d:3b:e6:19:5a:76 /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 2048 5c:10:8a:c0:55:8c:1f:d9:4b:05:f0:35:0a:0d:2f:5c /home/someuser/.ssh/authorized_keys
Not blacklisted: 2048 a7:b4:3e:41:18:cb:f7:68:5e:4f:ae:30:14:d2:17:fd /home/someuser/.ssh/authorized_keys

More information about OpenSSL in Debian / Ubuntu security vulnerability :