Remove Unneeded Software
Disable Network Services
Install Secure Tools
Re-enable Desired Services
Before I could set up and "firewall" behaviors, I had to configure the basic operating system. Since this was to be a bastion of security, configuration mainly involved uninstalling, deleting and disabling software and services.
Removing Unneeded Software
As RedHat gets more and more commercial, they unfortunately resemble Microsoft more and more. For example, they increasingly assume that your entire disk is devoted to RedHat--in this case, that didn't matter. They also increasingly assume that you will be running X-Windows--in this case, a bad assumption. That saddled me with a minor annoyance: RedHat's configuration tools only operate under X-Windows. And a less minor annoyance: RedHat installs several things by default which are pointless without X-Windows.
RedHat's arrogance probably did not result in any security risks, but it annoyed me. Why would I want the GNOME libraries installed on a machine with no window managers? For that matter, why did RedHat even install their GUI configuration stuff, even though I didn't install X? And why was linuxconf installed, when I didn't ask for it (call me a dinosaur, but I don't trust it)?
The first order of business was to delete any unused software I could identify. That included the Apache web server, anonymous FTP and sendmail, since I had other ideas about those services. Obviously, anything pertaining to X-Windows had to go. So did kudzu--it looks cute, but I don't plan to go popping peripherals in and out of my firewall.
The most important things to remove are network services I didn't want to use. That included NFS, portmap, the finger server, the talk daemon, and the Berkeley rexec family: rsh, rcp and rlogin. Those services are a huge security liability, and really don't belong on a firewall. (While we're on the topic, I did not install NIS, either.)
Disabling Network Services
If you look through your inetd.conf, you'll be surprised how many network services your machine can offer. You'll probably be surprised how many it does offer! There are three problems with offering public services like this at all, let alone from a firewall machine:
First, each service is a door into your system. If any one of them is buggy or weak, somebody can exploit that weakness to crack your system.
Second, each service is an invitation to the public to use some of your resources. It is impossible to prevent people from using your service if you offer it. When somebody uses all of the service you offer, then there's no service left for somebody else; this is called a denial of service attack. By definition, then, every service you offer is vulnerable to denial of service attacks. If your service is not configured properly, then a DOS attack will not only put the service out of commission, but your machine as well.
Third, network services are often managed by the standard inetd daemon. This can be a problem for two reasons. First and foremost, inetd runs as root. Consequently, any weaknesses in inetd can potentially be exploited to crack your system. Secondly, inetd fails to mitigate the risk of DOS attacks.
I've already indicated that all services are always vulnerable to DOS attacks; that is a fact of life. The issue is that a DOS attack should temporarily disable the service under attack only--it should not be possible to disable the entire system with a DOS attack. Although inetd has certain features for mitigating DOS attacks, it is still possible to disable a computer running inetd.
Since an excellent alternative exists, I completely disabled inetd. That means that I completely disabled all network services, of course. However, selected services were re-enabled later.
Installing Secure Tools
Technically, a firewall should only protect your network and handle public services; it should not be accessible to users, and it should not run purely internal services. However, saving hardware is also a priority in my home LAN, so I stretched that point.
The first thing I installed was a DHCP server. Friends and co-workers are liable to visit and connect to my LAN, so this was a must. (They can't actually use my LAN anyway, until I switch to 10baseT. Which I'll do when somebody buys me a hub.) I installed the server according to the directions, and set it to reserve fixed addresses for each of my NICs at home.
Almost everything else I installed was written by Professor Dan Bernstein of UI Chicago. This was not intentional sycophancy, even if my high opinion of his work gives that impression. His qmail email software, a replacement for sendmail, is famous for never offering attackers an exploitable security hole. Qmail is also a model of reliability.
My affection for the rest of Dan's software grew out of the qmail experience. After getting used to his style with qmail, I started to find his tools natural and usable. And, of course, qmail's well-deserved reputation for security and reliability led me to trust Bernstein's abilities in that direction.
Enabling Network Services
The first things I installed were Dan Bernstein's daemontools and ucspi-tcp. Daemontools is a set of general-purpose tools for running daemons. For example, supervise is a replacement for init--it runs another program, and restarts it if it dies. The softlimit runs a program after setting resource limits in the OS--eliminating the need for various daemons to know about resource limits. Ucspi-tcp is a set of tools for running network services. For example, tcpserver is a replacement for inetd--it listens to a port, and runs a specific program whenever a connection is made.
First I downloaded the packages, and installed them according to instructions. Then I arranged for any network services to be run by those tools instead of by inetd.
To give a taste of the process, I've provided instructions for running telnet under tcpserver. On my firewall, I only allow telnet connections from inside the LAN. This rule will be enforced by the firewall, but it is also enforced by tcpserver--just one of its attractive features.
When all is said and done, exactly three network services will be accessible from the Internet: FTP, HTTP and SSH. Those services will also be accessible from the internal LAN, of course. In addition, internal hosts will have access to DHCP, POP3, SMTP, telnet and the printer. Here, briefly, is what I did for each of those services.
FTP and HTTP. I don't really need to offer these to the Internet at all, so here I'm actually making a security mistake. I should be offering these services only internally. Anyway, I uninstalled Apache and wu-ftpd, and replaced them with Dan Bernstein's alternative package called publicfile. They are virtually certain to be safe, security-wise, and I will want to offer those services in two years when cable modems come to my town.
SSH. For philosophical reasons, I installed OpenSSH. Openssh is an ssh clone, based on an older version of Secure SHell which had an unrestrictive license. It is compatible with the original SSH, and is likely to be more reliable and secure, since the paranoid folks at OpenBSD are maintaining it.
To install OpenSSH, I downloaded the Linux source RPM, and built the RPM on my desktop machine. Then I transferred the new RPM to the firewall and installed it. (Since SSH is also my FTP substitute, I actually did this before disabling the standard FTP server. Dan's server does not permit any file uploads at all.)
DHCP and printing. These are standard services provided with RedHat; all I did was enable them.
SMTP and POP3. The first thing I did was uninstall sendmail. Sendmail has a bad history of security and reliability problems, it's a devil to configure, and I just don't like it. Instead I installed Dan's qmail package as my SMTP server. The included pop server, qmail-pop3d, seems to be adequate for my modest needs.
Since my ISP uses qmail, I decided to forward outgoing email through their smarthost using Dan's serialmail package. That way emails can be spooled, and pushed out whenever the the firewall is connected to my ISP.
It's a pretty standard thing to set up email store-and-forward using serialmail, so I won't explain it here. Except to remark that I run maildirsmtp from /service, like telnet. In this case I set the default state of the service to "down", and activate the service whenever the firewall is connected to the Internet.
