FW: Snort-users digest, Vol 1 #5042 - 7 msgs

["Cobb, John W." <cobbjw () ornl gov>]

Unsubscribe cobbjw () ornl gov

End


-----Original Message-----
From: snort-users-admin () lists sourceforge net
[mailto:snort-users-admin () lists sourceforge net] On Behalf Of
snort-users-request () lists sourceforge net
Sent: Sunday, March 27, 2005 2:14 AM
To: snort-users () lists sourceforge net
Subject: Snort-users digest, Vol 1 #5042 - 7 msgs

Send Snort-users mailing list submissions to
        snort-users () lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/snort-users
or, via email, send a message with subject or body 'help' to
        snort-users-request () lists sourceforge net

You can reach the person managing the list at
        snort-users-admin () lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Snort-users digest..."


Today's Topics:

   1. Re: Base Barnyard and Unified Logs (Dirk Geschke)
   2. Could you please deselect me from your mailing list ?  thanks
(Mark Fosseth)
   3. RE: Could you please deselect me from your mailing list ?  thanks
(Patrick Harper)
   4. Re: Base Barnyard and Unified Logs (Wes Young)
   5. Re: Snort rule lookup from ACID broken?? (ricter () ono com)
   6. Question on tags (Kevin Smith)
   7. Problem with "data link type 113" (Lukas 'tinLoaf' Barth)

--__--__--

Message: 1
From: Dirk Geschke <dirk () geschke-online de>
Date: Sat, 26 Mar 2005 11:47:57 +0100
To: Jerry <gll () inel gov>
Cc: Wes Young <wcyoung () buffalo edu>, Joel Esler <esler () knology net>,
        "Esler, Joel CNTR/Sytex" <joel.esler () rcert-s army mil>,
        Paul Schmehl <pauls () utdallas edu>,
snort-users () lists sourceforge net
Subject: Re: [Snort-users] Base Barnyard and Unified Logs

Hi Jerry,

> Just saw the discussion about barnyard and DB's.  Here is some info 
> I gained in having to deal with consolidating data from two snort 
> DB's in to a single application.
>
> Now that generators have been assigned to various parts of snort, 
> they need to be employed in the DB schema (generator:sid:rev) as 
> a key to a signature.  The generator-id is needed since the
> pre-processors usually start the SIDS=1!  The problem becomes more 
> complicated in that the signature, sensor, reference, and 
> classification tables are built on the fly by the DB-plugins.  The
> plugins first try to grab the signature from the DB using msg 
> (sig_name), Rev (sig_rev) and SID (sig_sid). If found then use 
> the assigned (via MySql auto-increment) sig_id.  If not, create the
> record.  Note that the generator-id is never mentioned in the DB.
>
> The signature, sensor, reference and classification tables are 
> "normalized" tables created on-the-fly by the database plugin.  Their
> ordinal (created by the order of insertion) is used in the
> other tables (eg. event) to save time and space.
> If you are only using a single DB, there isn't any problem, except as
> Joel wrote below, if you have to clean the DB, your mapping between 
> SID ->(sig_name,sig_sid,sig_rev) is lost.  If you are combining the 
> two DB's, for example an inside and an outside, into a single 
> application/DB like we are, you run in to data collisions and race
> conditions.
>
>
> To solve these issues, I ended up writing scripts to insert (read 
> preload) the following tables:
>       .signature, from all of the rules
>       .sensor (including the 'read from file' entries)
>       .reference (reference.config), and
>       .classification (classification.config)
> The input to the scripts will never shrink.  Thus I will maintain 
> the mapping.

a similar script exists as part of FLoP: rules.pl. It inserts all
rules of the signature files to the database. This would also speed
up insertiion of alerts since the signature is already part of the
database.

To solve the generator-id problem we use a hack, if the alert is
not created by a "normal" rule, e.g created by a pre-processor
then we insert the generator id in the field sig_rev since the
revision is neither defined for preprocessors nor would there
be any change within it. The big problem is that the generator
id was never thought of as the database design was made. And
more complicated, ACID/BASE won't use it...

To learn more about FLoP take a look at

  http://www.geschke-online.de/FLoP/

