argus and snort ?

[Chas DiFatta]

What is the down side of capturing over 64 bytes?  64
is a bare minimum for long posts?  I vote for 128.

	...cd

> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com]
> Sent: Monday, September 11, 2000 6:59 PM
> To: chas at freeworks.com; 'Russell Fulton'; 'argus'
> Subject: RE: argus and snort ?
> 
> 
> Hey Guys,
>    I see Argus as having two HUGE benefits.  Auditing
> all transactions, and generating a manageable persistent
> store.
> 
>    The persistent store makes historical analysis/discovery
> possible where no other tool allows for this.  Since
> you can't go back and run another tool with a better
> signature,  if Argus is well done, then we can go
> back and find out if anyone used that newly discovered
> attack on us last year.
> 
>    Argus will not be able to replace any dedicated near
> real time signature peeler, but if there is anything that
> we can do to make historical discovery a part of our tool,
> then we've got something.
> 
>    So how much data do we need to capture?  For your
> sgi telnet attack, can we detect it in less than 64 bytes
> of source user data?  Do we need response data?  User
> logins ids are easily captured in the first 32 bytes.
> Most hostnames are less than 64 bytes.
> 
>    What do you think?
> 
> Carter
> 
> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Chas DiFatta
> Sent: Monday, September 11, 2000 9:04 PM
> To: carter at qosient.com; 'Russell Fulton'; 'argus'
> Subject: RE: argus and snort ?
> 
> 
> We really haven't played with the "trigger-on-this-bad-thing"
> from a network security perspective, but we find it very useful
> for network application debugging.
> 
> 	I.e. capture the beginning of an http GET to a specific
> 	server so we can read the whole request.  We can then
> 	correlate the time of a problem with argus and snort
> 	and then diagnose.
> 
> If argus captured (via a trigger) all or some of the data portion
> of the tcp session, it would be EXTREMELY useful.  Or (wishing cap
> on now) the first x packets from a connectionless session (udp).
> 
> I want to make it clear that in application debugging, seeing what's
> going over the wire is very important and most of the time, you
> don't need to see that much.  Example, why is this mail server
> always giving an error?
> 
> 	reject=550 <someone at x.org>... Relaying denied
> 
> >From an network management perspective, it adds another dimension
> to the information that Argus provides.
> 
> Thoughts?
> 
> 	...cd
>  
> > -----Original Message-----
> > From: owner-argus at lists.andrew.cmu.edu
> > [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Carter Bullard
> > Sent: Monday, September 11, 2000 4:41 PM
> > To: 'Russell Fulton'; 'argus'
> > Subject: RE: argus and snort ?
> > 
> > 
> > 
> > So what is snort doing for you guys that is helping?
> > Is there some nugget of goodness that we can add to
> > argus that will give the same info?
> > 
> > Carter
> > 
> > -----Original Message-----
> > From: owner-argus at lists.andrew.cmu.edu
> > [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
> > Sent: Monday, September 11, 2000 5:45 PM
> > To: argus
> > Subject: Re: argus and snort ?
> > 
> > 
> > Perhaps I should have said that I am monitoring an 10Mbps ethernet 
> > running at around 3Mbps in one 'direction' (inbound) and 1 Mbps in the 
> > other. (yes I do know that ethernet does not have any sense of 
> > direction ;-)  The box is an IBM Ativa with a 500Mhz processor and 
> > 128MB ram.
> > 
> > Top shows Snort using about 8% of CPU and the two copies of argus are 
> > down below 1%.
> > 
> > We will soon go to 100Mbps on the DMZ and our data rates are likely to 
> > go up steeply when the Southern Cross fiber finally gets commissioned 
> > later this year.  We have been promised that prices will fall sharply 
> > -- I'm not holding my breath though...
> > 
> > Cheers.
> > 
> > 
>