NetFlow URL

As more applications use TCP port 80, having an application aware NetFlow URL monitoring solution is of even greater importance on today’s networks.  The fantastic news is that the solution is already on your network: NetFlow and IPFIX.  Devices from Cisco, Sonicwall, Palo Alto, Exinda, nProbe, and others have been reporting application details using IPFIX/Netflow for years.  In this blog, I’ll focus on how both Cisco and Sonicwall use Deep Packet Inspection (DPI) to find URL information.

Cisco AVC – HTTP Host Reporting:

Cisco Application Visibility and Control (AVC) is a feature-set in Cisco network devices that provides greater visibility into the application layer.  Cisco AVC, as I mentioned in my introduction, uses DPI to report on HTTP information through NetFlow/IPFIX.  First, the Cisco device needs to be configured with Flexible NetFlow (FNF) to export the AVC information.  Once that configuration is setup, you can use your NetFlow Collector to see reports like HTTP Host, HTTP Host by Client, and HTTP Host Transmit Duration by Host.

In the above example, you can see each HTTP host address.  You might be asking yourself what the BLANK_STRING host is and why is it taking up some much bandwidth.  Drilling deeper into the raw flows:

The BLANK_STRING HTTP Host tag is Secure Socket Layer (SSL) traffic.  Cisco AVC does do DPI, but does not strip the Secure Socket Layer certificates.  How does this differ from what SonicWALL is reporting on?

SonicWALL NetFlow Analyzer – URL Reporting:

The SonicWALL NetFlow Analyzer reports on full URL strings.  This allows a network administrator to see if a URL was redirecting an end-user somewhere else or running an executable.  This will help any administrator tasked to perform a forensic investigation and reduce the mean time to know (MTTK).

The main difference between Cisco and SonicWALL NetFlow URL reporting is that the SonicWALL NetFlow Analyzer can perform Deep Packet Inspection of the Secure Socket Layer (DPI-SSL); the inspection of encrypted HTTPS traffic.  As traffic crosses the SonicWALL, it is decrypted, inspected through DPI, re-encrypted, and sent to its destination if zero threats were found during the inspection.  In essence, the SonicWALL is performing a SSL Man-in-the-Middle Attack (MITM).  No other firewall vendor is doing this and providing this great of detail on your HTTPS traffic through IPFIX and DPI-SSL.

SonicWALL IPFIX Support:

I was recently working with a customer of a large university who was tasked by his CTO to find the amount of traffic Netflix traffic that was taking up their bandwidth.  We were able to utilize all reports, except URLs.  After reaching out to SonicWALL, it turns out you need to have the Content Filtering Service (CFS) enabled to view URL information for firmware higher than SonicOS 5.8.0:

SonicWALL IPFIX Support Knowledge Base:

This change applies to:

Gen6: NSA E10100, NSA E10200, NSA E10400, NSA E10800

Gen5: NSA E8510, NSA E8500, NSA E7500, NSA E6500, NSA E5500, NSA 5000, NSA 4500, NSA 3500, NSA 2400, NSA 240

Gen5 TZ Series: TZ 210, TZ 210 W.

Firmware/Software Version: SonicOS 5.8.0.0-27o and higher

11 – Q. Why is no AFM data showing for URLs while web traffic is traversing the firewall?

11 – A. The AFM URLs are dependent on CFS and therefore it might be an issue with CFS not being licensed/ activated, CFS is being bypassed for admin or other user sessions or the CFS policy assignment is set to ‘Via App Rules’ but no App Rule is present or active with a CFS category List match object.

As a side note, you do not need to be filtering any content to see the URL information.  It just needs to be enabled.  The customer was able to see the Netflix URL traffic:

What’s in the future for NetFlow URL Reporting?

Will more vendors create SSL-DPI features like the SonicWALL NetFlow Analyzer?  Will non-SSL traffic become extinct?  We’d love to get your feedback, either enter a comment below, or give us a call at 1-207-324-8805.