3 Replies Latest reply on May 26, 2015 2:43 PM by jefflby

    Repeated Attack - Multiple Detection Sources


      I have a request for the following rule to be made:


      Repeat Attack-Multiple Detection Sources

      Goal: Find hosts that may be infected or compromised detected by multiple sources (high

      probability of true threat).

      Trigger: Alert on ANY second threat type detected from a single IP Address by a second source

      after seeing a repeat attack. (i.e. Repeat Firewall Drop, followed by Virus Detected)


      Ignoring the obvious issues with how generalized this request is (i.e., what kind of events are determined to be primary and secondary attacks? how many constitutes "repeated"?, etc.), we are trying to at least get a starting point to the setup based on the last line of the request (Firewall drops + Virus detected)


      We are currently waiting on a connector to be made for our virus detection. Therefore, there are NO virus events possible in LEM (at this time). However, when I enable the following rule, we got close to 100 emails in about 4 minutes. Can anyone give some insight into the logic (or lack thereof) for the correlation set below?


      mult-src rule.jpg


      For reference, here is a similar search in nDepth over the time period we got all of the emails during:


      mult-src ndepth.jpg


      I am assuming that there is something off in either the correlation thresholds, or the correlation time.

      Also, for the TCPTrafficAudit events, there is an advanced threshold for the TCPTrafficAudit.SourceMachine field to be the same. (re-infer is disabled)


      As always, all help is appreciated!

        • Re: Repeated Attack - Multiple Detection Sources

          I have the same question/issue. The Correlation Time box needs better explanation. Alerts Within is very obvious. The Response Window however is what mystifies me. Re-Inference Time is rather vague and google is not much help.

            • Re: Repeated Attack - Multiple Detection Sources

              Okay! Correlation box 101:


              2015-05-26 09_04_50-SolarWinds Log & Event Manager.png


              The "X events in Y" is easy: the LEM will wait for the correlation conditions to be "TRUE" X times in Y time frame before firing.


              Response Window is "If the events are more than Z time from the present, then don't bother to take the actions."  So, you have a network segment get disconnected.  Workstations and servers on the far side are throwing errors because of this.  It takes you 12 hours to get your ISP to fix things.  The LEM agents on the far side of the break were logging events and caching them for 12 hours, and once the connection is restored, they start sending all of that information to the LEM.  Maybe in those 12 hours you had a million events that would usually result in an e-mail, but because your response window is 5 or 10 minutes, the LEM doesn't DOS your Exchange server.


              If the "X" events is greater than 1, you can get at the advanced correlation options with this gear:


              2015-05-26 09_08_55-SolarWinds Log & Event Manager.png


              This opens the Advanced Thresholds window:


              2015-05-26 09_42_43-SolarWinds Log & Event Manager.png


              Here you can set things like "I need 10 events, but the source IP needs to be the same on all 10 and the destination port needs to be different on all 10."  You can also play with the "Re-Infer (TOT)" options.  This is where we get into "Correlation Box 201."


              TOT stands for "Time Over Threshold."  Your threshold is the X events in Y seconds.  So, say that you have a rule looking for pings, and will trigger if it gets 10 in 30 seconds.  Some source starts pinging your network once a second.


              Second 1: LEM sees 1 ping

              Second 2: LEM sees 2 pings


              Second 10: LEM sees 10 pings - RULE FIRES!

              Second 11: LEM sees 11 pings

              Second 12: LEM sees 12 pings


              Second 30: LEM sees 30 pings

              Second 31: LEM sees 31 pings


              At no point do the pings let up, so we're "Over Threshold" and the rule doesn't re-fire.  The Re-Infer (TOT) setting says, "If you're still over threshold X time later, FIRE THE RULE AGAIN!"


              I hope that helps.

              1 of 1 people found this helpful
            • Re: Repeated Attack - Multiple Detection Sources

              This is perfect! I wish it had been in the documentation. It makes perfect sense of a complex but necessary set of logic.