Regression: OSSEC sending daily login reports, even if a user hasn't logged in

[nathandyer]

Description

I'm unsure if the underlying cause is the same as with issue #6748, but there appears to be a regression that has been in place since the release of SecureDrop 2.6.0.

It appears that OSSEC is sending a daily login report, even in instances when a user hasn't directly logged in. As a result, these alerts are not as effective as a monitoring tool.

Expected Behavior

A daily login report is only sent if someone logs into a SecureDrop server.

Actual Behavior

A daily login report is sent every day, even if a human has not logged into a SecureDrop server.

[cfm]

Logs from my QA instance

** Alert 1696910452.8858: mail  - Ossec daily notifications
2023 Oct 10 04:00:52 (app) 10.20.2.2->head -1 /var/lib/securedrop/submissions_today.txt | grep '^[0-9]*$'
Rule: 400600 (level 1) -> 'Boolean value indicating if there were submissions in the past 24h.'
ossec: output: 'head -1 /var/lib/securedrop/submissions_today.txt | grep '^[0-9]*$'':
0

** Alert 1696910452.9209: mail  - sd_data_problems
2023 Oct 10 04:00:52 (app) 10.20.2.2->sudo -u www-data /opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py check-disconnected-fs-submissions
Rule: 400801 (level 1) -> 'Indicates that there are files in the submission area without corresponding submissions in the database.'
ossec: output: 'sudo -u www-data /opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py check-disconnected-fs-submissions': There are files in the submission area with no corresponding records in the database. Run "manage.py list-disconnected-fs-submissions" for details.

** Alert 1696910452.9846: - pam,syslog,authentication_success,
2023 Oct 10 04:00:52 (app) 10.20.2.2->/var/log/auth.log
Rule: 5501 (level 3) -> 'Login session opened.'
Oct 10 04:00:38 app sudo: pam_unix(sudo:session): session opened for user www-data by (uid=0)

** Alert 1696910452.10108: - pam,syslog,
2023 Oct 10 04:00:52 (app) 10.20.2.2->/var/log/auth.log
Rule: 5502 (level 3) -> 'Login session closed.'
Oct 10 04:00:38 app sudo: pam_unix(sudo:session): session closed for user www-data

#6780 got rid of sudo invocations by switching from cron jobs to systemd timers, but we still have...

securedrop/securedrop/debian/ossec-agent/var/ossec/etc/ossec.conf

Lines 129 to 139 in d431061

	<localfile>
	<log_format>command</log_format>
	<command>sudo -u www-data /opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py check-disconnected-db-submissions</command>
	<frequency>90000</frequency>
	</localfile>
	<localfile>
	<log_format>command</log_format>
	<command>sudo -u www-data /opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py check-disconnected-fs-submissions</command>
	<frequency>90000</frequency>
	</localfile>

I was initially puzzled by the chronology between #6704 and #6780, but I see now that the latter didn't contain an explicit test case for #6748.

Now that these syscheck calls require sudo, I am skeptical that we can mask alerts for them without creating the risk of masking malicious sudos too.

[cfm]

...unless we mask only those alerts for exactly these command strings, which are safe and have no side effects?

[legoktm]

We could have those scripts run as systemd timers on the app server and do the same head/grep thing that submissions_today.txt does? Or flag on some line they print?

[cfm]

If I have time this afternoon, I'll throw in a local_rules.xml addition on my QA instance in order see if that threads the needle first.

[cfm]

I don't think OSSEC is up to this, because it would require correlating (in the following example) line 1 with each of lines 2 and 3, rather than processing each individually:

Oct  8 04:00:36 app sudo:     root : TTY=unknown ; PWD=/ ; USER=www-data ; COMMAND=/opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py check-disconnected-fs-submissions
Oct  8 04:00:36 app sudo: pam_unix(sudo:session): session opened for user www-data by (uid=0)
Oct  8 04:00:37 app sudo: pam_unix(sudo:session): session closed for user www-data

We don't even have an ID to accumulate on.

In theory we could do something clever with PAM to suppress lines (2) and (3) altogether. But I can't justify such a low-level intervention for such a high-level (anti-)observability wish.

So, reluctantly, I think you may be right to suggest adding a level of indirection to these script invocations so that OSSEC never sudos at all.

[cfm]

As of 8d648fc I have new systemd units in place:

root@app:/lib/systemd/system# systemctl start securedrop-check-disconnected-db-submissions.service
root@app:/lib/systemd/system# systemctl start securedrop-check-disconnected-fs-submissions.service
root@app:/lib/systemd/system# ls -al /var/lib/securedrop/*.txt
-rw-r--r-- 1 www-data www-data  60 Oct 13 01:23 /var/lib/securedrop/disconnected_db_submissions.txt
-rw-r--r-- 1 www-data www-data 148 Oct 13 01:24 /var/lib/securedrop/disconnected_fs_submissions.txt
-rw-r--r-- 1 www-data www-data   1 Oct 12 03:01 /var/lib/securedrop/submissions_today.txt
root@app:/lib/systemd/system# cat /var/lib/securedrop/*.txt
No problems were found. All submissions' files are present.
There are files in the submission area with no corresponding records in the database. Run "manage.py list-disconnected-fs-submissions" for details.

The OSSEC changes are there, too, but I've missed today's "Daily Reports" timer on this instance, so I won't be able to see what it looks like until tomorrow's. I can pick this back up on Monday, or tomorrow someone can test directly in staging.

[cfm]

This appears to work as expected on my long-running QA instance with disconnected submissions.

Before installing a package with this change

8620  PF Oct 07 To cory+sea1@fr (1.2K) Daily report: Successful logins
8621  PF Oct 07 To cory+sea1@fr (1.3K) OSSEC Notification - (app) - Alert level 1
> ossec: output: 'sudo -u www-data /opt/venvs/securedrop-app-code/bin/python3 /var/www/securedrop/manage.py
check-disconnected-fs-submissions': There are files in the submission area with no corresponding records in the
database. Run "manage.py list-disconnected-fs-submissions" for details.
8622  PF Oct 07 To cory+sea1@fr (1.0K) Submissions in the past 24h

After installing a package with this change

 148  PF Oct 16 To cory+sea1@fr (1.3K) OSSEC Notification - (app) - Alert level 1
> ossec: output: 'cat /var/lib/securedrop/disconnected_fs_submissions.txt': There are files in the submission area with
no corresponding records in the database. Run "manage.py list-disconnected-fs-submissions" for details.
 149  PF Oct 16 To cory+sea1@fr (1.0K) Submissions in the past 24h

Pull request forthcoming.