Maybe you can use some of the tools which are part of the project
or you can use it at all...

Best regards

Dirk


--__--__--

Message: 2
From: "Mark Fosseth" <brundleflynet () hotmail com>
To: Snort-users () lists sourceforge net
Date: Sat, 26 Mar 2005 11:10:23 +0000
Subject: [Snort-users] Could you please deselect me from your mailing
list ?  thanks






--__--__--

Message: 3
From: "Patrick Harper" <patrick () internetsecurityguru com>
To: "'Mark Fosseth'" <brundleflynet () hotmail com>,
   <Snort-users () lists sourceforge net>
Subject: RE: [Snort-users] Could you please deselect me from your
mailing list ?  thanks
Date: Sat, 26 Mar 2005 06:17:15 -0600

Dude, read the bottom, you selected to be on it in the first place (you
had
to send a confirmation e-mail) and it had instructions on how to leave. 



Patrick S. Harper | CISSP RHCT MCSE
www.internetsecurityguru.com 

 
-----Original Message-----
From: snort-users-admin () lists sourceforge net
[mailto:snort-users-admin () lists sourceforge net] On Behalf Of Mark
Fosseth
Sent: Saturday, March 26, 2005 5:10 AM
To: Snort-users () lists sourceforge net
Subject: [Snort-users] Could you please deselect me from your mailing
list ?
thanks






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
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




--__--__--

Message: 4
Cc: Paul Schmehl <pauls () utdallas edu>,
        Joel Esler <esler () knology net>,
        "Esler, Joel CNTR/Sytex" <joel.esler () rcert-s army mil>,
        snort-users () lists sourceforge net, Jerry <gll () inel gov>
From: Wes Young <wcyoung () buffalo edu>
Subject: Re: [Snort-users] Base Barnyard and Unified Logs
Date: Sat, 26 Mar 2005 09:21:36 -0500
To: Dirk Geschke <dirk () geschke-online de>


--Apple-Mail-1-395710371
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
        charset=US-ASCII;
        format=flowed

These hacks all are great in theory...i'd rather just rip out the CID 
in the signature table.
  I really like populating the sig table pre-emptively, that I might do 
