The next thing to take a look at is the security in your system against attacks from local users. Did I just say _local_ users? yes.
Getting access to a local user is one of the first things that system intruders attempt. With lax local security, they can then "upgrade" their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump.
Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or have no contact information for is a very bad idea.
Before changing permissions on any system files, make sure you understand what you are doing. Never change permissions on a file because it seems like the easy way to get things working. Always determine why the file has that permission before changing it.
You should make sure and provide user accounts with only the minimal requirements for the task. If you provide your son (age 10) with an account, you might want them to only have access to a word processor or drawing program, but be unable to rm everything.
Several good rules of thumb when allowing other people legitimate access to your linux machine:
Many local user accounts that are used in security compromises are ones that have not been used in months or years. Since no one is using them they provide the ideal attack vehicle.
It's important to insure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintance.
A quick explanation of unix permissions:
Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node
Permissions - Bits capable of being set or reset to allow certain types of access to it.
Read:
Write:
Execute:
You - The owner of the file
Group - The group you belong to
Everyone - Anyone on the system
Examples:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1st bit - directory? (no)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (no)
5th bit - read by group? (yes, by users)
6th bit - write by group? (no)
7th bit - execute by group? (no)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (no)
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1st bit - directory? (yes, it contains many files)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (yes, by kevin)
5th bit - read by group? (yes, by users
6th bit - write by group? (no)
7th bit - execute by group? (yes, by users)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (yes, by everyone)
System configuration files (usually in /etc) are usually mode 644 (-rw-r--r--), and owned by root. Depending on your sites security requirements, you might adjust this. Never leave any system files writable by a group or everyone.
Another common local user attacker is the admin of your linux box. yes, you! ;) Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea. Just use su or sudo to do those tasks you need to do.
Several tricks to avoid messing up your own box as root:
If you absolutely positively need to allow someone (hopefully very trusted) to have superuser access to your machine, there are a few tools that can help. Sudo allows users to use their password to access a limited set of commands as root. This would allow you to, for instance, let a user be able to eject and mount removable media on your linux box, but have no other root privileges. sudo also keeps a log of all sudo attempts and successes, allowing you to track down who used what command to do what. For this reason sudo works well even in places where a number of people have root access, but use sudo so you can keep track of changes made.
A Trojan Horse is named after the fabled ploy in Homers great literary work. The idea is that you put up a program or binary that sounds great, and get other people to download it and run it as root. Then, you can compromise their system while they are not paying attention. While they think the binary they just pulled down does one thing (and it might very well), it also compromises their security.
You should take care of what programs you install on your machine. redhat provides md5 checksums and pgp signed rpm files so you can verify you are installing the real thing. Other distributions have similar methods. You should never run any binary you don't have the source for or a well known binary as root! Few attackers are willing to release source code to public scrutiny.
Although it can be complex, make sure you are getting the source for some program from it's real distribution site. If the program is going to run as root make sure either you or someone you trust has looked over the source and verified it.
One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent linux distributions include 'passwd' programs that not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features.
In depth discussion of encryption is beyond the scope of this document , but a introduction is in order. Encryption is very usefull, possibly even nessessary in this day and age. There are all sorts of methods of encrypting data, each with their own flaws and drabacks. Some of the more common ones you should be aware of:
unix password encryption: Most unicies (and linux is no exception) use the DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, whatever you type in is encrypted again and compaired with the entry in the passwd file. If they match, it must be the same password and you are allowed access. DES is a one-way encryption. DES is know to be pretty weak in these days of fast computers. Brute force attacks, such as crack or John the ripper (see below) can often guess passwords unless your password is sufficently random. PAM modules (see below) allow you to use a diffrent encryption routine with your passwords (MD5 or the like).
Newer versions of the RedHat linux distribution ship with a thing called "PAM". PAM allows you to change on the fly your authentication methods and requirements. Without re-compiling any of your binaries. Configuration of PAM is beyond the scope of this document, take a look at the PAM web site for more information. http://www.kernel.org/pub/linux/libs/pam/index.html
Just a few of the things you can do with PAM:
Shadow passwords are a means of keeping your encrypted password information secret from normal users. Normally this encrypted password is stored in your /etc/passwd file for all to read. They can then run password guesser programs on it and attempt to determine what it is. Shadow passwords save this information to a /etc/shadow file that only privileged users can read. In order to run shadow passwords you need to make sure all your utilities that need access to password information are recompiled to support it. PAM (above) also allows you to just plug in a shadow module and doesn't require re-compilation of executables.
If for some reason your passwd program is not enforcing non easily guessable passwords, you might want to run a password cracking program and make sure your users passwords are secure.
Password cracking programs work on a simple idea. They try every word in the dictionary, and then variations on those words. They encrypt each one and check it against your encrypted password. If they get a match they are in.
There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" http://www.false.com/security/john/index.html . They will take up a lot of your cpu time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to get your passwd (unix /etc/passwd) file, but these are more common than you might think.
Another very good way to detect local (and also network) attacks on your system is to run an integrity checker like Tripwire. Tripwire runs a number of checksums on all your important binaries and config files and compares them against a database of former values. Thus, any changes in the files will be flagged.
It's a good idea to install tripwire onto a floppy, and then physically set the write protect on the floppy. This way intruders can't tamper with tripwire itself or change the database. Once you have tripwire setup, it's a good idea to run it once a day or so and check to see if anything has changed.
You can even add a crontab entry to run tripwire from your floppy every night and mail you the results in the morning. Something like:
# set mailto
MAILTO=kevin
# run tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
Tripwire can be a godsend to detecting intruders before you would otherwise notice them. Since a lot of files change on the average system, you have to be careful what is cracker activity and what is your own doing.
CFS is a way of encrypting an entire file system and allow users to store encrypted files on them. It uses a NFS server running on the local machine. rpms are avail at http://www.replay.com/redhat/ and more information on how it all works is at: ftp://ftp.research.att.com/dist/mab/
TCFS improves on CFS, adding more integration with the file system, so that it's transparent to any users using the file system that it's encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/
It's important for you to secure your graphical display to prevent attackers from doing things like: grabbing your passwords as you type them without you knowing it, reading documents or information you are reading on your screen, or even using a hole to gain superuser access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system.
X has a number of access control mechanisms. The simplest of them is host based. You can use xhost to specify what hosts are allowed access to your display. This is not very secure at all. If someone has access to your machine they can xhost + their machine and get in easily. Also, if you have to allow access from an untrusted machine, anyone there can compromise your display.
When using xdm (x display manager) to login, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and stored in your .Xauthorty file. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide only that connection access.
You can also use ssh (see ssh, above) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no un-encrypted data flows across the network.
Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites you wish to run X programs off of.
SVGAlib programs are typically suid root in order to access all your linux machines video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.
The linux GGI project is trying to solve several of the problems with video interfaces on linux. GGI will move a small piece of the video code into the linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console. http://synergy.caltech.edu/~ggi/
identd is a small program that typically runs out of your inetd. It keeps track of what user is running what tcp service, and then reports this to whoever requests it.
Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests.
Why would you want to run it then? Because it helps _you_ out, and is another data-point in tracking. If your identd is un compromised, then you know it's telling remote sites the user-name or uid of people using tcp services. If the admin at a remote site comes back to you and tells you user so and so was trying to hack into their site, you can easily take action against that user. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user.
The identd that ships with most distributions is more configurable than many people think. You can disable identd for specific users (they can make a .noident file), you can log all identd requests (I recommend it), you can even have identd return a uid instead of a user name or even NO-USER.