> Personal Stateful Firewall Overview
> This chapter provides an overview of the Personal Stateful Firewall In-line Service.
> This chapter covers the following topics:

> • | Supported Platforms and Products

> • | Licenses

> • | Overview

> • | Supported Features

> • | How Personal Stateful Firewall Works

> • | Understanding Firewall Rules with Stateful Inspection

> Supported Platforms and Products
> The Personal Stateful Firewall is an in-line service feature available on the Cisco� ASR 5000 chassis running 3GPP, 3GPP2, and WiMAX core network services.
> Important: For information on ASR 5000, please refer to the Product Overview Guide.
> Licenses
> The Personal Stateful Firewall is a licensed in-line service feature requiring the following license:
> [ 600-00-7571 ] Per Subscriber Stateful Firewall 1k sessions
> Important: For information on license requirements for any customer-specific features, please contact your local sales/service representative.
> Important: For information on installing licenses, see the Managing License Keys chapter of the System Administration and Configuration Guide.
> Overview
> The Personal Stateful Firewall is an in-line service feature that inspects subscriber traffic and performs IP session-based access control of individual subscriber sessions to protect the subscribers from malicious security attacks.
> The Personal Stateful Firewall supports stateless and stateful inspection and filtering based on the configuration.
> In stateless inspection, the firewall inspects a packet to determine the 5-tuple—source and destination IP addresses and ports, and protocol—information contained in the packet. This static information is then compared against configurable rules to determine whether to allow or drop the packet. In stateless inspection the firewall examines each packet individually, it is unaware of the packets that have passed through before it, and has no way of knowing if any given packet is part of an existing connection, is trying to establish a new connection, or is a rogue packet.
> In stateful inspection, the firewall not only inspects packets up through the application layer / layer 7 determining a packet's header information and data content, but also monitors and keeps track of the connection's state. For all active connections traversing the firewall, the state information, which may include IP addresses and ports involved, the sequence numbers and acknowledgement numbers of the packets traversing the connection, TCP packet flags, etc. is maintained in a state table. Filtering decisions are based not only on rules but also on the connection state established by prior packets on that connection. This enables to prevent a variety of DoS, DDoS, and other security violations. Once a connection is torn down, or is timed out, its entry in the state table is discarded. For more information see the Connection State and State Table in Personal Stateful Firewall section.
> The Enhanced Charging Service (ECS) / Active Charging Service (ACS) in-line service is the primary vehicle that performs packet inspection and charging. For more information on ECS, see the Enhanced Charging Service Administration Guide.
> Supported Features
> The Personal Stateful Firewall supports the following features:

> • | Protection against DoS Attacks

> • | Application-level Gateway (ALG) Support

> • | Stateful Packet Filtering and Inspection Support

> • | Stateless Packet Filtering and Inspection Support

> • | Host Pool, IMSI Pool, and Port Map Support

> • | Flow Recovery Support

> • | SNMP Thresholding Support

> • | Logging Support

> Protection against Denial-of-Service Attacks
> Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks can deprive network resources/services unavailable to its intended users.
> DoS attacks can result in:

> • | A host consuming excessive resources—memory, disk space, CPU time, etc.—eventually leading to a system crash or providing very sluggish response.

> • | Flooding of the network to the extent that no valid traffic is able to reach the intended destination.

> • | Confusing target TCP/IP stack on destination hosts by sending crafted, malformed packets eventually resulting in system crash.

> DoS attacks can destroy data in affected mobile nodes. Stateful Firewall is designed to defend subscribers and prevent the abuse of network bandwidth from DoS attacks originating from both the Internet and the internal network.
> Types of Denial-of-Service Attacks
> Personal Stateful Firewall can detect the following DoS attacks.
> The DoS attacks are listed based on the protocol layer that they work on.

> • | IP-based Attacks:

> • | Land attacks

> • | Jolt attacks

> • | Teardrop attacks — Detected only in downlink direction, i.e. traffic coming from the external network towards the mobile subscribers

> • | Invalid IP option length

> • | IP-unaligned-timestamp attack — Detected only in downlink direction

