Hi,


I'd like to propose a minor change to https://www.debian.org/doc/manuals/securing-debian-manual


While I have no argument with intrusion detection, I don't see anything
for active response. A metaphor would be Peter Cook and Dudley Moore's
extended joke:
https://www.youtube.com/watch?v=lbnkY1tBvMU

Anyway, I'd like to propose adding a section that describes ossec. While
I appreciate the detection aspect, I'm just a person who admins a server
farm of 6 Linodes mostly running WordPress. It took longer than it
should have to learn about ossec. I think an entry in the guide would be helpful. Also, with DEFCON approaching, this seems an appropriate time
to start this discussion.

Cheers,
jec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/12/23 08:47, Jeremy Stanley wrote:

On 2023-05-12 08:10:04 -0700 (-0700), Jeffrey Chimene wrote:
[...]

I'd like to propose adding a section that describes ossec.

[...]

There's an (ancient) RFP for it which apparently used to be an ITP:

https://bugs.debian.org/361954

There's no ossec-hids package in Debian currently though, so
actually packaging it for inclusion in the distribution seems like
the place to start.

Agreed. Actually, ossec itself has a debian package, so no ITP for me
:). It made my work significantly easier since the regex package (pcre2)
isn't part of the distro; the absence has a reason, but it's still an impediment that ossec itself has addressed with their .deb

I'm proposing adding a section to the document. I'll do the work.
There's a particular focus that I think needs clarifying, i.e. the
"accidental" sysop. To be clear, I've been using Debian since Potato as
a developer. It's only since 2017 that I've been actively using Buster, Bullseye.

<rant>I'm somewhat annoyed that, for example, Linode thinks documenting
ossec installation on Debian 7 is relevant to the sysop looking to
improve their security posture. That someone exploring ossec would be
running 7 seems not be a problem.</rant>


```

# Add Apt sources.lst
wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

# Update apt data
sudo apt-get update

# Agent
sudo apt-get install ossec-hids-[server|agent]

```

Cheers,
jec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-05-12 08:10:04 -0700 (-0700), Jeffrey Chimene wrote:
[...]

I'd like to propose adding a section that describes ossec.

[...]

There's an (ancient) RFP for it which apparently used to be an ITP:

https://bugs.debian.org/361954

There's no ossec-hids package in Debian currently though, so
actually packaging it for inclusion in the distribution seems like
the place to start.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmReX5dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCkhlQ//V28DQ/ck/DSO6erObQaxg1cu+lhNIxfYGqiN9UNxeXSPnoAxiS6K+JyO PVgaw9o97ER2BCaYOSjKl0Qvug6iFO01TKP19stO42ZdRlclZsjd7IOrEe7UWBp4 X/9akkAldJKc2Bp/y74V27l1cQZIFhMYm4YRQYOiZdtvi7mzEiwU9LJ/R3q5gu7a jT6VRhA13HJTgsMkOFXFbqUh6xDaAFUS24g+GWrK0pBCBlX+Jfv6PmNzDpqBYVUL 6wsAAgoL/LrPihXyUAqWKVBJzm0/eW8kimmsjshYKDBr6uxFaRVT2s+ylmvu8qTT 11g4pTfkqQa/UbB11G//yJnl3aQfZbcYotQ6ryeRKNk7enHB2jUaMVgMuvFLeiiO GzDocbn+VAQQNmflT+r7eASaUmy4uCMNCekeT5yHtDPJR/beUn4Fuv8AqPL08M6R 279vCoxsHFoJss16FZx4Dpe+/N9MWYv7Y2EVBJ7yfoDI7gxyOTcDYSZnqdW4re5G nIp1Ep+k/0x1/3SybgoB3KUVkHAtyUvUFpzCUj7hvtF0vAyvf/WCTQKAVzwaMW1I YiCcg1rsGbCDRkTTjOCjvgKHV8ZJS7TKKC9kCfFj3gqAzAbk8SY7TP1bDH3RGkaL fdXykxf/s9suJZu2VD1MD0mAjceaLZlv1Gn+QqZshgeo+sjYum0=
=0Iv3
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 2023-05-12 09:53:15 -0700 (-0700), Jeffrey Chimene wrote:
[...]

Agreed. Actually, ossec itself has a debian package, so no ITP for
me :). It made my work significantly easier since the regex
package (pcre2) isn't part of the distro; the absence has a
reason, but it's still an impediment that ossec itself has
addressed with their .deb

I'm not sure that official Debian documentation, particularly
security-focused documentation, should recommend that sysadmins
install packages from third party archives. That'll be up to the
maintainers of the documentation to decide, of course.

But beyond that...

wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

[...]

