Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
11-06-2006, 06:38 PM
|
#16
|
Senior Member
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
|
Quote:
Originally Posted by MBA Whore
chort:
Based upon some of your other posts, I gather that I could prevent this from happening if I do not su into root while in someone else's account.
Would that be a correct, though admittedly simplified, version of what you said (sorry, I'm not very tech smart)?
|
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.
|
|
|
11-07-2006, 05:38 PM
|
#17
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Currently Mint
Posts: 655
Original Poster
Rep:
|
Is that correct?
Quote:
Originally Posted by chort
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. 
|
|
|
11-07-2006, 09:27 PM
|
#18
|
Senior Member
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
|
Quote:
Originally Posted by MBA Whore
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...
Quote:
Originally Posted by dalek
|
|
|
|
11-09-2006, 06:40 PM
|
#19
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Currently Mint
Posts: 655
Original Poster
Rep:
|
Thanks for
Quote:
Originally Posted by chort
Not "via" rootkit, "versus" rootkit...
|
Thanks for your info!
|
|
|
11-12-2006, 04:33 PM
|
#20
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Currently Mint
Posts: 655
Original Poster
Rep:
|
I did "echo" and got this....is that good?
Quote:
Originally Posted by chort
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.
|
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.
|
|
|
11-12-2006, 07:02 PM
|
#21
|
Senior Member
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
|
":" 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):
:.:
|
|
|
11-15-2006, 06:49 AM
|
#22
|
LQ Newbie
Registered: Nov 2006
Posts: 10
Rep:
|
Chkroot issue?
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
|
|
|
11-15-2006, 09:14 AM
|
#23
|
Member
Registered: Mar 2005
Location: UK
Distribution: Slackware
Posts: 794
Rep:
|
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.
|
|
|
11-15-2006, 12:13 PM
|
#24
|
LQ Newbie
Registered: Nov 2006
Posts: 10
Rep:
|
How to check?
Thanks for this - I'll check out the tutorial later tonight.
How do I check the directories though? (complete newbie)
Thanks again
Steve
|
|
|
11-15-2006, 01:01 PM
|
#25
|
Member
Registered: Mar 2005
Location: UK
Distribution: Slackware
Posts: 794
Rep:
|
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.
|
|
|
11-15-2006, 01:03 PM
|
#26
|
Member
Registered: Mar 2005
Location: UK
Distribution: Slackware
Posts: 794
Rep:
|
Have a look at the link in my signature for an excellent tutorial on basic commands.
|
|
|
11-15-2006, 06:05 PM
|
#27
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Currently Mint
Posts: 655
Original Poster
Rep:
|
Is one better than
Quote:
Originally Posted by Steve K
Hi,
An interesting thread. I've downloaded and run the chkrootkit and rkhunter extensions.
|
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
|
|
|
11-15-2006, 07:10 PM
|
#28
|
Moderator
Registered: May 2001
Posts: 29,417
|
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.
Last edited by unSpawn; 11-15-2006 at 07:20 PM.
Reason: WHAAT? I don't need no fsckin reas^H^H^H
|
|
|
11-16-2006, 01:48 AM
|
#29
|
LQ Newbie
Registered: Nov 2006
Posts: 10
Rep:
|
Very interesting
And SimCox1 - thanks for the tutorial link. Will take about a month to read!
Steve
|
|
|
11-21-2006, 06:31 PM
|
#30
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Currently Mint
Posts: 655
Original Poster
Rep:
|
unSpawn:
Yes, that is very interesting. . .it will take me sometime to digest all of that! LOL. ty
|
|
|
All times are GMT -5. The time now is 02:47 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|