Michael Lazin 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 thin
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 an
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 t
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
re
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
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
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
ac
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
8 matches
Mail list logo
