[ 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, Javier El mar, 10 jun 2025, 15:11, Dave P. <[email protected]> escribió: > 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 <https://discord.com/invite/mggw8VGzUp> 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. > > Dave > > On Mon, Jun 9, 2025 at 12:21 PM Noah Meyerhans <[email protected]> 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 >> >>
