We had a reader send an email in a couple of weeks ago asking about understanding the flags field when looking at data in a report.   He didn't understand what the "flags" were referring to or what the actual flags mean. "They don’t appear related to TCP header flags like I’ve normally seen...S is the most common but I occasionally see RSA, RUS and a few others."

It's a great question to ask and understand to be a good analyst!!  I appreciated the question and desire to understand what it meant!  I personally feel many analysts today are way too dependent on the GUI interface to tell them everything; with no understanding of the tool or network protocols.  Way to often I encounter analysts who look at a GUI interface, but have NO idea how the tool works and in many cases what the data is telling them.  So, they aren't sure why they don't see data they thought they would or they don't know how to interpret the data other than what's on the screen.  In this scenario, without knowing the tool generating the data, there are at least two possible explanations!  I really don't know if he is looking at Netflow logs or if this is a firewall (or another tool).  I did not have that information.  Honestly the flags he listed would work for logs in both scenarios.  However, their interpretation becomes different based on the tool generating it.  I'll explain both based on the following info provided in the email:

"S is the most common but I occasionally see RSA, RUS and a few others."

In case you're not familiar with the flags in a TCP header, here is a high-level overview of the flags (NOTE:  I'm not listing ECN flags for this example):

U = Urgent (URG) - There is an urgent pointer set, process the information/command at the location in the packet the pointer is pointing to immediately (think CTRL-C in the middle of a FTP session to kill it)
A = Acknowledgement (ACK) - Acknowledges receipt of data and is used to ensure data isn't lost (used by both sides of the session since TCP is bi-directional)
P = Push (PSH) - For the receiving system, don't let the data sit in the buffer, push it immediately to the application
R = Reset (RST) - I'm not talking to you at all or I'm done talking to you and I'm killing the connection.  No communication set up or no graceful termination of the session
S = Synchronize (SYN) - Initiate the Initial Sequence Number (ISN) that will be the starting point for that session to track data with the ACK flags.  Remember, used only during the initial three-way handshake!  You should NOT see it anywhere else in the session.
F = Finish (FIN) - Used in the graceful termination of a session.
 

Scenario 1 - Netflow:  Netflow is meta data about packets that is aggregated to represent a flow of information.  So, it's not looking at just one packet and its flags.  It's looking at the entirety of the flow.  If it's netflow traffic, then usually the flag fields are abbreviated to just the letter (Yes, it can be a decimal sum in some tools, but for this example please see the letters above) AND they are the representation of all flags seen for that specific flow/session.  So, if you see RSA, then the RST, SYN and ACK flags have been set at some point during this flow in some packet or packets.  What you don't know without packets or some analysis, is the combination within the packets.  This could be "normal" such as:
    

Or not normal such as:

Scenario 2 - Firewall:  If its firewall traffic, some firewalls use just the letters for the flags fields in their logs as well.  It depends on your firewall and the level of logging you have turned on as to what data you will have in your logs.  If it is a firewall log your looking at, then the flag fields are NOT the sum but rather the actual flags set for that specific packet.  The traffic would look like this:  

So, if you see RUS or RSA, definitely not a normal or legitimate flag combination.

In the examples above, each tool's function drives how to interpret the flags field.  Same field, different interpretation!  So, when you're doing analysis, you have to know your tool and its capability in order to understand your logs!!  Without it, your analysis can be severely hindered or flat out wrong!   I appreciate a GUI interface, but think we have forgotten to take the time to teach new analysts what many of us learned coming up the ranks when the GUI wasn't so prevalent!  Teach them the fundamentals.  Give back to the security community and take the time to help the new analyst who wants to learn.  Please don't give them a GUI interface to watch and then forget them!