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.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 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 ]