Yes. Also make sure that root does not have . in it's path, but most distributions don't have this by default (just don't add it). Check all of root's dotfiles to make sure they don't include . in the PATH variable. You can verify this by typing echo $PATH as root. To be clear, the only things that these steps avoid is running "fake" copies of system commands that would accept password input. Just these steps alone does not protect you 100% against having your keystrokes captured.

So, doing what you said above would help prevent someone running a "fake" command. However, I would still need an additional layer of proctetion via a rootkit / keylogger detector (software) to supplement my efforts.

Is that correct?

On that note, are there any rootkit / keylogger detectors (for Linux) that you would recommend? Something effective but simple enough for a computer idiot like me to use correctly would be ideal.

Not "via" rootkit, "versus" rootkit...

Thanks for your info!

Hi chort:

I took your advice and su into root: echo $PATH

This is what I got:

/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games

I have no idea what that means. Do you?

I do not see "." but I do see ":"

Any thoughts?

Thank you again, I appreciate your patience with all of my questions.

":" is the separator character for UNIX directories in a PATH. On Windows it's ";". That littlerally means "when you type the name of a command, look in the following places for it:"
/bin
/sbin
/usr/bin
/usr/sbin
/usr/X11R6/bin
/usr/local/bin
/usr/local/sbin
/usr/games

If "." was in the path it would look like this (somewhere in between the rest of the directories):
:.:

Hi,
An interesting thread. I've downloaded and run the chkrootkit and rkhunter extensions.
I get everything clear, but a warning to check the following:

/dev/.static (directory) /dev/.udev (directory) /dev/.initramfs (directory)

Does this mean anything? Should I be worried?
Have only had linux (ubuntu 6.10) up and running for a few days and have not dowloaded anything not in the repositories.

Thanks

Steve

I think you should be safe. You can always check those directories but they're probably empty. You shouldn't need both rkhunter and chrootkit though. They both do similar checks. Whether they interfere with each other I don't know.

Thanks for this - I'll check out the tutorial later tonight.
How do I check the directories though? (complete newbie)

Thanks again

Steve

You can check the contents of a directory with ls. ls -l will give more info on the contents.

ls /dev/.udev

To view hidden files, ie those that begin with a . you use the -a option.

ls -a /dev/.udev

or

ls -la /dev/.udev

for the long form.

Have a look at the link in my signature for an excellent tutorial on basic commands.

Steve, or anyone else reading:

Is there any significant difference between chkrootkit and rkhunter? Let me rephrase to clarify my question: Is there enough of a difference between the two (2) programs to favor one over the other?

Thanks!

/ also n00b

Is there any significant difference between chkrootkit and rkhunter? Let me rephrase to clarify my question: Is there enough of a difference between the two programs to favor one over the other?

Yes. But before I get there I must remark they are both passive diagnostic tools that look for symptoms.
In short this means that their output can not be trusted on a system that is not properly hardened, audited, maintained. In case of doubt you better run audit tools from a Live CD distro like KNOPPIX-STD, HELIX or equivalent. With hardening I do not only mean 1) the regular steps you must take to protect your investment but also 2) installing a file integrity checker (right after OS install) like Aide, Samhain or tripwire and saving a copy of the binary, config and database off-site, preferably on read-only media. These can be used as authoritative means of verification if your audit tools or package manager fail or if your distro's package manager has weak or nonexistant verification functionality. And to top it of 3) running "preventive measures" (lets call it that for now) like SELinux or GRSecurity if possible. But enough of this.


In the scripted area there are only three applications: Chkrootkit (abbrev CRT), Rootkit Hunter (RKH), OSSEC Rootcheck (ORC) (and FindKit but it is deprecated, see http://mirror.trouble-free.net/killall/findkit). Chkrootkit (CRT) has been around since aprox 2000 and was an natural evolution of another tool of the same developer. Rootkit Hunter (RKH) entered the arena a few years later. All are shell based, run on GNU/Linux, BSDs and other OSes and CRT, RKH and ORC are more or less actively developed and maintained.


There are differences and some are more obvious (the amount of malicious tools detected) that others (maintainer stubbornness ;-p). For instance for detecting ethernet device promiscuous mode CRT still relies on the deprecated "ifconfig" binary (I pointed it out to Nelson oh, two years ago) while RKH uses "ip" from the iproute2 package. On the other hand CRT has "chkproc" to try and detect the Adore LKM but if you look at the code you'll see it isn't that hard to circumvent: just change one digit in Adore. RKH (CVS) uses external "unhide" to try and detect hidden processes, which works well with Adore. CRT uses the unhide method of using setpriority() (but only after I pointed it out to Nelson, heh). ORC is much worse (last time I checked) trying to detect Adore simply by looking for a binary named "ava" (the Adore "interface") in two locations.

Leaving ORC out of the equation here's some other methods CRT and RKH use for detecting rootkits are:
CRT only:
- Hidden directories
- Hidden processes
- Wtmp/Utmp deletion
- Lastlog deletion

Both:
- Suspicious names and locations
- Trojan strings
- Process details
- Symbols
- Backdoor ports
- Network interface promiscuous mode

RHK only:
- Auth info (passwd/group, multiple root users)
- Modules
- Extended attributes
- SysV and boot files
- Port scan (nmap, flawed: localhost)
- Open files (lsof)
- Common binary MD5sums
- Application versions and Apache conf+so's
- OpenSSH root login and SSHv1 protocol
- Running Syslog(-ng)
- Can scan prelinked binaries
- Hash blacklist
- Exclude common dotfiles and false positives


I hope this gives you an objective overview of some of the differences. Please conclude its not a bad thing to run both of them, but running both of them can *not* be considered enough to make a box "safe" in any way.

Very interesting

And SimCox1 - thanks for the tutorial link. Will take about a month to read!

Steve

unSpawn:

Yes, that is very interesting. . .it will take me sometime to digest all of that! LOL. ty