last thing, after everything's started. What if he were to create a shell script that kills the running /etc/rc before it can raise the securelevel, then turns around and starts his own /var/.hidden/rc.rootkit to finish bringing up the network?

Of course, this is only one path—there are others. The thing to remember is that system security is a thorny problem, with no one easy solution. Once intruders have a command prompt, it's you against them. And if they're any good, you won't even know that they're there until it's too late. And, of course, it's always better to keep intruders out of your castle than to try to get them out of the corridors.

Living with Securelevels

If you've been liberal with the schg flag, you might find that you can't upgrade (or even patch) your system conveniently. The fact is, the same conditions that make hackers’ lives difficult can make yours a living hell, if you don't know how to work around them. So how do you work around them?

If you've protected your /etc/rc.conf with schg, you'll first have to lower the securelevel to edit your system. Of course, the securelevel setting is in that file, so you'll need to take control of the system before /etc/rc runs in order to edit that file.

To do so, follow the procedure for booting into single−user mode (explained in Chapter 3), and mount the affected filesystems. Since at that level the securelevel has not been set, you can mount your filesystems, run chflags noschg on the affected files, and continue booting. You can even edit /etc/rc.conf to disable securelevels, and let it boot normally. (You'll restore service more quickly that way, but lose the file flags’ protection.)

Once you've finished maintenance, you can raise (but not lower) the system's securelevel without rebooting using the sysctl command:

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

# sysctl −w kern.securelevel=[desired securelevel]

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

Now that you can control file changes, let's take a look at controlling access to your system from the network.

Programs That Can Be Hacked

As I mentioned at the beginning of this chapter, it's generally not the operating system that gets hacked, it's the programs running on it. Of these, network programs are the biggest target, and the question then becomes, "How do I tell which programs are running on the network?" Answer: with sockstat(1).

Sockstat(1) is a friendly FreeBSD tool that determines which sockets are open on a system and which programs are listening on those sockets. It shows both connections that are running right now and connections that are available for people to talk to.

A socket is simply a "logical device" that is listening for a connection. You can have a socket listening to the network; those are the network ports I talked about in Chapter 5. You can have

153

sockets listening on IP version 6 networks, which are IPv6 sockets. Finally, you can have sockets listening on the local computer. Programs can create sockets to communicate with one another.

If you don't have an IPv6 network, you don't need to worry about IPv6 sockets. Similarly, UNIX sockets aren't an issue over the network; you must be logged on to the computer to talk to a UNIX socket, and you have to get through all the standard UNIX permissions to do so. If your intruder can do that, you're already in trouble. So, we'll look at the open IPv4 network sockets by running sockstat −4 in the following snapshot taken from my laptop:

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

#

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

Each line in the preceding listing represents either one open socket awaiting a connection or an established connection. (It looks a lot like netstat −na, doesn't it?) Most of the columns are fairly self−explanatory. USER is the user running the process, COMMAND is the command name, and PID is the process ID number of the particular process holding that socket. The command name is very helpful in securing the system. FD is the process's file descriptor—you don't have to worry about that right now. The PROTO column is the Internet protocol the connection is using. Finally, the LOCAL ADDRESS and FOREIGN ADDRESS columns show the IP addresses and port numbers on each side of the connection. If you have an IP address and port number in LOCAL ADDRESS and FOREIGN ADDRESS, you're looking at an existing connection. When the FOREIGN ADDRESS column shows two asterisks separated by a colon (*:*), that program is listening for incoming connections.

In the preceding example, I'm using ssh to connect to a remote system from the laptop. Ssh isn't actually listening for incoming connections; sockstat shows only a connection I made to another server. Four services are listening for incoming connections on the laptop: X is listening on all of the local IP addresses on port 6000/tcp; an snmp daemon is running on port 161/udp; and lpd and syslogd are listening for incoming connections.

Here's the important part. Every network port you have open is a potential weakness and an attacker's targets. Shut down unnecessary network services and secure the ones you must offer.

Got it? Good.

Note It's a good idea to regularly check which ports are open on your systems, because you might learn something that surprises you. For example, I installed net−snmp to get snmpwalk and related commands and completely forgot that it also installed the snmp daemon, which should be shut down and not started again at boot.[5]

Examining sockstat output on a laptop is pretty straightforward, but the output for an Internet server is another thing entirely. A small server can have hundreds of lines of output. For example, here's a listing for a very small server:

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

154

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

The function of some of these open ports is obvious; some are not. For example, while you'll probably recognize httpd and sendmail, what are all those open inetd ports?

To find out, "grep" the /etc/services file (see Chapter 5) for a port number, to see what service name it is using. For example, the service that's running on port 110 is curious (v). Grep searches for lines that match a pattern, so in this case we want to find all the lines that contain the string of characters "110". Grepping for port 110 gives us this series of lines:

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

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

The grep returns several lines that include 110, but we ignore the ones that include obvious wrong matches. For example, the third and fourth lines include the string "110", but only as a reference to port 1110. The first two lines tell us that the service is pop3, which we will discuss in Chapter 12. A quick check of the FreeBSD mailing list archives shows that pop3 delivers mail to desktop clients such as Eudora and Outlook.

Note If you don't know what a service is, you can either search for it on the Net or shut it off and see what breaks. While I've used both techniques successfully, researching is better in the long run.

You can use this technique to identify the other services provided by inetd. (Inetd itself is discussed in Chapter 12.) We also have several instances of httpd (w), a Web server. There's one ssh daemon

155

listening on port 22 (x), and one that's listening on port 80.[6] You'll also see lots of named entries listening on port 53, and one on 2151. We'll discuss each of these programs later, as we get into discussing the various network services FreeBSD can offer. The important thing for you to realize here is that each server program listens on a network socket, and you can identify those programs with sockstat(1).

So, now that you know what's running, how do you turn things off the ones you don't need? The best way to close these ports is not to start the programs that run them. Network daemons are generally started in one of two places: either /etc/rc.conf or a startup script in /usr/local/etc/rc.d. Programs that are integrated with the main FreeBSD system, such as sendmail, ssh, and portmap, have flags in /etc/rc.conf to enable or disable them (see Chapter 9). Add−on programs, such as Web servers, start via scripts in /usr/local/etc/rc.d (see Chapter 11). The inetd program is a special case, though, since its purpose is to start smaller, rarely used programs. While inetd as a whole is enabled via an rc.conf flag, the programs within inetd must be started and stopped from within inetd. To learn how to enable and disable inetd programs, see Chapter 12.

To remove unnecessary network services, run sockstat −4, and identify each process. Once you determine which ones you need, mark them and disable the rest; then reboot to be certain your changes will take effect. If, when you check sockstat again, you're happy with the result, you're done. Otherwise, go back to the beginning.

[5]"What is SNMP?" I hear you cry. See Chapter 19. "And how do I shut it down?" See Chapter 11. [6]A variety of firewalls can be bypassed by sending traffic over port 80, the TCP port used for Web traffic. If you have an Internet server outside such a firewall, you can run sshd on port 80 on that server and connect from within the firewall. While a firewall that relies solely on restricting port access cannot stop you from connecting in this way, that firewall is a definite hint that you're not supposed to be using services that they've tried to block. This sort of cleverness can get you fired.

Putting It All Together

Once you have only necessary network ports open, and you know which programs are using them, you know which programs you have to be concerned about securing. If the FreeBSD security team sends out an announcement of a problem with a service you don't run, you can safely ignore it. If the security team announces a hole in a program you are using, you know you have to pay attention. This will protect you against most of the script kiddies out there. Tools such as file flags and securelevels will help minimize the damage attackers can do if they do break in. Finally, using groups to restrict your own systems administrators to particular sections of the system can protect your computers from both accidental and deliberate damage.

Next, we'll look at some of the more advanced security tools FreeBSD offers.

156