TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
Kevin,
I am bit confused, how does the Network ICE Guard product determine the
time taken for a RST packet to be sent to terminate an attacker's
connection.. Are you stating that an "out of the box" ISS RealSecure does
not have this capability. On the other hand placing an inline IDS in front
of a ISS RealSecure will lessen the possibility of the ISS RealSecure
engine having to initiate sending a RST packet. But also there are +/-'s
in implementing an inline IDS. Especially if the - is if the inline IDS
determines anamolous behavior (i.e. malicious email that is later on
determined not to be, an overlapped packet,etc, etc)..
/cheers
/m
At 03:47 PM 6/28/2001 -0400, Overcash, Kevin (ISSAtlanta) wrote:
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
>----------------------------------------------------------------------------
>
>The NetworkICE Guard product is an inline IDS system.
>
>http://www.networkice.com/products/blackice_guard.html
>
>Kevin
>-------------------------------------------------------------------------
>Kevin Overcash
>Technical Product Manager - Intrusion Detection Technologies
>Internet Security Systems - www.iss.net
>6303 Barfield Rd.
>Atlanta, GA 30328
>(404) 236-2600
>-------------------------------------------------------------------------
>
>
>-----Original Message-----
>From: Barry Rowe [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, June 27, 2001 12:40 PM
>To: '[EMAIL PROTECTED]'
>Cc: Paul Johnson
>Subject: Time taken for RST packet to terminate attacker's connection
>
>
>
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any
>problems!
>----------------------------------------------------------------------------
>
>Hi all
>
>I had a question posed to me by a prospective client. When I explained the
>RealSecure "Spoofed RST packet" response to the client, he asked: "During
>the time it takes for RealSecure to spoof the RST packet and for the RST
>packet to reach the attacker, how much information or how far can an
>attacker potentially get with their attack?"
>
>I would answer that the RST packet would terminate the connection almost
>instantaneously and that the attacker would get no more than a few more
>packets of communication into the attack. This is a highly speculative
>answer, I'd like to be able to give a more concrete answer. Anyone have an
>opinion on this?
>
>His concern is that even though you reset the connection, there's still a
>certain amount of damage the attacker's going to cause or information
>they're going to gain. He says he's working on Snort in a bridge
>configuration, with all the traffic passing through that bridge and being
>filtered on-the-fly of malicious-appearing traffic. I'd imagine this would
>be incredibly resource-intensive and have a dramatic effect on performance.
>Let's however assume the amount of time for a RST packet to kill a
>connection is sufficient for an attacker to still cause damage and we need
>to set up a more effective response than the RST option (and OPSEC
>reconfiguration of a FW-1 is ruled out as an option), is there any
>RealSecure module made for an "in-line" device which could essentially
>vector traffic passing through it? I'm not aware of any "out-of-the-box" ISS
>option......but perhaps someone has an advanced setup of Server Sensor or
>Network Sensor performing such inline vectoring / vetoing?
>
>Anyone with an answer to my questions?
>
>Kind Regards
>
>Barry Rowe
>e-Security Consultant
>
>Vanco e-Security Limited
>John Busch House, 277 London Road, Isleworth, Middlesex, TW7 5AX, UK
>T: 020 8380 1000
>F: 020 8380 1001
>E: [EMAIL PROTECTED]
>W: www.vanco.co.uk
>
>
>
>****************************************************************************
>*******
>Any opinions expressed in the email are those of the individual and
>not necessarily the company. This email and any files transmitted with
>it are confidential and solely for the use of the intended recipient. If
>you are not the intended recipient or the person responsible for delivering
>it to the intended recipient, be advised that you have received this email
>in error and that any dissemination, distribution, copying or use is
>strictly prohibited.
>
>If you have received this email in error, or if you are concerned with
>the content of this email please e-mail to:
>[EMAIL PROTECTED]
>
>The contents of an attachment to this e-mail may contain software
>viruses which could damage your own computer system. While the sender
>has taken every reasonable precaution to minimise this risk, we cannot
>accept liability for any damage which you sustain as a result of
>software viruses. You should carry out your own virus checks before
>opening any attachments to this e-mail.
>****************************************************************************
>*******
