[Snort-devel] RE: Snort-devel digest, Vol 1 #290 - 7 msgs

Gary Gamerman ggamerman at ...439...
Wed May 23 15:36:49 EDT 2001


Craig...when you write the rule handlers (rule database, parsers, editors) keep SNORT 1.8 rule formats in mind as I expect 1.8 to be availible by the end of the year

-----Original Message-----
From: snort-devel-admin at lists.sourceforge.net
[mailto:snort-devel-admin at lists.sourceforge.net]On Behalf Of
snort-devel-request at lists.sourceforge.net
Sent: Wednesday, May 23, 2001 3:06 PM
To: snort-devel at lists.sourceforge.net
Subject: Snort-devel digest, Vol 1 #290 - 7 msgs


Send Snort-devel mailing list submissions to
	snort-devel at lists.sourceforge.net

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

You can reach the person managing the list at
	snort-devel-admin at lists.sourceforge.net

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


Today's Topics:

   1. Re: defrag and stream in snort-1.7 (Martin Roesch)
   2. classification changes (Brian Caswell)
   3. Re: classification changes (Chris Green)
   4. Re: classification changes (Brian Caswell)
   5. Re: [Snort-users] Re: [Snort-devel] classification changes (Mike Johnson)
   6. Re: [Snort-users] classification changes (Max Vision)
   7. Re: classification changes (Chris Green)

--__--__--

Message: 1
Date: Wed, 23 May 2001 00:25:08 -0400
From: Martin Roesch <roesch at ...402...>
To: Burak DAYIOGLU <dayioglu at ...287...>
CC: snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] defrag and stream in snort-1.7

Yes, we're here but I for one have been busy with several conferences.=20
Now that I'm finally back home, I'm going to probably take about a day
or three to get through the 795 messages in my inbox.  Pity me and
please be patient. ;)

     -Marty

Burak DAYIOGLU wrote:
>=20
> =BC=D6=BA=EC=CA=AF wrote:
> > I tested defrag using fragrouter,but it did not seem to work.
> > Are there any bugs in defrag and stream preprocessor in snort-1.7
> > or my test method is wrong ?
>=20
> If fragrouter can create overlapping fragments to test it will be
> obvious that Snort will not be able to catch up.
>=20
> I wrote an email to Mr. Roesch and Mr. Rui regarding overlapping
> fragments and one easy way to overcome this (roughly 2 weeks ago)
> with no answer back. Are they on the list listening?
>=20
> regards,
> -bd
>=20
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel

--
Martin Roesch
roesch at ...402...
http://www.sourcefire.com - http://www.snort.org


--__--__--

Message: 2
Date: Wed, 23 May 2001 02:11:49 -0400
From: Brian Caswell <bmc at ...227...>
Organization: The MITRE Corporation
To: snort-users at lists.sourceforge.net, snort-devel at lists.sourceforge.net
Subject: [Snort-devel] classification changes

This is a multi-part message in MIME format.
--------------AFF79F484E4206FB6D115A1D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We are going to change the classification for the Snort.org ruleset. 
Sorry IDWG guys, your classifications.  The IDWG classifications are
just not viable.  I tried.  Its really bad.  

Attached is the classification.config that will be included with snort
1.8.1 (Well, included into CVS as soon as I can clean up the rules)

If you have wishes/requests for default classifications, let me know
ASAP.  I will start changing rules within the next 2 days.

-- 
Brian Caswell
The MITRE Corporation
--------------AFF79F484E4206FB6D115A1D
Content-Type: text/plain; charset=us-ascii;
 name="class"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="class"

config classification: information,Informational Alert,4
config classification: policy-violation,Policy Violation,3
config classification: port-access,Port Scan,3
config classification: information-leak,Information Leak,3
config classification: misc-suspicious,Suspicious Traffic,2
config classification: port-scan,Port Scan,2
config classification: host-mapping,Host Mapping,2
config classification: attack-responce,Responce from an Attack,2
config classification: attempted-url-access,Attempted URL Access,2
config classification: attempted-url-exploit,Attempted URL Exploit,1
config classification: attempted-admin, Attempted User Privilage Gain,1
config classification: attempted-user, Attempted Administrative Privilage Gain,1

--------------AFF79F484E4206FB6D115A1D--



--__--__--

Message: 3
To: snort-users at lists.sourceforge.net
Cc: snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] classification changes
Reply-To: snort-devel at lists.sourceforge.net, snort-users at lists.sourceforge.net
From: Chris Green <cmg at ...81...>
Date: 23 May 2001 08:16:17 -0500

