Tag Archives: ssh

Block SSH Brute Force Attacks

I already advised in one of my previous post [1] to disable the root log-in on your Linux host. Neither the less, sometimes – somebody will try to attack you with an SSH Brute Force Attack. For those who are not familiar with brute force attacks, these are attacks, where all possible passwords are tested [2]. Starting from single digit passwords going to an undefined length you can imagine how much possibilities you will have to try. Therefore brute-force – and you can imagine that this will consume network bandwith on one side, but also processor load.

So as suggested in [1], set the root password according to modern standards and definitley turn off your ssh root log-in. Neither the less at a certain point somebody will try to perform a SSH brute force attack.

An indication for a ssh brute force attack is definitley if you find something like that in your /var/log/auth.log:

Feb 17 05:57:26 lvps5-35-244-75 CRON[30441]: pam_unix(cron:session): session closed for user root
Feb 17 05:58:12 lvps5-35-244-75 sshd[17899]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:58:14 lvps5-35-244-75 sshd[17899]: Failed password for root from 115.239.228.15 port 39623 ssh2
Feb 17 05:58:19 lvps5-35-244-75 last message repeated 2 times
Feb 17 05:58:21 lvps5-35-244-75 sshd[17899]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:58:33 lvps5-35-244-75 sshd[17901]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:58:35 lvps5-35-244-75 sshd[17901]: Failed password for root from 115.239.228.15 port 40071 ssh2
Feb 17 05:58:41 lvps5-35-244-75 last message repeated 2 times
Feb 17 05:58:43 lvps5-35-244-75 sshd[17901]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:58:45 lvps5-35-244-75 sshd[17906]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:58:47 lvps5-35-244-75 sshd[17906]: Failed password for root from 115.239.228.15 port 52315 ssh2
Feb 17 05:58:56 lvps5-35-244-75 last message repeated 2 times
Feb 17 05:58:58 lvps5-35-244-75 sshd[17906]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:59:01 lvps5-35-244-75 CRON[17913]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 17 05:59:01 lvps5-35-244-75 CRON[17913]: pam_unix(cron:session): session closed for user root
Feb 17 05:59:02 lvps5-35-244-75 sshd[17911]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:59:04 lvps5-35-244-75 sshd[17911]: Failed password for root from 115.239.228.15 port 42931 ssh2
Feb 17 05:59:09 lvps5-35-244-75 last message repeated 2 times
Feb 17 05:59:11 lvps5-35-244-75 sshd[17911]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:59:21 lvps5-35-244-75 sshd[17916]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.15 user=root
Feb 17 05:59:23 lvps5-35-244-75 sshd[17916]: Failed password for root from 115.239.228.15 port 42738 ssh2 

So, what to do? Panic? No!

The solution is easy-cheesy: use iptables to slow down the flow of request. The idea is to drop any ssh connection coming from a single source which is trying to attempt 4 times in a minute. This can be done via the following command:

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

If you watch your /var/log/auth.log, you will notice that the amount of connection attempts will decrease. So time to relax and having a cup of tee.

Please note that those rules are active until your next reboot. Actually I prefer to check out the rules first, before applying them permanently. If you are sure and you like to apply them permenently, please follow the official Ubuntu Howto [3].

Have a save day!

 

[1] jvr.at, Basic Security for Linux hosts

[2] Wikipedia, Brute Force Attach

[3] Ubuntu.com, iptables Howto

Anonymous SSH over TOR and disconnect without a trace

Surfing through the internet anonymously is one thing, but certain services, e.g. ssh, makes it hard to remain anonymously. Fortunately there is a way to anonymously connect via ssh, or at least partly. Partly, since you still need a user account on the remote host. Kids, just a friendly reminder – don’t do illegal stuff!

Ok, since we’ve clarified this point – lets get back to work. Having my ubuntu, first we need to install for [1] and the connect-proxy service.

apt-get install tor
apt-get install connect-proxy

That was an easy one. Now we move to the home directory of your user with which you would like to connect to the remote host anonymously. Go to the .ssh/ directory. Check if there is a file called “config” existing. If it’s existing add the following lines, if its not existing, you should create a “config” file with the following content:

Host *
CheckHostIP no
Compression yes
Protocol 2
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p

Having the tor service running, you should now be able to connect to the remote host via ssh anonymously. One more additional tip – to “close” your session anonymously – not that it is required – you can do as follows.

echo $$
kill -9 `echo $$`

While the first command should show you the process id of your shell, the second one kills your shell without writing the bash_history.

[1] Tor Project

[2] Ubuntu connect-proxy manpage

 

Ajaxterm – ssh access via the web-browser

