Securing the Server
A key aspect of a firewall is the security
of the firewall itself. If it is not secure, it is comparable to locking all the doors to your
house, but leaving the key under the mat. Therefore, taking the key with you, or for that matter
throwing it away is a much safer alternative.
So what do I mean when I say "throwing away the key"? Well, what I mean is that you eliminate all
potential routes that an intruder can use to get through the firewall or from the firewall to the
internal network. Granted, your security should be
sufficient enough that the intruder cannot get into the firewall in the first place. However, you
need to plan for that possibility.
The question is not whether I am too paranoid, but rather whether I am paranoid enough. To me,
not making the firewall machine secure is comparable to locking all the doors and writing your safe
combination on the wall next to it. Okay, the house is secure, but should someone break in,
they have free run of all your valuables.
So, let's first talk about locking the doors.
The purpose of your Internet gateway
is to provide a gateway to the Internet. Sounds simple enough, but what that means is not always
clear. The question you need to answer is "What is the purpose of the Internet connection?" The
answer to which will define what steps you take to secure the firewall.
For example, let's assume that you have a Internet connection so that your employees can connect
to the Internet, but do not provide any services yourself. In this case, you do not need to enable
services on the firewall such as FTP or HTTP. All that happens is
packets are routed through the firewall. Therefore, you can remove the daemons themselves (i.e.
telnetd, ftpd, httpd, etc) and the programs (telnet, ftp, etc.). To simply disable them, place a
pound sign in front of the appropriate entry in /etc/services.
This is where a lot of controversy occurs. In a article I wrote for a number of years ago, I describe the
procedures as "throwing away the key", in that the programs and daemons were physically removed
from the machine. Some people disagree and say to move them to a place that the normal user would
not have access to. The reason being the difficultly in administering the system should these
programs be needed.
Despite the respect I have for their technical capabilities, I have to disagree with him on this
point. Although he is correct that it does make the administration more difficult, there are two
important security issues involved. First it makes hacking more difficult. If
these programs are not on the machine, they cannot be compromised. You have, in essence,
thrown away the key.
The other issue is that hackers are not normal users. They are sneaky, plodding and
patient. Maybe you have hidden the file on the system, but a good hacker isn't thwarted by such
simple tricks. I wouldn't be and I am not even a good one. If a program was not in it's original
location, the first thing I would do is to see it was anywhere on the system. I have seen
administrators simple rename the file to something like telnet.orig so simply starting telnet, does
nothing.
My attitude is that it is better to err on the side of inconvenience than on security.
If you discover that access is too inconvenient, you can always change it. However, if you discover
that the security is too lack, it's too late.
I apply this same attitude when it comes to the services that I make available. If you remember
for the networking chapter, the available services are defined in /etc/services. My suggestion is
to first comment out every service. Then, one-by-one, uncomment those that you want. Yes, you
may forget one and cause a certain amount of inconvenience. However, doing it this way you know
exactly what services you are enabling. If your forget to enable one, you have inconvenienced
someone. If you do it the other way, by disabling the ones you do not want, if forget to disable
one, you may have let the would-be hacker into your system.
Another means of securing your system is to limit access to the machine. There is, of course, the
issue of the physical security of the machine. If someone has physical access
to your firewall all the network security in the world is of little value.
What you turn on depends on what your needs are. For example, if you ware providing FTP and
HTTP services these two entries should be uncommented. (Note this assumes that
httpd is running from inetd and is not stand-alone). I would definitely say that on the firewall,
you should not uncomment netstat, systat, tftp, bootp, finger, and ntp. There is no reason
that I have ever heard of to make these services available across the Internet. Personally, I think
you should also leave out telnet and login (for rlogin). The key is to only
give what you have to.
To set this all up there needs to be a couple of changes in the kernel.
Obviously, the basic networking functionality needs to be turned on, but there are two other
options that you will find useful. The first is IP_FORWARDING. This needs to be turned off
so that packets are not passed through the firewall.
The next is IP_FIREWALLING. This is necessary for the basic firewall functionality. If you want
to keep track of the IP packets, then you need to turn on IP accounting. I
recommend doing this because it allows you to keep track of from where the packets are coming and
where they are going.
Another concept is the idea of IP
masquerading. With this enabled, the internal network
is "invisible" to the rest of the world. What happens is the firewall server converts the IP
addresses so that machines on the Internet think they are communicating with the firewall and not
an Internal machine. You can then assign IP address to your internal network
that reside with the private ranges as defined by RFC 1918. IP_FIREWALLING must
be enabled for this to work.
If you plan to use your firewall as springboard, then the configuration is basically complete.
However, if you are planning to go from your workstations through the firewall, then there is more
that you need to do do. This is where the concept of a proxy comes in.
There are currently two well known proxy packages available for Linux. The first is "socks",
which operates as a full proxy and can work with any program. There is a single configuration file
and a single daemon that need to be configured.
The other is the TIS firewall toolkit, which requires a new version of each daemon
that will be going through the firewall. If you do not want users to have access to a particular
service, then you just don't provide them with the necessary programs. However, with socks, it is
easier to unintentionally allow access.
Although not really a firewall, the TCP
Wrapper program can be used to control access to and from a specific machine. That is, it
must be installed on each machine individually. In contrast, a firewall works for all machines that
are trying to get passed it to the Internet.
The socks proxy server is available on many of the newer distributions. If you don't have it you
can get as a gzipped tar archive from
ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz.
It is here that we have come to the point where we have locked the door and put "The Club" into
our steering wheel. The Firewall HOWTO goes into details of the actual
configuration of the proxy server and the associated files.
|