On Fri, Nov 18, 2016 at 6:00 PM, Christina Plummer <[email protected]> wrote: > 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. >
That makes sense. https://github.com/ossec/ossec-hids/pull/991 > 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. -- --- 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.
