Subject: RE: Anomaly Based Network IDS - msg#00105

Previous Message by Date: click to view message preview

RE: ssh and ids

Great feedback, thanks! Let me extend the question a bit. Are there any solutions that exist that allow a network which already supports an SSH keyed and escrowed infrastructure to allow the IDS platforms access to the relative keys? This might allow the IDS to know and read all authorized traffic on a network while at the same time, leaving the litmus test of "if I can't read it, something is wrong". Does this raise any additional issues? - Mark Runion -----Original Message----- From: Runion Mark A FGA DOIM WEBMASTER(ctr) [mailto:mark.runion@xxxxxxxxxxx] Sent: Friday, June 18, 2004 10:19 AM To: focus-ids@xxxxxxxxxxxxxxxxx Subject: ssh and ids 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 --------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ---------------------------------------------------------------------------

Next Message by Date: click to view message preview

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@xxxxxxx 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@xxxxxxx -----Original Message----- From: Adam Powers [mailto:apowers@xxxxxxxxxxx] Sent: Friday, June 18, 2004 9:29 PM To: focus-ids@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxx> 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 by Thread: click to view message preview

RE: Anomaly Based Network IDS

Hi Drew, I am myself evaluating Mazu's profiler. Don't you think they should do more when it comes to packet inspection . I mean deep inspection and atleast alarm if something is not following published RFCs etc. Shahid -----Original Message----- From: Drew Simonis [mailto:simonis@xxxxxxxxxx] Sent: Friday, June 18, 2004 10:35 AM To: Joe Dauncey; focus-ids@xxxxxxxxxxxxxxxxx Subject: Re: Anomaly Based Network IDS ----- Original Message ----- From: Joe Dauncey Date: Fri, 18 Jun 2004 14:09:08 +0100 To: focus-ids@xxxxxxxxxxxxxxxxx Subject: Anomaly Based Network IDS > Hi, > > I am interested in views on anomaly-based Network IDS. > > ... > > I suppose my defintion of anomaly based is that it discovers attacks based on sampling and analysing > the network traffic and identifying anomalies on the norm, rather than relying on a specific external > signature to tell it what to look for. > > I'm thinking that this would really have to be incredibly sophisticated as it's going to vary for every > network environemtn, and could potentially generate a lot of false positives. > > I'm especially interested in anything that would claim to be able to detect a worm attack (and even > prevent it) without knowing about it already - i.e. through a signature. > You'll want to look at a couple of things. First, there are protocol anomaly IDS, such as Symantec Manhunt. These detect deviations from published RFCs and report on that. They can detect attacks absent a signature, but are prone to false positives. They take some tuning and decently skilled analysts. Second, (and I think what you seem to want) you'll want to look at profiling systems. My favorite is the aptly named "Profiler" by Mazu Networks. It can, as you ask, detect worm activity absent any information, and (a set apart feature from the others in this space, IMO) has a dynamic baseline. I use it, and I like it. -Ds ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- ---------------------------------------------------------------------------

Next Message by Thread: click to view message preview

Re: Anomaly Based Network IDS

