Argus 3.0.2 unable to remember the direction of a connection (update: not resolved by 3.0.3.22)
Carter Bullard
carter at qosient.com
Fri Feb 11 15:16:14 EST 2011
Hey Cees,
This is correct behavior using your test-case2.pcap and the current flow timeout timers that
argus uses.
The issue is that you have a 75 second idle period with this flow, between the first and second
flow status report, and currently argus has a 60 second idle timeout for TCP flows. The "?" in the
direction is telling you that argus doesn't have confidence in the direction, and so when it
develops the flow record, it hasn't seen the SYN or SYN_ACK volley, and thus doesn't know
exactly what the direction is.
This is correct based on the timeout scheme currently used in argus-3.0.3.x. Earlier argi used
an idle timeout of 120s to match the FIN WAIT STATE 2 timer in the TCP protocol spec. If you
change the timeout back to 120s, and a flow as an idle time of 120.0001 seconds, this same
behavior would result.
When reading packets from a file, argus uses the timestamps in the packets as its clock.
When there is just a single flow in the packet trace, argus will not process the timeout queues
until after it has processed the current packet. In your situation, argus finds the timed out flow
cache in the timeout queue, and rather than discarding it, it uses the cache (a type of optimization).
If there was any other packet to process, argus would have discarded the specific expired cache
and it would then lose state (direction etc....).
If its any consolation, argus is reporting the correct direction, but the "?" is stating that it
doesn't have 100% confidence that the direction is correct. And if you use racluster(), the
resulting single flow will have the correct direction in it.
The flow timeouts are currently hard coded, but I'll expose all of the timeout timers in the
argus.conf file before I release argus-3.0.4.
What do you think?
Carter
On Feb 11, 2011, at 12:14 PM, Cees wrote:
> Although argus-3.0.3.22 fixed that particular test case, I've encountered the same problem with the latest argus on a very similar PCAP.
>
> This PCAP contains 3 sessions:
>
> 1. 172.16.10.67.4288 -> 192.168.234.166.8080
> 2. 172.16.10.67.4293 -> 192.168.234.166.8080
> 3. 172.16.10.42.1968 -> 192.168.234.166.8080
>
> Argus is unable to determine the direction of the first connection:
>
> $ ~/argus-3.0.3.22/bin/argus -r test-case2.pcap -w - | ~/argus-clients-3.0.3.22/bin/ra -nnr - | grep 4288
> 27 Jan 11 13:14:31 e 6 172.16.10.67.4288 -> 192.168.234.166.8080 4 1300 CON
> 27 Jan 11 13:15:47 e 6 172.16.10.67.4288 ?> 192.168.234.166.8080 5 1617 CON
> 27 Jan 11 13:15:57 e 6 172.16.10.67.4288 ?> 192.168.234.166.8080 2 1094 CON
>
> But when I extract this particular session in a separate PCAP, argus is able to determine the direction:
> $ tcpdump -nnr test-case2.pcap -w one_session.pcap port 4288
>
> $ ~/argus-3.0.3.22/bin/argus -r one_session.pcap -w - | ~/argus-clients-3.0.3.22/bin/ra -nnr -
> 27 Jan 11 13:14:31 e 6 172.16.10.67.4288 -> 192.168.234.166.8080 4 1300 CON
> 27 Jan 11 13:15:47 e 6 172.16.10.67.4288 -> 192.168.234.166.8080 5 1617 CON
> 27 Jan 11 13:15:57 e 6 172.16.10.67.4288 -> 192.168.234.166.8080 2 1094 CON
>
> Somehow the other connections reset the session state.
>
> See the attached PCAP (again stripped and obfuscated, but it reproduces the bug).
>
> Hope you can help,
>
> Thanks,
>
> Cees
>
> On Wed, Feb 9, 2011 at 8:51 PM, Cees <celzinga at gmail.com> wrote:
> I can confirm argus-3.0.3.22 fixes the issue.
>
> Thanks for the quick reply, should've checked with the latest dev version...
>
>
> On Wed, Feb 9, 2011 at 8:39 PM, John Gerth <gerth at graphics.stanford.edu> wrote:
> On 2/9/2011 6:43 AM, Cees wrote:
> >
> > Hello list,
> >
> > I encountered a strange bug in Argus where Argus is unable to remember the direction of a connection.
> > At first the direction is correct, but half-way through the session Argus 'forgets' the direction.
> >
> > I managed to create a test case, see the attachments.
> >
> > correct.pcap contains a TCP session of 52 packets between 172.16.12.165 port 1051 and 192.168.234.166 port 8080
> > test-case.pcap contains the same session, but with two additional packets on port 1058. In the original PCAP the packets were part of a complete
> > session, but these two packets are enough to confuse Argus.
> >
> This looks like a fixed bug as I get the behavior you want with the latest argus-3.0.3.22
>
> --
> John Gerth gerth at graphics.stanford.edu Gates 378 (650) 725-3273 fax 723-0033
>
> ***********
> argus-3.0.3.22 $ sbin/argus -F /dev/null -r ~/win/test-case.pcap -w - | bin/ra -nnr -
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts TotAppByte State NStrok Dur
> 06:55:05.196 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 10 10 0 CON 1.278
> 06:55:10.283 e 6 192.168.234.166.8080 ?> 172.16.12.165.1058 1 0 0 CON 0.000
> 06:55:40.595 e 6 192.168.234.166.8080 <? 172.16.12.165.1058 0 1 0 CON 0.000
> 06:56:03.903 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.275
> 06:56:34.920 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.420
> 06:57:05.963 e r 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.436
> 06:57:37.007 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.452
> 06:58:08.055 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.244
> 06:58:39.115 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.243
> 06:59:10.154 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.264
> 06:59:41.291 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.296
> 11:35:07.440 man 0. 0 23. 1 54 12 9887296 STP 0.000
> argus-3.0.3.22 $ sbin/argus -F /dev/null -r ~/win/correct.pcap -w - | bin/ra -nnr -
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts TotAppByte State NStrok Dur
> 06:55:05.196 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 10 10 0 CON 1.278
> 06:56:03.903 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.275
> 06:56:34.920 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.420
> 06:57:05.963 e r 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.436
> 06:57:37.007 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.452
> 06:58:08.055 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.244
> 06:58:39.115 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.243
> 06:59:10.154 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.264
> 06:59:41.291 e 6 172.16.12.165.1051 -> 192.168.234.166.8080 2 2 0 CON 0.296
> 11:35:24.481 man 0. 0 30. 1 52 10 9885624 STP 0.000
>
>
> <test-case2.pcap>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110211/9967994e/attachment.html>
-------------- 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/20110211/9967994e/attachment.bin>
More information about the argus
mailing list