Do s and Don ts (Common Gotchas)

Do's and Don'ts (Common Gotchas)

Every operating system has numerous pitfalls ready to snare the unwary. These pitfalls can be particularly dangerous when the system is newly installed or when the administrator is new to FreeBSD. This section lists some of the most commonly made errors and some of the most valuable pointers for effective FreeBSD administration.

DO:

• Do use the ports and packages to install software. It's possible to grab the source for a particular program directly from the developer and compile it using its built-in scripts, but that just risks polluting your core-system userland if the program's installer doesn't know about FreeBSD's filesystem structure. If the program isn't available as a port, post to the [e-mail] mailing list and ask for it, or you can even learn the porting process and become a maintainer yourself.

• Do pay attention to the nightly, weekly, and monthly periodic output messages. Any setuid executable differences are flagged in the security report. The messages also alert you to filesystem usage, rejected mail hosts, and many other forms of visibility that are an effective "closed-circuit TV" against intruders.

• Do become familiar with CVSup. CVSup is your friend. Not only can it keep your source and ports in sync at all times, it can also serve as an effective mirroring solution, as you learn in the section "Mirrors," a little later in this chapter.

• Do install sudo (/usr/ports/security/sudo) and promote its use instead of running as root directly, especially if you share administrative duties with others. The sudo program (invoked as a prefix before a regular command) allows you or other users to execute commands with root privileges without knowing the root password; it works by prompting the user for her own password, and then checking to make sure the user is listed in the /usr/local/etc/sudoers file as a valid administrator, before executing the command as root. You can also use the sudoers file to establish certain allowed programs or commands to be run through sudo. This allows you to keep the all-important root password as secret as possible, and to limit the destructive potential of an all-powerful root login, while still allowing you to share administrative duties effectively.

• Do use ntpd and ntpdate to synchronize your system's clock so that all the system logging and scheduled processes in FreeBSD that depend on the time being accurate can operate properly. You can do this by adding the following lines to /etc/rc.conf:

  ntpdate_enable="YES" ntpdate_flags="tick.usno.navy.mil" ntpd_enable="YES"

  Tip

  Other time servers you can use are listed at http://ntp.isc/org.

  
  

  You can use any NTP server you like for ntpdate, which runs at boot time and corrects any gross time discrepancies before other services have a chance to run. You should also create an /etc/ntp.conf file to control ntpd, which runs as a daemon and keeps your clock synchronized with the specified NTP server (or servers) on an ongoing basis. See man ntp.conf for details on creating that file. At a minimum, it should contain the following lines:

  server     tick.usno.navy.mil driftfile     /var/run/ntp.drift

• Do be nice to the FreeBSD committers. There are only 15 or so of them, and the responsibilities of the entire operating system rest largely on their shoulders (as opposed to the collective shoulders of thousands of independent developers and distributors of Linux, or the corporate shoulders of Microsoft). That's a lot of responsibility. Be a cooperative and supportive user.

• Do decide what kind of security model you're going to have. Do you trust all your users? If so, you can get away with leaving a lot of system-level resources viewable. This way, you won't have to worry as much when you have permission-collision problems (such as web applications that must store clear-text passwords or write to a world-writable directory). If you don't trust all your users, though, you'll have to be much more careful. However, it's always best when running a networked server to lock down as much external security as you can. Even if you trust your local users, as long as your machine is on the Internet, it will be interesting to those who would like to break into it. See Chapter 30 for a fuller discussion of security in a networked environment.

• Do subscribe to the appropriate mailing lists for your version of FreeBSD. Unquestionably, you should be on [e-mail] if you're running a server; [e-mail] and [e-mail] are also useful. If you're tracking the STABLE or CURRENT sources, subscribe to [e-mail] or [e-mail] accordingly.

• Do monitor the size of your log files. Apache's httpd-access.log and httpderror.log are notorious for eating up disk space if your web server gets any kind of significant traffic. Use Apache's built-in rotatelogs utility or run a cron job to flush the logs occasionally. If your /var partition fills up, your mail, databases, and runtime files will not work.

  Also, do be sure to read your logs! The system isn't just writing out all that data for its health. Well, it is, actually, but it only works if you pay attention to what the system has to say.

• Do fly the Daemon banner proudly!

DON'T:

• Don't use experimental features on a production server. This isn't the place to try out new ideas such as GVinum and unsupported filesystem kernel modules. Try these things out on a cheaply built "hobbyist" machine or a mirrored "backup" server; then put them into practice only once you're comfortable with their use.

  Beware, however, that if your test environment is not absolutely identical to your live machine, you run the risk of software failing in the production environment even if it worked on the test bed.

• Don't forget to add yourself to the "wheel" group at installation time! Very little is more disheartening than building a new server, driving 50 miles to the co-location facility, locking the server in a cabinet, driving home, trying to log in, and discovering you can't get root access.

• Don't get hung up on uptime. If a system has 350-day uptime, it sounds cool, but it also means the system has been sitting unused in a closet for a year or has not been conscientiously upgraded to keep up with security bulletins. Nonstop uptime doesn't make for such great bragging rights as one might think.

• When probing your server for weaknesses, be careful to avoid triggering defense mechanisms such as PortSentry which block remote access from an attacking IP addressyou might find that you've locked yourself out of your own server. If you're accessing the server from a static IP address, you might have to find an alternative location from which to access your server and reset the "blackhole" routes before you can access the server again from the original location.

  Try to be aware of any action or situation that might block remote access to your machine. If that happens, you'll require physical access to the machine in order to restore remote access.

• Don't use shutdown to drop to single-user mode (for high-privilege activities such as replacing the kernel) if you're using an older FreeBSD version that's running with the securelevel setting at 1 or higher. Using shutdown won't decrement the kernel security level. Instead, reboot the machine and enter boot -s at the loader prompt to boot into single-user mode. Simply exit the single-user shell to come back up the rest of the way. You must boot into and exit from single-user mode at the physical consoledon't do any of this stuff remotely!

• Don't make a habit of using filenames with spaces in them. This can be done with backslashes in front of the spaces, as with any other special character (for example, My\ Document.txt). There's no guarantee, however, that software will handle the filenames properly. Most of the time, it willbut all it takes is one shell script that didn't properly quote an embedded command line and you risk having your files get deleted or overwritten with files named things like My and Document.txt.

• Don't write Perl or shell scripts on a local Windows machine and then upload them in binary mode over FTP, rather than in ASCII mode. Binary mode prevents proper translation of end-of-line characters, which occurs properly in ASCII mode. Although the body of the uploaded script might look perfectly fine, the return character at the end of the very first line (#!/usr/local/bin/perl) will be unrecognizable to the shell and cause the script to fail.

  A much preferable method for transferring files is the secure scp, which avoids these pitfalls associated with FTP and is covered in Chapter 30.

• Don't use Telnet; use SSH instead, and (if at all possible) disable Telnet entirely so that your users can't expose themselves or you to the weaknesses of unencrypted terminal traffic. See Chapter 30 for more information on setting up SSH and disabling Telnet.

• Don't enable sudo without using a properly designed sudoers file that restricts administrative access to only what's necessary.

Tip

If you're having trouble with CGI programming and scripts that mysteriously fail after uploading, check the #!/usr/local/bin/perl script line first; then make sure you're uploading in ASCII mode. Better yet, do your programming directly on the server. Excellent text-editing tools (such as vim, pico, and emacs) are available for just that purpose.