Chapter 11: Managing Firewalls

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 http://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 on
logging timestamp
logging trap informational
logging facility 21
logging 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 http://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:

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