Adaptive Security Algorithm

Returning Traffic

While the previous concept is always explained in any discussion of ASA, something that often goes unsaid is this: any resulting return traffic also passes freely through the firewall, unless some configuration prevents it. Simply, if all traffic into the network was the result of outgoing requests from trusted hosts, no need would exist for any additional PIX configuration. Figure 19-1 shows a two-interface firewall and the unassisted traffic flow patterns.

Figure 19-1: A two-interface firewall showing data traffic flows

Security Levels 1 to 99

In addition to inside and outside interfaces, a firewall can have one or more protected interfaces connected to shared resources such as web servers. The resulting connections are referred to as DMZ networks or bastion networks, while the devices are referred to as DMZ hosts or bastion hosts.

ASA security levels 1 to 99 are used for the DMZ interfaces. If the PIX device has a single, protected DMZ interface, the security level would be configured between the inside and outside levels, such as 50. Figure 19-2 shows the interfaces just described. Packets originating from the inside interface could flow freely to the DMZ and reply packets could return to the inside interface. Packets originating in the DMZ that aren’t a part of a session originating from the inside interface, couldn’t travel to the inside interface without configuration assistance.

Figure 19-2: PIX security levels with a DMZ interface

DMZ originating packets can travel freely to the outside and can receive reply packets without additional configuration. This is particularly useful for servers, such as e-mail, DNS, and content servers, which must periodically communicate with the outside world.

Multiple protected DMZ interfaces are becoming more common as a way of offering varied levels of security for different types of shared resources. If multiple DMZ interfaces are used, it’s important to plan the security level assignments to make sure security flows properly. If two DMZ interfaces have the same security level, no traffic would flow between the interfaces without special configuration in both directions.

The following output shows an example of configuring four DMZ interfaces:

Pix(config)# write terminal
 ??(lines omitted)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz1 security80
nameif ethernet3 dmz2 security60
nameif ethernet4 dmz3 security40
nameif ethernet5 dmz4 security20
hostname Pix
 ??(lines omitted)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto
interface ethernet4 auto
interface ethernet5 auto
 ??(lines omitted)
ip address outside 1.1.1.1 255.255.255.0
ip address inside 192.168.1.1 255.255.255.0
ip address dmz1 192.168.2.1 255.255.255.0
ip address dmz2 192.168.3.1 255.255.255.0
ip address dmz3 192.168.4.1 255.255.255.0
ip address dmz4 192.168.5.1 255.255.255.0

Inbound Traffic

Because any traffic inbound from a low-security level interface to a higher security level interface is blocked by the ASA, configuring the device to allow for any exceptions is necessary. Combinations of the static command and access control lists (ACLs), or conduits, are used to allow these specific flows. Static commands are discussed in the upcoming section “Static Alone Is Not Enough” and ACLs are discussed in the section “Access Control Lists.”

Remember, this discussion is about holes punched through the firewall, each of which represents a vulnerability for the firewall device and protected networks behind them. Therefore, it’s only advisable to create these holes if they’re specifically allowed by the security policy. An example might be to allow outside users to access the organization’s web server on a protected DMZ. In this case, it’s important that the resulting hole allows controlled access to the appropriate DMZ, but not to the inside network.

Stateless Firewalls

Firewalls based on the stateless packet filtering model can, at most, only create mirror images of outbound traffic, like reflexive ACLs on Cisco routers. By being limited to source and destination address/port combinations, these technologies are effectively limited to Layer 3/Layer 4 filtering. Technologies that change port specifications or port requirements after the initial session exchange, such as multimedia applications, typically can’t function within packet filtering-only systems. To accommodate these technologies, the network administrator is often required to create permanent port openings, which could be discovered and exploited by hackers.

Figure 19-3 shows an example of a typical type of filtering that could be created by a stateless, packet filter-based firewall. In this example, an outbound packet to a web server creates a mirror-image inbound filter that would allow the requested information to return. This works well in many situations, particularly with typical TCP traffic. But what if the original request was to an FTP server, where the packet was sent to port 20, but port 21 responds? Now the filter isn’t right. Remember, firewalls are mindless devices that can only follow rules and can’t interpret or be appealed to with logic. The return traffic would probably fail.

Figure 19-3: Stateless firewall with reflexive-type filtering

Another problem scenario is a client-server type application where the outgoing packet is a request to a SQL server. In meeting the request, the SQL server forwards the packet on to another SQL server. When the reply arrives at the firewall, the source address could be the second server and would, therefore, fail to match the filter. If a permanent ACL entry is created to allow predictable traffic from the SQL data server, it could be detected in a port scan of the firewall and possibly exploited.

That only a stateful firewall that’s programmed to support SQL traffic could recognize the returning traffic is a reasonable expectation, based on the stateful table entries created when the original request went out. To maintain security that’s as tight as possible, while allowing legitimate inbound traffic, the ASA stateful algorithm looks at other packet fields, such as sequence number, acknowledgment, and code bit fields.

TCP Header Knowledge

ASA’s programming allows it to recognize additional TCP fields, such as sequence number, acknowledgement, and code bit fields, as well as the TCP three-step handshake used to establish a session. This programming allows ASA to detect and respond to irregularities, such as too many embryonic (half-open) sessions, sequence number irregularities, or session fragments, all of which could indicate an attack.