Adaptive Security Algorithm

Adaptive Security Algorithm

In Chapter 17, Adaptive Security Algorithm (ASA) was introduced as being the heart of the PIX Firewall system. Recognizing that ASA is more than just an algorithm for controlling the direction of traffic flows is important. ASA defines and controls all aspects and features of the PIX devices. While extremely powerful and versatile, ASA is less complex and more robust than packet filtering implementations. ASA provides performance and scalability advantages over application-level proxy firewalls.

ASA concepts introduced in this section, and covered in greater detail throughout this chapter, include the following:

  • Security levels

  • Stateful system

  • Translations

  • Connections

Security Levels

Simply stated, every interface on a PIX firewall is assigned a numeric security, or trust, level between 0 and 100. The larger the value, the higher the trust level, with 100 reserved for the inside interface and 0 reserved for the outside interface. Basic PIX ASA operation allows data to travel freely from interfaces with higher security values to interfaces with lower security values. This means, in a two-interface firewall, traffic can always flow without additional assistance from hosts connected to the inside interface out through the outside interface to whatever lies beyond.

Prior to version 5.2 of the PIX OS, Ethernet 1 was reserved for the inside and set to security level 100, and Ethernet 0 was reserved for the outside and set to security level 0. Since 5.2, these are still the defaults, but it’s possible to assign any interface as either the inside or the outside. The 100 and 0 security levels must still be assigned to the inside and outside interfaces, respectively.

When you think of security levels, think of data as a liquid and of security levels as elevation. Data would flow freely from the higher elevation to the lower elevation without additional assistance. Unfortunately, the analogy falls apart once you recognize that data, unlike liquids, flows in both directions. This is particularly problematic with data that’s in response to a request, returning traffic.

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.

Click To expand
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.

Click To expand
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.

Stateful System

ASA, much like the PIX IOS Firewall CBAC feature covered in Chapter 6, incorporates a stateful approach to evaluating inbound traffic. A stateful approach allows the firewall to use knowledge of how certain applications and protocols function to create temporary openings in the firewall to allow effective data exchanges. This effectively creates as-needed application-level filtering capabilities for those supported technologies.

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.

Click To expand
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.

Translations

ASA applies to the address translations that are integral to the PIX device in providing security by concealing the internal host addresses from the outside world. These translations can be either static (permanent) translations for servers and shared devices, which must be reliably accessed from the outside world, or dynamic translations to assist internal hosts in venturing out of the network.

As you saw in Chapter 17, and will see again in the next section, static translations use the static command, while dynamic translations use the global and nat commands in either Network Address Translation (NAT) or Port Address Translation (PAT) implementations. Both static and dynamic translations result in translation table entries or translation slots, referred to as xlates in the PIX environment.

Connections

You must realize that translations and connections aren’t the same thing. A translation is literally the substitution of an alias for a local address, but it can’t represent an existing connection. For example, a static translation creates an xlate entry to allow outside access to a web server in the DMZ, but there can be no active connection.

Connections, on the other hand, use translations to allow communication from one host to another. In fact, it’s possible that a single translation allowing access to a web server might have several active connections underway.

The ASA default rules pertaining to connections include the following:

  • No packets can pass through a PIX Firewall without a connection and a state table entry.

  • All outbound connections or states are allowed, except those specifically denied by ACLs. Remember, in firewall parlance, “outbound” refers to originating in any higher security-level interface destined to a lower security interface. This means the connection might originate on a DMZ interface destined for the outside interface, as in the case of an e-mail server searching for Internet mail updates.

  • All inbound connections or states are denied, except those specifically configured using ACLs or conduits. Inbound connections or states originate on a lower security interface than the destination device.

  • All ICMP packets are denied, unless specifically permitted with ACLs or conduits.

  • Any packet that can’t meet one of the rules, or when no exception has been configured, is dropped and a syslog message is sent.




Part III: Virtual Private Networks (VPNs)