Argus 3.0.2 unable to remember the direction of a connection (update: not resolved by 3.0.3.22)
Cees
celzinga at gmail.com
Wed Feb 16 05:26:40 EST 2011
Hello Carter,
Thanks for your detailed reply.
I assumed the problem was caused by the sessions in the PCAP, not realizing
Argus processed the timeouts differently depending on the number of
sessions. Using racluster works. In my specific situation i increased the
status reporting interval (-S) as a work-around.
Sounds great these parameters are exposed and configurable in the new argus.
Keep up the good work,
Cees
(with an on-list reply this time)
On Fri, Feb 11, 2011 at 9:16 PM, Carter Bullard <carter at qosient.com> wrote:
> 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/20110216/788f7642/attachment.html>
More information about the argus
mailing list