Quite often I am trying to access my Linux box remotely. Unfortunately most of the time for security reasons port 22 (SSH) is closed, leaving you disconnected from your home. Facing this issue, combined with my recent idea to get back to software development, its time to remove those boundary – lets install ajaxterm to get connected again.

Ajaxterm is a Python-based software using AJAX Javascript at the client side to provide an ssh terminal within a web-browser. Combining it with Apache’s Authentication it should be quite safe as well.

So lets start – first of all I think it is quite clear that you need an external accessible IP address as well as a web-server – e.g. Apache.  Using my own domain I then created a sub-domain pointing at the same IP address as my main server. I simply use the sub-domain as a structural way accessing various services. Having a Ubuntu System, the first thing now after updating the environment is getting the ajaxterm installed by the following command:

root@jvr.at:/home/jvr# apt-get install ajaxterm

Now we should enable the Password Authentication in /etc/ssh/ssh_config by simply uncommenting the line:

PasswordAuthentication yes

The next step is to create a login/password on the Apache Authentication level by following commands (please replace “MyName” with the preferred user name and please don’t use any kind of simple passwords):

root@jvr.at:/home/jvr# mkdir /srv/ajaxterm
root@jvr.at:/home/jvr# cd /srv/ajaxterm
root@jvr.at:/srv/ajaxterm# htpasswd -cm /srv/ajaxterm/.htpasswd MyName

Okay – following a structured approach, lets create now a separate Apache configuration file for the ajaxterm: /etc/apache2/sites-available/ajaxterm with the following content:

<VirtualHost ajaxterm.jvr.at:443>
                      ServerName ajaxterm.jvr.at
                       HostnameLookups Double
                       CustomLog /var/log/apache2/access.log combined env=!dontlog
                       SetEnvIf Request_URI "^/u" dontlog
                       ErrorLog /var/log/apache2/error.log
                       Loglevel warn
                       SSLEngine On
                       SSLCertificateFile /etc/apache2/ssl/apache.pem
                     <Proxy *>
                                 AuthUserFile /srv/ajaxterm/.htpasswd
                                 AuthName EnterPassword
                                 AuthType Basic
                                 require user MyUser
                                 Order Deny,allow
                                 Allow from all
                       </Proxy>
                       ProxyPass / http://localhost:8022/
                       ProxyPassReverse / http://localhost:8022/
  </VirtualHost>

So please note that the config is based on the newly created sub-domain. Furthermore we are using SSL but also, following the “require user”  line just enabling a defined user, named MyUser, to access the ajaxterm. Since the ajaxterm is basically a local running service, we have to set up a proxy.

But wait – having said before that we use SSL – I guess we will need to install and create an SSL certificate first. Therefore follow the following commands:

root@jvr.at:/srv/ajaxterm# apt-get install ssl-cert
root@jvr.at:/srv/ajaxterm# mkdir /etc/apache2/ssl
root@jvr.at:/srv/ajaxterm# /usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

And finally enable the proxy, ssl and the newly created ajaxterm config file.

root@jvr.at:/srv/ajaxterm# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Enabling module proxy.
Enabling module proxy_http.
Run '/etc/init.d/apache2 restart' to activate new configuration!
root@jvr.at:/srv/ajaxterm# a2enmod ssl
Module ssl already enabled
root@jvr.at:/srv/ajaxterm# a2ensite ajaxterm
Enabling site ajaxterm.
Run '/etc/init.d/apache2 reload' to activate new configuration!

Finally, just to be on the save side – we should restart the ajaxterm and the apache2 service by:

root@jvr.at:/srv/ajaxterm# /etc/init.d/ajaxterm restart
root@jvr.at:/srv/ajaxterm# /etc/init.d/apache2 restart

And now check-out your ajaxterm (hint – use https to access your service)!

2014/06/12: An additional note – some versions of ajaxterm seems to have an issue runng in daemon mode, where you receive an connection loss error. Suprisingly if you start ajaxterm from the console as a simple process it works. So to fix this issue I modified the startupscript in my Ubuntu installation in /etc/init.d/ajaxterm as follows (thats the diff):

42,43c42,43
<                         start-stop-daemon -b --start --group=$AJAXTERM_GID --pidfile $PIDFILE --exec
$DAEMON -- --port=$PORT --serverport=$SERVERPORT \
<                                 --uid=$AJAXTERM_UID >/dev/null &&
---
>                         start-stop-daemon --start --group=$AJAXTERM_GID --pidfile $PIDFILE --exec
$DAEMON -- --daemon --port=$PORT --serverport=$SERVERPORT \


>                                 --uid=$AJAXTERM_UID >/dev/null