rkhunter-users Mailing List for Rootkit Hunter
Brought to you by:
dogsbody
You can subscribe to this list here.
2006 |
Jan
(2) |
Feb
(2) |
Mar
(7) |
Apr
(5) |
May
(5) |
Jun
(7) |
Jul
(23) |
Aug
(17) |
Sep
(35) |
Oct
(138) |
Nov
(95) |
Dec
(84) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(140) |
Feb
(78) |
Mar
(28) |
Apr
(17) |
May
(78) |
Jun
(72) |
Jul
(49) |
Aug
(47) |
Sep
(74) |
Oct
(69) |
Nov
(50) |
Dec
(75) |
2008 |
Jan
(43) |
Feb
(80) |
Mar
(30) |
Apr
(29) |
May
(25) |
Jun
(14) |
Jul
(47) |
Aug
(11) |
Sep
(28) |
Oct
(17) |
Nov
(14) |
Dec
(66) |
2009 |
Jan
(54) |
Feb
(21) |
Mar
(22) |
Apr
(8) |
May
(4) |
Jun
(13) |
Jul
(10) |
Aug
(24) |
Sep
(1) |
Oct
(41) |
Nov
(17) |
Dec
(99) |
2010 |
Jan
(53) |
Feb
(19) |
Mar
(30) |
Apr
(28) |
May
(135) |
Jun
(34) |
Jul
(19) |
Aug
(24) |
Sep
(48) |
Oct
(4) |
Nov
(61) |
Dec
(17) |
2011 |
Jan
(23) |
Feb
(18) |
Mar
(14) |
Apr
(12) |
May
(23) |
Jun
(27) |
Jul
(57) |
Aug
(17) |
Sep
(25) |
Oct
(19) |
Nov
(9) |
Dec
(4) |
2012 |
Jan
(19) |
Feb
(5) |
Mar
(5) |
Apr
(17) |
May
(13) |
Jun
(21) |
Jul
(2) |
Aug
(10) |
Sep
(5) |
Oct
(5) |
Nov
(18) |
Dec
(4) |
2013 |
Jan
(23) |
Feb
(13) |
Mar
(5) |
Apr
(48) |
May
(38) |
Jun
(5) |
Jul
(19) |
Aug
(14) |
Sep
(10) |
Oct
(7) |
Nov
(19) |
Dec
(44) |
2014 |
Jan
(11) |
Feb
(11) |
Mar
(38) |
Apr
(36) |
May
(21) |
Jun
(13) |
Jul
(7) |
Aug
(21) |
Sep
(30) |
Oct
(3) |
Nov
|
Dec
(29) |
2015 |
Jan
(5) |
Feb
(5) |
Mar
(12) |
Apr
(5) |
May
(25) |
Jun
(11) |
Jul
(7) |
Aug
(8) |
Sep
(3) |
Oct
(15) |
Nov
(10) |
Dec
|
2016 |
Jan
(5) |
Feb
|
Mar
(6) |
Apr
(12) |
May
(2) |
Jun
(11) |
Jul
(8) |
Aug
(13) |
Sep
(15) |
Oct
(6) |
Nov
(21) |
Dec
(1) |
2017 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(3) |
May
(2) |
Jun
(30) |
Jul
(42) |
Aug
(8) |
Sep
(2) |
Oct
(24) |
Nov
(12) |
Dec
(14) |
2018 |
Jan
(7) |
Feb
(22) |
Mar
(8) |
Apr
(11) |
May
(28) |
Jun
(20) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(11) |
Dec
|
2019 |
Jan
(5) |
Feb
(11) |
Mar
(6) |
Apr
(5) |
May
(4) |
Jun
(4) |
Jul
(4) |
Aug
(8) |
Sep
(5) |
Oct
(7) |
Nov
(10) |
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(7) |
Nov
(3) |
Dec
(1) |
2021 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
(7) |
Jun
(2) |
Jul
(7) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(1) |
2024 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Landychev A. <ale...@bo...> - 2024-07-08 12:57:14
|
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<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! |
From: Dan B. <da...@do...> - 2024-03-17 12:43:11
|
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 |
From: <jwa...@gm...> - 2024-03-16 05:15:29
|
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 |
From: Michael L. <mic...@gm...> - 2024-03-13 01:21:06
|
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 >> > |
From: r3doubt <r3...@r3...> - 2024-03-13 00:17:41
|
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 > |
From: Michael L. <mic...@gm...> - 2024-03-12 23:15:35
|
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 > |
From: <cal...@fa...> - 2024-03-12 22:16:32
|
What are people using instead? |
From: Michael L. <mic...@gm...> - 2024-03-12 20:47:07
|
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 > |
From: <rkh...@si...> - 2024-03-12 08:39:03
|
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 |
From: John H. <joh...@pl...> - 2024-02-06 21:25:38
|
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]<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. |
From: Michael L. <mic...@gm...> - 2024-02-06 12:06:42
|
- 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 > |
From: John D. <jwa...@gm...> - 2024-02-06 05:13:08
|
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 |
From: Brent C. <bre...@gm...> - 2023-12-10 20:18:01
|
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 |
From: KenUnix <ken...@gm...> - 2023-11-30 22:23:11
|
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 |
From: Dan B. <da...@do...> - 2023-11-30 21:33:24
|
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 |
From: John D. <jwa...@gm...> - 2023-11-28 05:38:21
|
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 |
From: Mark S. <ma...@ri...> - 2023-11-27 16:28:29
|
John Horne, 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 <https://rideamigos.com/> > > Changing the way the world commutes. > > > <https://www.linkedin.com/company/rideamigos> > <https://www.twitter.com/rideamigos> <https://www.facebook.com/rideamigos> > <https://www.instagram.com/rideamigos> > <https://rideamigos.com/newsletter-sign-up/> > -- *Mark Stosberg* (he/him) Director of Systems & Security ma...@ri... | 765.277.1916 https://www.rideamigos.com <https://rideamigos.com/> Changing the way the world commutes. <https://www.linkedin.com/company/rideamigos> <https://www.twitter.com/rideamigos> <https://www.facebook.com/rideamigos> <https://www.instagram.com/rideamigos> <https://rideamigos.com/newsletter-sign-up/> |
From: wm1n <wm...@pr...> - 2023-10-16 18:19:25
|
So I found on YouTube the procedure to make this work. Now when I run rkhunter --update, it does an actual update. https://www.youtube.com/watch?v=uPj94tTckMw Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Monday, October 16th, 2023 at 6:43 AM, konstantinos dimos <kon...@ho...> wrote: > When i run rkhunter --update i get the following > checking file mirrors.dat [skipped] > checking file programs-bad.dat [update-failed] > checking file backdoorports.dat [update-failed] > checking file suspscan.dat [update-failed] > checking file i18n.versions [update-failed] > > tried many thngs but with no success, any suggestion? > > konstantinos Dimos |
From: wm1n <wm...@pr...> - 2023-10-16 13:28:01
|
When i run rkhunter --update i get Invalid WEB_CMD configuration option: Relative pathname: "/bin/false" Am a newbee to rkhunter so I may or may not even have it configured correctly. Any suggestions would be helpful. Alan Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Monday, October 16th, 2023 at 6:43 AM, konstantinos dimos <kon...@ho...> wrote: > When i run rkhunter --update i get the following > checking file mirrors.dat [skipped] > checking file programs-bad.dat [update-failed] > checking file backdoorports.dat [update-failed] > checking file suspscan.dat [update-failed] > checking file i18n.versions [update-failed] > > tried many thngs but with no success, any suggestion? > > konstantinos Dimos |
From: konstantinos d. <kon...@ho...> - 2023-10-16 10:44:08
|
When i run rkhunter --update i get the following checking file mirrors.dat [skipped] checking file programs-bad.dat [update-failed] checking file backdoorports.dat [update-failed] checking file suspscan.dat [update-failed] checking file i18n.versions [update-failed] tried many thngs but with no success, any suggestion? konstantinos Dimos |
From: Michael L. <mic...@gm...> - 2023-03-21 23:30:27
|
It would improve rkhunter if it could take the hash of the kernel binary. Since drivers are loaded externally as modules there is no reason that you can't check the compiled kernel against the hash it is supposed to have. Thank you, Michael Lazin .. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι. |
From: Mark S. <ma...@ri...> - 2023-03-02 16:38:09
|
> > 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 <https://rideamigos.com/> Changing the way the world commutes. <https://www.linkedin.com/company/rideamigos> <https://www.twitter.com/rideamigos> <https://www.facebook.com/rideamigos> <https://www.instagram.com/rideamigos> <https://rideamigos.com/newsletter-sign-up/> |
From: John L. <jle...@ou...> - 2023-03-02 15:53:36
|
The latest in Debian testing is at https://tracker.debian.org/pkg/rkhunter and is 1.4.6-11. On 3/2/2023 6:49 AM, John Dodson wrote: > 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 > > Cheers > > John > > > > > _______________________________________________ > Rkhunter-users mailing list > Rkh...@li... > https://lists.sourceforge.net/lists/listinfo/rkhunter-users |
From: John D. <jwa...@gm...> - 2023-03-02 11:49:40
|
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 Cheers John |
From: Mark S. <ma...@ri...> - 2023-03-01 22:18:39
|
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. Mark |