Linux Keyloggers -- How to defend ?
 

How do you defend yourself against Linux keyloggers? I do occassionaly see something in Synaptic that supposedly protects you from Linux keyloggers, but I really don't know how trustworthy they are.

Your thoughts, opinions, etc on good anti-keylogger programs (and practices) would be greatly appreciated.

FYI: I use a Debian based distro known as "MEPIS."

Thanks!

Something like this: http://gentoo-wiki.com/Keylogger ?

... as with all spyware, what you can do depends on how it operates and where you are and so on. Hardware keyloggers, for eg, are unlikely to be detected by software.

However, like all malware, it is difficult to infect your own computer without your permission.

Simply not using the keyboard (for sensitive typing like passwords) would be effective where you are sure you are being logged. OR, use a live distro - so you have your own RO operating system.

Of course, you can completely remove all spyware by completely reinstalling the OS ;)

So what are the circumstances, and how paranoid are you?

The key thing is preventing it from being installed to begin with. If you watch what is going on it should not install anything without your knowledge. Watch the sources where you get programs and such and you should be safe. Example, if you are going to install a Mozilla extension, make sure you have gone to the Mozilla site to get it.

:D :D :D :D

No specific situation....just looking for
 

No specific situation....just looking for information on what is out there. I know in Windows keyloggers are a big deal, so I figured it wouldn't hurt to check the issue in Linux.

I can't think of any "dumb" behavior I do online...I try to be careful regardless of my OS / Web Browser. Still, I would like some programs for Linux that I can occassionally run to check for known keyloggers. Everyone makes mistakes....catching and correcting them is what is important.

Anyone reading this can reply. Thanks again!

Keep in mind that windoze can/somtimes will install software without you knowing it is doing it. Also keep in mind that most things you install are precompiled so you really have no idea what is in the program. Admittedly most Linux distros are precompiled to but you can go look at the source code for it, windoze is closed source. There are also a LOT of volunteers that participate in the process of making say Mandriva. If someone was putting a keylogger in there, it wouldn't be secret for very long. Linspire may be different. I'm not sure what they do with their code. I have not looked into that one.

As long as you are not installing stuff from unknown sources you should be fine. Linux is a lot more secure than windoze can even dream of, unless you unhook the windoze box from the net and disable CD and floppy drives. :rolleyes:

If you have a constant connection like cable modem, make sure you have really good passwords, especially root, and check to make sure someone is not hacking in and installing a rootkit. Other than that, I wouldn't worry to much.

:D :D :D :D :D

How do
 

How do you do that?

Install chkrootkit.

http://www.chkrootkit.org/

:D :D :D :D

Is a rootkit
 

Is a rootkit the same as a keylogger? If not, would "chkrootkit" find both rootkits and keyloggers?

Thanks for the link. . .I'm looking it over.

In general any command or process that accepts keystrokes from you could log those keystrokes. Generally that wouldn't be such a big deal, say if you were doing ls and the ls command had been modified to log your command arguments. In some cases it is a big deal, such as when you type in a password or passphrase. A very old example of this is in the ancient days of UNIX a user would complain to the admin that there was a problem with their account, and could they please come over to the terminal and check it out?

What would happen is that the admin would physically walk over to the user's terminal, poke around a bit, and find something with messed up permissions or some other problem that required root to fix. Then the admin would type su root and enter root's password, thinking it was safe because the input is hidden. What they didn't know is that the user had created their own script to call su and tucked it in the bin directory, or created an alias to it. The admin would type their root password, the fake "su" would record it to a file, then it would call the "real" su with the password, which would succeed and admin now has root as if everything worked properly. Another variation is dropping fake versions of passwd at various public places on the file system hoping the admin would be in that directory when they typed passwd since root's .profile usually included "." in the path.

Any way, those are some examples of simple tricks that can read input. Now days it's more likely that a LKM (loadable kernel module) would hook the input, and the most common way for that to happen would be a rootkit, hence why protecting against rootkits can give you some defense against keystroke loggers.

Wow....just...
 

Wow....just wow....I had no idea it could be that complicated.

Regarding your example: a "normal" user could create some script that would essentially record the root password if it is typed in. Then, the normal user could have the root password. Then the normal user could do as he pleases.

Is that correct?

How can you protect yourself from something like that?

Would rootkit searchers / key logger searchers still help? Or would you need to do something that prevents the normal user from creating script (Would that even be possible???) in the first place?

Do you recommend any particular rootkit / key logger searchers?

Thanks for the insight. The more I learn, the more it seems like Linux can be manipulated into something unsafe just like Windows can be manipulated. :(

No matter what OS, if a user lacks knowledge on handle one, then he/she tends to get hack.

The way that you would secure against this particular problem is fairly straightforward. First, the system administrator would set up a path for all users that does not include the current directory. Thus, no user can execute a program or script by just typing the name (unless that name is found in a directory that IS in the path); he has to type ./thename or /thedirectorypath/thename in order to execute something.

Second, the system should be secured so that no user except root has write access to any directory that IS in the path. Thus no one but root can put a file into /usr/ /bin/ /usr/bin/ /usr/local/bin/ and so forth.

Third, users should not be allowed to set the path, and users should have no authority to change permissions on anything that is not in their home directory.

This will stop the problem described here.

Sorry to nag again.....
 

jiml8 (and anyone else reading):

Sorry to nag again, but could you possibly help me out here? I noticed you listed three (3) steps. Would I have to follow each step, or would I be ok if I only follow one (1) or two (2) of them?

Here is my current set up. How safe am I?

I have two (2) user accounts. Only root and the individual user can change individual account permissions. Each account has full read / write access to whatever content is in its own home directory.

More account details:

Account #1 is my main account with private info and mp3s, but I do not use that account very frequently. Account #2 is for "everyday" use. Account #2 has read only access to the mp3s on Account #1. However, Account #2 can not read, write or even view the private info I have in Account #1.

Am I safe from the original problem we discussed or could I do more?

Thanks!

The best way to avoid being tricked into running a local copy of a system command is to never su to root from anyone else's account. There are other ways to accomplish that trick besides having the fake program in the current directory. Many distributions of Linux include ~/bin in the path, so a user could put the fake su command in their ~/bin directory so it would work even though . isn't in the path. Another way is to use the shell alias, or function capabilities to override the default behavior. You can defeat those by using the "builtin" directive to get the "real" version of a command, but that is an aweful lot to remember. It's much more difficult to remember all the things you must do to avoid being tricked than it is to remember: don't su when you're logged in as someone else.

If you are on a system that is owned by you (as in possessed, not as in hacked) and contains only accounts for yourself, then you're pretty safe from stupid user tricks like I described. All you really have to watch out for in that case is falling victim to a rootkit that would install an LKM that hooks keyboard input. As described by others, there are utilities that will check for such rootkits. The real goal is to not provide an opportunity for a rootkit to be installed on your system in the first place, which means keeping up to date with security patches (yes, Linux needs these too, not just Windows), turning off any network services that you don't need (do you need IPP, or ftpd, or httpd, etc?), and making sure your firewall is enabled and has a tight default-deny configuration. Also, do not open any files or install any software that you are not sure comes from a safe & trusted source.

If I do not su while in
 

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)?

I am the only one who uses my computer, but I want to set it up as if multiple people used it, because I figured that "learning by doing" would be the best way to learn.

Thanks again for all your input!

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.

Is that correct?
 

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. :p

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

Thanks for
 

Thanks for your info!

I did "echo" and got this....is that good?
 

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):
:.:

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

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.

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

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.

Is one better than
 

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