Re: ssh and ids

[Tony Carter <tcarter () entrusion com>]

Some COTS applications will not work with CertainT type products  
(reverse proxy's with SSL accelerator card) because  features in the  
application redirects http traffic to https. This can obviously be a  
show stopper unless you have access to the application code or can  
convince the vendor to change the code to support http only.

-Tony

On Jun 22, 2004, at 6:27 PM, Thierry Evangelista wrote:

> David,
>
> I've played with CertainT in the past and as far as I remember, the  
> Radware
> box is the termination point of the SSL tunnel. What Peter says is  
> that the
> IntruShield solution is able to analyse SSL flows on the fly and
> *transparently* (which is a big difference, especially when it comes  
> about
> performance).
> My 0.02
>
> Thierry
>
> -----Original Message-----
> From: David W. Goodrum [mailto:dgoodrum () nfr com]
> Sent: mardi 22 juin 2004 19:16
> To: Peter_Schawacker () NAI com
> Cc: apowers () lancope com; focus-ids () securityfocus com;
> mark.runion () us army mil
> Subject: Re: ssh and ids
>
>
> Your claim is only partially true Peter.  NFR has been integrated with
> Radware's CertainT product for quite a while now.  While it's not a
> single box solution, it does work very well, and the solution prices
> very competitively.  We have a number of customers using this solution
> and are very happy with it.
>
> Peter_Schawacker () NAI com wrote:
>
> > Hello Adam,
> >
> > I believe you are correct to say that there are no silver bullets when
> > it comes to detection.  However, I would point out that as of the end
> > of July, McAfee's IntruShield network IPS will offer the ability to
> > decrypt SSL traffic (using the server's private key) and therefore to
> > detect and prevent encrypted attacks against web servers.  To date  
> > this
> > is the first and only network IDS to offer the ability to "pierce the
> > veil" of encryption.  Note that SSL decryption is available in both  
> > IDS
> > and IPS modes.
> >
> > If anybody is interested in the specifics of how IntruShield inspects
> > encrypted traffic there's a white paper available from
> > http://www.nai.com/us/_tier2/products/_media/sniffer/ 
> > wp_encr_th_prot.pd
> > f
> > ."
> >
> > Peter Schawacker, CISSP
> > Technical Evangelist
> > McAfee
> > Office 760 200 4258
> > Mobile 760 880 4258
> > ps () nai com
> >
> >
> > -----Original Message-----
> > From: Adam Powers [mailto:apowers () lancope com]
> > Sent: Friday, June 18, 2004 9:29 PM
> > To: focus-ids () securityfocus com
> > Cc: Runion Mark A FGA DOIM WEBMASTER(ctr)
> > Subject: Re: ssh and ids
> >
> >
> > There is really no one full-proof answer to this question (that I'm
> > aware of). Encryption remains the bane of network-based intrusion
> > detection technologies.
> >
> > At the risk of speaking on behalf of such flow-based vendors as Arbor,
> > Mazu, Q1, and (yes, my personal favorite) Lancope, I think some of the
> > new behavioral traffic analysis technologies go a long way toward
> > solving some of the problems presented by encryption technologies.
> >
> > <light details>
> > By observing the duration of a "flow" (read: a TCP socket or series of
> > related sockets) and the manner in which packets are exchanged over a
> > "long duration" flow, a behavior-based system can pinpoint those
> > connections that seem to be "out of the norm". During the baselining
> > period, a behavior driven system observes connections attributes such
> > as "duration" and "relative connectedness" to gain an understanding of
> > the nature of the flows being created by a given network node. The
> > flow-based, behavior-driven system should have the ability to discern
> > between a AES gotomypc.com connection over TCP 443 and an automatic
> > refresh connection to www.weather.com. The determination that "covert
> > communications" are underway is done not through string matching or
> > protocol anomaly but rather through the analysis of the flow  
> > attributes
> > themselves (duration, packets sent/rcvd, pkt size, etc). Bottoms line:
> > the magic is in the algorithms used to examine header traffic. Header
> > traffic is not encrypted. </light details>
> >
> > The #1 defining attribute of flow-analysis techniques is that they
> > typically DO NOT require use of payload data to determine the presence
> > of an attack.
> >
> > As previously mentioned, there is no fool-proof plan... Flow-based
> > technologies can be tricked... It just requires a much different
> > science than that used by snot, sidestep, or encrypted shell  
> > shoveling.
> >
> > - AP
> >
> >
> >
> > On 6/18/04 2:18 PM, "Runion Mark A FGA DOIM WEBMASTER(ctr)"
> > <mark.runion () us army mil> wrote:
> >
> >
> >
> > > Lets suppose the attacker is mildly sophisticated, and after making
> > > the initial assault roots the box and installs a secure backdoor or
> > > two.  Is there any IDS capable of isolating data it cannot read,
> > > except to monitor authorized port usage of a system or group of
> > > systems?  Not to complicate the question, but when the attacker is
> > > using portal gates and all communications traffic is encrypted in
> > > normal channels how can an IDS participate?  Monitoring normal  
> > > traffic
> >
> >
> >
> > > patterns seems a bit slow for detection.
> > >
> > > -
> > > Mark Runion
> > >
> > >
> > > --------------------------------------------------------------------- 
> > > -
> > > -----
> > >
> > > --------------------------------------------------------------------- 
> > > -
> > > -----
> >
> >
> >
> > ---------------------------------------------------------------------- 
> > -
> > -
> > ---
> >
> > ---------------------------------------------------------------------- 
> > -
> > -
> > ---
> >
> >
> > ---------------------------------------------------------------------- 
> > -
> > ----
> >
> > ---------------------------------------------------------------------- 
> > -
> > ----
>
> --
> David W. Goodrum
> Senior Systems Engineer
> NFR Security
> 703.731.3765
>
>
>
> ----------------------------------------------------------------------- 
> ----
>
> ----------------------------------------------------------------------- 
> ----
>
>
>
>
> ----------------------------------------------------------------------- 
> ----
>
> ----------------------------------------------------------------------- 
> ----


---------------------------------------------------------------------------

---------------------------------------------------------------------------