Proper Firewall Implementation Procedure

A firewall implementation procedure should prescribe the systematic process to install and configure a firewall properly. Because each firewall product is different and each type of deployment is likely different (for example, a border firewall versus an internal host firewall), you may even find that you need several firewall implementation guides.

The specifics of an implementation guide are different for each organization. Customizing a plan for your specific environment is essential to obtain the best security from the deployed firewall. However, every plan should have certain common elements. Whether you are developing your own firewall implementation policy or revising an existing one, use the following plan components to make yours the best possible policy for your organization.

Every firewall procedure should clearly define the requirements for the firewall. A generic description of a firewall is insufficient. Don’t just indicate that you need a software firewall or an appliance firewall. Instead, dictate the specific capabilities, features, and requirements to accomplish the tasks and security goals. You can include a specific example of a vendor’s exact make and model. However, products are frequently changed, revised, replaced, and retired by vendors. Include an inventory of features and specifications, even if you focus on a certain off-the-shelf product.

Specify the network design that the firewall will complement. To be effective, network firewalls (as opposed to host firewalls) must be at chokepoints or transition points. The design of the network is an essential element of effective firewall deployment. Define and even map out the network structure that should exist, pinpointing exactly where the firewall is, down to the logical configuration and the physical cables connecting to it. Your network design will change over time, but this can always change in the future when you perform change documentation and guidelines revision.

Write the plan down. Write out step by step, point by point, every action to take from the moment the firewall arrives on site through the point of enabling the filtering of production traffic. Include hardening of the bastion host, applying patches, updating firmware, changing defaults (especially passwords), locking down management interfaces, changing configuration settings, defining the rule sets, configuring interfaces, installing the physical components, backing up the configuration, testing at startup, testing for stress and load, documenting performance and stability, obtaining approval from senior management, and initiating filtering of production traffic.

Include photos in the documentation for quick retrieval of information. This should include the configuration screens and any physical setup, including cable attachment and labeling. The saying “a picture is worth a thousand words” is true when mission-critical functions are down on the network. The faster each is restored, the more likely the business is to survive the network crash or issue.

Write down every aspect of firewall use before deployment. Journal every step performed from start to finish of deployment, and then record into the documentation every action in managing, administering, monitoring, and troubleshooting the firewall for the remainder of its deployment life. No action or event is too insignificant to record relative to your firewall deployment. This comprehensive firewall documentation is essential to management, troubleshooting, recovery, and incident response.

Be prepared to face a situation where the final design of the firewall may involve political issues from upper management and other departments of the company. For example, the security policy may state that the Network News Transfer Protocol (NNTP) is not essential for the organization. You would then design the firewall to block all NNTP traffic. But even though it may not be essential, upper management may decide to allow the traffic.

You also need to decide how you want to configure the firewall and what strategy you’ll use. FIGURE 6-1 shows a simple firewall solution with one network firewall and all resources placed behind it.

A diagram illustrates a simple firewall solution.

FIGURE 6-1 Simple firewall solution.

FYI

Many security policies have a special section just for the firewall, outlining how to configure and use it. For example, many organizations recognize that every service and protocol allowed through the firewall represents a risk. By blocking traffic that is not needed to support the organization, these risks are eliminated. A simpler route is to just monitor the activity at the network and web server, but it may subject the network to risks you can easily avoid.

This method is generally not recommended for organizations that host Internet-facing servers such as email servers or web servers. These servers can go behind this single firewall, and you can configure the firewall to direct Internet traffic to the servers using port forwarding. However, this exposes the internal network to potential threats from the Internet. If you instead put your Internet-facing servers directly on the Internet, you expose these to threats of attack from anywhere in the world.

An alternative for organizations that have Internet-facing servers is to use a perimeter network. FIGURE 6-2 shows one example. The firewall has three connections: one to the Internet, one to the internal network, and one to the perimeter network. This is also known as a bastion host. In this solution, the firewall will direct traffic destined for the Internet-facing servers to the servers on the perimeter network. Unrequested traffic from the Internet will be blocked from entering the internal network.

A diagram illustrates a multi-homed firewall used for a perimeter network.

FIGURE 6-2 Multi-homed firewall used for a perimeter network.

The third solution uses two firewalls to create a demilitarized zone (DMZ) as shown in FIGURE 6-3. This provides several benefits. The two firewalls provide an additional layer of security for the internal network. If the web server requires access to a database, the database server can be placed in the internal network for better protection. Internet users will not be able to access the database server directly.

A diagram illustrates two firewalls used to create a D M Z network.

FIGURE 6-3 Two firewalls used to create a DMZ.

Many organizations use two different brands for their different firewalls. If a flaw or vulnerability appears in one, it is unlikely the second firewall will be vulnerable at the same time. Additionally, an attacker may be an expert at hacking one brand of firewall, but it is less likely that the attacker has the same level of expertise against two separate brands.

Remember, though, you need to balance the needs of the organization with the security requirements. While it is a true that a DMZ provides more protection than a single firewall, it also costs more.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.112.90