> • | Short IP header length

> • | IP checksum errors

> • | IP reassembly failure (downlink)

> • | IP reassembly failure (uplink)

> • | Source router — Detected only in downlink direction

> • | TCP-based Attacks:

> • | Data packets received after RST/FIN

> • | Invalid SEQ number received with RST

> • | Data without connection established

> • | Invalid TCP connection requests

> • | Invalid TCP pre-connection requests

> • | Invalid ACK value (cookie enabled)

> • | Invalid TCP packet length

> • | Short TCP header length

> • | TCP checksum errors

> • | SEQ/ACK out-of-range

> • | TCP null scan attacks

> • | Post connection SYN

> • | No TCP flags set

> • | All TCP flags set

> • | Invalid TCP packets

> • | Flows closed by RST before 3-Way handshake

> • | Flows timed-out in SYN_RCVD1 state

> • | Flows timed-out in SYN_RCVD2 state

> • | TCP-SYN flood attacks — Detected only in downlink direction

> • | FTP bounce attack — Detected only in downlink direction

> • | MIME flood attacks — Detected only in downlink direction

> • | Exceeding reset message threshold

> • | Source port zero

> • | WinNuke attack — Detected only in downlink direction

> • | TCP-window-containment — Detected only in downlink direction

> • | UDP-based Attacks:

> • | Invalid UDP echo response

> • | Invalid UDP packet length

> • | UDP checksum errors

> • | Short UDP header length

> • | UDP flood attack — Detected only in downlink direction

> • | ICMP-based Attacks:

> • | Invalid ICMP response

> • | ICMP reply error

> • | Invalid ICMP type packet

> • | ICMP error message replay attacks

> • | ICMP packets with duplicate sequence number

> • | Short ICMP header length

> • | Invalid ICMP packet length

> • | ICMP flood attack — Detected only in downlink direction

> • | Ping of death attacks

> • | ICMP checksum errors

> • | ICMP packets with destination unreachable message

> • | Other DoS Attacks

> • | Port-scan attacks — Detected only in downlink direction

> Protection against Port Scanning
> Port scanning is a technique used to determine the states of TCP/UDP ports on a network host, and to map out hosts on a network. Essentially, a port scan consists of sending a message to each port on the host, one at a time. The kind of response received indicates whether the port is used, and can therefore be probed further for weakness. This way hackers find potential weaknesses that can be exploited.
> Stateful Firewall provides protection against port scanning by implementing port scan detection algorithms. Port-scan attacks are only detected in the downlink direction—traffic from external network towards mobile subscribers.
> Application-level Gateway Support
> A stateful firewall while ensuring that only legitimate connections are allowed, also maintains the state of an allowed connection. Some network applications require additional connections to be opened up in either direction and information regarding such connections is sent in the application payload. For these applications to work properly, a stateful firewall must inspect, analyze, and parse these application payloads to get the additional connection information, and open partial connections/pinholes in the firewall to allow the connections.
> To parse application payloads, firewall employs ALGs. ALGs also check for application-level attacks. Personal Stateful Firewall provides ALG functionality for the following protocols:

> • | File Transfer Protocol (FTP)

> • | Real Time Protocol (RTP)

> • | Real Time Streaming Protocol (RTSP)

