M$SQL cleanup incentives

William Allen Simpson wsimpson at greendragon.com
Fri Feb 21 22:25:46 UTC 2003


I've been pretty disappointed with some of the responses on this issue. 

Yes, we filter both incoming and outgoing 1434 udp.  No, we cannot keep 
doing that forever, the router CPU utilization is pretty high.  We only 
logged for a couple of hours before turning that off (weeks ago)....

I'm of the technical opinion that everyone will need to filter outgoing 
1434 udp forever.  Yet, since we are (currently) free of infection, 
that's the direction we don't _need_ to filter. 

Now, some folks have expressed the opinion we should just all drop 
filters and let the infected machines DoS our networks, hoping against 
experience that the miscreant customers will notice their bad machines 
and fix them promptly. 

That's technically incompetent! 

For one thing, experience shows that the miscreant won't notice they're 
infected for DAYS!  Why do you think there are 20K+ still infected?

For another thing, I'm happy for all those of you that have such huge 
resources to overspecify your networks and equipment.  The rest of us 
were swamped.  We don't have any (that's right: zero zip nil) M$ 
machines in the operational network (only Linux, *BSD, Macs), and we 
still lost all accounting, network management, and basic services, 
until the border filters were in place.  


Iljitsch van Beijnum wrote:
> Maybe the best approach is to try and deliberately infect the entire
> local net every few minutes or so to detect new vulnerable systems while
> the people installing them are still on the premises.
> 
Gosh, should we do that for every known virus/worm/vulnerability?

Or maybe you don't actually own and/or have legal and financial 
accountability for your own network? 

Is there anybody around here serious about actually cleaning up the 
mess, and thinking of network operational mechanisms to prevent such 
things in the future?
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32



More information about the NANOG mailing list