[ Apologies on advance for top posting but I'm writing this on my phone in an airplane ]
Dear Noah,
As the main developer of the manual I find tour comments very interesting. I agree that the manual needs an overhaul and I'm sure more hands in it would help improve it tremendously.
Moving the manual to a Wiki could be an option but I would rather first have an updated version/content using the current package/toolset and then consider moving it to a wiki.
The manual is not "centrally maintained" as it is available in Salsa for anyone to contribute bits and pieces as they see fit.
Alternatively, somebody could start writing in the wiki different sections related to hardening specific services and, once mature/finished, move it to the manual.
Personally I think that the manual :
- Should not cover in details the principles you mention. There is enough literature out there that it does not make sense to describe what other sources (books / sites) provide better info on (it is manual, not a book!)
- Should maybe focus only on specific use cases (eg setting up a server) rather than trying to cover all potential use cases (eg desktop) unless there are enough "hands" working on it
Those thoughts aside I would be glad to help in pushing patches / new versions of the manual to the archive if people start actively contributing to it.
Best regards,
Excellent idea Noah, especially Debian server security. I'm willing to help. The Wiki option sounds like the best way to me.Some points:- SSH server security- Firewalls: I think someone mentioned nftables, and that is optimal. But for people choosing between UFW and firewalld front-end tools, why firewalld will usually be preferable.- Monitoring/auditing: top/htop/etc, process termination, AIDE/Lynis/etc- Minimizing the attack surface- Modern backup strategies- Looking at the current manual, user security needs to be updated as well.Thanks for taking this on. As you say, the current manual has been out-of-date for a long time and is not easily reviseable.If you would like additional help, please email or contact me at my Discord server. I support Debian servers for several customers and use Debian 12 and sid on the client side. Also, I wrote an SSH server security manual for a customer; it can be reused for this purpose.DaveOn Mon, Jun 9, 2025 at 12:21 PM Noah Meyerhans <noahm@debian.org> wrote:Hi all. The Securing Debian Manual (the harden-doc package) is
woefully out of date and doesn't provide accurate guidance for
operating modern software in the current threat landscape. I'd like
to begin the task of updating it to reflect current best practice and
to document current tools and technologies.
Most basically, I wonder if folks think this is a worthy idea. The
landscape has changed significantly since harden-doc was first
written. Default configurations don't require as much hardening, and
there are lots more available resources. Maybe harden-doc has
stagnated because there's no real need for it?
Assuming we do revive the doc, here are some ideas of what I'd like to
do with the document. I'd like to also get feedback, ideas, and
contributions from others interested in the topic.
1. More background information on principles such as:
a. Threat modeling
b. Defense in depth
c. Least privilege
2. Modern server deployment practices, such as:
a. Sandboxing (with systemd, containers, etc)
b. Image-based deployments, including cloud
c. Update deployment strategies for large fleets
3. Data privacy:
a. VPNs, wireguard, etc
b. Disk encryption
4. Workstation best practices, including:
a. Ssh key generation and handling
b. Basic browser hygine
c. Password managers and other password hygine
My inclination is to primarily focus on general principles rather than
try to document specific settings in specific packages, as in the
current document's Chapter 5 ("Securing services running on your
system"). It'll make sense to document some approaches to safe usage of
the most common software (firefox, openssh, etc), but I don't believe
that it's feasible to provide useful advice for a meaningful subset of
Debian packages.
Should we maybe consider maintaining this document on wiki.debian.org,
rather than being a centrally maintained document? The wiki may scale
better to multiple contributors, leading to better content and more
active maintenance.
If you've got ideas for other topics, I'd love to hear them.
noah