'known flows' configuration file
Carter Bullard
carter at qosient.com
Thu Feb 14 13:51:10 EST 2002
Hey Mark,
Displaying "everything but" is traditionally a
filtering issue, but if you want to group stuff together
and get aggregate statistics on it, that’s a job for
ragator(). But flagging flows or aggregates of flows,
is really the job of another type of program, instead
of generic filtering or general aggregation.
We do have some policy examples, but those are access
control policy violation flagging. Do you want a
performance flagging client, or do you think if we add
(gt and lt field value) type support in the filters that
that would solve your problem?
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter at qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> Mark Poepping
> Sent: Thursday, February 14, 2002 11:40 AM
> To: carter at qosient.com
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: RE: 'known flows' configuration file
>
>
>
> So can you use ragator to do the 'display everything *but*
> flows of these types'? I used to do that all the time, to
> discover new services popping up in the intranet, but that
> was before the days of ragator (I need to go read all these
> manpages again:-). This notion is close to the 'in-profile'
> (signature) ideas, and I admit I haven't thought about it a
> lot, but is there thought to having ragator (or something
> else) specify 'ranges' for almost (if not) all of the argus
> attributes, and then be able to see things that are in or out
> of that 'profile'?
>
> For instance, I might want to flag:
> . any rtp streams that had dropped packets
> . smtp transactions that lasted longer than 1-2 seconds
> . http transactions over 1MB
> . aggregate 2-packet RST kazaa (filed request) transactions
> separately . a billion other things..
>
> I must say too that many of us approach the processing from a
> programmatic (perl) mindset, though ragator can actually do
> much of this stuff really easily and quickly.. But man, that
> bugger is a head-banger for me - those indirect flow-filter
> proto's just don't fly off the fingers like those associative
> arrays do:-)..
>
> Mark.
>
>
> > -----Original Message-----
> > From: owner-argus-info at lists.andrew.cmu.edu [mailto:owner-argus-
> > info at lists.andrew.cmu.edu] On Behalf Of Carter Bullard
> > Sent: Thursday, February 14, 2002 10:38 AM
> > To: 'Yann Berthier'; argus-info at lists.andrew.cmu.edu
> > Subject: RE: 'known flows' configuration file
> >
> > Hey Yann,
> > Thanks for the mail and your support of argus!
> > ragator() is capable of doing a part of what you
> > are interested in, and with only some minor adjustments,
> > it should be able to do all of it, or at least what
> > I understand from your mail.
> >
> > ragator() can be configured to pass through
> > traffic of interest, and to aggregate all other
> > traffic into a single 'catch all' record. You can
> > either filter out the catch all record on output, or
> > you can leave it in the stream. Here is how I would implement your
> > example:
> >
> > fmodel.conf:
> > #
> > # id SrcCIDRAddr DstCIDRAddr Proto SPort DPort ModelList
> > Duration
> > Flow 100 $INTERNAL_NET $SMTP_DMZ tcp * 25
> 200 0
> > Flow 101 * * icmp echo *
> 200 0
> > Flow 102 * * * * *
> 201 60
> > #
> > # id SrcAddrMask DstAddrMask Proto SrcPort DstPort
> > Model 200 255.255.255.255 255.255.255.255 yes yes yes
> > Model 201 0.0.0.0 0.0.0.0 no no no
> >
> >
> > And then run ragator as:
> > ragator -f fmodel.conf -r argusfile -w outputfile
> >
> > This will give you only the two flow types you are
> interested in. All
> > the other traffic will be aggregated into a common flow that is
> > generated every 60 seconds. Because ragator() is designed
> to account
> > for everything on the input (i.e. it won't throw anything away), we
> > may need to add a Model type that allows you to toss a
> record, if you
> > don't want to see the "catch all" record on output.
> >
> > You could hold the records of interest a little longer than
> 0 seconds,
> > and get some output management for free. This should get
> you what you
> > we are interested in.
> >
> > Hope you find this is helpful! Don't hesitate to send mail at
> > anytime!
> >
> > Carter
> >
> > Carter Bullard
> > QoSient, LLC
> > 300 E. 56th Street, Suite 18K
> > New York, New York 10022
> >
> > carter at qosient.com
> > Phone +1 212 588-9133
> > Fax +1 212 588-9134
> > http://qosient.com
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-argus-info at lists.andrew.cmu.edu
> > > [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Yann
> > > Berthier
> > > Sent: Thursday, February 14, 2002 3:48 AM
> > > To: argus-info at lists.andrew.cmu.edu
> > > Subject: 'known flows' configuration file
> > >
> > >
> > >
> > > Hi list !
> > >
> > > I discovered Argus recently while searching tools to help to
> > > highlight anomalies in a network trace: signs of an intrusion,
> > > troyans, and so on, and I am very enthusiastic about it !
> > >
> > > So, back to my subject: wouldn't it be helpful to have
> argus able
> > > to
> > > display (well, ra*) only defined flows ? Something like:
> > >
> > > tcp $INTERNAL_NET.any -> $SMTP_DMZ.25
> > > icmp any -> any ECO
> > >
> > > One can imagine a configuration file listing flows,
> and a flag to
> > > ra*
> > > to display or not flows matching this file : after
> all, it could
> be
> > > interesting as well to have the number of packets / bytes
> exchanged
> > > between the defined networks / flows - but of course the notion
> of
> > > state of the connection is meaningless here.
> > >
> > > I don't know if all of this make sense, just wanted to ask the
> list
> > > to know ... :) anyway, the idea is not to transform argus in a
> > > nids,
> > > but it could be handy to have argus displaying only non known
> > > flows,
> > > perhaps at least for the guy trying to enumarate the
> flows on its
> > > network to be able to partition it on a second round.
> > >
> > > ok, of course the bpf like filters are here for that,
> but it can
> > > be a
> > > bit tedious if you have multiple networks / flows to define.
> > >
> > > If this has been debated before, i apologize - a quick look in
> the
> > > archives raised nothing but ... it was a very _quick_ look :)
> > >
> > > Last point: is there an irc channel where people meet around
> argus
> > > ?
> > >
> > > Regards,
> > >
> > > yann.
> > >
> > >
> > > --
> > > Yann.Berthier at hsc.fr * Hervé Schauer Consultants *
> > http://www.hsc.fr/
> >
> >
>
>
>
>
More information about the argus
mailing list