Question about states
Carter Bullard
carter at qosient.com
Tue Nov 24 11:23:31 EST 2009
Hey Matt,
In most cases, the only reason a field can't be printed the way you want,
is because we don't have a command line name of letter to apply the
option, usually because we didn't get around to doing it, or nobody asked
for it.
OK, understand that the default status fields are simply a convenient way of
presenting the TCP state progression in a simple fashion. We have more
information in the Argus records, as we track the perceived TCP states per
side of the connection, but how would you like to print them?
In raxml(), which is now obsolete (replaced with the '-M xml' option), we
printed out the entire contents of the ARGUS_TCP_DSR. That was argus-2.x.
In argus-3.0, we have more and less TCP information available, depending
on how you setup your argus(). So if you want some new TCP printing support,
we should discuss what the information is, what it means, and how to print it.
Currently, the combined TCP status field (default TCP output with the -z option),
tracks the progression of the TCP state machine, and the direction of the TCP control
packets that establish the various TCP states is indicated by the assignment of Src
and Dst for the flow. Who sent the SYN ('s') ? The Source. Who sent the
SYN_ACK ('S')? The Destination. In fact that is how the Source and Destination
are determined, and in some cases of TCP mediated scans, the direction seems
confused, because the scanner is violating the TCP state machine to get the
targets to respond. Notice that the use of lower case and upper case tracks the
source and destination.
The states for TCP are derived from the indications that Argus stores in the TCP
DSR. We capture "SAW_SYN", "SAW_SYN_ACK", "ESTABLISHED", "SAW_FIN",
"SAW_FIN_ACK", "SAW_RESET" on each side of the connection, as well
as the state that argus() thinks the TCP connection is in. And with each status
report, we zero most of these bits, so we can know what control packets were sent,
when.
So, with all of that, we can print out all that you ask, just need to know what syntax
to use to print the fields.
The flags format, because its simply the OR'ing of the TCP flags during
the status interval, you lose massive amounts of information, like direction
etc..... However, when you print the status field using the "-Z" option, you have
the flags for the source, the an '_' and then the flags for the destination.
Maybe you haven't seen this because your default status field width isn't large
enough to print the whole indicator?
"man" records are argus management records. They convey status of the argus
data source, which can be argus() or radium(), and act as keep alives for the
argus transport stream. I believe that they are described in the man pages.
Carter
On Nov 21, 2009, at 10:53 PM, Matt Brewer wrote:
> Hello,
>
> I have a few questions and ideas I'd like to share.
>
> Some of the flows in my captures are marked EC (This is with the -z option to show mimic tcp states) and I haven't been able to determine what the C stands for, any idea what it means?
>
> Also, I've been working with the states field a lot with the -z option, and its come to my attention that the sSEfFR orientation of the flags doesn't actually give me indication of who sent what packets with what tcp flags. I'm aware I can remove the -z and use the -Zs or -Zd option and it will give me an output of with tcp flags were set for each direction, but it would be nice to actually have both options displayed. If I use the -Zb option, it looks like it attempts to print out both states deliminated by an underscore, however the field appears to be truncated to 5 characters and is often cut off. And even if it wasn't cut off, the tcp flags aren't displayed it order of occurrence.
>
> Is there any reason the state field cannot keep the occurrence of flags in order? It would be incredibly useful to display the state of the flow in order. Ideally I would like to see the tcp flags as lower case letters as the source produced flags, and upper case letters as destination produced flags. A system like this would allow us to easily determine which side of the flow tore down the TCP session, either via a FIN or RST.
>
> Also, I've recently seen the "man" protocol in my captures. What exactly is this supposed to indicate? Some of the "man" flows are marked with STP or STA in the state field. I am assuming that "man" refers to switch management protocols? Correct me if I'm wrong.
>
> Also, the "man" protocol flows with the state "STA" have zero destination or source packets. Which is very bizarre, I do not understand how a flow could exist without packets.
>
> Oh also, what is the "offset" field for? The man pages are rather vague "record byte offset in file or stream."
>
> Thanks in advance, argus is a wonderful tool.
>
> ===========================
> | Matt Brewer
> | CCNA
> | www.sheridantutorials.com
> ===========================
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20091124/ba5293df/attachment.bin>
More information about the argus
mailing list