Chapter 11: Managing Firewalls

Cisco Press

1 2 3 4 Page 3
Page 3 of 4

Modifying the Configuration

As with any device, from time to time you will need to modify the configuration of the firewall. Whether this is due to a new device brought on line to access the Internet or the addition of a new web server behind the firewall, it will be necessary to change the firewall configuration. The problem with modifying the configuration comes down to change control—ensuring that changes made to a firewall are tracked and logged in case of problems. These items are discussed in the sections that follow.

Change Control

Change control is defined as the process and procedures to manage changes being made to a product or its configuration. For the sake of this discussion, the focus is on the control of changes made to the configuration of a firewall. Change control for firewalls relies on either those changes being logged or a copy of the previous configuration being stored or both. One of the simplest ways to control changes to the configuration of a firewall is to use some sort of revision control system—such as Revision Control Service (RCS) or Concurrent Version System (CVS)—to check the changes and, if necessary, to re-create a previous version of the configuration should a problem arise. This works when the configuration of the firewall is stored as a text file that can be downloaded to a system acting as the RCS or CVS repository. When the configuration of the firewall cannot be downloaded as a text file, a running log of the changes made to the firewall should be kept so that changes can be backed out of if necessary. See http://www.cs.purdue.edu/homes/trinkle/RCS for more information regarding RCS, CVS, and other change-control software systems.

To set up a simple change-control system such as RCS (on UNIX, Linux, or Windows) to manage the changes to firewall configurations, it is important to remember that configurations sometimes contain sensitive administrative information such as passwords or access control lists (ACLs). It is important that the RCS (or CVS) system and the directory or folder containing the configuration files be kept secure. In UNIX or Linux, this requires changing the permissions of the RCS repository such that only root or others within an administrative group have access privileges, for example:

# chgrp wheel configs
# chmod -R 750 configs

These commands change the group ownership of the configs directory to the wheel group and then change the permissions on it, as well as all directories beneath it, to read, write, and execute for the owner; read and execute for group members; and no permission for everyone else. This restricts access to the directory, in this example, to just the owner as well as those other users who are members of the wheel group. However, the group members cannot make changes to the files within the directory. They can only view them. Only the owner can make changes to the files in the configs directory.

Under Windows, the process is similar. To restrict access to the administrator only or to the administrative group, the everyone group must be removed. This can be accomplished by setting the permissions as shown in Figure 11-7. To set the security permissions on the folder, you must right-click the folder and choose Properties. This opens the folder Properties window as shown in Figure 11-7. In the folder Properties window, open the Security tab. This opens the Security permissions for the folder, as shown in Figure 11-8.

Figure 11-7

Figure 11-7

Folder Properties

Figure 11-8

Figure 11-8

Initial Security Settings for Folder

Select the Everyone group and click the Remove button on the right side of the Properties window. Then click the Add button to add the user you want to have ownership of the folder (in this example, the domain administrator has ownership). Figure 11-9 shows the result.

Figure 11-9

Figure 11-9

Final Security Settings for Folder

When that is accomplished, access to the folder is limited to only those with the proper credentials, as shown in Figure 11-10.

Figure 11-10

Figure 11-10

Access Denied Without Proper Credentials

When the configuration repository directory has been secured sufficiently, the next step is to check in the initial configuration to the repository. The initial configuration is the starting point that you will use as a known good configuration for the device. Any changes made after the initial configuration is tracked using the configuration repository. By doing this, you will be able to reconstruct a good configuration in case a specific change is not good or needs to be removed. In addition, by using revision control, you can find out who made what changes and why by requiring the individual making the change to enter a log entry explaining the change and the need for it. To check in the initial, known good configuration for the device, you just use the checkin (ci) command as shown in Example 11-4. This example shows how to check in a file to the repository as well as how to check out a file from the repository. These commands are entered on the command line in both UNIX and the Windows environment.

Example 11-4: Using RCS for Configuration Control
73 # ci -i frodo.cfg
RCS/frodo.cfg,v <-- frodo.cfg
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> Initial configuration of external/edge router
>> .
done
[root@sauron configs]
126 # co -l frodo.cfg
RCS/frodo.cfg,v --> frodo.cfg
revision 1.1 (locked)
done
[root@sauron configs]
127 # ls -l
total 26
drwxrwx---  2 root   sysadmin   512 Aug 29 10:06 RCS
-rw-r-----  1 root   other   11879 Aug 29 10:06 frodo.cfg

The ci command checks the configuration into the repository. The –i flag tells the RCS software to create and initialize a new repository. The co command is used to check items out of the repository. The –l flag also locks the repository for the specific user who issued the co command. When the configuration file is checked out of the repository, it appears in the local directory (or folder in the case of Windows) as shown above at the end of Example 11-4. The working file in this case is frodo.cfg.

After the file has been checked out and locked, only the current user can make changes to the configuration. When the file is then checked back into the repository, the changes made must be logged. Whenever you check a new revision back into the repository, the RCS software allows you to add a log message to the repository to explain the changes. Example 11-5 demonstrates how to check the configuration changes into the RCS repository. Notice that the–i flag was not used because we are not initializing the repository. After the configuration has been checked back into the repository, the working file (in this case, frodo.cfg) is deleted by the RCS software.

