Re: "Who else picked this one up?"

["Paul D. Robertson" <proberts () clark net>]

On Sat, 1 May 1999, R. DuFresne wrote:

> 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

Nobody should be "testing" a scanner against a network I administer 
without my express permission.  The idea that scanning a foreign network 
for potential vulnerabilities without permission is valid behaviour is 
just plain wrong.

> 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

Spoofing is a fact of life on a packet switched network.  Guess what?  
It's a solvable problem if upstreams did source filtering on their 
downstreams and providers did the same.  There's absolutely no impetus 
for anyone to do that at the moment.  So instead of trying to solve the 
problem, we should all just decide that business as usual is ok?  I think 
not.


> 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?

In most of the world, the current situation in Singapore withstanding, 
the only people scanning to "document broken networks" should be the 
network operators of those networks.  This means that they need to know 
they're being abused so that they can start the process of fixing them.  
Notification of apparent sources of packets fulfills that.  If the 
packets are spoofed, then a network operator can filter packets at their 
ingress point to ensure that they're only sourced at legitimate 
addresses.  You don't get that in the current environment.

> 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.

Like anything else, the data measured is what's hitting the networks of 
people wishing to share that information.  In the case of BO, there's no 
legitimate reason for that traffic to hit my networks, so it's either an 
attempt to locate a compromised machine, or it's a spoofed attempt to 
discredit another network.  In either case, the aggragation of my data 
with other people's data means that we can start at the apparent source 
and make some progress.  Right now we have zero progress.

> 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.

How can data be abused?  It's real packets hitting a real network.  
Fortunately, networks aren't transient like customers, so a known 
quantity can be established and metrics given to providers of the data.  
Given logs, a network operator can be responsible about cleaning up 
abuse.  It's the same issue that ISP's abuse departments face every day 
with USENET and SMTP reports.  Spoofing is possible, and network 
operators can mostly determine the validity of a report.  If networks are 
overly abusive, then the rest of the world can agree not to peer with 
them until they solve their problems.  It's the same principle that 
governs USENET, USENET II, and RBL.  Without data there's no way to start 
the process of accountability.  

> 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?

RBL works, UDP works, to some extent UCE reporting works.  Anarchy 
doesn't work because there are too many people willing to victimize others.

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

The meat of this thread is that it's about time that network operators 
started sharing information to prevent attacks and give those responsible 
for going after attackers the data necessary to do so.  They also need 
data to support their positions for deploying defensive systems, and in 
some cases tools to monitor for misbehaviour by their users.

I'd rather focus on abuse of my networks by third parties than abuse of 
any reports of that abuse that I forward.  The truth is that abuse in 
reports can be corroborated once there's an infrastructure in place and a 
reporting mechanism.  Right now, abuse of my network is a stand-alone 
item.  

Ask the folks running the networks that got compromised on Easter 
if they think coordinated reporting could have helped them.  Coordinated 
attacks happen, coordinated defense needs to as well.  Reporting and 
getting a baseline is the start of that process.  There's no 
technological reason not to.  Figuring out margins of error seems to be 
the only thing that isn't exact.  It never will be, that's true of any 
abuse situation.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280