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

[Sebastian Ip <9scki () qlink queensu ca>]

Not sure if you guys have seen it today but securityfocus had a nice write up 
about "hogwash". Basically a adaptation of snort into a packet scrubber to 
remove known attacks. They had a perfect test agaist the defcon people with a 
default install of redaht 6.2 using this scrubber to stop crackers.

So prehaps we can all start using this. I know eeyes makes a similar product 
for IIS but this protects all servers. Pretty cool stuff!

Cheers

Sebastian Ip


On Wednesday 01 August 2001 15:26, Delaney, Gavin J (EASD, IT) wrote:
> Dave,
> Restricting tcp/port80 initiated outbound connections from the DMZ is an
> reasonable approach.  I'll assume you've group your web server objects
> residing in the DMZ (ex. www_dmz_servers_) so the rule applied to your
> perimeter firewall would be pretty straight forward.  Many large companies
> use a multi-tiered firewall architecture whereby they use a proxy firewall
> for outbound http connections initiated from their trusted network and an
> stateful inspection firewall to handle incoming requests brokered by DMZ
> servers. Many companies also require the installation of site blocking
> software based on policy for connections initiated from their internal
> network. However, individuals that require access to DMZ servers for
> administrative reasons (i.e. log file retention, system patches) could have
> unrestricted browser access to the Internet from these very same DMZ
> servers.  Your approach could also restrict end-around outbound http access
> from the DMZ to the Internet.
>
> Gavin Delaney
>
> -----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 communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, any use, copying,
> disclosure, dissemination or distribution is strictly prohibited. If
> you are not the intended recipient, please notify the sender
> immediately by return email and delete this communication and destroy all
> copies.
>
> ---------------------------------------------------------------------------
> - 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