rkhunter-users Mailing List for Rootkit Hunter

Hi,

Le 09/06/2025 à 15:47, Ricky Tigg a écrit :
>
> > I think Fedora uses the last git version, which is dated October 24, 2022, plus some patches.
>
> October 24, 2022 - How could this date be verified on my system? From my investigation, I found that it was February 2018.

There is no easy way to verify version and date of unreleased version of RKH. I just have a look in the file 
"rkhunter-1.4.6-29.fc42.src.rpm", I was wrong: the tarball is the one of plain 1.4.6. not the one of the last git version.

>
> On https://sourceforge.net/p/rkhunter/support-requests/74/
>
> Username: dogsbody | Nov 30, 2023 | "We still use rkhunter as part of our suite of protection on around 150 servers and run 
> https://rkhmirror.dogsbody.com/ for the times that sourceforge goes down."
>
There is only the plain 1.4.6 version on this mirror..
> On https://www.rkhunter.dev/
>
> Indeed, the project is said to have been since December 2023 sponsored by Dogsbody Technology.
>
> As you suggested, it would be worth investigating there - and that in the first place.
>
> On https://rkhmirror.dogsbody.com/
>
> At pkgs/
> "rkhunter-1.4.6.tar.gz 24-Feb-2018 23:17"
>
> Here the version is even dated one day older than the one hosted on Sourceforge!
>
That's probably the date of the copy of SF repo or it's due to the time zone change (dogsbody.com is in England)
> Come to think of it, by the way, on Sourceforge, Rootkit Hunter declares "Brought to you by: dogsbody, dogsbodymark". One of 
> those names may be willing to discuss patches and signatures DBs.
>
Dogsbody is Dan Denton himself. I never heard of Dogsbodymark (Mark Flitter) . He create this Sourceforge  account on 
2025-05-15 (one month ago).
Maybe an employee of Dogsbody.com put in charge of RKH recently ?
> On Github, khunter
>
> No maintainer. Last commit dated on Feb 25, 2018 - authored by John Horne. Update RPM specifications file for version 1.4.6, 
> re-release of v. 1.4.6 tagged version-1.4.6a, itself tagged with date Feb 25, 2018.
>
There are maintainers, but the list is private: "This organization has no public members. You must be a member to see who’s a 
part of this organization." (read this on https://github.com/Rootkit-Hunter). That seems to be the new official repo: there is 
a link to https://www.rkhunter.dev/ there.
> On Sourceforge
>
> Contact information about "John Horne"
>
> "John Horne, University of Plymouth, UK (...)
> E-mail: E-mail: Joh...@pl... (...)"
>
> It is to be expected that the contact details displayed for this user have become obsolete since the user's last message on a 
> mailing list on 17 February 2006. Thus it seems wise not to entertain any hope of being able to contact this user by email at 
> joh...@pl..., which would likely have been that of this user.

John gave the admin right and the ownership of SF repo to Dogsbody, except these changes, everything remains unchanged since 
then (except for 2 or 3 added issues).

Regards.

Hello. README file, line 568, CREATING A NEW LANGUAGE FILE; this section
likely describes how to create a local language file dedicated to
rkhunter's tests and results. But what about creating such a file in the
source code, like "de" which is present when installing in
/var/lib/rkhunter/db/i18n and printed by 'rkhunter --list lang'?

A search of the archives of this mailing list against the keyword
"language" yielded no results. If the project had been hosted on
Git-structured Codeberg.org, then I would have been able to submit a
commit. On Sourceforge, however, the practice must differ.

Le 08/06/2025 à 16:17, Ricky Tigg a écrit :
> February 24, 2018, the date of publication of the last version—this one. I assume that since no version has been released 
> since then, there wasn't a sufficient need for it. The fact that such software exists is itself a source of satisfaction. And 
> even more so, since it's the only one for POSIX-compliant systems. It certainly ranks among the 256 best programs of all time 
> for POSIX-compliant systems. I'd give it a rating of 4.00–4.25 out of five if Sourceforge supported such precision.
>
> While there's clearly no issue here in the traditional sense, I agree with you about the documentation. Generally, any 
> documentation benefits from being up-to-date to ensure its reliability. Here are a few examples for illustration.
>
> case 1 | README file
>
> ---
> $ nano -l /usr/share/doc/rkhunter/README
>   5 Copyright (c) 2003-2017, Michael Boelen
>   6 See the LICENSE file for conditions of use and distribution.
>
>  10 the RKH website at http://rkhunter.sourceforge.net
> ---
>
> Updating would bring a full copyright chain and accurate website URL which is served as HTTPS, not HTTP. Here shown as 
> updated respectively:
>
> ---
>   5 Copyright (c) 2003-2017, Michael Boelen
>   6 Copyright (c) 2017-, <name>
>
>  11 the RKH website at https://rkhunter.sourceforge.net
> ---
>
> case 2 | rkhunter RPM package metadata
>
> $ rpm -qi rkhunter | grep ^URL
> URL         : http://rkhunter.sourceforge.net/
>
> Same observation regarding the URL; the actual website is used over HTTPS, not HTTP. Since this is mentioned as such in the 
> RPM package metadata, it might be the same in the project source code.
>
> > FWIW, that's around lines 21690 and 2250 in rkhunter file.
>
> What resource are you referring to by "rkhunter file"?

Hi,

I think Fedora uses the last git version, which is dated  October 24, 2022, plus some patches.

