Chapter 11: Managing Firewalls (2024)

More Cisco Press book chapters from new and classic Cisco Press books.

Rate your favorite Cisco Press books.

This chapter looks at the management of firewalls. From the perspective of the small office/home user, the firewall is a single device that protects the home network from malicious traffic—it keeps out the “bad stuff” and provides the end user a more secure online experience. For the enterprise, the firewall can be both an inbound filter as well as an outbound filter depending on how the security policy calls for enforcing the edge network. Either way, the firewall (or in the case of enterprises, possibly firewalls) must be managed in one fashion or another. Typically, most manufacturers rely these days on a web interface. In the home market, this stems from the fact that a graphical user interface (GUI) is more intuitive to the end user, and therefore ostensibly easier to use, than a command-line interface (CLI). However, for the more daring at heart who so want, there are firewalls (namely the PIX, Linux IPTables, and Solaris IPF to name just a few) that can be managed solely from the CLI. This chapter covers such topics as default passwords, the maintenance of the underlying firewall platform for firewalls such as Linux’s NetFilter, and managing firewalls through the CLI as well as a GUI. Finally, a discussion of management interfaces and common firewall management tasks is provided.

Default Passwords

When you purchase a new firewall (or any network device in general) such as a Cisco PIX, a Linksys, a NetScreen, or a SonicWall, out of the box the device has some default passwords set (and in some cases there is no default password). This is because the manufacturer must allow for initial access to the device for the end user to configure it. Most recent documentation for any device admonishes the end user to immediately change the default password to something else. Table 11-1 shows common default passwords for some firewalls.

Table 11-1: Default Passwords

