Filtering Methodology.docx

File uploaded by RSA Admin

on Sep 14, 2012

Version 1Show Document

Like • Show 0 Likes0
Comment • 6
View in full screen mode

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.

Attachments

Filtering Methodology.docx226.5 KB

Outcomes

6 Comments

Cris Rhea Apr 12, 2013 3:46 PM
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.
Like • Show 0 Likes0
Actions
Cris Rhea Apr 17, 2013 4:41 PM
Worked with Chris Ahearn (RSA) on an idea to fully-automate the creation and update of a Live Feed to handle this task.

My plan is to post this on this forum-- hopefully, the ideas will be useful to others.
Like • Show 0 Likes0
Actions
ftresgallo Apr 30, 2013 4:43 AM
Hi all,

Im trying to filter ARP traffic in our Decoder. So simple at first, is not working. I dont know how to specify the Ether Type for ARP:

My intention: if (eth.type = 0x0806) > FILTER

The syntax checker reports a wrong value for 0x0806. I've tried with 806, which passes the test, but it's not working because the ARP traffic continues to be assembled.

The official manual only gives a reference table for Ether Types and the like, but it does not show an example.

Could you give me a solution?

Thanks in advance,
Francisco
Like • Show 0 Likes0
Actions
- RSA Admin @ ftresgallo on Apr 30, 2013 8:53 AM
  To filter ARP traffic, you should refer to your alias.ini file to get the NetWitness alias for that protocol. The file is in plain text and is located typically at C:\ProgramData\NetWitness.
  
  The rule should be simply:
  eth.type=0x0806
  And set that rule to filter on the decoders. And since its a filter rule, also set it to stop rule processing and bump that rule to the top of your rule order. Let me know if that works for you.
  Like • Show 0 Likes0
  Actions
  - ftresgallo @ RSA Admin on Apr 30, 2013 9:36 AM
    Hi Fielder,
    
    I use a BPF as a workaroung to filter ARP ("not ether proto \arp") but would like to implement the filter at the network rule level (for baselining, export...)
    
    I cannot find the mentioned "alias.ini" file. Where is that part documented officially? I use the NwAdministrator manual but cannot find more information.
    
    Thank you very much for your support.
    Like • Show 0 Likes0
    Actions
    - RSA Admin @ ftresgallo on Apr 30, 2013 9:52 AM
      I think its mentioned in the Investigator help file. If you have installed Investigator that file will be local as mentioned above. I personally think the rule works better as a capture rule but should work okay as a network rule. The BPF is a great workaround as that takes it completely out of the hands of the packet capture system, freeing up resources.
      Like • Show 0 Likes0
      Actions

Filtering Methodology.docx

Attachments

Outcomes

Related Content

Recommended Content