through the various files.) To determine which jail a process is part of, first find the directory for the process ID you're interested in, and then look for a file named status. The last word in the status file is the host−name of the jail the process is running in. If the process is not jailed, the last word is a hyphen (−).

Shutting Down a Jail

When you shut down the host server, the various client jails are shut down as well. Shutting down a jail without shutting down the host is only slightly more complicated.

Programs such as shutdown(8) and reboot(8) are useless for shutting down a jail because their main responsibility is to sync and unmount disks, disconnect the network, and so on. A virtual machine does not have those responsibilities.

To shut down a jail, first log in to the jail as root. If your jail is hosting programs that like a nice, safe shutdown, such as databases, you should run the shutdown script to shut them down.

...............................................................................................

#/bin/sh /usr/local/etc/rc.d/programname.sh stop

#/bin/sh /etc/rc.shutdown

...............................................................................................

Once that's done, send the jail's main process (−1) a shutdown signal, also known as signal 15.

...............................................................................................

# kill −15 −1

...............................................................................................

This will shut down all jail processes. Since a jail is only processes, the jail will be shut down at this time.

Note Do not do kill −15 −1 on a nonjailed server. You'll shut down lots of stuff, leaving your system in a fairly useless state similar to single−user mode.

Monitoring System Security

So, you think your server is secure. Maybe it is, for now.

Unfortunately, there's a class of intruder with nothing better to do than to keep up on the latest security holes and try them out on systems they think might be vulnerable. Even if you read FreeBSD−security religiously and apply every single patch that comes along, you might still get hacked some day. While there is no way to be absolutely sure that you haven't been hacked, the following hints will help you be aware when something does happen:

∙Be familiar with your servers. Run ps −axx on them regularly, and learn what processes normally run on them. If you see a process you don't recognize, investigate.

∙Take a look at your open network ports via netstat −na and sockstat. What TCP and UDP ports should your server be listening on? If you don't recognize a port, investigate.

183

Perhaps it's something innocent, but it might be an intruder's backdoor.

∙Unexplained system problems are a hint as well. Many intruders are ham−fingered klutzes with few sysadmin skills; they use click−and−drool attacks and think that they're tough. (Truly skilled intruders can not only clean up after themselves, but also ensure that the system has no problems so that you won't be alerted.) Unexplained reboots might be a sign of a new kernel being installed. They might also be a sign of failing hardware or bad configuration, so they should be investigated anyway.

There are two security tools I particularly recommend for becoming familiar with your system. The first is lsof(8) (/usr/ports/sysutils/lsof), which lists all open files on your computer. Reading this is an education in and of itself; you probably had no idea that your Web server opened so much crud. Seeing strange files open indicates that you're either not familiar with your system or someone's doing something you probably don't want her to do.

The second tool is nessus(8) (/usr/ports/security/nessus). It's an automated vulnerability scanner. Running security audits on your own machines is an excellent way to see what an attacker might see on your systems.

If You're Hacked

There's no easy answer for what to do if your system is hacked. Huge books are written on the subject. Here are some general suggestions, however.

First of all, a hacked system cannot be trusted. If someone has gained root access on your Internet server, she could have replaced any program on the system. Even if you close the hole she got in through, she could have installed a hacked version of login that sends your username and password to an IRC channel somewhere. Don't trust your system. An upgrade will not cleanse your system, as even sysinstall and the compiler are suspect.

Feel free to write FreeBSD−[e-mail] for some advice. Describe what you're seeing, and why you think you're hacked. Be prepared for the final answer, though: reinstall your operating system from known secure media (FTP or CD−ROM), and restore your data from backup. (You did read Chapter 3, right?)

A good security process will increase your chances of never being hacked. Good luck.

184