In fact, there is need for a new release, but the primary (and lately the only) maintainer, John Horne, said he won't support 
the project anymore (see https://sourceforge.net/p/rkhunter/support-requests/74/).

There is also no news from Unspawn, the one who maintain signatures DBs, since November 2016.

Dan "Dogsbody" Denton then takes over the project in December 2023.
There is a migration repo here: https://github.com/Rootkit-Hunter/rkhunter and a site here: https://www.rkhunter.dev/
The version there is genuine 1.4.6 from 2018.
But nothing happens since then. And it seems Dan is no longer responding.
If you want to you can try to contact him there: https://www.dogsbody.org/ or there: https://www.dogsbody.com/ or even on this 
RKH mailing list.

Concerning the line numbers, I refer to the rkhunter script : /usr/bin/rkhunter.

Cheers.

Hello. README file, line 568, CREATING A NEW LANGUAGE FILE; this section
likely describes how to create a local language file dedicated to
rkhunter's tests and results. But what about creating such a file in the
source project, like "de" which is present in /var/lib/rkhunter/db/i18n and
printed by 'rkhunter --list lang'?

A search of the archives of this mailing list against the keyword
"language" yielded no results. If the project had been hosted on
Git-structured Codeberg.org, then I would have been able to submit a
commit. On Sourceforge, however, the practice must differ.

Le 07/06/2025 à 19:11, Ricky Tigg a écrit :
> Knowing now the context related to the LOGFILE key in the rkhunter.conf produced by the upstream project, I can at last 
> determine what has been done on Fedora's side.
>
> "# The default value is '/var/log/rkhunter.log'.
> #
> LOGFILE=/var/log/rkhunter/rkhunter.log"
>
> - No line addition took place
> - line dedicated to the LOGFILE key uncommented
> - New value for LOGFILE key defined
>
> Worth indicating that the very act of defining a path as value for the LOGFILE key is to be conceived as making it a default 
> for the option '--logfile' while no log-file is being specified in command-line with respect to the creation of rkhunter.log.
>
> > The key is now defined and this changes the path of log file. It's no more the default path.
>
> What happens? This "this changes the path of log file. It's no more the default path" is not related to the context.
>
> "As a result a log-file is created; its location is /var/log/rkhunter.log".
>
> Explicit is the location though!
>
> Even according to your very statement, it can be understood that the location where rkhunter.log is created is supposed to 
> match the LOGFILE key value - that is /var/log/rkhunter/rkhunter.log, not /var/log/rkhunter.log.
>
> > In case where the path is not given on the command line AND the key is not defined in the file, the default path 
> (/var/log/rkhunter.log) will be used.
>
> This too is not related to the context. The case obviously is that the '--logfile' file path is not specified and the LOGFILE 
> key value is defined. Despite that as already indicated the path the log-file is created in is /var/log/rkhunter.log while 
> supposed to be /var/log/rkhunter/rkhunter.log.
>
> Can you conclude that there is no issue?
>
>
> _______________________________________________
>
>     Rkhunter-users mailing list
>     Rkh...@li...
>     https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>
Hi,

Sorry I misread your post, I read "/var/log/rkhunter/rkhunter.log" there:

 > As a result a log-file is created; its location is /var/log/rkhunter.log

At the start of "OPTIONS" section, man page says :

       Some  options  can  also  be  specified  on the command-line, and these will *override**the equivalent configuration 
file options. *

As a result when you put a "-l" or a "--logfile" alone on the command line (without file path), RKH initializes the path with 
${DFLT_LOGFILE}, which equals to "/var/log/rkhunter.log", and overrides the rkhunter.conf LOGFILE parameter.

FWIW, that's around lines 21690 and 2250 in rkhunter file.


If you want the log file to be "/var/log/rkhunter/rkhunter.log" there are two ways:

- add LOGFILE=/var/log/rkhunter/rkhunter.log" in rkhunter.conf *AND* *don't put* -l/--logfile on the command line (it's implicit).

- put -l/--logfile "/var/log/rkhunter/rkhunter.log"  on the command line. It overrides  the conf file option.

The man page isn't really false but is surely quite unclear.

Note: I put the RKH list back in recipients list.

Regards.

Le 06/06/2025 à 21:00, Ricky Tigg a écrit :
> Log-file default location ignored when no file is specified for '--logfile'
>
> ---
> rkhunter(8) | man-pages
>
> -l, --logfile [file]
>  "If no specific file is given, then the default will be used."
> ---
>
>  I can reasonably assume that "default" implicitly refers to the LOGFILE key value that is in rkhunter.conf. Which thus 
> matches the situation where by default rkhunter writes out a log-file.
>
> Log-file default location
>
> # grep ^LOGFILE /etc/rkhunter.conf
> LOGFILE=/var/log/rkhunter/rkhunter.log
>
> To reproduce
>
> $ sudo rkhunter -X --rwo --cronjob --logfile --enable immutable
>
> As a result a log-file is created; its location is /var/log/rkhunter.log. Then that is unexpectedly according to rkhunter(8) 
> man-pages
>
> ---
> -l, --logfile [file]
>  "By default rkhunter will write out a log file. The default location of the file is /var/log/rkhunter.log."
> ---
>
>  The LOGFILE key value being ignored, does this indicate an issue?

Hi Ricky,

The default rkhunter.conf file contains (note that all lines are comments):

#
# This option specifies the log file pathname. The file will be created if it
# does not initially exist. If the option is unset, then the program will
# display a message each time it is run saying that the default value is being
# used.
#
# The default value is '/var/log/rkhunter.log'.
#
#LOGFILE=/var/log/rkhunter.log

In this case (key not defined) the path for log file is /var/log/rkhunter.log (default).

Fedora changes the rkhunter.conf file and adds  the line :

LOGFILE=/var/log/rkhunter/rkhunter.log

The key is now defined and this changes the path of log file. It's no  more the default path.

-l and--logfile are equivalent to the LOGFILE key.
In case where the path is not given on the command line AND the key is not defined in the file, the default path 
(/var/log/rkhunter.log) will be used.

That's not the case in the FEDORA package.

So everything is OK and there is no issue.

Regards.

Log-file default location ignored when no file is specified for '--logfile'

Rootkit Hunter v. 1.4.6
Shell: bash
OS: Fedora (on Wayland)

 Hello.

---
rkhunter(8) | man-pages

-l, --logfile [file]
 "If no specific file is given, then the default will be used."
---

 I can reasonably assume that "default" implicitly refers to the LOGFILE
key value that is in rkhunter.conf. Which thus matches the situation where
by default rkhunter writes out a log-file.

Log-file default location

# grep ^LOGFILE /etc/rkhunter.conf
LOGFILE=/var/log/rkhunter/rkhunter.log

To reproduce

$ sudo rkhunter -X --rwo --cronjob --logfile --enable immutable

As a result a log-file is created; its location is /var/log/rkhunter.log.
Then that is unexpectedly according to rkhunter(8) man-pages

---
-l, --logfile [file]
 "By default rkhunter will write out a log file. The default location of
the file is /var/log/rkhunter.log."
---

 The LOGFILE key value being ignored, does this indicate an issue?

Le 05/06/2025 à 17:26, Ricky Tigg a écrit :
> Rootkit Hunter v. 1.4.6
> ---
> rkhunter(8) | man-pages
>
> -l, --logfile [file]
>  (...) The default location of the file is /var/log/rkhunter.log. (...)
> ---
>
>  Hello. The default location of the log-file on Fedora Linux (RPM) is /var/log/rkhunter/rkhunter.log.
>
> Does this imply a need for correction in the documentation accordingly?
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Hello,

No, the log file location is defined in the rkhunter.conf file.

By default it is defined as /var/log/rkhunter.log. Fedora change this in its RKH package to /var/log/rkhunter/rkhunter.log.

Regards.

Rootkit Hunter v. 1.4.6
---
rkhunter(8) | man-pages

-l, --logfile [file]
 (...) The default location of the file is /var/log/rkhunter.log. (...)
---

 Hello. The default location of the log-file on Fedora Linux (RPM) is
/var/log/rkhunter/rkhunter.log.

Does this imply a need for correction in the documentation accordingly?

Bonjour,

Rkhunter warns me about suspicious files found in /dev:
Warning: Suspicious file types found in /dev:
[09:59:14]          /dev/shm/lttng-ust-wait-8: data
[09:59:14]          /dev/shm/lttng-ust-wait-8-3025: data

These files are opened  by wireplumb ie. the sound system...

Why are they "suspicious" and how can get rid of these warning?

Thank you.

F.P.

Is there some updates on definition (rkhunter --update) done or is rkhunter now EOL ?
/Alex

________________________________________________
Aleksei Landychev
IT-specialist
Mobil: 070-864 99 96

Bolagsverket, 851 81 Sundsvall, Telefon: 0771-670 670
bol...@bo...<mailto:bol...@bo...> - http://www.bolagsverket.se<" rel="nofollow">http://www.bolagsverket.se/>

Tänk på miljön innan du skriver ut det här e-postmeddelandet!
Förenkla ditt företagande - använd våra e-tjänster!

Hi All,

I'm Dan (Dogsbody) and I (we) took ownership of the rkhunter project 
last month :-)

