RE: Publishing Nimda Logs

From: Steve Zenone (Zenoneat_private)
Date: Wed May 08 2002 - 11:48:27 PDT

  • Next message: Mally Mclane: "Re: Publishing Nimda Logs"

    Mally Mclane wrote:
    |9 times out of 10, if you want contact information, the RIPEdb will supply
    |*correct* contact information. And opsat_private will *always* try to help
    |you out if you don't get correct contact information.
    I agree - I've had fairly decent luck with opsat_private 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 ipat_private`) 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:

    This archive was generated by hypermail 2b30 : Wed May 08 2002 - 15:04:59 PDT