Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Am 16.05.22 um 11:38 schrieb Sylvain:

Hello,

Here's the result of debcheckroot on an entirely fresh install of 
debian, without any access to the internet from a browser or a mail 
client. I only:

- ran "apt update" to test my internet connection
- copied files on a USB stick

Here's the fileserror.lis:

..._..M /usr/libexec/polkit-agent-helper-1 
policykit-1_0.105-31+deb11u1_amd64 root root 755

..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
.._L... /usr/share/dict/words american-english 
wamerican_2019.10.06-1_all root root 777
..._.GM /usr/lib/dbus-1.0/dbus-daemon-launch-helper dbus_1.12.20-2_amd64 
root root 755



Dear Sylvain
Dear readers of debian-security

  I have now analyzed these packages and in deed policykit sets setuid 
permissions in the postinst script manually instead of having these 
files unpacked with setuid bit set. This in order to honor 
dpkg-statoverride --list. However the problem for debcheckroot is that 
it can hardly analyze the postinst scripts; analyzing program logic 
would be turing complete and every postinst script is different.


policykit: calls set_perms if no statoverride present
cron: package configures dpkg-statoverride on its own
openssh-client: direct chmod, chgrp if no statoverride present
dbus: invokes dpkg-statoverride if not yet present

  Almost each of these packages would need its own logic for scanning 
the postinst script for setuid/chown/chgrp changes. Since there are only 
a limited number of such setuid programs it would be doable but probably 
not worth doing since as it turned out you can never truly rely merely 
on file modes any way.
  Debcheckroot was designed to detect file content alterations and it 
has several ways to do so. If this feature is not used you don´t get 
meaningful output information.


  So this time it was a false alarm. Debcheckroot did not detect 
anything, but in order for debcheckroot to be able to detect something 
you need to follow the recommendations at 
https://www.elstel.org/debcheckroot/. Most important is - do not scan 
from inside of the infected system. This does almost never give usable 
information.
  Please also excuse that I did not remember the docs correctly. I have 
not used the program on my own for quite a long time now. My main 
productive system has been running on Mageia and so applying 
debcheckroot was no more option for me.


  Finally I wanna conclude that this does certainly not mean Sylvain´s 
system was/is clean. Normally if you have a suspicion like him you don´t 
have that without reason. Also I have seen many rootkits not detected by 
rkhunter and chkrootkit, but yes by debcheckroot (I still have blue ray 
images of these incidents). If debcheckroot is not applied correctly it 
won´t yield any good result however. Besides this it is already quite a 
long time ago since I had developed that script and perhaps today´s 
rootkits are more prudent like the suggested memory only rootkits. To 
scan for this I would need to develop something like debcheckinitrd. 
Doable, but if there is little true known interest I won´t do that 
without any reward since my own interest is different. I just know from 
the weblogs that a South American university is using it besides some 
private people.


  The only thing that speaks for Sylvain´s initial allegation is that 
here appear to be posting people on this list who wiretap our private 
communication. He said "Feel free to cite me even if it WAS A PRIVATE 
EMAIL". - and that private email got cited by Michael Lazin posting on 
this list. Sylvain would have told me if the email was not private 
because this was my question. It  is the only thing provable for me now. 
Also I have noted that several emails addressed only to me got posted to 
the whole list. I simply don´t believe that Sylvain would do that 
intentionally for several times. At least I have not heard any 
explanation for it by him. I´d also believe there is no reason to 
interfere with me helping Sylvain if none of us were targeted in some 
way. I have asked Sylvain multiple times to repeat the scan fromout of a 
clean boot CD, because that could have been interesting. As far as what 
has reached me, he did not do that yet.


Regards,
Elmar Stellnberger

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Sylvain,

I just wanna warn you that there is a hardware backdoor in x86 
computers. Using that you won´t see any manipulation; like from a fresh 
install. See: https://www.elstel.org/uni/ DualSat master thesis, 
Epilogue, point 6 (as far as I remember, or last point).


Also please don´t re-send private emails like this one as new to 
debian-security. People will misinterpret your emails if they do not 
know the whole conversation.


Elmar

P.S.: If emailing does not work for you, you can call me via phone, 
usually on Tuesday, Wednesday and Thursday, but not this/next week; see 
elstel.org/Contact.html. FAX is also a possibility.



Am 16.05.22 um 12:34 schrieb Elmar Stellnberger:

Dear Sylvain

   That does not expose any rootkit. It is of course possible that the 
rootkit had already been deinstalled when you ran the test. Basically if 
you have suspicion you would need to unplug any physical connection. You 
could run an update before if you think the rootkiter has no reason to 
suspect what you will do next.
   I have discovered my first rootkit by installing offline merely from 
DVD, without updates. Then I installed again on a plain media and 
compared file for file (with a program called dircmp that I have not 
published yet). Afterwards I decided to write debcheckroot and that time 
it made me discover some more rootkits which I had burnt on blue ray 
along with the good files/packages to save evidence.


Yours,
Elmar


Am 16.05.22 um 11:38 schrieb Sylvain:

Hello,

Here's the result of debcheckroot on an entirely fresh install of 
debian, without any access to the internet from a browser or a mail 
client. I only:

- ran "apt update" to test my internet connection
- copied files on a USB stick

Here's the fileserror.lis:

..._..M /usr/libexec/polkit-agent-helper-1 
policykit-1_0.105-31+deb11u1_amd64 root root 755

..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
.._L... /usr/share/dict/words american-english 
wamerican_2019.10.06-1_all root root 777
..._.GM /usr/lib/dbus-1.0/dbus-daemon-launch-helper 
dbus_1.12.20-2_amd64 root root 755

