Port blocking last resort in fight against virus

Jack Bates jbates at brightok.net
Wed Aug 13 15:59:13 UTC 2003


Christopher L. Morrow wrote:

> This is the point, atleast I, have been trying to make for 2 years... end
> systems, or as close to that as possible, need to police themselves, the
> granularity and filtering capabilities (content filtering even) are
> available at that level alone.

I agree with you Chris, but I also believe that temp filters do have a 
role, even at backbones. One of my peers appears to be helping out my 
bandwidth and peer cpus with filtering. Helping people temporarily ease 
massive infection rates is a good thing. My helpdesk has seen 150% 
increase in call volume handling this worm. If I just kick the infected 
user's off the Internet, they don't have a chance to patch and fix their 
system without a) knowing someone who isn't infected that can give them 
the patch on cd or diskette or b) pay a computer tech.

Tomorrow is judgement day for us. EU contact, patch by Friday or have 
the account suspended. All accounts actively sending Friday will be 
suspended. Saturday, there will be no DOS packets from my network. Next 
week is a stage process for allowing user's to get infected that haven't 
patched, but blocking their spreading ability outbound. They'll fix by 
specified time or be suspended. No later than Friday of next week, all 
gateways will be open.

Honestly, it would be nice to offer different classes of service, 
allowing user's that are semi-protected and user's that are free and 
clear. The issue with doing so is dealing with the liability of 
offering protection. Although I've debated allowing for a class that 
supports common blocks in exchange for not immediately suspending 
accounts (due to the fact they'll just get filtered), while full access 
accounts will follow our current policies which entail suspension until 
they are fixed. Ports to filter? (25,135-139,445 to start) Of course, I 
don't have to mention the fun of doing per account class filtering. Fun, 
fun.


-Jack




More information about the NANOG mailing list