Hello folks,
slightly related with my previous post, and with experience seen from customer systems (whole system not rebooted for many of days, possibly even for years to ensure its work / compatibility), wondering if the agencies focused on computer security have a recommendation / requirement underlying system reboots to be scheduled on regular basis (like once per month).
As already mentioned, on one hand there can be often seen scenarios when customer(s) don't reboot the system due the fear of breaking the functionality / compatibility. Such behaviour on the other hand obviously means, that for example fixes for selected security flaws (mainly in the kernel) can't be applied completely / correctly, leaving the system in question still vulnerable to particular attack.
Therefore was thinking if we would want to introduce XCCDF rule / recommendation requiring the system to be rebooted on regular basis (like once per month looks reasonable, but opened for proposals), to ensure this (kernel still being vulnerable) wouldn't happen.
Besides that (I think) even when the reboot should result into system not being bootable, it's better to find it immediately, than after period like ~3 years (many of fixes applied at once => harder to find out which concrete one actually caused the failure to boot).
The corresponding OVAL check could see if there exists particular crontab entry scheduling reboot once per month (and fail if not). The fix then would be to add such crontab entry (possibly including "wall" notification with some delay prior actually performing the reboot).
Opinions appreciated.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
----- Original Message -----
From: "Jan Lieskovsky" jlieskov@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, December 17, 2013 11:47:39 AM Subject: Worthy to add XCCDF rule to ensure regular system reboots?
Hello folks,
slightly related with my previous post, and with experience seen from customer systems (whole system not rebooted for many of days, possibly even for years to ensure its work / compatibility), wondering if the agencies focused on computer security have a recommendation / requirement underlying system reboots to be scheduled on regular basis (like once per month).
As already mentioned, on one hand there can be often seen scenarios when customer(s) don't reboot the system due the fear of breaking the functionality / compatibility. Such behaviour on the other hand obviously means, that for example fixes for selected security flaws (mainly in the kernel) can't be applied completely / correctly, leaving the system in question still vulnerable to particular attack.
Therefore was thinking if we would want to introduce XCCDF rule / recommendation requiring the system to be rebooted on regular basis (like once per month looks reasonable, but opened for proposals),
Looked more: [1] http://www.unix.com/solaris/34784-reboot-unix-servers-recommended.html
and looks once per month might be too strict. But what about to recommend for automated reboot once per 90-120 days like written there?
Thanks, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
to ensure this (kernel still being vulnerable) wouldn't happen.
Besides that (I think) even when the reboot should result into system not being bootable, it's better to find it immediately, than after period like ~3 years (many of fixes applied at once => harder to find out which concrete one actually caused the failure to boot).
The corresponding OVAL check could see if there exists particular crontab entry scheduling reboot once per month (and fail if not). The fix then would be to add such crontab entry (possibly including "wall" notification with some delay prior actually performing the reboot).
Opinions appreciated.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Tuesday, December 17, 2013 05:47:39 AM Jan Lieskovsky wrote:
slightly related with my previous post, and with experience seen from customer systems (whole system not rebooted for many of days, possibly even for years to ensure its work / compatibility), wondering if the agencies focused on computer security have a recommendation / requirement underlying system reboots to be scheduled on regular basis (like once per month).
As already mentioned, on one hand there can be often seen scenarios when customer(s) don't reboot the system due the fear of breaking the functionality / compatibility. Such behaviour on the other hand obviously means, that for example fixes for selected security flaws (mainly in the kernel) can't be applied completely / correctly, leaving the system in question still vulnerable to particular attack.
This is a site specific issue and can't be generalized. For example, rebooting a machine hosting VM on QEMU could potentially take down 15 - 20 systems at once. They would need to migrate the VMs to other systems and then reboot. You can also have the same issues for DNS or database servers. Rebooting them can cause many unrelated systems to have failures during the time it takes to reboot.
Then, what it it doesn't come back up? I've seen systems that just needed a reboot and the server never comes back up...ever....needed new memory because memory problems corrupted the update on disk.
Therefore was thinking if we would want to introduce XCCDF rule / recommendation requiring the system to be rebooted on regular basis (like once per month looks reasonable, but opened for proposals), to ensure this (kernel still being vulnerable) wouldn't happen.
I'd say it would be fine to detect files in use that are deleted because of an update just to call attention. But to _require_ a reboot on any kind of schedule is going to be tailored/disabled immediately.
Besides that (I think) even when the reboot should result into system not being bootable, it's better to find it immediately, than after period like ~3 years (many of fixes applied at once => harder to find out which concrete one actually caused the failure to boot).
I'd say a lot of people would rather have uptime and just restart critical services as long as possible.
The corresponding OVAL check could see if there exists particular crontab entry scheduling reboot once per month (and fail if not). The fix then would be to add such crontab entry (possibly including "wall" notification with some delay prior actually performing the reboot).
I hope no one adds something in crontab to reboot. :-)
-Steve
scap-security-guide@lists.fedorahosted.org