Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
Being on the Internet full time leaves your site open to potential problems with hackers and mischief. I don't want to blow this out of proportion, now. Many sites will have no problems with such things, or at least scarce ones. However, as the saying goes, "Better safe than sorry."
When it comes to security, it's best to decide what kinds of security measures you're going to take before you start setting up any more of your site. Your security route will determine how each of your servers contacts the Internet.
In this chapter, you learn:
There are two basic routes you can take with Internet site security. You can use some basic Internet smarts and other tricks to make your site as secure as possible, or you can set up a firewall to cut access off to most of your site from the outside world.
You can make a fairly secure site on the Internet without doing anything spectacular. The things you should consider doing are dissued in detail in the section "Setting up your Security." A brief list of what you'll want to consider is:
You can run a fairly secure site this way (and many sites of all sizes do), but this method isn't sufficient for people who have the need to ensure that no one can get into their systems. If you absolutely, positively have a need to keep people out, and have an extra computer to devote to it, see the next section on firewalls (instructions on installing firewalls are in Appendix E).
A firewall is like a one-way mirror. It lets your users see out of your site, but doesn't let anyone (even your users) see in from outside. The firewall acts as a central server, somewhat like directing traffic. It know where the packets for your services and your users all need to go, and routes them to the proper machines and ports accordingly. However, it looks to the to the rest of the Internet like all your servers are on that machine.
Running a site with a firewall is a lot of extra work for the system administrator (you), but worthwhile if you think a firewall is necessary. You have to implement many extra security measures on each computer on your network, and you can't allow users to install their own software.
You might want to use a firewall for one of the following reasons:
You also may not want to run a firewall for the following reasons:
If you intend to run a firewall, first go through the basic Internet smarts security setup in this chapter, and then see Appendix E for how to set the firewall itself up. After all, you'll still want some security on the machines behind the firewall! The next section covers how to set your basic security up.
Now that we've talked a bit about the kinds of security options you have, and why you might or might not want to go as far as using a firewall, we can get started on setting everything up. If you're not sure whether you want to use a firewall, you can see how happy you are with the security on your site as it stands after the basic setup, and then make the decision.
You can take a number of simple precautions to increase your site's security. The idea is to deadbolt as many doors as you can and to make sure the rest are securely locked and the keys are properly protected.
One huge security hole most system administrators have to deal with is that of user passwords. Of course, it's imperative that intruders not be able to guess a user's password.
Initially, you need to ask the user for a password to use for the first login. Be sure to emphasize that this password should be changed as soon as possible to prevent anyone breaking into the user's account.
If you offer SLIP accounts without shell account access, you'll have to handle changing their passwords for them! Or, you can let them telnet in and use their limited shell account and use the passwd command from there.
One of the initial pieces of e-mail you send to your users should be a guide to selecting passwords. Remember, the more informed your users are, the better choices they will make and the better off your site will be! Many passwords are poor because they can be readily obtained by someone who takes the effort to learn about your users (see table 12.1).Table 12.1 Passwords That Make for Poor System Security
Type Examples Family Names Your name, your spouse or significant other's name, any of your parents', pets', or childrens' names. Other Names Your friends' names, coworkers' and boss' names, names of favorite fictional or historical characters. Names in general are a bad idea. System Related The name of your computer, operating system, site, user name. Personal Information Your phone number, social security number, birthday, or other easily found personal info. Dates Any birthday of your friends or family. Your wedding anniversary or favorite holiday. Ego Trips Don't choose anything like God, Wizard, famous wizard's names, famous leaders' names or titles. General Because so many system break ins happen due to people having access to programs that simply try passwords one by one until they get into an account, it's really best to avoid any of the following: words from the English dictionary, words from any foreign dictionary supported by your system, place names, or proper nouns. Also, avoid any of the words listed in any of these dictionaries spelled backwards or with a number at the front. Garbage Passwords of all one letter, or simple junk keyboard patterns like asdt.
The best choices for a password are acronyms or two unrelated words placed together. You can also intersperse numbers and any other keyboard characters. An example is TMY[af]1stacc (This Is My first account), where you've got acronyms, a non-letter character, a number, and abbreviations. Of course, now that I used this here, it's a bad password, so choose another one!
Pretty much anyone breaking into your system knows to do whatever they can to try to get the /etc/passwd file. If they do that, they've got every password for every user and process on your site. Of course, the passwords in this file are encrypted, but people have access to the encryption program and can just compare items they encrypt themselves to the ones in your file. This is one reason why it's so important not to choose a password that's easy to guess!
Remember, your /etc/passwd file has to be world-readable! That's not really the best security, because anyone can read the file. If everyone can read the file, they can also copy the contents. Then, they can try to decode the passwords contained in this file, and the encryption used in /etc/passwd isn't as secure as most of us would like.
To better protect the passwords for your site, you can replace the standard password system with Shadow passwords. This program keeps your password file in a separate file that doesn't have to be world readable, and that has better encryption.
Of course, there are down sides to using shadow passwords. You need to compile a few of your servers so that they don't look in the /etc/passwd file for your user passwords. You can't use the adduser command to add a new user to your system because the standard adduser utility looks straight at the /etc/passwd file. I will walk you through how to deal with these things once you have shadow passwords installed.
The first part of installing shadow passwords is to save things out so you can easily uninstall shadow password's changes, so it's not that risky of a change to your system.
I highly recommend that you install shadow passwords to make your system more secure. It's worth the extra work.
If you want to use or try shadow passwords, you need to install the shadow passwords package. First, to prepare for the installation, do the following:
You can restore the old nonshadow binaries by typing make restore in this directory.
Now, to compile and install shadow passwords on your system, do the following (you are logged in as root, in the shadow-mk directory):
Finally, you need to perform a few housekeeping tasks to complete your shadow passwords initial setup (you are logged in as root, in the shadow-mk directory):
Some of the programs you run on your system will no longer work with shadow passwords. Basically, any server that needs to handle logins-and, hence, passwords-needs to be recompiled to handle shadow passwords (e.g. FTP). All the source for the binaries on the CD-ROM is also included there. Often there's an option in the Makefile itself to set to compile for shadow passwords.
The adduser script automatically uses the /etc/password file, so you need to replace it with something that will use the /etc/shadow file. Fortunately, the Shadow Passwords package comes with a program you can use! From now on, while adding users, use the program useradd instead of the program adduser. The program useradd understands how to handle shadow passwords.
For more on the /etc/shadow file see the man page for shadow (man shadow) and the man 4 page for shadow (man 4 shadow).
Now is the time to decide what you want people to have access to from outside your site and individual machines. Be careful not to cut yourself off completely because you might want to telnet into your site to maintain it if you're away.
In the file /etc/securetty is the list of all the ttys (the specific terminal addresses each login session uses) that are considered secure enough that people can log in as root from them. It is important not to allow root logins from just anywhere, because it becomes too easy for people to have a chance at trying to get your root password. The terminals you want to allow access to are the straight tty ones (e.g. tty1, tty2, and so on). Even there, you may not want to limit how many of those people can log into root from. In a typical Linux setup, tty1 through tty12 are your function keys. Therefore, if you only allow tty1 through tty6 to log in as root, you can only log in as root with function keys F1 through F6.
You cannot log in as root from terminals not listed in the securetty file, but you can su (superuser) into root. By typing su you can temporarily act as though you're in another account. Typing su by itself means you're trying to superuser into root. To su into another account you'd use su userid (e.g. su joe). You'll be asked for the account's password, then you're in.
While this fact may seem to make the security measure useless, keep in mind that someone trying to break into your system would first have to get a password into another account before they could try for the root password. This slows them down a bit, which gives you more time to catch onto the problem.
To see what ttys you have available, go to the /dev directory and type ls tty* (see table 12.2 for an explanation of tty naming). All the files listed refer to a single terminal.
Table 12.2 Terminal Naming Conventions and Types tty Type Purpose tty Console login, directly from the keyboard. The numbering for ttys is in hexadecimal, so ttya, ttyb, and ttyc are actually tty10, tty11, and tty12. ttyS Serial login (e.g. modem) ttyp Telnet login
To add a tty, use the mknod command. Type ls -l tty* in /dev and look at the file listing. Notice that instead of a file size, there are two numbers listed separated by commas. The first number is the major number, and the second is the minor.
The major number is the same for every tty definition. For the minor number use the next one in the sequence for the particular tty type unless it is already being used for another tty definition.
For example, if I wanted to add another modem dial-in terminal, and the last one available was ttys3, at 4, 67, I would type in mknod -m 660 /dev/ttyS4 c 4 68. This line breaks down as follows:
If you occasionally find the need to be able to log in directly as root remotely, you can choose one terminal to allow this from and then disable it again once the need has passed.
If you don't want outside users to have access to a specific service (for example, FTP), be sure to disable this access. See the chapter covering the service you want to limit for your options on limiting access to services (e.g., chapter 7 for your Web server).
If you decide that you don't want to offer a service at all, don't install the server or disable it. To make sure the daemon isn't running, go to the appropriate file (e.g., /etc/inetd) and comment out or remove the line that refers to the server, and then be sure the process is killed:
Be sure to remove the item from the file that starts it up in the first place. Otherwise, it will restart the next time you reboot your system.
It is important to keep up with Linux security issues. When a security hole is found, information is broadcast along a few channels to let sysadmins know about it. Unfortunately, in explaining how to correct the problem, the problem itself must be revealed. So, if you don't fix the problem at your site, suddenly you become vulnerable to attack along the lines of the correctable problem.
You can join two mailing lists to keep track of security issues:
If you want to subscribe to only one of these lists, subscribe to linux-alert. You may still want to take a look at the archives for the linux-security list on occasion to keep up-to-date on current happenings.
Testing your site's security is a good way to make sure to catch any holes. One excellent method of testing security is the SATAN program (see the section on SATAN later in this chapter for information on installing and using this program).
The reason SATAN is such a useful tool is that it finds your security holes and tells you how to fix them! It's also important to use SATAN to test your system because people outside your site can also use it on your system. It's better to catch the problems yourself and fix them than to have an intruder find the problems first and exploit them.
One interesting security avenue to follow is locating hacker FAQs on the Internet. Try searching the Web for hack, and generally asking around to locate them.
There is a program on sunsite.unc.edu in /pub/linux/system/admin called Crack. You can use it to check the passwords on your site and see how many of them it can figure out (how many it can crack). Then, notify the users whose passwords you found that they need to change them, and give them suggestions on how to choose a secure password.
You can use SATAN to test your system security. It attacks a good number of entry points to see if it can get anywhere, and then reports back to you to let you know how far it got, and how to seal up the holes. This is definitely worth doing!
We couldn't include the source for SATAN on the CD-ROM, so you will need to FTP it. You can find the file satan-1.1.1.tar.gz (or .Z) at:
Site Directory coast.cs.purdue.edu /pub/tools/unix/satan/ ciac.llnl.gov /pub/ciac/sectools/unix/satan/ ftp.acsu.buffalo.edu /pub/security/ ftp.cerf.net /pub/software/unix/security/ ftp.mcs.anl.gov /pub/security/ ftp.net.ohio-state.edu /pub/security/satan/
Once you have the source, move it to where you prefer to compile things, un-gzip (or uncompress if it's a .Z file) it, and un-tar it. It will create the directory satan-1.1.1.
You first need to apply the patch file on the CD-ROM to the source. This file is /. Copy it to into the directory where your satan-1.1.1 directory is.
To use SATAN you need to have Perl installed. It's on Slackware's disk d10.
Keep a clean compressed copy of SATAN around in case something goes wrong as you're patching it.
Now, do the following (as root) to apply the patch:
Now it's time to compile SATAN. Fortunately, it's got compiling rules for Linux, so we don't have to port it from a generic UNIX version!
You must compile SATAN on a machine that has a Web browser.
Do the following:
Now, let's test out SATAN! First, to configure it, do the following:
Fig. 12.1 The SATAN Control Panel in Netscape.
Fig. 12.2 The SATAN Configuration Management page.
Now, to actually test out SATAN:
Fig. 12.3 The SATAN Target Selection page.
Fig. 12.4 The items SATAN scanned on my server.
Fig. 12.5 The menu page for the reports SATAN generated.
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation
