[ale] 300,000 failed login attempts in 6 months!!!

[Michael B. Trausch]

On Tue, 2008-08-19 at 19:06 -0400, Forsaken wrote:
> Port scanning an entire netblock for every possible available port
> is  
> a very large increase in scan time (and if your IDS/IPS is any good,  
> chances are it'll notice it). It's not a panacea, but it can buy you  
> some relief from the joyriders unless they're especially bored that  
> night.

No need to scan all 65536 ports.  nmap by default, for example, scans
just over 1,700 of the most frequently used ports on networks.  Odds are
if you're going to be relocating your SSH service in order to get away
from crackers, you're probably going to still be using a port that is
otherwise considered to be "frequently" used---such port numbers are
easier to remember, and generally more accessible.  If you want to get
SSH through a highly restrictive firewall, for example, you can put it
on port 443 or 567, assuming that you do not use those ports for their
intended purposes.

I guess that such people that are looking to get the "low hanging
fruit," as Brian put it, are probably not going to be designing
efficient multithreaded systems to be doing all of this, anyway... not
when they can turn machines into zombies relatively easily, right?

In any case, if you have even just 8k zombies, then scanning an
entire /16 netblock is pretty simple and not very time-consuming... each
host that is worthwhile will complete its scan in roughly 20 seconds,
unless there are a very large number of ports open (and then the alloted
time-out can be adjusted to compensate for the additional time
required).  With 8,000 zombies, spending, let's say, 30 seconds on each
host, scanning 65,025 hosts, can be finished in ~245 seconds---under 5
minutes.  An /8 can be scanned in ~2,073 seconds---just a little over a
half-hour.  Quicker, if hosts are being evasive and time-out on a few
ports, and even quicker if the software is able to detect firewalling,
subnet boundaries, and non-assigned addresses in the pool.

In fact, it'd probably take longer to run the queries to load the data
in the central database than it would to collect the data...

Anyone know what the size of the big botnets are these days?

-- 
My sigfile ran away and is on hiatus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080819/22c494e0/attachment.bin