Constant low-level attack
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]=- --
On Jun 28, 2012, at 4:31 PM, Lou Katz wrote:
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.
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.
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. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 06/28/12 17:52, TR Shaw wrote:
On Jun 28, 2012, at 4:31 PM, Lou Katz wrote:
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. 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.
On 2012-06-28 23:31, Lou Katz wrote:
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]=- You can use fail2ban to block bruteforcing hosts automatically and even report to your mail their whois info http://www.fail2ban.org/
--- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
On Thu, Jun 28, 2012 at 01:31:56PM -0700, Lou Katz wrote:
2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table?
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
participants (5)
-
Alain Hebert -
Denys Fedoryshchenko -
Lou Katz -
Rich Kulawiec -
TR Shaw