> ALG support for Simple Mail Transfer Protocol (SMTP) and HTTP is ECS functionality.
> Stateful Packet Inspection and Filtering Support
> As described in the Overview section, stateful packet inspection and filtering uses Layer-4 information as well as the application-level commands up to Layer-7 to provide good definition of the individual connection states to defend from malicious security attacks.
> Personal Stateful Firewall overcomes the disadvantages of static packet filters by disallowing any incoming packets that have the TCP SYN flag set (which means a host is trying to initiate a new connection). If configured, stateful packet filtering allows only packets for new connections initiated from internal hosts to external hosts and disallows packets for new connections initiated from external hosts to internal hosts.
> Stateless Packet Inspection and Filtering Support
> Stateful Firewall service can be configured for stateless processing. In stateless processing, packets are inspected and processed individually.
> Stateless processing is only applicable for TCP and ICMP protocols. By nature UDP is a stateless protocol without any kind of acking or request and reply mechanism at transport level.
> When TCP FSM is disabled, flows can start with any kind of packet and need not respect the TCP FSM. Such flows are marked as dummy (equivalent to flows established during flow recovery timer running). For these flows only packet header check is done; there will be no FSM checks, sequence number validations, or port scan checks done.
> When ICMP FSM is disabled, ICMP reply without corresponding requests, ICMP error message without inner packet data session, and duplicate ICMP requests are allowed by firewall.
> Host Pool, IMSI Pool, and Port Map Support
> This section describes the Host Pool, IMSI Pool, and Port Map features that can be used while configuring access ruledefs.
> Host Pool Support
> Host pools allow operators to group a set of host or IP addresses that share similar characteristics together. Access rule definitions (ruledefs) can be configured with host pools. Up to 10 sets of IP addresses can be configured in each host pool. Host pools are configured in the ACS Host Pool Configuration Mode.
> IMSI Pool Support
> IMSI pools allow the operator to group a set of International Mobile Station Identifier (IMSI) numbers together. Up to 10 sets of IMSI numbers can be configured in each IMSI pool. IMSI pools are configured in the ACS IMSI Pool Configuration Mode.
> Port Map Support
> Port maps allow the operator to group a set of port numbers together. Access ruledefs can be configured with port maps. Up to 10 sets of ports can be configured in each port map. Port maps are configured in the ACS Port Map Configuration Mode.
> The Personal Stateful Firewall uses standard application ports to trigger ALG functionality. The operator can modify the existing set to remove/add new port numbers.
> Flow Recovery Support
> Stateful Firewall supports call recovery during session failover. Flows associated with the calls are recovered.
> A recovery-timeout parameter is configurable for uplink and downlink directions. If the value is set to zero, firewall flow recovery is disabled. If the value is non-zero, then firewall will be bypassed for packets from MS/Internet until the time configured (uplink/downlink). Once the manager recovers, the recovery-timeout timer is started. During this time:

> • | If any ongoing traffic arrives from the subscriber and no association is found, and flow recovery is enabled, basic checks like header processing, attacks, etc. are done (stateful checks of packet is not done), and if all is okay, an association is created and the packet is allowed to pass through.

> • | If any ongoing traffic arrives from the Internet to MS and no association is found, and flow recovery is not enabled, it is dropped. No RESET is sent. Else, basic checks like header processing, flooding attack check are done (stateful checks are not done), and if all is okay, an association is created and the packet is allowed to pass through.

> • | In case flow recovered from ongoing traffic arrives from Internet to MS, and MS sends a NACK, the Unwanted Traffic Suppression feature is triggered, i.e. upon repeatedly receiving NACK from MS for a 5-tuple, further traffic to the 5-tuple is blocked for some duration and not sent to MS.

> • | If any new traffic (3-way handshake) comes, whether it is a new flow or a new flow due to pin-hole, based on the direction of packet and flow-recovery is enabled, basic checks like header processing, attacks, etc. are done (stateful checks are not done) and if all is okay, an association is created and the packet is allowed to pass through.

> For any traffic coming after the recovery-timeout:

> • | If any ongoing traffic arrives, it is allowed only if an association was created earlier. Else, it is dropped and reset is sent.

> • | If any new traffic (3-way handshake) arrives, the usual Stateful Firewall processing is done.

> If recovery-timeout value is set to zero, Stateful Firewall flow recovery is not done.
> SNMP Thresholding Support
> Personal Stateful Firewall allows to configure thresholds to receive notifications for various events that are happening in the system. Whenever a measured value crosses the specified threshold value at the given time, an alarm is generated. And, whenever a measured value falls below the specified threshold clear value at the given time, a clear alarm is generated. The following events are supported for generating and clearing alarms:

> • | Dos-Attacks: When the number of DoS attacks crosses a given value, a threshold is raised, and it is cleared when the number of DoS attacks falls below a value in a given period of time.

