Re: ssh and ids
From: David W. Goodrum (dgoodrum_at_nfr.com)
Date: 06/22/04
- Previous message: Drew Copley: "RE: Anomaly Based Network IDS"
- In reply to: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- Next in thread: Thierry Evangelista: "RE: ssh and ids"
- Reply: Thierry Evangelista: "RE: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Jun 2004 13:15:56 -0400 To: Peter_Schawacker@NAI.com
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.pdf
>."
>
>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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
- Previous message: Drew Copley: "RE: Anomaly Based Network IDS"
- In reply to: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- Next in thread: Thierry Evangelista: "RE: ssh and ids"
- Reply: Thierry Evangelista: "RE: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|