_.C_... /var/lib/aspell/en-common.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_2.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

_.C_... /var/lib/aspell/en.compat aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

_.C_... /var/lib/aspell/en_CA-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

_.C_... /var/lib/aspell/en_GB-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

..._..M /bin/fusermount fuse_2.9.9-5_amd64 root root 755
..._..M /bin/ntfs-3g ntfs-3g_1:2017.3.23AR.3-4+deb11u1_amd64 root root 
755

_.._..M /etc/sudoers sudo_1.9.5p2-3_amd64 root root 644

Greetings,
Sylvain

Re: What is the best free HIDS for Debian

[Sylvain]

Hello,

Here's the result of debcheckroot on an entirely fresh install of 
debian, without any access to the internet from a browser or a mail 
client. I only:

- ran "apt update" to test my internet connection
- copied files on a USB stick

Here's the fileserror.lis:

..._..M /usr/libexec/polkit-agent-helper-1 
policykit-1_0.105-31+deb11u1_amd64 root root 755

..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
.._L... /usr/share/dict/words american-english 
wamerican_2019.10.06-1_all root root 777
..._.GM /usr/lib/dbus-1.0/dbus-daemon-launch-helper dbus_1.12.20-2_amd64 
root root 755

_.C_... /var/lib/aspell/en-common.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_2.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-w_accents-only.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-wo_accents-only.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en.compat aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

_.C_... /var/lib/aspell/en_CA-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

_.C_... /var/lib/aspell/en_GB-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-w_accents-only.rws 
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-wo_accents-only.rws 
aspell-en_2018.04.16-0-1_all

..._..M /bin/fusermount fuse_2.9.9-5_amd64 root root 755
..._..M /bin/ntfs-3g ntfs-3g_1:2017.3.23AR.3-4+deb11u1_amd64 root root 755
_.._..M /etc/sudoers sudo_1.9.5p2-3_amd64 root root 644

Greetings,
Sylvain

Re: What is the best free HIDS for Debian

[Sylvain]

Dear Elmar,

Thank you for your tips. But before reinstalling from scratch on my 
desktop, that is a lot of work, I will reinstall Debian on an old 
netbook which is on a desk and I don't use anymore. I'll run debchekroot 
on it and we will see...


I must apology if my English is not very good. I'm french and I do 
really have problems learning over languages. So sorry if I'm not very 
clear and if I use words in an unusual way...


Best regards,
Sylvain

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Dear Vitaly

On 5/10/22 05:24, Vitaly Krasheninnikov wrote:

Hi Elmar,
Thank you for debcheckroot. I think it is a great project, which makes us one 
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed 
us: "..._.GM" and "..._..M".
According to the description on your website, it means the modification of the 
file permissions, not the actual content.
...
So while I truly consider the debcheckroot very useful, I think in this case it 
was a false positive due to the side effects of the postinst scripts of the 
relevant packages.

Thank you,
Vitaly



  Thanks for pointing that out! I have not used the tool for long on my 
own, so that I forgot about the change indication marker letters. Of 
course there isn´t much you can say about the modified group and file 
permission of a file. See here what Sylvain Sécherre had written me in 
her original email:


On 5/6/22 15:05, Sylvain Sécherre wrote to estel...@elstel.org,
(BCC possible):
> Hello Elmar,
> ...
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> ..._..M /usr/libexec/polkit-agent-helper-1
> ...
> The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.
>
> I ran debcheckroot on a possibly infected machine.
>
> Thank you for your help!
>
> Best regards,
>
> Sylvain

  If debcheckroot was executed inside the infected root file system, 
then no wonder it can´t find anything. The rootkits I know, and I have 
discovered and burned several root kits on blue ray, have behaved like 
this: Inside the root infected executables compare ok against the 
pristine version, but not so outside the rootkit root when you have a 
fresh boot. The fact that group and file permissions of these 
executables have changed could at least be interpreted as suspicious 
though, since normally I´d truly believe there will be nobody who 
modifies that.


Regards,
Elmar

Re: What is the best free HIDS for Debian

[Richard van den Berg]

On 10/05/2022 05:37, Vitaly Krasheninnikov wrote:


Thank you for debcheckroot. I think it is a great project, which makes us one 
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed 
us: "..._.GM" and "..._..M".
According to the description on your website, it means the modification of the 
file permissions, not the actual content.


Thanks a lot for clarifying this. I found the interpretation of the 
results of debcheckroot at https://www.elstel.org/debcheckroot/


On 06/05/2022 15:52, Elmar Stellnberger wrote:

Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 
755

> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> ...

  I hope you won´t mind that I am citing the output of debcheckroot 
you have given me.
  These three files point to an infection with a rootkit. Don´t care 
about modified configuration files like in /etc too much (but you may 
still have a look at them). Executable files on the other hand must 
never be modified. If these three files are different it means that 
someone has altered your system. If you look at the man pages of these 
executables then you also know that a maker of a rootkit would have 
interest to modify exactly these files. 


Since you are the author of the debcheckroot tool, why do you think that 
the G (group) and M (mode) flags indicate the content of the files were 
altered? Or did you make a mistake and forgot what the output of 
debcheckroot actually means? If so, does this change your opinion that a 
rootkit is installed on this system?


Kind regards,

Richard

Re: What is the best free HIDS for Debian

[Vitaly Krasheninnikov]

Hi Elmar,
Thank you for debcheckroot. I think it is a great project, which makes us one 
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from 
fileserror.lis that you showed us: "..._.GM" and "..._..M".
According to the description on your website, it means the modification of the 
file permissions, not the actual content.

