Security Incidents mailing list archives
Re: SSH scans...
From: <skippy1 () hickorytech net>
Date: Tue, 21 Dec 2004 11:07:49 -0600 (CST)
This is a fairly common idea, but its one that has some drawbacks to it. In general, automatically blocking a IP based on an IDS alarm has the advantage of needing less admin time but also has the potential of letting an attacker block outside IPs from you network at will. If an attacker figures out that your machine is protected this way and convinces your IDS that your home IP is trying to exploit the box, you have a problem. If you live half an hour from the box and don't have another way in, the attacker gets a free half hour to do what he wants. There are times when autoblocking is a worth while idea however. If you don't mind the chance of the service being down, it certainly can increase security. Added to the fact that spoofing TCP isn't that easy, and that (in this case) the attacker would have to spoof the ssh handshake and it sounds more feasible. In the case of ssh specifically, it might be a bit tough to set up autoblocking. Assuming that you would want to block on failed login attempts or login attempts using certain usernames, you would have to find a way to watch the ssh traffic through its encryption. In theory an nIDS could watch the handshake and given a copy of the server's private key could decrypt the traffic on the fly. This is not a good idea in a bunch of ways. A better way to do would be to set up a log watcher and block on the local machine based on the ssh daemon logging the failed attempts. The disadvantage is that you can only block one machine at a time that way. Skippy
Maybe this is a dumb question, but why not set up a honeynet or an IDS like snort and block addresses or networks as they begin scanning? Less administration needed and you don't have to block ranges larger than necessary... Also, I threw together a little C app and script which will quickly find passwords commonly used in brute force attacks. You may be able to use it with cron to locate users with easily-guessed passwords and reset them so brute force attacks aren't as successful. http://freshmeat.net/p/dumbass/ Gerry Dalton wrote:I have seen similar probes over the last 2 months. Most all have been from APNIC address blocks. I got so tired of some of it I just went ahead and blocked a full range of addresses from getting past our border routers. So far these have just been a nuisance. Gerry At 09:21 AM 12/20/2004, Dejan Markovic wrote:Hi Guys, Don't know whether this is the right list, but need to ask if others have the same entries in their logs for the past number of months. Let me take a step back, I maintain a number of networks on different IP ranges and they are all being probed by what looks like a tool, or maybe it is the same group/script. The originating computers range from open proxies to owned boxes and there are two distinct patterns I've seen so far. The following scan is a recent example where the root/password from x.x.x.x: 59 Time(s) caught my attention the first time a while back, and still getting the same scans on a daily basis: account/password from 210.245.168.28: 1 Time(s) adam/password from 210.245.168.28: 1 Time(s) adm/password from 210.245.168.28: 2 Time(s) alan/password from 210.245.168.28: 1 Time(s) apache/password from 210.245.168.28: 1 Time(s) backup/password from 210.245.168.28: 1 Time(s) cip51/password from 210.245.168.28: 1 Time(s) cip52/password from 210.245.168.28: 1 Time(s) cosmin/password from 210.245.168.28: 1 Time(s) cyrus/password from 210.245.168.28: 1 Time(s) data/password from 210.245.168.28: 1 Time(s) frank/password from 210.245.168.28: 1 Time(s) george/password from 210.245.168.28: 1 Time(s) henry/password from 210.245.168.28: 1 Time(s) horde/password from 210.245.168.28: 1 Time(s) iceuser/password from 210.245.168.28: 1 Time(s) irc/password from 210.245.168.28: 2 Time(s) jane/password from 210.245.168.28: 1 Time(s) john/password from 210.245.168.28: 1 Time(s) master/password from 210.245.168.28: 1 Time(s) matt/password from 210.245.168.28: 1 Time(s) mysql/password from 210.245.168.28: 1 Time(s) nobody/password from 210.245.168.28: 1 Time(s) noc/password from 210.245.168.28: 1 Time(s) operator/password from 210.245.168.28: 1 Time(s) oracle/password from 210.245.168.28: 1 Time(s) pamela/password from 210.245.168.28: 1 Time(s) patrick/password from 210.245.168.28: 2 Time(s) rolo/password from 210.245.168.28: 1 Time(s) root/password from 210.245.168.28: 59 Time(s) server/password from 210.245.168.28: 1 Time(s) sybase/password from 210.245.168.28: 1 Time(s) test/password from 210.245.168.28: 5 Time(s) user/password from 210.245.168.28: 3 Time(s) web/password from 210.245.168.28: 2 Time(s) webmaster/password from 210.245.168.28: 1 Time(s) www-data/password from 210.245.168.28: 1 Time(s) www/password from 210.245.168.28: 1 Time(s) wwwrun/password from 210.245.168.28: 1 Time(s) Regards, Dan
Current thread:
- SSH scans... Dejan Markovic (Dec 20)
- Re: SSH scans... Harald Nesland (Dec 20)
- RE: SSH scans... another possible solution Ron Moore (Dec 20)
- Re: SSH scans... Dejan Markovic (Dec 20)
- Re: SSH scans... Barrie Dempster (Dec 20)
- Re: [incidents] SSH scans... Tim Kennedy (Dec 20)
- Message not available
- Re: [incidents] SSH scans... Tim Kennedy (Dec 20)
- Message not available
- Re: SSH scans... Harald Nesland (Dec 20)
- Re: SSH scans... Keith Morgan (Dec 20)
- Re: SSH scans... Gerry Dalton (Dec 20)
- Re: SSH scans... Peter Willis (Dec 20)
- Re: SSH scans... skippy1 (Dec 21)
- Re: SSH scans... Peter Willis (Dec 20)
- Re: SSH scans... Raymond Lillard (Dec 20)
- Re: SSH scans... Ben Nelson (Dec 20)
- Re: SSH scans... Steve Kemp (Dec 20)
- RE: SSH scans... KEM Hosting (Dec 21)
- Re: SSH scans... Michael H. Warfield (Dec 21)
- Re: SSH scans... nixsec (Dec 22)
- Re: SSH scans... Dejan Markovic (Dec 22)
- <Possible follow-ups>
- re: SSH scans... brian () ethernet org (Dec 21)
- re: SSH scans... Kerry Thompson (Dec 22)
