Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Users
[Top] [All Lists]

Re: [Snort-users] A "Flowbits" issue

Subject: Re: [Snort-users] A "Flowbits" issue
Date: Wed, 5 Dec 2007 19:59:56 -0500
Hi,
I got a "Segmentation fault" with Snort 2.8.0.1 when I tried to
declare a new alert type, configured the order and used it in a rule
as you suggested. Is it a bug in Snort 2.8.0.1?
Thanks,
Tung.

On Dec 2, 2007 7:02 PM, tung tran <tunghack@gmail.com> wrote:
Great explanation !!!
Thanks,
Tung.


On Dec 2, 2007 3:37 PM, Jason Brvenik <jasonb@sourcefire.com> wrote:


tung tran wrote:
Hi,
My question is:should we use "flowbits" to check a packet against
multiple rules or we only use "flowbits" to check next coming packets?

yes but...

The behavior is not guaranteed and it's effectiveness is dependent on
the order of the rules. You must have the flowbits:set before the isset.

Given this constraint, there is generally no reason to do this because
in order for them to match, the same packet must have both qualifying
contents.

Except...

When there are multiple paths to a single end state for the final rule.

EG:

content:"bob"; flowbits:set,seen.suspect.user;
content:"alice"; flowbits:set,seen.suspect.user;
content:"jane"; flowbits:set,seen.suspect.user;

flowbits:isset,seen.suspect.user;content:"ccdata";

In this case we are looking for suspect users that are accessing credit
card data. It will immediately flag the packet(s) provided that they are
ordered correctly in the rules file.

You could just as easily use a single PCRE to locate the users but there
would be a different performance profile involved.

If you want to ensure that the rules are always evaluated in the desired
order you can define new rule types.

ruletype alert2
{
 type alert
}

Then use rules as folows.

alert tcp 192.168.0.1 any -> any any (msg:"Seen bob"; content:"bob";
flowbits:set,seen.suspect.user; sid:1000000; rev:1;)

alert tcp 192.168.0.1 any -> any any (msg:"Seen alice"; content:"alice";
flowbits:set,seen.suspect.user; sid:1000001; rev:1;)

alert tcp 192.168.0.1 any -> any any (msg:"Seen jane"; content:"jane";
flowbits:set,seen.suspect.user; sid:1000002; rev:1;)

alert2 192.168.0.1 any -> any any (msg:"suspect user access of ccdata";
flowbits:isset,seen.suspect.user; content:"ccdata"; sid:1000003; rev:1;)

and then set order using either -o

or

config order: pass drop alert alert2 log

The cases where you might want to do something like this are extremely
rare but I've seen them in the past.



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

<Prev in Thread] Current Thread [Next in Thread>