Testing Firewalls

Before you can start logging access to your firewall, you need to ensure that you have configured it correctly. Even if you have extensive experience configuring firewalls, you will have to test your implementation when you first install it. In fact, experienced professionals know that they have to continually test a firewall to ensure that it is properly configured, and that its current configuration protects the network. It is not enough to just check or read the Ipchains/Iptables rules and then think that you have properly tested the firewall. You need to actively send packets and monitor your firewall and internal network to be sure.

Before you learn about applications that can help you test your firewall, you first need to consider some of the actual attacks, problems, and issues to look for. When testing your firewall, consider the following:

• Internet Protocol (IP) spoofing Many hackers outside of the firewall try to imitate internal network hosts in order to bypass authentication.

• Open ports/daemons Many firewalls and/or routers allow unnecessary ports to remain open, which can expose your firewall to threats unnecessarily.

• Monitoring system hard drives, RAM, and processors If your firewall runs out of disk space, or begins to run low on memory, your network may become incapacitated. Check your server's performance regularly using standard tools (df, vmstat, top, and so forth).

• Suspicious users, logins, and login times Even if you allow only interactive login at your firewall, monitor it carefully to determine who has logged on. It is vital that you know exactly who is controlling the flow of packets on your network.

• Check the rules database One of the common moves by a hacker is to alter the rules database in subtle ways that make it easier for the hacker to gain access to the network. Check your rules and compare them carefully to ensure that no unauthorized changes have occurred.

• Verify connectivity After you have configured or reconfigured your firewall, make sure that these changes do not cause problems for management and employees.

• Remain informed concerning the operating system Bugs may be discovered in the kernel and/or daemons that you are using. If you do not keep current concerning the tools you are using, you may end up exposing yourself to hackers.

• Port scans If you are relatively new to securing firewalls, you will be amazed to find out how many times your firewall will be scanned. Logging all scans can consume an unnecessary amount of hard drive space and processor time. Still, the proper amount of logging will help you remain informed and will help you document scans that may be preludes to an attack.

Following is a more detailed discussion concerning each of these issues.

IP Spoofing

Your firewall should not allow any packets to pass from outside the network into your internal network if the source address is the same as any host in your internal network. Suppose, for example, that your external network interface card (NIC) has the IP address of 128.1.2.3.4/16, and your internal NIC has the address of 192.168.1.0/24. You then need to find a way to test your firewall to see if any traffic is passing through the external interface from, say, the 192.168.1.1 IP address.

If such packets are able to traverse your firewall, then a hacker can configure his or her system to use your firewall as a default gateway and participate on your network. Leaving your packet-filtering firewall open to spoofing attacks largely obviates the reason for having a firewall, so you should take every step to test exactly what your firewall drops and allows. If you require, for example, your end users to have access to the World Wide Web, you will find that it is necessary to allow ephemeral ports (any port over 1023) to access the Internet. However, if you are using private IP addresses (for example, the 192.168.45.0 network), no system outside of the firewall should ever be able to assume this IP address and access your internal network's ephemeral ports.

Open Ports/Daemons

Your firewall should be as secure as possible. Disable all unused services and configure the used ones with security in mind. If you are running Squid or another proxy server on the firewall, make sure that only this port is open. Daemons such as Telnet, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP) and others should be shut down in almost all situations. In many situations, you may require the ability to remotely administer your firewall. Still, consider disabling all login to the outside interface.

In many situations, it is best to allow only interactive logins at your firewall. This way, you need only secure the firewall's physical security. If you must, use only a relatively secure login application, such as Secure Shell (SSH). You could also consider Kerberos, although this requires you to open several additional ports. Even using one-time passwords (OTP) at the firewall is a solution, although the use of OTP does not encrypt the data that subsequently passes from your system to the router. If you do need to leave certain ports open, be prepared to conduct regular scans of your firewall to test the daemons listening on these ports. As suggested earlier, applications such as Nessus (www.nessus.org) are ideal in this type of situation.

Monitoring System Hard Drives, RAM, and Processors

Firewall logs can consume hard drive space, especially in busy networks. If you configured your firewall to log both accepted incoming and outgoing access, you will find that your log files will grow very large in a short period of time. You may need to cut back on your log settings. However, if you cannot do this, regularly use the df –h command to discover the total amount of hard drive space you have left. You could, for example, create a simple crontab entry that sends you this information automatically every Monday at 8:05:

5  8  *  *  mon  df -h | mail -s "HDRIVE" [e-mail]

