Dave,

This is a great idea. Funny thing is that just about any responsible
network engineer already does this with a firewall or access list:

INBOUND
access-list 112 permit tcp any gt 1023 host X.X.X.X eq 80
access-list 112 permit tcp any gt 1023 host X.X.X.X eq 443

OUTBOUND
access-list 113 permit tcp host X.X.X.X eq 80 any established
access-list 113 permit tcp host X.X.X.X eq 443 any established

The problem we have, you see, is that there seems to be a *ridiculous* lack
of responsible network/systems/security engineers, as evidenced by this
silly-a** worm.

Cheers!

Keith

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