cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Deep Packet Analysis - Fun with Flags!

Level 10

In my last post I talked through some of the reasons why mastering tcpdump is useful. Building on our previous example in this post I’ll focus on using TCP flags for troubleshooting.


Even with our cleaned up filter, we can still see quite a lot of traffic that we don’t care about.  When troubleshooting connectivity issues, the first packet is the hardest; especially when you start involving firewalls. I’m sure you will recall, a TCP packet flagged with SYN is the first sent when client tries to establish a layer-7 connection to a remote host.  On a LAN, this is simple, but when the destination is on a different network, there is more to go wrong with the inevitable NAT and routing.


Troubleshooting approaches differ, but I prefer to jump on the target console and work backwards as traffic is usually only policed on ingress. We need to know whether our packet is reaching our target. This way we can look down the stack (at routing and firewalling) or up to application itself.


This is where a working knowledge of TCP flags and a copy of tcpdump is helpful. 


Signalling with Flags


Each TCP packet contains the source and destination port, the sequence  and acknowledgement numbers as well as a series of Flags (or control bits) which indicate one or more properties of the packet. Each flag is a single bit flipped on or off. The below diagram shows the fields in a TCP packet. The source and destination ports are 16 bit integers (and is where we get the maximum 65535 from), but if you look at offset 96, bits 8 through 15 are individual flag, SYN, ACK, RST, etc.



Capture 0.PNG


When a connection is setup between a client and server, the first three packets will have the SYN and ACK flags set. If you look at them in any packet analyser, it’ll look something like this:


Client -> Server (SYN bit set)

Server -> Client (SYN and ACK bits set)

Client -> Server (ACK bit set)


To make sure we are actually getting the traffic, we want to see the first packet in the connection handshake. To capture packets where only the SYN flag is set, we use the following command from the server console:


[~] # tcpdump -i eth0 -n 'tcp[tcpflags] & (tcp-syn) != 0 and port not 22’


The above tcp option filters on specific packet fields. In this case we are using tcpdump’s built-in shorthand to look at the bits associated with TCP SYN (the ‘Flags [S]’ in yellow). 


The other thing we are introducing is using ‘single’ quotes on the filter. This prevents the shell from trying to interpret anything within brackets.


In the below example we can see three packets sent ~500ms apart (also highlighted in yellow). You must consider that almost everything on the wire is filtered out, we are only hearing one side of the conversation.


Capture1.PNG


Three packets with the same source and destination ports transmitted 500ms apart us a clue to what is happening. This is the typical behaviour of a client connection that received no response, assumed the packet was lost in transit and tried twice more.


What does the flag say?


Having taken this capture from the server; we know the outbound communication is working, so it unlikely that an intermediate firewall is causing a problem. My hunch is the server is not completing the connection handshake for some reason. A quick and dirty way is to check for TCP Reset packets; the host’s universal way of asking for a “do-over” and restarting the handshake. Hosts will respond with a TCP reset when there is no application listening; the lights are on; but no-one is home.


[~] # tcpdump -i eth0 -n 'tcp[tcpflags] & (tcp-rst) != 0 and port not 22'


Capture2.PNG


I took the above captures a few minutes apart, but for every TCP SYN, there is a TCP RESET from the server. Whether the server is actually listening on any ports or interfaces on that target destination port (3333) is easily confirmed with:


[~] # netstat -na | grep 3333


If no results are returned, the service ain't running. When taking captures from a firewall, you should expect different behaviour. In 99% of cases if a packet doesn't a match policy; it will be dropped without an acknowledgement (ACK) or reset (RST) packet.


These are not the flags you are looking for


With the tcpflags option we can pipe in additional matches. For example, we can look for all traffic where the tcp-syn and tcp-ack flags are not set to 0.


tcpdump -i eth0 -n 'tcp[tcpflags] & (tcp-rst|tcp-ack) != 0 and port not 22'


However, everything with SYN or ACK set  doesn’t constitute much of a filter; you are going to be picking up a lot of traffic.


Rather than just filtering on source/destination ports, why do I care about TCP flags? I'm looking for behaviour rather than specific sources or destinations. If you are troubleshooting back-to-back LAN PCs, you wouldn't bother with all the Vexillology. However, with hosts either side of a firewall, you can’t take much for granted. When firewalls and dynamic routing is involved traffic may cross NAT zones or enter an unexpected interface.


It’s easy to switch to source/destination filtering once you've “found” the flows you are looking for; I try and avoid making assumptions when troubleshooting.


In my next post I’ll dig into the payload of two common protocols to see what we can learn about layer 7 using only tcpdump.





12 Comments
Level 14

Excellent write up on the use filtering packets using flag bits.  I haven't done that in a while.  Time to add that tool back to the tool box.  Thank you.

I can't speak to all firewalls, but the McAfee firewall uses a proxy that will give different indications depending depending on the packet contents.  If the port is not in use, a reset packet will be sent imediately.  If the port is in use, but the socket doesn't match, it will allow the full three way hand shake before sending the reset.  Even better, when you have a SSH rule in place using the SSHv2 proxy and a client attempts to connect with a SSHv1 client, the firewall will read the fourth packet that identifies the version of the client.  When it sees the SSH version is wrong, it sends a reset packet in both directions.

Level 12

Nice trick to add to my arsenal, thanks a lot glenkemp !

Level 10

very interesting, i haven't actually used filters with flags so ill make sure to put this one in the books. looking forward to what interesting trick comes next

Level 15

That's an EXCELLENT point that you really can leverage these tools more with a solid understanding of what 'normal' is for your environment and how the devices interact with each other.

Kudos.

Level 7

Very informative

Level 13

Very useful. Thanks for this post!

Level 11

Now I have something else to play with. Thanks for this information.

Level 11

Great keep them coming

Level 10

Pretty much all firewalls, and most routers have some sort of ALG/Fixup/Helper for the many protocols; but in most cases I would expect packet drops to be silent these days..

Level 10

You won't have to wait long, Part III is up now! Deep Packet Analysis - What's in a Name (service)?

Level 14

Just to help solidify the syntax in my brain, I went looking for Reset flags on the inner interface of my firewall.  I found a pair of systems not communicating properly and was able to let the owners of the offending machines know.  Thanks.

Level 15

Bookmarked.  This is an educational and informative posting.

About the Author
Glen Kemp is a professional services consultant for Fortinet Inc. in the U.K. His words are his own and do not necessarily reflect those of the company he works for. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. His blogs can be found at sslboy.net and at the Packet Pushers Podcast. Follow him on Twitter @ssl_boy.