How to Remember Your TCP Flags

A mnemonic for the six flags, and why their order gives you the tcpdump filter numbers for free
June 28, 2014
Daniel Miessler

TCP header

the tcp header, with the six flags in the middle of the fourth row

Many people are familiar with the concept of a mnemonic, a memory device that uses a phrase based on the first letter of words in a series. Perhaps the most popular of these in the field of networking is the one for the OSI Model (All People Seem To Need Data Processing).

Well, for those that deal with TCP/IP a lot, I thought it might be helpful to have a mnemonic for the TCP flags as well. What I've come up with and use regularly is:

WordFlagWhat it does
UnskilledURGUrgent pointer is valid
AttackersACKAcknowledges received data
PesterPSHPush the data to the application now
RealRSTReset the connection
SecuritySYNSynchronize, the start of a connection
FolksFINFinish, the polite close

Uses ​

TCP flag information is most helpful to me when looking for particular types of traffic using tcpdump. It's possible, for example, to capture only SYNs (new connection requests), only RSTs (immediate session teardowns), or any combination of the six flags really. As noted in my tcpdump tutorial, you can capture these various flags like so:

bash
# Find all SYN packets
tcpdump 'tcp[13] & 2 != 0'

# Find all RST packets
tcpdump 'tcp[13] & 4 != 0'

# Find all ACK packets
tcpdump 'tcp[13] & 16 != 0'

Notice the SYN example has the number 2 in it, the RST the number 4, and the ACK the number 16. These numbers correspond to where the TCP flags fall on the binary scale. So when you write out:

…the mnemonic gives you the bit values in order, which is the whole trick. Here's the same byte drawn out, with the two flags above the six (CWR and ECE, used for congestion control) included:

TCP flags byte

the flags byte, and how the values in filters add up

Example ​

So as you read the SYN capture tcpdump 'tcp[13] & 2 != 0', you're saying find the 13th byte in the TCP header, and only grab packets where the flag in the 2nd bit is not zero. Well if you go from right to left in the UAPRSF string, you see that the spot where 2 falls is where the S is, which is the SYN placeholder, and that's why you're capturing only SYN packets when you apply that filter.

text
# tcpdump 'tcp[13] & 2 != 0'

12:40:04.649404 IP 10.5.1.42.51584 > 64.233.187.99.http: S 1524039069:1524039069(0) win 65535
12:40:04.708459 IP 64.233.187.99.http > 10.5.1.42.51584: S 1416742397:1416742397(0) ack 1524039070 win 8190

You'll notice that when I netcat'd to Google on port 80 from another terminal, tcpdump shows only two out of the three steps involved in the three-way handshake. It didn't show the third because the final step is simply an ACK from my side, i.e. no SYN flag set.

Conclusion ​

Remembering these flags and how to make use of them can go a long way in helping low-level network troubleshooting/security work by isolating what it is you want to see and/or capture. And of course the better you can isolate the problem, the faster you can solve it.

Notes

  1. Originally written in April 2004.
  2. 🤖 AIL 1: Daniel wrote this post. I (Kai, his AI assistant) cleaned up the formatting, added the flag table, the diagram, and the note on named flags. Learn more about AIL.