Design Elements for Perimeter Security

UNIT-10

Firewall and Router

The firewall and the router are two of the most common perimeter

security components.

Figure next illustrates one of the most common way to deploy a router

and a firewall together.

Deploy a router with a firewall behind it

Basic Filtering

The router is responsible for performing the routing functions.

It often makes sense to use the router's packet-filtering capabilities to

filter out some of the "noise" that we might not care to see in the

firewall's logs or that we want to stop at the very edge of the network.

Access Control

The firewall has primary access control responsibilities.

This is where we will implement the policy of blocking all traffic by default

and explicitly allowing only those protocols our business requires.

In some cases, placing systems onto the Screened Subnet might not be

appropriate.

Because the firewall is too much of a bottleneck, or because the system is

not trusted to be located on the same subnet as the servers in the

Screened Subnet

Router Under the ISP's Control

ISPs can provide you with an Ethernet connection to their networking

equipment, eliminating the need to set up your own border router.

But not giving you control over how their router is maintained and

configured.

You would then typically place your firewall behind the ISP's router.

In some respects, this simplifies the task of setting up and

administrating your network because you have to maintain one fewer

component.

At the same time, you cannot trust that the ISP configured the router in

the same way you would have configured it.

Router Without the Firewall

Border router is the only device that separated the internal network

from the Internet.

In some case it might still be appropriate for organizations that decide

that risks associated with the lack of the firewall are acceptable to their

business.

When properly configured, routers can be quite effective at blocking

unwanted traffic, especially if they implement reflexive access lists or if

they use the firewall feature set built in to high-end routers.

It is common to find routers at various other points on the internal

network, not just at the border of the perimeter. After all, the router's

primary purpose is to connect networks, and a company might need to

connect to networks other than the Internet.

Router Without the Firewall

Even when you are using routers with private WAN connections, such as

T1s or frame relay links, lock down the devices, tightening their

configuration by disabling unnecessary services and setting up required

access control lists.

This approach is compatible with the defense-in-depth methodology

we've been discussing, and it helps protect the network against a

multitude of threats we might not be aware of yet.

Firewall and VPNFirewalls are generally responsible for controlling access to resources,

and VPN devices are responsible for securing communication links between hosts or networks.

Examining how VPNs interact with firewalls is important for several reasons:

1) Network Address Translation (NAT) might be incompatible with some VPN implementations, depending on your network's architecture.

2) VPNs might create tunnels through your perimeter that make it difficult for the firewall to enforce access restrictions on encrypted traffic.

3) VPN endpoints have access to data in clear text because VPN devices are the ones that decrypt or authenticate it; this might warrant special considerations for protecting the VPN device.

4) VPNs, by protecting confidentiality of the encrypted data, can be used to pass by IDSs undetected.

Firewall and VPNWhen deciding how to incorporate a VPN component into the network

architecture, we have two high-level choices:

1. maintaining the VPN module as its own device, external to the

firewall,

2. integrating the VPN with the firewall so that both services are

provided by the same system.

Each approach has its intricacies, strengths, and weaknesses. We will

present the general overview here

Firewall with VPN as External Device

Many design choices allow us to set up a VPN endpoint as a device that

is external to the firewall.

Some of the placement options for VPN hardware include as follows:

1) In the DMZ, between the firewall and the border router

2) In the screened subnet, off the firewall's third network interface card

3) On the internal network, behind the firewall

4) In parallel with the firewall at the entry point to the internal network

Some of problems are associated with above mentioned configuration are

explained ahead.

Firewall with VPN as External Device (Issues)NAT is the cause of some of the most frequently occurring problems

when VPN equipment is deployed separately from the firewall.

Another issue with VPN devices located behind the firewall is address

management; some VPN specifications require VPN devices to be

assigned a legal IP address.

Firewall with VPN as External Device (Issues)Placing VPN hardware in front of the firewall, closer to the Internet,

helps avoid potential NAT and address management problems, but it

might introduce other concerns associated with all NAT deployments. As

you probably know, many applications such as those that use

Microsoft's Distributed Component Model (DCOM) protocols do not

work with some NAT implementations.

Another disadvantage of placing VPN devices in front of the firewall is

