Yeah, getting strong 90s vibes from this doc, perhaps because most hardening manuals like this are just collections of advice from other (bad and old) hardening manuals.

That's exactly it.

Lists like this exist to give administrators and their managers (1) a false sense of security when implementing it and (2) a subconscious excuse not to actually have to think about what you actually have to defend against. The list of topics is almost entirely useless if you are running any sort of containers on top of your Linux install, just as one example.

I'm sorry to be sounding so harsh, but I sincerely detest the security-by-checklist approach. It barely protects against any real-world threats, needlessly complicates matters, and gives credence to the perception that "security slow things down" through over-engineered solutions to non-existing problems. Moreover, it's a subconscious excuse to actually stop thinking about one's actual risks. Reasoning about actual threat models may not be easy but it is what one should be doing.

There's nothing "practical" about this at all, in my view.

> I'm sorry to be sounding so harsh, but I sincerely detest the security-by-checklist approach.

Checklists are essential (or becoming so) in all professions that require a level of safety or assurance in their operations. They don't replace careful though and action, but they do supplement it be making sure there's a minimum level of items that were checked and not omitted because someone thought they didn't apply when then did, or someone just plain forgot. A checklist is a good way to start some rational thinking about what's required for your specific case (especially if it's so restrictive that you have to (and are expected to) selectively alter portions of the checklist just so your current use case functions.

Checklists are well known and save lives in some professions (such as aviation), and are being applied to others even when there's push-back (Surgeons and emergency room operations[1]) because the benefits are just so large.

I think it's fair to dislike how people and organizations adopt a checklist in lieu of careful thought about security, and to dislike poorly defined and reasoned checklists themselves, but I for one would be much happier, and feel much safer, if security checklists were much more common overall.

1: https://www.who.int/bulletin/volumes/86/7/08-010708/en/

Checklists are fine if you have a fixed problem space. Just to go by your example - aviation safety is a mostly fixed problem space you can make mitigations in. Any item on the checklist would be there to mitigate safety issues almost any aircraft would encounter (and I'd imagine there are specific checklists for e.g. passenger vs. cargo aviation).

"Linux security" is not a fixed problem space. Not at all. And that's precisely my problem with this - this checklist pretends that it's a fixed problem space, and therefore grossly misrepresents the problem.

My point is that most problem spaces can be split into fixed and non fixed portions. Aviation safety has plenty of problems that require a real person to make a call and react intelligently, which is why we still have pilots. Checklists are used to cut down on the entirely avoidable problems that might be missed some percentage of the time otherwise.

There are plenty of things in Linux security that are static solutions that can be employed almost all the time, such as not allowing direct access to root accounts, always running a local firewall, making sure remote services aren't run as root without dropping privileges, etc.

I second that, encrypted /boot? Who is the adversary this is protecting you against? Many of these things looks like snake oil to me.

Encrypted boot really bit me in the ass one time, that's one afternoon spent in the dust underneath the stairs in my student housing that I won't get back.

Would've been so much easier to repair that machine if the boot partition wasn't so weird.

CIS and the various NSA STIGs are about the best actual prescriptive guides.

But threats occcur on a continuum - at a point (which is focused organised crime/nation state actors) you will lose...but there is still a lot of low hanging fruit you can win on.

> missing critical stuff for your typical hosted $webapp server usecase:

It looks like work in progress. Selinux, updates, deployment and many other topics are on the table of contents, but not present in the document. (Yet?)

It's got some context which is better than almost any other guide. Ideally they'd include some threat models applicable to each point, but that could come in the future (also you can send prs)

I think the CIS benchmarks are a good option, but they are very detailed. They do provide pre-rolled images though, which may be a quick solution.

I have recently completed a project applying CIS to a clients estate. Whilst CIS is great, particularly if you are a large Org having to deal with auditors and the like, it can only be regarded as the bare minimum.

Nah it looks like author just made table of contents and counts that there will be bunch of suckers that will collaborate on his repo by submitting pull requests.

Really, fire protection and locking racks with configuration of Nginx and Apache in same guide? If I am going to harden Apache, I am going to find Apache only guide.

Why not submit tickets or PRs? It looks like it's still actively maintained https://github.com/trimstray/the-practical-linux-hardening-g...