Section 1-1. Overview of Firewall Operation

team bbl


1-1. Overview of Firewall Operation

A firewall's essential function is to isolate its interfaces from each other and to carefully control how packets are forwarded from one interface to another. In its default state, a firewall does not allow any packets to pass through it until some security policies are configured.

Before connections can form between firewall interfaces, two conditions must be met:

  • An address translation policy must be configured between a pair of interfaces.

  • A security policy must be configured to allow the connection to initiate toward the destination. This is usually in the form of an access list applied to a firewall interface.

A Cisco firewall inspects traffic through a progression of functions. Figure 1-3 shows the order of these functions as a packet arrives at interface X (the left side of the figure) and exits at interface Y (the right side of the figure). The following sections describe each firewall function.

Figure 1-3. A Cisco Firewall's Sequence of Packet Inspection Functions


Initial Checking

As packets arrive at a firewall interface, they are checked for basic integrity. One of the most important things that can be checked is the integrity of a packet's source address. When a host sends a packet through a firewall, the firewall normally is concerned with finding a route for the destination address so that the correct egress interface can be used. The source address usually is ignored until the destination host needs to send a reply.

A malicious host can insert a bogus source IP address into the packets it sends. This is called address spoofing, and it is used to impersonate another host. When the malicious traffic is received, it looks like someone else sent it.

RFC 2827, "Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IP Source Address Spoofing," describes a method that a firewall can use to detect when a source address is being spoofed.

NOTE

You can find all RFCs online at http://www.ietf.org/rfc/rfcxxxx.txt, where xxxx is the number of the RFC. If you do not know the RFC's number, you can try searching by topic at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl.


A Cisco firewall uses this technique in its Unicast Reverse Path Forwarding (RPF) feature. When this feature is enabled on an interface, the source address in each incoming packet is inspected. The source address must be found in the firewall's table of known routes, which in turn must reference the interface on which the packet arrived. In other words, the firewall just verifies that the packet would take the same path in reverse to reach the source.

The firewall drops any packets that don't meet the RPF test, and the action is logged. If the RPF feature is enabled, you should make sure any IP subnets that can be reached on a firewall interface are also identified with a route command on the firewall. That way, the firewall can find those source addresses for the RPF test (as well as send packets toward those destination networks).

The outside firewall interface is a special case, however. Usually, the firewall has a default route associated with the outside interface, because most of the public network or Internet can be found on the outside. How can a firewall check for address spoofing on packets arriving at the outside interface?

If a source address can't be found in the table of known routes, the default route is assumed to match. Therefore, packets arriving from the outside pass the RPF test as long as the source subnet or a default route exists. If an outside host uses a spoofed source address that belongs to a host or subnet on another firewall interface, however, the firewall finds that the reverse path doesn't match.

In other words, RPF can detect spoofed addresses only when they are spoofed between interfaces. To do this, the firewall has to know that a spoofed address on one interface actually exists on another interface. Only those packets are dropped. However, if a host on the outside interface spoofs the address of another outside host, the firewall can't detect it, because the spoofing occurs on a single interface.

Xlate Lookup

A Cisco firewall maintains a translation or xlate table for each protected host that can participate in connections. A host's xlate entry can be statically defined before any active connections form. However, the static xlate entry is not actually created and used until the relevant traffic passes through the firewall. The host's xlate entry can also be created dynamically as a new connection is initiated.

Figure 1-4 illustrates the concept behind xlate operation. A host outside the firewall (Host A) has a registered public IP address, called a foreign address. A host on the inside of the firewall (Host B) has an internal IP address, called the real or local address. The internal host's address is translated through an xlate entry so that the local address appears on the outside of the firewall as a mapped or global address. Address translation is covered in greater detail in Chapter 6, "Controlling Access Through the Firewall."

Figure 1-4. The Basic Concept Behind Xlate


Each entry in the xlate table is maintained with the following parameters:

  • Protocol used (ICMP, UDP, or TCP)

  • Local and global interfaces

  • Local and global IP addresses

  • Local and global port numbers (if applicable; UDP and TCP only)

  • Flags (type of xlate)

  • Idle timer (incremented if no packets have used the xlate)

  • Absolute timer (incremented since the xlate entry was created)

  • Uauth bindings (originating user if user authentication or cut-through proxy is used)

  • Connections using the xlate entry:

    - Number of connections

    - Number of embryonic (not yet fully established) connections

    - A list of the active connections

Xlate table lookups occur at different points in the inspection process, depending on the direction of the connec-tion. For an outbound connection (initiated from the inside), the xlate entry must be created early in the sequence of events. This is because the translated (global) address is used to build the actual connection entry and is used as the reference point for any access control list (ACL) operations. For inbound connections, the opposite is trueany connections and ACL operations must look at the untranslated (global) addresses, so xlate lookup must occur late in the game.

A firewall controls several aspects of each xlate entry:

  • The number of active connections allowed to use an entry can be held to a maximum limit or can be unlimited (the default)

  • The number of embryonic connections attempting to use an entry can be held to a maximum limit or can be unlimited (the default)

  • An entry is aged out of the table if it has been idle for a timeout period

