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

From: dave.goldsmithat_private
Date: Wed Aug 01 2001 - 11:22:15 PDT

  • Next message: Sachs, Marcus: "RE: Possible method to prevent spread of CodeRed and other simila r wo rms"

    Because we can patch the server against known vulnerabilities but it is for
    the unknown, zero-day exploits that blocking outbound initiated connections
    would be beneficial.
    
    R/S, Dave Goldsmith
    
    -----Original Message-----
    From: Sachs, Marcus [mailto:sachsmat_private]
    Sent: Wednesday, August 01, 2001 2:19 PM
    To: 'dave.goldsmithat_private'
    Cc: 'incidentsat_private'
    Subject: RE: Possible method to prevent spread of CodeRed and other
    simila r wo rms
    
    
    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.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 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 archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 11:29:49 PDT