Beyond Firewallsby Carl Constantine
So you've taken the time to set up a firewall (you have set up a firewall haven't you?). Regardless of what firewall software you're using, you have to ask, "Now what?"
As I explained in my previous article, Securing Your Home Network With the Edge Firewall, a firewall is the first line of defense for a home network -- not the entire defense. Now you have to go through each computer on your network rigorously looking for problems and locking down everything as tight as you can. This is especially true for any server machines you may have running.
For this article, I'm going to focus a bit on how the underlying operating system plays a role in security. I'll also talk about a couple common problems in most default Linux installs and what to do about them. Finally, I'll talk about connectivity and access control and how it affects all your systems, not just your servers.
There are several things to look for in each system you have behind the firewall. Depending on the number of systems you have and how things are set up, security checks can be a daunting and time-consuming task. This is often why many people don't do it: They think they've done enough by just having a firewall. However, ignorance is not bliss. If you have only one system to check or ten, time spent early on will ultimately save you time, headaches, or even your job later.
To lock down each box, you must know its type and what it does. Is this box a server? If so, what kind of server -- web, FTP, SQL database, other? Is the server public -- can people outside the firewall access it through port forwarding -- or is it internal only? Is the system a workstation? What do you do on it? Does that box need to receive connections from outside? What operating system and version does the system use? Keep all these questions and any others you may think of in your mind as you continue reading. Write down the answers to each question on a sheet of paper. Keep one sheet of paper for each computer for easy reference later.
The operating system
The first place to start evaluating any security issues is the operating system itself. Many attacks only work against a certain version of an OS, or even a certain kind of operating system. For example, a Macintosh running any version of the Mac OS is less prone to outside attack than Unix or Windows systems. This is mainly due to the number of available exploits for the more popular operating systems as opposed to the Mac OS, but there are also other factors to consider in this example such as chip architecture.
A PowerPC running LinuxPPC is not as vulnerable to buffer overflow attacks as an x86 running Linux. In fact, the only attack I know of came about as part of a contest hosted by LinuxPPC to test its security. The winning entry exploited a known security flaw in a particular version of a Linux program, but the attack was specially written in PowerPC code and thus would not have otherwise worked. Needless to say this hole has been plugged.
For the purposes of this article, let's say that all systems behind the firewall are running some version of Linux. Now the question becomes, which distribution and which version of said distribution are you running? I've seen some attacks work on one Linux distribution and not another simply due to better setup with respect to access permissions (more on this later). The fun thing with operating systems is there are often many small programs that comprise the "core" operating system. You may be running the most current version of your favorite Linux distribution, but there could still be an exploitable attack in one or more of the applications that make up your OS. It's extremely important to keep up-to-date and watch your distro's web page for security information.
Another area to think about is version control. For example, I recently read an article that detailed the trials and tribulations of a company that had their system cracked. The administrators audited each box and found many of the systems didn't even run the same version of the operating system. In fact, some were running extremely old versions of the OS which helped in the crack attempt. While not a hard and fast rule, it's a good idea to keep all your computers running the same Linux distribution and version of the same. There are many reasons for this, most notably is that if you know one system, you know them all. Any security problems that crop up can be applied to all systems without trying to figure out if the security hole applies to the server machine but not Joe User's workstation.
Now before you start complaining that you run multiple versions of Linux for testing and development, I know many people do that. I've done it myself in fact. But those people are the exceptions rather than the rule.
Once you have the operating system issue under your belt, you're ready to begin tackling the finer details of system security. The first issue, and indeed one that encompasses the most work, is connectivity. Which systems on your network are servers? It doesn't matter if they are public or internal only as the same principles apply to both.
If you've set up your firewall correctly, all requests for web pages or FTP directories are being forwarded by your firewall to the "real" server which should have a non-routable IP address (see my firewall article for more information on non-routable IPs). The server accepts connections from the firewall and maybe internal machines and sends the information back along the same path. This server machine needs to be locked down as tight as you can to prevent potential crackers from gaining access.
I'm completely convinced that it's a wise idea to have a dedicated server box for each server type (web, FTP, etc.) instead of running multiple services from the same system. This does two things. First it gives you complete control over what kind of access is allowed to the server. Second, this setup allows for a bit of load balancing without expensive hardware. The file you need to look at and modify is
/etc/inetd.conf is a configuration file that's used by the
inetd super daemon that controls most of the services your system allows. Many Linux distributions enable a good portion of these by default, even when choosing tighter security options during the install process. Many of the services in this file are controlled through a package called TCP Wrappers which offers some security features. By using TCP Wrappers and
inetd, some Internet service daemons do not need to be running all the time. Instead, when the system detects a connection on one of the authorized service ports (controlled by
inetd starts a TCP wrapper that intercepts, verifies, and logs the request. If successful, the requested daemon runs to handle the connection and quits when done.
View an example of inetd.conf here.
Take a close look at that file. It's your job, or someone's in your shop, to know what each of these services are. If you don't know, you need to learn about them. Do you really want people to use
rlogin? Do you even know what
rlogin does? What about
Finger? Did you see the note just above the section on
Finger is enabled by default. Do you really want to allow telnet access from outside your network (you should use a version of Secure Shell, more often referred to as SSH, like OpenSSH if you need that kind of access). The answer to these questions is, probably not. If you're not using any of these services on that system, comment them all out or even better, disable the
If you do need to run some of these services, you may want to look at xinetd instead of the regular
xinetd is designed as a secure replacement for
inetd that can be used by any user to start services that do not require privileged ports. Once again, using
inetd is a function of what that machine is used for. On a firewall, you should only run SSH and no other services. They should be commented out or even removed from
Pages: 1, 2