Slow dictionary probing

[sgtz...@googlemail.com]

Hi

I am seeing a type of dictionary probing that is defeating my current Ossec defences. This seems to be for two reasons (a) because the login attempts are repeated quite slowly (every few minutes instead of every few seconds) and (b) because they are cycling through different hosted domains on the server instead of focussing on just one.  Here is an example:

Jul  8 07:28:17 my-server auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain1.com rhost=***.***.***.**
Jul  8 07:31:21 my-server auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain2.com rhost=***.***.***.**
etc etc

So what I need is a rule on the lines of "multiple authentication failures with same IP and different user names" - which is definitely *bad* behaviour on our servers (whereas the same behaviour but only targeted at one user name might be a legitimate user with e.g. a poorly configured smartphone). But I can't for the life of me figure out how to create such a rule in Ossec! Any ideas?

Failing that, I thought I could use active response with Pam rule 5503 (for example) to save the IP address and user name to a log, then write a script to peep at that file to detect the footprint of 'same ip + mutiple user IDs' - and then I've caught my fish. The problem I'm having with that idea is that the standard decoder does not seem to capture 'ruser' but only 'user' in the logs. So the bad guy is not getting detected when she speculates about user IDs and guesses wrong.  I guess that means I need a custom decoder? What's the best way to do that in this case?

Thanks

Richard

[dan (ddp)]

On Fri, Jul 11, 2014 at 7:39 AM, <sgtz...@googlemail.com> wrote:
> Hi
>
> I am seeing a type of dictionary probing that is defeating my current Ossec
> defences. This seems to be for two reasons (a) because the login attempts
> are repeated quite slowly (every few minutes instead of every few seconds)
> and (b) because they are cycling through different hosted domains on the
> server instead of focussing on just one. Here is an example:
>
> Jul 8 07:28:17 my-server auth: pam_unix(dovecot:auth): authentication
> failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain1.com
> rhost=***.***.***.**
> Jul 8 07:31:21 my-server auth: pam_unix(dovecot:auth): authentication
> failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain2.com
> rhost=***.***.***.**
> etc etc
>
> So what I need is a rule on the lines of "multiple authentication failures
> with same IP and different user names" - which is definitely *bad* behaviour
> on our servers (whereas the same behaviour but only targeted at one user
> name might be a legitimate user with e.g. a poorly configured smartphone).
> But I can't for the life of me figure out how to create such a rule in
> Ossec! Any ideas?
>

Look at rule 5720 (although I'm not sure why it doesn't have a
frequency, is that even valid?). It won't detect the multiple user IDs
part, but is that really necessary if it can catch a single host
failing repeatedly?

> Failing that, I thought I could use active response with Pam rule 5503 (for
> example) to save the IP address and user name to a log, then write a script
> to peep at that file to detect the footprint of 'same ip + mutiple user IDs'
> - and then I've caught my fish. The problem I'm having with that idea is
> that the standard decoder does not seem to capture 'ruser' but only 'user'
> in the logs. So the bad guy is not getting detected when she speculates
> about user IDs and guesses wrong. I guess that means I need a custom
> decoder? What's the best way to do that in this case?
>

Not know what those logs decode as off hand, it's hard to tell.

> Thanks
>
> Richard
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sgtz...@googlemail.com]

Dan, you say "Look at rule 5720 (although I'm not sure why it doesn't have a frequency, is that even valid?). It won't detect the multiple user IDs part, but is that really necessary if it can catch a single host failing repeatedly?". That's an SSHD rule of course. The equivalent for Pam I think is rule 5551. 

 <rule id="5551" level="10" frequency="6" timeframe="180">
    <if_matched_sid>5503</if_matched_sid>
    <same_source_ip />
    <description>Multiple failed logins in a small period of time.</description>
    <group>authentication_failures,</group>
  </rule>

This has a timeframe, but 5720 does not (and the latter does have a frequency, no? "<rule id="5720" level="10" frequency="6">").

You ask, is it really necessary to detect multiple user IDs? I'd say yes, because I want to avoid false positives. We have several fine, upstanding clients on our servers with incorrectly configured devices that regular poll the server with an incorrect user name and/or password. They seem oblivious. But we don't want to ban them. So just overriding rule 5551 by abandoning the timeframe seems a poor solution. But repeated failures by the same IP with differing user IDs seems like a reliable signature for a bad guy.

[dan (ddp)]

On Jul 11, 2014 10:02 AM, <sgtz...@googlemail.com> wrote:
>
> Dan, you say "Look at rule 5720 (although I'm not sure why it doesn't have a frequency, is that even valid?). It won't detect the multiple user IDs part, but is that really necessary if it can catch a single host failing repeatedly?". That's an SSHD rule of course. The equivalent for Pam I think is rule 5551. 
>
>  <rule id="5551" level="10" frequency="6" timeframe="180">
>     <if_matched_sid>5503</if_matched_sid>
>     <same_source_ip />
>     <description>Multiple failed logins in a small period of time.</description>
>     <group>authentication_failures,</group>
>   </rule>
>
> This has a timeframe, but 5720 does not (and the latter does have a frequency, no? "<rule id="5720" level="10" frequency="6">").
>

I meant timeframe. Sorry, trying to do too many things at once.

> You ask, is it really necessary to detect multiple user IDs? I'd say yes, because I want to avoid false positives. We have several fine, upstanding clients on our servers with incorrectly configured devices that regular poll the server with an incorrect user name and/or password. They seem oblivious. But we don't want to ban them. So just overriding rule 5551 by abandoning the timeframe seems a poor solution. But repeated failures by the same IP with differing user IDs seems like a reliable signature for a bad guy.
>