Since I was curious, I tried debcheckroot on my system, and found the same 
binaries at fileserror.lis (amongst a few others):
..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755

Here is the actual u/g and permissions:
-rwxr-sr-x 1 root crontab  Feb 23  2021 /usr/bin/crontab
-rwsr-xr-x 1 root root Jan 13 22:32 /usr/bin/pkexec
-rwxr-sr-x 1 root ssh Mar 13  2021 /usr/bin/ssh-agent

It is indeed different from the original deb-package permissions but I found 
the reason for that:
# egrep -e dpkg-statoverride /var/lib/dpkg/info/cron.postinst
dpkg-statoverride --update --add root crontab 2755 /usr/bin/crontab
# egrep -e chmod -e chgrp /var/lib/dpkg/info/openssh-client.postinst
chgrp ssh /usr/bin/ssh-agent
chmod 2755 /usr/bin/ssh-agent
# egrep -e set_perms /var/lib/dpkg/info/policykit-1.postinst
set_perms() {
set_perms root root 4755 /usr/bin/pkexec

So while I truly consider the debcheckroot very useful, I think in this case it 
was a false positive due to the side effects of the postinst scripts of the 
relevant packages.

Thank you,
Vitaly


On Friday, 6 May 2022 16:52:15 MSK Elmar Stellnberger wrote:
> Dear Sylvain
> 
> Am 04.05.22 um 13:17 schrieb Sylvain:
> > I've just tried debcheckroot too. It throws error. I'll try to fix them.
> 
> Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
>  > Here's the fileserror.lis:
>  > ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
>  > ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
>  > ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
>  > ...
> 
>I hope you won´t mind that I am citing the output of debcheckroot you 
> have given me.
>These three files point to an infection with a rootkit. Don´t care 
> about modified configuration files like in /etc too much (but you may 
> still have a look at them). Executable files on the other hand must 
> never be modified. If these three files are different it means that 
> someone has altered your system. If you look at the man pages of these 
> executables then you also know that a maker of a rootkit would have 
> interest to modify exactly these files.
> 
>  > The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.
> 
>If you have updated your system some time ago and there are newer 
> versions on the update server now then debcheckroot can certainly not 
> find these packages any more. You could try to update your system and 
> then verify again. Normally the rootkit will persist. However connecting 
> your computer to a network may be detrimental since the rootkit owner 
> may simply uninstall his rootkit once he knows that his malware has been 
> discovered.
>I would at least save suspicious executables first and additionally 
> the packages with known good of the same version.
> 
> Regards,
> Elmar
> 

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Am 09.05.22 um 13:34 schrieb t...@vandradlabs.com.au:



On 2022-05-09 18:04, Elmar Stellnberger wrote:

Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:

5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?


  If exactly such files have been changed where there is reason to
manipulate them for a rootkit then one shall assume unequivocally that
there is a rootkit installed. With bad RAM you get a system crash and
with a physically bad hard disk you get filesystem errors on fsck,


  Yes, bad cache ram written on a hard disk can at least by theory 
result in corrupted files on disk. If you read what I have written then 
you see my argument that then the whole program would have become 
unusable which is not the case for our example. Also I want to add that 
bad ram just causing file corruptions but no crash is somewhat very 
unlikely.




Not always true. I have experienced what looked like creeping file 
system corruption that was
in the end tracked down to bad RAM. it only occred under heavy load when 
RAM was over-utilised

and then swapped out.


  As said, I don´t really believe on what you tell here. By theory 
non-ECC ram can have errors, but these are very rare. Damaged ram on the 
other hand is damaged independent of the system load and it usually 
causes more severe/obvious effects. The probability that a corrupt ram 
block affects only block data but no kernel data structures is not that 
high as these tend to be interleaved.





none of which you get with a rootkit where only certain files have
been manipulated intentionally. A broken update could theoretically
result in a singleton file of half the size. Usually running programs


again I have seen bad/partial


  An update can only leave a partial file that is a prefix of an 
original file, never a corrupted one. That is, if you read, what I have 
told. All modern Linux filesystems use journalling and there will be no 
corruption like eventually on old Windows machines.


> I would want to see more info9rmationa botu what diagnostics were
> done before I cry rootkit.
>

  You are one of the people who want to tell people that they are not 
infected by a rootkit, when they obviously are. My recommendation for 
everyone is, care not to trust such people!
  Besides this I have requested Sylvain to collect more information, as 
this can still be interesting.

Re: What is the best free HIDS for Debian

[tmc]

On 2022-05-09 18:04, Elmar Stellnberger wrote:

Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:

5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?


  If exactly such files have been changed where there is reason to
manipulate them for a rootkit then one shall assume unequivocally that
there is a rootkit installed. With bad RAM you get a system crash and
with a physically bad hard disk you get filesystem errors on fsck,


Not always true. I have experienced what looked like creeping file 
system corruption that was
in the end tracked down to bad RAM. it only occred under heavy load when 
RAM was over-utilised

and then swapped out.


none of which you get with a rootkit where only certain files have
been manipulated intentionally. A broken update could theoretically
result in a singleton file of half the size. Usually running programs


again I have seen bad/partial


keep to use the old version of the file under Linux while newly issued
open operations on the same file name will use the file as replaced by
an update. A file of half the size would however result in an unusable
program, none of which you would usually observe with a rootkit.


I would want to see more info9rmationa botu what diagnostics were
done before I cry rootkit.

But if you wish to err on side of caution, backup your data and rebuild 
the box.

Then restore the data bit by bit avoiding executables.

Cheers
Tomasz

Re: What is the best free HIDS for Debian

[Michael Lazin]

This supports the use of rkhunter and running it once on first install but
you can manually find file changes systematically by becoming root and
going to the top level directory and running “find -ctime 1”, “find -ctime
-2” etc ad infinitum until you find all files that may have been
compromised.  This method will not find deleted files so some expertise in
the Linux file system is necessary when not using rkhunter.

Thanks,

Michael Lazin

On Mon,May 9, 2022 at 4:04 AM Elmar Stellnberger 
wrote:

> Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
> > 5. have we eliminated other causes of file mismatch - bad/incomplete
> > updates, corrupted HDD, bad RAM, user error ?
>
>If exactly such files have been changed where there is reason to
> manipulate them for a rootkit then one shall assume unequivocally that
> there is a rootkit installed. With bad RAM you get a system crash and
> with a physically bad hard disk you get filesystem errors on fsck, none
> of which you get with a rootkit where only certain files have been
> manipulated intentionally. A broken update could theoretically result in
> a singleton file of half the size. Usually running programs keep to use
> the old version of the file under Linux while newly issued open
> operations on the same file name will use the file as replaced by an
> update. A file of half the size would however result in an unusable
> program, none of which you would usually observe with a rootkit.
>
> Elmar
>
> --
Michael Lazin

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

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:

5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?


  If exactly such files have been changed where there is reason to 
manipulate them for a rootkit then one shall assume unequivocally that 
there is a rootkit installed. With bad RAM you get a system crash and 
with a physically bad hard disk you get filesystem errors on fsck, none 
of which you get with a rootkit where only certain files have been 
manipulated intentionally. A broken update could theoretically result in 
a singleton file of half the size. Usually running programs keep to use 
the old version of the file under Linux while newly issued open 
operations on the same file name will use the file as replaced by an 
update. A file of half the size would however result in an unusable 
program, none of which you would usually observe with a rootkit.


Elmar

Re: What is the best free HIDS for Debian

[Michael Lazin]

Rkhunter does find patterns of known rootkits but it also finds indicators
like memory anomalies like I mentioned and it logs each file change from
the install, this is why ideally you should install it in a fresh system.
Thanks.

Michael Lazin

On Sun, May 8, 2022 at 3:45 PM  wrote:

> Am 08.05.2022 20:43, schrieb estel...@elstel.org:
> > P.S.: A memory only rootkit would still need a hook to reinstall on a
> > fresh boot.
>
>Yes I know it is an issue. Debcheckroot does f.i. not check you
> initrd. To fix this issue I would need to program an own piece of
> software like debcheckinitrd. Anyone who wants to support me can do
> this: https://www.elstel.org/Contact.html. I am a free developer and I
> do not get paid for my open source related work.
>
-- 
Michael Lazin

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

Re: What is the best free HIDS for Debian

[estellnb]

Am 08.05.2022 20:43, schrieb estel...@elstel.org:

P.S.: A memory only rootkit would still need a hook to reinstall on a
fresh boot.


  Yes I know it is an issue. Debcheckroot does f.i. not check you 
initrd. To fix this issue I would need to program an own piece of 
software like debcheckinitrd. Anyone who wants to support me can do 
this: https://www.elstel.org/Contact.html. I am a free developer and I 
do not get paid for my open source related work.

Re: What is the best free HIDS for Debian

[estellnb]

Am 08.05.2022 20:48, schrieb Michael Lazin:

SELinux was made by the NSA but it open source, anyone can review the
source code, this is part of what makes open source software reliable,
it gets seen by many eyes, and even if you don’t review every line
of code yourself you have a web of trust that someone has reviewed it,
and it is strengthened by key signing which is more common in the
Debian community.  Thank you.

Michael Lazin



  If you talk about SELinux then let me talk about the times when 
Apparmor was not a default component to be installed, when I was 
creating and sharing Apparmor profiles to keep this technology 
supported. Sure, I have also read into SELinux. It can offer a better 
level of security, but it is more difficult to create profiles for it.
  The thing about rkhunter as I learned to know it was that it can only 
detect known rootkits. So who is adding NSA rootkits then? I am sure the 
NSA knows to prevent this. It would be nice to know about the circle of 
people who add rootkit descriptions/ detection code. Any way, if they 
have written the software, they will always know about the quirks and 
intricacies to avoid detection when it comes for them  to deploy their 
own rootkits.

Re: What is the best free HIDS for Debian

[Michael Lazin]

SELinux was made by the NSA but it open source, anyone can review the
source code, this is part of what makes open source software reliable, it
gets seen by many eyes, and even if you don’t review every line of code
yourself you have a web of trust that someone has reviewed it, and it is
strengthened by key signing which is more common in the Debian community.
Thank you.

Michael Lazin

On Sun, May 8, 2022 at 2:43 PM  wrote:

> Am 08.05.22 um 20:21 schrieb Michael Lazin:> I think if you have a root
> kit it is very unlikely to get rid of it
> > without backing up and reimaging but you may be able to achieve it if
> > you try first rkhunter and second apparmor which is similar to selinux
> > which was developed by the nsa and made accessible as a Red Hat
> > package.  Both solutions have the ability to limit what root can do and
> > is your only real option for saving a rooted system.  It is important
> > that if you try this that you dump your memory rkunter picks up a
> > memory
> > anomaly.  Fileless malware is popular among sophisticated threat actors
> > and rkhunter is equipped to find malware that resides in memory.
> > Apparmor is included in Debian.
> >
> > Thanks,
> > Michael Lazin
>Yes, it would be really interesting if rkhunter has also found the
> rootkit. If it was developed by the NSA, I am sure it would not find a
> rootkit used by the NSA. To my knowledge Apparmor was first developed as
> part of openSUSE. I can remember having filed them a report with the
> quest to keep Apparmor as it is more easy to use than SELinux.
>
> Elmar
>
> P.S.: A memory only rootkit would still need a hook to reinstall on a
> fresh boot.
>
-- 
Michael Lazin

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

Re: What is the best free HIDS for Debian

[estellnb]

Am 08.05.22 um 20:21 schrieb Michael Lazin:> I think if you have a root 
kit it is very unlikely to get rid of it

without backing up and reimaging but you may be able to achieve it if
you try first rkhunter and second apparmor which is similar to selinux
which was developed by the nsa and made accessible as a Red Hat
package.  Both solutions have the ability to limit what root can do and
is your only real option for saving a rooted system.  It is important
that if you try this that you dump your memory rkunter picks up a 
memory

anomaly.  Fileless malware is popular among sophisticated threat actors
and rkhunter is equipped to find malware that resides in memory.
Apparmor is included in Debian.

Thanks,
Michael Lazin
  Yes, it would be really interesting if rkhunter has also found the 
rootkit. If it was developed by the NSA, I am sure it would not find a 
rootkit used by the NSA. To my knowledge Apparmor was first developed as 
part of openSUSE. I can remember having filed them a report with the 
quest to keep Apparmor as it is more easy to use than SELinux.


Elmar

P.S.: A memory only rootkit would still need a hook to reinstall on a 
fresh boot.

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Hi Sylvain

  If you also care about the package selection you have installed you 
may do a 'dpkg -l' or copy /var/lib/dpkg/status. Possibly I will write 
something to clean the status file from packages that will be installed 
implicitly as dependency. Under Mageia you can use urpmi_rpm-find-leaves 
for that. Possibly also ask at a Debian mailing list (and tell me about it).

  I also forgot that you should possibly

cp -a /etc /media/usbdisk
  to save configuration files for later lookup. The /etc directory is 
not that big and you can copy it.


Elmar


On 08.05.22 17:15, Elmar Stellnberger wrote:

On 08.05.22 16:51, Sylvain Sécherre wrote:
I thought a lot about your answer and I feel a bit tricky... I 
understand what you're writing but I don't know how to do this.


Do you think I can simply get rid of these rootkit? I've tried to move 
the file "crontab" in a safe place and then reinstall the package 
cron. The new "crontab" file seems to be the same as the previous 
since the md5 are equal, but debcheckroot still throws an error for it...



Dear Sylvain

   No, I don´t think you can get rid of the rootkit by reinstalling a 
package. Usually rootkits are designed in a way that updating or 
reinstalling packages doesn´t damage the rootkit. The best thing to do 
is to reinstall new from scratch. In order to do this without 
complications I have an own home partition that I can register and reuse 
with /etc/fstab. If you don´t have that make a


 > cp -a /home /mnt/usbhdd/home

   However that is not all you need to respect. Basically any infected 
file can cause the rootkit to get reinstalled on your computer. That can 
also be the case for hidden files in your home directory like 
/home/sylvain/.*

   I always do it like this:

 > cd /home/sylvain
 > ls -lad .[^.]*
 > mkdir /mnt/usbhdd/hidden-quarantine
 > mv .[^.]* /mnt/usbhdd/hidden-quarantine

the .[^.]* - expression works like this:
* first match anything that starts with a dot (under Linux hidden files 
start with dots)
* second match a character that is not a dot [^.]: This excludes .. 
which denotes the parent directory. This one should of course not be copied

* third match any from zero up to more characters: *

   Make sure that you move away the hidden files before you copy your 
home directory back.
   Moving away hidden home directory files will also reset your Firefox 
bookmarks and saved passwords. If you have progressed this far I can 
tell you how to reinstall them - and under normal circumstances reusing 
a database file should not cause a rootkit to reinstall. If you are very 
thorough you can export the bookmarks as html and write down all saved 
passwords on a sheet of paper. You need to know however that getting rid 
of a rootkit with 100% certainty is hard since basically any binary file 
can result in an attack vector.
   If you have progressed this far, sure I am going to continue to help 
you with setting up a new installation and rescuing bookmarks (at least 
for FF).


Kind Regards,
Elmar

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

On 08.05.22 16:51, Sylvain Sécherre wrote:
I thought a lot about your answer and I feel a bit tricky... I 
understand what you're writing but I don't know how to do this.


Do you think I can simply get rid of these rootkit? I've tried to move 
the file "crontab" in a safe place and then reinstall the package cron. 
The new "crontab" file seems to be the same as the previous since the 
md5 are equal, but debcheckroot still throws an error for it...



Dear Sylvain

  No, I don´t think you can get rid of the rootkit by reinstalling a 
package. Usually rootkits are designed in a way that updating or 
reinstalling packages doesn´t damage the rootkit. The best thing to do 
is to reinstall new from scratch. In order to do this without 
complications I have an own home partition that I can register and reuse 
with /etc/fstab. If you don´t have that make a



cp -a /home /mnt/usbhdd/home


  However that is not all you need to respect. Basically any infected 
file can cause the rootkit to get reinstalled on your computer. That can 
also be the case for hidden files in your home directory like 
/home/sylvain/.*

  I always do it like this:


cd /home/sylvain
ls -lad .[^.]*
mkdir /mnt/usbhdd/hidden-quarantine
mv .[^.]* /mnt/usbhdd/hidden-quarantine


the .[^.]* - expression works like this:
* first match anything that starts with a dot (under Linux hidden files 
start with dots)
* second match a character that is not a dot [^.]: This excludes .. 
which denotes the parent directory. This one should of course not be copied

* third match any from zero up to more characters: *

  Make sure that you move away the hidden files before you copy your 
home directory back.
  Moving away hidden home directory files will also reset your Firefox 
bookmarks and saved passwords. If you have progressed this far I can 
tell you how to reinstall them - and under normal circumstances reusing 
a database file should not cause a rootkit to reinstall. If you are very 
thorough you can export the bookmarks as html and write down all saved 
passwords on a sheet of paper. You need to know however that getting rid 
of a rootkit with 100% certainty is hard since basically any binary file 
can result in an attack vector.
  If you have progressed this far, sure I am going to continue to help 
you with setting up a new installation and rescuing bookmarks (at least 
for FF).


Kind Regards,
Elmar

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

On 08.05.22 16:51, Sylvain Sécherre wrote:
I thought a lot about your answer and I feel a bit tricky... I 
understand what you're writing but I don't know how to do this.


Do you think I can simply get rid of these rootkit? I've tried to move 
the file "crontab" in a safe place and then reinstall the package cron. 
The new "crontab" file seems to be the same as the previous since the 
md5 are equal, but debcheckroot still throws an error for it...



Dear Sylvain

  No, I don´t think you can get rid of the rootkit by reinstalling a 
package. Usually rootkits are designed in a way that updating or 
reinstalling packages doesn´t damage the rootkit. The best thing to do 
is to reinstall new from scratch. In order to do this without 
complications I have an own home partition that I can register and reuse 
with /etc/fstab. If you don´t have that make a



cp -a /home /mnt/usbhdd/home


  However that is not all you need to respect. Basically any infected 
file can cause the rootkit to get reinstalled on your computer. That can 
also be the case for hidden files in your home directory like 
/home/sylvain/.*

  I always do it like this:


cd /home/sylvain
ls -lad .[^.]*
mkdir /mnt/usbhdd/hidden-quarantine
mv .[^.]* /mnt/usbhdd/hidden-quarantine


the .[^.]* - expression works like this:
* first match anything that starts with a dot (under Linux hidden files 
start with dots)
* second match a character that is not a dot [^.]: This excludes .. 
which denotes the parent directory. This one should of course not be copied

* third match any from zero up to more characters: *

  Make sure that you move away the hidden files before you copy your 
home directory back.
  Moving away hidden home directory files will also reset your Firefox 
bookmarks and saved passwords. If you have progressed this far I can 
tell you how to reinstall them - and under normal circumstances reusing 
a database file should not cause a rootkit to reinstall. If you are very 
thorough you can export the bookmarks as html and write down all saved 
passwords on a sheet of paper. You need to know however that getting rid 
of a rootkit with 100% certainty is hard since basically any binary file 
can result in an attack vector.
  If you have progressed this far, sure I am going to continue to help 
you with setting up a new installation and rescuing bookmarks (at least 
for FF).


Kind Regards,
Elmar

Re: What is the best free HIDS for Debian

[Michael Lazin]

I think if you have a root kit it is very unlikely to get rid of it without
backing up and reimaging but you may be able to achieve it if you try first
rkhunter and second apparmor which is similar to selinux which was
developed by the nsa and made accessible as a Red Hat package.  Both
solutions have the ability to limit what root can do and is your only real
option for saving a rooted system.  It is important that if you try this
that you dump your memory rkunter picks up a memory anomaly.  Fileless
malware is popular among sophisticated threat actors and rkhunter is
equipped to find malware that resides in memory.  Apparmor is included in
Debian.

Thanks,

Michael Lazin

On Sun, May 8, 2022 at 11:18 AM Sylvain  wrote:

> Dear Elmar,
>
> Thank you for your help. I really appreciate very much.
>
> I thought a lot about your answer and I feel a bit tricky... I
> understand what you're writing but I don't know how to do this.
>
> Do you think I can simply get rid of these rootkit? I've tried to move
> the file "crontab" in a safe place and then reinstall the package cron.
> The new "crontab" file seems to be the same as the previous since the
> md5 are equal, but debcheckroot still throws an error for it...
>
> Regards
>
> Sylvain
>
> Le 06/05/2022 à 16:20, Elmar Stellnberger a écrit :
> > Dear Sylvain
> >
> > The next thing I would do is create a timeline. Mount the partition with
> > noatime so that access times are preserved as they are on new file
> > operations and then let find output access, modification and creation
> > time of all files. Look on when these three executables have been
> > modified/created and then search back on what has happened at the
> > earliest time right before the rootkit has been installed. Once I
> > analysed a system of mine like this and found out that some suspicious
> > files had been uploaded in the ~/.skype directory. If I remember back I
> > think I had used vim for it but it should also be possible to use sth.
> > like sort.
> >
> > Regards
> > E.
>
> --
Michael Lazin

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

Re: What is the best free HIDS for Debian

[Sylvain]

Dear Elmar,

Thank you for your help. I really appreciate very much.

I thought a lot about your answer and I feel a bit tricky... I 
understand what you're writing but I don't know how to do this.


Do you think I can simply get rid of these rootkit? I've tried to move 
the file "crontab" in a safe place and then reinstall the package cron. 
The new "crontab" file seems to be the same as the previous since the 
md5 are equal, but debcheckroot still throws an error for it...


Regards

Sylvain

Le 06/05/2022 à 16:20, Elmar Stellnberger a écrit :

Dear Sylvain

The next thing I would do is create a timeline. Mount the partition with 
noatime so that access times are preserved as they are on new file 
operations and then let find output access, modification and creation 
time of all files. Look on when these three executables have been 
modified/created and then search back on what has happened at the 
earliest time right before the rootkit has been installed. Once I 
analysed a system of mine like this and found out that some suspicious 
files had been uploaded in the ~/.skype directory. If I remember back I 
think I had used vim for it but it should also be possible to use sth. 
like sort.


Regards
E.

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Dear Sylvain

The next thing I would do is create a timeline. Mount the partition with 
noatime so that access times are preserved as they are on new file 
operations and then let find output access, modification and creation 
time of all files. Look on when these three executables have been 
modified/created and then search back on what has happened at the 
earliest time right before the rootkit has been installed. Once I 
analysed a system of mine like this and found out that some suspicious 
files had been uploaded in the ~/.skype directory. If I remember back I 
think I had used vim for it but it should also be possible to use sth. 
like sort.


Regards
E.

Am 06.05.22 um 15:52 schrieb Elmar Stellnberger:

Dear Sylvain

Am 04.05.22 um 13:17 schrieb Sylvain:

I've just tried debcheckroot too. It throws error. I'll try to fix them.


Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
 > Here's the fileserror.lis:
 > ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
 > ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
 > ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
 > ...

   I hope you won´t mind that I am citing the output of debcheckroot you 
have given me.
   These three files point to an infection with a rootkit. Don´t care 
about modified configuration files like in /etc too much (but you may 
still have a look at them). Executable files on the other hand must 
never be modified. If these three files are different it means that 
someone has altered your system. If you look at the man pages of these 
executables then you also know that a maker of a rootkit would have 
interest to modify exactly these files.


 > The file filesunverified.lis is very long, while pkgcorrupt.lis is 
empty.


   If you have updated your system some time ago and there are newer 
versions on the update server now then debcheckroot can certainly not 
find these packages any more. You could try to update your system and 
then verify again. Normally the rootkit will persist. However connecting 
your computer to a network may be detrimental since the rootkit owner 
may simply uninstall his rootkit once he knows that his malware has been 
discovered.
   I would at least save suspicious executables first and additionally 
the packages with known good of the same version.


Regards,
Elmar

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

Dear Sylvain

Am 04.05.22 um 13:17 schrieb Sylvain:

I've just tried debcheckroot too. It throws error. I'll try to fix them.


Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> ...

  I hope you won´t mind that I am citing the output of debcheckroot you 
have given me.
  These three files point to an infection with a rootkit. Don´t care 
about modified configuration files like in /etc too much (but you may 
still have a look at them). Executable files on the other hand must 
never be modified. If these three files are different it means that 
someone has altered your system. If you look at the man pages of these 
executables then you also know that a maker of a rootkit would have 
interest to modify exactly these files.


> The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.

  If you have updated your system some time ago and there are newer 
versions on the update server now then debcheckroot can certainly not 
find these packages any more. You could try to update your system and 
then verify again. Normally the rootkit will persist. However connecting 
your computer to a network may be detrimental since the rootkit owner 
may simply uninstall his rootkit once he knows that his malware has been 
discovered.
  I would at least save suspicious executables first and additionally 
the packages with known good of the same version.


Regards,
Elmar

Re: What is the best free HIDS for Debian

[Sylvain]

Thank you very much for your answers.

I've tried to install Wazuh. It works fine but I can't install the agent 
and the manager on the same PC. Is it normal? However this soft seems to 
be very complex for my domestic needs...


I've just tried debcheckroot too. It throws error. I'll try to fix them.

Best regards,
Sylvain

Re: What is the best free HIDS for Debian

[Marc Haber]

On Tue, May 03, 2022 at 02:18:51PM +0200, Sylvain wrote:
> I have a segfault and this line in syslog: kernel: [ 1771.894150]
> aide[7032]: segfault at 1c ip 7f7472672050 sp
> 7fffc95d5bf0 error 4 in libnss_systemd.so.2[7f7472671000+33000]. The
> system is up to date from backports. The segfault is solved if I use the
> aid-dynamic package, but the scan is too much long...

What did you exclude from the default configuration? aide is in default
configured to check all home directores, which is probably not a good
idea if they contain millions of movies and pictues.

Did you read the fine README.Debian that comes with the aide package?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: What is the best free HIDS for Debian

[Elmar Stellnberger]

On 03.05.22 15:03, Jonathan Hutchins wrote:
When testing for intrusion on a system that has been running with a live 
connection, it's necessary to test from an inviolate source, an ISO 
image that is known to be un-infected.  Obviously, this should not be 
created on an infected machine, which is a problem if you have limited 
resources.




  Yes, exactly. If you are running Debian I would personally recommend 
debcheckroot (https:/www.elstel.org/debcheckroot/). It can test against 
fresh, untampered binary packages from any bootable Linux media. Debian 
is not required, use the next Linux magazine dvd. A system like Tripwire 
that monitors against file changes can itself be attacked, manipulating 
the checksums being stored by it in a way that you won´t detect these 
changes. You would need a backup of the sha256sums from a time of before 
the intrusion which is however not too old either. Using a package based 
checksum verifier like debcheckroot you do not have these problems!
  Note also that the date and time of the *first* intrusion may be 
before of what you think they are from the timeline if you have a tricky 
attacker. Timeline (file access, modification, creation times) is good 
for reconstructing on what has happened but you don´t need any with 
debcheckroot.

Re: What is the best free HIDS for Debian

[Jonathan Hutchins]

With that many errors from that many different programs it strongly 
suggests that there is a problem with your filesystem, possibly an 
existing infection.


When testing for intrusion on a system that has been running with a live 
connection, it's necessary to test from an inviolate source, an ISO 
image that is known to be un-infected.  Obviously, this should not be 
created on an infected machine, which is a problem if you have limited 
resources.


Nevertheless, you can try building a live image and testing from that.

--
Jonathan

On 2022-05-03 07:18, Sylvain wrote:

Thank you for your responses!


Tripwire:
-
- It throws a segfault error while scaning on one PC. No errors
mentioned in log files.
- on another machine tripwire worked fine for a long time but now I
have this error while scaning:
*** Fatal exception: basic_string::_M_create
*** Exiting...
run-parts: /etc/cron.daily/tripwire exited with return code 8


Aide:
-
I have a segfault and this line in syslog: kernel: [ 1771.894150]
aide[7032]: segfault at 1c ip 7f7472672050 sp
7fffc95d5bf0 error 4 in libnss_systemd.so.2[7f7472671000+33000].
The system is up to date from backports. The segfault is solved if I
use the aid-dynamic package, but the scan is too much long...


Integrit:
-
I have this error while initializing the DB: integrit (main): Error:
walk_file_tree: Permission denied
The support is simply a mailing list and I still don't have an answer
about this problem.


OSSEC:
--
There is no .deb for this soft. The compilation ends with an error.
I've just contact the support.


OSSEC+:
---
There's a problem during installation. I've just contact the support.



I'll test Wazuh.

Re: What is the best free HIDS for Debian

[Sylvain]

Thank you for your responses!


Tripwire:
-
- It throws a segfault error while scaning on one PC. No errors 
mentioned in log files.
- on another machine tripwire worked fine for a long time but now I have 
this error while scaning:

*** Fatal exception: basic_string::_M_create
*** Exiting...
run-parts: /etc/cron.daily/tripwire exited with return code 8


Aide:
-
I have a segfault and this line in syslog: kernel: [ 1771.894150] 
aide[7032]: segfault at 1c ip 7f7472672050 sp
7fffc95d5bf0 error 4 in libnss_systemd.so.2[7f7472671000+33000]. The 
system is up to date from backports. The segfault is solved if I use the 
aid-dynamic package, but the scan is too much long...



Integrit:
-
I have this error while initializing the DB: integrit (main): Error: 
walk_file_tree: Permission denied
The support is simply a mailing list and I still don't have an answer 
about this problem.



OSSEC:
--
There is no .deb for this soft. The compilation ends with an error. I've 
just contact the support.



OSSEC+:
---
There's a problem during installation. I've just contact the support.



I'll test Wazuh.

Re: What is the best free HIDS for Debian

[mlnl]

Hi Sylvain,

Sylvain  wrote:

>So can you tell me if there is another free HostBase Intrusion
>Detection System.

I have used Tripwire and Aide in the past and now, since a few years,
Samhain from source  together with
signify instead of gnupg for the signature database but without
Beltane management. Btw. i don't think, the "best" HIDS exist. 

-- 
mlnl

GPG:1FC05426F87FA623

Re: What is the best free HIDS for Debian

[Darren S.]

On Mon, May 2, 2022 at 11:36 AM Sylvain  wrote:
>
> Hello everyone !
>
> I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.
>
> All these softs throw errors while running or compiling on my Debian 11.3...
>
> So can you tell me if there is another free HostBase Intrusion Detection
> System.

Would definitely be good to know more detail on the issues you're
encountering with a pretty broad spectrum of tooling here.

I also recommend you take a look at osquery: https://osquery.io/

I'd also recommend a look at Wazuh as others have mentioned.

Another suggestion in the thread:

> Did you try Suricata?

This isn't HIDS, it's NIDS (network), but it's valuable nonetheless.
It's best deployed on a network perimeter or similar segment level to
protect multiple hosts. Particularly when running larger size
rulesets, memory consumption can be significant, so it may not be
suited for protecting each individual host in a fleet.

-- 
Darren Spruell
phatbuck...@gmail.com

Re: What is the best free HIDS for Debian

[Dave P.]

Did you try Suricata?
https://suricata.io/download/

D Pro

On Mon, May 2, 2022 at 2:36 PM Sylvain  wrote:

> Hello everyone !
>
> I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.
>
> All these softs throw errors while running or compiling on my Debian
> 11.3...
>
> So can you tell me if there is another free HostBase Intrusion Detection
> System.
>
> Sylvain
>
>

Re: What is the best free HIDS for Debian

[Gianluca Gabrielli]

Sylvain wrote:

I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.

All these softs throw errors while running or compiling on my Debian 
11.3...


So can you tell me if there is another free HostBase Intrusion Detection 
System.


Have you checked Wazuh [0] out?


[0] https://wazuh.com/

--
. o .  Gianluca Gabrielli  gianlu.ca
. . o  Software security engineer   suse.com
o o o  D78D 3FDC 2591 7EBA B52F 2362 6E17 38B8 2B60 B31D
-Dance like no one's watching, encrypt like everyone is-


OpenPGP_signature
Description: OpenPGP digital signature

Re: What is the best free HIDS for Debian

[Hannes von Haugwitz]

Hi Sylvain,

On Mon, May 02, 2022 at 08:11:18PM +0200, Sylvain wrote:
> I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.
>
> All these softs throw errors while running or compiling on my Debian 11.3...

Can you please be more specific? What are the errors you get from AIDE
on Debian 11.3?

Best regards

Hannes