2 weeks ago
Hello Netwitness community;
I would like to know which meta keys and condition to build a rule for (Max Traffic Received in bytes from Public IP Address to local systems).
Is this something can be achieved to identify Max Traffic Received?
@netwitnesseng @NetWitnessTeam @NWTeam
Appreciate your help on this.
Thanks
2 weeks ago
Are you attempting to alert or to perform a report on the top public talkers to your environment?
If you are just doing an Investigation then you can use ip.src (IP Source) as the meta key for seeing who all is talking to you. Then you can set the Quantify by Event Size to show a rough session size in KB for all the sessions being seen from a particular IP Source. What every is in the first position that is returned under this meta key is your top talker. You can then use queries to filter out internal IP Sources to then only see data coming from outside your organization.
2 weeks ago
Thanks for your support.
Actually we are trying to achieve this by creating a rule that will be used for a report and ESA rule.
The main challenge is how to show the max traffic received from outsource to internal.
Thanks
2 weeks ago - last edited 2 weeks ago
One way for creating reporting engine reports is to create several Application Rules that categorize session size. For instance all sessions that are size 1mb to 10mb would have an application rule names 1mb-10mb Session Size. Then the next application rule could be 11mb - 100mb, then 101mb - 500mb. By carving up the sessions like this you will be producing new meta with these application rule names on your sessions as they are detected by the decoder. Then using these new meta tags you can put them into a report to show the heavy talkers based on session packet size.
Here is a quick example of one of the application rules that would tag sessions whose sizes are between 1mb and 10mb in size.
Rule Name: SessionSize_1mb-10mb
Condition: size = 1000000 - 10000000
Session Options: Check 'Flag session with rule name in meta key' and select what meta key you want the rule name to appear if the session fits into the size as presented in the Condition.
As you can see the size meta is the size of the session in bytes. You can make as many of these application rule categories as you want. They will collect these sessions into size categories to allow you to see in a report what sessions that have ip.src from outside your company and generally how big they are. With that information you should then be able to use the same logic to set what you consider to be the threshold for "large" session in an ESA rule so that you can alert on them. For instance you may consider any sessions from outside to inside over 1GB is suspicious. You would then use the application rule carving names that you created to find any sessions that are over that threshold. For instance if all that matters is external sessions that are over say 1GB you could write just one rule like this.
Rule Name: Suspicious External Session
Condition: size = 1000000000 - u && ip.src != 10.1.0.0/16
Session Options: Flag session with rule name in meta key "whatever meta key works for you such as alert"
What this will do is flag any session that is over 1Gb, the - u means upper bound which is very similar to greater than or equal to in this context, and does not originate on the internal ip range of 10.1.0.0/16. You would need to adjust what would be the internal ip addresses but this should clearly produce the meta name Suspicious External Sessions on the alert meta key if the session size is over 1Gb and that it doesn't come from any internal ip address.
This page has some grammar rules for applications rules that you may need to help you out: https://community.netwitness.com/t5/netwitness-platform-online/configure-decoder-rules/ta-p/669145
Remember it is usually better to do this kind of thing at the decoder level as the session is being processed so later when you are doing reports and alerts the results return much quicker as the overall conditional statement should be much smaller and only on indexed meta keys. Like all things it is a matter of performance balancing when it comes to NetWitness.
I hope this helps.