Can anyone explain what constitutes "Suspicious or Unusual Traffic" in the LEM? What causes a positive hit?
Thanks,
-Mar
Can anyone explain what constitutes "Suspicious or Unusual Traffic" in the LEM? What causes a positive hit?
Thanks,
-Mar
The "unusual" alerts (Unusual Traffic, UnusualIPTraffic, UnusualProtocol, UnusualICMPTraffic, UnusualTCPTraffic, UnusualUDPTraffic), in my environment, are almost always inferred alerts. Inferred alerts are generated by rules in response to some condition configured in that rule. For example, if you look at the Default Rules container, you will see rules such as "TCPTrafficAudit Missing SYN Bit with possible Inference". If enabled, that rule will write an UnusualTCPTraffic alert to the database each time the configured Correlations and Correlation time parameters are true. Other rules behave the same way, so there isn't one definition of what an UnusualTCPTraffic alert is. It depends on the InferenceRule that originated it. There is a field labeled "InferenceRule" in each inferred alert that should help you trace it back.
"Suspicious" alerts (of which "Unusual" are a subcategory) are a much broader category. Many of the definitions can be found in the alert types section of the user guide. Sometimes they're vague, but there may be enough information for you to get an idea of what the underlying logic is.
I think one of the things I struggle with in LEM is the inability to see what the actual definitions for the alerts are. I am one of those people that needs to fully understand what I am working with and in this case it just isn't possible. You can certainly go into the policy section of the appliance and see some of the explanations of what the different alert categories are but that still doesn't provide a clean understanding of what would hit or qualify as that alert.
Generally, when they aren't generated by inferred alerts/rules, they are generated by devices that have a little more insight into the network and what's "normal", like a firewall or more commonly IPS/IDS. The "Suspicious" ones are not conclusively bad, while the "Attack" stuff tends to be fired from the firewall/IPS/et al as a match to something that we assume they already know IS bad.
There's two elements to the secret decoder ring here - the connectors, which normalize data (categorize and parse into fields), then the alert taxonomy itself.
We've heard this is a really common topic where people get "stuck" with LEM. If we were to cover it in a blog post, video, or other medium, what questions would be most useful to answer?
I think the alert taxonomy is the piece that is the most confusing and often the invisible part of the process, it wasn't until weeks after using the product and a call to support before I was even aware the policies were there (I admittedly am one of the people that will read the manual only as a last resort). Correct me if I am but isn't the taxonomy the Policies part?
The connectors I completely understand, those are basically templates on how to collect and and normalize (parse) the logs.
I often also think that the way LEM defines an alert can be confusing at times but I think that ultimately goes back to the taxonomy since those seem to be the "containers" that are the alerts. When you go into the Policies they have explanations as to what they mean; however, technical folks like myself are often trying to understand exactly what it would capture.
Not sure if this helped or not, was basically me thinking out loud about the issue.
Nicole,
Did someone follow through with this "We've heard this is a really common topic where people get "stuck" with LEM. If we were to cover it in a blog post, video, or other medium, what questions would be most useful to answer?"
Was a blog post, video, or other medium created to help people get un-"stuck" with LEM?
T.J.
I know that in the new version (6.1) these rules will no longer be enabled by default, but I did make a chart of the ones tat are enabled by default in 6.0.1 and previous. I'm sharing it here, in case it helps at least explain some of the noise that LEM makes out of the box.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.