Updating OSSEC Rules¶
SecureDrop uses the OSSEC open source host-based intrusion detection system (IDS) for log analysis, file integrity checking, policy monitoring, rootkit detection and real-time alerting. Refer to our OSSEC guide to learn more about how SecureDrop admins set up and monitor OSSEC alerts.
The goals of the OSSEC alerts in SecureDrop is to notify admins of:
- Suspicious security events
- Changes that require some kind of admin action
- Other important notifications regarding system state.
If an alert is purely informational and there is no realistic action an admin is expected to take, you should think carefully before suggesting a rule for it. Each additional alert that admins must read and/or respond to takes time. Alerts that are unimportant or otherwise require no action can lead to alert fatigue and thus to critical alerts being ignored.
Development on the OSSEC rules should be done from the staging environment.
mon-staging, there is a utility installed as part of OSSEC called
ossec-logtest that you can use to test log events. In order to evaluate
whether an alert will be produced, and if so, what rule triggered it and its
level, you can simply pass the event to
root@mon-staging:/home/vagrant# sudo echo "Feb 10 23:34:40 app-prod kernel: [ 124.188641] grsec: denied RWX mmap of <anonymous mapping> by /usr/sbin/apache2[apache2:1328] uid/euid:33/33 gid/egid:33/33, parent /usr/sbin/apache2[apache2:1309] uid/euid:0/0 gid/egid:0/0" | /var/ossec/bin/ossec-logtest 2017/08/16 22:28:25 ossec-testrule: INFO: Reading local decoder file. 2017/08/16 22:28:25 ossec-testrule: INFO: Started (pid: 18973). ossec-testrule: Type one log per line. **Phase 1: Completed pre-decoding. full event: 'Feb 10 23:34:40 app-prod kernel: [ 124.188641] grsec: denied RWX mmap of <anonymous mapping> by /usr/sbin/apache2[apache2:1328] uid/euid:33/33 gid/egid:33/33, parent /usr/sbin/apache2[apache2:1309] uid/euid:0/0 gid/egid:0/0' hostname: 'app-prod' program_name: 'kernel' log: '[ 124.188641] grsec: denied RWX mmap of <anonymous mapping> by /usr/sbin/apache2[apache2:1328] uid/euid:33/33 gid/egid:33/33, parent /usr/sbin/apache2[apache2:1309] uid/euid:0/0 gid/egid:0/0' **Phase 2: Completed decoding. decoder: 'iptables' **Phase 3: Completed filtering (rules). Rule id: '100101' Level: '7' Description: 'grsec error was detected' **Alert to be generated.
This is the utility we use in automated tests of OSSEC.
Writing Automated Tests for OSSEC Rules¶
We strongly recommend before making changes to OSSEC rules to attempt to write a failing test which you then can make pass with a patch to the OSSEC rules:
- Identify a log event you can use to trigger the alert.
Be sure to use only log events from test SecureDrop instances or those you have verified do not contain any sensitive data.
- Write a Testinfra test to verify that the log event does or does not trigger an alert.
- Apply your patch to the OSSEC rule on the relevant VM (likely
- Restart the service via
sudo service ossec restarton
The OSSEC rules and associated configuration files are distributed via Debian packages maintained by Freedom of the Press Foundation. Any changes made to OSSEC configuration files will land on production SecureDrop monitoring servers as part of each SecureDrop release. This upgrade will occur automatically.
The use of automatic upgrades for release deployment means that any changes made locally by admins to their OSSEC rules will not persist after a SecureDrop update.