Slashdot Mirror


Snort up For Revamp, says Creator

A reader writes:"The creator of Snort, the open-source network-based Intrusion Detection System (IDS), says the software is up for an overhaul. Martin Roesch has told the AusCERT conference IDS has failed to impress the market, citing the inability of many to minimise the number of false alarms triggered by the monitoring devices. The next iteration will include "passive discovery" features."

148 comments

  1. Worked ok for me by HogynCymraeg · · Score: 3, Informative

    I used snort on an IPCOP box. Worked ok for me.

    1. Re:Worked ok for me by justsomebody · · Score: 4, Interesting

      It's not the problem with working or not.

      Snort just isn't ready for serious use in enterprise. Sounds silly, but... Too many false positives may very well lock network.

      Here is a simpler case. On Port detectors.
      Why don't port detectors use iptables lock out of port scanners (or even better why it is not suggested).

      Most of port scan detectors count actual SYN,FIN and other blocked TCP blocks which are marked as invalid on your firewall. Not even one of them doesn't take to account that some features are completely valid even though they are not. (here is the case: You're running ftp server, that means port 21 is open, does it really matters if SYN,FIN occurs on that port???) Secondary they don't take to account some stupidity. (You don't really care if one machine has scanned your port XXX (yes, your pr0n port) for 50 times), result was always the same. This should count as 1 and not as 50. With this relatively simple logic port scan detectors would exclude false positives in a very simple way. And you could be sure thatsomeone that scanned 50 ports (different and not public open) is really port scanner.

      Now go to second level. Porscan detector is just one of many functions that snort provides. And even here there's many false positives.

      Actualy I use Snort very differently. Redirected logs to my external processor and this processor excludes invalid information, after that reaction on firewall or server follows. That way was the only possible way to get fairly restrictive measures with not too many false positives.

      --
      Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
    2. Re:Worked ok for me by The+Cornishman · · Score: 0, Troll

      I surely am ready for a revamp, Lord. What should I snort up?

  2. Not funny by SirChris · · Score: 4, Insightful

    not meant as a joke but i think it could also have to do with the psychological fact that Snort just sounds like something you want to distance yourself from. I wouldn't associate myself with a program called mucus-mouth no matter how good it was.

    1. Re:Not funny by dallask · · Score: 5, Funny

      maybe they can rename it "Blow" :)

      --
      The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
    2. Re:Not funny by flynt · · Score: 4, Insightful

      Martin Roesch has told the AusCERT conference IDS has failed to impress the market,

      He's not saying Snort has failed to impress the market, but rather that in general, all IDS systems have, which is true.

    3. Re:Not funny by Kaa · · Score: 3, Funny

      A sense of humor is a wonderful thing, in case you were wondering...

      And I associate the word "snort" with two things: either a sarcastic disbelieving chuckle, or an angry rhino. Umm... maybe you have something there about wanting to distance myself from... :-)

      --

      Kaa
      Kaa's Law: In any sufficiently large group of people most are idiots.
    4. Re:Not funny by Anonymous Coward · · Score: 0

      It sniffs traffic. What would you call it? Detector? Go ahead and distance yourself from Snort, but a good program is a good program and Snort is a memorable name that is associated with its functionality.

    5. Re:Not funny by Anonymous Coward · · Score: 0

      You kidding, I love the name. Seeing the looks on other people's faces when I was saying to a friend that I was thinking about trying Snort 'n' Acid was priceless.

    6. Re:Not funny by AmoebafromSweden · · Score: 1

      > I wouldn't associate myself with a program
      > called mucus-mouth no matter how good it was.

      Not even if it sent naked girls to you in your apartment every day?

      Everybody has a tolerance limit...

  3. Cool, but effective? by Allen+Zadr · · Score: 5, Interesting
    From the article:
    "The idea is to take a policy like 'thou shalt not run OS X on the network,' and then if someone with a Mac plugs into our network... it can tell the firewall to [block them],"...

    While this would be cool, the nature of TCP/IP says that it will be quickly defeated. There are already programs out there that will make your Linux box masquerade as another type of computer.

    If a policy says, thou shalt not run P2P - then the P2P will be reached through proxy. If you use snort regular expression detection (one of the coolest features) then new protocols will be written to look like an innocuous service (P2P though ICMP/Ping).

    The worst part, and my buddy Zero Hex could talk about this forever, is when ISPs start using this to enforce their will on users. Thou shalt not connect without Windows.

    Basically, it's not likely to enforce policies among those who actively want to get around them. Instead, it will enforce policies that push an agenda.

    --
    Kinetic stupidity has a new brand leader: Allen Zadr.
    1. Re:Cool, but effective? by Kenja · · Score: 5, Insightful
      "If a policy says, thou shalt not run P2P - then the P2P will be reached through proxy. If you use snort regular expression detection (one of the coolest features) then new protocols will be written to look like an innocuous service (P2P though ICMP/Ping)."

      A GOOD firewall will be doing more then just blocking ports. It will analyze packets to determine the type of comunication being used. Which is not to say such things can't be circumvented, but it is much harder then just using a proxy.

      The problem, and what this article is in many ways about, is dealing with false positives when checking for spacific types of network traffic.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    2. Re:Cool, but effective? by swb · · Score: 1

      Basically, it's not likely to enforce policies among those who actively want to get around them.

      You can raise the marginal cost for getting around them really high, to the point where the labor and possibly diminished performance isn't worth the effort.

      We've been demoing a Packeteer 2500 packet shaper, and it's a pretty amazing box. It uses content rules to identify specific protocols (as opposed to content-blind port numbers), which you can then apply bandwidth policies to, including "do not pass".

    3. Re:Cool, but effective? by wfberg · · Score: 5, Interesting

      A GOOD firewall will be doing more then just blocking ports. It will analyze packets to determine the type of comunication being used. Which is not to say such things can't be circumvented, but it is much harder then just using a proxy.

      Not quite. Case in point; try blocking instant messengers on your network. Turns out that if you block specific ports, you'll find that they start using port 80.

      Ok, block any IM content on port 80, and they move to port 443, that's HTTPS, encrypted.

      Ok, so you block some IM server hostnames (there are many) on your DNS server and block access to outside DNS and proxies. Then you find out that there are apps such as htthost/httport that will happily run on a box outside your network accepting encrypted traffic on the HTTPS port and with HTTPS headers, but that are actually proxies (similar things can be achieved on a linux box with a simple enough shellscript). This works easily enough to be downloaded by your smarter-than-average bear.

      P2P programs could easily go the HTTPS route if blocking becomes enough of a nuisance. They went route 80 (HTTP port) a long while ago.

      So what are your alternatives? Perhaps degrade network performance by interrupting (apparent) HTTPS sessions once in a while so that people won't be able to use certain applications? Or disallow any kind of encrypted communications?

      Creative people will always find a way around it. You're better off dealing with those sorts of threats from the inside by dealing with the people rather than the technology. That's probably also true for outside hackers, script-kiddies and virusauthors, but those you typically don't know.

      --
      SCO employee? Check out the bounty
    4. Re:Cool, but effective? by Allen+Zadr · · Score: 2, Interesting
      Sure, but gnutella (for instance) is already implimented using a structure that very closely follows the http protocol. So gnutella, across port 80, is very difficult to detect.

      So, even if I get 'smart' detection, how will this better protect me from getting false positives for P2P by users whom are hitting IP dotted addresses to find legitimate web sites.

      Computers can only get so smart, before they become smarter than you are...

      An example I would call on is Word. When I want to misspell a word on purpose like, recieved. Word knows better than I do, and will change it back, automatically. This is not so bad, until you start dealing with multi-page columns in a document. I know what text I want to show up in each column. I type it where it goes, Wysiwyg style, but Word knows better. It will change things around, and put my text where it wants.
      This is similar to false positives. Eventually, the program is written to think it knows better than the person running it.

      My point is - when will a SNORT type product decide that my Windows machine cannot work on an ISP of Windows machines because I pipe it's traffic through a virtual interface that coincidentally looks like I'm running OSX or Amiga?

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    5. Re:Cool, but effective? by Allen+Zadr · · Score: 1
      As the post above mentions, how effective is this against MSN Messenger? Messenger protocols will gladly talk http or https, and run over standard web ports.

      No MSN messenger is a common policy among companies. I'd be quite interested to see if it's effective, without cutting off web access (false positives).

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    6. Re:Cool, but effective? by homer_ca · · Score: 5, Informative

      You make a good point about people vs. technology. In security, policy is as important as firewalls. If IM's are prohibited by company policy and blocked so that advanced measures like httport are required to circumvent your block, you have good cause to reprimand someone found using IM.

    7. Re:Cool, but effective? by Allen+Zadr · · Score: 5, Interesting
      If you know of something that can block MSN Messenger effectively, let me know. It installs as part of windows, and without user intervention, tries very hard to bypass detection and get through to it's home servers.

      I can have a policy - don't install this - don't use this, but most people do anyway just to make that damned message go away. "Wouldn't you like all the benefits of adding a .NET password to XP?". Sure, I can remove it, but the service packs put it back again. I turned it off through the registry, and a security update restored it. MSN Messenger is pervasive, and annoying. No user intervention necessary.

      Back to "smart detection" -- After the first blocked attempt, it talks using standard http then as https (also over the correct ports). I don't want to block any web page that 'could' actually be a web page though.

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    8. Re:Cool, but effective? by rograndom · · Score: 2, Informative

      Ok, block any IM content on port 80, and they move to port 443, that's HTTPS, encrypted.

      Hold on now, just because something is using port 443, which also happens to be the standard HTTPS doesn't mean that it's automatically encrypted. Both sides of the connection have to be using an agreed upon encryption method. If they IM program was going to jump to port 80 just to run encryption, it could've done it just as easily on port 80. It's probably using 443 because that's the next "most-common" available port since port 80 was blocked.

    9. Re:Cool, but effective? by TheLinuxWarrior · · Score: 1
      It depends on the company and the OS in question as well...

      I know we don't block the firewall for these applications, however, SMS will uninstall them if detected on your PC when you logon.

      That means P2P is out, and IM is out except any of the web based IM such as AIM express etc...

      The application people just have to keep on top of what P2P and IM applications are out there so they can add "definitions" for SMS to look for.

    10. Re:Cool, but effective? by swb · · Score: 1

      MSN shows up as a distinct protocol in the Packetshaper's monitoring and management screens. They're using layer 7 analysis, it's not just port numbers. In fact, many of the protocols (referred to as traffic classes in Packeteerspeak) don't have a port definition they're dependent on.

      If I define my web proxy as a class and enable class discovery inside this class, I can see all the various classes it handles -- Windows Media Streams, Real Streams, MPEG, Quicktime over http.

      I don't know for sure, but I kind of have to guess that MSN over 443 isn't encrypted (I'd presume the server-end overhead would be crushing), so even MSN over 443 should be detectable as MSN.

      The advantage with something like this is you can clamp unwanted protocols hard (or even disable them) and not have to worry about port-hopping. In some cases, setting a 56kbps policy for an unwanted protocol and making it functional but essentially unusable is better than trying to block it, paritcularly for apps that won't hop to other ports if they "work" on their default port.

      It's certainly possible to stegonographically embed one protocol in another, use encryption to mask the entire packet, but each incremental step you take to evade becomes harder and harder, and requires more resources (such as outside proxies).

    11. Re:Cool, but effective? by Suidae · · Score: 1

      hmm, I wonder if SMS can be set up to remove GAIM running inside a colinux system that I'm connecting to with Cygwin/X?

    12. Re:Cool, but effective? by chris_v_25 · · Score: 1

      wfberg,

      As an aspiring network security professional, I am very impressed with your skills in tracking down traffic that you don't want on your network. I have to ask though, wouldn't it be simpler to have a desktop policy that will take away the users ability to install p2p/IM apps?

      Thanks!

    13. Re:Cool, but effective? by Anonymous Coward · · Score: 0

      Or GAIM that is proxied through an OpenVPN connection.. /for example

    14. Re:Cool, but effective? by TheLinuxWarrior · · Score: 1
      I would doubt that...

      But I do know that gaim was placed on our SMS remove list, along with all the other popular multi-protocol clients. :(

    15. Re:Cool, but effective? by wfberg · · Score: 1

      As an aspiring network security professional, I am very impressed with your skills in tracking down traffic that you don't want on your network. I have to ask though, wouldn't it be simpler to have a desktop policy that will take away the users ability to install p2p/IM apps?

      Can't use SNORT to do that ;-)

      Seriously though, there are some useful policies you can define for windows desktops if your workstations are hooked up to a domain/active directory.

      Most useful perhaps are the Windows XP (you must use 2003 server, or define them locally) software restriction policies; you can simply define applications that aren't allowed to run, and they are identified by their hash-value, path, internet-zone or a certificate.

      The path option is the most useful one, just restrict access to stuff in directories users can't write to. IIRC though, shortcuts are also affected, which is a bad thing (do you allow everything in the start menu, which is in a users profile, or disallow it and add items ad hoc?).

      SMS apparently has some of this functionality as well.

      Still, that is all defeated by using one of those SuSE or knoppix live CDs, becoming local administrator (simply use the password resetting bootfloppy), or as by using a laptop.

      Of course you could imagine scenarios where that wouldn't work, but there is a trade off between absolute security and usability.

      --
      SCO employee? Check out the bounty
    16. Re:Cool, but effective? by homer_ca · · Score: 1

      Did you try the "Set Programs Access and Defaults" to disable access to MSN Messenger? If you want to block on the firewall, you can run Messenger through an http proxy and log the hostnames it's trying to reach. I think the hostnames will be unique to Messenger and won't be a web page.

    17. Re:Cool, but effective? by Aliencow · · Score: 2, Informative

      Geez just set a GPO to disallow running Msn Messenger and it'll stop bugging them!

    18. Re:Cool, but effective? by Anonymous Coward · · Score: 0

      Well, you asked, so run Linux and don't let them install things without IT's approval.

      Yeah, yeah, I know. You probably cannot overhaul the whole company's computers to do such a thing, etc. etc. ...

    19. Re:Cool, but effective? by GAVollink · · Score: 1

      What's a GPO?

    20. Re:Cool, but effective? by ManxStef · · Score: 1

      Group Policy Object. See here:

      http://www.microsoft.com/windows2000/techinfo/pl an ning/management/groupsteps.asp
      http://www.actived ir.org/gp_faq.htm

      Check it out locally by running gpedit.msc

      For details on how to disable Messenger see here:
      http://techrepublic.com.com/5100-6270-50296 43.html

    21. Re:Cool, but effective? by Anonymous Coward · · Score: 0

      Or he could just implement a group policy object that disabled MS Messenger company-wide. Takes around 30 seconds to set plus 15 minutes max. to propagate across the domain.

    22. Re:Cool, but effective? by wayland · · Score: 1

      Try Winblox (wblox) from Liu de Yu (cf. recent Bugtraq posts). If you grok regex, it's easy.

    23. Re:Cool, but effective? by Thundersnatch · · Score: 1
      Windows Group Policy can block MSN messenger (or any application, really) from running on any machine to which the policy applies. You can even block apps by the executable's filename or even SHA-1 hash, or allow only approved apps to run.

      If you're not using Active Directory and Group Policy to manage your Windows 2000/XP workstations... well, it's time to step out of the late 90's, man.

    24. Re:Cool, but effective? by Allen+Zadr · · Score: 1
      Great idea... except I'm using Linux servers only. Worse... because I have road-warriors with laptops to support - they need Administrator access to their own machines .. a fact of life. I could set them up with Domains and ActiveDirectory through Linux tools, yet - these machnies would be in my network less than 15% of the time (on average).

      So, yes, I could break down and pay 10 times the price for the same server power, but - really, the price doesn't justify the functionality.

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    25. Re:Cool, but effective? by Thundersnatch · · Score: 1
      Well, you can also apply group policies to local machines by distributing appropriate .POL files. You do have some sort of automated software installation process, don't you?

      Also, mobile users do not need administrator access to their own machines. We have 30% mobile population, and not a single one has admin or even power user rights to their own machine.

      The only issue with them not being admins is printer driver installation at remote sites. We solved that problem by pre-loading a bunch of Lexmark, HP, etc. drivers on all machines, and letting plug-n-play take care of driver installation. We get maybe one or two calls a year where we have to remote control the user and to a runas on their machine to install a driver as administrator.

    26. Re:Cool, but effective? by Allen+Zadr · · Score: 1
      Fair enough. I could certainly try that route. I like the mutliple driver idea - I imagine running into conflicts with this.

      I have initial set-up automated, but not after-the-fact. (too small a user population for price to functionality to make it fiscally plausible).

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
  4. been done by Triumph+The+Insult+C · · Score: 4, Informative
    --
    vodka, straight up, thank you!
    1. Re:been done by Allen+Zadr · · Score: 1
      From your link:
      Certain revisions or patchlevels of an operating system may change the stack's behavior and cause it to either not match what's in the fingerprints file or to match another entry altogether.

      The above note does speak to one of the points I made. It's difficult to make this work correctly, and effectively (I use ipf on Solaris, and the OS SYN signatures are not reliable).

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
  5. Yep, Snort is great, but... by justsomebody · · Score: 3, Interesting

    Too many features might really mean to many false alerts (logs or mysql tables can get pretty crowded). But in any case it's usable to detect default signatures of attacks pretty well.

    Should be used? Yes, except some functions should be disabled
    Should be remodeled? Yes

    It has the same flaw as port scan attack detectors.

    --
    Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
  6. the problem with IDSes by Keruo · · Score: 5, Interesting

    the problem with IDS systems is encrypted traffic
    if someone wants to attack your network, they can easily implement proxy which will encrypt all the traffic they transfer and thus disabling the IDS's ability to analyze the traffic

    --
    There are no atheists when recovering from tape backup.
    1. Re:the problem with IDSes by tkrabec · · Score: 4, Insightful

      umm no, not completely, in order to attack your network the data has to become unencrypted at some point in time. When it does it becomes traceable and you'd then be able to analyze it. It may be a bit harder and require an IDS box on the inside of the network, too.

      -- Tim

      --
      TKrabec Pahh
    2. Re:the problem with IDSes by Keruo · · Score: 1

      it would require host based IDS.. by using network based one you might end up having funny effects,
      like in case of false alarm, the IDS would shut down connections from your net to outside world..
      that would be nasty to debug in a production environment

      --
      There are no atheists when recovering from tape backup.
    3. Re:the problem with IDSes by obby.net · · Score: 1

      ssldump is a good thing. http://www.rtfm.com/ssldump/

    4. Re:the problem with IDSes by talon77 · · Score: 1

      Well, not really. First, as with any IDP sensor, you need to tune it. That is, you run it for a few weeks without blocking traffic, find out what is normal for your network, and then set it to block based on a rule system learned from your tuning. Next, if there is a false alarm, you should set it to not block all traffic from the outside world, just traffic from the host that is causing that alarm, and for whatever default period of time you think is significant (15 min, etc.) If you take your time, and tune the system properly, you will find that you won't have too many instances of interuption of service from legit visitors.

  7. Open Source IDS Correlation by dcgrigsby · · Score: 5, Informative

    Some of what Martin says regarding minimizing false positives by correlating an attack with the correct platform, etc. is already being done by the open source IDS correlation project QuidScore:

    http://quidscor.sourceforge.net/

    1. Re:Open Source IDS Correlation by Anonymous Coward · · Score: 0

      Yeah actually there maybe a couple that already do this. I know Demarc also has F.A.S.T techonology with their Sentarus box(http://www.demarc.com/Sentarus) that I think is doing exactly what Marty plans on doing. Its funny how Sourcefire the founder of snort have fallen behind to others that are using their technology.

    2. Re:Open Source IDS Correlation by Helevius · · Score: 1
      Too bad you need to be a Qualys customer to use "Quidscore." This is not a workable solution for most people. From their FAQ:

      How do I fully take advantage of QuIDScor if I'm not a Qualys customer ?

      "To try QualysGuard with QuIDScor and Snort, visit http://qualys.com/quidscor and sign up for a free trial."

      Great.

      Helevius

    3. Re:Open Source IDS Correlation by _dl_ · · Score: 2, Informative

      Well, you can still download the source and adapt the concept to use another vulnerability assesment tool, not just Qualys'.

      Or in general, this shows that there are ways to enhance both tools efficiency by combining them.

      ps: I was the lead on Quidscor, so yes, I'm biased :-)

    4. Re:Open Source IDS Correlation by Helevius · · Score: 1
      Good point, thanks for that idea.

      You seem to be a Tcl wizard. Have you looked at Sguil, another Tcl tool? If you're interested in contributing, I know the project would be glad to have your assistance.

      Helevius

    5. Re:Open Source IDS Correlation by creining · · Score: 1

      There are open source correlation projects out there (opposed to QuIDScor, Sourcefires RNA, and Tenables NeVO) such as IDS Alert Verification, OSSIM, and Brian Caswell's simplistic honeysuckle.

  8. a way to improve.... by millahtime · · Score: 4, Interesting

    a way to improve this might be to take principles from the advanced diagnostics industry. There were a lot of false alarm rates with diagnostics for many years but now it is pretty well nailed down. They use some advanced methods to do diagnostics now. From the way monitors are used to the types of algorthyms.

    I know I can't spell. That's why I am an engineer.

    1. Re:a way to improve.... by lars_stefan_axelsson · · Score: 1
      a way to improve this might be to take principles from the advanced diagnostics industry.

      You wouldn't have a link or two? Maybe I'm dense but; Diagnostics of what exactly? Medical diagnostics? Computer networks? Car problems?

      --
      Stefan Axelsson
  9. I'm not surprised by Stevyn · · Score: 0, Offtopic

    I've heard these guys are very talkative, fidgety, and always have nose bleeds. I wouldn't trust any business with them.

    1. Re:I'm not surprised by Anonymous Coward · · Score: 0

      No sense of humor whatsoever.

      "One man's -1 Offtopic is another man's +5 funny"

  10. Encrypted attacks? by Anonymous Coward · · Score: 0

    That's dumb. If I encrpyt an IIS attack, it won't help me at all. Services aren't vulnerable to attacks they can't "understand".

    1. Re:Encrypted attacks? by id · · Score: 0

      If your IIS server is using HTTPS simply attack through it. Host based IDS or using an SSL accelerator with an IDS between it and the host are the best ways to deal with that.

  11. Will they disable some attack triggers? by k.panik · · Score: 5, Insightful

    "...If the new software detects an Apache server running on Linux, it will only look for attacks relevant to that configuration, instead of monitoring the device for an attack that would affect a Cisco router or Windows server..."

    This have 2 serious drawbacks:

    1. If someone is trying to brute-force attack your servers sending probes for every known exploit (aka. nessus), disabling alarms for software/services you don't run will not show the real size of the attack.

    2. In case of an infection similar to code red you won't be able to know wich infected servers are "attacking" you, so there is no way to block them in the router, firewall or reporting the virus-generated traffic to their ISP.

  12. Akamai Mirror by karmatic · · Score: 2, Informative

    It's fast, it's friendly, and it's fun!

    Mirror Here.

  13. Snort Internals by cerberusss · · Score: 4, Interesting
    I analysed the Snort source during my study. It has been some time ago, so I don't know how much of the core code has changed. If anyone's interested, look here and go to chapter 8. Snort ROCKS!

    --
    8 of 13 people found this answer helpful. Did you?
    1. Re:Snort Internals by Anonymous Coward · · Score: 1, Informative

      And yet they don't pick up patches if they are not "cool". I added support for a new DBMS to a previous version, and I submitted the patch. They didn't integrate it, and changed the code so the patch is no longer valid.

      Now people are mailing me directly for patch updates.. I'm not generating anymore since I don't want to keep up with the snort code on their schedule...

      oh well.

      I don't know how the current code is, but the old database code was kinda ugly; sacrificing code clarity for size.. for example you could support ODBC _or_ MSSQL but not both. ODBC + MSSQL didn't work... that is because they had an ifdef ODBC and ifdef MSSQL which were mutually exclusive.

  14. a new DOS tool in the making by prgrmr · · Score: 1

    The idea is to take a policy like 'thou shalt not run OS X on the network,' and then if someone with a Mac plugs into our network... it can tell the firewall to [block them]," he said.

    If this Comes To Pass, all someone will have to do is fire-up snort on you network (custom knoppix cd anyone?) with a policy to not allow any MS products on the network, and *poof*! Instant, internally-generated DOS!

    1. Re:a new DOS tool in the making by karmatic · · Score: 3, Insightful

      Of course, that only works if the attacker has the firewall password/snmp info anyway. And if the attacker has the password in the first place, he won't need snort anyway.

      "But what if he _installs_ a firewal?" If he has access to the cabling, all he has to do is cut it. Perfect internal DoS.

      Besides, if you really want to do that, go grab a copy of FIRE (no, I won't find the URL for you). Give ettercap a go. A couple of ARP packets, and you can take any windows machine off the local network (provided they aren't more than one router away).

    2. Re:a new DOS tool in the making by Alan+Hicks · · Score: 1
      If this Comes To Pass, all someone will have to do is fire-up snort on you network...Instant, internally-generated DOS!

      You don't really think that the firewall will be configured to accept alerts from any old IDS now do you? Likely if some one were to set this up, it would communicate between the IDS and the firewall (if they aren't the same machine) with encrypted TCP/IP packets using pre-shared keys. Unless you could crack the traffic and thus get the key, what shot do you realistically have to just fire up any ole IDS on any machine and get it to work?

      --
      Slackware, what else when it must be secure, stable, and easy?
    3. Re:a new DOS tool in the making by prgrmr · · Score: 1

      Interesting scenario. I'm not sure how well that would work on a network where damn near every subnet is vlan'd (like the one I'm using at work).

      I'll have to go check out FIRE, sounds fun^H^H^H interesting as well.

    4. Re:a new DOS tool in the making by Anonymous Coward · · Score: 0

      Much simpler.
      Hacker has a Mac, the company policy prohibits Macs.
      Hacker writes program to falsify traffic from all IPs on network, with random OS signatures. IDS detects these and shuts down all the IP's/ports.
      Administrator disables IDS's to correct problem.
      Hacker has a mac...

  15. Intrusion Prevention System is the key by Dark+Coder · · Score: 4, Informative
    Seems like most everyone needs to get off the IDS fence and go over and sit on the IPS fence.

    For the uninitiated, IPS stands for Intrusion Prevention System. What's the main difference?

    #1) IDS doesn't block bad traffic. IPS does. #2) IPS handles anomaly variants, IDS doesn't.

    IPS is a new technological way of filtering traffic over the simple brain-dead IDS method.

    You need to visit many of Tippingpoint's white papers to get the grift. (registration req. Just fake your email... I know, this is not an official endorsement, but I used to write IPS filters for them and my working real world experience shows that this IPS filter is more effective than any of Snort's filter.)

    I would love to write more IPS variant-resistant filters for SNORT but I'm afraid to tread on TPTI's handiwork (much less if I step on the same filter). Nonetheless, the defense industry picked me up. Go figure.

    IDS is truly dead. Stop beating a dead horse. Get over it, bud. IPS is your savior.

    1. Re:Intrusion Prevention System is the key by richard_willey · · Score: 1

      Bullshit. IPS was a Gartner attempt to generate publicity that even they have disowned.

      Think about this logically: According to gartner, the critical flaw with Intrusion Detection Systems was false positives. The sheer number of false positives generated by IDS system was overwhleming the ability of network admistrators to react.

      Gartner's "solution"??? Intrusion Prevention Systems that would automatically act to block inappropriate behaviour.

      In what way, shape, or form does automatically locking down Network Resources solve the problem of false positives???

      I agree completely that improved filtering is a good thing, however, this is orthogonal to the whole IDS/IPS debate.

    2. Re:Intrusion Prevention System is the key by Dark+Coder · · Score: 1

      Forget Gartner's glibs.

      How come TPTI doesn't generate false positives (never once did I see one during my Petabit testing tenure there and that is a fact; but the real mask behind the truth is I was testing for solid leads filter, not shaky vacuous filters that TPTI customer still wants, but these shaky filters are not of real values that predominately plague SNORT).

      Locking down Network Resources with a sledgehammer is not the answer, controlling them with a surgeon's knife is.

      Apparently, they have something working right.

    3. Re:Intrusion Prevention System is the key by jayhawk88 · · Score: 1

      I wish I had mod points. This sort of thing was mentioned by the instructor at the SANS conference I just attended last week. I think his exact words were something like, "IPS might be nice, but I guarentee there would be ways to game the system".

      To me the biggest problem with Snort right now is the lack of a good client. You can install ACID or any other number of log analyzers of course, but why wouldn't the Snort people themselves want to offer a nice client interface of some kind? Not a trivial task I understand, but one, I would think, that is certainly in the realm of possibility for the community. A better way to properly configure/monitor Snort "right out of the box" so to speak, without having to spend time installing configuring ACID or any of the other log analyzers would go a long way to getting Snort used more in coroporations I would bet.

    4. Re:Intrusion Prevention System is the key by djrogers · · Score: 1
      IPS was a Gartner attempt to generate publicity that even they have disowned.
      Disowned? Sure, that's why the Gartner group will no longer be publishing an IDS Magic Quadrant (they're replacing it with an IPS one). Publicity stunt? That's why enterprise customers are flocking to IPS in droves, and former IDS vendors everywhere are frantically trying to play catch-up with those that have been doing prevention from day one (ie the previously referenced TippingPoint).
      It only took a quick walk through this year's RSA Security Conference to see that IPS is not only real and here to stay, but it is actually working for lots of people out there. (ob. disclaimer - I work for TPTI)
      --
      Think outside the... Hey, where'd the friggin' box go?
    5. Re:Intrusion Prevention System is the key by bamm · · Score: 2, Insightful

      A cut -n- paste job from a previous post. Sorry, but I am too lazy to rewrite the thing.

      My personal opinion is IPS's have been mislabeled since the beginning (aren't marketers wonderful). Take this definition I found in some Usenet archives (circa 1992):

      "a combination of a security policy with some of the components
      above. Specifically, an implementation of the given policy that
      is enforced by a combination of screening and/or routing." [1]

      Geeze, seems like IPS would fit right in there. Now the final jeopardy question, what was that a definition of? If you guessed "firewall" then you get the big prize. So that's it, you heard it here folks, an IPS isn't the evolution of a IDS, but instead part of the evolution of a firewall. If you look at the history of firewalls, you'll see that early on there were huge flame wars over Packet Filtering and Application Firewalls. In the end, the packet filtering FW won out. Seems to me packet filtering FWs used less resources and could handle faster networks and as those speeds approached full duplex 100mb links, application FWs got left in the dust.

      Fast forward to 2003 and the designers of IDS software have made huge progress in detecting potential attacks, system's CPU/RAM/etc have increased phenomally, and the 'normal' speed of network have sorta leveled out. So, application FWs are back in the picture. Vendors with short term memory loss label this 'new' product an Intrusion Prevention System and advertise it as the replacement for your IDS. Those vendors give it a new label for good reason. There is no way they want to bang heads with the big FW companies and more importantly, their implementations of IDS have been huge failures within their customers networks and they need something to market as 'new and improved' (again).

      I say (most) vendors of IDS and 'IPS' products failed because they sold the product as an INTRUSION Detection System when they really had an ATTACK detection system. An INTRUSION Detection System implies the IDS can detect an event and determine its nature (malicious vs non-malicious). If the attack was malicious, an IDS will help you determine if it successful. If the attack was successful, the analyst should be able to use the data collected by the IDS to determine the impact on the system in question and finally what steps are needed for remediation. The 'IDS' vendors instead force fed us near worthless systems that can display an 'event'. Many won't give us any details on how they determined it was an 'event' and most can't give us any supporting data about 'attack' beyond a src/dest IP addr and port. If we are lucky, we get a whole packet too. No analysis can be done with the console, instead one must go to the targeted machine and pull out his/her host forensics kit or pay a 'Security Consulting' firm $600/hour to recommend you wipe and rebuild the system.

      Soon customers begin to ask "what do I do with this event" and later "I spent XXX hours tracking this down only to find the attack didn't happen or wasn't successful". The vendor noticing the agnst in his customer's voice replies with "we are working on ways to reduce 'false-positives' and in the future we will use IPS technology to prevent attacks too." and thus the birth of "IDS is Dead". I expect FW vendors to incorporate more and more attack detection features from IDSes (duh) and have true hybrid Packet Filtering/Application FWs, but the fact is we will still need IDS. IDS done the right way of course (we call it Network Security Monitoring), but that is a whole other rant.

      Bammkkkk

      --
      www.sguil.net
      The Analyst Console for NSM
  16. I haven't found this to be true by VAXGeek · · Score: 3, Interesting

    I use Snort all the time. The only thing I really get false positives for in great numbers are portscans, but even that is easily tweakable in the config file. I'd rather see one too many security alerts than one too few.

    --
    this sig limit is too small to put anything good h
  17. It is already in the works - I've seen it by Afroplex · · Score: 4, Interesting

    Roesch works within Sourcefire (which puts a lot of development into Snort) as their lead engineer. I've talked with him over a teleconference call and I got the feeling that he loves working with the technology and tries to avoid the sales side of business. Also discussed during the conference call was exactly what this article pertains to.

    If Sourcefire's engineering puts out something like this and not their sales reps, then this is really close to being reality. Take a look at Sourcefire's website, you'll see something called RNA. RNA can do passive monitoring of a network and find what machines do what, and what they are running. I've worked with RNA on a production network - it does as advertised very well and even determines patch levels of some machines just by sniffing network traffic. It doesn't take a rocket scientist to put 2-and-2 together that Snort and RNA are on a collision course to work together considering they are from the same company. I would expect something before the end of the year.

    RNA though isn't open source, so I'm curious to this announcement if the underlying engine to that product will eventually be opened up.

    1. Re:It is already in the works - I've seen it by AYeomans · · Score: 1
      See RNA description for more details. A similar passive sniffer product is Tenable Security's NeVO.

      These kinds of products seem a good way of finding out what software is really on your network. They can look at banners as well as p0f-style operating system versions. And hence deduce whether you have applied all the patches.

      Smaller organisations with good control on software versions might find them overkill and just use arpwatch or DHCP logs instead.

      I don't think they will eliminate the need for active vulnerability scanning to check for software configuration errors which don't depend on version. I'd be interested to hear other people's experiences. Or if anyone is working on tools and common database schemas for describing network topologies and inventories.

      --
      Andrew Yeomans
  18. Re:Fatherland by Doc+Ruby · · Score: 0, Offtopic

    That's a poignant song. It's calamitous how much 21st Century Americans can learn from the mistakes of 20th Century Germans. But what does that have to do with snorting?

    --

    --
    make install -not war

  19. i don't know if i agree, but... by millahtime · · Score: 1

    I don't agree with your but but I have a but of my own.

    I don't think the features need to be removed. THey need a system to get them to work together. That is one way to reduce false alarms. If the overall system knows how everything interacts. The monitors that is and it makes the determinations. Then when a problem is found it takes the information, diagnoses the problem and lets you know. It's the level and way it is done.

    I think it needs a revamp. But not in the same way many have thought of.

    1. Re:i don't know if i agree, but... by justsomebody · · Score: 1

      I never said they should be removed. And exactly. Agree 110%:)

      Read my other post, what did I think with my comment. It's right on top of the page "Re: It worked for me"

      --
      Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
  20. Re:Fatherland by shadowcabbit · · Score: 1

    But what does that have to do with snorting?

    Clearly, he was on coke when he posted it.

    --
    "Why Subscribe?" Good question...
  21. Hank: the response to snort by phoxix · · Score: 4, Informative

    The OSS app known as Hank was pretty much written as a reponse to the short-comings of Snort.

    It supports XML based network rules, and has really advanced things like an ACBM implementation

    Sunny Dubey

  22. Re:Man bites dog. by Anonymous Coward · · Score: 0

    If you knew anything about IDS you would realize that the "commercial equivalants" all use OSS ( tcpdump)as their base engine.
    But then you would not be a slashdot regular if you knew anything!

  23. False positives are not the primary IDS problem by Helevius · · Score: 4, Insightful
    The problem with IDS is not false positives. The problem is knowing what to do with an alert once it appears. If you don't have enough information to make sense of the alert, why bother triggering it in the first place?

    Most IDS vendors focus on ever more accurate alerts, but once they trigger they wash their hands of the problem. The end user must decide if the alert is truly significant to their situation and priorities. It's like having an anti-virus product cry wolf but never give any reasons for its identification of malware or background on its findings.

    An alternative to the "alert-centric" point of view is "Network Security Monitoring," which concentrates on giving analysts information to conduct at least rudimentary network-based investigation. Where most IDS care only about alerts, NSM-centric operations combine alert, session, full-content, and statistical data to give analysts a chance to identify and escalate incidents.

    A tool which uses Snort to generate alert data, combined with session and full content data from other sources, is Sguil.

    The April 2004 Sys Admin magazine features Sguil and a few other NSM tools.

    A book due in July, The Tao of Network Security Monitoring (also at Amazon.com) is all about NSM.

    Anything vendors can do, like Sourcefire's work with Snort, helps with more accurate identification. Just remember creating alerts is only the first step.

    All of the IPS fans out there should remember that their "prevention" depends on correctly identifying intrusions. All IDS and IPS products can be bypassed, which drives the need for audit-centric tools (especially using session data) which are content neutral and don't care about triggers, encryption, and so on.

    Helevius

  24. Re:Man bites dog. by dilettante · · Score: 2, Informative
    I work on an Air Force-funded project for disseminating tactical intelligence info. The IDS that this system uses: Snort.

    Then again, maybe the government doesn't have enough money for the better-quality commercial IDS.

  25. New Sourcefire Tshirt by silconous · · Score: 1

    No lie they are making shirts that say this
    "From the Guys that brought you snort now bring you speed"

  26. Ron Gula by Anonymous Coward · · Score: 0

    Aren't passive IDS capabilities one of the things Ron Gula left Enterasys to explore on his own?

  27. Re:Snort Up, for Revamp? by Anonymous Coward · · Score: 0

    The poster of the story could have titled it something like "Time for Snort to revamp" or something, but did they have to say "Snort Up for Revamp"?

  28. Re:Sore reader modded me down... by Dark+Coder · · Score: 1

    Oooh. Someone (prol'y from the IDS industry) has to be rather sore to hear the word "IDS is dead."

    Cheap shot to modding me down.

  29. Distributors by Gothmolly · · Score: 2, Insightful

    Could this revamp be due to pressure from companies which have built commercial offerings on Snort? Guardent's SDA tool is basically a Snort box, x86 linux on commodity hardware. How many other money-making ventures out there depend on Snort, and what influence do they have over the Marty?

    --
    I want to delete my account but Slashdot doesn't allow it.
  30. Log Monitoring/Notification tools have same issue by xmas2003 · · Score: 2, Insightful
    The false positive problem also affects log analysis programs ... although argueably, it's more a matter of how you use and tune it. I.e. most people expect to install Swatch (or other log scraper) and have it just "work outa the box" ... but in reality, you have to understand what is "normal" in your network and then tune out the false positives accordingly. Same things with network IDS tools such as Snort (MartyR is one smart dude BTW) ... although I "cheated" in that comparision because log scrapers are argueably host-based IDS's! ;-)

    If you are interested, read more about how Swatch and syslog are used in a large production environment.

    --
    Hulk SMASH Celiac Disease
  31. Network Nazis!!! by Anonymous Coward · · Score: 1, Interesting

    "The idea is to take a policy like 'thou shalt not run OS X on the network,' and then if someone with a Mac plugs into our network... it can tell the firewall to [block them],"

  32. Lack of functional cohesion to industry-wide IDS by Dark+Coder · · Score: 4, Interesting

    With the IDS technology lagging today, several IPS vendors stepped in with several technological enhancement toward IDS.

    But the key issue confronting the IDS industry today is the lack of functional cohesion (or double-speak for functional capabilities working together).

    Some of the basic building blocks of network-based inline IPS feature set that is needed to work together perfectly are:

    1. Host-OS-based anomaly decision. Both passive and active scan are recommended to be default on.

    2. Deep high-speed REGEX support. Some REGEX chip market didn't materialized as robustly as they should (SafeNet/Raqia)

    3. Large-scale TCP connection tracking. This has to work at high-speed as well. Goes to protect against DoS, unwarranted connections and terminations of a pattern-hits' connection.

    4. Anchored, unanchored and floating pattern match hardware-assist are needed to work together to cover the variety of algorithms set forth today. This would be a current "1000-watt" hardware issue.

    5. Basic issue of quick sub-millisecond table update of content-search memory remains undauntedly elusive. Most H/W content-search engine requires intensive compilation of fancy tr[e|i]e algorithms floating around.

    How about weaning yourself of SNORT and start coalescing these incoherent IDS functional cohesions into an IPS?

  33. general IDS probs by graf0z · · Score: 3, Interesting
    Network IDS have to fight several problems:
    • false positives: if this problem does not get solved, IDS won't work on larger sites. One solution could - maybe - be the interaction of an network IDS with a vulnerability scanner (eg packetalarm which combines snort with nessus or the above mentioned quidscor) Roesch indicated. Smart attacks try to hide the actual exploit inside the intentional white noise of false positives.
    • false positives.
    • false positives.
    • encrypted traffic: if an ipsec roadwarrior attacks a service or an attacker targets the https-port of a webserver (not using detectable openssl-overflows :-), the IDS sensor has to sit between encryption endpoint and the target. That means that You may have to terminate https with stunnel at your IDS-sensor one hop in front of your apache instead of using mod_ssl ... And how do You detect malicious content in gpg-encrypted mails?
    • "protocol tunneling" or "firewall piercing": how do You detect an trojan inside a corrupted internal workstation calling home through harmlessly looking traffic like http (or even https)? It could craft the http-requests to be indistinguishable from real user traffic (using same proxy and proxy-credentials as the user if nesseccary).
    • everyday a new way of obfuscating exploits. Modern IDS know tcp-segment-reassembly, ip-fragment-reassembly, hundred ways of quoting and encoding (like unicode), but it's hard to catch up hackers creativity.
    • polymorphic attacks: we've already seen polymorphic shellcode. There will be polymorphic attacks as well. Your IDS engine will have to be much smarter than matching regex to detect those!
    • hand crafted variations of known exploits: there are open source exploits which can be modified such that the according snort rules does not strike any more.
    • there are myriads of exploitable cgi/php/.. scripts: once coded by a poor student or - worse - a webdesigner, never updated, not publicly known. The chance is not too bad for an experienced hacker to construct a never-seen-before exploit against some ancient webshop. If he avoids the well known evidences (like typing "id" into an unencrypted bindshell) the IDS won't scream.

    I fear that when attackers learn to make heavy use of triggering massive false positives, crypto & steanography, protocol-tunneling and start to build exploit-engines producing polymorphic code the days of pattern matching IDS are count. Maybe anomaly-detection (using statistics or neural networks) will help.

    Just my 2ct. /graf0z

    1. Re:general IDS probs by Dark+Coder · · Score: 1

      NIPS addresses all of the issues stated above.

      Try www.TippingPoint.com.

  34. Re:Man bites dog. by Anonymous Coward · · Score: 0

    OK, you got your cheap shot at OSS in, please:
    1. collect your bonus
    2. get back to work, Microsoftie!

  35. Re:Hank: the response to snort by Anonymous Coward · · Score: 0

    How does an XML-based network rule scheme fix anything? I see that as just complicating an already complicated situation.

  36. sneeze? by krappie · · Score: 1, Informative

    Haha. I wonder if this whole thing has ANYTHING to do with this?

    http://www.phrack.org/unoffical/p62/p62-0x0d.txt

    1. Re:sneeze? by Anonymous Coward · · Score: 0

      old news, and this has been addressed many times on the snort-users list. this was a box in a basement that was only used to hop onto IRC.

      SNORT RULES

  37. Snort on ACID by AgentPhunk · · Score: 2, Funny
    During a recent interview I was asked about my experiences with IDS systems. I joked with the guy interviewing me (also the hiring manager) that I was using Snort on ACID*, and how that wasn't a phrase you should use in the elevator or when around non-geek types. He agreed and laughed.

    Sad part is, I just got the call 5 minutes ago saying that I didn't get the job. :-(

    * (Analysis Console for Intrusion Databases)

  38. Trip to HR by mrnick · · Score: 1

    If I was the CTO of a company and I didn't want or was instruct to not let employees use IM programs. I would make very simply rules that blocked the traffic, which would take care of 99% of the non creative people. If I went to the next step of checking for IM content on port 80 I wouldn't block the traffic instead I would log it. After they talked to HR and understood that we didn't want IM on ANY port I imagine they would be uninstalling AIM. If not, I asure you the next time someone else would be doing it for them.

    Unless our technology becomes more inteligent than humans there will always be a human aspect to security.

    Nick Powers

    --

    Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
  39. I want the alerts for pointless attacks by JimmytheGeek · · Score: 1

    I like the idea of Sourcefire's RNA product ("Realtime Network Awareness"). The idea is that it will use passive os fingerprinting to find out what's out there, and tap a database of vulnerabilities to see if there's a serious problem.

    But I want the other alerts - the cmd.exe attempts on Apache servers, etc. - as correlation for the other alerts. I agree there's a huge value in separating the stuff that's merely for correlating with the serious alerts.

    You can set an alert level = harmless just to get the packet recorded with a self-documenting tag. You can also pick action = "log", rather than "alert". Snort will store the packet, but won't put it in with the alerts. Sometimes lots of rules are required to give you what you want.

    I'm toying with the idea of alerting on ftp control sessions, with a big "Harmless: ftp control session established" message. The idea is to have a flag that will explain those weird ephemeral port -> ephemeral port alerts that show up. Passive ftp should go client ephem port to server port 20, imho, but the RFC doesn't seem to require it and most implementations don't do it.

  40. Just need the right config by Omega1045 · · Score: 3, Insightful
    I haven't used Snort for a while. We used it at a little ISP I worked at to protect various parts of our network. If I recall we were running Snort on some small linux build like trinix. We had old desktop machines running snort with rulesets that were mean for each segment i.e. the Snort box sitting on front of our NT machine was watching for NT attacks, etc. I never recall having performance issues; Snort was very fast even on old machines.

    We ended up putting together a little access db that we could generate rules for snort based on critieria like port, os, etc. Eventually we turned this into the first Snort rules site snort.rapidnet.com which is now down. I would imagine that any problems someone might have with Snort (or other IDS) is the correct config for a given scenario or situation.

    You have to give props to guys like Marty who make a really great, free product that the little guys can use to conduct homegrown (not homeland) security.

    --

    Great ideas often receive violent opposition from mediocre minds. - Albert Einstein

  41. The real problem is not false alerts... by greyfeld · · Score: 5, Insightful

    The real problem with Snort, and this is coming from someone that has administrated Snort systems in two major companies, is management's lack of understanding that it takes labor to maintain these systems. They want something that they can just pay for up front and will work with no additional tuning or labor costs.

    This is the true failing of Snort and other IDS systems as well. They require labor to tune the ruleset and configuration to a network. They require constant updates and someone that can create signatures on the fly. They require someone that has a knowledge of TCP/IP protocols, routing, networking and the ability to analyze data and follow leads.

    Working with Snort is kind of like being a detective. The alerts are clues and you have to dig through a lot of other logs, traceroutes, whois, calling people on the phone and find out what they are doing, etc. It's all labor intensive and no one in management wants to dedicate the resources necessary to make it really work.

    I could spend all day working on Snort, but I have to monitor firewalls, email, viruses, go to meetings, train people and type on slashdot once in a while. And IPS is no different, it is not something you can just put in and leave forever and feel safe.

    Management needs to realize they need people on site to deal with the New World Order of constant hacking attempts. IDS admins are jobs needing to be filled, that's why Snort is not living up to the "promise". Management somehow twisted the promise of Intrusion Detection into some automaticlly, always upgraded intrusion prevention system that requires no labor, no upkeep and you never have to spend any more on it. They continue to live in a fantasy world and one day will end up hacked even though they got a raise for cutting their security budgets by 25% for the year.

    1. Re:The real problem is not false alerts... by ErpLand · · Score: 1

      Exactly.

      This perhaps could also be expressed by the old adage (possibly from Bruce Schneier?) that security is neither a product nor a state but a process.

  42. Why isn't IM hit by DCMA ? by terminal.dk · · Score: 1

    Why isn't IM hit by DCMA or some other US regulations ?

    The apply different techniques to circumvent company firewalls, and whatever else is needed to no comply to company policies. And the suppliers does all they can to make it impossible to block. I.e. placing servers on different subnets where they also place other servers that people needs access to for other reasons.

    I think something should be done to kill this plague.

  43. CISSP certification toward ISP isn't worth squat. by Dark+Coder · · Score: 1
    Come to think of this, the famed CISSP certification is worthless with regard toward this new IPS arena...

    Even the SANS GAIC GCIA (Intrusion Analyst) certification is try to evolve to meet this new IPS technology, but until TPTI releases the ability to let end-user customized filters, the certification would be essentially worthless. Just too many IPS technological-curves for the ordinary IA guys to keep up. Really!

    It is tantamount to handing the wheel to a Formula 500 car over to a 15 1/2 year old testosterone-laden lad without supervision. This isn't your grandfather's car anymore. Its a whole new whole world of Intrusion Analysis out there.

    Tee-hee.

  44. Darwinism at its best for FW/IDS by Dark+Coder · · Score: 1

    Bammkkkk,

    IDS and FW has already tied for 2004 Darwinism Award for not applying the Moore's Law consistently toward themselves. They simply fell off the chart and has not been able to hold a lighted candle toward IPS.

    TPTI cooked and delivered IPS in 2001-2002. (You say IDS vendors gathered in just in 2003, sheesh... no wonder, its a response to the surprise evolutionary newcomer, IPS)

    IDS and Layer 4-7 Firewall deftly merged together along with many more HW-based analysis algorithms to become a true inline IPS (or more correctly, NIPS).

    Layer 4-7 firewall has its limitation with how many content filters such a firewall could do before it becomes CPU-bound. Small-scale HW-bound FW (i.e., Netscreen) tends to overheat (and thus may probably demand cooling fans, and maybe later cryogenic cooling?) when you start piling up memories to hold more than a couple hundred unanchored/floating content search patterns. (Hence, our "1000-watt" hardware problem.) TPTI handles at least an advertised 1800 working filters (but their signature database and hardware capacity is far much bigger and my TPTI employment NDA requires that this be left unstated).

    One of many IDSes' limitation was with lack of multiple state tracking algorithms, particularly the multi-layer state tracking tables (i.e., cookie state over HTTP state over 5-tuple state). Try doing that at 5 Gigabits per seconds.

    So, fork or no fork, no marketing angle was needed to tout IPS. It was evolutionary and natural.

    As to your assertion that IPS failed? Recheck various conferences on this (RSA, MilCom...). IPS is off to a roaring start since 2001 and doubling each year.

    Just an appropriate application and merger of new technologies justified such a new moniker: Prevention as in Intrusion Prevention System.

    Let me rephase my first post's statement:

    IDS/FW is truly dead. Stop beating a dead horse. Get over it, bud. IPS is your savior.

  45. False Positive isn't. by Dark+Coder · · Score: 1
    To those expert Intrusion Analysts (particularly those with GAIC GCIA certifications), it is possible to attain near-zero false-positives.

    One CTO at a well-know Maryland-based HIDS company stated to me personally that it is impossible to attain 0% false-positives. I agreed totally on this point BUT...

    Would the customer settled for something like one minus dot 9 nines? (0.0000001%)?

    Bammkkkk said:

    The vendor noticing the agnst in his customer's voice replies with "we are working on ways to reduce 'false-positives' and in the future we will use IPS technology to prevent attacks too." and thus the birth of "IDS is Dead"

    TPTI (and many other IPS and IDS) is restraining themselves from stating 0% false positives because it is tantamount to false advertising. But this would be purty darn good, wouldn't it?

    Now, TPTI (IPS) customers aren't complaining on this issues at all, AFAICT. I wonder why IDS customers are still complaining?

    I've got one possible answer... It must be a Trade Secret.

    1. Re:False Positive isn't. by bamm · · Score: 1

      You seem to be missing the point. It isn't about whether I think IPS is good/bad. I honestly think it's great. My point is that IPS doesn't replace an IDS. I feel you still need IDS. There are three components of Network Defense:

      Protection, Monitoring, and Response

      FWs/IPS/etc fall into Protection
      NIDS/HIDS/etc are in the Monitoring category

      I don't believe any protection (including IPS) will ever be 100% and therefore you better be implementing monitoring and response at some level. When I think IDS, I think IDS alerts (snort, RealSecure, etc) + session logging (argus, sancp, etc), and raw pcap logging. It's what I think IDS really should be, but since it isn't, we use the term Network Security Monitoring.

      Bammkkkk

      --
      www.sguil.net
      The Analyst Console for NSM
  46. weird? by Anonymous Coward · · Score: 2, Insightful

    whinge, whinge,

    * too many false positives, then tune your sensors - but then again _YOU_ will have to know and understand your network and its traffic.

    * requires too much time/labor/knowledge to use/setup/maintain - since when did the security industry stay static, or more likely since when did the otherside put their feet up and say, "enough is enough", we have created enough virii/worms/ddos apps/exploits...

    LOL, 'greyfeld' had it right in the last paragraph. Spend some money on Security you tight-fisted sods and stop bleating about how it hurts your budget so much - or your job will be on the line not mine; when the site is hacked and the customer databases are ripped, sales figures erased, and the backups failed (as they always do).

    I use (daily) a few of the top commercial IDS/IPS apps depending on the customer, and snort is still a favorite for what it is.

    So to get a feel on how ppl are comparing this to other IDS/IPS apps, a few questions;
    Q1. So how much money was invested in the latest McAfee IPS, and how much was that compared to the latest version of Snort?
    Q2. How many IDS/IPS style companies did snort.org take over in the last few months compared to Cisco.com?

    Moh.

  47. Re:Hank: the response to snort by Anonymous Coward · · Score: 0
    XML is just a better plaintext configuration syntax - one that you can program and validate against (aswell as key=value ASCII, XML can has hierarchy, which is easier to read). For larger companies, they could have a set of rules and via XSLT convert those to several IDSs.

    If you're not familiar with XML or XSLT then I guess the benefits might be hard to see.

  48. Re:Man bites dog. by Anonymous Coward · · Score: 0

    Wow! Did you hear that? That's the sound of a million open source coders throwing down their keyboards in defeat in the face of your biting criticism.

    Seriously, I'm wondering which of the following statements best describes your knowledge of IDSs and the security industry in general. Is it :

    a) I am well versed in the various IDS/IPS products on the market, both commercial and open source. I am aware that Snort is fairly well respected, that several commercial products are based on it and that none of the products on the market are anywhere fuckin' near perfect.

    b) I know fuck all. I live with my parents surrounded by a pile of semi-functional, worm ridden Windows boxes running pirated Anti-Virus software (that expired 6 months ago). My main ambitions in life are to create the smuggest, whiniest post ever to appear on Slashdot and to learn how to suck my own dick. My greatest fear is that when I finally succeed in the above, I will choke to death on it and photos from my autopsy will spread through the binary newsgroups faster than the latest Windows worm, to mass hilarity.

    So which is it Mumbles? Why don't you post the same shit in the next Apache story? It will be taken just as seriously.

  49. Eliminate large security network centers with IPS by Dark+Coder · · Score: 1

    The idea of IPS is to largely minimizing the Network Security Monitoring aspect and the bloated payrolls for those CISSP (and sorry, GAIC GCIA) guys.

    Blocking would-be successful attack is the paramount goal of a basic first-generation IPS. An admin won't even get paged for these events (and along a whole lot of other false-alarm and much less false-positive events, but in the rare case that they are feeling idle, they can even turn that pager-feature on). Why bothered, IPS did its job.

    TPTI does capture packets of events in libpcap v2.4 format. Pick it up the PCAP file with your web browser.

    TPTI assertion is that when you drop positively-identified sessions, there is no need to fill up your alarm tables with worthless glaringly eye-candies on the monitoring screen (but they will log it nonetheless and the log table listings are mouse-click multi-key sortable at all/any table columns.)

    Knock on the door? Who cares, ignore it. Paranoid of your rattling doorknobs? Subsequentially drop them from the specific source indefinitely. Port-scan? Want to block them? Go right ahead. Only for a couple of hours, sure. Ignores those ISS and BlackIce's AOL Instant Messaging's frequent false alarm of FTP port-scanning, yep.

    My assertion is no one needs IDS and their full datacenter-sized staff monitoring anymore. Start dropping those attack sessions. Prevent it from ever happening in the first place.

    No more support calls to your IDS. No more frequent IDS field support technician visiting your plants.

    You should only get REAL ATTACK alert. Not the "I Dunno, Sir (IDS)" nor "I think this may or may not be an attack" alarm event.

    No wonder, IDS industry are being transplanted by IPS.

  50. Re:Man bites dog. by Anonymous Coward · · Score: 0

    The language is beneath the threshold. Some*** moderate this.

  51. Re:Man bites dog. by Anonymous Coward · · Score: 0
    You mean the gub'mint, where all the smartest people work and the most intelligent buying decisions are the norm? that place?

    Do I really need to dig up stories on slashdot where some airforce computer has been hacked into to at least prove that the AF has no particular monopoly on security or smart tech decisions?

  52. What a letdown! by TheABomb · · Score: 1

    In the future, please refrain from beginning article titles with the words "snort up". Where I come from, they call that "the old bait & switch".

    --
    MSIE: The world's most standards-complaint web browser.
  53. Nice! by BollocksToThis · · Score: 1

    Snort up For Revamp, says Creator

    Well shit. If GOD is telling us to do it, how can we possibly condone laws against it?

    Snort up for revamp? Hell, I snort up for breakfast.

    --
    This sig is part of your complete breakfast.
  54. Re:NSM is just another stab at the venerable IPS by Dark+Coder · · Score: 1
    NSM is the sagging NIDS/HIDS vendors' response to the IPS-industry and I predict this will largely fail to attain their goal as the various NSM books are outdated already. This is why...

    There is Prevention, Monitoring and Response in that order. Each stage incurs a tremendous cost-fold as an event progresses each stage. Nip this at the bud where is should be and that is Prevention.

    NIPS products are not easily bypassed compared to their heathen-breathen (IDS, NSM, FW) due to their in-line "bump-in-the-wire" characteristics. One IPS vendor's ability to detect encrypted sessions data are the envy of the IPS industry. Another tracks unidentified protocols (by the use of known-protocol filter). Government loves these features.

    My take on false positive is stated earlier in this Slashdot post.

    The real 1st-generation IPS goal is to reduce event-logging, absolute control of malicious traffic (i.e., trojan, DoS) and operational cost-saving across the board.

    The 2nd-generation IPS will emcompass the viral checking of various payload as well as additional firmware-based algorithm for high-speed checking.

    NSM is still riding the IPS coattail from afar. Go where the real technological and cost-saving lead is: Prevention as in IPS.

  55. Gnutella? No problem... IPS is the solution. by Dark+Coder · · Score: 1

    One leading IPS vendor, Tippingpoint.com, can actually catch a specific protocol across any ports, such as eDonkey, Gnutella, KaZaA, Sharaza.

    University love these IPS products as a form of bandwidth saving measure.

    The unit usually pays for it own cost in form of bandwidth reduction (or avoidance of shelling out $$$ for additional bandwidth) in less than a year (or two).

    Oh, it also blocks those pesky HTTP tunneling proxy that student uses to defeat cheaper and less effective IDS vendors.

    Not to mention blocking about-to-be-successful trojan sessions. And many protections against many software vulnerabilities (ie. Code Red, Sache, BugBear...)

  56. Ok then... by Mind+Socket · · Score: 1

    ... I've snorted up Mr Creator, where's my revamp? Let's do lunch!

  57. Open letter to management by Propaganda13 · · Score: 1

    Son, we live in a world that has walls, and those walls have to be guarded by men with software. Whose gonna do it? You? You, HR? I have more responsibility here than you could possibly fathom. You weep for payroll, and you curse the admins. You have that luxury. You have the luxury of not knowing what I know. That the cost of manpower, while costly, probably saved money. And that my existence, while grotesque and incomprehensible to you, saves money. I know deep down in places you dont talk about at parties, you don't want me on that wall, you need me on that wall.

  58. Re:Eliminate large security network centers with I by bamm · · Score: 1

    Sorry, why didn't you say that this was an I_P_S (Instant Protection System)? Guaranteed to stop 100% of all attacks. I didn't realize that by putting an I_P_S on my network, that no longer would I need to patch any of my systems, audit them for vunlerabilities, etc. Long live service pack 1! Woooo hoooo! No more worrying about systems running legacy applications that can't be upgraded! Users getting trojan via instant messanging applications? Not a problem! I can't wait to tell the board. Risk? We have no risk! Not with our Instant Protection System in place. The threat is ZERO!! We CAN NOT be compromised!! Eat my dust you l33t hax0rs!!

    Excuse me while I go back to the real world. With a real network. With real users. And real security problems. Prevention will NEVER be 100%. So you either suck it up and ingore the possibility of a compromise or you inuclude monitoring. I choose prevention+monitoring.

    Bammkkkk

    --
    www.sguil.net
    The Analyst Console for NSM
  59. Setting the record straight by martyroesch · · Score: 4, Informative
    The article missed a few key points so I'll try to set the record straight here.

    First off, my presentation was about making the case for Passive Network Discovery Systems (PNDS), a "new" technology that I created over at Sourcefire. The basic idea of a PNDS is to discover the composition and topology of your network via a mix of passive OS fingerprinting and passive application layer protocol discovery and the other information that you can infer from that data, such as network topology and asset vulnerabilities. I sought to show how that technology could improve a variety of network security technologies by using the example of how Snort (and other IDS) works today and how it could be improved by integrating the information that comes from a PNDS.

    Sourcefire has developed a product called RNA that performs the PNDS functions that I outlined during my talk. Note that it is a proprietary technology that we developed commercially and it is a completely separate product from Snort or the Sourcefire IDS sensors. We are not going to be integrating the functionality of RNA into Snort, we're going to be modifying Snort to take advantage of the information that a system like RNA can generate. In the best case scenario, RNA has a very different deployment profile than an IDS.

    I said that IDS has had trouble in the market because of its complexity and the requirement that users perform extensive tuning of IDSes in general in order to get maximum benefit from them. There are a lot of things that factor into this problem, but the root cause of almost all IDS problems today is that we don't have automated methods for provisioning them nor do we have effective methods of data reduction available that are automated, persistent and real-time. PNDS addresses that problem head on in a way that is appropriate for real-time processes like IDS in ways that traditional scanning technologies have a very tough time providing.

    I then went on to say that we're planning on making changes to Snort to enable it to leverage the information that a system like RNA provides and make it into a true target-based IDS, redefining how IDS operates and hopefully revitalizing it as a technology. Snort will still be available for free and will still operate in "classic" mode where it doesn't leverage this info for people who don't have passive discovery technologies (or even active ones) so that they can still continue to use it.

    Snort is not going to be doing the configuration policy enforcement (i.e. the "block OS X on my network" function), RNA is. RNA is capable of seeing devices on the network and discovering their attributes in real-time and communicating that data to our management console where it can be analyzed for policy compliance and where appropriate remediation responses can be executed. Not to get too deep into the marketing, but there are good engineering reasons for wanting to do this that include worm/virus containment, real-time IDS policy updates and some other really useful mechanisms for performing policy enforcement.

    We're making mods to Snort because we believe that we can make a truly next-generation IDS capability that is easier to deploy, manage and get valuable information out of due to the effect of RNA. This approach directly addresses all the arguments of the "IDS is dead" crowd while at the same time making IDS a much more impactful technology while greatly reducing the overhead requirements on users.

    I hope this clears things up for people!

  60. One more thing by martyroesch · · Score: 4, Informative
    IDS != IPS, IPS !>= IDS.

    Once again, with feeling:
    IDS is a network monitoring technology

    IPS is anaccess control technology

    We use IDS to let us know what's happening on our networks, how our policy is being enforced by our access control mechanisms and when there are security failures.

    We use IPS to "shoot down" attacks that are in flight before they can complete and affect the target.

    Confusing the two is the name of the game for IPS vendors because the FW vendors have deep pockets and the IPS guys didn't want to rock the boat at first. In-line network IPS is only useful as long as you have time to provision new detection signatures before attacks/worms come out, they are deterministic and therefore have a very tough time dealing with the unknown (and yes, I know they have the ability to do rate-based blocking in some cases, that's deterministic too). The natural progression for IPS technology is as a feature on a firewall, not as a stand alone independent product, it's just an enhancement to access control technology after all. The natural progression of IDS will remain as a stand alone product or perhaps it will disappear into the infrastructure of the network itself (e.g. switches), but it is going to be a necessity as long as people need to have visibility into what's happening outside the purview of their access control technologies. In-line network IPS only watches/defends your peering points, NIDS monitors everything if deployed properly.

    To claim that IDS is "dead" is to basically say that people should put on blinders and only watch the peering points, not a very realistic proposition in my opinion. IPS is not a replacement for IDS, those who say so either don't understand the role of IDS or they're selling something.

    1. Re:One more thing by Anonymous Coward · · Score: 1, Interesting
      I'm sure you've thought of it this way, oh wise oracle of Snort, but maybe turn your thinking of FW vs IPS around: An IPS is a firewall-plus. In-line IPS's can eliminate a need for firewalls, since it's trivial to set firewall-ish rules there. Is there some reason against this, other than customer inertia? I understand the performance gap between software and ASIC-based firewalls, but performance seems sufficient for most uses at this point. Put another way, I'd say the natural progression is to move from firewalls to IPS, with simple firewalls becoming obsolete.

      Further, while I respect you conservatively saying IPS won't help against zero-day stuff, IPS is useful immediately for all former signatures. There are so many compromised machines yammering out old attack patterns, a handful of base rules can silence them forever in ways a simple firewall can't do. People love that, where we've set it up.

      As for 'provisioning new signatures', I've been waiting for you to boil rules down to another service-oriented mechanism, providing updates much like AntiVirus, for an annual fee. To be honest, there are several damn-useful technologies that I can't recommend to small businesses mostly because there isn't an inexpensive source for expert maintenance/support. Automation, trust, and expertise in ensuring/responding to zero-false-positive issues would be why customers would pay you for autodeploying these 'free' rules. Oh, and for the call center for supporting false-neg/false-pos questions.

      I do agree that IPS vendors aren't yet doing a remarkable job of tackling the firewall-vendor hegemony (pauses, considers setting the 'post as anonymous' flag). Perhaps modularizing some rules then sticking them into a GUI that resembles firewalls is part of the answer. Familiarity is a big selling point when the customer doesn't have time to spare. Or maybe the answer is redeclaring the battlefield itself: stop calling it IPS and embrace the firewall name with "100% firewall functionality plus (insert buzzword like 'in-packet inspection', akin to 'stateful inspection' improvements to firewalls that have become standard). Everyone knows they need a firewall. Make them want a 'firewall with subpacket filtering' or whatever you name it. Otherwise, it'll be like a project I'm doing now, with the packets flowing (redundantly) thru an IPS to a firewall to the protected equipment.

      Keep up the good ^h^h^h^h great work.

  61. Did anyone else read this incorrectly?? by Reenigne · · Score: 1

    "snort up for revamp," says creator. What ever you say lord, I could do with a topup! =)

    --
    Why can I not mod a message to crap?!?
  62. Re:Eliminate large security network centers with I by Dark+Coder · · Score: 1

    Bammkkkk,

    Ok, ok... I'll suck it up. I, personally, wouldn't go without monitoring myself either.

    So, I do agree with you wholely on all your points.

    Could you at least agree that prevention is the forefront cornerstone of all defense mechanism?

    After all, prevention is a frequent dictum in the "Arts of War."

  63. Re:Eliminate large security network centers with I by bamm · · Score: 1

    Yes, I truly believe that IPSs/application FWs are the direction those assets belonging to the 'prevention' category need to go (see my previous post about prevention, monitoring, response).

    I think there are some fundamental _business_ problems for the IPS guys.

    Number one, some of those (IPS) products seem to be a lot like their IDS cousins and selling something that doesn't work as expected or isn't useful as implemented. Number two, IPS companys have to take on those huge goliaths of FW companys. I think that is the reason a very good technology (IPS) went after a market hindered by bad implentations (IDS) even though I don't see them as direct competitors. Blame it on the damn marketers.

    Sorry for the late post, but I thought you deserved a response.

    --
    www.sguil.net
    The Analyst Console for NSM