OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Sebastian Ip (9sckiqlink.queensu.ca)
Date: Wed Aug 01 2001 - 22:12:23 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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.goldsmithintelsat.com [mailto:dave.goldsmithintelsat.com]
    > Sent: Wednesday, August 01, 2001 1:48 PM
    > To: incidentssecurityfocus.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