Visualizing failed SSH login attempts

Shortly after Christmas I opened the ssh port 22 at home to access my network from the Internet, while commuting or traveling. To secure the open port I installed fail2ban on the machine I redirected the port to. As soon as the jail was enabled in the file /etc/fail2ban/jail.conf and fail2ban was restarted it blocks the source IP for 5 minutes after 6 failed login attempts by default. If I remember right, it took only a few minutes and the first IP was blocked. I decided, that 5 minutes is too short and extended the blocking to one day, as well as the number of allowed login attempts, which I reduced to 3.

Since I use ssh-keys, I also decided to deny root login at all and password logins via pam by modifying /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

However, this caused some trouble with fail2ban. The log entries of failed login attempts in /var/log/auth.log now looked differently. And soon there was someone (more likely a bot?) trying to login 1960 times within 1:15 hours from the IP address 61.183.1.8. Therefore, I added the following lines to failregex in /etc/fail2ban/filter.d/sshd.conf

^%(__prefix_line)sConnection closed by \[preauth\]\s*$
^%(__prefix_line)sReceived disconnect from : 11: Bye Bye \[preauth\]\s*$

Now fail2ban blocks the login attempts again.

Before I turned off pam authentication, I searched the Internet for how to log passwords and came across this article on a Symantec site using so called honeypots to attract hackers with a weak system. This inspired me to evaluate at least the data I can extract from my auth.log files. I wrote a perl script, which creates a SQLite database of the failed logins and an R script using ggplot2 to display the results, which is even possible without using fail2ban. To find out the subnet and country of the source IP I found a function for R here, which I used for whois lookups. There are other possibilities to visualize the data, too, for example on the fail2ban webpage itself.

There were 4628 failed logins at total from 1005 IP addresses (457 subnets) with 296 usernames. And here are my results:

Timeseries for the one month my port is open now:

ts

The usernames used. Note that since I deny password logins usernames are only logged when they are before connecting (e.g. ssh admin@<host> for command line ssh). Note the x-axis are scaled logarithmic and only a subset of the total usernames, subnets and countries are shown:

user

The subnets, from which most attacks came:

subnet

The countries:

country

And finally the map (with this worldmap) with the number of attacks color coded (again logarithmic):

map

The strange colorbar is somehow related to cairoDevice. However, fonts are much better with it than with the default png device.

Both scripts I wrote are available on GitHub.

Another related link from Cisco: http://www.cisco.com/web/about/security/intelligence/ssh-security.html.

Advertisements

Installing a git server for our working group

In our working group we’ve been discussing for quiet a while now to install our own version control system. However, it was always a question of man power that nothing happened. At the end of last week I decided to install a git server on an unused computer in my office. I must say, it was much easier than I thought. After a quick web search I choose gitolite with gitweb, which is part of git. The operating system is Ubuntu 14.04, but I assume it is very similar for all Debian like systems (without the usage of sudo all the time, when you open one root shell in Debian). The main part of the information is from two other webpages on ubuntuforums and Ubuntu help. In the following I describe what I did and partly why. One minor problem persisted till the end. You have to modify some configuration files with your text editor of choice. On my local machine I prefer Emacs, nevertheless, my choice over the network is vi since it is much faster.

1.) Install the software

> sudo apt-get install gitolite gitweb

2.) Create user git

> sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

3.) Adjust projectroot and projects_list in /etc/gitweb.conf. I will use the user git to run gitolite, therefore I modified the corresponding lines in the config file:

$projectroot = "/home/git/repositories/";
$projects_list = "/home/git/projects.list";

4.) Configure the webserver, in my case I use Apache

> sudo cp -i /etc/apache2/conf.d/gitweb /etc/apache2/conf-available/gitweb.conf
> cd /etc/apache2/conf-enabled
> sudo ln -s ../conf-available/gitweb.conf

5.) Modify the Apache configuration: add “+” before “FollowSymLinks”

> sudo vi gitweb.conf

So that the config file looks like follows:

Alias /gitweb /usr/share/gitweb
  Options +FollowSymLinks +ExecCGI
  AddHandler cgi-script .cgi

6.) Add the user www-data to the group git, so that apache can read the repositories (www-data, or whatever UID apache is running under). You can do this either by modifying /etc/group by hand or by command:

> sudo vi /etc/group

or

> sudo usermod -a -G git www-data

7.) Enable the Apache CGI module and restart the server.

> sudo a2enmod cgi
> sudo service apache2 restart

8.) Gitolite uses a git repository for its one configuration, so that I don’t need to do everything under the UID git. For authentication ssh-keys are used. You have to copy the public ssh key (in Linux/Unix systems: ~/.ssh/id_rsa.pub) to a directory readable by the user git. The file name is the username for gitolite. For example you can use the user you are logged in as. If you have no ssh key pair yet create one first and follow the instructions:

> ssh-keygen
> cp ~/.ssh/id_rsa.pub /tmp/admin.pub

9.) Change to user git and initialize Gitolite

> sudo su - git
> gl-setup /tmp/admin.pub

10.) In the configuration file (~/.gitolite.rc) change $REPO_UMASK from 0077 to 0027, otherwise the webserver won’t be able to read the repositories and project lists. And then exit user git

> vi ~/.gitolite.rc
> exit

11.) Set up git global vars, if not previously done. And clone the configuration repository.

> git config --global user.email "your.email@domain.org"
> git config --global user.name "admin"
> git clone git@my.gitserver.org:gitolite-admin.git

12.) Add users by adding their public ssh key to the subfolder “keydir” in the just created repository “gitolite-admin”. Don’t forget to add the file to the repository!

cd gitolite-admin
git add keydir/newuser.pup

13.) Create new repositories in gitolite-admin/conf/gitolite.conf and commit changes and push them back to the server.

git commit -a -m "created new repository and added user newuser"
git push -u origin master

14.) Now comes the tricky point, which took a while to find out. And as always afterwards I thought “Was that easy!” The repositories were not listed on the webpage of gitweb (http://my.gitserver.org/gitweb/). If you want the repository to be displayed on gitweb the user “gitweb” needs to be added to the repositories access list in ~/gitolite-admin/conf/gitolite.conf.

All user for which you added a ssh key to the gitolite-admin repository cat now access those repositories for which you granted read and/or write access in the configuration file. All users use the UID git, p.e.

git clone git@my.gitserver.org:newrep.git

And now I and my collegues can access and share the repositories we work together on or we could also use it for manuscripts. If you want to follow the above description don’t forget to replace the usernames with your appropriate usernames and “my.gitserver.org” with your server name or IP address.