Create a rule to exclude Private IPs in Security Analytics
I want to create a rule in Security Analytics to exclude all private IPs. I do not have Warehouse implemention. It is a normal AIO appliance. So, I do not have access to CEP or any other complex rule creation features.
Can anyone help on this. I have tried NOT regex and NOT like. But they don't seem to be working.
- Community Thread
- Forum Thread
- RSA NetWitness
- RSA NetWitness Platform
You have to be more specific about what you are trying to do.
Do you want to exclude traffic from Private IPs to be captured by a decoder? This would be a BPF rule.
Do you want to exclude sessions from or to Private IPs from being seen in Investigator? or Reports? for this you would want to create some meta data that can be used to identify Private IPs so you can use EXISTS and !EXISTS conditions, or generate other meta.
I want to exclude all traffic on firewalls from private IP ranges. But this rule will be for concentrator not decoder !
In rule, there is the "Where" part. In that, I need an expression which filters out private IP traffic.
So it looks like you are trying to write a Rule in the Reporting Engine, and you would like to run a report against data from your firewalls that have been collected by a log decoder - is that correct?
If so, you should refer to the sadocs.emc.com site for information on how to structure a rule:
The best way to achieve what you want to do would be to create some Application Rules on the Log Decoder that will tag traffic from Private IPs with a piece of meta. You can then use that piece of meta in the report engine. Here is an example:
Rule Name: private
Condition: ip.src = 10.0.0.0/8 || ip.src = 172.16.0.0/12 || ip.src = 192.168.0.0/16
Alert To: net.src
create a second rule that matches based on destination IP:
Rule Name: private
Condition: ip.dst = 10.0.0.0/8 || ip.dst = 172.16.0.0/12 || ip.dst = 192.168.0.0/16
Alert To: net.dst
Then in your reporting rule you would use this syntax in your where clause:
where: net.src != 'private' || 'net.dst != private'
another way would be to create a custom feed to label traffic that way. Using a custom feed would be more efficient than using Application rules.
Tagging traffic from private IP with a meta seems to be a nice idea.
One thing I would like to know though, like in the condition you mentioned
"Condition: ip.src = 10.0.0.0/8 || ip.src = 172.16.0.0/12 || ip.src = 192.168.0.0/16"
Can't we use != instead of = and && instead of || in the above condition. Will this not work?
You could, but it would make the decoder work a lot harder,create much more meta to store (reducing your retention time windows) and could adversely affect packet capture, I.e dropping traffic.
It would need some extreme tuning!
Depends on what fw you are tapping of course, internet gateway or internal and the line rates.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
One of the best tricks I tend to use when looking at private versus public IPs is to use the org.dst or org.src keys in an anding rule on the decoders. Not only will this be able to tag public versus private IPs for use in rules, but it can also allow you to monitor directionality of traffic flows.
The MaxMind GEOIP integration built into SA/NetWitness natively adds the geoIP tags to each IP address. If it is a public IP, it is registered with ICANN. If it is private, it is not.
For instance, here are some use cases:
I want to monitor only outbound emails for attachments for potential data exfiltration.
service=25 && attachment exists && org.dst exists && org.dst !=my.domain
This means, Im looking at mail, with attachments, destined to a public IP range that is not owned by me.
Maybe I want to look at inbound only emails from external sources with attachments, perhaps to identify malicious attachments and exes used for spearphishing. My rule would be
service=25 && attachment exists && org.src exists && org.dst=my.domain
This will show only inbound emails with attachments that did not originate from a private IP sent to your organization
For your firewall rule above, when dealing with logs, I'm pretty sure the same logic would apply, and you would do it as an application rule, not as a correlation rule.
Lets say you want to detect port access attempts for a particular service coming inbound to your firewall, and you don't care about similar outbound activity-
service=2056 && org.src exists && device.id=my.device