Alternate state fields
John T. Myers via Argus-info
argus-info at lists.andrew.cmu.edu
Sun Apr 3 15:44:06 EDT 2016
Carter,
Thanks for that explanation. It makes sense now, but I don't really think the ra.1 man page does a good job explaining that special case just for the -z option. It mentions it "represents TCP state changes" but our assumption was that was TCP state changes per flow records, since everything else is by flow record.
I think it's really important to note that the way Argus is doing TCP state tracking is additive for the entirety of the bi-directional TCP session, instead of observing only the states seen in that particular capture window.
From what I can tell, Ra doesn't have any other fields that are additive for the entire session, vs the individual flow capture window, so this kind of makes it a special case??
John
> On Apr 2, 2016, at 8:47 PM, Carter Bullard <carter at qosient.com> wrote:
>
> Hey John,
> You’re on the right track. Argus is much different from other flow technologies with regard to TCP state tracking, and the -z flag is specific to Argus state reporting. Netflow and IPFIX only report the TCP flags seen, which are OR’d flags seen in a unidirectional stream of TCP packets. This has its limitations, i.e. you can’t tell the difference between the 2 packets SYN and ACK, vs a single SYN_ACK packet using Netflow/IPFIX. The semantics of these two different conditions is huge. Argus, on the other hand, tallys the states that the bi-directional TCP goes through, so that the SYN and ACK are tracked as connection requested (SYN) and connection established (ACK) (s, E), and the -z option is used to print the TCP state that the flow is in. Don’t think of the sSE as TCP flags, think of them as observed states, and it shouldn’t be confused as misleading. “sSE” as a state is different than “E” as a state. With sSE I have observed the SYN, SYN_ACK, and ACK handshake, and the connection is established. With just an E, argus is saying that it see’s a TCP connection that seems established, but argus can’t verify that the TCP was neogitated.
>
> The -Z option is just printing the set of TCP flags that were seen for the status interval, so seems that that is more oriented to what you expect to see ??? The -Z option is there for the Netflow crowd, but I rarely look at it.
>
> The ra.1 man page is actually pretty detailed on this ???
>
> Carter
>
>> On Apr 2, 2016, at 12:20 PM, John T. Myers via Argus-info <argus-info at lists.andrew.cmu.edu <mailto:argus-info at lists.andrew.cmu.edu>> wrote:
>>
>> Hi Carter,
>>
>> I've been experimenting with modifying the state fields using the -z and -Z options with ra.
>>
>> I did two SCP transfers, one with each option, and I'm confused on the logic for how the fields are populated, and the manual doesn't quite explain why.
>>
>> When using the -z option, it seems like the state field maintains all TCP state changes seen for the entire session, not just that flow record. While using the -Z option, it seems that only TCP flags seen for that flow duration are tracked. I've copied my output below
>>
>> I would expect that for the -z option I would see the first flow record have "sSE" in the field and then subsequent records (excluding teardown) would only have "E". Instead every field here has "sSE" which is misleading. Wireshark confirms (as it should b/c this is TCP) that there is only one SYN & SYN/ACK exchange for the SCP session.
>>
>> However, using -Z, the SYN flag is only tracked once, on the first session, which is seen with the SPA_* in the field, and all subsequent fields do not have the S present.
>>
>> This seems a little inconsistent to me, could you provide any insight?
>>
>> I'm using Ra Version 3.0.8.2.rc.2 and Argus Version 3.0.8.1
>>
>> jtmhotroute:~ jtm$ ra -S 127.0.0.1:1776 <http://127.0.0.1:1776/> -z - port 22
>>
>> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytes State
>>
>> 12:05:28.726620 e s tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 11791 11853171 sSE
>>
>> 12:05:33.728299 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 24965 25502802 sSE
>>
>> 12:05:38.730173 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 25702 26240872 sSE
>>
>> 12:05:43.730638 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 33712 34532864 sSE
>>
>> 12:05:48.731169 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 53476 54405756 sSE
>>
>> 12:05:53.731298 e s tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 57456 58217859 sSE
>>
>> 12:05:58.732201 e s tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 29702 29707269 sSE
>>
>> 12:06:03.733620 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 30154 30824832 sSE
>>
>> 12:06:08.736406 e & tcp 192.168.87.28.61864 -> 192.168.87.29.ssh 8750 8566056 sSER
>>
>>
>>
>>
>>
>>
>> ^Cjtmhotroute:~ jtm$ ra -S 127.0.0.1:1776 <http://127.0.0.1:1776/> -Z b - port 22
>>
>> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytes State
>>
>> 12:07:04.327678 e s tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 11430 11567973 SPA_*
>>
>> 12:07:09.328327 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 28235 28832474 A_PA
>>
>> 12:07:14.328806 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 29312 29921468 A_PA
>>
>> 12:07:19.330776 e s tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 32839 33147266 PA_PA
>>
>> 12:07:24.331001 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 31180 31834004 A_PA
>>
>> 12:07:29.331785 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 34135 34876590 A_PA
>>
>> 12:07:34.333754 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 38064 38903160 A_PA
>>
>> 12:07:39.333868 e & tcp 192.168.87.28.61964 -> 192.168.87.29.ssh 51077 52220114 PA_PA
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160403/1dd541cf/attachment.html>
More information about the argus
mailing list