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.goldsmithat_private [mailto:dave.goldsmithat_private] >Sent: Wednesday, August 01, 2001 1:48 PM >To: incidentsat_private >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
This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 12:14:09 PDT