Add initial automated tests for OSSEC and whitelist overloaded Tor guard log event

[redshiftzero]

Status

Ready for review

Description of Changes

Fixes #1670 and begins work towards #2134

Changes proposed in this pull request:

• 523447e - Adds initial example of automated testing for OSSEC rules based on log event in PR whitelisted grsec Denied RWX mmap #871
• dd40158 - Adds a failing test to reproduce spurious OSSEC alert described in ticket Filter out Tor Guard overloaded log event in OSSEC #1670
• 32b18ad - Adds an OSSEC rule to suppress the spurious email notification for the log event in ticket Filter out Tor Guard overloaded log event in OSSEC #1670 and thus makes the failing test added in dd40158 pass

(Happy to break this up into separate PRs to aid in review)

Testing

At minimum, verify the new tests run and pass in the CI staging environment.

If you want to be super thorough:

1. Provision staging on dd40158 and see that test_overloaded_tor_guard_does_not_produce_alert fails ("Alert to be generated" appears in the output of ossec-logtest)
2. Provision staging on 32b18ad and see that test_overloaded_tor_guard_does_not_produce_alert now passes ("Alert to be generated" does not appear in the output of ossec-logtest)

Deployment

This just updates the OSSEC rules, so there should be no issues in deployment.

Checklist

If you made changes to the system configuration:

• Configuration tests pass on app and mon

[conorsch]

Hmm, I would expect the RWX mmap of <anonymous mapping> by /usr/sbin/apache2 alert never to fire, given that we set kernel.grsecurity.rwxmap_logging=0 in the grsecurity role. @redshiftzero have you observed that particular event on staging machines?

[redshiftzero]

Hmm so this isn't apache2, but I see this event:

Aug 16 21:58:28 app-staging kernel: [ 7.847843] grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/landscape-sysinfo[landscape-sysin:279] uid/euid:0/0 gid/egid:0/0, parent /usr/share/landscape/landscape-sysinfo.wrapper[50-landscape-sy:269] uid/euid:0/0 gid/egid:0/0

in /var/log/syslog on app-staging provisioned today.

[conorsch]

Spinning up VMs to test out these changes.

[conorsch]

We have alerting tests! 😍 Thanks @redshiftzero!

I'll note now that we're definitely going to want to DRY out the alerting config tests by writing a reusable function (should technically be a fixture in pytest/testinfra nomenclature, but a helper function will work too), and reading in the alert metadata via the YAML testinfra vars files. Won't block merge for that, since we have several pending alert test PRs (e.g. #2143, #2152).

Will need to circle back on the dev docs anyway to explain the alert testing workflow, we can handle DRY cleanup then.

[conorsch]

If you want to be super thorough

I did and was. Confirmed that the new test failed on develop, but passed after reprovisioning staging machines with the code changes in this PR (via the rebuilt deb package).

[redshiftzero]

Nice, thanks for reviewing this @conorsch - I'm with you on DRYing up the alerting config tests and adding developer docs to explain that people should be writing regression tests for OSSEC rule changes (to address in a followup).