RE: ssh and ids
From: Drew Copley (dcopley_at_eEye.com)
Date: 06/22/04
- Previous message: Adam Powers: "Re: ssh and ids"
- Maybe in reply to: Runion Mark A FGA DOIM WEBMASTER(ctr): "ssh and ids"
- Next in thread: David W. Goodrum: "Re: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Jun 2004 12:50:23 -0700 To: "Adam Powers" <apowers@lancope.com>, <Peter_Schawacker@NAI.com>, <focus-ids@securityfocus.com>
> -----Original Message-----
> From: Adam Powers [mailto:apowers@lancope.com]
> Sent: Tuesday, June 22, 2004 6:42 AM
> To: Peter_Schawacker@NAI.com; focus-ids@securityfocus.com
> Cc: mark.runion@us.army.mil
> Subject: Re: ssh and ids
>
> Hey Peter, my concern here is that your response covers an
> incredibly narrow
> range of encryption attacks. This kind of technology only
> protects known
> encryption channels in which you have (and can actually
> manage) the private
> key of the web server.
>
> You guys definitely get an A for effort, don't get me wrong! Doing
> decryption and inspection on the IDS itself is interesting,
> but I have a few
> questions....
>
> 1. How many keys can be stored and utilized at once?
> 2. This really only works for inbound attacks over SSL
> traffic. What about
> the dozen or so other popular encryption technologies a
> hacker might select
> for his/her covert communications (after all, this was the
> poster's original
> question)?
> 3. How fast? Performance for an SSL accelerator is usually measured in
> session per second, how does Intrushield look in this department?
> 4. Why would a hacker use the web server's private key to
> encrypt his / her
> communications?
>
> IMHO, this kind of technology adds more of a convenience factor than
> anything. It doesn't solve any new problems nor does it help
> with other
> encrypted attack vectors other than SSL.
It is mostly a convenience, however I might note... I worked with a
very large team of security researchers and developers over a period
of several years to come up with "firewall bypassing" utilities to
help ensure "free internet" in restricted nations like China and
Saudi Arabia... we eventually bypassed ideas such as complicated
steganographical network traffic methods and settled on simple
SSL traffic. Ala, "6/4" and "Peekabooty", both of which applications
we designed.
(Granted, my own solution was to utilize stegangraphy, and I do
believe most really advanced attackers would likely use steganography
for trojan communication traffic... regardless, most would come
to the same conclusions we did... over extremely unique potential
channels such as Freenet...)
This said most such applications would be using custom keys... though
a very popular route - very easy, very available - is using the
available keys for simple SSL cgi type proxying... say, a worker
wants to browse porn at work, or a worker wants to make some
extra money selling secrets, or a worker wants to have potentially
damaging conversations online while at work... such people would
be more inclined to using a free chi based SSL proxy then installing
their own covert communication channel.
As most attacks are from insiders, this does remain a viable
potential solution.
>
>
>
> On 6/21/04 10:44 PM, "Peter_Schawacker@NAI.com"
> <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_t
> h_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
> >>
> >>
> >>
> ----------------------------------------------------------------------
> >> -----
> >>
> >>
> ----------------------------------------------------------------------
> >> -----
> >>
> >
> >
> >
> >
> --------------------------------------------------------------
> ----------
> > ---
> >
> >
> --------------------------------------------------------------
> ----------
> > ---
> >
>
> --
>
> Adam Powers
> Senior Security Engineer
> Advanced Technology Group
> c. 678.725.1028
> o. 770.225.6521
> f. 770.225.6501
> e. apowers@lancope.com
> AOL IM: adampowers22
>
> StealthWatch by Lancope - Security through network intelligence
>
>
>
> --------------------------------------------------------------
> -------------
>
> --------------------------------------------------------------
> -------------
>
>
---------------------------------------------------------------------------
---------------------------------------------------------------------------
- Previous message: Adam Powers: "Re: ssh and ids"
- Maybe in reply to: Runion Mark A FGA DOIM WEBMASTER(ctr): "ssh and ids"
- Next in thread: David W. Goodrum: "Re: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
