# New ssh attack?

## Carnildo

In the past few days, I've seen a shift in the pattern of failed ssh login attempts.  Normally, I see one or two hosts each trying several hundred usernames.  However, starting sometime last Sunday, I've instead been seeing several hundred different hosts each trying to log in as either "root" or "mysql".  Is there some new exploit going around?

----------

## transient

http://isc.sans.org/diary.html?storyid=3529

----------

## padoor

how do i check if my computer is being accessed by ssh attack?

i have no firewall installed.

code please

----------

## ToeiRei

```
cat /var/log/messages
```

That thing is called 'syslog'...

----------

## padoor

thanks ToeiRei

none found.

----------

## bunder

 *padoor wrote:*   

> how do i check if my computer is being accessed by ssh attack?
> 
> i have no firewall installed.
> 
> code please

 

 *Quote:*   

> grep "`date +'%b %e'`" /var/log/auth.log | grep "Invalid user"
> 
> grep "`date +'%b %e'`" /var/log/vsftpd.log | grep "FAIL LOGIN"
> 
> 

 

should get you all the failed logins for sshd and vsftpd (for today).  you can add a "| wc -l" for numbers instead of raw output.

cheers

----------

## padoor

localhost sda1 # grep "`date +'%b %e'`" /var/log/auth.log | grep "Invalid user"

grep: /var/log/auth.log: No such file or directory

localhost sda1 # grep "`date +'%b %e'`" /var/log/vsftpd.log | grep "FAIL LOGIN"

grep: /var/log/vsftpd.log: No such file or directory

localhost sda1 # dir /var/log

Xorg.0.log                      

Xorg.0.log.old                 

cups                            

dmesg                           

emerge-fetch.log                

emerge.log                       

faillog                        

kdm.log                       

lastlog                          

messages                         

news                             

portage                          samba

localhost sda1 #            

there is no such   login refused or requested except my own newly connected    laptop which shows in messages

----------

## bunder

what's your logger?  i use sysklogd... maybe you do have to check /var/log/syslog (or messages like you said,)for these.    :Confused: 

----------

## Ramblurr

This is a useful program.. I've used it for some time now, and it works well. 

"BlockSSHD is a Perl script based on BruteForceBlocker v1.2.3 that dynamically adds IPTables rules for Linux and pf firewall rules for BSD that block SSH brute force attacks. It can also detect ProFTPd login failures."

http://blocksshd.sourceforge.net/

----------

## ToeiRei

another way would be disabling password logins and using keys.

Rei

----------

## Corvinian

Consider moving your SSH-port, this way I have reduced 99,99% of all brute-forcing attempts!

Others who did this can confirm, too. 

And you get it for free!  :Smile: 

Please read this:

http://www.ossec.net/en/attacking-loganalysis.html

additionally use public-keys,

disallow direct root-access, allow only 'su' to root.

root is by far the most often tried brute-force account!

I can highly recommend 'fail2ban', it has no weaknesses as its comparing program 'denyhosts', which has exploitable weaknesses discovered every month (or so), and still new ones get known frequently.

http://www.fail2ban.org/wiki/index.php/Features

fail2ban can protect ALL services, not just SSH. It has DOS-protection, so somebody spoofing your

IP-address cannot block/deny you administrative SSH-access. You can centrally gather/aggregate fail2ban-data from all your hosts/servers...

Maybe OSSEC can do this too, but I need to evaluate it myself first, seems to be similar to Samhain and OSIRIS: http://www.ossec.net

"OSSEC is a scalable, multi-platform, open source Host-based Intrusion Detection System (HIDS). It has a powerful correlation and analysis engine, integrating log analysis, file integrity checking, centralized policy enforcement, rootkit detection, real-time alerting and active response."

HTH, Corvinian

----------

## Carnildo

 *Ramblurr wrote:*   

> This is a useful program.. I've used it for some time now, and it works well. 
> 
> "BlockSSHD is a Perl script based on BruteForceBlocker v1.2.3 that dynamically adds IPTables rules for Linux and pf firewall rules for BSD that block SSH brute force attacks. It can also detect ProFTPd login failures."
> 
> http://blocksshd.sourceforge.net/

 

BlockSSHD, Fail2ban, and Denyhosts are all useless against the current attack.  When each host only tries one username/password combination, it's not useful to identify it as a brute-force attack, because you can't tell who will try the next combination.

----------

## Ramblurr

It isn't always convenient but changing the port your SSHD listens on helps a lot. Of course a port scan will reveal which port it is running on. Using keys instead of passwords is (as others have said) a good solution.

Another solution would be to implement a port knocker. See net-misc/knock  from http://www.zeroflux.org/knock/

----------

## Corvinian

Portknocking sequences can be easily captured and replayed.

A solution to this could be 'Single Packet Authorization (SPA)' => looks quite promising!

http://www.cipherdyne.org/fwknop/

a quote:

Single Packet Authorization retains the benefits of Port Knocking (i.e. service protection behind a default-drop packet filter), but has the following advantages over Port Knocking:

SPA can utilize asymmetric ciphers for encryption. Asymmetric ciphers typically have larger key sizes than symmetric ciphers, and the data transmission rate of port knocking (which uses packet headers instead of packet payloads) is not sufficient to effectively use an asymmetric cipher. SPA is compatible with 2048-bit Elgamal GnuPG keys.

SPA packets are non-replayable. There are strategies (such as S/Key-style iteration of a hash function) used by port knocking implementations to reduce the danger of a replayed knock sequence, but these strategies are relatively brittle and not generally very scalable to lots of users.

SPA cannot be broken by trivial sequence busting attacks. For any attacker who can monitor a port knocking sequence, the sequence can be busted by simply spoofing a duplicate packet (as though it comes from the source of the real sequence) to the previous port in a sequence.

SPA only sends a single packet over the network, and hence does not look like a port scan to any intermediate IDS that may be watching.

SPA is much faster because it only sends a single packet. Port knocking implementations must build in time delays between successive packets because there is no guarantee of in-order delivery. 

But I haven't come around testing it.

Corvinian

----------