Conn Lookup

A Cisco firewall examines and keeps track of the state of each connection attempting to go through it. This is often called stateful inspection. If a connection is allowed to form (the access list permits the traffic flow), each state change is updated in the firewall's connection or conn table. As soon as a connection initiates and a conn table entry is created, traffic from the source to the destination is allowed to pass. As well, the return traffic for that connection is allowed back through the firewall toward the source.

The connection state and the behavior of packets from the source and destination must follow the rules of the IP protocol being used. Any deviation from the accepted behavior causes the connection to be dropped and logged.

Each entry in the conn table is maintained with the following parameters:

  • Protocol used (ICMP, UDP, or TCP)

  • Local and foreign IP addresses (note that local addresses are used here, after the xlate lookup)

  • Local and foreign port numbers (if applicable; UDP and TCP only)

  • Flags for fixup type and connection state

  • Idle timer (incremented if no packets have used the connection)

  • Byte counter (total traffic volume using the connection)

  • Local and foreign TCP sequence numbers

Conn entries are aged out of the table if they have been idle (no data passing through) for a timeout period. Conn entries can also age out after a short period if the connections are not fully established.

When Transmission Control Protocol (TCP) is used for a connection, a Cisco firewall can generate a random initial sequence number (ISN) toward the foreign host. Some hosts don't generate a truly random ISN, resulting in predictable values that can be exploited. The firewall can substitute a truly random ISN into the TCP packets when the connection is negotiated. This reduces the risk of session hijacking and is totally transparent to the local and foreign hosts.

ACL Lookup

Before a connection can be completed or actually allowed to form, its traffic must be permitted by an ACL. You can configure any number of ACLs in a firewall, but only one ACL can be applied to a firewall interface in a specific direction.

NOTE

Before PIX 7.x, ACLs could be applied in only the inbound direction, to inspect traffic as it enters the interface. Beginning with PIX 7.x, ACLs can be applied in the inbound or outbound direction.


ACLs are not used to inspect a connection's state. Rather, they are used only to permit or deny packets in a single direction, only as connections are being initiated. For connectionless protocols such as Internet Control Message Protocol (ICMP), ACLs permit or deny all packets in the direction in which they are applied.

By default, no ACLs are configured or applied to any of a firewall's interfaces. Connections are permitted to initiate from a higher-security interface to a lower oneeven with no ACL applied to the higher-security interface. One exception is the Catalyst 6000 Firewall Services Module, which requires an ACL on any interface before permitting traffic to pass. However, no connections are allowed to initiate from a lower-security interface to a higher one until an ACL is applied to the lower-security interface.

ACL configuration and use are covered in greater detail in Chapter 6 in section 6-3, "Controlling Access with Access Lists."

Uauth Lookup

A Cisco firewall can authenticate users as they pass through to initiate connections. After a user is successfully authenticated, the firewall keeps the user credentials cached so that additional connections can be quickly approved. In other words, the firewall acts as a cut-through authen-tication proxy so that no further authentication is needed.

User authentication occurs by a request-reply exchange between the firewall and an authentication, authorization, and accounting (AAA) server, such as Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access Control System Plus (TACACS+).

After a user is authenticated, the firewall can also request authorization information from the server. This information is used to limit users to reaching only specific resources through the firewall. The firewall can authorize users through one of the following methods:

  • Retrieving a AAA attribute for the user

  • Controlling the user's connections with an ACL referenced by the AAA server

  • Controlling the user's connections with an ACL that has been downloaded from the AAA server

The firewall performs these functions by keeping a table of authenticated users and their user auth-entication (uauth) attributes. The uauth table records each authenticated user, along with his or her source IP address, the authorization ACL name (if any), and session timer values. In Chapter 5, "Managing Firewall Users," section 5-5, "Configuring AAA for End-User Cut-Through Proxy," covers AAA functions in greater detail.

After a user authenticates with the firewall, he can use and create new connections until his absolute uauth timer expires. As well, the firewall tracks to see if the user has not sent or received data on any of his connections for an idle uauth timer period. If the idle timer expires, that user is deleted from the uauth table, and all current connections are closed. That user is required to reauthenticate when he attempts a new connection. If the absolute timer expires, all the user's existing connections are allowed to remain open. However, the user is prompted to reauthenticate when a new connection is initiated.

Inspection Engine

The firewall inspects each connection and applies rules according to the protocol being used. This process has traditionally been called fixup, and more recently an inspection engine.

Some protocols are simple and have very loose guidelines about the traffic between source and destination. These are called connectionless protocols, and they include ICMP and UDP. Other protocols are very strict about the handshaking and packet exchange between source and destination. These are called connection-oriented protocols, and they include TCP.

    team bbl



    Cisco ASA and PIX Firewall Handbook
    CCNP BCMSN Exam Certification Guide (3rd Edition)
    ISBN: 1587051583
    EAN: 2147483647
    Year: 2003
    Pages: 120
    Authors: David Hucaby

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net