RE: Possible method to prevent spread of CodeRed and other simila r wo rms

["McCammon, Keith" <Keith.McCammon () eadvancemed com>]

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.goldsmith () intelsat com [mailto:dave.goldsmith () intelsat com]
> Sent: Wednesday, August 01, 2001 1:48 PM
> To: incidents () securityfocus 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