Re: Publishing Nimda Logs == BAD IDEA

From: Deus, Attonbitus (Thor@HammerofGod.com)
Date: 05/09/02 

Date: Thu, 09 May 2002 10:03:54 -0700
To: Dug Song <dugsong@monkey.org>, incidents@securityfocus.com, vuln-dev@securityfocus.com
From: "Deus, Attonbitus" <Thor@HammerofGod.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 11:27 AM 5/8/2002, Dug Song wrote:

Not withstanding the veneration with which I hold you and your
accomplishments, I would like to make some counterpoints:

>we will NOT, however, be publishing a comprehensive list of infected
>IPs (we have over 5 million of them, since September 2001). here are
>the reasons why:
>
>1. such a list would be useless to the general public. NOBODY in their
> right mind would try to block all the individual IPs in such a
> list, for they change far too much, and are far too widely
> distributed to effect useful filters. these worm infection attempts
> are more of a nuisance than a threat to sites that would actually
> block them, anyway - so the ORBS/RBL analogy is pretty weak.

I don't recall the entire list blockage being proposed... Administrators
would be able to choose relevant netblocks to selectively act upon, and the
entire process could be easily automated. And while I agree that those
with the security mind-set required to know of the list and how to use it
would already be secured against the attack, I believe that the posture of
avoidance is stronger than that of defense. People would at least have a
choice of if and when they wanted to use the information. In this case, it
would be better to have the information and not need it than to need the
information and not have it.

>2. such a list would only benefit remote attackers. because Nimda is
> fairly localized (it only attempts a completely random jump 1/4 of
> the time), many of its infected hosts are actually out of the
> purview of many attackers (at least, those that aren't on cable
> modems themselves in 24/8). by publishing a list of Nimda hits
> you've seen, you're basically handing out a map of the vulnerable
> houses in your own neighborhood, inviting trouble (do you really
> want your local bandwidth to be wasted on massive DDoS floods?).

You are not evil, and you are not malicious, yet you have still collected
over 5 million infected IP's. Logic dictates that those who are evil and
malicious, and who place a much higher value on that information, would
have done the same. The future theoretical threat of a DDoS is mitigated
by the fact that the sources for such an attack would have already been
blackholed by those who chose to do so. Additionally, if an flood were to
occur, the aggregate information would have already been compiled, and
could be easily assembled by the ISP or admin to block the attacks as
opposed to building that data on the fly.

You already know what machines are attacking the rest of us, yet will not
publish that information based on the presumption that those with malicious
intent do not already have the information, and once they do, they will use
the information to make the machines that are already attacking us attack
us. I disagree with that logic.

>3. to clean things up, we (as a community) need to act in a
> coordinated fashion. if you have your own lists of infected hosts,
> please, send them to your local CERT to deal with. why bother with
> tracking down contacts for thousands of IPs yourself? let someone
> else deal with the bureaucracy, that's what they're there for.

If they were dealing with it appropriately, this thread would not have
started. The fact is that we are still under constant attack, and after
all the press, all the bulletins, and all the fury of activity surrounding
the publication of this information and the education of the user, it is
not working. Not only can I not count on other administrators to properly
set up their boxes, but I can't count on CERT to tell the ISP about it, and
I can't count on the ISP to take any further action. I can count on a Perl
script to blackhole someone.

What would be immensely valuable would be for you to offer a sign up option
where you can verify my contact information, and allow me to pull IP's for
my netblocks from your massive database in an automated fashion. At least
in this way we can see what will really happen rather than living in theory.

Thanks for your posts, Dug.

AD

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPNqr+ohsmyD15h5gEQLbUgCfYOFROEircDJ9z8sMqhmCfBA9haEAn2tT
BSuJF1dUZaNWk1Qw1+msUtLl
=I37Y
-----END PGP SIGNATURE-----

Relevant Pages

  • Re: Developmental Dictionary Attack
    ... Do you have any idea where people get their lists of common ... use your data gathering method as an input to a real world attack. ... high security systems can have physical lockouts, ... word dictionaries aren't too unusual for this) and then you iterate ...
    (sci.crypt)
  • Re: Why misc.survivalism should keep on talking about _THREAT MODELS_
    ... threat models and how to deal with them. ... big attack - the one we won't recover from. ... participants to do a smallpox vaccine study, ... you have done the same with your "lists". ...
    (misc.survivalism)
  • Re: Agendas
    ... and uses falses identities like ianhillsmith to attack ... copies stuff from all over for your postings. ... One who sets up blogs and mails to lists about how evil and horrible ... exist as long as yahoo groups and usenet groups have online archives, ...
    (sci.astro.amateur)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... the update server (just from traffic, if not direct attack) and the ... My prediction was that malware would entrnch itself within core code, ... doesn't seem to have arisen yet - i.e. infection within core code. ... >> network. ...
    (microsoft.public.security)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... the update server (just from traffic, if not direct attack) and the ... My prediction was that malware would entrnch itself within core code, ... doesn't seem to have arisen yet - i.e. infection within core code. ... >> network. ...
    (microsoft.public.security.virus)