You can find a detailed default password list at either the F/X site (https://www.phenoelit.de/dpl/dpl.html) or at the Nikto site (https://www.cirt.net/cgi-bin/passwd.pl). It is precisely because sites such as these keep lists of default passwords that these passwords are considered detrimental. In some cases, vendors have gotten the hint that although they need to have default passwords for the initial setup, the initial setup should also require the administrator to change the password from the default value. This has been done on some Cisco devices, such as their IDS platform, and is finding more and more acceptance among other vendors.

Maintaining the Underlying Platform

As with any device on the network, firewalls run software (whether it is embedded in an application-specific integrated circuit [ASIC] or runs from Flash memory or runs from a disk file system) to be able to perform their functions. Typically, as in the case of the Cisco PIX and ASA platforms as well as NetScreen and other vendor firewalls, these firewalls run a custom operating system whose source code is not available to the general community for review or tampering. If a bug or vulnerability is discovered by an outside party, it is left to the manufacturer to develop a patch and release a new version of the operating system to be installed by the end user to solve the problem. In addition, any new feature added to the device is done according to the schedule of the manufacturer.

At the opposite end of the spectrum are the open source systems with firewall capabilities. These include Linux, OpenBSD, and Solaris 10, to name a few. Each of these systems’ (Linux’s NetFilter, OpenBSD’s PF, and Solaris 10’s IPFilter) firewall source code is available for inspection by outside groups. This does not necessarily mean that the filter code in these operating systems is better, but it can be more easily extended by someone who has the skill set necessary to code the additional capabilities into the software. However, each of these filtering systems runs under a more generic operating system (Linux, OpenBSD, and Solaris, respectively), and therefore the possibility of bugs or vulnerabilities (some tied to the filtering code and others not) may be greater because the underlying operating systems are meant for more general use. Such systems require care, patience, and effort to both maintain and to secure to ensure that the firewall is not compromised. If a bug or vulnerability is discovered in one of these firewalls, the patch for it is likely to be available sooner than a closed source appliance system. Typically, this is because the number of people who may be able to provide a fix for the bug or vulnerability is significantly greater than those involved in the development of commercial closed source systems. This does not mean that vendors such as Cisco, NetScreen, Watchguard, Linksys, and the like do not provide timely patches; in some cases, it depends on the severity of the problem. Statistically, however, Linux and OpenBSD bugs are fixed quickly relative to closed-source vendors (https://csoinformer.com/research/solve.shtml).

Consider the case of a firewall consisting of a simple Intel PC with two interfaces running Fedora Core 4 Linux and NetFilter as the filtering firewall. The number of packages in Fedora Core 4 is on the order of approximately 1500 packages (1806 to be exact). Many packages may contain a bug that could result (however unlikely) in the possible compromise of the system. In addition, the level of effort to secure the system properly or to maintain the system may be beyond the capabilities of most people without a sufficient technical background. For a more novice group of users, a packaged, closed source system may be the better choice. A Linksys router/firewall, a Cisco PIX 501, or a NetScreen 5XP may be better suited for the less-technically-savvy individual or for someone who wants a closed source appliance because of the lower effort required to configure and maintain it. Nevertheless, for those who are willing to make the effort and for those who are skilled, an open source firewall can fit the bill.

Maintaining the underlying platform requires time. The more complex the underlying platform, the more time required. This is where closed source appliances such as PIX, NetScreen, and Linksys have an advantage. They provide a device that, although configured and maintained by the user, eliminates many of the variables inherent in more general operating systems. This makes it much easier for a less-experienced user to be able to maintain the firewall.

Firewall Management Interface

Modern firewalls come with two administrative interfaces:

• The CLI

• The GUI (typically, but not necessarily, web based)

This section provides an overview and some examples of these interfaces.

Managing Firewalls with a CLI

A CLI enables you to use a specific instruction set to configure the firewall. Most firewalls require the end user to do the initial configuration of the firewall (inputting in the basic network information such as IP address, net mask, default gateway, and possibly an administrative password) via CLI before the end user can switch over to the GUI. Linux’s NetFilter is, for the most part, configured through a CLI, although there do exist several products that allow for configuration of NetFilter-based firewalls through a GUI.

CLIs require knowledge of the command set in the firewall product. For example, to configure NetFilter, use the IPTables CLI to allow inbound Secure Shell (SSH), e-mail, and web traffic (using TCP ports 22, 25, and 80, respectively) and deny all other traffic requires the configuration in Example 11-1.

Example 11-1: Configuring NetFilter with IPTables

# iptables –P INPUT DENY# iptables –P OUTPUT ACCEPT# iptables –P FORWARD ACCEPT# iptables –A INPUT –i lo –j ACCEPT# iptables –A INPUT –p tcp –s 0.0.0.0/0 –d 10.16.17.202 --dport 22 –m state --state NEW – j ACCEPT# iptables –A INPUT –p tcp –s 0.0.0.0/0 –d 10.16.17.202 --dport 25 –m state --state NEW –j ACCEPT# iptables –A INPUT –p tcp –s 0.0.0.0/0 –d 10.16.17.202 --dport 80 –m state --state NEW – j ACCEPT# iptables –A INPUT –m state --state ESTABLISHED,RELATED -j ACCEPT# iptables –A INPUT --reject-with icmp-host-prohibited –j REJECT

Example 11-2 provides a similar configuration with the PIX command set.

Example 11-2: Configuring a PIX

gandalf(config)# access-list acl_test permit tcp any host 10.16.17.202 eq sshgandalf(config)# access-list acl_test permit tcp any host 10.16.17.202 eq smtpgandalf(config)# access-list acl_test permit tcp any host 10.16.17.202 eq 80gandalf(config)# access-list acl_test permit icmp any anygandalf(config)# access-list acl_test deny ip any anygandalf(config)# show access-list acl_testaccess-list acl_test; 5 elementsaccess-list acl_test line 1 permit tcp any host 10.16.17.202 eq ssh (hitcnt=0)access-list acl_test line 2 permit tcp any host 10.16.17.202 eq smtp (hitcnt=0)access-list acl_test line 3 permit tcp any host 10.16.17.202 eq www (hitcnt=0)access-list acl_test line 4 permit icmp any any (hitcnt=0)access-list acl_test line 5 deny ip any any (hitcnt=0)

Knowledge of the command set is critical to effectively configure a firewall through a CLI. Many vendors (and third parties) have worked hard to reduce the configuration of a firewall to a more simplistic method. When the initial configuration is done (supplying the firewall software with an IP address and net mask), the end user can immediately switch to a more graphical method of configuring the firewall.

Managing Firewalls with a GUI

A GUI provides a more-user-friendly interface to configure the firewall. Some firewalls are configured through a direct interface on the host, such as Symantec Norton Internet Security shown in Figure 11-1 and Figure 11-2, before the firewall is active. Some come with a preconfigured IP address and an administrative password to be used for access by the end user during initial configuration (such as Linksys or the PIX 501 and 506E series systems).

Figure 11-1

Symantec Internet Security Configuration

Figure 11-2

Symantec Firewall Configuration

The PIX Device Manager (for PIX operating systems up to versions 6.3(5)), known as the Cisco Adaptive Security Device Manager in PIX version 7.0, is a Java applet that is downloaded from the PIX or ASA device and runs locally through the client browser. Figure 11-3 shows the PIX Device Manager screen.

Figure 11-3

Cisco PIX Device Manager

The information is presented in a more natural fashion to the end user in the form of graphics and graphs for performance.

Not to be outdone, there are GUIs for Linux’s IPTables firewall software. Some are web based (such as Webmin), and some are applications running on the Linux system itself (such as Firestarter or FW-Builder). Firestarter provides a simple, easy-to-use interface for IPTables, as shown in Figure 11-4.

Figure 11-4

Firestarter for IPTables

Webmin provides a method by which the firewall can be managed through a web browser interface, which is more convenient than an application that can only be viewed on an X Windows-enabled server. Figure 11-5 shows this interface.

Figure 11-5

Webmin IPTables Rules Interface

Interface Preference

Whether it is through a CLI or through a GUI, the management of a firewall can range from the highly complex to the relatively easy. Typically, novice users start by administering the firewall through a GUI. Over time, as their experience level and comfort level with the firewall increase, they may find it more convenient to use a CLI. One significant benefit of a CLI over a GUI is that the CLI is available through Telnet and SSH sessions as well as connected directly to the serial port. This becomes important when considering how access to the firewall management interface will be controlled.

Management Access

Control of access to the management interface of network infrastructure devices is critical. Network devices such as routers, switches, intrusion detection sensors, and firewalls should be accessed only by those users who need to administer them. This requirement stems from the fact that an unauthorized user, whether someone with malicious intent or not, may change the configuration or disable the device and thus lower the security of the surrounding network. Management access comes in two forms: in-band and out-of-band. Additional considerations must be made regarding how the firewall is accessed: Telnet, SSH, SNMP, FTP, TFTP, HTTP/HTTPS, or some proprietary management protocol and must conform to the management access policy as discussed in Chapter 10, “Firewall Security Policies.”

In-Band Management

In-band management refers to the administrative access to systems and network devices over the same network that is used by the traffic being filtered. In-band management can represent a significant risk to the administrator if certain precautions are not taken. These risks center predominantly around the use of unencrypted communications channels. Specific attention must be paid to the use of encrypted communications such as SSH and HTTPS when considering whether to manage a firewall in-band. The use of simple Telnet or HTTP can result in the adminis-trative password being captured by an attacker who is sniffing the traffic between the administrative interface of the firewall and the rest of the network. In-band management also runs the risk of being susceptible to a denial-of-service (DoS) attack during large-scale outbreaks such as worms. This would make it more difficult to reconfigure the firewall during such an event to block traffic or shut it off altogether if necessary to defeat the attack.

Out-of-Band Management

As the term indicates, out-of-band management results in access to the firewall through a secondary channel that is not carrying production traffic. This can either be a VLAN setup for administrative access to network devices and hosts or, preferably, a completely separate physical network. In addition, out-of-band management can be used to provide access to the serial port of the network device for access should the network fail. Out-of-band management can be more time-consuming to set up and not cost effective for smaller networks, but it represents the most secure and reliable method of administering firewalls and other network equipment.

Telnet vs. SSH

Telnet is an unencrypted network communication protocol that is typically used to provide remote access to systems and other devices. Telnet is originally defined in RFC 854 and was developed long before the Internet was in its current form—when networks were much smaller. Not much consideration was given in the Telnet protocol design to confidentiality in the data being transmitted using the protocol. Therefore, all data transmitted using the Telnet protocol is subject to eavesdropping and susceptible to capture.

SSH provides for cryptographic protection of data as well as authentication and ensures that the integrity and confidentiality of the communication is secured. If a device can support SSH as an access method to the command line, it should be preferred over Telnet. Alternatively, if the device’s GUI is accessible within a secure network and it is necessary to remotely manage the device across an insecure network and an SSH connection can be established, it is possible to tunnel the connection through SSH. To establish an SSH tunnel between two hosts, you need to use port forwarding. In the example shown in Figure 11-6 the client establishes an SSH connection through to the SSH server on TCP port 22 (the standard SSH port). However, the client uses the port-forwarding capability to forward his localhost TCP port 1025 and redirects it to the Telnet port of on the router. To access the Telnet port of the router through the tunnel, the client need only telnet to his localhost TCP port 1025 and he will automatically be redirected, through the SSH tunnel, to the router’s Telnet port.

Figure 11-6

SSH Forwarding Across an Insecure Network

This way the traffic goes through an encrypted SSH session between the client and the SSH server and then the traffic can be forwarded using an insecure protocol such as Telnet.

HTTP vs. HTTPS

A discussion about the use of HTTP versus HTTPS follows a similar line of thought as the previous discussion about Telnet versus secure shell. HTTP is an unencrypted protocol that allows eavesdroppers to view the communication between the client and the server. Although attackers may not necessarily be able to capture the password to the web server, they may be able to capture other information such as specific configuration information or possibly a valid cookie that would then allow the attacker to impersonate a legitimate user and gain access to the firewall’s administrative interface.

HTTPS uses Secure Sockets Layer (SSL) encryption technology to encrypt the communication between the client and the firewall web server. This makes it impossible for an attacker to eaves-drop on a management session or intercept any information that could be used to gain access to the firewall or gain information about the firewall configuration.

Common Firewall Management Tasks

One of the first things to accomplish when deploying a new firewall, whether this is for an enterprise deployment or for a deployment in a small office or home office, is to configure some basic aspects of networking. Doing so includes changing the default administrative password, configuring the default gateway, configuring the IP addresses for the internal and external (and possibly other) interfaces, and configuring the logging of messages from the firewall. In addition to these tasks, the firewall administrator must also manage the configuration of the firewall over time. Doing so may require the use of a change control system such as the Revision Control System (RCS), which is available both on the UNIX/Linux platforms as well as the Windows platform. The following sections discuss each of these tasks in more detail.

Initial Configuration

The initial configuration of a firewall requires several items of information. This information includes both the internal and external interface IP addresses (or the use of DHCP on one of those interfaces), the next-hop gateway, logging, and an administrative password. The first three items are discussed in the following paragraphs. A discussion of administrative passwords was provided earlier in the “Default Passwords” section.

Interfaces

Most small office/home office (SOHO) firewalls have only two interfaces. On enterprise firewalls, there can be well over a half dozen interfaces that comprise various demilitarized zones (DMZ) with varying levels of security. In addition, newer enterprise firewalls can also support VLANs and filtering between VLANs while only having a limited number of physical interfaces. All firewalls have at least two interfaces:

• Inside—The inside interface is typically assigned a static IP address (and this IP address typically comes from one of the three private IP address blocks—10.0.0.0/8, 172.16.0.0–172.31.255.255, or 192.168.0.0/16—but this is not a hard requirement). This interface serves as a default gateway for systems that are behind the firewall. A default gateway is the gateway of last resort for systems to send traffic to when the other end of the connection (that is, the system being contacted) is not reachable any other way or is not on the client’s local network.

• Outside—The outside interface can either be assigned a static IP address as provided by the Internet service provider or it can be configured to be assigned an IP address through the Dynamic Host Configuration Protocol (DHCP).

In addition to the IP addresses on the various interfaces, the firewall can also run a DHCP server to provide IP addresses and other configuration information to systems inside the firewall. This server makes the deployment of a SOHO firewall much easier because most vendors also provide some default configuration for the DHCP server, too. Care must be taken to ensure that the scope of the DHCP server does not overlap or conflict with any DHCP scope already in place in the network. Also, in the case of wireless firewall routers (such as the Linksys BEFW11S4 or the WRT54G) that are popular these days, it is extremely important for the administrator of the device to ensure that only authorized users can associate and authenticate to the device. If these devices are not locked down, any user can authenticate and associate to the device, and the DHCP server will provide them with a network address that they can use.

Routing/Gateway

In many cases, where simple firewalls such as the Linksys, the Linux NetFilter, or the PIX 501 or 506E firewalls are used, there is a simple network topology—essentially an internal network behind the firewall and an external network (typically consisting of the external IP address provided by the service provider). These firewalls do not do complex routing but rather just forward packets from the internal network to the external network using a default gateway. The default gateway information is provided either by the administrator or by the service provider’s DHCP server when the firewall boots up.

In enterprise networks, however, the firewall can segment multiple networks and DMZs from each other. In this case, the routing can be quite complex and may require the use of a dynamic routing protocol such as the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocol.

To add a default route to a Cisco PIX during initial configuration, you need to use the route command as follows:

pix(config)# route outside 0.0.0.0 0.0.0.0 172.16.45.1 1

This tells the PIX that the default route goes out the outside interface, that the next hop is 172.16.45.1, and that it is only one hop away (that is, it is the next device going outbound).

Logging

Logging is also essential for maintaining and administering a firewall. Logging enables the administrator to see all the traffic blocked by the firewall as well as troubleshoot the firewall configuration when a particular function, such as Network Address Translation (NAT), is not working as expected. Most firewalls such as the PIX 501 or 506E and Linux’s NetFilter allow for logging of messages to remote syslog servers.

Syslog’s origins are in the UNIX operating system, and syslog is used by a wide variety of processes on many Linux, BSD, and UNIX-derivative operating systems. In addition, many vendors, such as Cisco, have adapted syslog to their products such as IOS and PIX OS. Syslog is defined in the Internet RFC 3164 (available from the Internet Engineering Task Force (IETF) website at https://www.ietf.org/rfc/rfc3164.txt?number=3164). The two primary concepts to understand with syslog is the message facility and the severity. Each message generated and sent to a syslog server must be sent with a defined facility and severity for the syslog server to understand how to handle the message. The currently defined facilities and severities defined in the syslog RFC (3164) are listed in Table 11-2 and Table 11-3, respectively. There are eight levels of syslog severities possible, as defined in RFC 3164 and shown in Table 11-3 in descending order. One of the confusing aspects of the syslog severity levels is that the lower the numeric value of the severity (with 0 being an Emergency), the higher the severity of the message being sent. Also, the “lower” the severity (that is, the higher the numeric value of the severity), the greater amount of information that is generated by the process. So, level 7, Debug, produces a prodigious amount of syslog log messages, whereas level 0, Emergency, produces few messages (but of critical significance). Because syslog originally was developed on the BSD UNIX operating system, many facilities are assigned to specific processes and daemons in UNIX. Processes that have not been explicitly assigned a facility may use one of the “local-use” facilities.

Table 11-2: Syslog Facilities

Table 11-3: Syslog Severities

In many cases, syslog servers are kept behind the firewall and, more preferably, in the management network; therefore, there is no need to open up the firewall to allow these messages to reach the server. Example 11-3 demonstrates the commands to configure a PIX 501 or 506E to send its logs to a remote syslog server. The following commands are entered in the configuration or config mode of the PIX device.

Example 11-3: PIX Logging

logging onlogging timestamplogging trap informationallogging facility 21logging host inside 10.16.17.124

The command logging on tells the device to turn on logging on the device, and the logging timestamp command ensures that a date/time field is inserted in each syslog message sent to the remote syslog server. The logging trap informational command specifies the level of logging to be conducted. The reason why Informational is a good level to use for logging with the PIX is because it provides enough information to monitor the traffic going through the PIX without overwhelming the administrator with unnecessary information. Level 7, Debug, is typically used only to try and determine a problem with the configuration of the PIX or why some capability of the PIX does not work. The logging facility 21 syntax specifies which syslog facility is used. The facility 21 syntax translates, according to Table 11-2, to local use 5. Finally, the last line, logging host inside 10.16.17.124, tells the PIX to send its messages to the host on the “inside” of the PIX (that is, the host on the internal network) with the IP address of 10.16.17.124.

No matter how the firewall logs information, it is critical that the logged information be reviewed by an administrator. Administrators can distill the information from firewalls and other sources via a variety of different log analysis tools. These tools range from commercial tools such as CiscoWorks VMS to open source or freeware tools. An excellent resource for log analysis tools is the website https://www.loganalysis.org. Cisco provides detailed instructions on how to set up a syslog server to receive the various messages generated by the PIX firewall. These instructions are applicable to any device that can generate a syslog message and can be found here:

https://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094030.shtml#setupsyslogd

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 https://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

Folder Properties

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

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

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.cfgRCS/frodo.cfg,v <-- frodo.cfgenter 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.cfgRCS/frodo.cfg,v --> frodo.cfgrevision 1.1 (locked)done[root@sauron configs]127 # ls -ltotal 26drwxrwx--- 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.cfgRCS/frodo.cfg,v <-- frodo.cfgnew revision: 1.2; previous revision: 1.1enter 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 -ltotal 2drwxrwx--- 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.cfgRCS file: RCS/frodo.cfg,vWorking file: frodo.cfghead: 1.2branch:locks: strictaccess list:symbolic names:keyword substitution: kvtotal revisions: 2; selected revisions: 2description:Initial configuration of external/edge router----------------------------revision 1.2date: 2005/08/29 14:19:59; author: root; state: Exp; lines: +1 -0Added new external NAT address, 172.16.45.152 -> 192.168.155.152 - idubraws----------------------------revision 1.1date: 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,vretrieving revision 1.1retrieving revision 1.2diff -r1.1 -r1.273a74> 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

One of the first items to do when deciding with which software release to upgrade a firewall (or any device for that matter) is to read the release notes for that version. The release notes typically include a detailed list of supported devices, new features in the release, and software bugs fixed in the release. In addition, some manufacturers include a list of outstanding bugs that have not been addressed in the release at the time of shipment. The release notes represent a one-stop shop for much, if not all, of the necessary information needed to determine whether the software release being considered is appropriate for the firewall to be upgraded.

Defects and Bugs

Firewall software is complex and contains many subsystems and lines of code. Although the vendors make every effort to identify potential bugs or other errors in the software, not all possible cases can be discovered during testing before the software is released to the general public. Therefore, possible bugs and vulnerabilities in the software may not be detected until after the software has been released.

Vulnerabilities

A vulnerability is a defect that might result in the potential exploitation of the firewall by an attacker to cause either a denial-of-service (DoS) attack or to gain access to the firewall itself. A vulnerability can also be caused by a misconfiguration of the firewall. An example of a vulnerability in firewall software is the Cisco PIX Telnet/SSH DoS attack described on SecurityFocus (https://www.securityfocus.com/bid/6110). This vulnerability, although not providing access to the PIX itself, causes the PIX Telnet/SSH service to become nonresponsive. Cisco immediately released a fix for this problem in PIX OS 6.2.2.111.

A vulnerability due to a misconfiguration of the firewall can range from allowing access to Remote Procedure Call (RPC) ports on systems behind the firewall to not setting an access password on the device itself. These types of vulnerabilities are not mitigated by software upgrades but rather by correcting the configuration of the device. One of the quickest ways to find any ports that may be open due to a firewall misconfiguration is to use a network-scanning tool such as Nmap (available at https://www.insecure.org) or Foundstone’s Fscan (available from https://www.foundstone.com)

Tracking a Defect

So, a bug or a vulnerability has been discovered in the software version running on your firewall. What do you do now? If the vendor has released a version that resolves the bug or vulnerability, the simplest solution is to download it and apply the patched software. If no fixed software is available, it is important to keep track of the bug and any possible workarounds the vendor has devised. Typically, vendors provide a portal on their websites that include defect information and whether a specific defect has been resolved. For Cisco PIX devices, the Product Security Incident Response Team provides security advisories that can be viewed on the Cisco website at https://www.cisco.com/go/psirt. In addition, for registered users, a database of security-related and non-security-related defects is available. For Linksys devices, this section is part of their technical support website (https://www.linksys.com). Information related to bugs in the Linux kernel is available at the Linux Kernel Archives website (https://www.kernel.org). For Linux kernels 2.6 bugs, there is a specific bug-tracking system, https://bugzilla.kernel.org. For bugs that are NetFilter specific (whether it is the NetFilter code in the kernel or the utilities used to manipulate the NetFilter firewall), there is https://bugzilla.netfilter.org. Regardless of the device, it is important to be aware of bugs and other software issues to be prepared to mitigate any new vulnerabilities that they may introduce into the network.

Summary

Managing firewalls is not much different from managing any other device on the network. However, special care must be taken when managing a firewall because it represents the nexus of security in the any network. In many cases, it represents the only security device on the network. Managing a firewall securely is not difficult and does not mean that you are limited only to command-line tools. You can manage many firewalls using SSH (for command-line configuration) and HTTPS (for a browser-based management system) to do such tasks as change default passwords, maintain the platform, make initial configurations, set up logging, modify the configuration, and update the firewall software. Finally, paying attention to potential defects in the firewall software will ensure that a bug or a vulnerability will not sneak up unnoticed and cause a DoS attack or the potential exploitation of devices in the network.

Copyright © 2007 Pearson Education. All rights reserved.