What to do with your hack attack server logs

Internet | Accountability
Following is a bunch of hack attacks against my server which are trying to exploit the problem identified by the Computer Emergency Reponse Team (CERT) as CA-2003-09 Buffer Overflow in Core Microsoft Windows DLL (also see its CVE entry)

Essentially, my access logs fill up with lines like “SEARCH /x90x02xb1…” (for 32,000 characters), and my Apache configuration has proved very stubborn in filtering them out automatically. So it’s a bit annoying. Plus I don’t like 32KB getting sent to my server unsolicited, in much the way that spam is.

My guess is that most of these attacks occur as a result of the host machine being compromised, instead of malice on the part of the host’s owner. What’s pretty dumb about this attack is that it blabs too much; it tries to attack non-Microsoft servers which are unaffected by it.

I’ve notified my network provider (Speakeasy) about the attacks coming from addresses in their network (66.92.*). All but one of the attacks come from the 66.* network, which probably just reflects that the worm limits its scanning to 16million hosts on its Class A network. How awfully polite.

What I’d really like to just enter in the other IP onto a website, and have somebody else take it from there. That is, the network provider would be alerted that a host on their network was launching attacks. Also, people who hav computers on the Internet with static IP addresses should periodically check this list to see whether they’re on it; this can be automated. (Indeed, the Composite Block List and the Exploits Block List do this for exploits related to spam.

April 19th update: I got about 15 hits in the last three days as a result of Google searches– amazing, considering that it’s the 59th link which comes up under a search for “request failed: URI too long”. That’s right, #59. I guess a lot of people were unsatisifed with the previous 58. Reading many of those results of that search, it turns out that nobody has the answer for how to direct Apache 1.3.28 to stop logging this crud in the access logs.

I’ve moved the access logs to this file, which I shall update cron-ically. This may lower the Google PageRank for this page. On the other hand, it’s going to serve as a resource for my ISP (or anybody else) to see what machines are hit with the worm. Speakeasy wrote back to my original report, and asked if I could paste the information into an email or into the support ticket, and could I include the source IP and port, destination IP and port, yada yada. Like I have time. Like that would stop the problem. What I offer here is a more sustainable approach to the problem.