RE: Publishing Nimda LogsFrom: Steve Zenone (Zenone@cats.ucsc.edu)
- Previous message: Thomas Frerichs: "Re: Publishing Nimda Logs"
- In reply to: Mally Mclane: "Re: Publishing Nimda Logs"
- Next in thread: E: "Re: Publishing Nimda Logs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Steve Zenone" <Zenone@cats.ucsc.edu> To: <INCIDENTS@securityfocus.com> Date: Wed, 8 May 2002 11:48:27 -0700
Mally Mclane wrote:
|9 times out of 10, if you want contact information, the RIPEdb will supply
|*correct* contact information. And email@example.com will *always* try to help
|you out if you don't get correct contact information.
I agree - I've had fairly decent luck with firstname.lastname@example.org. 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 email@example.com`) 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).
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