Re: ssh and ids

From: Tony Carter (tcarter_at_entrusion.com)
Date: 06/24/04

  • Next message: Drew Simonis: "Re: Anomaly Based Network IDS" 
    Date: Thu, 24 Jun 2004 00:16:30 -0400
To: "Thierry Evangelista" <thierry.evangelista@turpial.net>

    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
    >
    >
    >
    > -----------------------------------------------------------------------
    > ----
    >
    > -----------------------------------------------------------------------
    > ----
    >
    >
    >
    >
    > -----------------------------------------------------------------------
    > ----
    >
    > -----------------------------------------------------------------------
    > ----
    >

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

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

  • Next message: Drew Simonis: "Re: Anomaly Based Network IDS"

    Relevant Pages

    • Re: ISA 2004 Server Errors
      ... Tunneling SSL Through a WWW Proxy ... CONNECT is really a lower-level function than the rest of the HTTP methods, ... Through ISA Server ...
      (microsoft.public.isa)
    • Re: RWW with no https
      ... What you cannot normally do is configure an HTTP SSL listeners to redirect traffic based on HTTP headers. ... Or dump Kerio Mail Server since you have the same capabilities in Exchange;-) ... > port but going to port 8080. ...
      (microsoft.public.windows.server.sbs)
    • Re: SSL cert in ISA 2006
      ... protocol (HTTP, SMRP, POP3, IMAP, etc.) to provide session-level encryption. ... What is the purpose of SSL used in ISA for? ...
      (microsoft.public.isa.configuration)
    • Re: Redirect https to http Exchange 2007
      ... I took off require SSL on the /OWA dir and i can get to ... it by http and https, but the redirect to https isnt working if i force ssl ... /OWA vdir but the redirect to SSL isnt working, ...
      (microsoft.public.exchange.admin)
    • Re: ADFS, ISA and SSL offloading
      ... Assuming it is a very short, secure segment between your LB and web server, the risk of running that segment unencrypted is likely be very low but still deserving of caution. ... The other aspect of this is that SSL is not likely to be that big of a deal in terms of absolute performance here, so I'm not sure if you gain much by doing this. ... leave all HTTP on 80 and all SSL on 443. ... ISA is going ...
      (microsoft.public.windows.server.active_directory)