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