Welcome!

Network Aware, Business Secure

Michael Patterson

Subscribe to Michael Patterson: eMailAlertsEmail Alerts
Get Michael Patterson via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: PC Security Journal, Citrix Virtualization Journal, Cisco Virtualization Journal, Security Journal

Blog Feed Post

A Firewall Monitoring Tool You Didn’t Know Existed: NetFlow and IPFIX

IT professionals have been looking for better ways to monitor and store firewall logs for years. Properly handled, firewall events can give insight into APTs, DoS attacks, firewall rule planning and misconfigurations, policy violations, and much more. To date, Syslog has been the go-to mechanism for access to firewall log info. It’s universally supported by the firewall community, easy to understand, and it’s quick to implement on both the firewall as well as the syslog analyzer.

Unfortunately syslog is resource intensive on both the firewall and the log analyzer. It’s largely unstructured, requires string pattern matching, and the exact format and fields vary from one firewall to the next. How often do you turn on full “Accept” and “Deny” logging for every rule? Sure you can and yes it’s valuable but the amount of syslog created is tremendous.

Enter NetFlow and IPFIX

Routers and switches have supported NetFlow and IPFIX for years. In early days manufacturers realized they had precious few resources to spend and that routing packets was job #1, impact to CPU resulting from logging features must be kept to a minimum. NetFlow helped solve this, especially for Cisco Systems. Flows are structured, compact data elements that describe every IP datagram that passes through the device. When you tell the router to begin “exporting” them to a Flow Collector such as Plixer’s Scrutinizer you get deep visibility into exactly what the router is routing. Top talkers, interface utilization, DoS detection, policy violations, the list goes on.

Recently, starting with Cisco’s ASA NSEL feature, we’ve seen a sharp uptick in the number of firewalls that can export flows. Taking lessons from the router and switch community, firewall vendors have learned that NetFlow/IPFIX can be a major advantage to everyone involved. A quick list of popular firewalls that currently support NetFlow or IPFIX include:

Palo Alto Networks (NAT translations, usernames, application)

SonicWALL (NAT translations, application, URLs)

Barracuda NG Series (ACLs, MAC address) 

Cisco ASA (NAT translations, usernames, ACLs, limited due to missing fields)

CheckPoint (IPSO only, v5 fields, consumes 25% state table space)

<vendors, contact us to be added to this list, mention this blog>

 

Here’s why NetFlow/IPFIX has become such a popular feature in modern firewalls…

Customers:

  • Flows will help you diagnose problems with firewall rules.
  • Flows will help you plan for new rule insertion. “Firewall planning”. Simply run a flow query against the source and destination addresses and see who the rule would impact.
  • You get visibility into key locations within the network that need to be closely monitored but historically couldn’t due to high “Accept” log rates. Crushing the firewall via syslog logging is a bad thing.
  • You probably already have a flow collector that you can bring to bear on the firewall’s NetFlow/IPFIX logs. As long as your collector fully supports IPFIX you should be all set. If your collector falls short you can always try Plixer Scrutinizer for free.
  • Your IT security guys, even if they don’t manage firewall rules, will get tons of network security benefit from NetFlow coming from the firewall.
  • Sometimes the only devices that are NetFlow/IPFIX enabled are the firewalls. It’s not uncommon to see a situation where the network guys just won’t turn NetFlow on in their devices. For you security types, the firewall might be your only answer to detailed traffic accounting since you control the firewall itself.

Vendors:

  • Flow export will be a differentiator for your firewall, especially against those that don’t support flow export or who’s exports aren’t all that robust (CheckPoint, one of the original enterprise firewalls, has poor support for NetFlow – only in IPSO and reduces connection count by 25%).
  • Customers that enable firewall flow export will get more value out of their existing solutions, encouraging maintenance renewals and hardware refreshes. Maintenance is good amirite?
  • More and more SIEM vendors are supporting NetFlow/IPFIX. While they don’t provide the same capabilities as something like Plixer’s Scrutinizer, they can still make use of the flow data for correlation purposes.
  • You get one syslog message per UDP packet while you get around 24 flows per UDP packet. Lower bandwidth, lower CPU, less overheard.

A few more notes for you firewall vendors out there that might be considering flow export features. If you want more details on any of these suggestions contact us:

  • Remember that the whole point of a flow export feature is to be more efficient at exporting detailed traffic information and the results of packet hits against ACLs/rules. If enabling flows is going to consume half the resources in your firewall you probably haven’t done it right.
  • IPFIX, just do it. Don’t use NetFlow v9. It’s Cisco’s brand and they pretty much own it and all the IDs included.
  • Don’t call it something you made up like “AppFlow” or “jFlow”. Just call it IPFIX. It’s easier for everyone. Not to hate on Citrix’s NetScaler AppFlow feature, it’s quite nice. But it’s just IPFIX with a brand name and some really interesting elements.
  • It’s not just syslog over NetFlow/IPFIX. You should include cool stuff like what Palo Alto Networks Application Aware NetFlow v9 or like what SonicWall has done with URLs and IPFIX.
  • At this point if you haven’t already added flow export then you’re catching up; do something unique and differentiating. Like, oh I don’t know, fully qualified ACL names anyone?
  • Make a big deal out of it! Talk about it in marketing materials and brief your sales engineers on it. THOROUGHLY. Other’s haven’t, they are missing an opportunity.
  • Talk to us first before you draw up your requirements; we can help. You need to know about things like timeouts, proper ifindex usage, directionality, cache size, minimum fields (see NetFlow v5) and more.
  • Send us your betas, we’ll help you test and blog about the results once you’re happy with them (the results that is, we won’t publish until you’re ready).
  • Don’t use sFlow.

Again, let us know if you have questions about NetFlow, IPFIX, or Plixer’s Scrutinizer Flow Analysis System. We’re the experts and we’re here to help.

BTW: Join the NetFlow Developments group on LinkedIn.com if you haven’t already. More info and discussion on flow analysis technology can be found there.

 

Read the original blog entry...

More Stories By Michael Patterson

Michael Patterson, is the founder & CEO of Plixer and the product manager for Scrutinizer NetFlow and sFlow Analyzer. Prior to starting Somix and Plixer, Mike worked in a technical support role at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix and Plixer.