IDS mailing list archives
Re: ssh and ids
From: Adam Powers <apowers () lancope com>
Date: Tue, 22 Jun 2004 09:41:43 -0400
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. 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_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 trafficpatterns 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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Re: ssh and ids, (continued)
- Re: ssh and ids Gary Flynn (Jun 21)
- Re: ssh and ids Frank Knobbe (Jun 22)
- Re: ssh and ids Bamm Visscher (Jun 23)
- Re: ssh and ids Frank Knobbe (Jun 23)
- Re: ssh and ids Frank Knobbe (Jun 22)
- Re: ssh and ids Gary Flynn (Jun 21)
- Re: ssh and ids Ron Gula (Jun 21)
- RE: ssh and ids Wozny, Scott (US - New York) (Jun 21)
- RE: ssh and ids Omar Herrera (Jun 21)
- RE: ssh and ids Matthew F. Caldwell (Jun 22)
- RE: ssh and ids Frank Knobbe (Jun 22)
- RE: ssh and ids Peter_Schawacker (Jun 22)
- Re: ssh and ids Adam Powers (Jun 22)
- Re: ssh and ids David W. Goodrum (Jun 22)
- RE: ssh and ids Thierry Evangelista (Jun 23)
- Re: ssh and ids David W. Goodrum (Jun 23)
- Re: ssh and ids Tony Carter (Jun 24)
- now SSL and ids ( was Re: ssh and ids ) Jason (Jun 23)
- Re: ssh and ids Martin Roesch (Jun 25)