Sorry for the radio silence, there is a lot to unpack and as you have 
all already stated, development has stalled for a number of years.

We have plans to update rkhunter (slowly at first) although it still 
stands up really well.

As John states, there are already a pile of backlogged bugs so please 
feel free to continue to submit improvements.

I do want to separate development conversations from user conversations 
so please do sign up to the rkhunter-devel mailing list 
https://sourceforge.net/projects/rkhunter/lists/rkhunter-devel

More when I have it.

Dan Benton


On 16/03/2024 05:15, jwa...@gm... wrote:
> I've used rkhunter for quite some time & have found it useful,
> but do use a number of other things as well. Much home grown.
>   
> As to support, I've reported a bug via the Fedora bugzilla &
> it was fixed.
>
> 	2020/06/27 - sshd_config -
> 			https://bugzilla.redhat.com/show_bug.cgi?id=1851620
>
> and one that had already been fixed (use of egrep) but these were triggered by
> changes in the way sshd config files were arranged & egrep was being
> discouraged in favour or grep -E (same for fgrep/grep -F ...) & stray escapes.
>
> If you look at,
>
> 	https://sourceforge.net/p/rkhunter/bugs/
>
> there are the open bugs. Pick one & fix it
>
> Likely the maintainer needs help, which means some young blood.
> But as I recall from many years ago before I retired, young blood
> actually caused me too many problems explaining why certain code was the way
> it was from 30 years before & that if they wanted to rewrite something from
> scratch that worked be my guest... they soon lost interest sadly.
>
> Look at the user profiles of the maintainers, particularly, jhorne the
> primary maintainer) & the comments there, as well as comments on many of the
> open bugs.
> Also jhorne's activity to see what was done & the needs...
>
> John Horne: It appears both dogsbody & unspawn are no longer involved/responding
> is that right?
>
> I thought I'd look at doing something from the rkhunter bug list & picked the
> oldest bug, permissions on rkhunter tmp files (I realise I need a longer life
> expectancy, less grandchildren & slightly less travel addicted travel partner)
> but as a suggestion would a start on that not be a much more restrictive
> umask? (& see if Christoph Anton Mitterer <cal...@sc...> is happy
> with that - as he submitted it in 2010! ;-)
>
> Cheers
>
> John
>
> On Tue, 2024-03-12 at 19:50 -0400, r3doubt wrote:
>> I have found rkhunter useful, especially for quick triage or auditing and
>> hardening to create a baseline configuration.  I wouldn't rely on static
>> signatures for any sort of malware analysis or DFIR, regardless of OS or
>> product.
>>
>> For a continuous monitoring EDR use case, I would recommend two free and open-
>> source solutions, as an alternative to commercial offerings.  I have found
>> OSQuery to be a pretty useful tool on MacOS and Linux, giving me some of the
>> same EDR via native logs I get using Sysmon and Windows Event Logs on Windows
>> boxes.  For dealing with "live off the land" style intrusions, this type of
>> data is crucial for EDR.    OSQuery will look at things like syslog, but will
>> limit the info reported to a DIF on changes to certain logs or settings which
>> are stored in SQL style relational DB.  You can set custom monitoring in a
>> syntax similar to SQL.  I've been a "certified product engineer" for major
>> vendors, and even contributed to some of their work on things like security
>> orchestration, but you can't "buy" security, regardless of the product, comes
>> down to putting in the work.
>>
>> You can also install an instance of Security Onion, and run it as either a
>> distributed instance for enterprise use, or in the standalone mode for the
>> student, hobbyist, SoHo network.  It can be set to pull your native logs from
>> Linux, and do a lot of ingest and normalization for you, giving you a pretty
>> nice dashboard and SOC environment based in Kibana (it runs on ELK stack).  It
>> can also work, out of the box, with OSQuery on your Linux endpoints.
>>
>> Don't forget about NIST either.  NIST, CISA, NSA, and GCHQ (UK) have all put
>> out various public hardening guides and even open-sourced auditing and
>> hardening scripts for Linux / Unix systems to help automate configurations.
>>
>> -R3doubt
>>
>> On Tue, Mar 12, 2024 at 7:17 PM Michael Lazin <mic...@gm...> wrote:
>>> Commercial EDR solutions like SentinelOne and Crowdstrike are better for
>>> business users who need protection against advanced threat actors, I know
>>> both use AWS IP addresses to report to an AI backend.  The AI engine is
>>> really just using statistical analysis.  Chkrootkit is another free offering
>>> but I think rkhunter is better as far as free tools.
>>>
>>> Michael Lazin
>>>
>>> ..              τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
>>>
>>>
>>> On Tue, Mar 12, 2024 at 6:25 PM <cal...@fa...> wrote:
>>>> What are people using instead?
>>>> _______________________________________________
>>>> Rkhunter-users mailing list
>>>> Rkh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>>> _______________________________________________
>>> Rkhunter-users mailing list
>>> Rkh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>> _______________________________________________
>> Rkhunter-users mailing list
>> Rkh...@li...
>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users

I've used rkhunter for quite some time & have found it useful,
but do use a number of other things as well. Much home grown.
 
As to support, I've reported a bug via the Fedora bugzilla &
it was fixed.

	2020/06/27 - sshd_config -
			https://bugzilla.redhat.com/show_bug.cgi?id=1851620

