Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: IDS Design

  1. #11
    Member
    Join Date
    Sep 2005
    Posts
    77
    Determining/Filtering out false positives is always a major challenge when working with/monitoring IDS's... I'd like to ask everyone else in the forum if they have any good sources that assist with determining them. I once tried to start a thread within a support forum of a specific vendors IDS site that was geared towards identifying common false positives. Unfortunately there weren't many contributors to the forum in general and the thread never took off. I thought it was a good idea though. People could post specific alerts they commonly saw that they deemed false positives and why. Hell.. maybe it could work here?
    %42%75%75%75%75%72%70%21%00

  2. #12
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    The problem is with FP's is that one man's FP is another man's Positive. Each network is different as is the traffic that traverses it. Implementing an IDS is a "hit or miss" affair at best if you just install, update the rulesets and start logging. Tuning your own rulesets is the task of the Snort admin. It's a process of seeing what you get and determining the correctness of the alert by examining the packet data and deciding what is really going on and then disabling or tuning the rule to reduce the FP if it is one.

    To consider a place where "common" FP's can be reported is a little redundant... Each ruleset, (be they proprietary or open source), have a place where you can go to report FP's and have the vendor or community fine tune it or not depending upon the nature of the FP. They are what should be used.

    I have FP's for Edonkey... On an SSL OWA connection in the policy rules. Since I don't manage that server I am still trying to determine whether to tune the rule to exclude the server - not knowing how it is physically secured - or to leave the rule as it is and alter my scripts that pull out the items of interest to ignore the FP's from that server.... I'm still considering what to do.

    You also mentioned placing the IDS just inside the firewall.... [This is a personal preference and not a criticism]. Firstly, that would depend upon the internal network size and internet traffic as to whether you would get too much data... But, that aside... I think you lose a lot by not doing both, an awful lot. Sometimes you can see someone sneaking around out there before they try something. You may not do anything about that snooping - why force them underground - but knowing they are coming is useful. Also, if you only see the filtered traffic then, since it is the nature of an IDS to report but not react, it's all a little late. Seeing the outside traffic may show you attempts that never passed the firewall that might cause you to chose to block the source or whatever.... You can't have too much information... It's how you manage the information that is important for both your defenses and your sanity....
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  3. #13
    Member
    Join Date
    Sep 2005
    Posts
    77
    T.S. -

    Without going too indepth about design, I agree with you in that its better to have an IDS in front and behind the firewall. I suppose I was dumbing it down to a one IDS per client senario and where to put it. With the sensor inside the firewall, you still get to see what makes it in past the firewall and reap the benefits of not having to see a ton of autonomous exploits/scans, worm propogation attempts showing up in your security console (unless they do of course make it past the firewall/gateway). Not to mention, if you see an alert that looks fishy on the LAN, you can easily spot the culprit machine without having to dig out the firewall logs and look for NAT translations.

    But if money isn't scarce, by all means, I would say put one in front and behind. Even enable IPS if feasible. Drop packets at the signature level instead of having to worry about blocking individual IP's or subnets. Granted, that takes quite a bit more tuning, which brings us back to the whole false positive issue. Its definately easier to manage an IPS if you are only looking after few clients.

    In the case of working for an MSSP, and your clientel are almost all in the same industry, it might be easier enabling certain signatures to be blocked and having a standard signature config/image loaded on the sensors. I don't see many legit reasons why banks, hospitals, or credit card companies would need to run P2P applications such as KaZAa or Gnutella

    "You can't have too much information... It's how you manage the information that is important for both your defenses and your sanity"

    *raises Guinness high* I hear ya on that one!

  4. #14

    Caswell

    The Snort book 2.0 and 2.1 Books by Brian Caswell and Jay Beale are great.

  5. #15
    Junior Member
    Join Date
    Feb 2005
    Posts
    26
    Glad I started off a good thread….

    TS – You say one mans false positive is another’s’ positive and but why is this? I can see that most companies would not want Kazaa and all the other P2P apps running, but some might allow it with their policy so we have a difference in acceptable traffic right there and I'm answering my own question…

    But do they have ‘templates’ for IDS systems because surely in this day and age 9 out of 10 corporate networks would have pretty consistent policies?

    You know, no P2P software, no spyware and obviously no malicious traffic?

  6. #16
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    You say one mans false positive is another’s’ positive and but why is this
    Traffic... period. It's different on every network despite the similarity of the apps etc. used in each company. The "perfect" signature is very difficult to write unless the traffic is so simple you could almost watch it go by on the wire yourself. The more complicated the target packet payload, (and the potential that it may be split across packets), the more difficult it is to maintain the accuracy of the signature. As the complexity of the target payload increases the amount of "normal" traffic that inadvertently "collides" with it increases too. While that traffic may not collide head on, (Alert), it is very close. Then it comes down to the myriad of settings etc. on the individual network that alter packet data slightly... Pretty soon, a sig that functions perfectly on 1000 other networks, is firing alerts in the hundreds or thousands on your network. For example... The eDonkey alerts over my SSL OWA connection. How could that happen? The traffic is encrypted - yet, when this _one_ user SSL OWA's from his home I get a stream of eDonkey Alerts for the entire period he is connected. The way I see it is that it must be the "keepalive" packets - I haven't bothered to sniff it yet because I pretty much understand the nature of this beast. The keepalive must contain some kind of session key or something that varies from user to user - it must, I don't get the alerts from anyone else. Unfortunately, this user's key triggers the eDonkey Alert. A perfect example of a rule becoming more complex that, under the correct circumstance, will collide with benign data for no good reason.

    Am I going to remove the rule? No. Am I going to exclude port 443? Certainly not. We already decided I'm not excluding the server.... So I either alter my logging analysis scripts or live with them... Right now I'm living with them.... But, for me to report this anomoly anywhere would be a waste of everyone's time. It might be a fun academic exercise to try to fine tune the rule to exclude my particular circumstance - but, in all likelihood it will force the rule to collide elsewhere on someone elses network with some slightly different traffic.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  7. #17
    Member
    Join Date
    Sep 2005
    Posts
    77
    I agree for the most part with TigerShark about false positives. With so many different network architectures out there, with countless different configurations, servers, applications running...etc.
    I can see the potential for there being countless false positives. Regardless, a forum or database listing IDS alerts where people can submit their determined false positives and supporting reasons might prove useful to some people.

    Example of some alerts I commonly see on at least 3 different IDS products:

    *IDS Evasive Double Encoding - Observed traffic almost always seen communicating with ad-servers/domains (such as DoubleClick or Fastclick..etc)
    *DNS Tunneling - same thing... spyware traffic reporting data back(ET Phone home)
    *ICMP Network Sweep w/Echo - In this instance, Turns out to be Yahoo messenger trying to find an alternate port to use to get out past the firewall when the default IM port is blocked

    etc..

    Granted, you may hypothetically read 15+ different submissions for one alert, but maybe one of them may apply to the researcher... heheh
    ya never know.. maybe someone else saw and determined eDonkey traffic running over SSL OWA was a false positive and stated their reason why...
    Although, its more fun (and better for learning) to determine if its a false positive or not yourself!
    %42%75%75%75%75%72%70%21%00

  8. #18
    Goz,

    I see you passed your Secure and Pix exams, so I'm assuming you've done your CCNA. This mean you have a basic understaning of TCP/IP, which is good. One of the best things you can do is now is to make it better. It will be the building blocks of your understanding of an intrusion detction/prevent/whatever solution. Pretty much the more you know about the basics, the better you'll be. Also, this understanding of networking allows you to really dig into the operational portion of IDS once you get it working.

    Don't forget to step outside of the technical aspects of IDS and look at the business need, the overall architecture, and the "why's". Trust me, this will be important as your career advances.

    Play man, play. And have fun. That's what it's all about. Good luck!

    Trench CISSP, CCSP, etc...

  9. #19
    Junior Member
    Join Date
    Feb 2005
    Posts
    26
    Hi Trench,

    Yes I've done the CCNA (recertified when I passed the PIX exam), CCNP etc and up until now I've been the kind of all round support guy (couple of MCSE's thrown in for good measure) but this is a good opporunity for me moving into a design role.

    And the team I am going to work for have an emphasis on security and business risk analysis so all of the areas you mentioned about business and overall perspective in your post are very relevant.

    I was a bit concerned about my lack of experience in the actual 'design' aspect of security. You know someone says to me 'My firewall is broken please fix it' and I'll have a chance but going to meet a client and them saying 'I have x to spend, please design me a security infrastructure' is an area I need something of a heads-up in.

    So I'm glad I started this thread and already have some good resources and advice from it!

    Thanks guys!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •