Definition of filter fin and finack
Carter Bullard
carter at qosient.com
Wed Aug 27 21:38:20 EDT 2008
Hey Nick,
Hmmmmmm........
Yes, fin seems to just mean the fin bit is set. This is syntactically
correct,
based on the compiler (individual bit keywords, syn, ack, rst, urg, ece,
cwr, push, fin) are used to test TCP flag bits. TCP flag bits are
stored for each
side of the TCP, so the keywords "src" and "dst" apply to the simple
bit tests.
We added all the flag bit tests for argus-3.0.0, so you could pick any
bit you
wanted, and seem to have messed up the original test for syn and
fin. (the
logic is there, but the test is now looking at the wrong offset in the
TCP dsr).
The TCP states are different, as there is no direction associated with
the states.
Thats because for most of the states, they imply the direction. These
are printed
correctly in the status field, but only the synack, finack and 'con'
keywords actually
pick up these states.
We have additional compound keywords for TCP, 'normal', and 'est',
that test some
of the various tcp state indicators. But these are not detailed
enough to pick out,
say the fin only flows. I'll have to come up with some keywords that
will be easy to
use and are different than the flags tests, such as "synonly",
"finonly", or "syninit",
"fininit"?
Can these work?
Argus is doing the right thing, and the states are represented correctly
in the records, so its just the client filter that is messed up right
now.
Carter
On Aug 27, 2008, at 5:54 PM, Nick Diel wrote:
> Carter,
>
> As always, thanks for the info. I have a couple more questions.
>
> First, most of my fin packets (from the source who initiated the
> teardown) also have the ack bit set. So I was a little confused
> when you said that the fin means a packet with onlythe fin bit set.
> I don't know what the RFC says, I just know the vast majority of my
> packets are this way (and I have billions of them).
>
> I did just a couple of tests where I tested a flow that is complete
> (syn-synack-data-fin-finack). Then tested one with just a fin
> packet and finally one with just the first fin and the ack for it.
> Based on the results it appears as if fin means the fin bit was set,
> while finack seems to mean a fin was acknowledged. I can't put src
> or dst in front of finack to completey test this theory as I get a
> syntax error.
>
> The results are below, hopefully you can shed some light onto what I
> am missing.
>
> Thanks,
> Nick
>
> First I test a complete flow in argus:
>
> tcpdump -r singleCompleteFlow.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S
> 2565614892:2565614892(0) win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S
> 2137176771:2137176771(0) ack 2565614893 win 49640 <mss
> 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1
> win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack
> 55 win 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55
> win 49640
> 09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
> 09:36:56.479347 IP 1.1.1.1.14713 > 2.2.2.2.pop3: F 55:55(0) ack 231
> win 64283
> 09:36:56.493103 IP 2.2.2.2.pop3 > 1.1.1.1.14713: . ack 56 win 49640
>
> ra -r singleCompleteFlow.argus - fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 23 1571 FIN
> ra -r singleCompleteFlow.argus - src fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 23 1571 FIN
> ra -r singleCompleteFlow.argus - dst fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 23 1571 FIN
> ra -r singleCompleteFlow.argus - finack
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 23 1571 FIN
>
> Here I test the same flow, but with only the first fin packet.
>
> tcpdump -r singleF.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S
> 2565614892:2565614892(0) win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S
> 2137176771:2137176771(0) ack 2565614893 win 49640 <mss
> 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1
> win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack
> 55 win 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55
> win 49640
>
>
> ra -r singleF.argus - fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 20 1403 FIN
> ra -r singleF.argus - src fin
> (no results as expected)
> ra -r singleF.argus - dst fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 20 1403 FIN
> ra -r singleF.argus - finack
> (no results as expected)
>
>
> Next I test a flow that only has the first half of the tcp teardown
> (initial fin and ack of the fin).
>
> tcpdump -r singleFA.pcap
> reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
> 09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S
> 2565614892:2565614892(0) win 64512 <mss 1460,nop,nop,sackOK>
> 09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S
> 2137176771:2137176771(0) ack 2565614893 win 49640 <mss
> 1460,nop,nop,sackOK>
> 09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
> 09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1
> win 49640
> ....
> 09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack
> 55 win 49640
> 09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55
> win 49640
> 09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
>
> ra -r singleFA.argus - fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 21 1457 FIN
> ra -r singleFA.argus - src fin
> (no results as expected)
> ra -r singleFA.argus - dst fin
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 21 1457 FIN
> ra -r singleFA.argus - finack
> 09:36:54.772992 e tcp 1.1.1.1.14713 ->
> 2.2.2.2.pop3 21 1457 FIN
>
>
> Nick
>
> On Wed, Aug 27, 2008 at 12:46 PM, Carter Bullard
> <carter at qosient.com> wrote:
> Hey Nick,
> Fin means that we saw a TCP packet with only the fin bit set. It
> doesn't excude
> that other states were seen, it just means that we did see a proper
> FIN packet.
>
> Finack means that we saw a TCP packet with only the fin and the ack
> bit set,
> so we know that there appears to be a proper response to a FIN packet.
>
> If you put "src" or "dst" in front of a TCP flag keyword, you aren't
> asking about
> TCP states, you're just asking for the occurrence of the bit being
> set in any packet
> observed by the flow record. For example this filter:
>
> "src \( fin and ack\)"
>
> is not the same as
>
> "finack"
>
> In the first filter, the fin and the ack bits are not related, in
> that, they could
> have occurred in different packets. The "finack" filter requires
> that a packet
> with the fin and ack were seen or'd in the same packet. This is
> much different
> that what you see with Netflow, or any other flow data.
>
> Carter
>
>
> On Aug 27, 2008, at 12:45 PM, Nick Diel wrote:
>
> A quick question as I work on a paper. For the filters "fin" and
> "finack", do each one represent one half of the 3-way tear down.
> For example, does "fin" mean that argus saw the first fin and saw
> the ACK for this fin? And on the other side, does "finack" mean
> that argus saw the second fin and saw the ACK for this fin? Or does
> a complete teardown in terms of fin and finack filters look like
> this: (src fin and dst finack) and (dst fin and src finack)?
>
> I want to make sure I get my defitions right for a paper.
>
> Thanks,
> Nick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080827/375cf35c/attachment.html>
More information about the argus
mailing list