OSSEC Rules: Remove syscheck alert when bulk tmp file deleted

[redshiftzero]

Status

Ready for review

Description of Changes

Fixes #1691.

Changes proposed in this pull request:

• When bulk downloads occur on the SecureDrop journalist interface,
  a temporary file is created in /var/lib/securedrop/tmp. When
  this file is cleaned up, an integrity checking alert fires.
  If SecureDrop is getting heavy use, this alert can fire many times per
  day.

• This commit modifies the syscheck options on the app server
  to exclude any files named tmp_securedrop_bulk_* in
  /var/lib/securedrop/tmp from the integrity checking.

Testing

Note: In the testing instructions that follow, I'm indicating the hostname via the string prior to the shell prompt.

A. Reproduce the alert

1. Provision staging locally.

2. Create test file:

   app-staging# echo "test" > /var/lib/securedrop/tmp/tmp_securedrop_bulk_dl_FDkPe4

3. Establish syscheck baseline:

   mon-staging# /var/ossec/bin/agent_control -r -a

4. Remove test file:

   app-staging# rm /var/lib/securedrop/tmp/tmp_securedrop_bulk_dl_FDkPe4

5. Watch the OSSEC alerts log (or watch your email if you have prod-like secrets configured in site-specific):

   mon-staging# tail -f /var/ossec/logs/alerts/alerts.log

6. And now syscheck again to rerun integrity checking:

   mon-staging# /var/ossec/bin/agent_control -r -a

7. An alert will appear in /var/ossec/logs/alerts/alerts.log:

** Alert 1503096612.240301: mail  - ossec,syscheck,
2017 Aug 18 22:50:12 (app-staging) 10.0.1.2->syscheck
Rule: 553 (level 7) -> 'File deleted. Unable to retrieve checksum.'
File '/var/lib/securedrop/tmp/tmp_securedrop_bulk_dl_FDkPe4' was deleted. Unable to retrieve checksum.

B. Verify the fix in this PR

1. The patch is in ossec.conf on the agent (the Application server), so you can either:

   a. reprovision staging with the patch applied, or

   b. you can just manually apply the patch to /var/ossec/etc/ossec.conf on mon-staging. Note that you will then need to bounce the service (i.e. mon-staging# service ossec restart).

2. Follow steps 2-5 from section A above, except now no alert will fire.

Deployment

As ossec.conf is delivered via the securedrop-ossec-agent deb package, the change should be deployed without issue.

Checklist

If you made changes to the system configuration:

• Configuration tests pass

[conorsch]

@redshiftzero Kindly rebase for me, now that #2143 is merged? There aren't any conflicts, but coverage checks are failing, due to develop being out of sync.

[redshiftzero]

Rebased!

[conorsch]

Testing now, starting with reproducing the alerts on current develop.

[conorsch]

After copious manual testing, I've failed to reproduce the original alert in staging VMs. The testing steps provided in the PR submission failed to generate the original alert, and manual interaction with the webserver (to generate tmp files via bulk downloads) failed to do so as well. Was provisioned on latest develop.

Going to step away from this PR and circle back, in case I'm missing something obvious. My best guest at present is that I'm not waiting nearly long enough before and after running /var/ossec/bin/agent_control -r -a, which returns suspiciously quickly.

[redshiftzero]

Ah my bad @conorsh - you're probably right that syscheck is not completing, when I composed these instructions enough time likely elapsed between steps that I did not hit that issue.

FYI to determine if syscheck is finishing one can monitor the syscheck datastore for changes in /var/ossec/queue/syscheck/(app-staging) 10.0.1.2->syscheck on mon-staging (there may be an easier way, but I'm not aware of it). I can circle back on this PR later and run through the testing again to double check if you don't get to it first.

[conorsch]

Thanks for confirmation, @redshiftzero. Tackling this again now, and will be more patient between commands. Will try to get a rough estimate of what a full refresh of the system integrity checks (on VMs) clocks in at, and report back.

[conorsch]

Ahh, finally making progress. One can check when syscheck last ran via /var/ossec/bin/agent_control -i <host_id>. Explicitly:

root@mon-staging:~# /var/ossec/bin/agent_control -lc

OSSEC HIDS agent_control. List of available agents:
   ID: 000, Name: mon-staging (server), IP: 127.0.0.1, Active/Local
   ID: 1024, Name: app-staging, IP: 10.0.1.2, Active

root@mon-staging:~# /var/ossec/bin/agent_control -i 1024

OSSEC HIDS agent_control. Agent information:
   Agent ID:   1024
   Agent Name: app-staging
   IP address: 10.0.1.2
   Status:     Active

   Operating system:    Linux app-staging 3.14.79-grsec #1 SMP Wed Jun 21 19..
   Client version:      OSSEC HIDS v2.8
   Last keep alive:     Fri Aug 25 18:46:31 2017

   Syscheck last started  at: Fri Aug 25 18:31:17 2017
   Rootcheck last started at: Fri Aug 25 18:39:53 2017
root@mon-staging:~# /var/ossec/bin/agent_control -i 1024

OSSEC HIDS agent_control. Agent information:
   Agent ID:   1024
   Agent Name: app-staging
   IP address: 10.0.1.2
   Status:     Active

   Operating system:    Linux app-staging 3.14.79-grsec #1 SMP Wed Jun 21 19..
   Client version:      OSSEC HIDS v2.8
   Last keep alive:     Fri Aug 25 18:56:31 2017

   Syscheck last started  at: Fri Aug 25 18:50:26 2017
   Rootcheck last started at: Fri Aug 25 18:39:53 2017

Have now reproduced the original alert we're trying to silence, so proceeding with testing the patch in this PR.

[conorsch]

Finally able to confirm the changes in this PR behave as intended, and alerts are no longer fired when tmp files are removed as a result of bulk downloads. Thanks, @redshiftzero!

I did notice the alert being triggered after switching to this PR branch (from develop) and rebuilding and reinstalling the deb packages. That strikes me as odd, since the deb packages should appropriately bounce the services. After a reboot of the staging machines, however, the feature behaved as advertised, and prod updates involve a reboot as well, so I'm satisfied.

[conorsch]

After copious manual testing, I can confirm that @redshiftzero was spot-on with these changes. Should go a long way in cutting down on alert noise. Let's get it in!