[Rule Tuning] Potential SSH Brute Force Detected on Privileged Account

[willem-dhaese]

Link to rule

For some reason I cannot find it in https://www.elastic.co/guide/en/security/current/prebuilt-rules.html

I do find this => https://www.elastic.co/guide/en/security/current/prebuilt-rule-8-3-3-potential-ssh-brute-force-detected-on-privileged-account.html

Description

Most of our admin accounts have adm in them, but not admin. This makes this rule not applicable. Please consider update of admin to adm.

sequence by host.id, source.ip with maxspan=10s
  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
   event.outcome == "failure" and source.ip != null and source.ip != "0.0.0.0" and
   source.ip != "::" and  user.name : ("*root*" , "*admin*")] with runs=3

Update to:

sequence by host.id, source.ip with maxspan=10s
  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
   event.outcome == "failure" and source.ip != null and source.ip != "0.0.0.0" and
   source.ip != "::" and  user.name : ("*root*" , "*adm*")] with runs=3

[Aegrah]

@willem-dhaese I would like your take on this - do you feel like this rule does bring additional benefits to your organization in combination with the other brute force attack rules that we have for Linux? Because deprecating this one has been on my mind for a while.

I am fine with your suggestion; but not sure whether this rule specifically adds many benefits over the rest of our ruleset. WDYT?

[willem-dhaese]

@Aegrah Thanks for your answer. I did notice there seem quite a bit of SSH login related rules.

I guess there is room for consolidation and optimalization here.

As always, the question is how far will and can we go and how much noise are we willing to endure..

The thing is that the rule "Potential SSH Brute Force Detected on Privileged Account" works on auditbeat-* and the others only on logs-system.auth-*

"Potential Internal Linux SSH Brute Force Detected" would not have triggered, as we are not on Elastic Agent yet.

[willem-dhaese]

@Aegrah This rule has the same issue => https://www.elastic.co/guide/en/security/current/privileged-account-brute-force.html

We could also greatly benefit from changing user.name *admin* to *adm*.

Please let me know if this is something that Elastic is willing to change. If not, also good, then we will duplicate the rules and edit them ourselves.