ssh mass login attempts... what to do..

[ndavey]

Hi All,
Been looking at my auth.log files, and on a semi-regular basis I notice mass ssh login attempts (someone looking for weak / no password accounts etc)...

What do other ppl do about these? Just leave them be? Is there some software I can setup in the vps to block the ip for a period of time?

Regards
Neil

[artagesw]

What I have found most effective is to use a firewall to block access to SSH except for your own management IPs. This works best if you connect to the Internet via a static IP address. I am using apf on my VPS and it is working well. I'm planning on writing up a HOWTO document soon. Let me know if you are interested in "beta-testing" it for me.

Sam

[ndavey]

artagesw,
I had considered doing that, but I connect from a number of networks, and not all have static IP's. Also, I encourage my clients to use sftp (I don't like running an ftp server if I can help it) so I can't really lock it down that way..

I don't have a problem having SSH port open.. but if I get a flood of connection attempts it would be nice to be able to block it dynamiclly.. Actually, come to think of it, that should be possible... hmm... google time... :)

Regards
Neil

[artagesw]

Two packages to look into would be portsentry and psad.

http://sourceforge.net/projects/sentrytools/
http://www.cipherdyne.org/psad/

psad works by watching iptables logs, so it may not be useful in your particular case. Worth checking out though.

Sam

[RedOut]

Here's what I do... I let iptables block ip addresses that aren't nice, and I whitelist good addresses.

Something like this...


iptables -N SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP


You can add hosts to the whitelist with:


iptables -A SSH_WHITELIST -s <TRUSTEDIPADDRESS> -m recent --remove --name SSH -j ACCEPT

(obviously replace <TRUSTEDIPADDRESS> with your IP address.)

You could also switch to public key authentication, and disable password authentication, which would render the brute force attacks useless.

[lazyant]

1) Use strong passwords. You can also use of the scripts that parse the /var/log/secure file for these attacks and ban the IP addresses in /etc/hosts.deny

2) Do not use password-based SSH authentication; allow only signature-based.

In more detail:

http://www.fduran.com/wordpress/?p=21

[sam]

iptables -N SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP



I'd propose using --rcheck instead of --update. --update adds a new entry to the recent log, so you're getting two entries per hit. also, when you use --rcheck you can eliminate the state checking in the --rcheck rules because you're only checking, not setting.

also, might want to add a -m limit rule to the logging rule so you don't flood your logs.

[UnrulyGrrl99]

I have had very good luck with simply changing the port SSH answers on. I went from hundreds of hacker login attempts to a handful every 4-6 weeks. I keep an eye on my Logwatch emails and just add the IP address to my firewall to drop all packets to any source IP that looks like a hacker attempting to login.

Change the port to something beyond 1024, that is the default last-looked-at port for nmap.

[sam]

fwiw, here's a little script i run daily via cron to email me a report of recent attempts. assumes you have an iptables rule, like the one described above, that prefaces brute force attempts with "SSH brute force."

#!/bin/sh

cat <<EOF>/tmp/bf.tmp
The following IPs attempted brute force SSH attacks on $(date -d yesterday +%A,\
%B%e):

`grep "$(date -d yesterday +'%b %e')" /var/log/messages | grep "SSH brute force"
| awk '{print $12;}' | cut -c 5-`
EOF

cat /tmp/bf.tmp | mail -s "SSH Attack Report for $(date -d yesterday +%F)" root

rm /tmp/bf.tmp

[Eustace1435]

A w e s o m e !

[manish]

You could apt-get the 'logwatch' package, for automatic analysis of logs (including ssh-brute force attempts) and daily emails.

[dlevancho]

I have same issue my log is full of unauthorized access atempts, so what if it was possible for rimu guys to let us use rsa keys for authentication instead of username and password, so for example I generate pair of keys and send public key to rimu to put it on my server so I can get authenticated with ssh2 using my private key matched with one on the server? is it something possible to do here? this is how I connect to all of our manages servers at work.

[kulej]

OK, so I know this thread's a little old, but good info for a newbie.

Is it proper to put the throttling rules before or after the ACCEPT ssh rule? I think I had it backwards, and I ended up locking myself out. Yes, I have quite a nice log delay in there. I NOW have this (where I've flipped it around):

# Allow connections to our SSH server
-A INPUT -p tcp -m tcp --dport ssh -j ACCEPT

# Auto limit throttle
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 1800 --hitcount 2 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 1800 --hitcount 2 --rttl --name SSH -j DROP