Of course, keeping the cron daemon enabled on your firewall can present its own problems, because it will require you to ensure that this daemon is not subject to bugs that can cause a security problem. Any daemon, such as cron, that acts automatically can cause problems if misconfigured, so carefully review all default scripts, and you will be in good shape. It is an additional service, after all. You will have to make the decision yourself.

Following is a quick overview of standard Linux tools that can help you determine if your system is becoming overburdened:

• vmstat Informs you about the amount of random RAM and virtual RAM used on the system.

• top Used to inform you about the processes that occupy the largest percentage of CPU time. The busiest processes rise to the top of the display. The Gtop and Ktop applications, both available from www.rpmfind.net, are graphical versions that are somewhat easier to use than the original.

Suspicious Users, Logins, and Login Times

Use the who and last commands to learn about who has logged in to the firewall. In addition, manually check the /etc/passwd and /etc/shadow files to determine if any users have been added. An application such as Tripwire can be extremely helpful if you want to remain informed about any changes to such files.

Check the Rules Database

Determine if any unauthorized changes have been made to your database. When you first created your firewall, you should have created a backup using either the ipchains-save or iptables-save commands. Use the diff command to compare the two files to see if any changes have occurred. You can also use md5 to generate fingerprints of the configuration files to see whether any unauthorized changes have been made to them.

Truly talented hackers are interested in entering a network and then controlling it without your knowledge. Accordingly, many will deactivate certain logging rules on your firewall, and then activate them again. If you leave the ipchains or iptables commands on your system, this will be very easy. To at least slow down the hacker, try removing these applications from the system. This way, the hacker will at least be forced to install these applications on your system before he or she can manipulate it. If you have Tripwire installed, you will then be informed of massive changes to the hard drive.

Verify Connectivity with Company Management and End Users

After you install and configure your firewall according to your security policy, check with various managers and employees to ensure that your firewall rules are working properly. You may have to further adjust your firewall to ensure that the right services are available to the company. You may have to inform people about certain services that are no longer available by design. Otherwise, you will receive help desk calls informing you that service has been interrupted.

Employee education is often necessary whenever you make any changes to the firewall. Otherwise, you will receive complaints that the network is "down," when in fact it is behaving according to your design. In order to cut down on ill will and employee frustration, find ways to carefully and tactfully inform employees concerning changes. Consider the following suggestions:

• Contact management and make sure that they understand and agree with the changes you are making.

• Many times, upper management will ask for certain changes and not quite understand how this will affect the end user. Decisions to cut off certain services (for example, Web traffic, or access to outside Post Office Protocol v3 [POP3] accounts) may negatively affect the company's ability to conduct business, or may cause unnecessary problems with employee morale. Make sure that upper management understands the ramifications of any suggestions they make.

• Warn employees before any changes to the security policy/firewall rules will occur.

• Remind employees that changes have occurred.

• Use e-mail, word of mouth, and employee area bulletin boards to remind people about changes.

Port Scans

Ipchains/Iptables-based firewalls are classic examples of packet-filtering firewalls. This type of firewall has traditionally been vulnerable to scanning attacks; they can simply allow scans to occur without informing anyone, because packet filters generally do not pay attention to Transmission Control Protocol (TCP)-based connections. They are interested, rather, in filtering out IP addresses and ports (they pay attention to the network layer of the Open System Interconnection Reference Model OSI/RM).

The introduction of log analysis software such as firelogd and Fwlogdaemon have made it possible to detect and block such scans, all the while sending an alert to the systems administrator. This type of software can help reduce a firewall's exposure to distributed denial-of-service (DDoS) attacks, because it helps the firewall completely drop certain hosts. However, this strategy introduces new problems, because it is possible for attackers to spoof source IP addresses and assume the identity of hosts you trust. The result is that hackers can use your own strategies against you and make your own software conduct a DoS attack against you by blocking your network from its own Domain Name System (DNS) servers, default gateways, and other hosts that you trust implicitly. However, most adjunct software, such as fwlogwatch, provides ways to exclude trusted hosts from being blocked. You will learn more about this later in this chapter.

Note

As long as unencrypted, non-IPsec versions of IPv4 remain the most commonly used version of IP, spoofing will remain a fact of life. If you find that spoofing attacks keep occurring against your network, you can take the following actions:

• Edit the configuration files of your log-watching software and increase thresholds to eliminate false positives.

• Carefully manage any Ipchains/Iptables entries created by your log-scanning software so that sensitive hosts are not blocked.

  These strategies are ways that you can mitigate and manage spoofing attacks, as opposed to eliminating them, because until all systems use IPsec or move to IPv6, there is really no way to completely eliminate them. Even when IPsec and/or IPv6 become common, it is likely that hackers will find newer and cleverer ways to spoof these protocols as well.