[unisog] Cleaning up those networks

Michael Hornung hornung at cac.washington.edu
Wed Feb 21 17:55:45 GMT 2007

On Wed, 21 Feb 2007 at 10:02, power less wrote:

|my question is, in general ( I don't know that I personally want to 
|maintain a list of who wants to be notified of things and who doesn't ) 
|do universities want/need to be notified of various detection data that 
|arbitrary people could compile?

Define arbitrary.  If you get hits on hosts you manage then that is not 
arbitrary in my book.  If you're looking up hosts in a DNSBL you don't 
manage and reporting those to the owning institutions, then I believe that 
is arbitrary and not helpful.  I think most places would rather err on the 
side of getting more information about a given threat source than none at 
all, but only from people who were impacted by said threat and can 
contribute detailed and informational trace matter (logs, timestamps, 

|I ask because I wonder if they aren't thinking "geez we certainly don't 
|need to get 5,000 arbitrarily formatted emails about a couple IP numbers 
|that had some dumb worm". Maybe they hear about each thing way more than 
|they need to?

Or maybe everybody who *could* report on the given "dumb worm" chooses not 
to notify on it and then the people have not gotten any help from the 
community and may not be aware of the existence or magnitude of the given 
threat source.

|One thing that I've found out is there's a very distinct nuke the messenger
|probability in notifying people of potential security issues.

Define "potential security issues."  You need to send supporting evidence 
with your claim to demonstrate that the activity in question is indeed 
illegitimate or at the very least is against your host or network's 
acceptable use policies.  People have the right to be rude, but so long as 
you have given them sufficient supporting evidence along with your claim, 
then you have tried to help and if they continue to be offensive you have 
every right to block said host or institution from accessing your 

Perhaps here you're talking about doing a "free of charge, you don't even 
need to ask me" penetration test against a person's computers and then 
sending them your findings.  In that case I would say you are in fact 
doing something wrong unless the target had specifically and clearly 
requested the "help."

|For example what if I detected that some IP ping scanned my subnet and they
|sent a tcp syn to port 22 on one host. If I reported this, in my experience,
|I'd get a reaction that "pings aren't attacks and
|one syn packet is not a scan!." They would not only not want the
|information, but be annoyed they got it. This is because their system is
|optimized for blackholing attackers. (They don't want grayish info in their
|blackhole system.) But what if that report did get to the actual admin of
|the network? It might be useful. They might think "no way that server
|should've been ping scanning someone else's subnet, I never tried to
|connect to that machine with ssh".  So in that case it would be a valuable
|warning to the admin that
|something was going on. I think that's a big problem currently that most
|systems are not even conceptually able to handle "mini info" like that. (
|Also the blackhole solution doesn't deal with subnets that have "gateways"
|in front of them such that all traffic out of there comes from one IP
|number. If the gateway represents for example a plethora of NAT clients, the
|gateway tends to not get blackholed because it's not the "attacker", the
|attacker is some long gone dhcp client, and then it's rather giving the
|effect that that subnet has a license to bug the world. This is the
|unfortunate security downside of NAT.

I can't help but get the distinct feeling that you're talking about a 
specific business or institution in your message.  In my Security 
Operations experience I did not arrive at the same general consensus that 
you describe above.

 Michael Hornung          Computing & Communications 
 hornung at washington.edu   University of Washington

More information about the unisog mailing list