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
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 if 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. However, if the machine is compromised, an attacker would not be fooled.
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 relaxed, 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.
I believe that which
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. If you are going to provide remote login access to your system ssh is a much better idea.
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.