Main

Services

Clients

OOXML

 
Posted 3 months ago by Nazar Aziz

Automatically Report all SSH Brute Force Attacks to ISPs

3244 reads - 6 comments

Update 4th July: This plugin has now been in operation for about 12 hours and has sent a few notification emails overnight. So far I have had four replies from system admins confirming that these machines have been compromised. These machines have since been removed from the Internet.

SSH Brute Force Attacks on the Increase

The last few months and particularly in the last few days (beginning of July) saw a marked increase in global SSH brute force attacks.

What is SSH?

SSH is a common and secure method to remotely connect to Linux/Unix servers, be this for managing or uploading content (via SCP/SFTP for example).

Generally, system administrators configure a SSHD server to only allow a limited access by either disallowing certain users to logon (i.e. root) or by restricting from where remote connections can be made.

The Problem.

Sadly, there exists many Linux/Unix boxes with poorly configured SSHD servers. These typically have username/password combinations of test/test, web/web, john/john and so on.

It is these servers that are targeted by botnet operators. Once such a server is found, it is often compromised and itself becomes a zombie in the botnet. These servers, in turn, then go on and attempt to compromise other servers on the internet.

The Real Problem

It is fairly easy to hack proof your server. Brute force attacks can also be thwarted by running DenyHosts on your server. DenyHosts monitors all SSHD hack attempts and blacklists the attacker. DenyHosts can also be optionally configured to share your blacklist with other DenyHosts users. This sharing of blacklists can greatly reduce SSHD attempts.

The real problem still remains. SSHD attacks are now on the increase and it is no longer sufficient to blacklist offenders.

Ideally, any SSHD hack attempt should be blacklisted, logged and most importantly; the ISP of the attacker must be notified in order to disconnect the attacking machine from the internet.

The Solution - report-hack-isp Plugin

We have developed a DenyHosts plugin that will email an attacker’s ISP as soon as the attack is detected. DenyHosts supports plugins to perform extra commands when an attacker is blacklisted. This email also contains an excerpt of the SSHD logfile that provides details of the attempted attack.

DenyHosts is the first step in this pro-active approach. Download, install and enable DenyHosts to synchronise your blacklist with the DenyHosts central server.

Armed with this, an ISP has sufficient evidence to take appropriate action.

Requirements

This is applicable to Linux/Unix/BSD servers only. The plugin requires the following applications:

Download

Report-hack-isp can be downloaded from http://github.com/nazar/report-hack-isp/tree/master

Instructions

I've posted a simple guide on how to configure and setup this plugin here.

Metalog Users

Please note that several system loggers compress output by default. This means that if a log entry is repeated, the logger caches and outputs "Last output repeated" x times to the log file.

Please note that such compression should be turned off otherwise the DenyHosts log scanner will miss several entries.

If using MetaLog, add showrepeats = 1 to your metalog.conf file.


Digg it! Slashdot Del.icio.us Technorati Google Bookmarks Reddit! Dzone Yahoo! MyWeb

Comments - add your comment

What others have said:

 
why would you need to allow ssh from the entire wo

I remote admin tons of linux boxes but still dont need to allow attempts from anywhere but the ip ranges of isp’s i use
thus downing my attack surface by hmm several billion degrees

also makes logging easier {every connection attempt from dissallowed space just gets reported and just fails wheither the right id or password was used or not}

simply done by running ssh via xinet.d
and using hosts allow from

{just in case i end up on a weird isp} i run another sshd via xinet.d on a crazy port only allowing login from one hidden id/password, that users shell is set to a script that adds his ip to the hosts allow in /etc/winet.d/ssh and restarts xinet.d and logs-out

so from new ip i can ssh usermyhost:crazyport
password **
host closed connection
then
ssh me
myhost
my greet-banner
password:

simple really
the odd time a host from one of my ISP’s attempts login {never happened yet} i’ll report manually {as i get a log of all failed passwords per day}
failed connection attempts are allways reported

Posted 2 months ago

 
ps. also all successfull shell logins should mail

just include this script in /etc/profile.d/loginalert.sh
#!/bin/sh
if [ “$SSH_CLIENT” = ‘’ ]
then
MSG="’“"$LOGNAME just logged into $HOSTNAME via telnet or console @ `date +%c`”“’”
else
MSG="’""$LOGNAME just logged into $HOSTNAME via ssh from $SSHCLIENT @ `date +%c`“"’”
fi
cat $HOME/.bash
history | /usr/bin/Mail–s"$MSG" login-alert
echo “$MSG” >$HOME/.bashhistory
who >>$HOME/.bash
history

it will alert of any successfull ssh or console login {as on a server its unlikely to happen often {also it means you have a nice mail based audit trail of what you did last login} {also alerts on telnet but who’s that crazy} or any exploit that starts bash shell

Posted 2 months ago

 
If you're using Fail2ban instead of Denyhosts...
By: Russ

Inspired by this plugin, I wrote a similar one for users of Fail2ban. Download here: http://www.gloomytrousers.co.uk/open_source/fail2ban.shtml

Nazar, you may be interested in my implementation–I extended your idea of preferring “abuse@” addresses to look for more patterns, both in the e-mail address, on the line in which the address appears, and in the couple of lines immediately above. I’ve found this is more effective at finding the right addresses for complaints.

Posted 2 months ago

 
Fail2Ban
By: nazar
Joined: September 21, 2007
Posts: 15

Hi Rus.

Thanks for your comments plus the link. Will definitely incorporate some of your ideas.

Posted 2 months ago