oreilly.comSafari Books Online.Conferences.


Beyond Firewalls

by 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.

Risk assessment

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.

Checking connectivity

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.

Inet daemon

/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 /etc/services), 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? Yet, 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 inetd daemon.

If you do need to run some of these services, you may want to look at xinetd instead of the regular inetd daemon. 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 xinetd or 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 /etc/inetd.conf.

Pages: 1, 2

Next Pagearrow

Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: