Nice idea, Dave. BUT, if you are going to go to the trouble of blocking outbound TCP/80 at the router, why not just go ahead and patch the server? After all, you'd have to write a rule that enumerates the specific IPs of your web servers, so that means that you know what web servers are behind you, and that means that you should have some means to patch them. However, long-term this is a good idea and fits into the layered defense model. Appropriate egress filtering can be used to guard against future malicious code that attacks web servers from other web servers like Code Red does. Marc -----Original Message----- From: dave.goldsmithat_private [mailto:dave.goldsmithat_private] Sent: Wednesday, August 01, 2001 1:48 PM To: incidentsat_private Subject: Possible method to prevent spread of CodeRed and other similar wo rms I mailed this earlier today but got a message that the incidents mailbox was disabled so I am resending it. Obviously firewalls, screening routers and whatever other tools people use to guard their networks are configured to allow INCOMING connections from the Internet to be initiated to their public web servers. The web server then responds and while the session exists, two way traffic is exchanged. Is there normally any reason for a web server to initiate OUTBOUND connections to the Internet? If not, why not block such outbound packets? The primary reason that I can think of for a web server to initiate Internet traffic is if a system administrator is upgrading software and trying to retrieve software patches from the Internet. Usually, you could access those files from a local network server or transfer the files via flopy/CD or other media. If an IIS (or any other) web server were to become infected with a worm that then tried to spread, that system would be blocked from sending out viral traffic. Flaws, glaring omissions, or a good idea? Dave Goldsmith ############################################################ This email message is for the sole use of the intended recipient(s)and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Intelsat, Ltd. and its subsidiaries. ############################################################ ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 11:34:49 PDT