My 2 cents:
1) I got tripped up by the fact that the default alert level to trigger an
active response is 6, while the default alert level to trigger an email is
7. There were a number of times when communication between 2 internal hosts
on my network suddenly stopped working, then mysteriously started working
again - and it wasn't at all obvious that OSSEC was the culprit. I dealt
with this by monitoring active-responses.log on both agents and server, and
then creating local rules that alert_by_email whenever rules 601-606 hit.
2) There are a lot of SSH rules at level 6 that make it really easy to
trigger an active response. E.g. with the default configuration, rule 5706
will trigger a block if a single invalid connection to port 22 is made
(such as a telnet or port map). While you could certainly argue that this
is impolite, there are in fact a lot of monitoring and other tools that do
something similar in order to see if the port is listening without actually
trying to make an SSH connection - so blocking after one attempt is way too
aggressive for us. I dealt with this by reducing the alert level on a
bunch of these rules, and adding a frequency/timeframe requirement which
triggers an email but no active-response (since the level is still < 6):
<!-- reduce alert level from 6 to 1 on SSH scans so that active-response
won't trigger,
but send email alert (via rule 100014) after 10 hits 5 minutes (yes,
8=10 in this case) -->
<rule id="100012" level="1">
<if_sid>5706,5713,5731,5747,5748</if_sid>
<description>Malformed SSH connection attempt</description>
</rule>
<rule id="100014" level="1" frequency="8" timeframe="300">
<if_matched_sid>100012</if_matched_sid>
<options>alert_by_email</options>
<description>Potential SSH scan, possible attack</description>
</rule>
So, I've worked around it - but the default behavior did seem non-intuitive
and overly aggressive to me. FWIW, I'm in a corporate environment; I
imagine if you had SSH exposed to the internet and you were getting scanned
all the time, the current defaults (block with extreme prejudice and don't
bother to tell me about it) would make more sense.
Christina
On Fri, Nov 18, 2016 at 10:06 AM, Whit Blauvelt <[email protected]> wrote:
> Hi Dan,
>
> Since I skipped answering this:
>
> On Mon, Nov 14, 2016 at 11:09:52AM -0500, dan (ddp) wrote:
>
> > > Except in a context of anon FTP servers (does anyone run those any
> more?)
> > > blocking IPs because they connect using valid logins "too often" is a
> > > dangerous default. "First, do no harm."
> >
> > Creating perfect defaults for every environment is nearly impossible.
> > Niche and odd-ball usage patterns can cause issues.
> >
> > Which rule was triggering the alerts? Maybe it's time for a tweak.
>
> 11301 in pure-ftpd_rules (not to be confused with 11302 for multiple failed
> logins).
>
> Whit
>
> --
>
> ---
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
