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