and one that had already been fixed (use of egrep) but these were triggered by
changes in the way sshd config files were arranged & egrep was being
discouraged in favour or grep -E (same for fgrep/grep -F ...) & stray escapes.

If you look at,

	https://sourceforge.net/p/rkhunter/bugs/

there are the open bugs. Pick one & fix it

Likely the maintainer needs help, which means some young blood.
But as I recall from many years ago before I retired, young blood
actually caused me too many problems explaining why certain code was the way
it was from 30 years before & that if they wanted to rewrite something from
scratch that worked be my guest... they soon lost interest sadly.

Look at the user profiles of the maintainers, particularly, jhorne the
primary maintainer) & the comments there, as well as comments on many of the
open bugs.
Also jhorne's activity to see what was done & the needs...

John Horne: It appears both dogsbody & unspawn are no longer involved/responding
is that right?

I thought I'd look at doing something from the rkhunter bug list & picked the
oldest bug, permissions on rkhunter tmp files (I realise I need a longer life
expectancy, less grandchildren & slightly less travel addicted travel partner)
but as a suggestion would a start on that not be a much more restrictive
umask? (& see if Christoph Anton Mitterer <cal...@sc...> is happy
with that - as he submitted it in 2010! ;-)

Cheers

John

On Tue, 2024-03-12 at 19:50 -0400, r3doubt wrote:
> I have found rkhunter useful, especially for quick triage or auditing and
> hardening to create a baseline configuration.  I wouldn't rely on static
> signatures for any sort of malware analysis or DFIR, regardless of OS or
> product.  
> 
> For a continuous monitoring EDR use case, I would recommend two free and open-
> source solutions, as an alternative to commercial offerings.  I have found
> OSQuery to be a pretty useful tool on MacOS and Linux, giving me some of the
> same EDR via native logs I get using Sysmon and Windows Event Logs on Windows
> boxes.  For dealing with "live off the land" style intrusions, this type of
> data is crucial for EDR.    OSQuery will look at things like syslog, but will
> limit the info reported to a DIF on changes to certain logs or settings which
> are stored in SQL style relational DB.  You can set custom monitoring in a
> syntax similar to SQL.  I've been a "certified product engineer" for major
> vendors, and even contributed to some of their work on things like security
> orchestration, but you can't "buy" security, regardless of the product, comes
> down to putting in the work.
> 
> You can also install an instance of Security Onion, and run it as either a
> distributed instance for enterprise use, or in the standalone mode for the
> student, hobbyist, SoHo network.  It can be set to pull your native logs from
> Linux, and do a lot of ingest and normalization for you, giving you a pretty
> nice dashboard and SOC environment based in Kibana (it runs on ELK stack).  It
> can also work, out of the box, with OSQuery on your Linux endpoints. 
> 
> Don't forget about NIST either.  NIST, CISA, NSA, and GCHQ (UK) have all put
> out various public hardening guides and even open-sourced auditing and
> hardening scripts for Linux / Unix systems to help automate configurations.
> 
> -R3doubt
> 
> On Tue, Mar 12, 2024 at 7:17 PM Michael Lazin <mic...@gm...> wrote:
> > Commercial EDR solutions like SentinelOne and Crowdstrike are better for
> > business users who need protection against advanced threat actors, I know
> > both use AWS IP addresses to report to an AI backend.  The AI engine is
> > really just using statistical analysis.  Chkrootkit is another free offering
> > but I think rkhunter is better as far as free tools.  
> > 
> > Michael Lazin
> > 
> > ..              τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
> > 
> > 
> > On Tue, Mar 12, 2024 at 6:25 PM <cal...@fa...> wrote:
> > > What are people using instead? 
> > > _______________________________________________
> > > Rkhunter-users mailing list
> > > Rkh...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rkhunter-users
> > _______________________________________________
> > Rkhunter-users mailing list
> > Rkh...@li...
> > https://lists.sourceforge.net/lists/listinfo/rkhunter-users
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users

https://www.cisecurity.org/cis-benchmarks

This is useful too and much easier to implement than just going by NIST.
Thanks for the tip on OSQuery, I ran it on a Linux system and a Mac and it
appears powerful and useful.

Michael Lazin

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


On Tue, Mar 12, 2024 at 7:45 PM r3doubt <r3...@r3...> wrote:

> I have found rkhunter useful, especially for quick triage or auditing and
> hardening to create a baseline configuration.  I wouldn't rely on static
> signatures for any sort of malware analysis or DFIR, regardless of OS or
> product.
>
> For a continuous monitoring EDR use case, I would recommend two free and
> open-source solutions, as an alternative to commercial offerings.  I have
> found OSQuery to be a pretty useful tool on MacOS and Linux, giving me some
> of the same EDR via native logs I get using Sysmon and Windows Event Logs
> on Windows boxes.  For dealing with "live off the land" style intrusions,
> this type of data is crucial for EDR.    OSQuery will look at things like
> syslog, but will limit the info reported to a DIF on changes to certain
> logs or settings which are stored in SQL style relational DB.  You can set
> custom monitoring in a syntax similar to SQL.  I've been a "certified
> product engineer" for major vendors, and even contributed to some of their
> work on things like security orchestration, but you can't "buy" security,
> regardless of the product, comes down to putting in the work.
>
> You can also install an instance of Security Onion, and run it as either a
> distributed instance for enterprise use, or in the standalone mode for the
> student, hobbyist, SoHo network.  It can be set to pull your native logs
> from Linux, and do a lot of ingest and normalization for you, giving you a
> pretty nice dashboard and SOC environment based in Kibana (it runs on ELK
> stack).  It can also work, out of the box, with OSQuery on your Linux
> endpoints.
>
> Don't forget about NIST either.  NIST, CISA, NSA, and GCHQ (UK) have all
> put out various public hardening guides and even open-sourced auditing and
> hardening scripts for Linux / Unix systems to help automate configurations.
>
> -R3doubt
>
> On Tue, Mar 12, 2024 at 7:17 PM Michael Lazin <mic...@gm...>
> wrote:
>
>> Commercial EDR solutions like SentinelOne and Crowdstrike are better for
>> business users who need protection against advanced threat actors, I know
>> both use AWS IP addresses to report to an AI backend.  The AI engine is
>> really just using statistical analysis.  Chkrootkit is another free
>> offering but I think rkhunter is better as far as free tools.
>>
>> Michael Lazin
>>
>> .. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
>>
>>
>> On Tue, Mar 12, 2024 at 6:25 PM <cal...@fa...> wrote:
>>
>>> What are people using instead?
>>> _______________________________________________
>>> Rkhunter-users mailing list
>>> Rkh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>>>
>> _______________________________________________
>> Rkhunter-users mailing list
>> Rkh...@li...
>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>>
>

