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.
|
|
|
10-28-2006, 08:59 PM
|
#1
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Rep:
|
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!
|
|
|
10-29-2006, 01:34 AM
|
#2
|
LQ Guru
Registered: Oct 2003
Location: Waiheke NZ
Distribution: Ubuntu
Posts: 9,211
Rep:
|
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?
|
|
|
10-29-2006, 07:42 AM
|
#3
|
Senior Member
Registered: Jul 2003
Location: Mississippi USA
Distribution: Gentoo
Posts: 2,058
Rep:
|
|
|
|
10-29-2006, 07:24 PM
|
#4
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
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!
|
|
|
10-30-2006, 12:07 AM
|
#5
|
Senior Member
Registered: Jul 2003
Location: Mississippi USA
Distribution: Gentoo
Posts: 2,058
Rep:
|
|
|
|
11-01-2006, 07:44 PM
|
#6
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
How do
Quote:
Originally Posted by dalek
|
How do you do that?
|
|
|
11-01-2006, 09:14 PM
|
#7
|
Senior Member
Registered: Jul 2003
Location: Mississippi USA
Distribution: Gentoo
Posts: 2,058
Rep:
|
Quote:
Originally Posted by MBA Whore
How do you do that?
|
Install chkrootkit.
http://www.chkrootkit.org/
|
|
|
11-02-2006, 07:47 PM
|
#8
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
Is a rootkit
Quote:
Originally Posted by dalek
|
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.
|
|
|
11-02-2006, 08:28 PM
|
#9
|
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:
|
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.
|
|
|
11-04-2006, 09:05 PM
|
#10
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
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.
|
|
|
11-05-2006, 01:45 AM
|
#11
|
LQ Newbie
Registered: Nov 2006
Posts: 18
Rep:
|
No matter what OS, if a user lacks knowledge on handle one, then he/she tends to get hack.
|
|
|
11-05-2006, 12:47 PM
|
#12
|
Senior Member
Registered: Sep 2003
Posts: 3,171
Rep:
|
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.
|
|
|
11-05-2006, 05:51 PM
|
#13
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
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!
|
|
|
11-06-2006, 02:54 PM
|
#14
|
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:
|
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.
|
|
|
11-06-2006, 06:12 PM
|
#15
|
Member
Registered: May 2006
Location: Kansas City, MO
Distribution: Various: pclos, Debian, Ubuntu, etc . . .
Posts: 649
Original Poster
Rep:
|
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 01:00 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
|
|