Chapter 11: Managing Firewalls

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 (http://www.phenoelit.de/dpl/dpl.html) or at the Nikto site (http://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 (http://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 ssh
gandalf(config)# access-list acl_test permit tcp any host 10.16.17.202 eq smtp
gandalf(config)# access-list acl_test permit tcp any host 10.16.17.202 eq 80
gandalf(config)# access-list acl_test permit icmp any any
gandalf(config)# access-list acl_test deny ip any any
gandalf(config)# show access-list acl_test
access-list acl_test; 5 elements
access-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.