reguardless, but software
ppl need to revolve their "viewing" software around the sid. I think 
the PK that originally was in place (cid or whatever) was before
SID's were even involved and everything was just PK'd on the msg... 
(hense making the CID important in the DB schema, but not in
real life. If you re-vamp the output plugin along with the schema to 
reflect everything being key'd on the sid, the system would scale
much higher when you start incorporating more databases with teh 
product (i have about 4 diff db's that rely on the one snort_log
alone, not to mention the snort_alerts, all work well untill I have to 
clear one of them, i clear one, 2 of them have to be flushed and
re-init'd as well because of the stupid CID auto-increment stuff, and 
no, aanval (atleast the older version) isn't totally exempt
from this problem either). If they were all SID based, the joins would 
be fine reguardless of what i flush.

Actually the db plugin doesn't really have to be re-written come to 
think of it, just rip out the CID and base your software on the SID.
IMO that key shouldn't even be there.

I think the original problem I was having was because i re-init'd one 
of my databases and it threw off the rest, i didnt check to make sure 
base was ok until i had a 1G database of logs, by then it was too late 
and it labeled every sig as it's SID within base...

On Mar 26, 2005, at 5:47 AM, Dirk Geschke wrote:

> Hi Jerry,
>
> > Just saw the discussion about barnyard and DB's.  Here is some info
> > I gained in having to deal with consolidating data from two snort
> > DB's in to a single application.
> >
> > Now that generators have been assigned to various parts of snort,
> > they need to be employed in the DB schema (generator:sid:rev) as
> > a key to a signature.  The generator-id is needed since the
> > pre-processors usually start the SIDS=1!  The problem becomes more
> > complicated in that the signature, sensor, reference, and
> > classification tables are built on the fly by the DB-plugins.  The
> > plugins first try to grab the signature from the DB using msg
> > (sig_name), Rev (sig_rev) and SID (sig_sid). If found then use
> > the assigned (via MySql auto-increment) sig_id.  If not, create the
> > record.  Note that the generator-id is never mentioned in the DB.
> >
> > The signature, sensor, reference and classification tables are
> > "normalized" tables created on-the-fly by the database plugin.  Their
> > ordinal (created by the order of insertion) is used in the
> > other tables (eg. event) to save time and space.
> > If you are only using a single DB, there isn't any problem, except as
> > Joel wrote below, if you have to clean the DB, your mapping between
> > SID ->(sig_name,sig_sid,sig_rev) is lost.  If you are combining the
> > two DB's, for example an inside and an outside, into a single
> > application/DB like we are, you run in to data collisions and race
> > conditions.
> >
> >
> > To solve these issues, I ended up writing scripts to insert (read
> > preload) the following tables:
> >      .signature, from all of the rules
> >      .sensor (including the 'read from file' entries)
> >      .reference (reference.config), and
> >      .classification (classification.config)
> > The input to the scripts will never shrink.  Thus I will maintain
> > the mapping.
>
> a similar script exists as part of FLoP: rules.pl. It inserts all
> rules of the signature files to the database. This would also speed
> up insertiion of alerts since the signature is already part of the
> database.
>
> To solve the generator-id problem we use a hack, if the alert is
> not created by a "normal" rule, e.g created by a pre-processor
> then we insert the generator id in the field sig_rev since the
> revision is neither defined for preprocessors nor would there
> be any change within it. The big problem is that the generator
> id was never thought of as the database design was made. And
> more complicated, ACID/BASE won't use it...
>
> To learn more about FLoP take a look at
>
>   http://www.geschke-online.de/FLoP/
>
> Maybe you can use some of the tools which are part of the project
> or you can use it at all...
>
> Best regards
>
> Dirk
--
Wes

I wish I could come up with some witty sigs

--Apple-Mail-1-395710371
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
        charset=US-ASCII

These hacks all are great in theory...i'd rather just rip out the CID
in the signature table.

 I really like populating the sig table pre-emptively, that I might do
reguardless, but software

ppl need to revolve their "viewing" software around the sid. I think
the PK that originally was in place (cid or whatever) was before

SID's were even involved and everything was just PK'd on the msg...
(hense making the CID important in the DB schema, but not in

real life. If you re-vamp the output plugin along with the schema to
reflect everything being key'd on the sid, the system would scale

much higher when you start incorporating more databases with teh
product (i have about 4 diff db's that rely on the one snort_log

alone, not to mention the snort_alerts, all work well untill I have to
clear one of them, i clear one, 2 of them have to be flushed and

re-init'd as well because of the stupid CID auto-increment stuff, and
no, aanval (atleast the older version) isn't totally exempt 

from this problem either). If they were all SID based, the joins would
be fine reguardless of what i flush.


Actually the db plugin doesn't really have to be re-written come to
think of it, just rip out the CID and base your software on the SID.

IMO that key shouldn't even be there.


I think the original problem I was having was because i re-init'd one
of my databases and it threw off the rest, i didnt check to make sure
base was ok until i had a 1G database of logs, by then it was too late
and it labeled every sig as it's SID within base...


On Mar 26, 2005, at 5:47 AM, Dirk Geschke wrote:


<excerpt>Hi Jerry,


<excerpt>Just saw the discussion about barnyard and DB's.  Here is
some info 

I gained in having to deal with consolidating data from two snort 

DB's in to a single application.


Now that generators have been assigned to various parts of snort, 

they need to be employed in the DB schema (generator:sid:rev) as 

a key to a signature.  The generator-id is needed since the

pre-processors usually start the SIDS=1!  The problem becomes more 

complicated in that the signature, sensor, reference, and 

classification tables are built on the fly by the DB-plugins.  The

plugins first try to grab the signature from the DB using msg 

(sig_name), Rev (sig_rev) and SID (sig_sid). If found then use 

the assigned (via MySql auto-increment) sig_id.  If not, create the

record.  Note that the generator-id is never mentioned in the DB.


The signature, sensor, reference and classification tables are 

"normalized" tables created on-the-fly by the database plugin.  Their

ordinal (created by the order of insertion) is used in the

other tables (eg. event) to save time and space.

If you are only using a single DB, there isn't any problem, except as

Joel wrote below, if you have to clean the DB, your mapping between 

SID ->(sig_name,sig_sid,sig_rev) is lost.  If you are combining the 

two DB's, for example an inside and an outside, into a single 

application/DB like we are, you run in to data collisions and race

conditions.



To solve these issues, I ended up writing scripts to insert (read 

preload) the following tables:

        .signature, from all of the rules

        .sensor (including the 'read from file' entries)

        .reference (reference.config), and

        .classification (classification.config)

The input to the scripts will never shrink.  Thus I will maintain 

the mapping.

</excerpt>

a similar script exists as part of FLoP: rules.pl. It inserts all

rules of the signature files to the database. This would also speed

up insertiion of alerts since the signature is already part of the

database.


To solve the generator-id problem we use a hack, if the alert is

not created by a "normal" rule, e.g created by a pre-processor

then we insert the generator id in the field sig_rev since the

revision is neither defined for preprocessors nor would there

be any change within it. The big problem is that the generator

id was never thought of as the database design was made. And

more complicated, ACID/BASE won't use it...


To learn more about FLoP take a look at


  http://www.geschke-online.de/FLoP/


Maybe you can use some of the tools which are part of the project

or you can use it at all...


Best regards


Dirk




</excerpt><fontfamily><param>Helvetica</param>--

Wes


I wish I could come up with some witty sigs</fontfamily>


--Apple-Mail-1-395710371--



--__--__--

Message: 5
Date: Sat, 26 Mar 2005 17:38:45 +0100
From: ricter () ono com
Subject: Re: [Snort-users] Snort rule lookup from ACID broken??
To: snort-users () lists sourceforge net


I've found that if you change the line 

"snort"     =3D> array("http://www.snort.org/snort-db/sid.html?sid=3D";,
"=
"),

for

"snort"     =3D> array("http://www.snort.org/pub-bin/sigs.cgi?sid=3D";,
""=
),

acid works fine

Cheers

ricter




--__--__--

Message: 6
Date: Sat, 26 Mar 2005 15:51:19 -0500
From: Kevin Smith <kjsmith () tm net>
To:  snort-users () lists sourceforge net
Subject: [Snort-users] Question on tags

Hey everyone,

I finally got snort, barnyard, and mysql working together. For some odd 
reason it does not like simply mepis with mysql 4.1. I used Pro mepis 
with mysql 4.0.2 and it worked without a problem.

My question is about the tag keyword. I'm a little confused as to how it

works. Say ten packets come over the interface, does it grab all in time

x and log it as 1, but oviously the size is bigger with the payload. Or 
does it still log all of them sperataly after the time has expired? Also

in the manual it says that tagged packets are not properly logged in a 
database. Is it after a certain amount of time? Or what happens when it 
tries to log to a database. My goal is to lower the amount of entries in

the database of traffic that we are looking at, there are about 15,000 
packets in 10 minutes. I would like to use the tag option to lower the 
amount of entries in the database if that is possible. Or is there a 
better way to do that?

Thanks again for everyone's help
Kevin


--__--__--

Message: 7
Date: Sun, 27 Mar 2005 00:59:12 +0100
From: "Lukas 'tinLoaf' Barth" <tinloaf () goerresonline de>
To: snort-users () lists sourceforge net
Subject: [Snort-users] Problem with "data link type 113"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I know this problem has been discussed before, but the solutions
mentioned there dont work for me: when I start snort, I'm getting the
message

"snort cannot handle data link type 113
Exiting..."

Searching google I found out that I have to use at least libpcap version
0.6.2, but my installed version is 0.7.2 and I get the error anyway.

Can someone help me with this problem?

thanks,

Lukas Barth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCRfdQgsbFi6ZpoGERAmgAAJ9pSkjaOhf8W0tS4Zudw2sRY3ZC5gCfTDMB
+LhCGA4ZK2/8hH4TY8eBc28=
=iWzK
-----END PGP SIGNATURE-----



--__--__--

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-users


End of Snort-users Digest


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
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