Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Beyond Firewalls

by Carl Constantine
03/30/2001

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.

Controlling other services

Some programs, like the Apache web server, do not use TCP Wrappers and so the HTTP protocol is not listed in /etc/inetd.conf. Other server programs, notably Exim (a mail server), can be compiled to use the TCP Wrappers or not. These programs use built in security measures that make using TCP Wrappers redundant. However, you need to know what you are installing, what it does, how it does it, and what changes you need to make in the configuration or compilation to make the software secure. If you don't know what a software package does, DO NOT INSTALL IT. Do your research first. Find out if other people are using the software and what their experiences were. Find out if there are any outstanding security advisories for the software (this applies to any piece of software, not just server programs).

Again, watch web sites for updates and other information about security problems and fixes. This is time well spent. Remember, it's your job to know about each program that runs on your computer(s).

Access control

One area often overlooked in security is the use of access control files. Two main files, /etc/hosts.deny and /etc/hosts.allow control who can access a given system, how they can access it, and from where they can access it. These two files are set up as an access pair with hosts.deny being read and used first and then hosts.allow. Simply put, /etc/hosts.deny should be set up to deny everyone from accessing your computer. Then, add the specific hosts that can access your system to hosts.allow. Generally, you only want your internal network to be able to access your system and nothing else.

Here is a typical hosts.deny file:

#
# hosts.deny	This file describes the names 
#       of the hosts which are *not* allowed to 
#       use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to 
# remind you that the new secure portmap uses hosts.deny 
# and hosts.allow.  In particular you should know that 
# NFS uses portmap!

ALL:ALL

The line ALL:ALL means that all services from all hosts are denied access. Now, look at hosts.allow:

#
# hosts.allow	This file describes the names 
# of the hosts which are allowed to use the 
# local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#

ALL:LOCAL

The use of LOCAL refers to the loopback interface and to unqualified hostnames; hosts without a dot in their name or hostnames without a domain name. For better security however, it's best to address your internal network specifically like this:

#
# hosts.allow	This file describes the names 
# of the hosts which are allowed to use the 
# local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#

ALL:10.0.0.0/24

Once again, if this is a server machine, you might want to allow access to specific services such as SSH or POP3 from specific machines on your network, like this:

# hosts.allow	This file describes the names 
# of the hosts which are allowed to use the 
# local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#

sshd: 10.0.0.5
ipop3d: 10.0.0.5

Resources

Web sites:

Security Portal

Linux Administrator's Security Guide

Root Prompt

Linux System Administrator's Guide

Books:

Maximum Linux Security (SAMS) ISBN: 0-672-31670-6

Linux Network Administrator's Guide, 2nd Edition (O'Reilly) ISBN: 1-56592-400-2

Practical Unix and Internet Security (O'Reilly) ISBN: 1-56592-148-8

Running Linux, 3rd Edition (O'Reilly) ISBN: 1-56592-469-X

Linux System Security (Prentice Hall) ISBN: 0-13-015897-0

In this example, only the machine with IP address 10.0.0.5 can access SSH and POP3.

You can set up rules that are considerably more complicated and restricted, but the above examples should give you a general idea. Take a look at host_access(5) for more details as well as a good book on system security.

Summary

OK, so you've done everything I've talked about here. You've got a firewall up and you've plugged some common security holes. You're finished with your security checks for all your systems, right? WRONG! There is still much more that can be done. Install Tripwire on your firewall and servers to monitor if anyone tries to break in. Set up a good VPN system such as FreeS/WAN to secure traffic between remote sites or even between two different subnets of your existing network. Upgrade from your existing IPCHAINS firewall to the newer IPTABLES and Netfilter that's part of the 2.4 kernel. Maybe set up a proxy server for all your regular Internet traffic.

I'll explore each of these options in upcoming articles. As to which one is next; you'll just have to stay tuned and watch for them here.

Carl Constantine works for Open Source Solutions, Inc. (www.os-s.com) as a Linux Trainer and Programmer.



Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.