Detecting Application Tunneling with NetFlow

With today’s networks getting larger and larger and with the need to accommodate end-user devices, locking down the network without affecting performance is becoming a major concern. This blog will cover how some malicious end users often try to obfuscate their traffic on the network and how by using our NetFlow and metadata collector, we can proactively alarm when these types of behaviors are seen.

Application Tunneling

Application tunneling is often described as running applications over non-standard ports. A common example of this is running SSH (typically port 22/TCP) over port 53, which is commonly used for DNS. The reason why this works so well to get data off the network (or to use disallowed applications) is that unless a device is doing DPI (Deep Packet Inspection), there is no real way to decode what’s running over a port/protocol. This is where basic NetFlow v5 tends to fall short. Luckily, with the advancements of NetFlow and IPFIX, DPI elements are often very easy to export.

Taking the example of someone tunneling VPN traffic (non-corporate) over port 8080 TCP (commonly used for web proxys), we can see how a next-generation flow collector handles this. Using basic NetFlow v5, we can see already where it falls short. The image below shows a connection between my client device (10.50.5.36) and an http-alt connection to an internet-facing IP. This does not tell me much and since this is encrypted, I can’t get much more information.

Using NBAR and IPFIX

If we change this report to use some DPI elements, such as NBAR/NBAR2 from Cisco devices or PAN-OS fields from Palo Alto, we can see much more detail in the conversation that my device had without any SSL decryption. For this example, I will be using the DPI engine from a SonicWALL firewall. As you can see below, it doesn’t just detect VPN traffic—it correctly identifies the vendor of the VPN service I am using, even though I tried to obfuscate it over odd ports. While packet capture has its uses on the network, this is a lot more efficient in both time and resources.

From here, it would be a very easy workflow to tag this behavior with a threshold and take a proactive stance when non-corporate applications are running over odd ports. Using our NetFlow and metadata collector, we can send these alarms as Syslogs to your SIEM for further event correlation or email the necessary party who can take action using the information we have found.

Future of DPI Applications

Since application tunneling is such a common way for a malicious user to avoid the corporate firewall/proxy, it may already be happening on your network. Maybe they aren’t trying to steal corporate secrets and just want to catch up on Game of Thrones—but how can you really be sure? Feel free to reach out to our team here at Plixer to see how we can help detect these types of traffic and alert you proactively when they are seen!