[ is there anyone on devel that isn't on users? ]

Brian Caswell <bmc at ...227...> writes:

> We are going to change the classification for the Snort.org ruleset. 
> Sorry IDWG guys, your classifications.  The IDWG classifications are
> just not viable.  I tried.  Its really bad.  

Yes for right now, a good bit of the priorities aren't worth watching.
This is partially due to weird classicfactions like "bad-unknown" and
partially tdue to snort not having a to easily differentiate between
an attempted- and a successful-

To do this, nearly a whole set of rules that operate only on stuff
once tagged seems to be to separate the CMD.EXE 200's from the CMD.EXE
404s or whatever.

> Attached is the classification.config that will be included with snort
> 1.8.1 (Well, included into CVS as soon as I can clean up the rules)
> 
> If you have wishes/requests for default classifications, let me know
> ASAP.  I will start changing rules within the next 2 days.
>

Atleast keep the same order that was already defined where larger
numerical magnitude means higher priority.

I don't think url-access/exploit are any different than attempted-user
in the large scheme of things.

service-probe for like a bind.version
attempted-admin for an root exploit

attempted-user for an exploit that will give you nobody privledges

host-mapping == os identification? That sounds like a specific
information


> -- 
> Brian Caswell
> The MITRE Corporation
> 
> config classification: information,Informational Alert,4
> config classification: policy-violation,Policy Violation,3
> config classification: port-access,Port Scan,3
> config classification: information-leak,Information Leak,3
> config classification: misc-suspicious,Suspicious Traffic,2
> config classification: port-scan,Port Scan,2
> config classification: host-mapping,Host Mapping,2
> config classification: attack-responce,Responce from an Attack,2
> config classification: attempted-url-access,Attempted URL Access,2
> config classification: attempted-url-exploit,Attempted URL Exploit,1
> config classification: attempted-admin, Attempted User Privilage Gain,1
> config classification: attempted-user, Attempted Administrative Privilage Gain,1

-- 
Chris Green <cmg at ...81...>
A good pun is its own reword.


--__--__--

Message: 4
Date: Wed, 23 May 2001 09:53:31 -0400
From: Brian Caswell <bmc at ...227...>
Organization: The MITRE Corporation
To: snort-devel at lists.sourceforge.net, snort-users at lists.sourceforge.net
Subject: Re: [Snort-devel] classification changes

Chris Green wrote:
> [ is there anyone on devel that isn't on users? ]

no idea.  Since this affects both developers AND users, I e-mailed
both.

> > Attached is the classification.config that will be included with snort
> > 1.8.1 (Well, included into CVS as soon as I can clean up the rules)
> >
> > If you have wishes/requests for default classifications, let me know
> > ASAP.  I will start changing rules within the next 2 days.
> >
> 
> Atleast keep the same order that was already defined where larger
> numerical magnitude means higher priority.

Thats a simple change in your classification.config

Since many NIDS shops use RealSecure and snort, I've elected to make
the default priorities follow sort of the same scheme.  (With a bit
more brain cells to classifying rules, that's for sure)

If there is a generalized consent that we want priorities done in low
to high instead of high to low, then I'll change it.  NOTE:  That
means if you want it, you MUST speak up.

> I don't think url-access/exploit are any different than attempted-user
> in the large scheme of things.

Actually, I do.  One is an exploit.  One is just a probe.  I'm much
more concerned if someone does /scripts/../../../winnt/cmd.exe than if
they do /cgi-bin/phf

> service-probe for like a bind.version
> attempted-admin for an root exploit
> 
> attempted-user for an exploit that will give you nobody privledges
> 
> host-mapping == os identification? That sounds like a specific
> information

host-mapping would contain NMAP probes, and things host -> many hosts
targetting a single port.  Actually, I will be releasing HOMER soon,
an alert correlation engine that we at MITRE have developed.  (See the
SANS paper on Intrusion Detection & Data Mining)  This classification
is used by those things.  

-- 
Brian Caswell
The MITRE Corporation


--__--__--

Message: 5
Date: Wed, 23 May 2001 10:54:24 -0400
From: Mike Johnson <mike at ...438...>
To: snort-devel at lists.sourceforge.net,
	snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] Re: [Snort-devel] classification changes

Chris Green [cmg at ...81...] wrote:
> 
> Brian Caswell <bmc at ...227...> writes:
> 
> > We are going to change the classification for the Snort.org ruleset. 
> > Sorry IDWG guys, your classifications.  The IDWG classifications are
> > just not viable.  I tried.  Its really bad.  
> 
> Yes for right now, a good bit of the priorities aren't worth watching.
> This is partially due to weird classicfactions like "bad-unknown" and
> partially tdue to snort not having a to easily differentiate between
> an attempted- and a successful-

I'm actually quite happy with the current priorities.  I simply
filter out the first three (not-suspicious, unknown, bad-unknown).
I like that they're there, though, in case I want to have a
better view of my network. 

In the end, I'll cope.  I always knew using code from CVS was
subject to change.
 
> To do this, nearly a whole set of rules that operate only on stuff
> once tagged seems to be to separate the CMD.EXE 200's from the CMD.EXE
> 404s or whatever.

There's already some rules that have successful- tags.  I think
I only noticed one or two that weren't DDoS related (like zombie to
handler comminucations), though.  But separating the CMD.EXE's like
you mention could bequite useful.

> Atleast keep the same order that was already defined where larger
> numerical magnitude means higher priority.

Consider this a 'me too' vote.  Both methods have their disadvantages
when it comes to adding new priorities (you can't insert a new
rule with a discrete (no other rules with this priority) priority of 2  
into either without renumbering most all of them.  But I'm quite used
to a higher number meaning a higher priority.
 
> I don't think url-access/exploit are any different than attempted-user
> in the large scheme of things.

Agreed.  Exploiting a cgi grants user access at best, or on IIS
boxes it grants admin.
 
> service-probe for like a bind.version

Currently attempted-recon.  At the very least, I like the 
service-probe name better as it's a bit more descriptive as to
what's going on.  But what about probes for listening trojans
and looking for zombies?

> attempted-admin for an root exploit

Certainly.
 
> attempted-user for an exploit that will give you nobody privledges

Or whatever user your daemon runs as.
 
Mike
-- 
If at first you don't succeed, destroy all evidence that you tried -- unknown


--__--__--

Message: 6
Date: Wed, 23 May 2001 08:01:17 -0700
To: Brian Caswell <bmc at ...227...>, snort-users at lists.sourceforge.net,
   snort-devel at lists.sourceforge.net
From: Max Vision <vision at ...195...>
Subject: [Snort-devel] Re: [Snort-users] classification changes

At 02:11 AM 5/23/2001 -0400, Brian Caswell wrote:
>We are going to change the classification for the Snort.org ruleset.
>Sorry IDWG guys, your classifications.  The IDWG classifications are
>just not viable.  I tried.  Its really bad.
>Attached is the classification.config that will be included with snort
>1.8.1 (Well, included into CVS as soon as I can clean up the rules)
>If you have wishes/requests for default classifications, let me know
>ASAP.  I will start changing rules within the next 2 days.
I wrote some info about this before but had email problems and it seems to 
be gone (and not sent).  Basically we came up with a good classification 
system last week that has so far been a good fit for all of the intrusion 
events.  You can see this implemented at 
http://whitehats.com/ids/vision18.conf.gz

You can see an overview of how this breaks down at:
http://whitehats.com/cgi/arachNIDS/BrowseTree?field=classtype&order=COUNT

The system we came up with is the following 20 classifications:
  not suspicious  (policy foo)
  suspicious (miscellaneous such as source routing ip opts)
  info / attempt,success,failed (information gathering)
  relay / attempt,success,failed (relay vuln like socks, spam, etc)
  data / attempt,success,failed (data integrity, such as snmp write)
  system / attempt,success,failed (system integrity, such as shell access)
  client / attempt,success,failed (client software attacks)
  data-or-info-attempt
  system-or-info-attempt
  relay-or-info-attempt

This allowed us to classify each known intrusion event. It was a struggle 
with the IDWG system.  The last three categories were required since we 
have a lot of events where we can't see clearly which class the event is 
in.  For example, a signature to catch just "phf" in uricontent data would 
catch either an information gathering probe (is phf there?) or a system 
integrity attempt (let's push this linefeed through and run some 
commands).  So it would be inappropriate to pick one or the other unless 
there were several very specific variations of the signature to case each 
case.  I can list some examples of why these classifications were chosen is 
anyone needs the info.

Max



--__--__--

Message: 7
To: snort-devel at lists.sourceforge.net, snort-users at lists.sourceforge.net
Subject: Re: [Snort-devel] classification changes
Reply-To: snort-devel at lists.sourceforge.net, snort-users at lists.sourceforge.net
From: Chris Green <cmg at ...81...>
Date: 23 May 2001 11:24:26 -0500

Brian Caswell <bmc at ...227...> writes:
> > I don't think url-access/exploit are any different than attempted-user
> > in the large scheme of things.
> 
> Actually, I do.  One is an exploit.  One is just a probe.  I'm much
> more concerned if someone does /scripts/../../../winnt/cmd.exe than if
> they do /cgi-bin/phf

Thats what I was trying to say. Didn't say it clearly enough

> > service-probe for like a bind.version
> > attempted-admin for an root exploit
> > 
> > attempted-user for an exploit that will give you nobody privledges

phf would be a service-probe, cmd would be an attempted-user

I was arguing that url-attempt / url-exploit are the same as a
service-probe and an attempted-user-exploit


> > host-mapping == os identification? That sounds like a specific
> > information
> 
> host-mapping would contain NMAP probes, and things host -> many hosts
> targetting a single port.  Actually, I will be releasing HOMER soon,
> an alert correlation engine that we at MITRE have developed.  (See the
> SANS paper on Intrusion Detection & Data Mining)  This classification
> is used by those things.  

Ah, I would have called host-mapping "network-mapping".

-- 
Chris Green <cmg at ...81...>
"Yeah, but you're taking the universe out of context."



--__--__--

_______________________________________________
Snort-devel mailing list
Snort-devel at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/snort-devel


End of Snort-devel Digest


More information about the Snort-devel mailing list