I have found rkhunter useful, especially for quick triage or auditing and
hardening to create a baseline configuration.  I wouldn't rely on static
signatures for any sort of malware analysis or DFIR, regardless of OS or
product.

For a continuous monitoring EDR use case, I would recommend two free and
open-source solutions, as an alternative to commercial offerings.  I have
found OSQuery to be a pretty useful tool on MacOS and Linux, giving me some
of the same EDR via native logs I get using Sysmon and Windows Event Logs
on Windows boxes.  For dealing with "live off the land" style intrusions,
this type of data is crucial for EDR.    OSQuery will look at things like
syslog, but will limit the info reported to a DIF on changes to certain
logs or settings which are stored in SQL style relational DB.  You can set
custom monitoring in a syntax similar to SQL.  I've been a "certified
product engineer" for major vendors, and even contributed to some of their
work on things like security orchestration, but you can't "buy" security,
regardless of the product, comes down to putting in the work.

You can also install an instance of Security Onion, and run it as either a
distributed instance for enterprise use, or in the standalone mode for the
student, hobbyist, SoHo network.  It can be set to pull your native logs
from Linux, and do a lot of ingest and normalization for you, giving you a
pretty nice dashboard and SOC environment based in Kibana (it runs on ELK
stack).  It can also work, out of the box, with OSQuery on your Linux
endpoints.

Don't forget about NIST either.  NIST, CISA, NSA, and GCHQ (UK) have all
put out various public hardening guides and even open-sourced auditing and
hardening scripts for Linux / Unix systems to help automate configurations.

-R3doubt

On Tue, Mar 12, 2024 at 7:17 PM Michael Lazin <mic...@gm...> wrote:

> Commercial EDR solutions like SentinelOne and Crowdstrike are better for
> business users who need protection against advanced threat actors, I know
> both use AWS IP addresses to report to an AI backend.  The AI engine is
> really just using statistical analysis.  Chkrootkit is another free
> offering but I think rkhunter is better as far as free tools.
>
> Michael Lazin
>
> .. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
>
>
> On Tue, Mar 12, 2024 at 6:25 PM <cal...@fa...> wrote:
>
>> What are people using instead?
>> _______________________________________________
>> Rkhunter-users mailing list
>> Rkh...@li...
>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>

Commercial EDR solutions like SentinelOne and Crowdstrike are better for
business users who need protection against advanced threat actors, I know
both use AWS IP addresses to report to an AI backend.  The AI engine is
really just using statistical analysis.  Chkrootkit is another free
offering but I think rkhunter is better as far as free tools.

Michael Lazin

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


On Tue, Mar 12, 2024 at 6:25 PM <cal...@fa...> wrote:

> What are people using instead?
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>

What are people using instead? 

I would not rely on rkhunter to find the most sophisticated threat actors,
I have pointed out a few times that it does not check the kernel hash or
kernel modules at all but in defense of the project I like to run it on
newly installed systems to get a baseline, if there is a change down the
road it is easier to spot if you have a baseline from running it at
first install.

Michael Lazin

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


On Tue, Mar 12, 2024 at 4:46 AM rkhunter.yih68--- via Rkhunter-users <
rkh...@li...> wrote:

> Hello,
>
> I have been using for a while RKhunter but I realized that there is not
> any update since February 2018, which means 6 years ago.
>
> Is this project still alive and under development or has it become
> outdated? My concern is that 6 years in IT, specially in the security area,
> looks too risky for me without updates.
>
>
> Regards,
> David
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>

Hello,

I have been using for a while RKhunter but I realized that there is not any update since February 2018, which means 6 years ago.

Is this project still alive and under development or has it become outdated? My concern is that 6 years in IT, specially in the security area, looks too risky for me without updates.

Regards,
David

On Tue, 2024-02-06 at 16:12 +1100, John Dodson wrote:
> Hi Guys,
> I just found time to think about rkhunter again, & realise the last update
> via fedora was for,
>
>       Version     : 1.4.6
>       Release     : 22.fc39
>       Build Date  : Sat 22 Jul 2023 03:14:29
>
> Did we make any progress on transition?
> & particularly was there any answer to the question below?
>
From the 1.4.6 changelog:

Added the 'Diamorphine LKM' test.


John.



