Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #6207 > unrolled thread

sysadmin in training

Back to article view | Back to linux.debian.security

Contents

  sysadmin in training Jeffrey Chimene <jeff@systasis.co> - 2023-05-12 17:40 +0200
    Re: sysadmin in training Jeremy Stanley <fungi@yuggoth.org> - 2023-05-12 18:20 +0200
      Re: sysadmin in training Jeffrey Chimene <jeff@systasis.co> - 2023-05-12 19:10 +0200
        Re: sysadmin in training Jeremy Stanley <fungi@yuggoth.org> - 2023-05-12 19:20 +0200
          Re: sysadmin in training Jeffrey Chimene <jeff@systasis.co> - 2023-05-12 21:40 +0200
            Re: sysadmin in training Michael Lazin <microlaser@gmail.com> - 2023-05-13 03:50 +0200
              Re: sysadmin in training Lupe Christoph <lupe@lupe-christoph.de> - 2023-05-13 04:10 +0200
              Re: sysadmin in training Olaf Dietsche <olaf+list.debian-security@olafdietsche.de> - 2023-05-13 14:40 +0200

#6207 — sysadmin in training

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

[toc] | [next] | [standalone]

#6208

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#6209

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

[toc] | [prev] | [next] | [standalone]

#6210

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#6211

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

[toc] | [prev] | [next] | [standalone]

#6213

[Multipart message — attachments visible in raw view] — view raw

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
>
>
>

[toc] | [prev] | [next] | [standalone]

#6214

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               |

[toc] | [prev] | [next] | [standalone]

#6216

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web