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:
| Word | Flag | What it does |
|---|---|---|
| Unskilled | URG | Urgent pointer is valid |
| Attackers | ACK | Acknowledges received data |
| Pester | PSH | Push the data to the application now |
| Real | RST | Reset the connection |
| Security | SYN | Synchronize, the start of a connection |
| Folks | FIN | Finish, the polite close |
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:
# 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:
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.
# 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 8190You'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.
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.