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.
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
Gadi Evron wrote:
Other solution: disable IPv4 SSH and enable the IPv6 one, no scanning on
that planeYet.
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 planeYet.
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?
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.
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?
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
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.
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.
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
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?
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?
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
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
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 portsIf 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