> • | Drop-Packets: When the number of dropped packets crosses a given value, a threshold is raised, and it is cleared when the number of dropped packets falls below a value in a given period of time.

> • | Deny-Rule: When the number of Deny Rules cross a given value, a threshold is raised, and it is cleared when the number of Deny Rules falls below a value in a given period of time.

> • | No-Rule: When the number of No Rules cross a given value, a threshold is raised, and it is cleared when the number of No Rules falls below a value in a given period of time.

> Logging Support
> Stateful Firewall supports logging of various messages on screen if logging is enabled for firewall. These logs provide detailed messages at various levels, like critical, error, warning, and debug.
> Logging is also supported at rule level, when enabled through rule a message will be logging whenever a packet hits the rule. This can be turned on/off in a rule.
> These logs are also sent to a syslog server if configured in the system.
> How Personal Stateful Firewall Works
> This section describes how Personal Stateful Firewall works.
> Important: In StarOS 8.x, Stateful Firewall for CDMA and early UMTS releases used rulebase-based configurations, whereas later UMTS releases used policy-based configurations. In StarOS 9.0, Stateful Firewall for UMTS and CDMA releases both use policy-based configurations. For more information, please contact your local service representative.
> Firewall-and-NAT policies are configured in the Firewall-and-NAT Policy Configuration Mode. Each policy contains a set of access ruledefs and the firewall configurations. Multiple such policies can be configured, however, only one policy is applied to a subscriber at any point of time.
> The policy used for a subscriber can be changed either from the CLI, or by dynamic update of policy name in Diameter and RADIUS messages.
> The Firewall-and-NAT policy to be used for a subscriber can be configured in:

> • | ACS Rulebase: The default Firewall-and-NAT policy configured in the ACS rulebase has the least priority. If there is no policy configured in the APN/subscriber template, and/or no policy to use is received from the AAA/OCS, only then the default policy configured in the ACS rulebase is used.

> • | APN/Subscriber Template: The Firewall-and-NAT policy configured in the APN/subscriber template overrides the default policy configured in the ACS rulebase. To use the default policy configured in the ACS rulebase, in the APN/subscriber configuration, the command to use the default rulebase policy must be configured.

> • | AAA/OCS: The Firewall-and-NAT policy to be used can come from the AAA server or the OCS. If the policy comes from the AAA/OCS, it will override the policy configured in the APN/subscriber template and/or the ACS rulebase.

> Important: The Firewall-and-NAT policy received from the AAA and OCS have the same priority. Whichever comes latest, either from AAA/OCS, is applied.
> The Firewall-and-NAT policy to use can be received from RADIUS during authentication.
> Disabling Firewall Policy
> Important: By default, Stateful Firewall processing for subscribers is disabled.
> Stateful Firewall processing is disabled for subscribers in the following cases:

> • | If Stateful Firewall is explicitly disabled in the APN/subscriber template configuration.

> • | If the AAA/OCS sends the SN-Firewall-Policy AVP with the string “disable”, the locally configured firewall policy does not get applied.

> • | If the SN-Firewall-Policy AVP is received with the string “NULL”, the existing policy will continue.

> • | If the SN-Firewall-Policy AVP is received with a name that is not configured locally, the subscriber session is terminated.

> Mid-session Firewall Policy Update
> The Firewall-and-NAT policy can be updated mid-session provided firewall policy was enabled during call setup.
> Important: When the firewall AVP contains “disable” during mid-session firewall policy change, there will be no action taken as the Firewall-and-NAT policy cannot be disabled dynamically. The policy currently applied will continue.
> Important: When a Firewall-and-NAT policy is deleted, for all subscribers using the policy, Firewall processing is disabled, also ECS sessions for the subscribers are dropped. In case of session recovery, the calls are recovered but with Stateful Firewall disabled.
> How it Works
> The following figures illustrate packet flow in Stateful Firewall processing for a subscriber.
> Stateful Firewall Processing
> Continued... Stateful Firewall Processing
> Continued... Stateful Firewall Processing
> Understanding Rules with Stateful Inspection
> This section describes terms used in the Personal Stateful Firewall context.

