Forwarding UDP Packets

Michael Patterson : Advanced NetFlow Traffic Analysis
Michael Patterson
Founder and Product manager for Plixer's Scrutinizer NetFlow and sFlow Analyzer as well as Flow Analytics.

Forwarding UDP Packets

Many threat detection systems rely on reviewing logs in order to uncover contagions on the network.  In most cases, these logs come in the form of syslogs, NetFlow and IPFIX.  In an effort to protect the corporate jewels from the growing attack continuum, some organizations resort to sending the same system logs to multiple security platforms which look for surreptitious infections in different ways.  It can become a problem when hundreds or even thousands of devices need to be reconfigured to send logs to a second, third or fourth source.  All of these export changes can add up to several weeks o work and errors are inevitably introduced.

As a result of adding new log collection systems that try to find cyber threats, system administrators must find ways to start forwarding streams of UDP packets to multiple collectors.  Even if the time necessary to reconfigure thousands of devices to send flows to a 2nd system isn’t an issue, many log sending systems can only forward their messages to a single IP address and that becomes a real problem.  One way to overcome this problem is to introduce a UDP forwarder or UDP forwarding system. 



UDP Forwarding

A UDP Forwarder receives packets, duplicates them, changes the destination IP address and leaves the source IP address intact.  As a result, the collector believes it received the packets directly from the source and the UDP Forwarding appliance becomes transparent to the process. On the surface, it appears to be a pretty simple process but, customers always want more features such as:

  • Performance at wire speed : 10G+.  The process of forwarding UDP packets means that more data is being generated is coming into the appliance.
  • Auto assignment : New UDP exporting devices coming from certain subnets should have their datagrams auto forwarded to specified collectors.
  • Fault tolerance : Should the UDP forwarder break, a 2nd system should be standing by to auto assume the responsibility of forwarding UDP packets.
  • Metrics : Once the deployment gets large, wrapping ones arms around the magnitude of the configuration can become difficult. 
  • Intuitive GUI and Restful API : The solution needs to be simple to configure and provide the techies with an API that allows them to perform specialized tasks.

UDP Director Vs Flow Replicator

As a result of some of the above, the forwarding of UDP packets has evolved into an entire industry.  Cisco has something called the UDP Director™ and Plixer has something called the Flow Replicator™.  Comparing the these competitive solutions is not the goal here.  It is however important to do a side by side comparison when evaluating competing products.  The Flow Replicator vs. the UDP Director might be a good topic for another post.  Below is a visual example provided by the Flow Replicator.  It does a good job of graphically representing the UDP Fanout capabilities.  The first column is the UDP exporter.  The second column is the profile that contains all of the exporters sending to the collector in column 3. 

forwarding UDP packets

UDP Forwarding Drastically Improves Incident Response

One of the primary objectives of many malware types is to delete the logs created by the contagions activities. By forwarding UDP packets that contain these logs to multiple systems, efforts by the malware to delete them becomes nearly impossible.  First the malware would have to figure out where the logs are going.  Second, the UDP forwarder would have to be compromised to figure out where the logs are being forwarded to.  Third, each collector receiving the forwarded messages would have to be compromised. Most malware simply won’t put in the effort as each compromise increases the risk of getting caught.

Related Articles to 'Forwarding UDP Packets'
Feedback for Forwarding UDP Packets

Leave a comment

Featured Events