I'm not going to get into the semantics of "zero-day" vs. a "day-one" vs. a "well known exploit". As an engineer, I really don't care. At some level, it's all "markitecture". Especially when used on a vendor such as Lancope's website. Lancope's marketing literature stresses the point that a signature database is NOT used to detect attacks. It's that simple. While some attacks will certainly still go unnoticed, many attacks, be they of the "zero-day" or "really old and crusty" type, will be noticed. Understand though that it's the change in network traffic and host activity that is noticed, not the specific exploit. Lancope's StealthWatch technology has no ability to actual name an attack; this is for the sig guys. StealthWatch names the change in behavior... Be it an increase in traffic volume, a change in the number or type of connections, or (as discuss by Marty and me earlier) a change in the services running on a given host, a compromised host almost always exhibits some observable change in it's behavior. The real question is how well does the behavior-based technology detect changes in behavior? And if they even can detect suspicious behaviors, how accurate is the detection capability? As with any network-based system, false positives are always a consideration. In my experience here at Lancope, I can tell you that there are some environments in which these "behavior-based" systems work extremely well out of the box and others in which they work not so well without significant tuning. And BTW: Regarding the overzealous Lancope sales person posting to the forum as "Aaron" or whatever... He will be hung at high noon today. Sorry about that folks. On 6/22/04 2:18 PM, "Drew Copley" <dcopley@xxxxxxxx> wrote: > > >> -----Original Message----- >> From: Aaron Jordan [mailto:aaronj0rdan23@xxxxxxxxxxx] >> Sent: Friday, June 18, 2004 2:14 PM >> To: focus-ids@xxxxxxxxxxxxxxxxx; secdistlist@xxxxxxxxxxx >> Subject: Re: Anomaly Based Network IDS >> >> My company uses Lancope's StealthWatch for anomaly based >> network IDS. We >> are quite pleased with its ability to detect zero-day >> undocumented attacks >> on our network. > > Guys, as a "bugfinder", I have to tell you this... this vendor > is misleading you in regards to "zero day". > > From their site, the first bullet point they have up? > > "Defeat Zero-Day Attacks" > > That is extremely misleading. > > Here's an unbiased article: > Crying wolf: False alarms hide attacks > http://www.nwfusion.com/techinsider/2002/0624security1.html > > But, that guy was not even trying to address a claim like > "defeat zero day attacks". This crafty claim... for one > thing, it is extremely unlikely they have ever even found > one single zero day attack. > > [Unless they count putting in bugs in their own products, > then "finding" it.] > > "Zero Day" attacks... "zero day" means a newly discovered > security vulnerability not yet shown to the public. It is > impossible to know what it may be. Anyone that has spent much > time looking at past security bugs knows they could be anything. > > "Day One" attacks would involve security vulnerabilities just > released to the public. It used to be something like "Day Forty" > or so that an unknown vulnerability would become a worm. No one > uses this terminology, exactly, and today the time from bug > release to attacks is extremely non-static. > > Very rarely unfixed bugs which have been disclosed through Full > Disclosure have been called - with some right - "zero day". > > The number of actual "zero day" that anyone is actually familiar > with are extremely small. A webdav issue in IIS was being used > against Navy servers early last year. This year a spyware distributor > just of late who obviously bought some zero day and has been > using it. That is about it. > > Obviously, it is very likely that there is some zero day "floating > around"... in fact, every single bug finder that posts to Bugtraq > or Full Disclosure or NTBugtraq has "zero day". > > Because that is what their bugs are before they disclose them to anyone. > > > There is a trend, there are more bugfinders today then there was > yesterday... but when I say "bugfinders" I do not mean "everyday QA". > There > are hundreds, not thousands. And when I say "hundreds", I include > those that do not have much experience and whose skills are > lacking -- but they have potential. > > People can be trained to find security vulnerabilities. An > accomplished assembly language programmer could easily break into > the world of cracking and hacking and learn his way around after > a few years. Very ambitious individuals could learn their way > around. But, the field is well hidden from public view -- the > "script kiddy" is the glamorous hacker of media fame... and even > when one does understand this is the "core", one is a long way > from spending endless nights trying to find a high quality security > bug which has been missed by teams of QA and devel working for > years. > > These things said... someone with a "zero day" attack has an > unknown attack. A "golden key" to the systems, I like to say. There > are possibilities to find large classes of "zero day" attacks. We > do this in SecureIIS and have instituted the same functionality > in our upcoming Blink. We have had a lot of "zero day" with which > to test and design and develop these products. > > Rule based API guards can do a lot to protect against true > zero day attacks. Class based protection schemes can do a lot > against true zero day attacks. More importantly, these schemes > can help secure systems against new variants of known vulnerabilities > including every manner of virus or trojan... which is the most > common type of attack, and therefore, the most plausible. > > It is true the real "nightmare scenarios" of computer security > do involve zero day. There are likely some nightmare scenarios > of this caliber going on right now. I know I am aware of some over > the years. But, these scenarios almost always involve extremely > important "target" systems such as military, diplomatic, primary > routing systems, or extremely senstive corporate systems. > > A very likely scenario, however, is a zero day worm which is > wildly propagated in the next few years... one made by individuals > who really want to destroy systems, like the Witty Worm of late. > > But, this does not remove the fact that you need to be up on > everyday attacks which do not utilize "zero day". > > Merely writing a new trojan or doing a "new hacking attack" is > a far cry from the true and generalized definition of the term > "zero day". If marketers are trying to pass off such definitions > as accurate, they are being highly deceptive. > >> We're easily able to see into our network to >> examine what >> is actually happening on it versus what should be happening on it. >> >> We evaluated a few of the other products in this space and >> decided on this >> one since it was the easiest to use. >> >> --my $.02 >> >> AJ >> "802.3" >> >> _________________________________________________________________ >> Is your PC infected? Get a FREE online computer virus scan >> from McAfee(r) >> Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 >> >> >> -------------------------------------------------------------- >> ------------- >> >> -------------------------------------------------------------- >> ------------- >> >> > > --------------------------------------------------------------------------- > > --------------------------------------------------------------------------- > -- Adam Powers Senior Security Engineer Advanced Technology Group c. 678.725.1028 o. 770.225.6521 f. 770.225.6501 e. apowers@xxxxxxxxxxx AOL IM: adampowers22 StealthWatch by Lancope - Security through network intelligence? --------------------------------------------------------------------------- ---------------------------------------------------------------------------