(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted": - - - - - - [snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]: - - - - - - I got the same thing both before and after "dnf upgrade". rkhunter made no mention of "wted".
I tried to find what "wted" is: - - - - - - bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST. Error: No matching Packages to list bash.9[~]: - - - - - - duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
home user via users wrote:
(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted":
[snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]:
I got the same thing both before and after "dnf upgrade". rkhunter made no me ntion of "wted".
I tried to find what "wted" is:
bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local /bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST . Error: No matching Packages to list bash.9[~]:
duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
You didn't try but I did:
# dnf provides */wted No matches found.
Sorry, no answer to your real question.
On 2/13/25 1:00 PM, Dave Close wrote:
home user via users wrote:
(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted":
[snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]:
I got the same thing both before and after "dnf upgrade". rkhunter made no me ntion of "wted".
I tried to find what "wted" is:
bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local /bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST . Error: No matching Packages to list bash.9[~]:
duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
You didn't try but I did:
# dnf provides */wted No matches found.
Sorry, no answer to your real question.
Thank-you, Dave.
On 13 Feb 2025, at 17:51, home user via users users@lists.fedoraproject.org wrote:
When I ran chkrootkit
I cannot find evidence of this tool being maintained. But I did find people saying its reports contain false positives.
Barry
On 2/13/25 1:15 PM, Barry wrote:
On 13 Feb 2025, at 17:51, home user via users users@lists.fedoraproject.org wrote:
When I ran chkrootkit
I cannot find evidence of this tool being maintained. But I did find people saying its reports contain false positives.
Barry
Thank-you, Barry. I "patch" weekly. dnf says this tool was last patched on my workstation on Dec. 12, 2023.
dnf says I have version 0,47, It's in the @System repository, from fedora repo.
The tool's webpage says there is a 0.58b, released on July 05, 2023. So our repository does seem behind, and it does seem the tool is being maintained slowly if still at all.
This morning on the web, I did see that chkrootkit is prone to false positives. I've seen that with the tool's check of "lkm".
On Feb 13, 2025, at 12:51, home user via users users@lists.fedoraproject.org wrote:
(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted":
[snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]:
I got the same thing both before and after "dnf upgrade". rkhunter made no mention of "wted".
I tried to find what "wted" is:
bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST. Error: No matching Packages to list bash.9[~]:
duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
The “wted” function in the chkrootkit script runs “chwtmp -f /var/log/wtmp` (the executable is part of the package and might not be on your path)
What I think it’s doing is identifying time periods that appear to have been removed from the wtmp file, which is a binary log file that is updated every time you log in and out. The “last” command reads it, for example. A potentially compromised system might have the malicious login wiped from the file, although I’ve never seen that.
This checker was written many years ago and I have no idea how accurate it is with modern tools and the current structure of that file. The chkrootkit code isn’t in any useful code repository so who knows what is going on there.
Hope that helps.
On 2/13/25 2:40 PM, Jonathan Billings wrote:
On Feb 13, 2025, at 12:51, home user via users users@lists.fedoraproject.org wrote:
(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted":
[snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]:
I got the same thing both before and after "dnf upgrade". rkhunter made no mention of "wted".
I tried to find what "wted" is:
bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST. Error: No matching Packages to list bash.9[~]:
duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
The “wted” function in the chkrootkit script runs “chwtmp -f /var/log/wtmp` (the executable is part of the package and might not be on your path)
What I think it’s doing is identifying time periods that appear to have been removed from the wtmp file, which is a binary log file that is updated every time you log in and out. The “last” command reads it, for example. A potentially compromised system might have the malicious login wiped from the file, although I’ve never seen that.
This checker was written many years ago and I have no idea how accurate it is with modern tools and the current structure of that file. The chkrootkit code isn’t in any useful code repository so who knows what is going on there.
Hope that helps.
Thank-you Jonathan.
Is there a way of checking for outside connections during the time periods being reported?
On 2/13/25 3:11 PM, home user via users wrote:
On 2/13/25 2:40 PM, Jonathan Billings wrote:
On Feb 13, 2025, at 12:51, home user via users users@lists.fedoraproject.org wrote:
[snip]
What is "wted", and is there a security problem?
The “wted” function in the chkrootkit script runs “chwtmp -f /var/log/wtmp` (the executable is part of the package and might not be on your path)
What I think it’s doing is identifying time periods that appear to have been removed from the wtmp file, which is a binary log file that is updated every time you log in and out. The “last” command reads it, for example. A potentially compromised system might have the malicious login wiped from the file, although I’ve never seen that.
This checker was written many years ago and I have no idea how accurate it is with modern tools and the current structure of that file. The chkrootkit code isn’t in any useful code repository so who knows what is going on there.
Hope that helps.
Thank-you Jonathan.
Is there a way of checking for outside connections during the time periods being reported?
"Something inside me" suggested I try the "last" command, even though what you said suggested wtmp might be corrupted. I did so. For some unknown reason, booting this workstation sometimes fails to result in a login screen; it just goes black. I have to hit the tower's reset button. It often takes 2 boots, occasionally 3, to get a login screen. I've not been able to discern a pattern to this. In the output to "last", I can see when those multiple boots happened. The wted messages in the chkrootkit output all coincide with when it took 2 or 3 boots to get a login screen, though most multiple boots that did not correspond to wted messages in the chkrootkit output. I'm now thinking the wted messages are not a security issue, but I'm not certain.
On 14/2/25 10:17, home user via users wrote:
On 2/13/25 3:11 PM, home user via users wrote:
On 2/13/25 2:40 PM, Jonathan Billings wrote:
On Feb 13, 2025, at 12:51, home user via users users@lists.fedoraproject.org wrote:
[snip]
What is "wted", and is there a security problem?
The “wted” function in the chkrootkit script runs “chwtmp -f /var/log/wtmp` (the executable is part of the package and might not be on your path)
What I think it’s doing is identifying time periods that appear to have been removed from the wtmp file, which is a binary log file that is updated every time you log in and out. The “last” command reads it, for example. A potentially compromised system might have the malicious login wiped from the file, although I’ve never seen that.
This checker was written many years ago and I have no idea how accurate it is with modern tools and the current structure of that file. The chkrootkit code isn’t in any useful code repository so who knows what is going on there.
Hope that helps.
Thank-you Jonathan.
Is there a way of checking for outside connections during the time periods being reported?
"Something inside me" suggested I try the "last" command, even though what you said suggested wtmp might be corrupted. I did so. For some unknown reason, booting this workstation sometimes fails to result in a login screen; it just goes black. I have to hit the tower's reset button. It often takes 2 boots, occasionally 3, to get a login screen. I've not been able to discern a pattern to this. In the output to "last", I can see when those multiple boots happened. The wted messages in the chkrootkit output all coincide with when it took 2 or 3 boots to get a login screen, though most multiple boots that did not correspond to wted messages in the chkrootkit output. I'm now thinking the wted messages are not a security issue, but I'm not certain.
Just out of curiosity I issued "sudo chkrootkit" and the only message I got relative to wted was the following (I've just done a 438 package update in F41 as its been a couple of weeks since I've logged into linux and done an update):
Checking `wted'... chkwtmp: nothing deleted
regards, Steve
On Thu, 2025-02-13 at 10:50 -0700, home user via users wrote:
When I ran chkrootkit, I got the following (including a few lines of context) regarding
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
Unlike Windows, our mail clients don't automatically run executables that have been attached to emails, etc. You have to choose to run executables.
On 2/13/25 7:33 PM, Tim wrote:
On Thu, 2025-02-13 at 10:50 -0700, home user via users wrote:
When I ran chkrootkit, I got the following (including a few lines of context) regarding
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
Unlike Windows, our mail clients don't automatically run executables that have been attached to emails, etc. You have to choose to run executables.
Maybe I'm remembering wrong, but I recall over a decade ago being advised on this list to use 2 tools to watch for malware on this workstation: chkrootkit and rkhunter. (I was also advised that those tools are not perfect.) Being not an IT professional, and trusting that those list members that do the helping are experienced professionals (though not perfect), I live by that advice and run both tools weekly. Also, don't these tools check for more than just rootkits?
By the way, I notice that rkhunter was last patched on my workstation in June of 2022. But its webpage show its last update to be March of 2024. Our repository almost a year behind on this?
On 13 Feb 2025 at 20:39, home user via users wrote:
Date sent: Thu, 13 Feb 2025 20:39:23 -0700 Subject: Re: security: wted? To: Community support for Fedora users users@lists.fedoraproject.org Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: home user via users users@lists.fedoraproject.org Copies to: home user mattisonw@comcast.net
On 2/13/25 7:33 PM, Tim wrote:
On Thu, 2025-02-13 at 10:50 -0700, home user via users wrote:
When I ran chkrootkit, I got the following (including a few lines of context) regarding
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
Unlike Windows, our mail clients don't automatically run executables that have been attached to emails, etc. You have to choose to run executables.
J> Maybe I'm remembering wrong, but I recall over a decade ago being advised on this list to use 2 tools to watch for malware on this workstation: chkrootkit and rkhunter. (I was also advised that those tools are not perfect.) Being not an IT professional, and trusting that those list members that do the helping are experienced professionals (though not perfect), I live by that advice and run both tools weekly. Also, don't these tools check for more than just rootkits?
Shows a slightly newer version. chkrootkit 0.58b is now available! (Release Date: Jul 05 2023) https://chkrootkit.org/download/ ftp://ftp.chkrootkit.org/pub/seg/pac/chkrootkit.tar.gz Link is to ftp, but firefox doesn't seem to to that anymore so did ncftpget ftp://ftp.chkrootkit.org/pub/seg/pac/chkrootkit.tar.gz .
then tar -xvf chkrootkit.tar.gz cd chkrootkit-0.58b/
The directory has files, but only the chkrootkit as an executible shell script. Running make create the files with todays date. 2531 Feb 24 2023 strings.c 1292 Feb 24 2023 README.chkwtmp 1323 Feb 24 2023 README.chklastlog 1637 Feb 24 2023 Makefile 5965 Feb 24 2023 chkutmp.c 10057 Feb 24 2023 chkproc.c 7376 Feb 24 2023 chkdirs.c 7195 Feb 24 2023 check_wtmpx.c 5210 Jun 23 2023 ACKNOWLEDGMENTS 1337 Jun 29 2023 COPYRIGHT 7833 Jun 29 2023 chklastlog.c 9011 Jun 29 2023 ifpromisc.c 15638 Jun 29 2023 README 2283 Jun 29 2023 chkwtmp.c 582 Jun 29 2023 chkrootkit.lsm 88420 Jul 6 2023 chkrootkit These created by make. 15104 Feb 14 15:51 chklastlog 15024 Feb 14 15:51 chkwtmp 15176 Feb 14 15:51 ifpromisc 15216 Feb 14 15:51 chkproc 15080 Feb 14 15:51 chkdirs 14832 Feb 14 15:51 check_wtmpx 748544 Feb 14 15:51 strings-static 15088 Feb 14 15:51 chkutmp
Then run the ./chkrootkit to test it.
The chkrootkit that the dnf installs is 0.57 is in /usr/lib64/chkrootkit-0.57 and has these files. 725888 Jan 23 2024 strings-static 14 Jan 23 2024 strings -> strings-static 16048 Jan 23 2024 ifpromisc 15824 Jan 23 2024 chkwtmp 15992 Jan 23 2024 chkutmp 87233 Jan 23 2024 chkrootkit 16032 Jan 23 2024 chkproc 15928 Jan 23 2024 chklastlog 16032 Jan 23 2024 chkdirs 15968 Jan 23 2024 check_wtmpx 0 Feb 14 04:20 1
So not clear who makes the rpm to install them in that way.
Ran the 0.57 and the 0.58 and redirected output to files. Then compared, and differences were 22c22 < Checking `inetd'... not found ---
Checking `inetd'... not tested
119a120,121
Searching for Tsunami DDoS Malware.. nothing found Searching for Linux BPF Door.. nothing found
178,180c180,182 < ! root 905650 pts/0 /usr/bin/sh /usr/lib64/chkrootkit-0.57/chkrootkit < ! root 906780 pts/0 ./chkutmp < ! root 906781 pts/0 ps ax -o tty,pid,ruser,args ---
! root 906789 pts/0 /bin/sh ./chkrootkit ! root 907932 pts/0 ./chkutmp ! root 907933 pts/0 ps ax -o tty,pid,ruser,args
So looks like 0.58 has some added things.
rkhunter seems to have the same version as sourceforge site.
By the way, I notice that rkhunter was last patched on my
workstation in June of 2022. But its webpage show its last update to be March of 2024. Our repository almost a year behind on this?
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com mailto:msetzerii@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 2/13/25 11:15 PM, Michael D. Setzer II wrote:
On 13 Feb 2025 at 20:39, home user via users wrote:
[snip]
So looks like 0.58 has some added things.
rkhunter seems to have the same version as sourceforge site.
Thank-you Michael.
My information came from "dnf history" and the tools' websites.
By the way, I notice that rkhunter was last patched on my
workstation in June of 2022. But its webpage show its last update to be March of 2024. Our repository almost a year behind on this?
On 2/13/25 7:39 PM, home user via users wrote:
On 2/13/25 7:33 PM, Tim wrote:
On Thu, 2025-02-13 at 10:50 -0700, home user via users wrote:
When I ran chkrootkit, I got the following (including a few lines of context) regarding
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
Unlike Windows, our mail clients don't automatically run executables that have been attached to emails, etc. You have to choose to run executables.
Maybe I'm remembering wrong, but I recall over a decade ago being advised on this list to use 2 tools to watch for malware on this workstation: chkrootkit and rkhunter. (I was also advised that those tools are not perfect.) Being not an IT professional, and trusting that those list members that do the helping are experienced professionals (though not perfect), I live by that advice and run both tools weekly. Also, don't these tools check for more than just rootkits?
That was a very long time ago and even if it was valid advice then, it isn't now.
By the way, I notice that rkhunter was last patched on my workstation in June of 2022. But its webpage show its last update to be March of 2024. Our repository almost a year behind on this?
rkhunter hasn't had a new release since 2018. I don't know where you're seeing something from 2024.
chkrootkit has a release in 2023, but that's a beta. They're still providing downloads over ftp!
Those tools are not going to provide any useful help.
On Thu, 2025-02-13 at 23:32 -0800, Samuel Sieb wrote:
Those tools are not going to provide any useful help.
I tend to agree. I've never used either of them and have had no consequences as a result. Linux can have security issues of course, but my feeling is that they are much more likely to come from phishing or from supply-chain attacks, which rootkit detectors aren't going to catch.
poc
On 2/14/25 3:49 AM, Patrick O'Callaghan wrote:
On Thu, 2025-02-13 at 23:32 -0800, Samuel Sieb wrote:
Those tools are not going to provide any useful help.
I tend to agree. I've never used either of them and have had no consequences as a result. Linux can have security issues of course, but my feeling is that they are much more likely to come from phishing or from supply-chain attacks, which rootkit detectors aren't going to catch.
poc
Thank-you Samuel and Patrick.
I'm all for "redeeming" a few minutes each week!
supply-chain attack? I've not heard of that one before. I'd ask what's next, but I fear I won't like the answer. And I'm concerned that the answer will "help" the malicious people/groups that are snooping and harvesting this list for e-mail addresses and names.
On Fri, 2025-02-14 at 14:51 -0700, home user via users wrote:
On 2/14/25 3:49 AM, Patrick O'Callaghan wrote:
On Thu, 2025-02-13 at 23:32 -0800, Samuel Sieb wrote:
Those tools are not going to provide any useful help.
I tend to agree. I've never used either of them and have had no consequences as a result. Linux can have security issues of course, but my feeling is that they are much more likely to come from phishing or from supply-chain attacks, which rootkit detectors aren't going to catch.
poc
Thank-you Samuel and Patrick.
I'm all for "redeeming" a few minutes each week!
supply-chain attack? I've not heard of that one before.
An example of a supply-chain attack would be the (fortunately failed) attempt at subverting the XZ source code:
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
which was caught in time by an alert guy from Microsoft of all places.
I'd ask what's next, but I fear I won't like the answer. And I'm concerned that the answer will "help" the malicious people/groups that are snooping and harvesting this list for e-mail addresses and names.
That's absolutely the wrong attitude. People need to be aware of potential vulnerabilities. Clearly there are sensible conventions about disclosure in order to give developers time to correct errors, but secrecy is the enemy of quality. That's one reason we use free software.
poc
Tim:
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
home user:
Maybe I'm remembering wrong, but I recall over a decade ago being advised on this list to use 2 tools to watch for malware on this workstation: chkrootkit and rkhunter.
As a general rule, old advice goes stale... ;-)
And out-of-date malware detection of any kind is probably pointless.
I don't know about on Linux, but running competing malware detection on Windows boxes was always a good way to start a software fight between them.
Also, don't these tools check for more than just rootkits?
I haven't looked into it, but the name suggests what their job is. And the Linux approach was always to make a tool to do its job, and another tool to do another job.
Most of the time anti-malware running on Linux was to protect Windows machines on the same network. Such as scanning incoming mail before the Windows machines got it.
And another general rule was that Linux doesn't really need it if you follow good computing practice of not installing or running (without installing) random software from anywhere. Supposedly our repos have enough eyes looking through them to stop shonky things getting in, although that has happened.
As I mentioned before, our email programs aren't so dumb as to go "this attachment is an executable, I'll do what the system normally does with executables," as Windows did. Likewise with web browsers. Those are the two main remote vectors of attack against any PC (mail and websites).
If you want to open yourself up to Windows-style attacks, run Samba with no firewall and treating the public internet the same as your LAN like ye olde Windows did (I've no idea if modern Windows is as vulnerable). I saw a friend's old XP PC get done just 13 seconds after connecting to the internet through a USB ADSL modem, several times in a row after lengthy format and re-installs, because he wouldn't listen to me. It was several hours before he finally paid attention. We were watching movies and having a pizza feast while his computer was grinding its gears. I wouldn't have put up with that much timewasting otherwise, but I just about wet myself laughing.
But, Fedora doesn't do that. We have a firewall by default, Samba isn't running by default, and public IPs are treated like the plague compared to your LAN. We don't usually have core features that are exposed to the Wild-Wild-West, SSH has to be configured dumbly to do that. We have SELinux that sets rules on servers about what files they're allowed access to (e.g. webservers can't just read any file outside of the serving directory, unless you're dumb enough to follow really stupid guides on the internet telling you to shut it off).
And we're mostly behind some kind of router with NAT that gets in the way of remote access, these days.
Several years ago when we had fibre internet installed in the house, during part of the install procedure they asked me to plug a computer directly into the fibre network (bypassing their modem/router combo device that normally is between you and them). Other than me being assigned an IP, they were perplexed that they couldn't detect my laptop. Normally they get some kind of response from Windows devices that lets them tell it's there, and can figure out what it is via various fingerprints. My laptop was running Fedora.
How is malware going to get onto Linux box?
You pretty much have to shoot yourself in the foot with Linux, and few anti-malware products are good at stopping people who do that. There's very little of things just slipping in without your help.
There's the obvious route of a miscreant giving someone advice to download and install BADTHING from their website, which might be a website with fake how-to-solve something instructions, or a telephone call from not-your-bank about some fake security problem. But most of that crap is aimed at Windows users.
There's the sly remote hack of your system, where bad actors are probing every IP on the planet trying to find something to hack (*). But there's very few things on your system paying attention to outside traffic. Again most of that crap is aimed at Windows users. And that's not just because of the sheer numbers of Windows users, but because it's such an easy target.
* Many years ago when I was not on Linux, and using a dial-up modem with a direct connection to my computer, I would notice any time after I posted on public mailing lists there'd be a flurry of failed connection attempts on my IP. Clearly some bad actors watch certain places for currently active connections.
But they probably are just scanning every IP on the planet all the time, now. The computing power to do that is available to them. Unplug your PC (and other LAN devices) and watch the traffic lights on your modem/router. Ignore the odd blip, but if its WAN lights are winking like mad that's things probing it. Some may be in response to something you were just doing. See if it dies off after a couple of minutes.
There will be certain apps that are a vulnerability in themselves. Web browsers are highly complex software, probably having far more features than they really need. And buggy... Though probably fairly limited to a remote hacking exploiting whatever data is in the browser, more than getting *through* it to the system, on Linux. Peer-to-peer filesharing software's probably another big risk, it's *meant* for sharing files, I've not read into how exploitable they may be for a long time, but a common issue was people stupidly sharing their entire filesystem, or all their own personal files. And just being on a peer-to-peer network does attract a gazillion connection attempts to your IP, and that in itself that can swamp some home modem/routers. Remember that a lot of software is not written by trained software engineers following best practice. There a lot of "seems to work for me" programming.
Web blogging software is a known problem. It's an interface between inside and outside, with writeable capabilities. You have to be very careful about ownership and file permissions, and access controls, to let it only do what it needs to do. Else remote blackhat can create a file through it, with executable commands, and find some way to have the webserver run it. Some people find it hard to set up the correct access controls, and let the thing run as root, have world readable and writeable permissions, and switch off protective software (like SELinux) because it tries to stop them doing stupid things. They're often quite buggy and need frequent updates to mitigate exploits, blogging software is not something you want to leave running old versions.
Rule of thumb: Webservers MUST NOT own the files they serve. The files must be owned by the author. Only the author has write permission for them (this means directories and files). The public files have world-readable permissions, and the webserver reads things as the unknown other (world) user. Webservers should not run as root, but as an independent webserver kind of user. That limits its access to only world-readable public files. Blogging software has to act as an interface obeying that same criteria when it creates the files it will publish.
Having said all that, most people don't serve websites from their own PC any more, few ISPs allow it. But those problems still exist for people who rent space and remote install webservers and blogging software. With the victim being your website and the host's computer systems.
There's the harder-to-set-up hack where someone is inside your LAN, who then has less networking obstacles in the way. But that's more of a corporate thing, it's not like someone can plug into your home LAN without you noticing there's a black-hat guy in your home who shouldn't be there. Although insecure WiFi doesn't preclude that.
And the harder to do long-game of hackers weaselling their way into some software project and contaminating software. That happened not all that long ago.
On Fri, Feb 14, 2025 at 11:50 AM Tim via users users@lists.fedoraproject.org wrote:
Most of the time anti-malware running on Linux was to protect Windows machines on the same network. Such as scanning incoming mail before the Windows machines got it.
Decades ago at work many of us had email on IRIX64 or NextStep and were required to switch to Outlook. Some users had big mbox files. We use clamav check for malware before transferring the mbox files. There were many attachments with Windows malware.
My boss was at a high-level meeting that included US military brass. At the end of the meeting the final report was shared via a USB key. My boss had a macbook, but the military had Windows laptops. At the time, Apple was using clamav with custom rules. The macbook detected malware in the form of a copy.exe on the USB key.
On Sat, 2025-02-15 at 02:19 +1030, Tim via users wrote:
Having said all that, most people don't serve websites from their own PC any more, few ISPs allow it.
I do run a small family webserver on my desktop, but I also have Fail2Ban installed. It registers multiple failed connection attempts every day, mainly from China. My policy is to automatically ban these forever as soon as they occur.
poc
On 2/14/25 9:59 AM, Patrick O'Callaghan wrote:
On Sat, 2025-02-15 at 02:19 +1030, Tim via users wrote:
Having said all that, most people don't serve websites from their own PC any more, few ISPs allow it.
I do run a small family webserver on my desktop, but I also have Fail2Ban installed. It registers multiple failed connection attempts every day, mainly from China. My policy is to automatically ban these forever as soon as they occur.
poc
Thank-you, Patrick. I thought I had fail2ban on this workstation. I just checked. It's one of many things that got wiped out in this workstation's October disaster. I'll have to take another look at the tool and, more likely than not, re-install it.
Tim:
Having said all that, most people don't serve websites from their own PC any more, few ISPs allow it.
Patrick O'Callaghan:
I do run a small family webserver on my desktop, but I also have Fail2Ban installed. It registers multiple failed connection attempts every day, mainly from China. My policy is to automatically ban these forever as soon as they occur.
Related tangentially to IP blocking, I killed off just about all nuisance phone calls by having my phone company geo-block the main culprits. I figure there's no way I'll ever get a genuine call from those countries.
In some ways I'd like to run my website from home, I can configure Apache far easier than the abomination called LightSpeed. But then I'd also have to handle the constant attacks (not that hard considering how useless most of them are, but it's a lot of activity on a low speed uplink. And, most ISPs in my country forbid it.
On 2/14/25 8:49 AM, Tim wrote:
Tim:
Is there a reason you feel the need to check for rootkits?
I'm under the impression that if you don't install things from outside of the repos, and keep SELinux running, there's a so-close-to-zero chance of you having a problem that it's not worth worrying about.
home user:
Maybe I'm remembering wrong, but I recall over a decade ago being advised on this list to use 2 tools to watch for malware on this workstation: chkrootkit and rkhunter.
As a general rule, old advice goes stale... ;-)
And out-of-date malware detection of any kind is probably pointless.
I don't know about on Linux, but running competing malware detection on Windows boxes was always a good way to start a software fight between them.
Actually, I was manually running them, one at a time.
Also, don't these tools check for more than just rootkits?
I haven't looked into it, but the name suggests what their job is. And the Linux approach was always to make a tool to do its job, and another tool to do another job.
I'm not certain. It was the impression I got from the tools' output.
Most of the time anti-malware running on Linux was to protect Windows machines on the same network. Such as scanning incoming mail before the Windows machines got it.
And another general rule was that Linux doesn't really need it if you follow good computing practice of not installing or running (without installing) random software from anywhere. Supposedly our repos have enough eyes looking through them to stop shonky things getting in, although that has happened.
As I mentioned before, our email programs aren't so dumb as to go "this attachment is an executable, I'll do what the system normally does with executables," as Windows did. Likewise with web browsers. Those are the two main remote vectors of attack against any PC (mail and websites).
and those are my real concerns. I use Firefox. There's that little shield icon just to the left of the address bar. I'm amazed (and concerned) at how many web sites that shield "says" are trying to track, cross-site track, and fingerprint. ...and how many sites refuse to function unless I disable Firefox's blocking. ...even charities and government sites. Messages in Thunderbird can be surprisingly tricky and subtle, too. I dare not say more about that.
If you want to open yourself up to Windows-style attacks, run Samba with no firewall and treating the public internet the same as your LAN like ye olde Windows did (I've no idea if modern Windows is as vulnerable). I saw a friend's old XP PC get done just 13 seconds after connecting to the internet through a USB ADSL modem, several times in a row after lengthy format and re-installs, because he wouldn't listen to me. It was several hours before he finally paid attention. We were watching movies and having a pizza feast while his computer was grinding its gears. I wouldn't have put up with that much timewasting otherwise, but I just about wet myself laughing.
But, Fedora doesn't do that. We have a firewall by default, Samba isn't running by default, and public IPs are treated like the plague compared to your LAN. We don't usually have core features that are exposed to the Wild-Wild-West, SSH has to be configured dumbly to do that. We have SELinux that sets rules on servers about what files they're allowed access to (e.g. webservers can't just read any file outside of the serving directory, unless you're dumb enough to follow really stupid guides on the internet telling you to shut it off).
And we're mostly behind some kind of router with NAT that gets in the way of remote access, these days.
Several years ago when we had fibre internet installed in the house, during part of the install procedure they asked me to plug a computer directly into the fibre network (bypassing their modem/router combo device that normally is between you and them). Other than me being assigned an IP, they were perplexed that they couldn't detect my laptop. Normally they get some kind of response from Windows devices that lets them tell it's there, and can figure out what it is via various fingerprints. My laptop was running Fedora.
How is malware going to get onto Linux box?
You pretty much have to shoot yourself in the foot with Linux, and few anti-malware products are good at stopping people who do that. There's very little of things just slipping in without your help.
There's the obvious route of a miscreant giving someone advice to download and install BADTHING from their website, which might be a website with fake how-to-solve something instructions, or a telephone call from not-your-bank about some fake security problem. But most of that crap is aimed at Windows users.
There's the sly remote hack of your system, where bad actors are probing every IP on the planet trying to find something to hack (*). But there's very few things on your system paying attention to outside traffic. Again most of that crap is aimed at Windows users. And that's not just because of the sheer numbers of Windows users, but because it's such an easy target.
- Many years ago when I was not on Linux, and using a dial-up modem
with a direct connection to my computer, I would notice any time after I posted on public mailing lists there'd be a flurry of failed connection attempts on my IP. Clearly some bad actors watch certain places for currently active connections.
But they probably are just scanning every IP on the planet all the time, now. The computing power to do that is available to them. Unplug your PC (and other LAN devices) and watch the traffic lights on your modem/router. Ignore the odd blip, but if its WAN lights are winking like mad that's things probing it. Some may be in response to something you were just doing. See if it dies off after a couple of minutes.
There will be certain apps that are a vulnerability in themselves. Web browsers are highly complex software, probably having far more features than they really need. And buggy... Though probably fairly limited to a remote hacking exploiting whatever data is in the browser, more than getting *through* it to the system, on Linux. Peer-to-peer filesharing software's probably another big risk, it's *meant* for sharing files, I've not read into how exploitable they may be for a long time, but a common issue was people stupidly sharing their entire filesystem, or all their own personal files. And just being on a peer-to-peer network does attract a gazillion connection attempts to your IP, and that in itself that can swamp some home modem/routers. Remember that a lot of software is not written by trained software engineers following best practice. There a lot of "seems to work for me" programming.
Web blogging software is a known problem. It's an interface between inside and outside, with writeable capabilities. You have to be very careful about ownership and file permissions, and access controls, to let it only do what it needs to do. Else remote blackhat can create a file through it, with executable commands, and find some way to have the webserver run it. Some people find it hard to set up the correct access controls, and let the thing run as root, have world readable and writeable permissions, and switch off protective software (like SELinux) because it tries to stop them doing stupid things. They're often quite buggy and need frequent updates to mitigate exploits, blogging software is not something you want to leave running old versions.
Rule of thumb: Webservers MUST NOT own the files they serve. The files must be owned by the author. Only the author has write permission for them (this means directories and files). The public files have world-readable permissions, and the webserver reads things as the unknown other (world) user. Webservers should not run as root, but as an independent webserver kind of user. That limits its access to only world-readable public files. Blogging software has to act as an interface obeying that same criteria when it creates the files it will publish.
Having said all that, most people don't serve websites from their own PC any more, few ISPs allow it. But those problems still exist for people who rent space and remote install webservers and blogging software. With the victim being your website and the host's computer systems.
There's the harder-to-set-up hack where someone is inside your LAN, who then has less networking obstacles in the way. But that's more of a corporate thing, it's not like someone can plug into your home LAN without you noticing there's a black-hat guy in your home who shouldn't be there. Although insecure WiFi doesn't preclude that.
And the harder to do long-game of hackers weaselling their way into some software project and contaminating software. That happened not all that long ago.
Good "white paper"? I only have this one stand-alone home workstation and a modem. But I can see how all you've said can be useful to many others.
Thank-you, Tim.
On Fri, 2025-02-14 at 15:24 -0700, home user via users wrote:
I use Firefox. There's that little shield icon just to the left of the address bar. I'm amazed (and concerned) at how many web sites that shield "says" are trying to track, cross-site track, and fingerprint. ...and how many sites refuse to function unless I disable Firefox's blocking. ...even charities and government sites. Messages in Thunderbird can be surprisingly tricky and subtle, too. I dare not say more about that.
So many sites, these days, are a cobbled together conglomeration of dozens of scripts to do /cool/ things that they can't figure out how to do buy themselves, and to handle the advertising that they sold their soul to. Never pay any *webmaster* extortionate expertise fees if that's the kind of thing they're going to do. Also there's far less altruistic sites, where information was published just to benefit others. It's "what can I publish to rake in dosh," otherwise known as click-bait.
If you block scripts and/or cookies, much of that stuff just fails (the tracking, and the entire website).
I use NoScript, it blocks a lot of crap, and stops my browser needlessly running the CPU at full pelt. But there's plenty of sites I have to carefully start enabling things to get them to work.
I only want those things to be allowed with the site I'm viewing, not globally allow a caching farm or cloud server. Because that server farm is used by a plethora of sites that I don't trust. Neither directly, or to share things between each other that doesn't help me in any way.
My DNS server also blackholes a variety of advertising and tracking sites. That took care of a lot of things without browser plug-ins. But with browsers moving away from using traditional DNS servers, that benefit will diminish in time. The claim is that it will help with people not having to solve network problems, the reality will be that it will help with tracking as they pretend to reduce tracking by moving away from cookies.
I get very little advertising following me around because of those steps. But on the Android phone where it's harder to run browsers with plug-ins, and it often runs from the mobile service provider instead of my WiFi, I notice how much of the crap does follow me around.
My ISP pissed me off, so I looked at a few alternative ISP adverts, now most of my adverts were for ISP deals (which is far less annoying than lots of other adverts).
On 2/13/25 10:50 AM, home user via users wrote:
(f40; gnome; last patched minutes ago)
When I ran chkrootkit, I got the following (including a few lines of context) regarding "wted":
[snip] Checking `w55808'... not infected Checking `wted'... 1 deletion(s) between Tue Jan 28 07:33:49 2025 and Tue Jan 28 07:36:08 2025 1 deletion(s) between Fri Feb 7 08:13:43 2025 and Fri Feb 7 08:15:51 2025 1 deletion(s) between Sat Feb 8 15:26:59 2025 and Sat Feb 8 15:29:22 2025 1 deletion(s) between Sat Feb 8 15:29:22 2025 and Sat Feb 8 15:31:27 2025 Checking `scalper'... not infected [snip] bash.5[~]:
I got the same thing both before and after "dnf upgrade". rkhunter made no mention of "wted".
I tried to find what "wted" is:
bash.5[~]: which wted /usr/bin/which: no wted in (/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/root/bin) bash.6[~]: whereis wted wted: bash.7[~]: man wted No manual entry for wted bash.8[~]: dnf info wted Last metadata expiration check: 0:23:46 ago on Thu 13 Feb 2025 10:05:51 AM MST. Error: No matching Packages to list bash.9[~]:
duck-duck-go and google gave me nothing useful.
What is "wted", and is there a security problem?
My apologies for the delay in closing this.
As recommended, I no longer run chkrootkit. As recommended, I no longer run rkhunter. As recommended, I re-installed fail2ban and launched it.
Most likely, the deletions noted by chkrootkit coincided in time to boot failures and crashes. These seem to be random.
I thank everyone for their time and effort trying to help.
-
Barry -
Dave Close -
George N. White III -
home user -
Jonathan Billings -
Michael D. Setzer II -
Patrick O'Callaghan -
Samuel Sieb -
Stephen Morris -
Tim