I test each system, after patching, for the existence of /var/run/reboot-required.
If that file doesn't exist, I don't reboot. Been doing this for decades, including 22.04 release (ubuntu and Mint). If something changed after that, it is news to me.
It works on some Debian releases too ... or I'd never reboot my email gateway servers either.
As for needing to reboot all the time, I have this to say.
Do you patch more than once a week? Why? If a bad patch comes through and you are patching multiple times a day, your system might see 3 different versions and claim a reboot is needed 3 times. I've been patching weekly (usually Sat mornings), so at most, I'll reboot once a week, if that. Often, I'll patch on Saturday, but not reboot, if a reboot is needed, until Sunday.
Code:
$ uptime
06:37:45 up 2 days, 22:00, 5 users,
For a desktop, I can't imagine why people would patch more than once a week.
For a server, it is important to watch the bug reports for critical fixes that relate to your specific software. My servers run all sorts of public services and sometimes those have critical issues that actually impact security. That hardly ever actually happens. Sure, there are critical issues, but the specific nature of the problem isn't something my server(s) use, so it can wait.
In the last 15 yrs, I've needed to patch mid-week less than 5 times and only 1 of the servers was impacted by those critical fixes. Part of that mitigation is that I don't run php webapps on the public internet and we don't use wordpress or drupal or other often-hacked CMS.
Additionally, our security is setup in layers to prevent bad inputs from ever getting to our webapps. So, if there is a bug in a webapp we use, it is likely some special POST/GET request is needed to begin the attack, often through an administration page. Those are blocked from access upstream before they ever hit the webapp server. This makes sleeping pretty easy.
We have automated, daily, versioned, backups that contain at least 90 days if not 365 days of versioned backups stored on a system that isn't able to reach over the internet. The at-risk servers don't "push" their backups, rather, the backup server "pulls" the backups from each client system. The client systems don't have any way to contact the backup server and certainly cannot access the backup storage directly. The restore of backups has to be "pushed" to the clients as well. It is a subtle thing, but drastically changes security risks.
With versioned backups, we can look through the versions and find where any attacks started. That's happened a few times over the decades and been really helpful. Finding the smoking attack 13 days before we noticed it, meant we could check all the other systems on the LAN for issues around the same time as the base starting point. Without versioned backups, we'd have to just blow away every system and start over to ensure some root kit wasn't left behind.
Security isn't just "patching", there is network architecture, systems architecture, storage architecture, backup and recovery design all to mitigate what can be done by nefarious actors. Patching is important, but not the only thing. Security always has layers. When possible, we'll use read-only mounts for static files used by a webapp. Remember watching someone attach a web server we'd setup with read-only mounts over NFS. There's no way the client could change them to be writable, but they really tried. Seeing all the failures in the system log files, as they happened was funny and a little sad.
But for desktops, security is simpler.
Adv Reply
Originally Posted by rusty.hinge
Bookmarks