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.goldsmithintelsat.com [mailto:dave.goldsmithintelsat.com]
Sent: Wednesday, August 01, 2001 1:48 PM
To: incidentssecurityfocus.com
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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]