> • | Access Ruledefs: The Personal Stateful Firewall’s stateful packet inspection feature allows operators to configure rule definitions (ruledefs) that take active session information into consideration to permit or deny incoming or outgoing packets.

> An access ruledef contains the criteria for multiple actions that could be taken on packets matching the rules. These rules specify the protocols, source and destination hosts, source and destination ports, direction of traffic parameters for a subscriber session to allow or reject the traffic flow.
> An access ruledef consists of the following fields:

> • | Ruledef name

> • | Source IP address

> • | Source port number — not required if the protocol is other than TCP or UDP

> • | Destination IP address

> • | Destination port number — not required if the protocol is other than TCP or UDP

> • | Transport protocol (TCP/UDP/ICMP/AH/ESP)

> • | Direction of connection (Uplink/Downlink)

> • | Bearer (IMSI-pool and APN)

> • | Logging action (enable/disable)

> An access ruledef can be added to multiple Firewall-and-NAT policies.
> A combined maximum of 4096 rules (host pools + IMSI pools + port maps + charging ruledefs + firewall/access ruledefs + routing ruledefs) can be created in a system. Access ruledefs are different from ACS ruledefs.

> • | Firewall-and-NAT Policy: Firewall policies can be created for individual subscribers, domains, or all callers within a referenced context. Each policy contains a set of access ruledefs with priorities defined for each rule and the firewall configurations. Firewall-and-NAT policies are configured in the Firewall-and-NAT Policy Configuration Mode.

> • | Service Definition: User-defined firewall service for defining Stateful Firewall policy for initiating an outgoing connection on a primary port and allowing opening of auxiliary ports for that association in the reverse direction.

> • | Maximum Association: The maximum number of Stateful Firewall associations for a subscriber.

> Connection State and State Table in Personal Stateful Firewall
> This section describes the state table and different connection states for transport and network protocols.
> After packet inspection, the Personal Stateful Firewall stores session state and other information into a table. This state table contains entries of all the communication sessions of which the firewall subsystem is aware of. Every entry in this table holds a list of information that identifies the subscriber session it represents. Generally this information includes the source and destination IP address, flags, sequence, acknowledgement numbers, etc.
> When a connection is permitted through the Personal Stateful Firewall enabled chassis, a state entry is created. If a session connection with same information (source address, source port, destination address, destination port, protocol) is requested the firewall subsystem compares the packet’s information to the state table entry to determine the validity of session. If the packet is currently in a table entry, it allows it to pass, otherwise it is dropped.
> Transport and Network Protocols and States
> Transport protocols have their connection’s state tracked in various ways. Many attributes, including IP address and port combination, sequence numbers, and flags are used to track the individual connection. The combination of this information is kept as a hash in the state table.
> TCP Protocol and Connection State
> TCP is considered as a stateful connection-oriented protocol that has well defined session connection states. TCP tracks the state of its connections with flags as defined for TCP protocol. The following table describes different TCP connection states.
> TCP Connection States

> State Flag | Description
> TCP (Establishing Connection)
> CLOSED | A “non-state” that exists before a connection actually begins.
> LISTEN | The state a host is in waiting for a request to start a connection. This is the starting state of a TCP connection.
> SYN-SENT | The time after a host has sent out a SYN packet and is waiting for the proper SYN-ACK reply.
> SYN-RCVD | The state a host is in after receiving a SYN packet and replying with its SYN-ACK reply.
> ESTABLISHED | The state a host is in after its necessary ACK packet has been received. The initiating host goes into this state after receiving a SYN-ACK.
> TCP (Closing Connection)
> FIN-WAIT-1 | The state a connection is in after it has sent an initial FIN packet asking for a graceful termination of the TCP connection.
> CLOSE-WAIT | The state a host’s connection is in after it receives an initial FIN and sends back an ACK to acknowledge the FIN.
> FIN-WAIT-2 | The connection state of the host that has received the ACK response to its initial FIN, as it waits for a final FIN from its connection peer.
> LAST-ACK | The state of the host that just sent the second FIN needed to gracefully close the TCP connection back to the initiating host while it waits for an acknowledgement.
> TIME-WAIT | The state of the initiating host that received the final FIN and has sent an ACK to close the connection and waiting for an acknowledgement of ACK from the connection peer.Note that the amount of time the TIME-STATE is defined to pause is equal to the twice of the Maximum Segment Lifetime (MSL), as defined for the TCP implementation.
> CLOSING | A state that is employed when a connection uses the unexpected simultaneous close.