If you ban the incorrectly configured systems they will have motivation to fix them.

[Michael Starks]

On 07/11/2014 09:02 AM, sgtz...@googlemail.com wrote:
> You ask,/is it really necessary to detect multiple user IDs?/ I'd say

> yes, because I want to avoid false positives. We have several fine,
> upstanding clients on our servers with incorrectly configured devices
> that regular poll the server with an incorrect user name and/or
> password. They seem oblivious. But we don't want to ban them. So just
> overriding rule 5551 by abandoning the timeframe seems a poor solution.
> But repeated failures by the same IP with differing user IDs seems like
> a reliable signature for a bad guy.

It sounds like what you're really looking for is a distinct option,
which OSSEC does not have. There may be some other creative way around
it like adding a username to a CDB list then doing a subsequent lookup,
but it's all going to have to be custom.

[sgtz...@googlemail.com]

> If you ban the incorrectly configured systems they will have motivation to fix them.

I'm afraid we don't see eye to eye on that Dan. I take the view that we shouldn't make the lives of the good guys harder because we can't (or are unwilling) to make our systems more fit for purpose in holding off the bad guys.

> I meant timeframe. Sorry, trying to do too many things at once.

Those poor folks with incorrectly configured systems (the good guys) are probably just like you and me: just trying to do too many things at once. 

[dan (ddp)]

On Jul 11, 2014 10:24 AM, <sgtz...@googlemail.com> wrote:
>
> > If you ban the incorrectly configured systems they will have motivation to fix them.
>
> I'm afraid we don't see eye to eye on that Dan. I take the view that we shouldn't make the lives of the good guys harder because we can't (or are unwilling) to make our systems more fit for purpose in holding off the bad guys.
>

If they're not willing to do their jobs, force them. :)

You can add the option to make this functionality possible. I'd encourage it being added. Someone else might want to sweep issues under the rug.

> > I meant timeframe. Sorry, trying to do too many things at once.
>
> Those poor folks with incorrectly configured systems (the good guys) are probably just like you and me: just trying to do too many things at once. 
>

[sgtz...@googlemail.com]

It sounds like what you're really looking for is a distinct option,
which OSSEC does not have. There may be some other creative way around
it like adding a username to a CDB list then doing a subsequent lookup,
but it's all going to have to be custom.

Thanks Michael. I thought it might have to be custom, but I thought I'd ask anyway! I think I can solve this if I can figure out a custom decoder to get the 'ruser', then get the events out to a custom log file and get a Perl script on a cron to peek at that and ban the offenders. Am new to decoders though.

[dan (ddp)]

I added this to decoders.xml before "pam-host":

<decoder name="pam-ruser">
<parent>pam</parent>
<prematch> ruser</prematch>
<regex offset="after_prematch">^=(\S+) </regex>
<order>user</order>
</decoder>

<decoder name="pam-ruser">
<parent>pam</parent>
<regex> rhost=(\S+)$</regex>
<order>srcip</order>
</decoder>


Please do some testing and report back.

[sgtz...@googlemail.com]

I added this to decoders.xml before "pam-host":

<decoder name="pam-ruser">
  <parent>pam</parent>
  <prematch> ruser</prematch>
  <regex offset="after_prematch">^=(\S+) </regex>
  <order>user</order>
</decoder>

<decoder name="pam-ruser">
  <parent>pam</parent>
  <regex> rhost=(\S+)$</regex>
  <order>srcip</order>
</decoder>

 

Please do some testing and report back.

Excellent. Many thanks Dan. I'll post back when I've had a chance to try it.  

[dan (ddp)]

That would be awesome. I'll do a pull request if it works as expected.
If it doesn't, please provide not-working log samples.

[Jeremy Rossi]

>I am seeing a type of dictionary probing that is defeating my current Ossec
>defences. This seems to be for two reasons (a) because the login attempts
>are repeated quite slowly (every few minutes instead of every few seconds)
>and (b) because they are cycling through different hosted domains on the
>server instead of focussing on just one. Here is an example:
>
>Jul 8 07:28:17 my-server auth: pam_unix(dovecot:auth): authentication
>failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain1.com
>rhost=***.***.***.**
>Jul 8 07:31:21 my-server auth: pam_unix(dovecot:auth): authentication
>failure; logname= uid=0 euid=0 tty=dovecot ruser=in...@mydomain2.com
>rhost=***.***.***.**
>etc etc

Other people have answered the question, but if can change the decoder
for dovecot to match dstuser as "info" and not match "@domain.com".
This way dstuser is not different for each requests.

This might not be the correct way but could help.

Also a little active-response and cdb make this problem go away ;)

-Jeremy Rossi

[sgtz...@googlemail.com]

<decoder name="pam-ruser">
  <parent>pam</parent>
  <prematch> ruser</prematch>
  <regex offset="after_prematch">^=(\S+) </regex>
  <order>user</order>
</decoder>

<decoder name="pam-ruser">
  <parent>pam</parent>
  <regex> rhost=(\S+)$</regex>
  <order>srcip</order>
</decoder>

Please do some testing and report back.

This works great Dan. Well apart from one little thing. I couldn't figure out why I was not getting the IP address. Then I noticed that there must be a whitespace character after the IP address in the log. This meant that rhost=(\S+)$ did not work. I have removed the '$' at the end and now it seems fine.

Many thanks.