Security vendors have recommended proxies as a means of protecting security, with detection to identify evasion. Commonly proxied network applications include web browsing, email sending and receiving, VPN access, and DNS resolution. These proxies allow protection against several security threats, as well as content-based filtering for security threats and data exfiltration. Traffic that bypasses such proxies (e.g., by accessing upstream, external, or unauthorized servers directly) is useful to track because it offers insight into potential security gaps and into the effectiveness in practice of employing specific security proxies. Some organizations have configuration standards requiring proxy use, so this tracking would also be useful for compliance verification. In this blog post, I discuss how to track the amount of network traffic that is evading security proxies. The network traffic of interest is for services that such proxies are expected to cover.

This post is the first in a series addressing a simple question: “What might a security operations center (SOC) analyst want to know at the start of each shift regarding the network?” In each post, we will discuss one answer to this question and application of a variety of tools that may implement that answer. The goal here is to provide some key observations that will help the analyst monitor and defend the network, focusing on useful ongoing measures rather than those specific to one event, incident, or issue. We will not focus on signature-based detection, since there are a variety of resources for such, including intrusion detection systems (IDS) / intrusion prevention systems (IPS) and antivirus products. The tools used in these articles will mainly be part of the CERT/NetSA Analysis Suite, but we will include other tools if helpful.

Our approach will be to highlight a given aspect, discuss the motivation behind the analytic, and provide the application as a worked example. The worked example, by intention, is illustrative rather than exhaustive. The decision of what analytics to deploy, and how, is left to the reader. If there are specific behaviors that readers would like to suggest, please send them by email to netsa-help@cert.org with a subject line “SOC Analytics Idea”.

The analytic for tracking network traffic that evades security proxies assumes that the population of proxies for each service is known (at least as a list of IP addresses), and that the address space for the network being protected is also known. While proxies are useful, if there are occasions when they must be bypassed (for example, when delays in traffic transmission must be avoided), the affected addresses or ports are assumed to be known. The analytic also assumes that evasion is not being done by tunneling through a separate protocol, such as using a VPN or establishing a transport-layer security (TLS) connection to access an unauthorized service host.

The approach taken in this analytic is straightforward, paralleling rule-based approaches for detecting evasion. First, isolate outbound traffic for the desired service (for example, DNS), with sufficient content to assure that this is not a probe or an aborted connection, and not involving one of the identified proxies. The sufficient content part of this analytic requires separate handling of TCP (protocol 6) and UDP (protocol 17) traffic, for those services where both may be employed, since the respective packet formats differ. After the two sets of traffic are isolated, they are combined and summary statistics are reported. For proxy evasion, the desired results are often the source of the evading traffic. For the authorized bypasses, these sources should be consistent and identifiable. The remaining sources can be presumed to be unauthorized.

Figure 1 presents a series of SiLK commands to implement this analytic to identify evasion of DNS proxies, together with a set of results from executing these commands on sample data derived from a security exercise. The rwfilter commands do the traffic isolation. The rwsort command combines the results. The rwstats command is used to report results. In this example, only a few hosts seem to be evading the proxy. The network security personnel could follow up and evaluate if these hosts are authorized to do so.

Figure 2 shows the analytic implemented as a configuration for analysis pipeline. The two filters, serverDetectDNS_detectDnsUDPnotProxy_filter and serverDetectDNS_detectDnsTCPnotProxy_filter, isolate the service traffic that evades the DNS proxy for UDP and TCP, respectively. The third filter, serverDetectDNS_detectDnsTCPnotProxy_filter, combines the traffic from the first two, and it is in turn called by serverDetectDNS_detectDnsNotProxy_intfilter to produce IP addresses that are incorporated into a daily list of sources that evade the proxy. The final code, serverDetectDNS_detectedDnsNotProxy_list, sends this list as an alert (possibly to a security information and event management system).

Figure 3 provides an implementation of the analytic in SQL-like notation. This notional example assumes that IP flow information export (IPFIX) information elements are present in records, and that the list of known proxies is present in a separate table. The outer SELECT identifies the fields reported by the analytic. The inner SELECT isolates and summarizes the relevant traffic to be reported.

Whichever tooling is used, analysts often need an understanding of what traffic is, or is not, available to be inspected and reported by network defenses. This analytic is a start at providing this understanding, although over time, analysts should revise and specialize it to reflect their needs.