Software Assurance Secure Systems Organizational Security Coordinating Response Training
Skip to end of metadata
Go to start of metadata

The CERT NetSA Security Suite provides a large feature set for network flow analysis. This tooltip focuses on leveraging the application label feature of Yet Another Flowmeter (YAF) for analysis of tunneled SSH application traffic. As YAF aggregates packets to flows, it examines packet payloads and determines the application in use. YAF then sets the application label of each network flow record with a corresponding application number. Application numbers, often equal to the default port number, are specified in /etc/yafApplabelRules.conf and used by YAF via a combination of plugins and regular expression matching. For example, the label statement label 22 regex ^SSH-\d.\d assigns the numeric label 22 to flows that contain SSH-n.m, where n and m are numeric values. The label statement label 443 plugin tlsplugin tlsplugin_LTX_ycTLSScanScan assigns the numeric label 443 to flows which a binary plugin identifies as representative of TLS/SSL protocol traffic. If a packet payload does not match any of the configured application expressions, the application label will be set to ‘0’ for unknown.

The presence of application labels in network flow records provides analysts the ability to identify applications irrespective of port number or direction, and assists security teams with validation and discovery of various network traffic. Application labels are selectable by the analyst by using the ‘--application’ switch of rwfilter in combination with the corresponding application number. Application numbers are specified individually or with a comma separated list.

rwfilter --start-date=2013/01/01 --proto=6 --type=out,outweb --application=22

rwfilter --start-date=2013/01/01 --proto=6 --type=out,outweb --application=22,443,80

The previous example demonstrates use of the application switch, and will provide limited utility to an analyst looking for tunneled SSH traffic. Therefore, we will explore a use case that leverages application labels and the SiLK app-mismatch plugin. The plugin (app-mismatch.so) provides rwfilter with a simple method to partition network flows containing application numbers where neither the source or destination ports match that number. This removes the need of specifying ports to rwfilter, and allows for identifying protocols not running on their default ports.

Our example use case is to partition network flow records that are representative of established outbound SSH client sessions communicating with a destination port other than 22/TCP. This can be accomplished with the following rwfilter statement, saving the results to a SiLK raw file (detailed explanations of switches follow the example).

rwfilter --start-date=2013/01/01 --plugin=app-mismatch.so --type=out,outweb \
--proto=6 --sport=1024- --app=22 --packets=4- --flags-initial=S/SURFPACE \

--start-date: all flow records for the day of January 1, 2013
--plugin: load the app-mismatch.so plugin
--type: select the out and outweb traffic types
--proto: protocol number 6 (TCP)
--sport: source port 1024 and above (client ephemeral ports)
--app: application number 22 (using short notation)
--packets: 4 or more packets (established, two-way communication)
--flags-initial: the initial packet flag on the flow was a TCP SYN (client initiated)
--pass: write resulting flow records to a binary SiLK file (tunn-ssh.rw) 

Application labels are accessed by specifying the ‘application’ flow attribute field to multiple SiLK tools (rwuniq, rwtuc, rwcut, rwgroup, and rwdedupe). Because this field is not a default selection for these tools, the field name or number must be specified by the user.

rwcut --fields=sip,sport,dip,dport,stime,application tunn-ssh.rw

rwuniq --fields=3,29 --packets=4 --bytes=500 tunn-ssh.rw

The rwcut command generates a table of flow field values in the order specified, including the ports and the application values for each flow record. The rwuniq command generates a summary table for flows based on a key of source port and application number, showing the number of packets and bytes aggregated for each port-application pair, but only if there were at least four packets and at least 500 bytes (which may provide a useful summary of which mismatches had the most content).

This is just one example of how to leverage the application labeling features of YAF and SiLK. Other potential use cases include validating HTTP network flows on destination port 80 or TLS on port 443; these are left as an exercise for the reader.

  • No labels