> Cheers
>
> John
>
>
> On Sun, 2023-12-10 at 22:17 +0200, Brent Clark wrote:
> > Good day Guys
> >
> > I came across this
> >
> > https://arstechnica.com/security/2023/12/stealthy-linux-rootkit-found-in-the-wild-after-going-undetected-for-2-years/
> >
> > Does rkhunter can detect / scan for
> >
> >      Diamorphine
> >      Suterusu
> >      Rooty
> >
> > Regards
> > Brent
> >
> >
> >
> > _______________________________________________
> > Rkhunter-users mailing list
> > Rkh...@li...
> > https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
________________________________
[https://www.plymouth.ac.uk/images/email_footer.gif]<" rel="nofollow">http://www.plymouth.ac.uk/worldclass>

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.

   - The rootkit can hook the `kill()` syscall, network-related functions,
   and file listing operations in order to hide its activities and evade
   detection.

This should theoretically change the hash of the "kill" command leading to
detection as a generic rootkit.  The link you shared shows that this
rootkit is a kernel module.  Rkhunter does not check kernel modules by
default but this would be a great feature.

Thank you,

Michael Lazin

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


On Sun, Dec 10, 2023 at 3:23 PM Brent Clark <bre...@gm...>
wrote:

> Good day Guys
>
> I came across this
>
>
> https://arstechnica.com/security/2023/12/stealthy-linux-rootkit-found-in-the-wild-after-going-undetected-for-2-years/
>
> Does rkhunter can detect / scan for
>
>      Diamorphine
>      Suterusu
>      Rooty
>
> Regards
> Brent
>
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>

Hi Guys,
I just found time to think about rkhunter again, & realise the last update
via fedora was for,

	Version     : 1.4.6
	Release     : 22.fc39
	Build Date  : Sat 22 Jul 2023 03:14:29

Did we make any progress on transition?
& particularly was there any answer to the question below?

Cheers

John


On Sun, 2023-12-10 at 22:17 +0200, Brent Clark wrote:
> Good day Guys
> 
> I came across this
> 
> https://arstechnica.com/security/2023/12/stealthy-linux-rootkit-found-in-the-wild-after-going-undetected-for-2-years/
> 
> Does rkhunter can detect / scan for
> 
>      Diamorphine
>      Suterusu
>      Rooty
> 
> Regards
> Brent
> 
> 
> 
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Good day Guys

I came across this

https://arstechnica.com/security/2023/12/stealthy-linux-rootkit-found-in-the-wild-after-going-undetected-for-2-years/

Does rkhunter can detect / scan for

     Diamorphine
     Suterusu
     Rooty

Regards
Brent

I too would like to see this move forward. Looking at chkrootkit it does
not seem
to do the same thing as rkhunter .

I would be willing to TEST any new releases.

-Ken


On Thu, Nov 30, 2023 at 4:38 PM Dan Benton via Rkhunter-users <
rkh...@li...> wrote:

>
> Attempting to keep this rolling...
>
> I would also be interested in helping keep rkhunter going.
>
> We still use rkhunter as part of our suite of protection on around 150
> servers and run https://rkhmirror.dogsbody.com/ for the times that
> sourceforge goes down.
>
> I'd be very happy to help support it's transition, even if just to keep
> things ticking over as new distributions are released :-)
>
> How can we (all) make this happen?
>
> Thank you again to John, unspawn and all the contributors
>
> Dan
>
>
> On 28/11/2023 05:38, John Dodson wrote:
> > Hi John  & Mark,
> >
> > I'd also like to give a vote of thanks to John Horne for his efforts on
> the
> > rkhunter project.
> >
> > Personally I "retired" almost 10 years ago now so it's unlikely that I'd
> be
> > able to take on the project.
> >
> > Obviously we do need some young blood if rkhunter is to continue.
> >
> > Mark, you've included comments I made long ago, & I was no longer
> confused
> > after a conversation with John Horne around that time & the fedora people
> > doing a build.
> >
> > I am about to update a machine to FC39, so I'll see what effect that has.
> > Currently FC38 is at rkhunter-1.4.6-21.fc38.noarch.
> >
> > The bug I originally reported in fedora bugzilla was,
> >
> >       https://bugzilla.redhat.com/show_bug.cgi?id=1851620
> >
> > & it ends with,
> >
> >       Fixed In Version: rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33
> >       -> rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33
> rkhunter-1.4.6-10.fc32
> >
> >
> > If John Horne does make a new release can we include the version number
> at the
> > start of the /usr/bin/rkhunter shell script & some historical commentary?
> > (What's there now is dated 2017!)
> >
> >
> > Cheers
> >
> > John
> >
> >
> >
> >
> > On Mon, 2023-11-27 at 09:35 -0500, Mark Stosberg wrote:
> >> I found that the note you don't plan to support rkhunter going forward:
> >> https://sourceforge.net/p/rkhunter/support-requests/74/
> >>
> >> Thank you for the time you put into rkhunter and supporting it for as
> long as you did.  It's completely fair for someone else to pick up the
> maintenance torch at this point.
> >>
> >> As you mention in that message, version 1.4.7 is stable. Given that,
> could you be willing to make a final release from what's in Sourceforge?
> >>
> >> Doing so would be an opportunity to add a clear note to the changelog
> that you no longer plan to maintain it, adding a call for new maintainers
> there. That may get the attention of some people who didn't find the
> maintenance status note in the bug tracker or this mailing list.
> >>
> >>         Mark
> >>
> >> On Thu, Mar 2, 2023 at 11:12 AM Mark Stosberg <ma...@ri...>
> wrote:
> >>>>   so I'm confused as to what's going on. (I'm not a developer on it)
> >>>>
> >>>
> >>>> Can anyone shed light?
> >>>>
> >>>
> >>> Distros distribute patched versions of software. So when you see a
> version of  rkhunter-1.4.6-18, that means they've made 18 releases of the
> 1.4.6. You reported a bug about this to Fedora in 2020, and Fedora released
> a fix for it in their 1.4.6-10 release.
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1851620
> >>>
> >>> Independently, the bug was discovered and reported by a Ubuntu user to
> their bug tracker in 2021, but never fixed in Ubuntu releases:
> >>> https://bugs.launchpad.net/debian/+source/rkhunter/+bug/1911014
> >>>
> >>> That's why we are both using "1.4.6", yet you have the fix in your
> RPM, but I don't have it on Ubuntu. Instead, I've now written a bit of
> Ansible code for my internal team to apply the patch that's in the rkhunter
> repo for this issue until the next release is made.
> >>>
> >>> It would be a lot less work overall if the fix was in an official
> release, rather than having people using various distributions finding and
> patching the independently in downstream packages or in private corporate
> repos.
> >>>
> >>> Here's the patch I applied:
> >>>
> >>> +--- a/files/rkhunter
> >>> ++++ b/files/rkhunter
> >>> +@@ -18422,20 +18422,49 @@
> >>> +
> >>> +
> >>> + #
> >>> ++ # Where possible we will use the 'sshd -T' command to obtain SSH
> >>> ++ # configuration values. The command will handle any configuration
> >>> ++ # sub-directories as well as 'Match' clauses. If the command is
> >>> ++ # not available, then we simply use the old method of checking
> >>> ++ # the main configuration file.
> >>> ++ #
> >>> ++
> >>> ++ USE_SSHDT=0
> >>> ++ SSHD_CMD=`find_cmd sshd`
> >>> ++
> >>> ++ if [ -n "${SSHD_CMD}" ]; then
> >>> ++ ${SSHD_CMD} -T >/dev/null 2>&1
> >>> ++ test $? -eq 0 && USE_SSHDT=1
> >>> ++ fi
> >>> ++
> >>> ++ if [ $USE_SSHDT -eq 1 ]; then
> >>> ++ display --to LOG --type INFO FOUND_CMD 'sshd' "${SSHD_CMD} -T"
> >>> ++ fi
> >>> ++
> >>> ++ #
> >>> + # Now we check some of the configuration options.
> >>> + #
> >>> + # First we check for allowed root access.
> >>> + #
> >>> +
> >>> +- RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}"
> 2>/dev/null | tail ${TAIL_OPT}1`
> >>> +-
> >>> +- if [ -n "${RKHTMPVAR}" ]; then
> >>> +- #
> >>> +- # Get the value that has been set.
> >>> +- #
> >>> +-
> >>> +- RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^
> #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'`
> >>> +-
> >>> ++ RKHTMPVAR=""
> >>> ++ RKHTMPVAR2=""
> >>> ++
> >>> ++ if [ $USE_SSHDT -eq 1 ]; then
> >>> ++ RKHTMPVAR2=`${SSHD_CMD} -T -C user=root,host=* 2>/dev/null |
> ${AWK_CMD} '{ IGNORECASE=1; if (/^PermitRootLogin /) print tolower($2); }'
> 2>/dev/null`
> >>> ++ else
> >>> ++ RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}"
> 2>/dev/null | tail ${TAIL_OPT}1`
> >>> ++
> >>> ++ if [ -n "${RKHTMPVAR}" ]; then
> >>> ++ #
> >>> ++ # Get the value that has been set.
> >>> ++ #
> >>> ++
> >>> ++ RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^
> #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'`
> >>> ++ fi
> >>> ++ fi
> >>> ++
> >>> ++ if [ -n "${RKHTMPVAR2}" ]; then
> >>> + if [ "${RKHTMPVAR2}" = "${ALLOW_SSH_ROOT_USER}" ]; then
> >>> + test "${RKHTMPVAR2}" = "no" && RKHTMPVAR="NOT_ALLOWED" ||
> RKHTMPVAR="ALLOWED"
> >>> + display --to SCREEN+LOG --type PLAIN --result ${RKHTMPVAR} --color
> GREEN --log-indent 2 --screen-indent 4 SYSTEM_CONFIGS_SSH_ROOT
> >>> +@@ -21050,6 +21080,8 @@
> >>> + ALLOW_SSH_PROT_V1=0
> >>> + ALLOW_SSH_ROOT_USER=""
> >>> + SSH_CONFIG_DIR=""
> >>> ++# This SSH option is only set within the program.
> >>> ++USE_SSHDT=0
> >>> +
> >>> + # These syslog options can only be set in the configuration file.
> >>> + ALLOW_SYSLOG_REMOTE_LOGGING=0
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Wed, 2023-03-01 at 15:32 -0500, Mark Stosberg wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I was just tracking down a warning was getting "PermitRootLogin No"
> errors,
> >>>>> and found the the bug was found in 2020 and long ago patched
> upstream but not
> >>>>> released. It looks like there have been a lot of updates since 1.4.6
> and a new
> >>>>> release would be welcome. Thanks.
> >>>>>
> >>>> The version I'm using (Fedora 37) has a build date of Sat 23 Jul 2022
> 11:24:32
> >>>> (the RPM package rkhunter-1.4.6-18) & does include the changes I
> suggested to
> >>>> check the /etc/ssh/sshd_config.d/* files. (unless I changed myself,
> but I
> >>>> thought a fixed version was distributed in fedora)
> >>>>
> >>>> Sadly the /usr/bin/rkhunter script itself does not have a version
> number/date
> >>>> in it that would allow relatively easy comparison to the sourceforge
> version,
> >>>> which still seems to have a modified date of, 2018-02-20 which seems
> very old!
> >>>> (https://sourceforge.net/projects/rkhunter/files/) & not consistent
> with changes
> >>>> that are obviously there (my change suggestion was mid 2020)
> >>>>
> >>>> Yet there are changes shown in the Project activity,
> >>>> (https://sourceforge.net/projects/rkhunter/)
> >>>> so I'm confused as to what's going on. (I'm not a developer on it)
> >>>>
> >>>> Can anyone shed light?
> >>>> Would it be possible to have the version number in the header of the
> >>>> /usr/bin/rkhunter script? (for consistency?)
> >>>>
> >>>> & is there an easy way to prompt fedora to release a new version?
> >>>>
> >>>>>       Mark
> >>>>> _______________________________________________
> >>>>> Rkhunter-users mailing list
> >>>>> Rkh...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
> >>>
> >>> --
> >>> Mark Stosberg (he/him)
> >>> Director of Systems & Security
> >>> ma...@ri... | 765.277.1916
> >>> https://www.rideamigos.com
> >>> Changing the way the world commutes.
> >>>
> >>
> >> --
> >> Mark Stosberg (he/him)
> >> Director of Systems & Security
> >> ma...@ri... | 765.277.1916
> >> https://www.rideamigos.com
> >> Changing the way the world commutes.
> >>
> >> _______________________________________________
> >> Rkhunter-users mailing list
> >> Rkh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
> >
> >
> > _______________________________________________
> > Rkhunter-users mailing list
> > Rkh...@li...
> > https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>


-- 
End of line
JOB TERMINATED

Attempting to keep this rolling...

I would also be interested in helping keep rkhunter going.

We still use rkhunter as part of our suite of protection on around 150 
servers and run https://rkhmirror.dogsbody.com/ for the times that 
sourceforge goes down.

I'd be very happy to help support it's transition, even if just to keep 
things ticking over as new distributions are released :-)

How can we (all) make this happen?

Thank you again to John, unspawn and all the contributors

Dan


On 28/11/2023 05:38, John Dodson wrote:
> Hi John  & Mark,
>
> I'd also like to give a vote of thanks to John Horne for his efforts on the
> rkhunter project.
>
> Personally I "retired" almost 10 years ago now so it's unlikely that I'd be
> able to take on the project.
>
> Obviously we do need some young blood if rkhunter is to continue.
>
> Mark, you've included comments I made long ago, & I was no longer confused
> after a conversation with John Horne around that time & the fedora people
> doing a build.
>
> I am about to update a machine to FC39, so I'll see what effect that has.
> Currently FC38 is at rkhunter-1.4.6-21.fc38.noarch.
>
> The bug I originally reported in fedora bugzilla was,
>
> 	https://bugzilla.redhat.com/show_bug.cgi?id=1851620
>
> & it ends with,
>
> 	Fixed In Version: rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33
> 	-> rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33 rkhunter-1.4.6-10.fc32
>
>
> If John Horne does make a new release can we include the version number at the
> start of the /usr/bin/rkhunter shell script & some historical commentary?
> (What's there now is dated 2017!)
>
>
> Cheers
>
> John
>
>
>
>
> On Mon, 2023-11-27 at 09:35 -0500, Mark Stosberg wrote:
>> I found that the note you don't plan to support rkhunter going forward:
>> https://sourceforge.net/p/rkhunter/support-requests/74/
>>
>> Thank you for the time you put into rkhunter and supporting it for as long as you did.  It's completely fair for someone else to pick up the maintenance torch at this point.
>>
>> As you mention in that message, version 1.4.7 is stable. Given that, could you be willing to make a final release from what's in Sourceforge?
>>
>> Doing so would be an opportunity to add a clear note to the changelog that you no longer plan to maintain it, adding a call for new maintainers there. That may get the attention of some people who didn't find the maintenance status note in the bug tracker or this mailing list.
>>
>>         Mark
>>
>> On Thu, Mar 2, 2023 at 11:12 AM Mark Stosberg <ma...@ri...> wrote:
>>>>   so I'm confused as to what's going on. (I'm not a developer on it)
>>>>
>>>   
>>>> Can anyone shed light?
>>>>
>>>
>>> Distros distribute patched versions of software. So when you see a version of  rkhunter-1.4.6-18, that means they've made 18 releases of the 1.4.6. You reported a bug about this to Fedora in 2020, and Fedora released a fix for it in their 1.4.6-10 release.
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1851620
>>>
>>> Independently, the bug was discovered and reported by a Ubuntu user to their bug tracker in 2021, but never fixed in Ubuntu releases:
>>> https://bugs.launchpad.net/debian/+source/rkhunter/+bug/1911014
>>>
>>> That's why we are both using "1.4.6", yet you have the fix in your RPM, but I don't have it on Ubuntu. Instead, I've now written a bit of Ansible code for my internal team to apply the patch that's in the rkhunter repo for this issue until the next release is made.
>>>
>>> It would be a lot less work overall if the fix was in an official release, rather than having people using various distributions finding and patching the independently in downstream packages or in private corporate repos.
>>>
>>> Here's the patch I applied:
>>>
>>> +--- a/files/rkhunter
>>> ++++ b/files/rkhunter
>>> +@@ -18422,20 +18422,49 @@
>>> +
>>> +
>>> + #
>>> ++ # Where possible we will use the 'sshd -T' command to obtain SSH
>>> ++ # configuration values. The command will handle any configuration
>>> ++ # sub-directories as well as 'Match' clauses. If the command is
>>> ++ # not available, then we simply use the old method of checking
>>> ++ # the main configuration file.
>>> ++ #
>>> ++
>>> ++ USE_SSHDT=0
>>> ++ SSHD_CMD=`find_cmd sshd`
>>> ++
>>> ++ if [ -n "${SSHD_CMD}" ]; then
>>> ++ ${SSHD_CMD} -T >/dev/null 2>&1
>>> ++ test $? -eq 0 && USE_SSHDT=1
>>> ++ fi
>>> ++
>>> ++ if [ $USE_SSHDT -eq 1 ]; then
>>> ++ display --to LOG --type INFO FOUND_CMD 'sshd' "${SSHD_CMD} -T"
>>> ++ fi
>>> ++
>>> ++ #
>>> + # Now we check some of the configuration options.
>>> + #
>>> + # First we check for allowed root access.
>>> + #
>>> +
>>> +- RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}" 2>/dev/null | tail ${TAIL_OPT}1`
>>> +-
>>> +- if [ -n "${RKHTMPVAR}" ]; then
>>> +- #
>>> +- # Get the value that has been set.
>>> +- #
>>> +-
>>> +- RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^ #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'`
>>> +-
>>> ++ RKHTMPVAR=""
>>> ++ RKHTMPVAR2=""
>>> ++
>>> ++ if [ $USE_SSHDT -eq 1 ]; then
>>> ++ RKHTMPVAR2=`${SSHD_CMD} -T -C user=root,host=* 2>/dev/null | ${AWK_CMD} '{ IGNORECASE=1; if (/^PermitRootLogin /) print tolower($2); }' 2>/dev/null`
>>> ++ else
>>> ++ RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}" 2>/dev/null | tail ${TAIL_OPT}1`
>>> ++
>>> ++ if [ -n "${RKHTMPVAR}" ]; then
>>> ++ #
>>> ++ # Get the value that has been set.
>>> ++ #
>>> ++
>>> ++ RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^ #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'`
>>> ++ fi
>>> ++ fi
>>> ++
>>> ++ if [ -n "${RKHTMPVAR2}" ]; then
>>> + if [ "${RKHTMPVAR2}" = "${ALLOW_SSH_ROOT_USER}" ]; then
>>> + test "${RKHTMPVAR2}" = "no" && RKHTMPVAR="NOT_ALLOWED" || RKHTMPVAR="ALLOWED"
>>> + display --to SCREEN+LOG --type PLAIN --result ${RKHTMPVAR} --color GREEN --log-indent 2 --screen-indent 4 SYSTEM_CONFIGS_SSH_ROOT
>>> +@@ -21050,6 +21080,8 @@
>>> + ALLOW_SSH_PROT_V1=0
>>> + ALLOW_SSH_ROOT_USER=""
>>> + SSH_CONFIG_DIR=""
>>> ++# This SSH option is only set within the program.
>>> ++USE_SSHDT=0
>>> +
>>> + # These syslog options can only be set in the configuration file.
>>> + ALLOW_SYSLOG_REMOTE_LOGGING=0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Wed, 2023-03-01 at 15:32 -0500, Mark Stosberg wrote:
>>>>> Hello,
>>>>>
>>>>> I was just tracking down a warning was getting "PermitRootLogin No" errors,
>>>>> and found the the bug was found in 2020 and long ago patched upstream but not
>>>>> released. It looks like there have been a lot of updates since 1.4.6 and a new
>>>>> release would be welcome. Thanks.
>>>>>
>>>> The version I'm using (Fedora 37) has a build date of Sat 23 Jul 2022 11:24:32
>>>> (the RPM package rkhunter-1.4.6-18) & does include the changes I suggested to
>>>> check the /etc/ssh/sshd_config.d/* files. (unless I changed myself, but I
>>>> thought a fixed version was distributed in fedora)
>>>>
>>>> Sadly the /usr/bin/rkhunter script itself does not have a version number/date
>>>> in it that would allow relatively easy comparison to the sourceforge version,
>>>> which still seems to have a modified date of, 2018-02-20 which seems very old!
>>>> (https://sourceforge.net/projects/rkhunter/files/) & not consistent with changes
>>>> that are obviously there (my change suggestion was mid 2020)
>>>>
>>>> Yet there are changes shown in the Project activity,
>>>> (https://sourceforge.net/projects/rkhunter/)
>>>> so I'm confused as to what's going on. (I'm not a developer on it)
>>>>
>>>> Can anyone shed light?
>>>> Would it be possible to have the version number in the header of the
>>>> /usr/bin/rkhunter script? (for consistency?)
>>>>
>>>> & is there an easy way to prompt fedora to release a new version?
>>>>
>>>>>       Mark
>>>>> _______________________________________________
>>>>> Rkhunter-users mailing list
>>>>> Rkh...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>>>
>>> -- 
>>> Mark Stosberg (he/him)
>>> Director of Systems & Security
>>> ma...@ri... | 765.277.1916
>>> https://www.rideamigos.com
>>> Changing the way the world commutes.
>>>
>>
>> -- 
>> Mark Stosberg (he/him)
>> Director of Systems & Security
>> ma...@ri... | 765.277.1916
>> https://www.rideamigos.com
>> Changing the way the world commutes.
>>
>> _______________________________________________
>> Rkhunter-users mailing list
>> Rkh...@li...
>> https://lists.sourceforge.net/lists/listinfo/rkhunter-users
>
>
> _______________________________________________
> Rkhunter-users mailing list
> Rkh...@li...
> https://lists.sourceforge.net/lists/listinfo/rkhunter-users