There's a bit of irony in suggesting that security-conscious
sysadmins should download and run arbitrary scripts, much less with
root privileges. `curl|sudo bash` has virtually become a meme unto
itself these days.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmRedFNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnV2g//ZuX5HQCnJjTQhlipuDhcdXPQvGHPc1n0EoO7486EXJWKmwkMXi8e8IJp kB0GDwKmap3Px1ZfUsvMUIyrEC080OyKwD3OT6Y7+rEi1ylsnjj5Tqn0HdBfV51h fl2l2iz5vK2XGJ4NqbQ4uFKUiIJ3lrXap2aXGNDfchYLSgAn2KzpHT2LPn8hITU1 jY2pXuiVg9SB8OxKKAYzVZObodx7t4t9ukqoWi2HAqhqC6Rf5+088r0MZe9bctSt SKjlWCx9/dSB+NBF2Iz7rbukk29GEMivFvlJiYYgD0ls8toTrtMVSJb1foR+0IyS 5vTZ6Mjw6IrUaQDVmCbkOaPtN+qu9LoII3GFWt4iCIdkgx5ewT1CRN3RlymCnxGg TNkuB+Key8mHhPXfmISjxF6U7zs1rdXDb3RrL3gsk6hJ3Br31lXN6M+lDuukjHO0 YQjBZxwOCGDDWVtAilIrFWmLpEJGrU5dOCTYRKvq7ROjMNP0XdRbv64duZThbOeU dTJkCruCZN9d3LdgiOVdiintExcg9Xu9DSY/3AUSecT+G7dDanEWIb/pBIVlaYvX YCkpwmWsMzUt0N+eeb5+0QtyEoi4iVPsuoEtarV6CBRgdUih9zPe9xLk048LQ4Ap JOs9QRN0tEmzMvKoE/ZhGnltn6ZUu25utqYnnn98Bg8Tl/TwTqQ=
=IC66
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 5/12/23 10:16, Jeremy Stanley wrote:

On 2023-05-12 09:53:15 -0700 (-0700), Jeffrey Chimene wrote:
[...]

Agreed. Actually, ossec itself has a debian package, so no ITP for
me :). It made my work significantly easier since the regex
package (pcre2) isn't part of the distro; the absence has a
reason, but it's still an impediment that ossec itself has
addressed with their .deb

I'm not sure that official Debian documentation, particularly security-focused documentation, should recommend that sysadmins
install packages from third party archives. That'll be up to the
maintainers of the documentation to decide, of course.

Agreed.

But beyond that...

wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

[...]

There's a bit of irony in suggesting that security-conscious
sysadmins should download and run arbitrary scripts, much less with
root privileges. `curl|sudo bash` has virtually become a meme unto
itself these days.

Thank you for your concern. I certainly look at the script before
execution. I think that suitable precautions can be written. I'm
installing on several systems, so I like to have such command as a
record. The example command comes from my notebook.


Thanks for your time!


Cheers,
jec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 2023-05-12 at 21:48:55 -0400, Michael Lazin wrote:

The thing that caught my eye is disabling execution for /tmp. I
managed thousands of Debian servers at one time and I often found hacker scripts in ./tmp because of a Wordpress exploit. This is because /tmp is world writable and presumably people who don't know better are unlikely to look for bad scripts there. While I agree pulling third scripts with curl
is cringe-worthy I think Ossec HIDS is an exception because it is GNU
Public licensed.

Because of a bug in the current version of Nitrokey's App 2 I became
aware that the /tmp on the machine I tested that app on was set to
default, i.e. rw,noatime. I set it to rw,nosuid,nodev,noexec,noatime
only to find out that the app did some dirty tricks to run that did not
work anymore with those mount options. See my ticket on Github: https://github.com/Nitrokey/nitrokey-app2/issues/54#issuecomment-1525455482

The problem is pyinstaller.

Which means that using a secure /tmp prevents this from working. I did
not check if pyinstaller respects TMPDIR or some such ENV variable. But
in the general case, one can't rely on this for every braindead
installer.

HTH,
Lupe Christoph

PS: BTW, just because something is GPLed does not mean it's trustworthy.
--
| Never attribute to malice that which is adequately explained by stupidity. |
| Hanlon's razor |
| Never attribute to malice that which can adequately be explained by awarding |
| every job to the lowest bidder. |
| From The Daily WTF https://thedailywtf.com/articles/thanks |

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

SInce Ossec HIDS is GNU Public licensed I think this is not a bad idea to include this in the documentation. The referenced article does describe securing Debian with open source tools and I honestly have seen this documentation for the first time tonight and I think it is very high
quality. The thing that caught my eye is disabling execution for /tmp. I managed thousands of Debian servers at one time and I often found hacker scripts in ./tmp because of a Wordpress exploit. This is because /tmp is
world writable and presumably people who don't know better are unlikely to
look for bad scripts there. While I agree pulling third scripts with curl
is cringe-worthy I think Ossec HIDS is an exception because it is GNU
Public licensed.

Michael Lazin

.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.


On Fri, May 12, 2023 at 3:33 PM Jeffrey Chimene <jeff@systasis.co> wrote:

On 5/12/23 10:16, Jeremy Stanley wrote:

On 2023-05-12 09:53:15 -0700 (-0700), Jeffrey Chimene wrote:
[...]

Agreed. Actually, ossec itself has a debian package, so no ITP for
me :). It made my work significantly easier since the regex
package (pcre2) isn't part of the distro; the absence has a
reason, but it's still an impediment that ossec itself has
addressed with their .deb

