Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

sysadmin in training

1 view
Skip to first unread message

Jeffrey Chimene

unread,
May 12, 2023, 11:40:04 AM5/12/23
to
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

Jeremy Stanley

unread,
May 12, 2023, 12:20:04 PM5/12/23
to
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
signature.asc

Jeffrey Chimene

unread,
May 12, 2023, 1:10:04 PM5/12/23
to
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

Jeremy Stanley

unread,
May 12, 2023, 1:21:47 PM5/12/23
to
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
signature.asc

Jeffrey Chimene

unread,
May 12, 2023, 3:40:04 PM5/12/23
to
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

Michael Lazin

unread,
May 12, 2023, 9:50:03 PM5/12/23
to
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

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

Lupe Christoph

unread,
May 12, 2023, 10:10:06 PM5/12/23
to
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 |

Olaf Dietsche

unread,
May 13, 2023, 8:41:15 AM5/13/23
to
Michael Lazin <micro...@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.
0 new messages