Security Incidents mailing list archives
RE: Publishing Nimda Logs
From: "Steve Zenone" <Zenone () cats ucsc edu>
Date: Wed, 8 May 2002 11:48:27 -0700
Hello, Mally Mclane wrote: |9 times out of 10, if you want contact information, the RIPEdb will supply |*correct* contact information. And ops () ripe net will *always* try to help |you out if you don't get correct contact information. I agree - I've had fairly decent luck with ops () ripe net. A part of the problem, as I see it, is the quantity of systems actively performing NIMDA scans. As already mentioned within this thread, the IDS logs are enormous per day as a result of all of the scans. A large number of the source IPs pull up bogus info when querying the ripe database (e.g., `whois ip () whois ripe net`) and getting results that have email addresses that point to the bitbucket. I am unclear what the most common cause for this is (outdated data within the database?) The other part of the problem has also been brought up is that systems just aren't being patched and/or installed correctly, thus fueling the automated attacks and noise on the networks.
From an incident response standpoint, the load is very demanding as the
number of systems actively performing NIMDA scans grows/continues. What has been frustrating out of all of this is once a correct contact has been established, response has been less than satisfactory. On the positive side, I admit that the percentage of responses from notifications has increased, albeit still small in number. Lastly, the problem with publishing Nimda infected systems is that it would be that much more trivial for an attacker to dump all of that data into an automated tool that would only target those systems (their logs would only show a small subset of the entirety of the list). The damage could be much worse than what we're seeing from Nimda if someone had such intentions. Why provide the reconnaissance? Then again, maybe someone would feed that info into an attack that ends up patching the systems (well, that would probably break a number of systems too, thus causing a DoS - not good). Regards, Steve ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
Current thread:
- Publishing Nimda Logs Deus, Attonbitus (May 07)
- Re: Publishing Nimda Logs Hugo van der Kooij (May 08)
- Re: Publishing Nimda Logs Glenn Forbes Fleming Larratt (May 08)
- Re: Publishing Nimda Logs Rainer Duffner (May 08)
- Re: Publishing Nimda Logs Mally Mclane (May 08)
- RE: Publishing Nimda Logs Steve Zenone (May 08)
- Re: Publishing Nimda Logs Mally Mclane (May 08)
- Re: Publishing Nimda Logs E (May 08)
- RE: Publishing Nimda Logs Benjamin Tomhave (May 08)
- Re: Publishing Nimda Logs John Kristoff (May 08)
- Re: Publishing Nimda Logs jlewis (May 08)
- <Possible follow-ups>
- Re: Publishing Nimda Logs Thomas Frerichs (May 08)
- Re: Publishing Nimda Logs Justin Shore (May 08)
- Re: Publishing Nimda Logs Mally Mclane (May 08)
- Re: Publishing Nimda Logs Richard . Smith (May 08)
- Re: Publishing Nimda Logs Jay D. Dyson (May 09)