that they cannot enjoy the protection the firewall offers. If the system

serving as the VPN endpoint is compromised, the attacker might gain

access to information whose confidentiality is supposed to be protected

by the VPN.

Firewall and VPN in One System

When deploying a device that integrates VPN and firewall functionality

into a single system, you will most likely recognize some cost savings

over the solutions in which the two devices are separated.

One of the biggest drawbacks of an integrated solution is that you might

be limited in the choices you can make with regard to optimally

deploying your VPN and firewall components.

Firewall products that match most closely to your business needs might

not be as well suited to their VPN components. Similarly, under some

situations, you will benefit from deploying an external specialized VPN

device, and purchasing an integrated solution might lock you into having

VPN and firewall components on the same system.

Multiple Firewalls Some designs call for the use of multiple firewalls to protect the

network. This makes sense when you want to provide different levels of

protection for resources with different security needs. Such scenarios might involve deploying firewalls inline, one behind

another, to segment resources with different security requirements. Firewalls can also be deployed in parallel, next to each other and equidistant from the Internet.

Using multiple firewalls provides the designer with the ability to control access to resources in a fine-grained manner.

Some products, such as Check Point FireWall-1, provide an intuitive interface for controlling multiple firewalls from a single system. Others, such as NetFilter, might require more significant efforts for keeping firewall configurations in sync with the organization's security policy.

Inline Firewalls Inline firewalls are deployed one behind another, and traffic coming to

and from the Internet might be subjected to access control restrictions of multiple firewall devices.

If locating one firewall-like device right behind another seems wasteful to you, another inline configuration, presented in Figure next, might make more sense.

Here, we take advantage of the subnets with different security levels created by multiple firewalls.

The closer the subnet is to the Internet, the less secure it is. In such an architecture, we could place web servers behind the first firewall, while keeping more sensitive resources, such as database servers, behind the second firewall. The first firewall could be configured to allow traffic to hit web servers only, whereas the second firewall would only allow web servers to talk to the database servers.

Inline Firewalls One of the biggest problems with environments incorporating inline

firewalls is that of manageability. Not only do you need to set up, maintain, and monitor multiple

firewalls, but you need to support multiple firewall policies. If, for example, you need to allow a system behind multiple firewalls to connect to the Internet, you need to remember to modify the rule sets of both firewalls.

Commercial firewalls, such as Check Point FireWall-1 and Cisco PIX, provide software solutions for managing multiple firewalls from a single console, and they allow you to ensure that all inline firewalls are properly configured.

If you determine that a device protected by inline firewalls needs to communicate directly with the Internet, you might also consider restructuring the network's design to minimize the number of firewalls to be traversed.

Firewalls in Parallel

Many times you might be compelled to set up firewalls in parallel with each other.

We can design architectures that incorporate firewalls in parallel in many ways. In most

such configurations, the firewalls protect resources with different security needs.

When firewalls are set up inline, as discussed in the previous section, packets destined

for the hosts deep within the organization's network might be delayed because they

need to go through several access control devices. With parallel firewalls, this is not a

significant concern because the firewalls are equidistant from the Internet.

In a parallel configuration, we can deploy firewalls that are each tuned specifically for

the resources they are protecting. One such scenario is shown in Figure 12.3. Here, we

use an application gateway and a stateful firewall, each protecting a different set of

systems.

Firewalls in Parallel

In a parallel configuration, we can deploy firewalls that are each tuned

specifically for the resources they are protecting.

One such scenario is shown in Figure next. Here, we use an application

gateway and a stateful firewall, each protecting a different set of

systems.

Firewalls in Parallel In this example, we assume that our business requires the use of robust

proxy-level capabilities of an application gateway to protect Internet-

accessible systems such as web, SMTP, and DNS servers.

We are okay with the generally slower performance of the proxying

firewall for this purpose.

At the same time, we need the flexibility of a stateful firewall for the

corporate network, which hosts internal workstations and servers. By

deploying two different firewalls in parallel, we are able to take

advantage of the best-of-breed functions offered by each type of device.

At the same time, we do not have the luxury of placing a system behind

multiple layers of firewalls, as would be the case with the inline

configuration.