The other day, I looked carefully at my auth.log (Xubuntu 11.04) and discovered many lines
of the form:
Jun 28 13:13:54 localhost sshd[12654]: Bad protocol version identification '\200F\001\003\001' from 94.252.177.159
In the past day, I have recorded about 20,000 unique IP addresses used for this type of probe.
I doubt if this is a surprise to anyone - my question is twofold:
1. Does anyone want this evergrowing list of, I assume, compromised machines?
2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table? I have done
that and do see a certain amount of repeat hits.
-=[L]=-
Just a note that if you were running fail2ban.org you would get automatic updates of your firewall and share the IPs with the community and get the advantage of the communities detections as well.
You can use fail2ban to block bruteforcing hosts automatically and even report to your mail their whois info
http://www.fail2ban.org/
Hi,
We implemented fail2ban about a year ago to cut down on incoming spamming (down from 500k+ emails a day to 20k)
Now what can I do with the ~11,000 IP's I identify as spammer every week 
Reporting them to their Telco is pretty much a waste of time... they are not about to lose customers to something as trivial as computer security.
Do you need to allow inbound ssh connections from the entire planet?
If not, then head over to ipdeny.com and grab the relevant network
allocations for the countries that you *do* need to allow them from.
Block everyone else, allow only the countries you need.
This won't solve your problem completely, but it'll take a substantial
bite out of it, and it'll minimize the number of additional point entries
that you need for annoying hosts whose connections originate in the
set of countries you need to allow.
Then: do you need to allow inbound ssh connections from all operating
systems?
If not, then use passive OS fingerprinting to block those which originate
from operating systems known not to be in use, particularly if those
operatng systems happen to be the ones running on a few hundred million
compromised systems. (Obviously, this technique is far less effective
is you can't do that. My condolences.)
And then: consider, instead of point blocks for the remaining annoyances,
use the enclosing /24. A lot of compromised hosts are not on static
addresses, and guessing that they will bounce around inside (roughly)
a /24 is often a good enough approximation to reality that it works.
Your mileage may vary.
And then: scotch. Macallan. 18-year. You've earned it.
---rsk