Example 11-5: Checking in Changes to the RCS Repository
[root@sauron configs]
132 # ci frodo.cfg
RCS/frodo.cfg,v <-- frodo.cfg
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:
>> Added new external NAT address, 172.16.45.152 -> 192.168.155.152 - idubraws
>> .
done
[root@sauron configs]
33 # ls -l
total 2
drwxrwx---  2 root   sysadmin   512 Aug 29 10:20 RCS

RCS, CVS, and other open source revision-control systems provide an easy, low-cost way of managing and controlling configuration changes.

Change-Control Logging

Change-control logging is the process by which information is entered in the change-control system regarding changes made to a configuration. It is important that information about configuration changes be included when they are made. This provides for easier troubleshooting should a problem occur with the new configuration. When new configuration revisions are checked in to the repository, the RCS software automatically provides for the addition of a log message. The log message should sufficiently reflect the changes made to the configuration so that another person can go in, identify the changes, and be able to back them out if necessary. One way of viewing all the changes made to a particular configuration file through RCS is the use of the rlog program. The rlog program prints log messages and other information about files in the RCS repository. Example 11-6 demonstrates viewing the RCS log for a configuration using the rlog command. To view the log file for changes made to the configuration being managed through RCS, the syntax is just rlog filename. This displays the log entries for all changes made to the file.

Example 11-6: Viewing the RCS Log for Configuration Changes
[root@sauron configs]
136 # rlog frodo.cfg

RCS file: RCS/frodo.cfg,v
Working file: frodo.cfg
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;   selected revisions: 2
description:
Initial configuration of external/edge router
----------------------------
revision 1.2
date: 2005/08/29 14:19:59; author: root; state: Exp; lines: +1 -0
Added new external NAT address, 172.16.45.152 -> 192.168.155.152 - idubraws
----------------------------
revision 1.1
date: 2005/08/29 13:51:42; author: root; state: Exp;
Initial revision

The output in Example 11-6 provides a lot of information. For example, the working file is identified in the Working file line. In addition, it shows how many revisions have been made to the file (in the example, two revisions have been made). A description of the file is provided and below that the revision log entries.

This shows all log entries of the changes made since the configuration file was first checked in to the repository. Note that the name of the user which made the change to the NAT configuration was entered into the log message itself. The user was using the root administrative account however. This is important if the person needs to be contacted regarding the changes he or she made. It is better practice to use individual user accounts to provide accountability for any changes that need to be rolled back out of a configuration.

To view changes made between configurations, the administrator can use the rcsdiff command as shown in Example 11-7. The rcsdiff command shows the difference between two revisions of a given file in the RCS repository. In the case of Example 11-7, this shows the configuration commands that were entered between the revision levels specified using the –r flag on the command line.

Example 11-7: Viewing Differences in Configuration Revisions
[root@sauron configs]
14 # rcsdiff -r1.1 -r1.2 frodo.cfg
================================================================
RCS file: RCS/frodo.cfg,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
73a74
> ip nat inside source static 172.16.45.152 66.92.161.152

Although RCS is useful for a small site, an enterprise network administrator would be better served by commercial configuration management tools such as the CiscoWorks Management Center for Firewalls. This tool not only provides revision control for the configurations but also a workflow tool that provides for separation of duty among administrators. This prevents a single adminis-trator from making changes and pushing the configuration to the firewall without having another administrator review the changes and approve them.

Updating the Firewall Software

The final topic to consider when managing firewalls is updating the firewall software. There are two primary reasons to update the software. One reason is to take advantage of new capabilities added to newer software versions. The other reason is the need to fix bugs and vulnerabilities in the software. Like all software, firewall software is complicated and contains many lines of code. The code in the firewall may have been rigorously tested, but there will still be corner cases that the software developers did not consider or just outright overlooked. A corner case is a situation that only occurs outside of normal operations. Typically, corner cases arise when multiple conditions occur simultaneously and at an extreme level. For example, a DHCP starvation attack (an attack where the attacker tries to exhaust a DHCP server's ability to provide clients with leases by generating multiple requests for all the IP addresses in the DHCP server's scope) along with a distributed denial-of-service (DDoS) attack. The combination of these two attacks may cause a resource exhaustion on the firewall or trip some other software bug that could make the firewall unusable. These bugs may result in the firewall resetting itself or may result in the firewall allowing invalid traffic through when it should be blocked.

Choosing the Correct Version

The first step in updating a firewall's software is determining the right version. This means determining which version will run on the firewall platform to be upgraded and which version provides all the capabilities desired and for which the firewall is licensed. On SOHO firewalls such as a Linksys device or the PIX 501/506E, the most recent version is typically the correct version to use. However, recently Cisco released PIX OS 7.0 for the PIX platform. This version works on all PIX platforms except for the PIX 501 and the 506E platforms. Take care when a new software version is released by the manufacturer that the requirements for that version are met before attempting to upgrade the firewall. Otherwise, this could result in the firewall being nonfunctional and requiring a software downgrade to a previous version to restore operation.

In the case of Linux NetFilter-based firewalls, the administrator must be careful to ensure that the NetFilter firewall code is compiled into the Linux kernel (either statically or as dynamically loaded modules). In the more recent Linux kernels of the 2.6 series, the NetFilter is automatically included in the kernel configuration as dynamically loaded modules.

Reading the Release Notes

Related:
1 2 3 4 Page 3
Page 3 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)