Okay, well I've looked through ksysguard (which is apparently what XFCE also uses) and it doesn't have the processes listed. It only shows the processes currently running like firefox, X server, etc.

The weird thing is, I honestly don't know why chkrootkit would look for this trojan. However, sometimes it doesn't show up on scans. I've done a scan with ClamAV and it's showed nothing except it's standard sanity-check viruses.

The weird thing is you seem unwilling to listen to reason and, even more, mistake OralDeckards replies for proper advice.

I apologize. I thought they were. I'll start checking my system from my Knoppix live CD. However, one reason I am concerned about using my Knoppix Live CD is because I had a thread about the official site of Knoppix. Apparently there's knoppix.net (which is the first link from Google after typing 'Knoppix Official'), knoppix.com (links to knoppix.net) and knoppix.org (according to Wikipedia). I got my LiveCD from the .org one, but I'll still try.

Edit:

Okay, after doing a little more digging, here is what I get with the archive.org link's help:

First:
Everything seemed to be fine as they were all found except:

From the second command:

Command, it seemed everything checked out fine except for a similar problem:

As for the everything seemed to check out fine, but I did have some concerns. One of my concerns, were a few of these (4 actually):

/home/thomas/.serverauth####

because chkrootkit also has this error on every scan:

And yes, /home/thomas/.serverauth.2636 was 1 of the 4 hidden files.

The scan also came out with:

Although I'm not sure if this is a concern. I'm only concerned about it because generally chkrootkit just says "not infected" or "not found".

This scan did not come out with the whole LKM Trojan thing this time. Although sometimes it does. I guess I still need to do some more testing to see which program or process is giving me this whole "LKM Trojan" thing.

As for the md5 check, I've used md5 checks before with the file coming out with an OK but when using the one from Slackware.com's mirrors, I came out with each check being: FAILED which leads me to believe I did it incorrectly. Was there a certain place CHECKSUMS.md5 should have been placed?

Last thing from the archives list was the whole network thing. I'm currently using the firewall from Alien Bob's Easy Firewall Generator and have disabled inbound connections and put it in rc.local to load up on start up, so I think I have that covered.

No need to apologize. He clearly said I can't offer any expert advice". Doesn't mean I consider myself a security guru though.


The "can't find" lines are from 'find' itself. In a terminal type the following on one line:
and you'll find the first numerical value is the current shells PID, the second value the PID of 'find' as it runs in the background, and the 'ps' output shows the Parent Pid (PPID) of 'find' is the PID of the parent shell (also see SID). If the last three lines aren't a problem with how that version of find accepts command line arguments the in looks like you're running 'find' on /, while instead your disks partitions should be mounted either automagically in /media or manually wherever you like it, usually in /mnt?..


See http://www.linuxquestions.org/questi...kutmp-496382/?


See your own other thread http://www.linuxquestions.org/questi...cerns-901573/?


The reason I suggested verifying your machines integrity first is that if you can make certain no foreign files exist on your system then behaviour it exhibits is native to the system (in short: you gotta learn to live with it ;-p).


Sure, probably is, but for checking it shouldn't matter unless there's no absolute paths inside the MD5 file. Do show an example or post a new thread in the Slackware forum.


There's more than that. It starts with not installing what you don't need as this makes for less risk. Then don't run services you don't need. Then harden the machine and protect the services you do need. Finally log what's unacceptable / denied, have those logs parsed (Logwatch?) and read the reports so you can act on them.

I understand. The only things I've installed on this computer have been from slackbuilds.org with the exception of sbopkg, wine and VLC Media Player. Anything else has been family photos from photobucket or flickr that I downloaded.

The Slackware DVD wasn't even torrented, I downloaded it via Firefox from the 13.37 64bit folder directly (and I checked the DVD iso with the md5 file).

Here's one example of the whole failed not found thing I was speaking of:

But the last 2 lines (before it stops) also shows this:

This was with me using: 'md5sum -c CHECKSUMS.md5'

Also, I'm not sure if this would take longer but I think checking my system for any foreign "transient" files would be a faster solution, since if nothing is found then I can confirm that the /proc file is just my hardware.

The command returns these results:
And yes, I am running it as root on / because I'm currently verifying my Live CD for other security reasons. ^.^ I'll run it on my Live CD ASAP.

The wlan0 thing, if it is something about logging in may be NetworkManager which uses gnome-keyring. I've set it to automatically start and made it available to all users so I wouldn't have to constantly unlock the keyring every time I started up my computer.

Okay, sorry for double posting here but I'm going to mark this thread as solved. Simply put, I haven't found any problems. I even downloaded the same packages and pictures I had on another computer, without the error popping up again.

I even cleared out the hard drive a third time, and installed ONLY chkrootkit and rkhunter with no malicious finds. I feel like I'm in the clear. Thanks to everybody who helped. ^.^

If CHECKSUMS.md5 was taken from any slackware site or CDROM then you're verifying hashes from the installation tree. It won't tell you anything about the integrity of what you have installed (package contents). As per the default slackware "that is left to the sysadmin" mantra you are free to script fetching packages, explodepkg them, hash package contents and then verify against what you have installed.


I think you're confusing things right now. If you list the packages you have installed then you can know which files you have installed. If you know which files you have installed then you can verify their integrity. The difference of using 'find' on the system and comparing that result with the list of files you have installed are files to investigate. These may be common application-generated files (xhost), regular files that are modified by system use (passwd, syslog), user temporary files (Xorg, any DE, ssh-agent, man) or foreign files (like finding a reverse shell or a kernel module in your /tmp directory). Potentially malicious files are commonly dropped in a directory and not commonly transient in the sense process Ids are.


Since you have not posted commands and (error) output I have no idea what you're talking about. While "made it available to all users" sounds like mucking with ownership and access rights which may be a security issue let's focus on the core problem.

I see, so even if the CHECKSUMS.md5 file would only verify the installation tree files, which is done primarily by default with slackpkg for any new packages anyways. *Facepalm to myself*

Ohhh, okay I see. Unfortunately (or maybe fortunately) to say, even on the second hard drive I mentioned, I still continue to get the /proc find error (from the CERT Archive link), and so I think I can safely assume it's a false positive, but I would like a different opinion as you know, I'm paranoid.

Again, sorry for the double post but I found the problem! Hilariously (and ironically) it's rkhunter.

rkhunter was the hidden processes, and the "possible LKM Trojan" so I guess moral of the story is...don't run two rootkit checkers at once. ^.^

Whenever rkhunter isn't on, or if the scan finishes, chkrootkit doesn't find the hidden processes, but while it is running it finds them.

Show me proof.

If you don't like the photo proof, I'll get a log if you want but in all honesty I'm not sure which log to check, and I'm limited on time today (busy Monday classes).

Attached Thumbnails

   

NP. Basically any short-lived process may cause chkproc to issue what in the end are false positives. Back to #10 ;-p