Help with script for ssh exploit attempts
Hi, I could use a little help with some scripting. My perl/python is rudimentary, and bash not a lot better, but I'm sure this isn't too hard to do... We get a lot (read thousands a day) of these lines in logs on all the machines we support, including our own: Jul 6 16:53:24 xxx sshd[1628]: Invalid user chris from 202.202.43.110 It's a script kiddie trying to take advantage of an exploit in SSH. We use key-based authentication only, on SSH V2, so no real risk there, but it's annoying. What I'd like to do is monitor the logs for such a line (or maybe three on the trot), and immediately do this: /sbin/route add -host 202.202.43.110 reject which will lock them out until a restart. Any help appreciated! Cheers, Laurie. -- -------------------------------------------------------------------- Laurie Brown laurie@brownowl.com --------------------------------------------------------------------
On 7/6/06, Laurie Brown <laurie@brownowl.com> wrote:
We get a lot (read thousands a day) of these lines in logs on all the machines we support, including our own:
Jul 6 16:53:24 xxx sshd[1628]: Invalid user chris from 202.202.43.110
It's a script kiddie trying to take advantage of an exploit in SSH. We use key-based authentication only, on SSH V2, so no real risk there, but it's annoying.
I use "ssh block", which I would tell the URL, except my google foo has failed me, and my working example is switched off due to excessive heat. It works by blocking the IP with iptables for a few days after 4 failed attempts. Can be white listed, of course. Hope this helps, Tim.
Tim Green wrote:
On 7/6/06, Laurie Brown <laurie@brownowl.com> wrote:
We get a lot (read thousands a day) of these lines in logs on all the machines we support, including our own:
Jul 6 16:53:24 xxx sshd[1628]: Invalid user chris from 202.202.43.110
It's a script kiddie trying to take advantage of an exploit in SSH. We use key-based authentication only, on SSH V2, so no real risk there, but it's annoying.
I use "ssh block", which I would tell the URL, except my google foo has failed me, and my working example is switched off due to excessive heat. It works by blocking the IP with iptables for a few days after 4 failed attempts. Can be white listed, of course.
It's not practical to use iptables on every machine like that, whereas the route command is simple and immediately effective on the machine being attacked. Thanks for the link to "ssh block", I'll have a look and see if I can hack it a bit. Cheers, Laurie. -- -------------------------------------------------------------------- Laurie Brown laurie@brownowl.com --------------------------------------------------------------------
Tim Green wrote: [SNIP]
I use "ssh block", which I would tell the URL, except my google foo has failed me, and my working example is switched off due to excessive heat. It works by blocking the IP with iptables for a few days after 4 failed attempts. Can be white listed, of course.
Hope this helps,
It certainly did, Tim. Thanks! I pulled it down and hacked it about a bit, and it does what I need very well. For the record, I got it from here: http://bluedogsecurity.cyberinfo.se/ssh_block/ I removed the reference to /var/log/secure as I don't use it, and changed the "business" line to this: | awk '{ system("/sbin/route add -host " $0 " reject" )}' I've tested it, and it works very well. Top stuff! I love Linux! Cheers, Laurie. -- -------------------------------------------------------------------- Laurie Brown laurie@brownowl.com --------------------------------------------------------------------
On 06-Jul-06 Laurie Brown wrote:
Hi,
I could use a little help with some scripting. My perl/python is rudimentary, and bash not a lot better, but I'm sure this isn't too hard to do...
We get a lot (read thousands a day) of these lines in logs on all the machines we support, including our own:
Jul 6 16:53:24 xxx sshd[1628]: Invalid user chris from 202.202.43.110
It's a script kiddie trying to take advantage of an exploit in SSH. We use key-based authentication only, on SSH V2, so no real risk there, but it's annoying.
What I'd like to do is monitor the logs for such a line (or maybe three on the trot), and immediately do this:
/sbin/route add -host 202.202.43.110 reject
which will lock them out until a restart.
Any help appreciated!
Cheers, Laurie.
The following may perhaps be a bit simplistic for your purpose, but something on these lines might work for you. tail -f -n 1 logfile | grep sshd | grep "Invalid user" | awk '{n=NF}; {if(n>1){{system( "/sbin/route add -host " $n " reject" )}}' where "logfile" is the pathname of the file wehre your logs are sent. This will take action each time -- and only then -- when you get a line with "sshd" and "invalid user" in it, on the assumption that any such line ends in an IP address. If this assumption does not hold, then you may need to be a bit more subtle about it. Hoping this helps, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 06-Jul-06 Time: 17:50:50 ------------------------------ XFMail ------------------------------
Hi,
I could use a little help with some scripting. My perl/python is rudimentary, and bash not a lot better, but I'm sure this isn't too hard to do...
We get a lot (read thousands a day) of these lines in logs on all the machines we support, including our own:
Jul 6 16:53:24 xxx sshd[1628]: Invalid user chris from 202.202.43.110
It's a script kiddie trying to take advantage of an exploit in SSH. We use key-based authentication only, on SSH V2, so no real risk there, but it's annoying.
What I'd like to do is monitor the logs for such a line (or maybe three on the trot), and immediately do this:
/sbin/route add -host 202.202.43.110 reject
which will lock them out until a restart.
Any help appreciated!
Cheers, Laurie. --
Be careful with auto route blockers and iptables manipulators like that. As an attacker you could detect quit easily that you're being actively blocked then spoof the source ip as the target computer. The blocker script would then quite correctly shut down all routes to and from its self requiring console access. As an added kick in the proverbials the attacker could spoof his address as a 192.168.x.x range and block local lan access as well. In effect you just dos'd yourself! Not too much of a problem if you are on site but a bugger if your server is remote. One way to combat it is to time out the blocks with an intelligent script that removes the block after, say, 10 mins. Just be careful is all :) Stuart -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself?
Stuart Fox wrote: [SNIP]
Be careful with auto route blockers and iptables manipulators like that. As an attacker you could detect quit easily that you're being actively blocked then spoof the source ip as the target computer. The blocker script would then quite correctly shut down all routes to and from its self requiring console access. As an added kick in the proverbials the attacker could spoof his address as a 192.168.x.x range and block local lan access as well. In effect you just dos'd yourself! Not too much of a problem if you are on site but a bugger if your server is remote.
One way to combat it is to time out the blocks with an intelligent script that removes the block after, say, 10 mins.
Just be careful is all :)
Fair point, but all our servers are already behind firewalls that deal with that sort of spoofing, so it's unlikely that it will occur. In my research I've found this tool, which is gentoo-orientated, but should be adaptable. It looks really good, and has expiries and such-like built in: http://blinkeye.ch/mediawiki/index.php/SSH_Blocking In the last 4 days I've had over 88,000 ssh-cracking hits on one (randomly-selected) server alone. I'd just like to drop the traffic... Cheers, Laurie. -- -------------------------------------------------------------------- Laurie Brown laurie@brownowl.com --------------------------------------------------------------------
Laurie Brown <laurie@brownowl.com>
What I'd like to do is monitor the logs for such a line (or maybe three on the trot), and immediately [...] lock them out until a restart.
Try Adam Rosi-Kessel's ssh_login_blocker from http://adam.rosi-kessel.org/weblog/free_software/code/ssh_login_blocker.html Hope that helps, -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
participants (5)
-
Laurie Brown -
MJ Ray -
Stuart Fox -
Ted.Harding＠nessie.mcc.ac.uk -
Tim Green