Re: Resurrecting the Securing Debian Manual

--000000000000b153de06373d2357
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[ 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=C3=B3:

> 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 wel=
l.
>
> 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 sid=
e.
> 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=E2=80=AFPM 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
>>
>>

--000000000000b153de06373d2357
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><p dir=3D"ltr">[ Apologies on advance for top posting but=
 I&#39;m writing this on my phone in an airplane ]</p>
<p dir=3D"ltr">Dear Noah,</p>
<p dir=3D"ltr">As the main developer of the manual I find tour comments ver=
y interesting.=C2=A0 I agree that the manual needs an overhaul and I&#39;m =
sure more hands in it would help improve it tremendously.</p>
<p dir=3D"ltr">Moving the manual to a Wiki could be an option but I would r=
ather first have an updated version/content using the current package/tools=
et and then consider moving it to a wiki.</p>
<p dir=3D"ltr">The manual is not &quot;centrally maintained&quot; as it is =
available in Salsa for anyone to contribute bits and pieces as they see fit=
. </p>
<p dir=3D"ltr">Alternatively, somebody could start writing in the wiki diff=
erent sections related to hardening specific services and, once mature/fini=
shed, move it to the manual.</p>
<p dir=3D"ltr">Personally I think that the manual : </p>
<p dir=3D"ltr">- Should not cover in details the principles you mention. Th=
ere 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, no=
t a book!)</p>
<p dir=3D"ltr">- Should maybe focus only on specific use cases (eg setting =
up a server) rather than trying to cover all potential use cases (eg deskto=
p) unless there are enough &quot;hands&quot; working on it </p>
<p dir=3D"ltr">Those thoughts aside I would be glad to help in pushing patc=
hes / new versions of the manual to the archive if people start actively co=
ntributing to it. </p>
<p dir=3D"ltr">Best regards,</p><div data-smartmail=3D"gmail_signature"><br=
>Javier</div></div><br><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">El mar, 10 jun 2025, 15:11, Dave P. &lt;=
<a href=3D"mailto:[email protected]">[email protected]</a>&gt; escribi=
=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family=
:tahoma,sans-serif;font-size:small">Excellent idea Noah, especially Debian =
<i>server</i> security. I&#39;m willing to help. The Wiki option sounds lik=
e the best way to me.=C2=A0 <br></div><div class=3D"gmail_default" style=3D=
"font-family:tahoma,sans-serif;font-size:small">Some points:</div><div clas=
s=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small"=
>- SSH server security <br></div><div class=3D"gmail_default" style=3D"font=
-family:tahoma,sans-serif;font-size:small">- Firewalls: I think someone men=
tioned nftables, and that is optimal. But for people choosing between UFW a=
nd firewalld front-end tools, why firewalld will usually be preferable.</di=
v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-=
size:small">- Monitoring/auditing: top/htop/etc, process termination, AIDE/=
Lynis/etc</div><div class=3D"gmail_default" style=3D"font-family:tahoma,san=
s-serif;font-size:small">- Minimizing the attack surface</div><div class=3D=
"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small">- M=
odern backup strategies</div><div class=3D"gmail_default" style=3D"font-fam=
ily:tahoma,sans-serif;font-size:small">- Looking at the current manual, use=
r security needs to be updated as well.</div><div class=3D"gmail_default" s=
tyle=3D"font-family:tahoma,sans-serif;font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small">=
Thanks for taking this on. As you say, the current manual has been=C2=A0out=
-of-date for a long time and is not easily reviseable.<br></div><div class=
=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small">=
</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;f=
ont-size:small">If you would like additional help, please email or contact =
me at my <a href=3D"https://discord.com/invite/mggw8VGzUp" target=3D"_blank=
" rel=3D"noreferrer">Discord</a> server. I support Debian servers for sever=
al 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 purpo=
se.</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri=
f;font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:tahoma,sans-serif;font-size:small">Dave<br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 9, 2025 =
at 12:21=E2=80=AFPM Noah Meyerhans &lt;<a href=3D"mailto:[email protected]" =
target=3D"_blank" rel=3D"noreferrer">[email protected]</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all.=C2=A0 The Secu=
ring Debian Manual (the harden-doc package) is<br>
woefully out of date and doesn&#39;t provide accurate guidance for<br>
operating modern software in the current threat landscape.=C2=A0 I&#39;d li=
ke<br>
to begin the task of updating it to reflect current best practice and<br>
to document current tools and technologies.<br>
<br>
Most basically, I wonder if folks think this is a worthy idea.=C2=A0 The<br=
>
landscape has changed significantly since harden-doc was first<br>
written.=C2=A0 Default configurations don&#39;t require as much hardening, =
and<br>
there are lots more available resources.=C2=A0 Maybe harden-doc has<br>
stagnated because there&#39;s no real need for it?<br>
<br>
Assuming we do revive the doc, here are some ideas of what I&#39;d like to<=
br>
do with the document.=C2=A0 I&#39;d like to also get feedback, ideas, and<b=
r>
contributions from others interested in the topic.<br>
<br>
1. More background information on principles such as:<br>
=C2=A0 =C2=A0a. Threat modeling<br>
=C2=A0 =C2=A0b. Defense in depth<br>
=C2=A0 =C2=A0c. Least privilege<br>
2. Modern server deployment practices, such as:<br>
=C2=A0 =C2=A0a. Sandboxing (with systemd, containers, etc)<br>
=C2=A0 =C2=A0b. Image-based deployments, including cloud<br>
=C2=A0 =C2=A0c. Update deployment strategies for large fleets<br>
3. Data privacy:<br>
=C2=A0 =C2=A0a. VPNs, wireguard, etc<br>
=C2=A0 =C2=A0b. Disk encryption<br>
4. Workstation best practices, including:<br>
=C2=A0 =C2=A0a. Ssh key generation and handling<br>
=C2=A0 =C2=A0b. Basic browser hygine<br>
=C2=A0 =C2=A0c. Password managers and other password hygine<br>
<br>
My inclination is to primarily focus on general principles rather than<br>
try to document specific settings in specific packages, as in the<br>
current document&#39;s Chapter 5 (&quot;Securing services running on your<b=
r>
system&quot;).=C2=A0 It&#39;ll make sense to document some approaches to sa=
fe usage of<br>
the most common software (firefox, openssh, etc), but I don&#39;t believe<b=
r>
that it&#39;s feasible to provide useful advice for a meaningful subset of<=
br>
Debian packages.<br>
<br>
Should we maybe consider maintaining this document on <a href=3D"http://wik=
i.debian.org" rel=3D"noreferrer noreferrer" target=3D"_blank">wiki.debian.o=
rg</a>,<br>
rather than being a centrally maintained document? The wiki may scale<br>
better to multiple contributors, leading to better content and more<br>
active maintenance.<br>
<br>
If you&#39;ve got ideas for other topics, I&#39;d love to hear them.=C2=A0 =
<br>
<br>
noah<br>
<br>
</blockquote></div>
</div>
</blockquote></div>

--000000000000b153de06373d2357--