I'm not sure that official Debian documentation, particularly security-focused documentation, should recommend that sysadmins
install packages from third party archives. That'll be up to the maintainers of the documentation to decide, of course.

Agreed.

But beyond that...

wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo

bash

[...]

There's a bit of irony in suggesting that security-conscious
sysadmins should download and run arbitrary scripts, much less with
root privileges. `curl|sudo bash` has virtually become a meme unto
itself these days.

Thank you for your concern. I certainly look at the script before
execution. I think that suitable precautions can be written. I'm
installing on several systems, so I like to have such command as a
record. The example command comes from my notebook.

Thanks for your time!

Cheers,
jec

<div dir="ltr">SInce Ossec HIDS is GNU Public licensed I think this is not a bad idea to include this in the documentation.  The referenced article does describe securing Debian with open source tools and I honestly have seen this documentation for the
first time tonight and I think it is very high quality. The thing that caught my eye is disabling execution for /tmp.  I managed thousands of Debian servers at one time and I often found hacker scripts in ./tmp because of a Wordpress exploit.  This
is because /tmp is world writable and presumably people who don&#39;t know better are unlikely to look for bad scripts there.  While I agree pulling third scripts with curl is cringe-worthy I think Ossec HIDS is an exception because it is GNU Public
licensed. <div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Michael Lazin<br><span style="font-size:16.6px;font-family:serif"></span><div><br></div><div><span style="font-size:16.6px;font-
family:serif"></span><span style="font-size:16.6px;font-family:serif">.. </span><span style="font-size:16.6px;font-family:serif">τὸ </span><span style="font-size:16.6px;font-family:serif">γὰρ</span><span style="font-size:16.6px;font-
family:serif"> αὐτὸ </span><span style="font-size:16.6px;font-family:serif">νοεῖν </span><span style="font-size:16.6px;font-family:serif">ἐστίν </span><span style="font-size:16.6px;font-family:serif">τε </span><span style="font-size:
16.6px;font-family:serif">καὶ </span><span style="font-size:16.6px;font-family:serif">εἶναι</span><span style="font-size:16.6px;font-family:serif">.</span></div><span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.
6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span><
span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span><span style="font-size:16.6px;font-family:serif"></span></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="
gmail_attr">On Fri, May 12, 2023 at 3:33 PM Jeffrey Chimene &lt;<a href="mailto:jeff@systasis.co">jeff@systasis.co</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;
border-left-color:rgb(204,204,204);padding-left:1ex">On 5/12/23 10:16, Jeremy Stanley wrote:<br>
&gt; On 2023-05-12 09:53:15 -0700 (-0700), Jeffrey Chimene wrote:<br>
&gt; [...]<br>
&gt;&gt; Agreed. Actually, ossec itself has a debian package, so no ITP for<br> &gt;&gt; me :). It made my work significantly easier since the regex<br> &gt;&gt; package (pcre2) isn&#39;t part of the distro; the absence has a<br> &gt;&gt; reason, but it&#39;s still an impediment that ossec itself has<br> &gt;&gt; addressed with their .deb<br>
&gt; I&#39;m not sure that official Debian documentation, particularly<br>
&gt; security-focused documentation, should recommend that sysadmins<br>
&gt; install packages from third party archives. That&#39;ll be up to the<br> &gt; maintainers of the documentation to decide, of course.<br>
Agreed.<br>
&gt;<br>
&gt; But beyond that...<br>
&gt;&gt; wget -q -O - <a href="https://updates.atomicorp.com/installers/atomic" rel="noreferrer" target="_blank">https://updates.atomicorp.com/installers/atomic</a> | sudo bash<br>
&gt; [...]<br>
&gt;<br>
&gt; There&#39;s a bit of irony in suggesting that security-conscious<br>
&gt; sysadmins should download and run arbitrary scripts, much less with<br> &gt; root privileges. `curl|sudo bash` has virtually become a meme unto<br> &gt; itself these days.<br>

Thank you for your concern. I certainly look at the script before <br> execution. I think that suitable precautions can be written. I&#39;m <br> installing on several systems, so I like to have such command as a <br>
record. The example command comes from my notebook.<br>


Thanks for your time!<br>


Cheers,<br>
jec<br>


</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Lazin <microlaser@gmail.com> writes:

SInce Ossec HIDS is GNU Public licensed I think this is not a bad idea to include this in the documentation. The referenced article does describe securing Debian with open source tools and I honestly have seen this documentation for the first time tonight and I think it is very high
quality. The thing that caught my eye is disabling execution for /tmp. I

I don't know about the current state, but I did disable execution for /tmp
at some point, only to discover that installing some packages failed because
of this.

Although I don't remember, if it was the package or apt-get/dpkg needing
an executable /tmp.

managed thousands of Debian servers at one time and I often found hacker scripts in ./tmp because of a Wordpress exploit. This is because /tmp is world writable and presumably people who don't know better are unlikely to look for bad scripts there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)