LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Linux Keyloggers -- How to defend ? (http://www.linuxquestions.org/questions/linux-security-4/linux-keyloggers-how-to-defend-496495/)

MBA Whore 10-28-2006 09:59 PM

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!

Simon Bridge 10-29-2006 02:34 AM

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?

dalek 10-29-2006 08:42 AM

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

MBA Whore 10-29-2006 08:24 PM

No specific situation....just looking for
 
Quote:

Originally Posted by Simon Bridge
So what are the circumstances, and how paranoid are you?

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!

dalek 10-30-2006 01:07 AM

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

MBA Whore 11-01-2006 08:44 PM

How do
 
Quote:

Originally Posted by dalek
check to make sure someone is not hacking in and installing a rootkit. :D :D :D :D :D

How do you do that?

dalek 11-01-2006 10:14 PM

Quote:

Originally Posted by MBA Whore
How do you do that?


Install chkrootkit.

http://www.chkrootkit.org/

:D :D :D :D

MBA Whore 11-02-2006 08:47 PM

Is a rootkit
 
Quote:

Originally Posted by dalek
Install chkrootkit.

http://www.chkrootkit.org/

:D :D :D :D


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.

chort 11-02-2006 09:28 PM

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.

MBA Whore 11-04-2006 10:05 PM

Wow....just...
 
Quote:

Originally Posted by chort
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....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. :(

argh2xxx 11-05-2006 02:45 AM

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

jiml8 11-05-2006 01:47 PM

Quote:

Originally Posted by MBA Whore
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. :(

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.

MBA Whore 11-05-2006 06:51 PM

Sorry to nag again.....
 
Quote:

Originally Posted by jiml8
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.


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!

chort 11-06-2006 03:54 PM

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.

MBA Whore 11-06-2006 07:12 PM

If I do not su while in
 
Quote:

Originally Posted by chort
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.

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!


All times are GMT -5. The time now is 03:59 PM.