for one host, 185,932 ssh dictionary password attacks in one gmt day (and, of course, password login is not enabled). randy
Randy Bush wrote:
for one host, 185,932 ssh dictionary password attacks in one gmt day (and, of course, password login is not enabled).
Partial "solution": rate limit ports to max X (5) new connects per X (60 secs) time. Et tada, almost not to be seen any more. Misc Linux-based example: http://unfix.org/~jeroen/archive/rc.ratelimit Also possible with your favorite BSD and other OS's... Limiting port 25 also helps with those annoying bots around the net. Other solution: disable IPv4 SSH and enable the IPv6 one, no scanning on that plane ;) Greets, Jeroen
Other solution: disable IPv4 SSH and enable the IPv6 one, no scanning on that plane ;)
Yet. -- My blog: http://blogs.securiteam.com/?author=6 "The third principle of sentient life is the capacity for self-sacrifice --- the conscious ability to override evolution and self-preservation for a cause, a friend, a loved one." -- Draal, "A Voice in the Wilderness", Babylon 5.
Gadi Evron wrote:
Other solution: disable IPv4 SSH and enable the IPv6 one, no scanning on that plane ;)
Yet.
Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently. It's easier & faster to google or use logs* for working hosts ;) Greets, Jeroen * = maybe RFC3041 does have a use as that makes these IP's 'random' and thus sort of useless unless one attacks directly...
Jeroen Massar wrote:
Gadi Evron wrote:
Other solution: disable IPv4 SSH and enable the IPv6 one, no scanning on that plane ;)
Yet.
Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently.
It's easier & faster to google or use logs* for working hosts ;)
Greets, Jeroen
* = maybe RFC3041 does have a use as that makes these IP's 'random' and thus sort of useless unless one attacks directly...
Not to start a huge pointless discussion, but I have a few thoughts on this: You don't have to scan an entire /64 ( :) ). You can sniff network traffic and see what IP addresses you see, then scan only close ranges to those. You can create a DB or download one, with addresses of known used spaces. You can throw out thousands of random packets, finding used spaces. You can do a lot of things, some smarter and mathematical, others just sensible. If I could come up with 3 silly solutions in 2 seconds, I bet the Bad Guys will do far better when the time comes, if it ever does. I am of a mind that we need IPv-NEXT-ONE (or whatever) to deal with actual problems before we undertake IPv6, but that's just an opinion and therefore completely wrong. Don't count any of today's trouble out.. even if we all did use IPv6. Besides, with IPv6 it is my understanding we will have far larger issues to contend with. Gadi.
In message <43791C64.4050500@linuxbox.org>, Gadi Evron writes:
You don't have to scan an entire /64 ( :) ).
You can sniff network traffic and see what IP addresses you see, then scan only close ranges to those. You can create a DB or download one, with addresses of known used spaces.
You can throw out thousands of random packets, finding used spaces.
You can do a lot of things, some smarter and mathematical, others just sensible. If I could come up with 3 silly solutions in 2 seconds, I bet the Bad Guys will do far better when the time comes, if it ever does. I am of a mind that we need IPv-NEXT-ONE (or whatever) to deal with actual problems before we undertake IPv6, but that's just an opinion and therefore completely wrong.
Yes. Angelos Keromytis, Bill Cheswick, and I have a paper on this that will be out shortly. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Jeroen Massar wrote:
Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently.
There is no need to scan an entire /64. Lists of known hosts can be scanned for sparse addresses. Lists of known/likely subnets can be scanned for common human numbering patterns (think servers). Chances are good that every IPv6 node that talks to untrusted nodes will end up on one or more 31337 host lists. - Kevin
Hi, NANOGers. Efficient or not, we do see scanning activity on IPv6. We've seen IPv6 botnets, compromised hosts on IPv6 used as IRC bounces, and even one EU-based warez crew that enabled IPv6 tunnels on the hosts they compromised. They used the IPv6 tunnels as their management plane. While IPv6 obviously presents a huge address space, the miscreants don't have to scan all of it, or compromise much more than a few devices on it, to reap a reward. Just enough is good enough. I'll take a pina colada anyway. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently.
i am in hawai`i, but don't do alcohol. and they don't need to scan, hosts leave ip fingerprints all over the net. look at the received headers of this message. randu
Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently.
google/altavista/excite/etc are incredibly useful for gathering target lists, even for ipv4. if you truly believe ipv6 is a magic bullet which will stop scanning, i have a bridge to sell you. -Dan
for one host, 185,932 ssh dictionary password attacks in one gmt day (and, of course, password login is not enabled). Partial "solution":
it's not a problem, so needs no solution. it was just what i hoped would be a very competitive entry into the "how many useless knocks there have been on your door" contest. randy
Randy Bush wrote:
for one host, 185,932 ssh dictionary password attacks in one gmt day (and, of course, password login is not enabled).
randy
I guess it is. Must be a high performing system :) I have seen many attacks on DSL 1000 MBit and 2000 MBit hosts. Attacks typically lasted 10 minutes. No more than 10 attacks a day. I did not count the passwords - I guess it must have been 250 each. Getting rid of them: Starting sshd from xinetd or inetd. If you have an ol' 386 like me they have already wasted their wordbook before your sshd comes up. Moving sshd from port 22 to port 137, 138 or 139. Nasty eh? Seen no more wordbooks since. Had to by me a dictonary :) I would not dare enabling logins on your system. Kind regards Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
On Tue, 15 Nov 2005, Peter Dambier wrote:
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
Or run two daemons. One on port 22 does not allow ANY logins at all but just tracks incoming connections and attempts (and possibly allows to block-list them in real time - typically not worth the effort though) and another one on some higher port of your choice that is a real sshd daemon for login into your system. -- William Leibzon Elan Networks william@elan.net
william(at)elan.net wrote:
On Tue, 15 Nov 2005, Peter Dambier wrote:
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
Or run two daemons. One on port 22 does not allow ANY logins at all but just tracks incoming connections and attempts (and possibly allows to block-list them in real time - typically not worth the effort though) and another one on some higher port of your choice that is a real sshd daemon for login into your system.
Been doing it this way for some time - 'tis amusing to see them try. It also has the side effect of those that scan for open ports when they find ssh not open tend not to scan for another SSH. / Mat
On Tue, Nov 15, 2005 at 12:01:00AM +0100, Peter Dambier wrote:
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
don't do that! Lots of (access) isps around the world (esp here in Europe) block those ports (in and out), so if you ever need emergency access to your system from a network you don't know, you'll find yourself blocked. Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
don't do that! Lots of (access) isps around the world (esp here in Europe) block those ports
If you're going to move sshd somewhere else, port 443 is a fine choice. Rarely blocked, rarely probed by ssh kiddies. It's probed all the time by malicious web spiders, but since you're not a web server, you don't care. R's, John
John Levine wrote:
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
don't do that! Lots of (access) isps around the world (esp here in Europe) block those ports
If you're going to move sshd somewhere else, port 443 is a fine choice. Rarely blocked, rarely probed by ssh kiddies. It's probed all the time by malicious web spiders, but since you're not a web server, you don't care.
Except if you're running a version of OpenSSL that has a vulnerability, you could be inviting trouble - particularly with kiddies scanning for Apache with vulnerable versions of OpenSSL attached by way of mod_ssl etc... Regards, Mat
Matthew Sullivan <matthew@sorbs.net> writes:
John Levine wrote:
Moving sshd from port 22 to port 137, 138 or 139. Nasty eh?
don't do that! Lots of (access) isps around the world (esp here in Europe) block those ports
If you're going to move sshd somewhere else, port 443 is a fine choice. Rarely blocked, rarely probed by ssh kiddies. It's probed all the time by malicious web spiders, but since you're not a web server, you don't care.
Except if you're running a version of OpenSSL that has a vulnerability, you could be inviting trouble - particularly with kiddies scanning for Apache with vulnerable versions of OpenSSL attached by way of mod_ssl etc...
It's worth noting that while OpenSSH uses OpenSSL for crypto, most of the recent vulnerabilities in OpenSSL do not extend to OpenSSH, because they're in the SSL state machine, not the crypto. -Ekr
participants (13)
-
Dan Hollis -
Eric Rescorla -
Frank Louwers -
Gadi Evron -
Jeroen Massar -
John Levine -
Kevin Loch -
Matthew Sullivan -
Peter Dambier -
Randy Bush -
Rob Thomas -
Steven M. Bellovin -
william(at)elan.net