Dave, Restricting tcp/port80 initiated outbound connections from the DMZ is an reasonable approach. I'll assume you've group your web server objects residing in the DMZ (ex. www_dmz_servers_) so the rule applied to your perimeter firewall would be pretty straight forward. Many large companies use a multi-tiered firewall architecture whereby they use a proxy firewall for outbound http connections initiated from their trusted network and an stateful inspection firewall to handle incoming requests brokered by DMZ servers. Many companies also require the installation of site blocking software based on policy for connections initiated from their internal network. However, individuals that require access to DMZ servers for administrative reasons (i.e. log file retention, system patches) could have unrestricted browser access to the Internet from these very same DMZ servers. Your approach could also restrict end-around outbound http access from the DMZ to the Internet. Gavin Delaney -----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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. ---------------------------------------------------------------------------- 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 - 12:58:32 PDT