How can we (more) easily determine if a kernel-change-reboot is required in Debian, other than doing this in a script (which is a bit cumbersome)?

Ubuntu has /var/run/reboot-required and per our experience it works well. However, thus far Debian (at least in Buster, 10.6) does not. Some package(s) might have done this in the past (prior to Debian Jessie) and were replaced thigns that try/claim to do it today, but we've seen nothing work (in 10.6). Details below.

Things we've tried (in Debian 10.6) with no success:

1. checkrestart (no simple binary state report for kernel boot)
2. needrestart (same problem as #1)
3. Despite https://serverfault.com/a/667082/104173 claiming so, /var/run/reboot-required.pkgs has not yet been visible on our Debian 10.6 system (after a kernel upgrade).
4. reboot-notifier does not seem to offer anything that works.
5. lsof | grep lib | grep DEL does not (yet) seem to provide what we need.

"Nagios output mode" for some of the above options do not (yet) seem easily parsable.

For an iptables(8) firewall that is otherwise "properly locked down" in the filter table, is there any use to employ DROP, REJECT or similar, terminating, "blocking or disabling" rules in non-filters tables, namely the NAT table (or the mangle, raw, or security tables for that matter)?

We specifically want to close any, potential "holes" in our firewall.

NAT's POSTROUTING chain does not accept a DROP or REJECT target on at least one of out team's systems:

$ iptables -t nat -P POSTROUTING DROP
iptables v1.6.1:
The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.


Try `iptables -h' or 'iptables --help' for more information.
$
$ iptables -t nat -P POSTROUTING REJECT
iptables: Bad policy name. Run `dmesg' for more information.
$
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:    18.04
Codename:   bionic
$

How can one allow or deny an ssh login for a specific user(s) or group(s) on an sshd server?

(I realize SE has similar questions, but not I could find any that address this specific point. All others I found appear to conflate other scenarios.)

Summary

We want to support this scenario: if we sense any security threat that might expose our core data (all stored on a /home NFS mount from our NFS server), we immediately "hard" power off the NFS server. Any potential, successive, unauthorized reboot of the server can not read nor write to /home... because our system will (hopefully) require the password/key_challenge/secret from a human (as initially proposed below), possibly if not probably via a simple ssh login to the NFS server machine, before the system can mount the /home volume.

Is this feasible, and if so, how do we do this? Is this the "normal/default" mode for LUKS-based mounts (or some similar technology, toolset, gizmo)? And/or are there alternative (better?) ways to server our intent?

Details

My team plans to implement an NFS export of a LUKS-based, "sparse-file-like" loop-device file, similar to or exactly like a /home export (for NFS client mounting by other servers/machines/VMs/containers in our VPN/network).

Our current target implementation: require a password (or key-based challenge) before the system can mount the LUKS /home volume (only when mounting from the NFS server), presumably after normal bootup of the NFS-server machine/container.

However, if there's a better way... please do suggest it. We want to server the goal/intent described in the summary in the best way(s) possible and do not which to presume a limited scope of potential solutions.

Currently we anticipate the NFS server to be an Ubuntu 18.04.4 Docker container running on an the same-version-Ubuntu docker host. And the NFS-exported mount points will be Docker volumes served by the Docker host (to the NFS Docker container). But this design is far from "set," and we're flexible and open to alternative suggestions.

And while we are indeed serving an NFS application (of the system design) employing a loop-device ("filesystem in a file", as we understand it) mapping, we do not yet view this an an NFS- nor loop-device-specific problem. i.e., the same scenario might arise for other designs with no NFS or loop-device components.

System constraints

In our current environment, we can NOT employ a SAN-like solution. (We understand LUKS embedded in networked-storage/SAN solutions are popular nowadays. We've received a lot of comments similar to "just use a LUKS-based SAN." That will not work for us in this case.) Our current constraint: this NFS-server rig runs all within a kvm-based virtual machine, typically deployed by a hosting provider like DigitalOcean, Linode, AWS, etc.

Consequences and team background

Yes, we realize a hard-power-off / ungraceful shutdown of the NFS server will break all the NFS clients; we plan to require they all get rebooted (in the worse-case scenario). And yes, we realize that ungraceful shutdown can munge data, filesystems, databases, etc.

We have architected our network to robustly and (relatively) easily handle all these scenarios, within reason. Further: we expect 1) this "kill switch" scenario to rarely happens, and 2) we rarely have to reboot the NFS server system (Docker container or otherwise) for any reason; we'll keep it very stable and have all of our more-dynamically-changing software (OS, apps, etc) systems on other machines. The NFS server get's a bit, ole' config lockdown and super-simple setup, with few dependencies.