> ‌
> UDP Protocol and Connection State
> UDP is a connection-less transport protocol. Due to its connection-less nature, tracking of its state is a more complicated process than TCP. The Personal Stateful Firewall tracks a UDP connection in a different manner than TCP. A UDP packet has no sequence number or flag field in it. The port numbers used in UDP packet flow change randomly for any given session connection. So the Personal Stateful Firewall keeps the status of IP addresses.
> UDP traffic cannot correct communication issues on its own and it relies entirely on ICMP as its error handler. This method makes ICMP an important part of a UDP session for tracking its overall state.
> UDP has no set method of connection teardown that announces the session’s end. Because of the lack of a defined ending, the Personal Stateful Firewall clears a UDP session’s state table entries after a preconfigured timeout value reached.
> ICMP Protocol and Connection State
> ICMP is also a connection-less network protocol. The ICMP protocol is often used to return error messages when a host or protocol cannot do so on its own. ICMP response-type messages are precipitated by requests using other protocols like TCP or UDP. This way of messaging and its connection-less and one-way communication make the tracking of its state a much more complicated process than UDP. The Personal Stateful Firewall tracks an ICMP connection based on IP address and request message type information in a state table.
> Like UDP, the ICMP connection lacks a defined session ending process, the Personal Stateful Firewall clears a state table entry on a predetermined timeout.
> Application-Level Traffic and States
> The Personal Stateful Firewall uses Deep Packet Inspection (DPI) functionality to manage application-level traffic and its state. With the help of DPI functionality, the Personal Stateful Firewall inspects packets up to Layer-7. It takes application behaviors into account to verify that all session-related traffic is properly handled and then decides which traffic to allow into the network.
> Different applications follow different rules for communication exchange so the Personal Stateful Firewall manages the different communication sessions with different rules through DPI functionality.
> The Personal Stateful Firewall also provides inspection and filtering functionality on application content with DPI. Personal Stateful Firewall is responsible for performing many simultaneous functions and it detect, allow, or drop packets at the ingress point of the network.
> HTTP Application and State
> HTTP is the one of the main protocols used on the Internet today. It uses TCP as its transport protocol, and its session initialization follows the standard TCP connection method.
> Due to the TCP flow, the HTTP allows an easier definition of the overall session’s state. It uses a single established connection from the client to the server and all its requests are outbound and responses are inbound. The state of the connection matches with the TCP state tracking.
> For content verification and validation on the HTTP application session, the Personal Stateful Firewall uses DPI functionality in the chassis.
> File Transfer Protocol and State
> FTP is an application to move files between systems across the network. This is a two way connection and uses TCP as its transport protocol.
> Due to TCP flow, FTP allows an easier definition of the overall session’s state. As it uses a single established connection from the client to the server, the state of the connection matches with the TCP state tracking.
> Personal Stateful Firewall uses application-port mapping along with FTP application-level content verification and validation with DPI functionality in the chassis. It also supports Pinhole data structure and Initialization, wherein FTP ALG parses FTP Port command to identify the initiation and termination end points of future FTP DATA sessions. The source/destination IP and destination Port of FTP DATA session is stored.
> When a new session is to be created for a call, a check is made to see if the source/destination IP and Destination Port of this new session matches with the values stored. Upon match, a new ACS data session is created.
> This lookup in the pinhole list is made before port trigger check and stateful firewall ruledef match. If the look up returns a valid pinhole then a particular session is allowed. Whenever a new FTP data session is allowed because of a pinhole match the associated pinhole is deleted. Pinholes are also expired if the associated FTP Control session is deleted in, or when the subscriber call goes down.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883