Re: "Who else picked this one up?"

["R. DuFresne" <dufresne () sysinfo com>]

You are planning on building a database that only logs those scanning
ports that are commonly explored poking for the existance of BO, and only
those ports, yes?  And there are no other scanners out there but the ones
the script kiddies use that test such ports?  Well, none but those that
IRCOPs out to help folks have been using, so all networks on ISP's that
host and or allow IRC to their users will be excluded?  And you will
filter out those testing new security scanners, so as to not put their
names on a potential future 'blacklist' also.  And those just testing
scanners, to get a feel for the SW just brought up, those door knockers
just testing, they will not muddie up the waters too much, will they?  The
NFR SW also, knows how to track down spoofed scans, so as to not logs the
database with false info <I have not looked at it here yet>?  No one is
going to be logging other ports scanned, so, that eliminates those
knocking doors to locate and document broken networks, right?

What I'm saying here is that there are a few large problems that have been
touched on;

1)  Data, what is being measured, and what is the true validity of what is
being measured.

2)  The large tendency for abuse, of the collected 'data', and the abuse
of flooding and loading the database once it is made public that it
exists.

Even if #1 is surmounted,  do we trust even the 'whitehats' to handle a
list such as this and use the information only for reporting and to
support the 'security of their own positions'.  Once the data is abused,
and others are suffering from it's existance, then those guarding and
distributing the information will be charged with establishing an
*internet court* so to speak, so the 'offenders' can show that they have
paid for their 'crimes' and closed the holes, so that they can again
become good netizens again?

I must be missing something, I have been busy, so, perhaps I have missed
the real meat of this thread...

Thanks,

Ron DuFresne

On Fri, 30 Apr 1999, Marcus J. Ranum wrote:

> Paul Robertson writes:
> > A hashed IP address isn't going to be really useful as a cover if it's 
> > easily recreated, and not so useful as a tool if it isn't.  I'd rather 
> > see heavy disclaimers that packets may be spoofed and real addresses.
>
> True. This is a Hard Problem(tm) - I was toying with 3 choices:
>       1) Send up hashed addresses
>       2) Send up keyed hashed addresses
>       3) Send up actual addresses
>
> Hashed addresses has the advantage that we're not publishing a
> "black list" of addresses. It has the disadvantage that someone
> can pretty easily brute force the hashes.
>
> Using keyed hashed addresses has the advantage that only the
> person who submits the address can verify that it matches
> previous/other entries. So groups of network managers who are
> cooperating could share the keys and generate useful information
> without sharing it. It has the disadvantage that correlation
> across addresses would then be impractical/useless.
>
> Using the actual addresses has the advantage of simplicity
> and functionality. It has the disadvantage of becoming a
> potential "black list" and/or legal/privacy problem. I agree
> with Paul that putting heavy disclaimers around the
> database would be a sensible precaution, but I don't want to
> trust people's ability to read disclaimers.
>
> > The important issue IMO is in the reporter's validity.  That's a tougher 
> > nut to crack, but should probably be a longer-term goal.  Victim data is 
> > going to be more difficult to get from everyone than attacker data.  
>
> I figured that the way to crack the reporter validity problem is
> to rate reporters to different degrees of trustworthiness. We'd
> support an authenticated/encrypted record submission approach
> as well as an anonymous one. Authenticated records would be
> rated as "more reliable" and some of them (based on knowledge
> of the individuals or organizations involved) might get additional
> ratings. I'm still at the "scratching my head" phase of this
> part of the problem. :) But I think it might work. If the script
> kiddies decided to "pack" the database it'd be easy enough to
> simply "reduce" the database to tiers of "trustworthiness" and
> treat that data as "FYI" instead of fact. But that raises the
> problem of disclaimers and getting people to read them.
>
> > How do you envision using the data, and how much of it (if any) should be 
> > blind analysis?
>
> Well, that's the _really_ interesting question!!!
> What could this data be used for?
>
> First off, it'd be the first attempt I know of to quantify
> the level and rate with which corporate and personal sites/systems
> are scanned by "vulnerability assessment" tools (hacker tools)
> or "illustrate problems with windows security" tools (hacker tools).
> The information there could make for some interesting studies.
> Are web sites (like where you work, Paul...?) scanned more often
> than personal systems? How often are cable modem pools scanned,
> versus dialups? Are the scans being conducted from within the USA
> or outside? What countries are most popular? Are the time-of-day
> patterns or is the activity constant? Does scanning activity
> fluctuate with school schedules/college schedules? What percentage
> of scans appear from ISPS? What percentage of scans appear from
> corporate sites?
>
> It might be very interesting to see what ISPs are the main sources
> of "incidents" and forward the information to them. Perhaps
> automatically. :)
>
> It might also make a worthwhile data set for folks to use for
> calibrating anomaly detection systems. I suspect there are
> researchers who could have fun with such a database.
>
> It might make some useful data for getting corporate management
> and ISP management and maybe even Feds to realize that, yes,
> Dorothy, there is a problem. It might make useful data for
> convincing people that dial-up is not secure. It might make
> useful data for convincing cable service providers to think
> about designing their crap better.
>
> It might make beautiful artwork, if you rendered a 5-hour
> segment of the probes originating from a specific ISP on top
> of Cheswick's Internet Maps. :)
>
> It might serve as "probable cause" for cops to bust script
> kiddies who spend all day scanning networks for Back Orifice.
> BackOfficer Friendly has already scored a few hacker-kills
> this way, according to a few cops I gave early versions to.
>
> > > Anyone got thoughts they'd like to share about some of the
> > > information that might be worth gathering? We thought we'd
> >
> > Originating AS of the apparent source of the packets.  It's time to start 
> > dragging providers into the mess in some tangenital way.  If there are 
> > highly abusive networks, then that issue needs to be raised with those 
> > network operators.
>
> Yep. It'd be _tempting_ to black hole them but I don't think
> it's time (yet) for Internet vigilatism. _Yet_. We can't, _yet_
> because we don't have good enough data to justify vigilantism.
>
> > Time both local and zulu (GMT) would also be good for overall trending.  
>
> Good point. I figured we'd have the client submit its idea of the
> time (and timezone) when it uploads records. Then we could use
> patented subtraction technology to adjust the times.
>
> I also was thinking that the source of the data records would
> be optional. A site uploading records could upload them with
> its "tagged" addresses, or keyed hashes of the tagged addresses.
> That wouldn't show up in the database for query, it'd just be
> recorded by unique site ID.
>
> Still "scratching my head" over this stuff. Ches wanted to do
> this kind of thing back in (hmm, 1992, I think it was) but
> we never got around to it. He wanted to share syslogs. I never
> figured out what I'd do with the information. Now that I'm
> working on intrusion detection I'm starting to get ideas of
> what to do with the information. :)
>
> mjr.
> --
> Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
> work - http://www.nfr.net
> home - http://www.clark.net/pub/mjr

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior consultant:  darkstar.sysinfo.com
                  http://darkstar.sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!