Damiano Bolzoni wrote: > On 19/03/2009 1.49, Martin Roesch wrote: >> You guys do know that anything you can't do in the Snort rules >> language natively can be done using .so rules, right? Write your >> rules in C, store data statefully within Snort, manipulate things like >> flowbits that other rules can reference, pretty much anything you care >> to do in C. The only thing you can't do with it is generate >> pseudopackets for other subsystems to analyze. > > Marty, > .so rules offer indeed a high degree of personalization. However, you > need to know what you're doing...it's C code, and we all know what that > means. I would like to see a "neater" way to do that, with something > more similar to "normal" Snort rules. I know there is a price to pay for > this: I won't be able to push the analysis so in depth as with a .so > rule. But I believe a user would prefer the rule to the C code...perhaps > I'm wrong :) >
This seems to be as good a place as any to step in. One of the goals of the Realeyes IDS project (http://realeyes.sourceforge.net) is to detect behavior. It attempts to achieve this by using a multi-level rule definition format. The lowest level, Triggers, are combined into Actions, which are in turn combined into Events. This means that you can monitor for SQL injection attempts by defining several columns of the target table. Those values can be detected in any order and the Action will still fire. There are parms for setting min/max distance between the Triggers and EOL strings such as '</script>' can be used to define groupings. The next level allows Actions to be found in opposite halves of a TCP session to cause Events to fire. This means that an Action detecting an FTP login request can be matched with multiple FTP server rejections to detect brute force login attacks. I've actually got this defined in the pilot project I'm running for the project. Triggers and Actions may be defined with the NOT flag, which allows conditions to be set for discarding detected Events, and helps reduce false positives. Also, there are specialty rules, such as time monitoring, which allows a specific server to be monitored between midnight and 5:00 am for example. The definitions are read by the sensors from XML files which are defined by using the application GUI. The most recent updates (to be released in the next download package) handle fairly thorough context checking. Later . . . Jim Lead developer of the Realeyes IDS
