Some problems (bugs?) with argus
Carter Bullard
carter at qosient.com
Fri Aug 7 12:47:40 EDT 2009
Hey Martijn,
We know which IP address sent the syn and the synack in the record.
In each TCP DSR there is status, state, all options reported, metrics,
etc...
by direction, so we have the data in the record. We even know the micro
second duration between these two events (print the 'synack' or 'ackdat'
field in tcp records).
The argus TCP state transitions are used by the clients to specify
direction,
so the syn state will be associated with the source. The synack state
is going to be associated with the reported destination, so there
isn't any
ambiguity in argus records as to what side of the connection
generated the two connection establishment messages, syn and synack.
So, ..., argus and the clients are definitely doing what you want.
So I did this
and it works great. If you have different experience send email!!!!
% tcpdump -i en0 -w /tmp/tcpdump.tcp.out - tcp
I do a few web transactions and then close tcpdump.
thoth:tmp carter$ argus -r /tmp/tcpdump.tcp.out -w -| ra
StartTime Flgs Proto SrcAddr
Sport Dir DstAddr Dport SrcPkts DstPkts
SrcBytes DstBytes State
2009/08/07.12:33:01.814534 e d tcp
192.168.0.68.51100 -> 17.112.152.32.http 13
15 3202 12637 CON
2009/08/07.12:33:02.155070 e tcp
192.168.0.68.51101 -> 17.250.248.105.http 6
4 582 1285 FIN
2009/08/07.12:33:02.306515 e tcp
192.168.0.68.51102 -> 17.250.248.77.http 7
6 717 768 FIN
2009/08/07.12:33:02.331235 e tcp
192.168.0.68.51103 -> 208.59.201.75.http 30
45 11006 53471 CON
2009/08/07.12:33:02.474851 e tcp
192.168.0.68.51105 -> 208.59.201.75.http 33
54 10102 73255 CON
2009/08/07.12:33:02.486656 e tcp
192.168.0.68.51106 -> 208.59.201.75.http 23
27 7477 33915 CON
2009/08/07.12:33:02.487187 e tcp
192.168.0.68.51107 -> 208.59.201.75.http 59
166 14993 224623 CON
2009/08/07.12:33:02.538073 e tcp
192.168.0.68.51108 -> 17.250.248.77.http 7
6 1053 596 FIN
2009/08/07.12:33:03.652003 e tcp
192.168.0.68.51109 -> 64.233.161.149.http 4
3 804 762 CON
2009/08/07.12:33:03.667048 e tcp
192.168.0.68.51110 -> 66.235.133.11.http 8
6 2601 2436 FIN
2009/08/07.12:33:03.786080 e tcp
192.168.0.68.51111 -> 64.233.169.149.http 9
7 2987 2105 FIN
2009/08/07.12:33:04.032955 e tcp
192.168.0.68.51112 -> 66.235.133.11.http 5
3 2608 814 CON
2009/08/07.12:33:09.474880 e tcp
192.168.0.68.51114 -> 17.250.248.77.http 7
6 717 768 FIN
2009/08/07.12:33:09.656268 e tcp
192.168.0.68.51115 -> 17.250.248.77.http 7
6 1053 596 FIN
2009/08/07.12:42:36.558756 man 0.
0 32. 1 0 15 0
9011820 STP
Ok, grab a single side of one of the connections:
% tcpdump -r /tmp/tcpdump.tcp.out -w /tmp/test.out - dst port 51100
thoth:tmp carter$ tcpdump -nr /tmp/test.out
reading from file /tmp/test.out, link-type EN10MB (Ethernet)
12:33:01.894824 IP 17.112.152.32.80 > 192.168.0.68.51100: S
1765636025:1765636025(0) ack 2248356905 win 8190 <mss 1380>
12:33:01.981277 IP 17.112.152.32.80 > 192.168.0.68.51100: .
1:1381(1380) ack 1138 win 8190
12:33:01.981284 IP 17.112.152.32.80 > 192.168.0.68.51100: .
1381:2761(1380) ack 1138 win 8190
12:33:01.981767 IP 17.112.152.32.80 > 192.168.0.68.51100: .
2761:4141(1380) ack 1138 win 8190
12:33:01.981771 IP 17.112.152.32.80 > 192.168.0.68.51100: P
4141:4739(598) ack 1138 win 8190
12:33:04.415847 IP 17.112.152.32.80 > 192.168.0.68.51100: . ack 2477
win 15015
12:33:04.417093 IP 17.112.152.32.80 > 192.168.0.68.51100: .
4739:6119(1380) ack 2477 win 15015
12:33:04.417097 IP 17.112.152.32.80 > 192.168.0.68.51100: .
6119:6199(80) ack 2477 win 15015
12:33:04.417099 IP 17.112.152.32.80 > 192.168.0.68.51100: .
7579:7659(80) ack 2477 win 15015
12:33:04.417596 IP 17.112.152.32.80 > 192.168.0.68.51100: .
6199:7579(1380) ack 2477 win 15015
12:33:04.421092 IP 17.112.152.32.80 > 192.168.0.68.51100: .
7659:9039(1380) ack 2477 win 15015
12:33:04.421097 IP 17.112.152.32.80 > 192.168.0.68.51100: .
9039:9119(80) ack 2477 win 15015
12:33:04.421099 IP 17.112.152.32.80 > 192.168.0.68.51100: .
10499:10579(80) ack 2477 win 15015
12:33:04.421342 IP 17.112.152.32.80 > 192.168.0.68.51100: .
9119:10499(1380) ack 2477 win 15015
12:33:04.421592 IP 17.112.152.32.80 > 192.168.0.68.51100: P
10579:11756(1177) ack 2477 win 15015
And argus generates:
thoth:tmp carter$ argus -r /tmp/test.out -w - | ra
StartTime Flgs Proto SrcAddr
Sport Dir DstAddr Dport SrcPkts DstPkts
SrcBytes DstBytes State
2009/08/07.12:33:01.894824 e tcp
192.168.0.68.51100 -> 17.112.152.32.http 0
15 0 12637 CON
2009/08/07.12:45:47.070834 man 0.
0 20. 1 0 2 0
8985856 STP
So this works great. We feed argus just one half of the connection,
and ra() knowss who the
correct initiator (from the synack state), and gets the server
correctly.
Now, when you don't see the syn or the synack, say because argus timed-
out
the orginal flow cache because the flow went idle, but then went
active again,
then there isn't any data to indicate which port is the service port.
The way to correct this is to keep state over a longer period of time
than
argus's 120 seconds. That's what racluster() is designed to do. If
racluster()
can't do the job, then there is rasqlinsert() which used mysql()
tables to
provide the cache, so that you can find the original flow report that
has the
direction in it.
The actual TCP flags in the packets are another item you can use.
You can access the TCP flags values using client filters like:
ra - src syn and ack
While this is not useful when a lot of packets go by because the flags
field is generated through or'ing the flags of all the packets seen in
a specific direction, in some cases it helps a lot.
Is this helpful?
Carter
On Aug 7, 2009, at 11:47 AM, Martijn van Oosterhout wrote:
> Thanks for the info, it was very helpful. The fragments turn out to be
> easily filterable by using something like syn or con. It's nice to
> know they're not important.
>
> I do have one question: you refer to ArgusReverseRecord() and it does
> what it says it does. However, what I'm interested in is: can I tell
> from the flow record in which direction SYN or SYNACK went. If I could
> determine that then it would be possible to take that into account.
>
> It's easy to reproduce, take the PCAP of any complete TCP connection
> and strip out the SYN packet (with editcap for example). If you're
> saying it's not possible at all then I'll have to reconsider my
> approach (I'm trying to detect services).
>
> Thanks for any information you can provide.
>
> On Fri, Aug 7, 2009 at 4:05 PM, Carter Bullard<carter at qosient.com>
> wrote:
>> Argus does not dictate the direction of a flow, its rules are very
>> simple,
>> so any problems with flow direction reporting are issues in the
>> logic for
>> the
>> client programs. So I wouldn't modify argus to deal with what would
>> appear to be a direction issue. Check out the ArgusReverseRecord()
>> use in the client library for help there!!!!
>
>
> --
> Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090807/58c884c9/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/20090807/58c884c9/attachment.bin>
More information about the argus
mailing list