Security Incidents mailing list archives
RE: Possible method to prevent spread of CodeRed and other simila r wo rms
From: "McCammon, Keith" <Keith.McCammon () eadvancemed com>
Date: Wed, 1 Aug 2001 14:33:50 -0400
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
Current thread:
- RE: Possible method to prevent spread of CodeRed and other simila r wo rms Sachs, Marcus (Aug 01)
- <Possible follow-ups>
- RE: Possible method to prevent spread of CodeRed and other simila r wo rms Frank Knobbe (Aug 01)
- RE: Possible method to prevent spread of CodeRed and other simila r wo rms McCammon, Keith (Aug 01)
- RE: Possible method to prevent spread of CodeRed and other simila r wo rms Delaney, Gavin J (EASD, IT) (Aug 01)
- Re: Possible method to prevent spread of CodeRed and other simila r wo rms Sebastian Ip (Aug 01)