Re: ssh and ids

From: David W. Goodrum (dgoodrum_at_nfr.com)
Date: 06/22/04

  • Next message: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
    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
    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------
    

  • Next message: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"

    Relevant Pages

    • Vulnerability in encrypted loop device for linux
      ... An attacker is able to modify the content of the encrypted device ... considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, ... As we need to authenticate the device across mounts and not while it is ... It slows down mount operations but they are ...
      (Bugtraq)
    • [UNIX] Vulnerability in Encrypted Loop Device for Linux
      ... Encrypting a disk device aims to protect against an off-line attacker who ... The encryption mode used by encrypted loop device is CBC. ... We propose 2 types of fixes: one that authenticate at mount time (see ...
      (Securiteam)
    • Re: Question about rsync
      ... The most important aspect of security is improving your weakest links - when you are at the stage that the easiest methodof attack is physical, or personal, then your job as IT security is pretty much done. ... It makes sense to take easy steps to increase security if you can - an attacker might not have the same opinion about the easiest methodof attack as you. ... but it contains information about an algorithm aimed precisely at transferring only those parts of a file that have changed. ... So unless you are doing a backup of a nuclear missile design, encryption on an rsync backup will only make a realistic difference if your network topology is such that the traffic is accessible by more people. ...
      (comp.os.linux.networking)
    • Re: Signatures and encryption headers
      ... breached when an attacker can modify the message received? ... But I see how the lack of authentication can cause the receiver to act ... not for the iv or other encryption ... A create a payload, S signs it with public key crypto (most likely ...
      (sci.crypt)
    • Re: ssh and ids
      ... McAfee's IntruShield network IPS will offer the ability to ... >>new behavioral traffic analysis technologies go a long way toward ... >>solving some of the problems presented by encryption technologies. ... >>the nature of the flows being created by a given network node. ...
      (Focus-IDS)