Primitives for tcp/udp/icmp flow

[CS Lee]

Carter,

Thanks, ra -M xml works. My bad of not noticing it in the man page, maybe my
partner will have input about raxml once he gets into it.

Yeah, it's good to track those flow and it would be lovely to to have those
primitives but I can't think of good name though, currently maybe can add s
as start and e as end like -

   1. syn only - synonly
   2. syn with synack but no data, no closing - synack-nodata
   3. syn and synack and fin, with no data passed - synack-fin-nodata
   4. synack with no syn - ssynack
   5. data with no syn or synack with reset - dataonly-rste
   6. syn with reset - ssynrste
   7  syn with synack with initiator fin - fin-synack

It looks cryptic though but what if we want it to be more specific on either
sender or receiver side, we can use the same with the flags which using _ as
separator. I don't know what's best but just my idea.

All these are really good as for example number 4 option can easily track
down backscatter traffics.

Thanks for adding the appbytes support so that I can easily doing
application protocols analysis. Anyway I'm looking forward for senc and denc
added to argus clients.



On 5/16/07, Carter Bullard <carter at qosient.com> wrote:
>
> Hey CS Lee,These flag indicators are indeed very useful, but there are a
> number ofconditions that you will want to track for lots of different
> reasons, so
> its hard to reduce the combinations, especially when you add to the
> mix that in some situations you also want to know which direction the
> flag was set it.
>
> If we can come up with unique keywords for combinations, then I
> can support that.   Here are the ones that I think are most important
> to track and their filter equivalents:
>    1. syn only
>    2. syn with synack but no data, no closing
>    3. syn and synack and fin, with no data passed
>    4. synack with no syn
>    5. data with no syn or synack with reset
>    6. syn with reset
>    7  syn with synack with initiator fin
>
> they all have multiple reasons to track them, some operational,
> some security.  So not sure how I can help here.
>
> Other keywords that are useful:
>    'normal'     - tcp normal close (fin finack)
>    'wait'          - tcp time wait state (fin no finack)
>    'con', 'est'  - tcp connected/established (syn, synack, ack)
>
>
> raxml() is not going to be any longer, as all the ra* programs can
> print as XML now.  But the xml support is still weak.  Try:
>
>    ra -r file -M xml
>
> To see how far I've come with it.  Any help anyone can give
> on the xml part would be great, like definitions of schema's
>  opinions as to what it should look like.
>
> Carter
>
>
> On May 14, 2007, at 9:03 AM, CS Lee wrote:
>
> Hey Carter,
>
> Except the one listed in the man page such as syn, synack unreach and so
> forth. Are there any other options that are available that not mentioned in
> the man page. Is any other workaround if I want to search for the flow that
> contains syn flag only but ignoring others and I have to use
>
> ra -r argus-test.arg - syn and ! \(synack or reset or fin or finack\) and
> dst net 192.168.5.0/24
>
> sometimes I'm lazy with the flag and I just use
>
> ra -r argus-test.arg -Z b | egrep '\<S_\>'
>
> Both do the job but the first one requires me to call complex filter
> combinations. This is great to look for scanning activity to your network.
>
> Another thing is will raxml shipped with completion in argus clients 3.0as currently my friend thinks of using raxml and parsing the data to db.
>
> Thanks.
>
> --
> Best Regards,
>
> CS Lee<geekooL[at]gmail.com>
>
>
>
>


-- 
Best Regards,

CS Lee<geekooL[at]gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20070516/8811f687/attachment.html>