OSSEC sending daily login reports, even if a user hasn't logged in #6748
Assignees
Milestone
Comments
nathandyer
changed the title
|
It would be worth checking to see if #6705 fixes this, I don't remember if systemd timers trigger the same pam line about a session being opened. Of course the simpler fix would be to adjust the OSSEC rule. |
|
It probably would - |
legoktm
added a commit
that referenced
this issue
Apr 12, 2023
systemd timers are easier to define and offer more flexibility in running commands. For example, 9169606 would've been a 2 line change instead of a complex and fragile bash migration. We clear the old crontabs and enable the timers in d/postinst for now. Once we migrate to dh_installsystemd, we can let debhelper take care of activating the timers (dh_systemd_enable will enable both the timer and service units, which we don't want). Fixes #6705. Fixes #6748.
legoktm
added a commit
that referenced
this issue
Apr 12, 2023
systemd timers are easier to define and offer more flexibility in running commands. For example, 9169606 would've been a 2 line change instead of a complex and fragile bash migration. We clear the old crontabs in the postinst and let debhelper enable the timers. Turns out uur usage of `dh_systemd_enable` and `dh_systemd_start` was wrong, because we were calling it multiple times without specifying explicit unit files, it was adding the same stanza to the postinst/postrm multiple times. We now invoke it explicitly for each unit we want enabled/started. Hopefully when we switch to compat 12/dh_installsystemd we don't need to manually list each one. Fixes #6705. Fixes #6748.
legoktm
added a commit
that referenced
this issue
Apr 12, 2023
systemd timers are easier to define and offer more flexibility in running commands. For example, 9169606 would've been a 2 line change instead of a complex and fragile bash migration. We clear the old crontabs in the postinst and let debhelper enable the timers. Turns out our usage of `dh_systemd_enable` and `dh_systemd_start` was wrong, because we were calling it multiple times without specifying explicit unit files, it was adding the same stanza to the postinst/postrm multiple times. We now invoke it explicitly for each unit we want enabled/started. Hopefully when we switch to compat 12/dh_installsystemd we don't need to manually list each one. Fixes #6705. Fixes #6748.
cfm
pushed a commit
that referenced
this issue
May 24, 2023
systemd timers are easier to define and offer more flexibility in running commands. For example, 9169606 would've been a 2 line change instead of a complex and fragile bash migration. We clear the old crontabs in the postinst and let debhelper enable the timers. Turns out our usage of `dh_systemd_enable` and `dh_systemd_start` was wrong, because we were calling it multiple times without specifying explicit unit files, it was adding the same stanza to the postinst/postrm multiple times. We now invoke it explicitly for each unit we want enabled/started. Hopefully when we switch to compat 12/dh_installsystemd we don't need to manually list each one. Fixes #6705. Fixes #6748.
legoktm
added a commit
that referenced
this issue
May 25, 2023
systemd timers are easier to define and offer more flexibility in running commands. For example, 9169606 would've been a 2 line change instead of a complex and fragile bash migration. We clear the old crontabs in the postinst and let debhelper enable the timers. Turns out our usage of `dh_systemd_enable` and `dh_systemd_start` was wrong, because we were calling it multiple times without specifying explicit unit files, it was adding the same stanza to the postinst/postrm multiple times. We now invoke it explicitly for each unit we want enabled/started. Hopefully when we switch to compat 12/dh_installsystemd we don't need to manually list each one. Fixes #6705. Fixes #6748.
github-project-automation
bot
moved this from Cycle Backlog
to Done
in SecureDrop dev cycle
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Ever since the 2.5.1 release, OSSEC sends a daily email showing either one or two logins on the app server. After investigation, it appears that this is happening as a result of changes made in this commit which changes it so that OSSEC checks run as as the
www-datauser.Because it now sends out these false alarms, the daily login report is less useful as a monitoring tool.
Steps to Reproduce
This behavior happens automatically once per day, as long as the server is running and OSSEC alerts are set up correctly.
You can see where this happens by inspecting
/var/log/auth.log. A line will appear, containing:followed by:
Expected Behavior
A daily login report is only sent in the event of an actual login by an end-user.
The text was updated successfully, but these errors were encountered: