Conntrack
This chapter covers some aspects related to system conntrack, which is a
feature that allows the user to track connections through OSDx devices.
The conntrack utility provides a featured userspace interface to the Netfilter connection tracking system. It can be used to dump a list of all (or a filtered selection of) currently tracked connections.
Connection Format
All connections can be structured in a similar fashion to the one shown below:
icmp 1 25 src=10.0.0.1 dst=10.0.0.2 type=8 code=0 id=18723 vrf=RED packets=2 bytes=168 src=10.0.0.2 dst=10.0.0.1 type=0 code=0 id=18723 vrf=RED packets=2 bytes=168 mark=33 use=1 appdetect[L3:1]
In the example above, you can see a ping connection using a vrf called RED. It contains both an origin and a reply message (each with its own fields, such as the source (src) and destination (dst) ip address and message code and type), as well as global parameters like the protocol used (icmp), the number of packets and bytes transmitted, and the id.
In addition to the fields mentioned, there are others related to the traffic policies established in the connections. For example, information on whether the connection is bypassed or not (Sc: not-bypass) can be found, as well as on the mark packet, the offloaded flag ([OFFLOAD] or [HW_OFFLOAD]), and app-detect data (appdetect[engineId:appID]). More information about these fields and their configuration is found in Traffic Routing Articles and Firewall Service.
Running the system conntrack monitor command will monitor all current connections (containing the previously described fields) via three different states:
NEW: New conntrack messages.
UPDATE: Updated conntrack messages.
DESTROY: Conntrack messages indicating disconnection.
Logging
system conntrack logging is an option that allows conntrack information to be sent via syslog.
The message types to be captured, NEW, UPDATE, DESTROY or ALL of them (events option with destroy as default value) must be configured, as well as
the log level of those events (log-level option). This last option indicates the log level at which messages will be displayed,
and not their own level. For example, setting this option to err will display the conntrack messages with error format, but
configuring it with debug will show the information with debug style (info level by default).
The expected output when running system journal monitor or system journal show will be as follows:
osdx ulogd[9431]: [NEW] ORIG: SRC=10.0.0.1 DST=10.0.0.2 VRF=RED PROTO=TCP SPT=55406 DPT=80 PKTS=6 BYTES=577 , REPLY: SRC=10.0.0.2 DST=10.0.0.1 VRF=RED PROTO=TCP SPT=80 DPT=55406 PKTS=4 BYTES=653 MARK=33 LABELS=LOCAL APPDETECT[L4:80 http-host:10.0.0.1]
In addition to the default conntrack message, the label field associated to a traffic policy and the app-id related to the traffic detection are also included.
Identifier ulogd is optional. Using the commmand system conntrack logging identity <txt> is possible to customize the identify to OSDx_DUT0 for example.
Some examples of this feature and how to configure it can be found here.
App Detection
system conntrack app-detect is an implementation based on the RFC6759
that enables visualizing application detection information in conntrack flows.
App Detection feature applies Deep Packet Inspection (DPI) to enrich traffic flows by assigning them an Application ID field and another protocol based detected data.
The Application ID field (App ID) is formed by two values: Classification Engine ID and Selector ID
Running system conntrack show, system conntrack monitor or configuring system conntrack logging
while this configuration option is set will display this field with the following format: appdetect[enginedID:appID “detected data”].
The assigned AppId can be used as a criterion for selecting and matching identified traffic sessions in stateful access-lists
and applying policies (Traffic Policy).
Engine ID
Indicates the abstraction layer associated to that flow. There are three possible values: L4 (Layer 4 protocol, such as an http connection), L3 (Layer 3 protocol, like ICMP) and U (Userspace, which corresponds to layer 7 applications).
App ID
Indicates the identifier associated to the Engine ID detected. If the engine ID is “L3” (i.e icmp protocol), then this number will reflect the code associated to that protocol (icmp corresponds to protocol code 1, as indicated in RFC792). If the engine ID is “L4” (i.e http protocol), then this field will indicate the port used during the connection (http typically runs in port 80). Futhermore, the activated application detectors can override the normal AppId assignment for detected applications. For example, the L4:80 (HTTP) AppId can be assigned to a session connecting to an 8080 server port if the HTTP application is detected. Finally, if the engine ID is “U”, then the AppId identifies a layer 7 traffic with a value that can be set using different mechanisms.
One of the mechanisms mentioned above involves creating a traffic policy with a custom AppId and configuring that policy in an interface as follows::
set traffic policy Test rule 1 set app-id custom 33
set interfaces ethernet eth4 traffic policy in Test
Sending some traffic with ping <ipv4|ipv6|txt> and running system conntrack show will output the following:
icmp 1 28 src=10.215.168.1 dst=10.215.168.64 type=8 code=0 id=17504 packets=2 bytes=168 src=10.215.168.64 dst=10.215.168.1 type=0 code=0 id=17504 packets=2 bytes=168 mark=0 use=1 appdetect[U:33]
where the appdetect field is displayed with the app-id custom value.
It is possible to create a customized dictionary with specifics AppIds and FQDNs via CLI.
The configuration command is system conntrack app-detect dictionary <u32> custom app-id <u32> fqdn <txt>.
Furthermore, an application name for that AppID could be included using system conntrack app-detect dictionary <u32> custom app-id <u32> name <txt>.
The Classification Engine ID assigned for this dictionary is 6.
Another mechanism involves defining a dictionary file (XML or GZIP extensions if it is compressed) containing different sets of identifiable applications. An application is defined by its name, an AppId, an optional list of FQDN patterns and an optional list of IP ranges. An example is shown below:
<?xml version='1.0' encoding='UTF-8'?>
<provider engine_id="128" name="Teldat">
<app id="30" name="Teldat Test" version="1">
<fqdn_list>
<fqdn>10.215.168.1</fqdn>
</fqdn_list>
</app>
<app id="31" name="Teldat Test 2" version="1">
<address_list>
<range id="1">
<net_address>10.215.168.64</net_address>
<net_mask>255.255.255.192</net_mask>
</range>
</address_list>
</app>
<app id="69" name="Teldat Test sdwan-lab" version="1">
<fqdn_list>
<fqdn>teldat.com</fqdn>
</fqdn_list>
</app>
</provider>
In this case, configuring system conntrack app-detect dictionary <u32> filename <file> with these applications
and system conntrack app-detect enable_dict_match_priv_ip, setting an SSH connection to 10.215.168.64,
and running system conntrack show will output the following:
tcp 6 3597 ESTABLISHED src=10.215.168.1 dst=10.215.168.64 sport=52360 dport=22 packets=18 bytes=1016 src=10.215.168.64 dst=10.215.168.1 sport=22 dport=52360 packets=21 bytes=2452 [ASSURED] mark=0 use=1 appdetect[U:31]
where app-id 31 corresponds to the “Teldat Test 2” application identifier.
Note
Even though, by default, SSH corresponds to an L4 engine ID with port 22 (app ID), the paths configured rename the engine ID to “U” and the app ID to 31 (as set forth in the dictionary file).
It is also supported the usage of an application dictionary from the external provider Quatily. Quatily dictionary format uses .ENC (encrypted) extension to keep its original content obfuscated. The Classification Engine ID assigned for this dictionary is 129.
Detected Data
The last information represented by the app-detect feature refers to specific information on traffic traversing the OSDx device.
This information must be first configured in the system conntrack app-detect path.
If no option is configured, no data will be displayed. The options are:
dns, dns-host, http, http-host, http-referer, http-url, http-user-agent, ssl and ssl-host.
For the DNS inspection to be applied, the applications defined in the configured application dictionary must include FQDNs. When activated, the command analyzes DNS sessions by comparing the requested FQDN against the configured application dictionary. On DNS detection, the L4:53 AppID is assigned to the session (regardless of the server-side port used for connection purposes). Using the option dns-host will display DNS Host header domain names and canonic names (aliases) from the first session request.
HTTP analyzes TCP sessions looking for traces of the HTTP protocol. Versions 1.0 and 1.1 are both detected. Only the initial session request is inspected, so persistent connections only extract HTTP fields belonging to the first request. GET, PUT, POST, HEAD, TRACE, DELETE, OPTIONS and CONNECT are the supported HTTP request methods. On HTTP detection, the L4:80 AppID is assigned to the session (regardless of the server-side port used for connection purposes). In addition, http-host will display Host header domain names, http-referer the referer headers, http-url the URLs from the first session request and http-user-agent the user agent to identify the application.
SSL analyzes TCP sessions in search of SSL/TLS handshakes. Both SSL and TLS are detected, regardless of the version. Only the initial Client Hello of the session is inspected. When SSL/TLS is detected, no specific AppID is assigned to the session as SSL/TLS is not a final application but a transport, so the server-side port number carries more information regarding the application (e.g., 443 for HTTPS or 5061 for SIPS). The option ssl-host will display server host domain extracted from the Sever Name Indication (SNI) extension linked to Client Hello.
For example, if http-host is configured and there is some communication with an http server,
running system conntrack show will display the host the OSDx device has connected to:
tcp 6 17 TIME_WAIT src=10.215.168.64 dst=10.215.168.1 sport=41666 dport=80 packets=6 bytes=583 src=10.215.168.1 dst=10.215.168.64 sport=80 dport=41666 packets=4 bytes=504 [ASSURED] mark=0 use=1 appdetect[L4:80 http-host:10.215.168.1]
where the host of the http server corresponds to ip 10.215.168.1
Note
More information on this last option will be displayed by configuring system conntrack app-detect debug and
running system journal show or system journal monitor