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: