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
_________________
reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

[ToeiRei]

[padoor]

thanks ToeiRei
none found.
_________________
reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

[bunder]

[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
_________________
reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

[bunder]

what's your logger? i use sysklogd... maybe you do have to check /var/log/syslog (or messages like you said,)for these.
_________________
goodbye fgo. it was nice knowing you.

[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
_________________
Blog | btrfs | Please stand by - The mailer daemon is busy burning your messages in hell...

[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!

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]

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