Linux Security for Beginners

Now that you have commented out those services that aren't needed, what do you do about those that are? As we discussed above, you could use tcp wrappers, but that only cuts it for services offered by inetd, and tcpd doesn't necessarily mean your system is secure—those applications can still be exploited. Also, those services independent of inetd and those people who do have access to your system must be considered.

The best thing to do is be aware. If you run a news server right out of the box, you could be taking a severe security risk. On the other hand, if you learn everything including known security holes, then you have the opportunity to search for a patch or solution. There are also alternatives such as using different programs. Instead of using an insecure application like TELNET, use one that is more secure and designed with security flaws in mind. A secure replacement for TELNET would be ssh; for sendmail, which is notorious for its security flaws, a secure alternative is qmail.

What about users who have authorized access, or those who don't but manage to gain access? There are all kinds of known security holes, back doors and other nasty things which can be used for no good. Since you can't beat them, join them. By this, I mean learn all about those exploits; new ones are discovered every day and patches are made to remedy the situation. Several web sites thoroughly document these problems and solutions (see Resources).

The system can also be exploited through setuid programs. These are programs which run with the privilege of the program's owner when executed. These programs could even be setuid root and, as a result, when executed they have the permissions of root. Crackers can use this to gain root privileges. The best way to deal with this situation is to learn about possible problems with programs that run with the root setuid bit set on and disable those programs which are not needed.

With all of the above in mind, let's look at some nifty tools and methods for internal security. Obviously, someone can compromise your system if they have access. To limit user access on a machine, you use two files: /etc/securetty and /etc/login.access. The first file defines which ttys terminals can be logged into by root. The second limits user access, but is far more flexible. Lines in this file follow the format:

permission : users : origins

where permission is either access granted (+) or access denied (-), users is a list of login names, group names or ALL, and origins specifies “where” a user can log in. An example would be the following line:

- : ALL EXCEPT bob : ALL

- : ALL : .anytown.state.us console

As I mentioned above, setuid programs can be hazardous. One way to deal with these programs is to find them first. This can be done with a simple script, using the find command as shown in Listing 1.

Be aware that this script will generate a file containing sensitive information. After viewing it, you should delete it. Once you've looked at the list and found any scripts or programs that aren't necessary, you could disable them as root using chmod like this:

chmod 644 filename

Once setuid is disabled, the script or program is no longer a security risk.

So far, we have discussed a couple of techniques to tighten system security. What about testing the security on your system? Is it vulnerable to attack? Are there back doors? Several tools are available to answer these questions. Satan can scan a system for any back doors or holes that might become potential security risks. Other programs like netwatch and tcpdump can monitor network traffic on your system. A packet sniffer program, SniffIt, can also help you in many ways. Packet sniffers have a bad reputation, because they can be a security risk to your system, but they can also help you find problems. A lot of network clients/hosts send information using plaintext, which presents a severe security risk.

Using sniffit you can test various combinations to see if there is any potential risk. The program can be downloaded from the URL shown in Resources. I won't discuss compiling and installing sniffit, for that's another topic. Once you have the program up and running, you can give it a test drive. To use the interactive mode, which has a nice curses-based interface, type the following command:

sniffit -i

In Figure 1, you can see two IP addresses: a destination and a source. The source IP is sending packets from port 19 to the destination IP, 192.168.1.2. Notice that port 19 is “chargen” and does nothing but send characters. (Packet sniffing works only in situations with high bandwidth.) If the source and destination port are changed to 21, any TELNET sessions from 192.168.1.1 to 192.168.1.2 can be picked up, thus allowing the viewer to see what the TELNET user is typing in his session. If the user is using ssh instead of TELNET, the viewer would see only useless garbage.

Figure 1. SniffIt Screenshot