Filtering trusted and forensically unwanted traffic should be a top priority for every enterprise running NextGen. By discarding the trusted and known, only the untrusted and unknown traffic will remain. The following document discusses how to embark on a filtering project using a risk-based approach to eliminate the capture of traffic that only eats up decoder disk space. Just ask yourself: "Do I really need 340 gigs of icmp traffic?" The answer is always no.
Embedded in the document are two Informer reports that will automatically suggest tuning candidates for you as well, taking out a bulk of the analysis time.
I'm trying to get a handle on this for our organization. I believe the rules are more complex than first glance and I'd love to get some feedback:
I want to keep the meta data, but drop the streaming video packet data for YouTube.com
This implies using an Application filter at the Decoder level. Using "alias.host" in the rule is problematic as alias.host is set (for example) in links in email messages as well as embedded links in other web sites. As a result, "alias.host ends youtube.com" filters too much. In much the same vein, "action != put" can be set by other links in a web page or email message, unrelated to a youtube.com action.
So, what about using an IP address to trigger the filter/truncate rule? As I write this, youtube.com is 11 IP addresses. They change over time and they don't reverse-resolve to youtube.com. So, you can write a rule that looks for those sessions: ip.dst = '173.194.46.32-173.194.46.41','173.194.46.46'
OK, that shows Service Types of HTTP, OTHER, and SSL (NetWitness flags some of the YouTube traffic as "unknown service over ssl port"). So, let's add tcp.dstport = 443 to the mix...
As you can see, one has to more-or-less reverse-engineer how YouTube works in order to effectively write a filter for it.
Also, since this solution uses IP addresses, one has to periodically query DNS to see when they change. This could potentially be automated by using a custom Live Feed, but I haven't gone to that length yet.