In any case, we're signing up for all this rig entails, as we are significantly-experienced block-and-filesystem, storage-server admins (long before LUKS was around) and have "been around this block," at least from long ago. (Specifically from pre-Fibre-Channel-SAN and post-FC-SAN era from the mid 1990's to the early 2000's, before Linux "was big." A bit more systems experience in the late 2000's to early 2010's.)

And while we're seasoned, grizzled veterans from the old days, we are also LUKS newbies. Nonetheless, the LUKS concepts all seem straightforward with similar systems we've managed previously. Our initial research shows that there's many StackExchange/ServerFault questions asking specifically how to avoid having to manually provide a password/key_challenge/secret of some sort. We effectively (we think?) want to do the opposite. And before we jump in implementing all this, we're posting this question in hopes we can learn from those who've gone before us, and maybe save a bit of project time.

Summary

In Unix, Linux, or BSD systems:

Besides private-key or password files, user-private content, or any custom-application-specific reasons (like serving a database of private information for users or automated processes, internal or external), why disable other access file permissions (eg: chmod -R o-rwx <file/directory>) for OS-system-installed files, related configuration settings content (often found in /lib and /etc) and additional, common/standard places?

Please read and understand this related question ("Why do many linux files have others=read access?") and its answers before commenting or answering.

More details

What general reasoning or "best practices" apply to most any system, particularly any system providing a service (popular examples include but not limited: DNS, SMTP, IMAP, HTTP, and their secure variants) on the public Internet?

Note that we are focusing more on system files and less on application-specific or user-private info (like many files/dirs found in /home).

My team is particularly interested in general paradigms/best practices for /etc, but the question applies to any part of any filesystem created in a Linux/Unix/BSD install.

In general, we'd prefer to keep all, default, other-readable (and/or executable and in rare cases, writable) permissions as is typically found in the default settings for each OS. We are simply looking for best-practice, general reasons (they are often privacy-and-security based reasons, but now always) why we would specifically disable any world permissions.

EDIT 2019-10-23

We're investigating further on our own systems. We're running variants of the following command in system-file directories (namely /etc) on our various host systems (all Ubuntu) to further evaluate. (Suggests and guidance for this approach welcome.)

find . -name .git -prune -o ! -type l \( ! -perm /o=r -a ! -perm /o=w -a ! -perm /o=x \) -exec ls -ld {} \+

Where can I find good documentation describing memory-rank "sparing" (for computer-hardware memory-protection configurations)? I'm seeking to clarify what benefits it provides and how it's typically implemented.

I'd prefer vendor-neutral documentation. Have had trouble finding quality docs thus far.

Scenario: hosted machine (typically a VPS) serving wiki, svn, git, forums, email lists (eg: GNU mailman), Bugzilla (etc) privately to < 20 people. People not on team not allowed access. Seeking VPN-restricted access to said server. Have good user experience with OpenVPN-based servers/clients, but have yet to server-admin such systems. Otherwise, experienced Linux sysadmin. Target system: Ubuntu, probably 12.04.

Seeking to put an OpenVPN process on above server to "protect" all the above-mentioned services, enabling only OpenVPN-authorized clients/processes to access above services. (Can easily acquire additional IP address(es) as needed for this setup.)

Option: if absolutely needed, can employ an additional, dedicated, "VPN server" VPS simply to be my VPN server "front end." But prefer to have all server processes (VPN server plus other server apps) all running on same machine, if possible. Will consider further if dedicated-VPN-machine setup enables 1. easier installation/administration, 2. better/easier end-user experience, and/or 3. makes system significantly more secure.

Any of above feasible?

The main intention: create a VPN from purely-hosted resources, and not spend all the effort to make a non-VPN, secure site--which typically means "SSL wrapping" + all the continual webserver-application-update management. Let the VPN server deal with access security, and spend list time pushing said security "down" in the other apps/Apache.