Application Assurance — Security Gateway Stateful Firewall
This chapter provides information about Application Assurance Security gateway stateful firewall.
Topics in this chapter include:
Applicability
This chapter is applicable to all 7750 SR/SR-c and 7450 ESS chassis supporting Application Assurance (AA).
The configuration was tested on Release 13.0.R2.
Overview
The SR OS 13.0.R1 AA stateful firewall feature runs on AA-ISA and extends application-level analysis to provide an in-line stateful service, integrated within the Security Gateway (SeGW). The feature provides protection for mobile infrastructure; Mobility Management Entities (MMEs), Serving Gateways (SGWs), and Network Management Systems (NMSs), against attacks from compromised base stations, evolved NodeBs (eNBs), or Femto Access Points (FAPs). AA stateful packet filtering, combined with AA L7 classification and control, provides advanced, next-generation firewall functionality. Using stateful packet filtering, the AA FW not only inspects packets at layers 3 to 7, but also monitors the connection state.
AA FW deployed within a SeGW in ultra-broadband access networks (3G/4G/Femto) provides back-end core network security protection, as per Figure 1. AA FW offers protection for the following 3rd Generation Partnership Project (3GPP) defined interfaces:
S1-MME
S1-U
Operations, Administration and Maintenance (OAM)
Figure 1. LTE SeGW Firewall Deployment 
Similarly, the SeGW architecture for Femto deployment is based on two 7750 SR systems terminating the mobile backhaul side (front-end and connecting to, for example, a 9365 Base Station Router Gateway (BSR-GW) and other network elements of the packet core (back-end), as per SeGW in Small Cells Architecture:
The two SeGWs run in stateful redundant mode: upon partial or total failure of the active SeGW for a set of IPSec tunnels, the other SeGW takes over without terminating the IPSec tunnels, providing hitless failover.
In addition to MS-ISA hardware dedicated to the IPSec function, each SeGW supports one or more additional MS-ISAs running AA to provide firewall capabilities. The firewall rules protect the BSR as well as the BSR-GW and packet core network elements (NEs) from malicious attacks or unauthorized traffic.
The objective of this chapter is to describe the required configuration within AA-ISA in order to enable AA FW and protection for S1-MME, S1-U, and OAM traffic. Basic knowledge of AA-ISA diversion configuration is assumed.
S1-MME Traffic Protection
The purpose of AA FW in this deployment is to protect the MME infrastructure against an attack from a compromised eNB or FAP. Network flooding attacks, malformed packets, and port scans are examples of denial of service (DoS) attacks that can be carried out using a compromised eNB or FAP.
AA FW provides inspection of the Stream Control Transmission Protocol (SCTP) used to communicate to the MME. Such inspection includes checking for SCTP payload protocol IDs (PPIDs), source /destination ports, SCTP chunk validation, and malformed SCTP packets (such as checksum validation). In addition, the operator can configure DoS flooding rules, such as policers to limit the bandwidth and/or flow counts of SCTP traffic.
S1-U Traffic Protection
The purpose of AA FW in this deployment is to protect the SGW infrastructure against an attack from a compromised eNB or FAP. AA FW supports protection against:
malformed GPRS Tunneling Protocol User plane (GTP-U) packet attacks
Checking packet sanity, which include GTP-U mandatory, optional, and extension header checks, as well as checks for invalid reserved information elements (IE) and missing IEs.
unsupported GTP messages
Filtering messages based on message type and/or message length.
flooding attacks
Shaping GTP traffic bandwidth, which limits the GTP-U bandwidth that a FAP can send to the core (SGW).
Limiting GTP tunnels, which limits the number of concurrent GTP tunnels and/or setup rate of these tunnels from a FAP to the core network.
To prevent the shared resources of bandwidth and the SGW processor from being consumed by an attacker, Nokia recommends the GTP flow rate limiting configuration.
IP fragmentation-based attacks
Applying various drop rules for IP fragmentation of GTP messages.
OAM Traffic Protection
The purpose of AA FW protection in this deployment is to protect against any abuse of OAM network resources, such as NMS.
Network flooding attacks, malformed packets, and port scans are examples of such attacks that can be carried out using a compromised eNB or FAP.
See the configuration described in the Application Assurance — Stateful Firewall chapter for this context of OAM protection in SeGW.
Configuration
AA-ISA Application QoS Policies (AQPs) are enhanced in Release 13.0.R1 with several new AQP actions that provide SCTP and GTP filtering functionality. As with all AQPs, these actions have partition-level scope, which allows different FW policies to be implemented by using AA partition concepts within the same AA-ISA.
The configuration topology in Configuration Topology shows the SeGW FW functionality of S1-U and S1-MME interfaces. Geo-redundancy, which is a very common deployment option, is not described in this here because it is described in the Multi-Chassis IPSec Redundancy chapter.
Pre-Setup Requirements
Configure tunnel ISAs with optional multi-chassis redundancy. See the Multi-Chassis IPSec Redundancy chapter for more information.
Divert AA traffic and apply basic firewall rules.
Step 1.1. Divert private VPRN traffic into AA-ISA with AA multi-chassis redundancy.
This step is required for any of the configurations in Steps 2, 3 or 4.
There is no dependency between Steps 2, 3 or 4.
In this example, one private VPRN is used for all traffic to/from eNBs. In some small cell deployments, eNB traffic is split into three different VPRNs: one for control (S1-MME), one for management (OAM), and one for bearer traffic (S1-U GTP-U). In that case, each of these VPRNs needs to be diverted into AA-ISA in order to provide firewall protection.
First, define an application profile and transit IP policy, such as:
*A:7750-1>config>app-assure>group$ info ---------------------------------------------- policy begin app-profile "default" create description " App profile that applies to the whole SAP" divert exit commit exit transit-ip-policy 1 create description "Per eNB-IP Sub policy" detect-seen-ip transit-auto-create no shutdown exitThen, apply these policies to the SAP on the private side of the IPSec tunnel ISA:
*A:7750-1>config>service>vprn>if# info ---------------------------------------------- sap tunnel-1.private:1 create transit-policy ip 1 app-profile "default" exitThis configuration achieves:
Traffic to/from the IPSec tunnel ISA private SAP is diverted to AA-ISA for the purpose of FW protection
Within AA-ISA, the diverted SAP is treated as a parent SAP. That is, instead of treating the whole SAP as a single subscriber, subscribers are auto-created within this SAP based on the IP address of the eNBs
Step 1.2. Protect against malformed packets.
In firewall deployments, it is recommended that overload-drop, error-drop, and fragment-drop (all) are enabled within the default sub-policy, as shown in the example below:
overload-drop ensures that AA-ISA, when overloaded, drops the excess traffic instead of allowing it through, without applying firewall rules.
error-drop ensures that AA-ISA drops malformed IP packets.
fragment-drop (all) because many network DoS attacks use IP fragmentation to initiate attacks, the operator has the option to drop all fragmented traffic, drop out-of-order fragments only, or allow fragments through. Allowing fragments through is not recommended for firewall deployments.
*A:7750-1>config>app-assure>group>policy# app-qos-policy *A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- entry 500 create description "apply SeGW session filter rules" match traffic-direction subscriber-to-network exit action overload-drop error-drop fragment-drop all exit no shutdown exit exit ---------------------------------------------- *A:7750-1>config>app-assure>group>policy#
Step 1.3. Limit total traffic from any eNB.
It is recommended that a total limit be placed on how much bandwidth and how many flows an eNB or FAP can generate toward the network, regardless of the type of traffic.
The limit values are a function of the number of end devices that are served by the eNB or FAP, plus some additional margin:
*A:7750-1>config>app-assure>group# info ---------------------------------------------- policer "limit_eNBs_total_Flows" type flow-count-limit granularity subscriber create flow-count 1000 exit policer "limit_eNBs_total_bw" type single-bucket-bandwidth granularity sub scriber create rate 500 mbs 500 exit ---------------------------------------------- *A:7750-1>config>app-assure>group#Note:If the traffic from eNB or FAP is separated into different private SAPs, based on traffic type (S1-AP, S1-U, or OAM), as with some deployment topologies, then the policing limit value is dependent on the SAP traffic type as well as the number of end devices. See policing limit settings in Steps 2 and 3.
Apply the configured policers as actions from within the default sub-policy AQP entry:
*A:7750-1>config>app-assure>group>policy# app-qos-policy entry 500 *A:7750-1>config>app-assure>group>policy>aqp>entry>action# flow-count-limit "limit_eNBs_total_Flows" *A:7750-1>config>app-assure>group>policy>aqp>entry>action# bandwidth-policer "limit_eNBs_total_bw" *A:7750-1>config>app-assure>group>policy>aqp>entry# info ---------------------------------------------- description "apply SeGW session filter rules" match traffic-direction subscriber-to-network exit action bandwidth-policer "limit_eNBs_total_bw" flow-count-limit "limit_eNBs_total_Flows" session-filter "SeGW_FW" overload-drop error-drop fragment-drop all exit no shutdown ---------------------------------------------- *A:7750-1>config>app-assure>group>policy>aqp>entry#Note:All of the above listed actions use the traffic direction of subscriber-to-network. That is, they are not applied to traffic in the other direction (downstream) because the purpose of the firewall is to protect the network resources from upstream traffic coming from compromised eNBs or FAPs.
Configure AA-ISA to provide firewall protection to protect MMEs (S1-AP traffic).
Step 2.1. Create IP AA lists.
First, create an AA IP prefix list that contains eNB IP addresses or range of addresses:
*A:7750-1>config>app-assure# group 1:1 *A:7750-1>config>app-assure>group# ip-prefix-list "ALL_eNBs" create *A:7750-1>config>app-assure>group>pfx>$ description "eNodeB subnet" *A:7750-1>config>app-assure>group>pfx>$ prefix 172.16.100.0/24 *A:7750-1>config>app-assure>group>pfx>$ exitNext, optionally create an AA IP list that contains MME IP addresses (in case there are more than one):
*A:7750-1>config>app-assure>group# ip-prefix-list "MMEs" create *A:7750-1>config>app-assure>group>pfx>$ description "MME(s) subnet" *A:7750-1>config>app-assure>group>pfx>$ prefix 172.16.110.100/30 *A:7750-1>config>app-assure>group>pfx>$ exitAfter the above lists are created, they can be referenced and used in AA FW rules using session filters and AQPs.
Step 2.2. Allow only SCTP traffic towards MMEs — No port scanning.
A basic setup creates session-filter rules that will only allow SCTP traffic between eNBs and MMEs.
*A:7750-1>config>app-assure>group# session-filter "SeGW_FW" create *A:7750-1>config>app-assure>group>sess-fltr$ default-action deny *A:7750-1>config>app-assure>group>sess-fltr$ entry 1 create *A:7750-1>config>app-assure>group>sess-fltr>entry$ description "allow SCTP to MM Es" *A:7750-1>config>app-assure>group>sess-fltr>entry$ match *A:7750-1>config>app-assure>group>sess-fltr>entry>match$ ip-protocol-num "sctp" *A:7750-1>config>app-assure>group>sess-fltr>entry>match$ src-ip ip-prefix-list "ALL_eNBs" *A:7750-1>config>app-assure>group>sess-fltr>entry>match$ dst-ip ip-prefix-list "MMEs" *A:7750-1>config>app-assure>group>sess-fltr>entry>match$ dst-port eq 6005 *A:7750-1>config>app-assure>group>sess-fltr>entry>match$ exit *A:7750-1>config>app-assure>group>sess-fltr>entry$ action permit *A:7750-1>config>app-assure>group>sess-fltr>entry$ exitNote:In the above configuration, SCTP traffic on MMEs is assumed to be running on port 6005.
Next, the newly created session filter needs to be referenced from a default sub-policy AQP action, as follows:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- entry 500 create description "apply SeGW session filter rules" match traffic-direction subscriber-to-network exit action session-filter "SeGW_FW" overload-drop error-drop fragment-drop all exit no shutdown exit exit ---------------------------------------------- *A:7750-1>config>app-assure>group>policy#Using traffic direction subscriber-to-network in the above AQP entry achieves two objectives:
Protects MMEs by allowing only SCTP traffic to be initiated from eNB subnets toward MMEs. Port scanning toward MME is blocked.
Allows MMEs to have full access to eNBs.
Note:It is important that an AQP, containing a session-filter action, does not contain any matching condition other than ASOs, traffic direction, or subscriber ID. Subscriber ID is not applicable in this deployment use-case.
Step 2.3. DoS protection: Limit the number of SCTP flows from eNBs.
In this step, the operator configures a flow count policer to limit the number of SCTP flows that an eNB can generate toward the MMEs. This protects the MMEs against a compromised eNB trying to set up many SCTP flows.
*A:7750-1# configure application-assurance group 1 *A:7750-1>config>app-assure>group# policer "sctp_flow_count" type flow-count-limit granularity subscriber create *A:7750-1>config>app-assure>group>policer$ flow-count 2 *A:7750-1>config>app-assure>group>policer$ exitIn the above configuration, an eNB or FAP can have up to two flows at a time. In practice, there should only be one SCTP session, one flow in each direction, per eNB-MME pair. The above example uses two flows to leave a margin in case a second, backup, MME needs to communicate with the eNB, while still providing enough protection.
Add the defined policer as a flow-count-limit as an AQP action, as follows:
A:7750-1>config>app-assure>group>policy>aqp# entry 100 A:7750-1>config>app-assure>group>policy>aqp>entry$ info ---------------------------------------------- description "limit SCTP traffic" match traffic-direction subscriber-to-network ip-protocol-num eq sctp exit action flow-count-limit "sctp_flow_count" exit no shutdown ---------------------------------------------- A:7750-1>config>app-assure>group>policy>aqp>entry$Step 2.3.1. Configure an AA FW events log.
It is sometimes advisable to configure a log that captures events related to various AA FW actions. Due to the limited size of the log and the large amount of traffic AA can handle, consider the usefulness of the information in the log when:
debugging a configuration
testing a configuration in a staged environment
capturing infrequent actions
To configure a log:
*A:7750-1# configure application-assurance group 1:1 *A:7750-1>config>app-assure>group# event-log "FW_drops_log" create *A:7750-1>config>app-assure>group>evt-log$ buffer-type circular *A:7750-1>config>app-assure>group>evt-log$ max-entries 100000 *A:7750-1>config>app-assure>group>evt-log$ no shutdown *A:7750-1>config>app-assure>group>evt-log$ exit *A:7750-1>config>app-assure>group# info ---------------------------------------------- ---snip--- event-log "FW_drops_log" create buffer-type circular max-entries 100000 no shutdown exitTo reference the configured log from within the deny action of the session filter:
*A:7750-1>config>app-assure>group>sess-fltr# info ---------------------------------------------- default-action deny event-log "FW_drops_log" entry 1 create description "allow SCTP to MMEs" match ip-protocol-num sctp src-ip ip-prefix-list "ALL_eNBs" dst-ip ip-prefix-list "MMEs" exit action permit exit ---------------------------------------------- *A:7750-1>config>app-assure>group>sess-fltr#To view the log:
*A:7750-1# tools dump application-assurance group 1:1 event-log "FW_drops_log" isa 1/2 ===================================================== Application-Assurance event-log "FW_drops_log" Current Time: "06/10/2015 22:45:30" (UTC) group[:partition]: 1:1 isa: 1/2 admin state: no shutdown buffer-type: circular max-entries: 100000 ===================================================== Event-source Action SubType SubName Direction Src-ip Dst-ip Ip-protocol Src-port Dst-port Timestamp Total Records: 0 ===================================================== *A:7750-1#To clear all the entries within the specified log:
*A:7750-1# clear application-assurance group 1:1 event-log "FW_drops_log"Step 2.4. DoS protection: Limit the SCTP bandwidth from eNB
Similar to the previous step, the operator configures a flow bandwidth policer to limit the amount of SCTP traffic that an eNB can generate toward the MMEs. This protects the MMEs against a compromised eNB trying to flood the MMEs.
*A:7750-1# configure application-assurance group 1 *A:7750-1>config>app-assure>group# info ---------------------------------------------- ---snip--- policer "sctp_bw_limit" type single-bucket-bandwidth granularity subscriber create rate 30 mbs 10 exit ---snip--- exit ---------------------------------------------- *A:7750-1>config>app-assure>group#In the above example, a single leaky-bucket policer is configured with a rate set to 30 kb/s and maximum burst size of 10 kbytes. This provides enough bandwidth to ensure normal operations, while still providing a ceiling limit of how much traffic any eNB can send toward the MMEs.
The value for this policer is a function of the amount of user equipment (UEs) served by the eNB/FAP. For example, in a small cell deployment, with 32 active users per 9962 FAP, the S1-MME bandwidth is estimated to be:
Uplink — toward MME : 2.7 kb/s
Downlink — from MME toward FAP : 28 kb/s
Add the defined policer as a subscriber policy, as follows:
A:7750-1>config>app-assure>group>policy>aqp# entry 100 A:7750-1>config>app-assure>group>policy>aqp>entry$ info ---------------------------------------------- description "limit SCTP traffic" match traffic-direction subscriber-to-network ip-protocol-num eq sctp exit action bandwidth-policer "sctp_bw_limit" flow-count-limit "sctp_flow_count" exit no shutdown ---------------------------------------------- A:7750-1>config>app-assure>group>policy>aqp>entry$Step 2.4.1 Configure additional limits for all traffic to MMEs.
To further protect the MMEs from a distributed attack, whereby a number of eNBs or FAPs are compromised, an AA FW can be configured to limit total traffic, not just from a single eNB as outlined in previous sections, but from all eNBs toward the MMEs.
It is recommended to configure the following three protection limits:
total bandwidth of SCTP toward MMEs
total number of flows toward MMEs
flow setup rate toward the MMEs
The configuration is shown below:
*A:7750-1>config>app-assure>group# info ---------------------------------------------- policer "limit_total_sctp_bw" type single-bucket-bandwidth granularity system create rate 1200 mbs 100 exit policer "limit_total_sctp_flows" type flow-count-limit granularity system create flow-count 400 exit policer "limit_total_sctp_flows_rate" type flow-rate-limit granularity system create rate 100 mbs 100 exit ---------------------------------------------- *A:7750-1>config>app-assure>group#Note:The policers are of type system and not subscriber in order to be applied to all eNBs or FAPs, as is the case when auto-transit subscribers are created (see Step 1).
The actual limits of these policers are a function of the total number of eNBs served by the SeGW. In the above configuration, it is assumed that there are 400 eNBs. Therefore, the total limit is 400 flows of SCTP traffic.
A flow setup rate limit of 100 is set to protect MMEs from a storm of new SCTP flows.
The policers are then referenced from within the appropriate AQP entry that matches the MMEs traffic and SCTP:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- ---snip--- entry 110 create description " limit system traffic towards MMEs" match traffic-direction subscriber-to-network src-ip eq ip-prefix-list "ALL_eNBs" dst-ip eq ip-prefix-list "MMEs" exit action bandwidth-policer "limit_total_sctp_bw" flow-rate-limit "limit_total_sctp_flows_rate" flow-count-limit "limit_total_sctp_flows" exit no shutdown exit *A:7750-1>config>app-assure>group>policy>aqp#Note:It is possible, but redundant, to add the ip-protocol eq sctp command as a match condition, because the configured session filter already ensures that only SCTP traffic can flow between eNBs and MMEs.
Step 2.5. Allow only specified SCTP PPIDs toward the MMEs.
In this step, the operator blocks all except the specified SCTP messages that contain configured PPIDs, using an AA SCTP filter configuration:
*A:7750-1>config>app-assure>group# sctp-filter - no sctp-filter <sctp-filter-name> - sctp-filter <sctp-filter-name> [create] <sctp-filter-name> : [32 chars max] <create> : keyword [no] description - Configure a description of the SCTP filter [no] event-log - Configure an event log for packets dropped by the SCTP filter ppid + Configure actions for specific or default PPIDs (Payload Protocol Identifiers) [no] ppid-range - Configure the range of allowable PPIDs for the SCTP filterThe filter specifies either a range of PPIDs or individual PPIDs:
*A:7750-1>config>app-assure>group>sctp-fltr>ppid$ entry 1 - entry <entry-id> value <ppid-value> action {permit|deny} - no entry <entry-id> <entry-id> : [1..255] <ppid-value> : [0..4294967295]D | [256 chars max] <permit|deny> : permit|denyThe PPIDs can be specified either by their values or by names. Names are specified in RFC 4960. See SCTP PPIDs .
Table 1. SCTP PPIDs Value
SCTP PPID
Value
SCTP PPID
0
Reserved by SCTP
31
Service Area Broadcast Protocol (SABP)
1
IUA
32
Fractal Generator Protocol (FGP)
2
M2UA
33
Ping Pong Protocol (PPP)
3
M3UA
34
CalcApp Protocol (CALCAPP)
4
SUA
35
Scripting Service Protocol (SSP)
5
M2PA
36
NetPerfMeter Protocol Control Channel (NPMP-CONTROL)
6
V5UA
37
NetPerfMeter Protocol Data Channel (NPMP-DATA)
7
H.248
38
Echo (ECHO)
8
BICC/Q.2150.3
39
Discard (DISCARD)
9
TALI
40
Daytime (DAYTIME)
10
DUA
41
Character Generator (CHARGEN)
11
ASAP
42
3GPP RNA
12
ENRP
43
3GPP M2AP
13
H.323
44
3GPP M3AP
14
Q.IPC/Q.2150.3
45
SSH over SCTP
15
SIMCO <draft-kiesel-midcom-simco-sctp-00.txt>
46
Diameter in a SCTP DATA chunk
16
DDP Segment Chunk
47
Diameter in a DTLS/SCTP DATA chunk
17
DDP Stream Session Control
48
R14P. BER Encoded ASN.1 over SCTP
18
S1 Application Protocol (S1AP)
49
Unassigned
19
RUA
50
WebRTC DCEP
20
HNBAP
51
WebRTC String
21
ForCES-HP
52
WebRTC Binary Partial (deprecated)
22
ForCES-MP
53
WebRTC Binary
23
ForCES-LP
54
WebRTC String Partial (deprecated)
24
SBc-AP
55
3GPP PUA
25
NBAP
56
WebRTC String Empty
26
Unassigned
57
WebRTC Binary Empty
27
X2AP
58-4294967295
Unassigned
28
IRCP - Inter Router Capability Protocol
29
LCS-AP
30
MPICH2
It is recommended to limit the SCTP traffic to only those packets with S1 AP PPID. The SCTP filter can be configured to deny all by default and only allow PPID S1 AP (by value = 18 or by name: s1-application-protocol) as follows:
*A:7750-1# configure application-assurance group 1:1 sctp-filter "SCTP-PPID-Filter" create description "Allow only S1AP PPID" event-log "FW_drops_log" ppid default-action deny entry 1 value "s1-application-protocol" action permit exitThis configured SCTP filter is then referenced as an action from within an AQP entry:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- entry 100 create description "limit SCTP traffic" match traffic-direction subscriber-to-network ip-protocol-num eq sctp exit action bandwidth-policer "sctp_bw_limit" flow-count-limit "sctp_flow_count" sctp-filter "SCTP-PPID-Filter" exit no shutdown exit ---------------------------------------------- A:7750-1>config>app-assure>group>policy>aqp#To view the packets allowed or denied by the configured SCTP filter:
*A:7750-1# show application-assurance group 1:1 sctp-filter "SCTP-PPID-Filter" =============================================================================== Application Assurance Group 1:1 SCTP Filter "SCTP-PPID-Filter" =============================================================================== Description : Allow only S1AP PPID Maximum PPID : 4294967295 Minimum PPID : 0 Default action : deny Configured PPIDs : 1 Packets arrived : 0 Packets denied Malformed packet : 0 PPID out of range : 0 PPID denied : 0 Packets permitted : 0 =============================================================================== *A:7750-1#Note:The SCTP malformed packet counter shown above increments when an AA SCTP filter encounters an SCTP packet that is malformed, such as:
IP packet is too small to contain a common SCTP header
SCTP chunk LEN < 4 bytes: each SCTP chunk header is 4 bytes, so the SCTP chunk cannot be smaller than this
remaining space in the IP packet is too small to contain a chunk header (for example, your packet has 2 chunks and the 2nd chunk length goes beyond the IP length advertised)
IP packet is too small to contain the chunk
Currently, the SCTP filter statistics cannot be reset on the fly without shutting down the SCTP filter.
Another way to view the effect of the configured SCTP filter is to check the firewall log, if configured:
*A:7750-1# tools dump application-assurance group 1:1 event-log "FW_drops_log" isa 1/2ConfigureAA-ISA to protect SGW (GTP-U traffic).
The steps to configure the AA-ISA in an SeGW to protect against attacks toward the SGW are similar to the steps for SCTP traffic. While GTP filtering is very different from SCTP filtering, configuration to limit the flow counts, bandwidth, and session filter are similar.
Step 3.1. Create an AA IP list for SGWs.
In addition to the lists configured in step 2.1, the operator can optionally configure a list that contains the SGW IP addresses that are served by the SeGW, in case there is more than one.
*A:7750-1# configure application-assurance group 1:1 ip-prefix-list "SGWs" create *A:7750-1>config>app-assure>group>pfx>$ description "Serving Gateways IPs" *A:7750-1>config>app-assure>group>pfx>$ prefix 172.16.111.1/32 *A:7750-1>config>app-assure>group>pfx>$ prefix 172.16.111.2/32 *A:7750-1>config>app-assure>group>pfx>$ exitStep 3.2. Allow only GTP-U traffic toward SGWs — No port scanning.
Similar to Step 2.2, create an GTP filter to allow only GTP traffic to/from eNBs to SGWs:
*A:7750-1>config>app-assure>group>sess-fltr# info ---------------------------------------------- default-action deny event-log "FW_drops_log" ---snip--- entry 2 create description "allow GTP-u to SGWs" match ip-protocol-num udp src-ip ip-prefix-list "ALL_eNBs" dst-ip ip-prefix-list "SGWs" dst-port eq 2152 exit action permit exit ---------------------------------------------- *A:7750-1>config>app-assure>group>sess-fltr#The following session filter needs to be added to the default sub-policy AQP, similar to Step 2.2:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- entry 500 create description "apply SeGW session filter rules" match traffic-direction subscriber-to-network exit action session-filter "SeGW_FW" overload-drop error-drop fragment-drop all exit no shutdown exit exit ----------------------------------------------For AA to recognize GTP traffic and perform sanity packet checking, configure a GTP filter at the group:partition level:
*A:7750-1# configure application-assurance group 1:1 gtp no shutdownStep 3.3. DoS protection — Limit the number of GTP-U flows from eNBs.
AA can be configured to limit the number of GTP flows from an eNB. A GTP-U flow is defined by GTP-U packet destination IP + tunnel ID (TEID).
AA allows the operator to configure two limits: one that applies to the each eNB and one that applies for all GTP-U traffic from all eNBs:
*A:7750-1>config>app-assure>group# info ---------------------------------------------- policer "GTPu-Flow-count-limit" type flow-count-limit granularity subscriber create flow-count 800 gtp-traffic exitThe actual value of the flow count limit is a function of the number of UEs or devices served by an eNB or FAP. In the above case, it is assumed that there are 100 devices with a maximum of 8 GTP-U flows per device. For FAP, the number is typically around 32 devices per FAP. Note: By 3GPP standards, the maximum number of GTP-U tunnels per device is 16.
Assuming that there are 1000 eNBs or FAPs that are served by the SeGW, then to limit the total number of GTP-U flows, the operator can apply the following system policer:
*A:7750-1>config>app-assure>group# info ---------------------------------------------- policer "limit_total_GTPU_Flow_count" type flow-count-limit granularity system create flow-count 800000 gtp-traffic exitConfigure AQPs to execute the policers:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- ---snip--- entry 120 create description "limit GTP-U traffic" match traffic-direction subscriber-to-network exit action flow-count-limit "GTPu-Flow-count-limit" exit no shutdown exit entry 130 create description "limit TOTAL GTPU towards SGWs" match traffic-direction subscriber-to-network exit action flow-count-limit "limit_total_GTPU_Flow_count" exit no shutdown exitFor GTP-U flow count policing, it is important that aqp-initial-lockup is enabled:
*A:7750-1# configure application-assurance group 1:1 aqp-initial-lookupThe above configured limits are applied only to upstream traffic, to protect the network. No limit is placed on the downstream traffic toward the eNBs.
Note:For small cell deployments, the number of GTP-U tunnels per FAP is a function of:
deployment mode:
residential = 32 (9962 MSEC-MS-MCI Enterprise) UEs
enterprise = 8 (9961 MSHC) UEs.
number of guaranteed bit rate (GBR) tunnels (max 8) and non-GBR tunnels (max 8) per UE.
Therefore, the GTP-U tunnel limit per FAP should be set to 32 x 8 = 256 for residential deployments or 8 x 8 = 64 for enterprise deployments.
The operator can view the effect of the configured policers on GTP traffic by running the following show routine:
*A:7750-1>show>app-assure>group# gtp =============================================================================== Application Assurance Group 1:1 GTP =============================================================================== Admin status : Up Event log : (Not Specified) ------------------------------------------------------------------------------- GTP Statistics sub-to-net net-to-sub ------------------------------------------------------------------------------- Incoming packets 0 0 Packets denied UDP packet length 0 0 GTP message length 0 0 GTP version 0 0 ------------------------------------------------------------------------------- Packets permitted 0 0 ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- GTP Policing Statistics sub-to-net net-to-sub ------------------------------------------------------------------------------- Packets arrived 0 0 Packets denied gtp-traffic flow-count policer 0 0 Other 0 0 ------------------------------------------------------------------------------- Packets permitted 0 0 ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- GTP Filter Statistics sub-to-net net-to-sub ------------------------------------------------------------------------------- Packets arrived 0 0 Packets denied (gtp-filter) 0 0 Packets permitted gtp-filter 0 0 no gtp-filter 0 0 ------------------------------------------------------------------------------- Total GTP packets permitted 0 0 =============================================================================== *A:7750-1>show>app-assure>group#In the last section shown above, GTP filter statistics are related to GTP filters that are discussed and configured later in Step 3.5 of this chapter.
Step 3.4. DoS protection: Limit the GTP-U bandwidth from eNBs.
This step is similar to Step 3.3, but instead of configuring a flow count policer, the operator configures bandwidth policers:
*A:7750-1>config>app-assure>group# info ---------------------------------------------- policer "GTPU_bw_limit" type single-bucket-bandwidth granularity subscriber create rate 5000 mbs 100 exit policer "limit_total_GTPU_bw" type single-bucket-bandwidth granularity system create rate 2000000 mbs 2000 exit *A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- ---snip--- entry 120 create description "limit GTP-U traffic" match traffic-direction subscriber-to-network exit action bandwidth-policer "GTPU_bw_limit" flow-count-limit "GTPu-Flow-count-limit" exit no shutdown exit entry 130 create description "limit TOTAL GTPU towards SGWs" match traffic-direction subscriber-to-network exit action bandwidth-policer "limit_total_GTPU_bw" flow-count-limit "limit_total_GTPU_Flow_count" exit no shutdown exitThe above configured limits are applied only to upstream traffic, to protect the network. No limit is placed on downstream traffic toward the eNB.
As a debugging tool, the operator can use the AA flow-record-search command to check the status of GTP flows through the ISA:
*A:7750-1# tools dump application-assurance group 1:1 flow-record-search isa 1/2 flow-status active protocol "gtp" ===================================================== Application-Assurance flow record search, Version 1.0 Search Start Time: "06/16/2015 20:38:09" (UTC) Search Criteria: group[:partition]: 1:1 isa: 1/2 protocol name: "gtp" application name: none specified app-group name: none specified flow-status: active start-flowId: none specified classified: none specified server-ip: none specified server-port: none specified client-ip: none specified bytes-tx: none specified flow-duration: none specified max-count: none specified search-type: default ===================================================== FlowId Init Src-ip Dst-ip Ip-prot Src-prt Dst-prt Protocol Application Pkts-tx Bytes-tx Pkts-disc Bytes-disc Time-ofp(UTC) Time-olp(UTC) SEARCH COMPLETED. Search End Time: "06/16/2015 20:38:09" (UTC) Total Records: 0 ===================================================== *A:7750-1#GTP flows that are to be denied by the previous AA configurations should not appear in the search results.
Step 3.5. Further GTP filtering and validation.
AA allows the operator to configure a GTP filter to enforce which GTP message types are allowed/denied, as well as the maximum allowed GTP message length:
*A:7750-1>config>app-assure>group>gtp>gtp-fltr# [no] description - Configure a description of the GTP filter [no] event-log - Configure an event log for packets dropped by the GTP filter [no] max-payload-le* - Configure the maximum payload length of the GTP filter message-type + Configure actions for specific or default messages *A:7750-1>config>app-assure>group>gtp>gtp-fltr#Note:An AA GTP filter allows the operator to configure a maximum payload size for the GTP traffic. However, in this configuration example, no maximum payload size is configured.
The list of GTP message types are defined by 3GPP standard 3GPP TS 29.281 as per GTP Messages .
Table 2. GTP Messages Message Type Value (Decimal)
Message
Message Type Value (Decimal)
Message
1
‟echo-request”
55
‟”forward-relocation-complete
2
‟echo-response”
56
‟relocation-cancel-request”
3
‟versi”n-not-supported:
57
‟relocation-cancel-response”
4
‟node-alive-request”
58
‟forward-sms-context”
5
‟ node-alive-response”
59
‟forward-relocation-complete-acknowledge”
6
‟redirection-request”
60
‟forward-sms-context-acknowledge”
7
‟redirection-response”
70
‟ran-information-relay”
16
‟create-pdp-context-request”
96
‟mbms-notification-request”
17
‟create-pdp-context-response”
97
‟mbms-notification-response”
18
‟update-pdp-context-request”
98
‟mbms-notification-reject-request”
19
‟update-pdp-context-response”
99
‟mbms-notification-reject-response”
20
‟delete-pdp-context-request”
100
‟create-mbms-context-request”
21
‟delete-pdp-context-response”
101
‟create-mbms-context-response”
22
‟initiate-pdp-context-activation-request”
102
‟update-mbms-context-request”
23
‟initiate-pdp-context-activation-response”
103
‟update-mbms-context-response”
26
‟error-indication”
104
‟delete-mbms-context-request”
27
‟pdu-notification-request”
105
‟delete-mbms-context-response”
28
‟pdu-notification-response”
112
‟mbms-registration-request”
29
‟pdu-notification-reject-request”
113
‟mbms-registration-response”
30
‟pdu-notification-reject-response”
114
‟mbms-de-registration-request”
31
‟supported-extension-headers-notification”
115
‟mbms-de-registration-response”
32
‟send-routing-information-for-gprs-request”
116
‟mbms-session-start-request”
33
‟send-routing-information-for-gprs-response”
117
‟mbms-session-start-response”
34
‟Failure-report-request”
118
‟mbms-session-stop-request”
35
‟failure-report-request”
119
‟mbms-session-stop-response”
36
‟note-ms-gprs-present-request”
120
‟mbms-session-update-request”
37
‟note-ms-gprs-present-response”
121
‟mbms-session-update-response”
48
‟identification-request”
128
‟ms-info-change-notification-request”
49
‟identification-response”
129
‟ms-info-change-notification-response”
50
‟sgsn-context-response”
240
‟data-record-transfer-request”
51
‟sgsn-context-request”
241
‟data-record-transfer-response”
52
‟sgsn-context-acknowledge”
254
‟end-marker”
53
‟forward-relocation-request”
255
‟g-pdu”
54
‟forward-relocation-response”
Of the 67 GTP message types shown above, only 6 are allowed, by the standards, for GTP-U:
echo-request echo-response error-indication g-pdu end-marker supported-extension-headers-notificationIf these message types are permitted by the configured GTP filter, AA performs extensive GTP-U header checking on these six types.
Note:If no GTP filter is configured, no extensive GTP-U header checks are performed. For example, if the operator wants to allow all GTP-U packets and perform all GTP header sanity checks, then a GTP filter that permits all message types needs to be configured, with the default action of permit and with no values, such as:
gtp-filter ‟allow-all” create message-type default-action permitBecause AA FW in an SeGW is protecting an S1-U interface running GTP-U, the GTP filter only needs to allow the six GTP messages that are permitted for GTP-U:
*A:7750-1>config>app-assure>group>gtp# info ---------------------------------------------- gtp-filter "filter-gtp-msgs" create description "allow only certain msg types" message-type default-action deny entry 1 value "echo-request" action permit entry 2 value "echo-response" action permit entry 3 value "error-indication" action permit entry 4 value "supported-extension-headers-notification" action permit entry 5 value "end-marker" action permit entry 6 value "g-pdu" action permit exit exit no shutdown ---------------------------------------------- *A:7750-1>config>app-assure>group>gtp#This GTP filter is then referenced from within an AQP entry action, as follows, in order for it to take effect:
*A:7750-1>config>app-assure>group>policy>aqp# info ---------------------------------------------- entry 120 create description "limit GTP-U traffic" match traffic-direction subscriber-to-network dst-ip eq ip-prefix-list "SGWs" exit action bandwidth-policer "GTPU_bw_limit" flow-count-limit "GTPu-Flow-count-limit" gtp-filter "filter-gtp-msgs" exit no shutdown exitThe operator can view the effect of the configured GTP filter on S1-U traffic using the following show routine:
*A:7750-1>show>app-assure>group# gtp gtp-filter "filter-gtp-msgs" =============================================================================== Application Assurance Group 1:1 GTP Filter "filter-gtp-msgs" =============================================================================== Description : allow only certain msg types Maximum payload length : (Not Specified) Default action : deny Configured messages : 6 Packets arrived : 0 Packets denied Payload length : 0 Message type : 0 Mandatory header : 0 Extension header : 0 Information element : 0 Packets permitted : 0 =============================================================================== *A:7750-1>show>app-assure>group#The above output is in addition to the information provided by the overall GTP show command:
*A:7750-1>show>app-assure>group# gtpConfigure AA-ISA to protect NMS (OAM Traffic).
Step 4.1. Create an IP AA list that contains the NMS server IPs.
*A:7750-1# configure application-assurance group 1:1 *A:7750-1>config>app-assure>group# info ---------------------------------------------- ip-prefix-list "NMSs" create description "Network Management-OAM subnet" prefix 172.16.120.0/30 exitNote:In the case of small cell deployments, different NMS servers need to be configured.
Step 4.2. Allow eNBs to initiate FTP- and ICMP-only traffic toward NMS, block port scanning.
*A:7750-1>config>app-assure>group>sess-fltr# info ---------------------------------------------- default-action deny event-log "FW_drops_log" entry 3 create description "allow FTP to NMS" match ip-protocol-num tcp src-ip ip-prefix-list "ALL_eNBs" dst-ip ip-prefix-list "NMSs" dst-port eq 22 exit action permit exit entry 4 create description "allow ICMP to NMS" match ip-protocol-num icmp src-ip ip-prefix-list "ALL_eNBs" dst-ip ip-prefix-list "NMSs" exit action permit exit ---------------------------------------------- *A:7750-1>config>app-assure>group>sess-fltr#The operator can view the effect of the session filter on traffic, in terms of how many times it is applied, using the following show routine:
*A:7750-1>show>app-assure>group# session-filter =============================================================================== AA Session Filter Table =============================================================================== Name Default Action Referenced Entries ------------------------------------------------------------------------------- SeGW_FW deny aqp 4 ------------------------------------------------------------------------------- No. of session filters: 1 =============================================================================== *A:7750-1>show>app-assure>group# *A:7750-1>show>app-assure>group# session-filter "SeGW_FW" =============================================================================== AA Session Filter Instance "SeGW_FW" =============================================================================== Description : (Not Specified) Default Action : deny Event Log : FW_drops_log AQP Entries : 500 ------------------------------------------------------------------------------- Filter Match Criteria ------------------------------------------------------------------------------- Entry : 1 Description : allow SCTP to MMEs IP Protocol : sctp Source IP List : ALL_eNBs Dest IP List : MMEs Action : permit Event Log : (Not Specified) Hits : 0 flows ------------------------------------------------------------------------------- Entry : 2 Description : allow GTP-u to SGWs IP Protocol : udp Source IP List : ALL_eNBs Dest IP List : SGWs Dest Port : eq 2152 Action : permit Event Log : (Not Specified) Hits : 0 flows ------------------------------------------------------------------------------- Entry : 3 Description : allow FTP to NMS IP Protocol : tcp Source IP List : ALL_eNBs Dest IP List : NMSs Dest Port : eq 22 Action : permit Event Log : (Not Specified) Hits : 0 flows ------------------------------------------------------------------------------- Entry : 4 Description : allow ICMP to NMS IP Protocol : icmp Source IP List : ALL_eNBs Dest IP List : NMSs Action : permit Event Log : (Not Specified) Hits : 0 flows ------------------------------------------------------------------------------- No. of entries : 4 =============================================================================== *A:7750-1>show>app-assure>group#
The above configuration is generic and may need to be modified to suit the deployment requirements. For example, in the case of small cell SeGW deployment, traffic on other ports needs to be allowed to/from different NMS type servers, such as allowing TCP port 7003 and port 7013 to HDM servers. This can be accomplished by configuring additional entries in the above session filter.
By allowing port 22 for FTP, the AA FW automatically opens and closes the associated data channel ports. For more information about AA FW capabilities, with regard to OAM FW protection, see Application Assurance Stateful Firewall.
Conclusion
The SR OS AA stateful firewall feature runs on AA-ISA and extends application-level analysis to provide an in-line stateful service, integrated within the Security Gateway (SeGW).
AA stateful packet filtering, combined with AA Layer 7 classification and control, provides advanced, next-generation firewall functionality, protecting mobile network core infrastructure, such as MMEs, SGWs, and NMSs.