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...
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
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.
Did you try Suricata?
So can you tell me if there is another free HostBase Intrusion
Detection System.
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 00007f7472672050 sp
00007fffc95d5bf0 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.
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.
I have a segfault and this line in syslog: kernel: [ 1771.894150]
aide[7032]: segfault at 1c ip 00007f7472672050 sp
00007fffc95d5bf0 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...
I've just tried debcheckroot too. It throws error. I'll try to fix them.
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
...
The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.
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 isempty.
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
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.
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...
cp -a /home /mnt/usbhdd/home
cd /home/sylvain
ls -lad .[^.]*
mkdir /mnt/usbhdd/hidden-quarantine
mv .[^.]* /mnt/usbhdd/hidden-quarantine
Dear Elmar,Michael Lazin
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.
--
without backing up and reimaging but you may be able to achieve it ifYes, it would be really interesting if rkhunter has also found the
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
cp -a /etc /media/usbdiskto save configuration files for later lookup. The /etc directory is
On 08.05.22 16:51, Sylvain Sécherre wrote:
I thought a lot about your answer and I feel a bit tricky... IDear Sylvain
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...
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
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,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
Michael Lazin
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.
P.S.: A memory only rootkit would still need a hook to reinstall on a
fresh boot.
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
Am 08.05.2022 20:43, schrieb estellnb@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.
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 <estellnb@elstel.org> wrote:
Am 08.05.2022 20:43, schrieb estellnb@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
.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?
Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:Michael Lazin
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
--
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.
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
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!
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 Scherre:
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 wont mind that I am citing the output of debcheckroot you have given me.
These three files point to an infection with a rootkit. Dont 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
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.
Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
Here's the fileserror.lis: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
..._.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.
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
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
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
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:53:26 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,330 |