Application Assurance — Stateful Firewall
This chapter describes Application Assurance stateful firewall (FW) configurations for protecting residential and WiFi subscribers.
Topics in this chapter include:
Applicability
Initially, this chapter was written for SR OS Release 11.0.R1. The TCP validation section was added for SR OS Release 14.0.R4. The CLI in the current edition corresponds to SR OS Release 25.3.R2.
Overview
The AA stateful FW feature extends AA-ISA application level analysis to provide an in-line integrated stateful service that protects subscribers from malicious attacks. AA stateful packet filtering combined with AA layer 7 classification and control, empowers operators with advanced, next generation firewall functionality that is integrated within the Service Router. The AA stateful firewall (FW) and application firewall runs on AA-ISA. Using stateful inspection, the AA firewall not only inspects packets at layers 3-7, but also monitors and keeps track of the connection state. If the operator configures a deny action within a session filter, then the matching packets (matching both the AA Application QoS policy (AQP) and associated session filter match conditions) are dropped and no flow session state or context is created.
AA FW can be used in all deployments of AA-ISA; mobile (MG OS) and fixed (SR OS); however, the configuration examples here, while still very applicable (and almost 100% identical in mobile deployments) are focused on AA-ISA deployments in fixed networks.
The AA-ISA FW enabled solution provides:
-
stateful (and stateless) packet filtering and inspection with application-level gateway (ALG) support
denial of service (DoS) attack protection.
The objective of this chapter is to describe the required configuration within AA-ISA (divert to AA-ISA basic knowledge is assumed) to enable AA FW and protect AA subscribers from attacks (unsolicited attacks and DoS attacks), while still allowing pin-holing through the firewall, so that applications such as peer to peer gaming and various ALGs (such as FTP) are not affected.
Stateful filtering
By performing stateful inspection, AA-ISA takes into account which side initiated a session and acts accordingly. Stateful flow processing and inspection uses IP layer 3 and layer 4 header information to build a state of the flow within AA-ISA. Layer 7 inspection is used to provide ALG support. Stateful flow and session processing takes note of the originator of the session and therefore can allow traffic to be initiated from the subscriber, while denying (when configured) traffic originating from the network. Packets received from the network are inspected against the session filter and only those that are part of a subscriber-initiated session are allowed.
To support the example shown in Block unsolicited traffic, AA is configured with an action to block unsolicited traffic; traffic that is not requested by the subscriber. The direction field in match criteria of AQPs is used to enable this functionality.
SFW — allow gaming shows a similar concept. It is used to allow UDP traffic for peer to peer applications, such as gaming. When the traffic from one peer is seen by AA-ISA, a pin-hole is opened in the reverse direction to allow for the corresponding UDP traffic from the peer.
Stateless packet filtering on the other hand does not take note of the session initiator. It discards or allows packets independently of any previous packets. In addition to the AA-ISA support for stateless (and stateful) filtering, stateless packet filtering can be performed in the system using line card ACLs (and MGISM PCC rules in mobile gateway deployments).
Application layer gateway filtering
AA FW inspection of packets at Layer 7 offers application layer gateway functionality for a large list of applications (for example, FTP, SIP, RTSP, PPTP, IRC, and so on). These applications make use of control channels or flows that spawn other flows. AA FW inspects the payload of these control flows so it can open a pinhole in advance for unspawned data flows. ALG support example — FTP depicts an example of AA ALG support for FTP traffic.
Denial of Service (DoS) protection
DoS attacks work by consuming network and system resources, making them unavailable for legitimate network applications. Network flooding attacks, malformed packets and port scans are examples of such DoS attacks.
The aim of AA FW DoS protection is to protect subscribers and prevent any abuse of network resources.
Using AA FW stateful session filters, operators can protect their subscribers from any port scan scheme. This can be done by configuring the session filters to disallow any traffic that is initiated from the network.
Furthermore, AA ISA provides configurable flow policers. These policers prevent a wide range of flooding attacks (such as ICMP PING flooding, UDP flooding, SYN flood attack...and so on.). These policers provide protection at multiple levels; per system per application or application group and per subscriber per application or application group.
There are two types of AA ISA flow policers: flow setup rate policers and flow count policers. Flow setup rate policers limit the number of new flows, while flow count policers limit the total number of active flows.
To protect hosts and network resources, AA FW checks different fields in the packet header (checksum, TCP flag, and so on) and if any fails, it declares the packet to be invalid. This complements the SR OS subscriber management enhanced security features, such as IP (or MAC) anti-spoofing protection (such as protecting against LAND attacks) and network protocol DoS protections. The cut-through-drop AQP action must be configured in order to drop these types of invalid packets.
Virtual FW or zone-based FW
AA FW can provide up to 128 virtual FWs, each with its own FW policies. This is achieved through the use of AA partitions.
In addition, AA subscribers within the same AA partition can have different application profiles with different Application Service Options (ASO) values. This provides a further control mechanism to enable or disable firewall rules.
For example, the operator may want to have some subscribers possess full firewall protection, while other subscribers not subscribed to this service have a partial firewall protection that focuses on protecting network resources, instead of network and subscribers resources.
Configuration
AA-ISA AQP actions provide session filtering functionality. AQPs have partition level scope, which allows different FW policies to be implemented by utilizing AA partitions concepts within the same AA-ISA group. Therefore, multiple virtual AA FW instances can be realized, without the need for multiple physical instances of FWs to implement different FW policies.
The AA FW stateful session filter consists of multiple entries (similar to ACLs) with a match and action per entry. A deny action results in packets being discarded without creating a session or flow context. Match conditions include IP protocol types, source and destination IP addresses, and source and destination ports. An overall default action is also configurable in case of no match to any session filter entry.
AQPs with session filter actions need to have — as a matching condition — traffic direction, ASOs, and/or subscriber name. These AQP match rules cannot have any references to applications or application groups.
An AQP action to drop malformed or errored packets is also available.
Statistics are incremented when packets are dropped by a session filter. These are accounted against:
protocol: denied by default policy
application: unknown
application group: unknown.
The configuration topology is shown in Configuration topology.
Application profiles
Nothing new is introduced in application profiles to support FW. This section describes how to configure the application profile to allow differentiated FW services for different subscribers. In a nutshell, the AA common building construct or attribute for differentiated policy is ASO.
To configure an ASO for FW protection:
configure
application-assurance
group 1:2 create
policy
begin
app-service-options
characteristic "FW-Protection" create
value "None"
value "ON"
default-value "None"
exit
characteristic "ISP-Protection" create
value "None"
value "ON"
default-value "None"
exit
characteristic "DOS-Protection" create
value "None"
value "ON"
default-value "None"
exit
exit
commit
In the preceding example:
-
ASO "FW-protection" allows the operator to select if the subscriber is FW protected or not.
-
ASO "DOS-protection" refers to if the subscriber is protected from DoS attacks.
-
ASO "ISP-protection" is different from the preceding two because it protects the ISP resources by (in the example that follows) not allowing unsolicited traffic. This should be ON for all subscribers (it is then arguable if someone needs it to be defined in the ASO list, instead of merely configuring an AQP to protect ISP resources all the time).
These ASOs are referenced in appProfiles (and later in AQPs) as follows:
configure
application-assurance
group 1:2 create
policy
begin
app-profile "Protected" create
divert
characteristic "FW-Protection" value "ON"
characteristic "DOS-Protection" value "ON"
characteristic "ISP-Protection" value "ON"
exit
commit
The preceding application profile "Protected" is assigned to subscribers who opted/subscribed to the firewall protection service; for example, subscriber 1 and subscriber 2 in the example shown in Configuration topology.
Subscribers who are not protected (for example subscriber 3 in Configuration topology) are assigned a different profile:
configure
application-assurance
group 1:2 create
policy
begin
app-profile "unProtected" create
divert
characteristic "FW-Protection" value "None"
characteristic "DOS-Protection" value "None"
characteristic "ISP-Protection" value "ON"
exit
commit
An alternative method to using application profiles/ASOs to provide differentiated services is to configure multiple partitions with different AQPs/session filters. One partition, for example, is for subscribers who are provided with firewall protection, while another is used for subscribers who are not protected. This configuration is simpler and provides statistics per partition. This example however covers the more complex case using ASOs/appProfiles.
Flow count policers
The following configuration limits the number of flows a subscriber can have at any time to 500. This is done to protect against DoS attacks. The value 500 is arbitrary and requires tuning for each deployment.
configure
application-assurance
group 1
policer Dos_police_Flow_count type flow-count-limit granularity subscriber create
flow-count 500
exit
The following configuration limits the total number of flows that matches the configured AQP matching condition. It is used for ICMP applications to prevent mass port scanning.
configure
application-assurance
group 1
policer Dos_Police_ICMPFlows type flow-count-limit granularity system create
flow-count 5000
exit
TCP protocol validation
The following configuration allows the operator to call the "TCP_protect" policy from within an AQP action entry.
configure
application-assurance
group 1:2 create
tcp-validate TCP_protect create
exit
The operator can also configure the policy to be strict, in which case the AA checks for valid sequence and acknowledgements numbers. In this example, the strict option is not used.
Applications
The following application configuration is standard with AppDB. It is shown here for reference.
configure
application-assurance
group 1:2 create
policy
begin
application "ICMP" create
exit
app-filter
entry 1540 create
protocol eq "non_tcp_udp"
ip-protocol-num eq icmp
application "ICMP"
no shutdown
exit
entry 35500 create
protocol eq "non_tcp_udp"
ip-protocol-num eq ipv6-icmp
application "ICMP"
no shutdown
exit
exit
commit
Session filters
The following displays session filter configuration commands to be used.
configure
application-assurance
group 1:2 create
session-filter <name> create
description <description>
default-action permit|deny # default=deny
entry <...> create
description <entry-description>
match
ip-protocol-num <ip-protocol-number> | <ip-protocol-name>
src-ip <ip4_or_v6-address/mask> | ip-prefix-list <name>
dst-ip <ip4_or_v6-address/mask> | dns-ip-cache <name>| ip-prefix-list <name>
src-port {eq|gt|lt} <port-num> | range <start> <end> | port-list <name>
dst-port {eq|gt|lt} <port-num> | range <start> <end> | port-list <name>
exit
action permit|deny | http-redirect <name> | redirect <IP/port> | tcp-optimizer <..>
exit
---snip---
Parameters
-
entry
A session filter can have multiple match-action rules, each of these match-action rules represents an entry within the session filter. The entries are executed in order. If a match is found, within one entry, the subsequent entries within the session filter are skipped (not evaluated).
-
default-action [permit | deny]
*A:PE-1>config>app-assure>group>sess-fltr# default-action ? - default-action {permit|deny} [event-log <event-log-name>] <permit|deny> : permit|deny <event-log-name> : [32 chars max]The default action is performed if no match is found for any of the configured entries within the session filter. Default is deny.
-
A deny action drops the packet and does not allow a flow record to be allocated for that flow. A drop action within AA AQP drops the packet but it still creates flow record.
-
A permit action allows the packet to flow through the system. A flow record is also allocated. The packet may get dropped by other configured AQP actions (because of header check failures).
-
-
description description-string
This configures a text string which can be used to describe the use of the session-filter.
-
match
*A:PE-1>config>app-assure>group>sess-fltr>entry# match ? - match [no] dst-ip - Configure the destination IP address to match against [no] dst-port - Configure a destination port or port range to match against [no] ip-protocol-num - Configure the IP protocol number to match against [no] src-ip - Configure the source IP address to match against [no] src-port - Configure a source port or port range to match againstKeywords to perform the action specified under the action keyword only if the conditions in the match section are met.
-
ip-protocol-num : <protocol-number> | <protocol-name>
*A:PE-1>config>app-assure>group>sess-fltr>entry>match# ip-protocol-num ? - no ip-protocol-num - ip-protocol-num <ip-protocol-number> <ip-protocol-number> : <protocol-number> | <protocol-name> <protocol-number> : [0..255]D [0x0..0xFF]H [0b0..0b11111111]B <protocol-name> : none|icmp|igmp|ip|tcp|egp|igp|udp|rdp|ipv6|ipv6-route|ipv6-frag|idrp|rsvp| gre|ipv6-icmp|ipv6-no-nxt|ipv6-opts|iso-ip|eigrp|ospf-igp|ether-ip|encap| pnni|pim|vrrp|l2tp|stp|ptp|isis|crtp|crudp|sctp| * - udp/tcp wildcard -
src-ip>/dst-ip defines the source an destination IP address within the packet header.
*A:PE-1>config>app-assure>group>sess-fltr>entry>match# src-ip ? - no src-ip - src-ip <ip-address> - src-ip ip-prefix-list <ip-prefix-list> <ip-address> : ipv4-address - a.b.c.d[/mask] mask - [0..32] ipv6-address - x:x:x:x:x:x:x:x/prefix-length x:x:x:x:x:x:d.d.d.d x - [0..FFFF]H d - [0..255]D prefix-length [0..128] <ip-prefix-list> : [32 chars max]*A:PE-1>config>app-assure>group>sess-fltr>entry>match# dst-ip ? - dst-ip <ip-address> - dst-ip dns-ip-cache <dns-ip-cache-name> - dst-ip ip-prefix-list <ip-prefix-list-name> - no dst-ip <ip-address> : ipv4-address - a.b.c.d[/mask] mask - [0..32] ipv6-address - x:x:x:x:x:x:x:x/prefix-length x:x:x:x:x:x:d.d.d.d x - [0..FFFF]H d - [0..255]D prefix-length [0..128] <ip-prefix-list-na*> : [32 chars max] <dns-ip-cache-name> : [32 chars max] -
src-port/dst-port
*A:PE-1>config>app-assure>group>sess-fltr>entry>match# src-port ? - src-port {eq|gt|lt} <port-num> - src-port range <start-port-num> <end-port-num> - src-port port-list <port-list-name> - no src-port <eq | gt | lt> : eq|gt|lt <port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <range> : keyword <start-port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <end-port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <port-list-name> : [32 chars max]*A:PE-1>config>app-assure>group>sess-fltr>entry>match# dst-port ? - dst-port {eq|gt|lt} <port-num> - dst-port range <start-port-num> <end-port-num> - dst-port port-list <port-list-name> - no dst-port <eq | gt | lt> : eq|gt|lt <port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <range> : keyword <start-port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <end-port-num> : [0..65535]D [0x0..0xFFFF]H [0b0..0b1111111111111111]B <port-list-name> : [32 chars max]src-port/dst-port {eq | gt | lt} port-num-
eq — equal, exact match
-
gt — match port numbers that are greater than the one specified.
-
lt — match port numbers that are lower than the one specified.
-
port-num — 0..65535 (applicable to TCP, UDP and SCTP protocols only)
-
-
-
action: only executed if a match is found.
*A:PE-1>config>app-assure>group>sess-fltr>entry# action ?
- action <action> [event-log <event-log-name>]
- action http-redirect <http-redirect-name> [event-log <event-log-name>]
- action redirect [dst-ip <ip-address>] [dst-port <tcp/udp-port>] [event-log <event-log-name>]
- action tcp-optimizer <tcp-optimizer-name>
<action> : permit|deny
<http-redirect-name> : [32 chars max]
<tcp-optimizer-name> : [32 chars max]
<redirect> : keyword
<ip-address> : ipv4-address - a.b.c.d
ipv6-address - x:x:x:x:x:x:x:x (eight 16-bit pieces)
x:x:x:x:x:x:d.d.d.d
x - [0..FFFF]H
d - [0..255]D
<tcp/udp-port> : destination port
<event-log-name> : [32 chars max]
-
deny action drops the packet and does not create a flow record.
-
permit action allows the packet to go through (unless another different action is found that causes it to be dropped).
- http-redirect action refers to a HTTP redirect policy.
- redirect action redirects sessions matching the criteria to a different destination using a layer 3 and layer 4 redirect.
- tcp-optimizer action refers to a TCP optimization policy.
The session filter "denyUnsolictedwMgntCntrl" is configured as follows:
configure
application-assurance
group 1:2 create
session-filter "denyUnsolictedwMgntCntrl" create
description "S-FW opted-in sub – allow ISP access"
default-action deny
entry 10 create
description "allow ICMP access from ISP LAN1"
match
ip-protocol-num icmp
src-ip 10.10.8.0/24
exit
action permit
exit
entry 20 create
description "allow ICMP access from ISP LAN2"
match
ip-protocol-num icmp
src-ip 192.168.0.0/24
exit
action permit
exit
entry 30 create
description "allow all TCP (e.g. FTP/telnet)access from ISP LAN2"
match
ip-protocol-num tcp
src-ip 192.168.0.0/24
exit
action permit
exit
entry 40 create
description "allow TCP on port 80 /HTTP access from ISP LAN1"
match
ip-protocol-num tcp
src-ip 10.10.8.0/24
dst-port eq 80
exit
action permit
exit
The session filter "protectISPLan2" is used to protect systems located in LAN2. It drops all unsolicited traffic except for FTP coming from LAN1.
configure
application-assurance
group 1:2 create
session-filter "protectISPLan2" create
description "S-FW to deny all unsolicited requests to LAN2"
default-action deny
entry 10 create
description "allow ftp access from ISP LAN1"
match
ip-protocol-num tcp
src-ip 10.10.8.0/24
dst-port eq 21
exit
action permit
exit
exit
AQPs
configure
application-assurance
group 1:2 create
policy
begin
app-qos-policy
entry 100 create
description "protecting ISP1 from DoS attacks from subs"
match
traffic-direction subscriber-to-network
characteristic "ISP-Protection" eq "ON"
dst-ip eq 10.10.8.0/24
exit
action
flow-count-limit "Dos_police_Flow_count"
exit
no shutdown
exit
entry 105 create
description "protecting ISP2 from DoS attacks from subs"
match
traffic-direction subscriber-to-network
characteristic "ISP-Protection" eq "ON"
dst-ip eq 192.168.0.0/24
exit
action
flow-count-limit "Dos_police_Flow_count"
exit
no shutdown
exit
exit
commit
These AQPs protect the ISP network by limiting the number of concurrent flows. Dropping malformed packets is done by entry 130 (see further).
To guard against ICMP flooding attacks, a flow count policer (defined earlier) is used as follows:
configure
application-assurance
group 1:2 create
policy
begin
app-qos-policy
entry 107 create
match
application eq "ICMP"
traffic-direction subscriber-to-network
exit
action
flow-count-limit Dos_Police_ICMPFlows
exit
no shutdown
exit
exit
commit
To guard against attacks exploiting TCP handshake mechanisms, TCP validate policy is used as follows:
configure
application-assurance
group 1:2 create
tcp-validate "TCP_protect" create
exit
policy
begin
app-qos-policy
entry 108 create
match
characteristic "ISP-Protection" eq "ON"
exit
action
tcp-validate "TCP_protect"
exit
no shutdown
exit
entry 109 create
match
characteristic "FW-Protection" eq "ON"
exit
action
tcp-validate "TCP_protect"
exit
no shutdown
exit
exit
commit
TCP validation works on both directions and needs to be called in from within a sub-default AQP entry. Therefore, this AQP action cannot be restricted to one ISP versus another because no destination IP address can be specified. The configuration shown runs TCP validation policy when ISP-Protection or FW-protection ASOs are enabled.
The preceding configuration ensures, for example, that no TCP session starts without the correct handshake message exchanges.
To protect ISP LAN2 from all unsolicited incoming traffic, entry 120 is configured:
configure
application-assurance
group 1:2 create
policy
begin
app-qos-policy
entry 120 create
match
traffic-direction subscriber-to-network
characteristic "ISP-Protection" eq "ON"
exit
action
session-filter "protectISPLan2"
exit
no shutdown
exit
exit
commit
The session filter "ProtectISPLan2" drops all unsolicited traffic to LAN2 (highly secure) except for access to FTP services coming from ISP LAN1.
To enable stateful protection for opted-in subscribers:
configure
application-assurance
group 1:2 create
policy
begin
app-qos-policy
entry 110 create
description "FW for managed opted-in subs"
match
traffic-direction network-to-subscriber
characteristic "FW-Protection" eq "ON"
exit
action
session-filter "denyUnsolictedwMgntCntrl"
exit
no shutdown
exit
exit
commit
The preceding AQP protects opt-in subscribers from unsolicited traffic but still allows unsolicited traffic from ISP subnets to manage the subscriber network.
Dropping malformed or illegal packets and protecting against DOS attacks is done via the following entries 130 and 131.
configure
application-assurance
group 1:2 create
policy
begin
app-qos-policy
entry 130 create
match
traffic-direction subscriber-to-network
characteristic "DOS-Protection" eq "ON"
exit
action
flow-count-limit "Dos_police_Flow_count"
exit
no shutdown
exit
entry 131 create
match
characteristic "DOS-Protection" eq "ON"
exit
action
overload-drop
error-drop
fragment-drop all
exit
no shutdown
exit
exit
commit
Threshold crossing alerts
Operators can configure AA to generate TCAs for various firewall related parameters, such as error-drop, session-filter hits, TCP-validate, fragment-drop-all and so on, as well as flow count policers. An example of a TCA used for TCP validation policy is as follows:
configure
application-assurance
group 1:2 create
statistics
threshold-crossing-alert
tcp-validate "TCP_protect" direction from-sub create
high-wmark 50 low-wmark 40
exit
exit
Unlike the other TCAs, to configure TCAs for flow count policers, operators need first to configure AA admit-deny to allocate ISA resources, such as:
configure
application-assurance
group 1:2 create
statistics
aa-admit-deny
policer-stats-resources
exit
A TCA can be configured for any flow based policer in the system, as follows:
configure
application-assurance
group 1:2 create
statistics
threshold-crossing-alert
policer "Dos_police_Flow_count" direction from-sub create
high-wmark 300 low-wmark 199
exit
The system allows the various AA-admit-deny statistics to be exported via XML according to the configured accounting policy on the system. Analytics systems can then use these statistics to generate the right reports and alerts.
As a prerequisite, an accounting policy is configured for aa-admit-deny statistics:
configure
log
accounting-policy 5
record aa-admit-deny
no shutdown
exit
Then, the operator can configure AA to export the statistics related to various firewall functions configured in the system, as follows:
configure
application-assurance
group 1:2 create
statistics
aa-admit-deny
accounting-policy 5
collect-stats
session-filter-stats
policer-stats-resources
tcp-validate-stats
exit
GPRS tunneling protocol (GTP) and stream control transmission protocol (SCTP) admit deny stats are related to firewall deployment within a SeGW, which is not covered within the scope of this chapter.
Show commands
Show routines — AQP:
*A:PE-1# show application-assurance group 1:2 policy app-qos-policy 110
===============================================================================
Application QOS Policy Entry 110 (Default Subscriber Policy)
===============================================================================
Description : FW for managed opted-in subs
Admin State : in-service
Hits : 0 flows
Conflicts : 0 flows
Match :
Traffic Direction : network-to-subscriber
ASO Characteristics :
FW-Protection : eq ON
Action :
Session Filter : denyUnsolictedwMgntCntrl
===============================================================================
Show routines — session filter:
*A:PE-1# show application-assurance group 1:2 session-filter
===============================================================================
AA Session Filter Table
===============================================================================
Name Default Action Referenced Entries
-------------------------------------------------------------------------------
protectISPLan2 deny aqp 1
denyUnsolictedwMgntCntrl deny aqp 4
-------------------------------------------------------------------------------
No. of session filters: 2
===============================================================================
*A:PE-1# show application-assurance group 1:2 session-filter "denyUnsolictedwMgntCntrl"
===============================================================================
AA Session Filter Instance "denyUnsolictedwMgntCntrl"
===============================================================================
Description : (Not Specified)
Default Action : deny
Event Log : (Not Specified)
AQP Entries :
110
-------------------------------------------------------------------------------
Filter Match Criteria
-------------------------------------------------------------------------------
Entry : 10
Description : allow ICMP access from ISP LAN1
IP Protocol : icmp
Source IP : 10.10.8.0/24
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 20
Description : allow ICMP access from ISP LAN2
IP Protocol : icmp
Source IP : 192.168.0.0/24
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 30
Description : allow all TCP (e.g. FTP/telnet)access from ISP LAN2
IP Protocol : tcp
Source IP : 192.168.0.0/24
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 40
Description : allow TCP on port 80 /HTTP access from ISP LAN1
IP Protocol : tcp
Source IP : 10.10.8.0/24
Dest Port : eq 80
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
No. of entries : 4
===============================================================================
Show routines — TCP validation:
*A:PE-1# show application-assurance group 1:2 tcp-validate "TCP_protect"
===============================================================================
Application Assurance Group 1:2 tcp-validate "TCP_protect"
===============================================================================
Description : (Not Specified)
Event log : (Not Specified)
Strict Validation: No
AQP referenced : Yes
-------------------------------------------------------------------------------
Decision Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Total
-------------------------------------------------------------------------------
Allowed
Octets 0 0
Packets 0 0
Dropped
Octets 0 0
Packets 0 0
Dropped Reason
-------------------------------------------------------------------------------
Bad Flags
Octets 0 0
Packets 0 0
Bad Options
Octets 0 0
Packets 0 0
Bad Sequence Number
Octets 0 0
Packets 0 0
Bad Acknowledgment Number
Octets 0 0
Packets 0 0
No Establishment
Octets 0 0
Packets 0 0
SYN After Conn Establishment
Octets 0 0
Packets 0 0
Asymmetric Traffic
Octets 0 0
Packets 0 0
Traffic After Reset (RST)
Octets 0 0
Packets 0 0
Fragmented
Octets 0 0
Packets 0 0
===============================================================================
*A:PE-1# show application-assurance threshold-crossing-alert detail
===============================================================================
Application Assurance Threshold Crossing Alerts
===============================================================================
-------------------------------------------------------------------------------
policer "Dos_police_Flow_count" from-sub
-------------------------------------------------------------------------------
Group:Part : 1:2 Trigger on : denied-traffic
High watermark : 300 Low watermark : 199
Last raised : N/A Last cleared : N/A
State : cleared
-------------------------------------------------------------------------------
tcp-validate "TCP_protect" from-sub
-------------------------------------------------------------------------------
Group:Part : 1:2 Trigger on : denied-traffic
High watermark : 50 Low watermark : 40
Last raised : N/A Last cleared : N/A
State : cleared
No. of TCAs : 2
===============================================================================
The following output is slightly modified to make the wide table fit on the page.
*A:PE-1# tools dump application-assurance group 1:2 admit-deny-stats
=============================================================================
Application-Assurance Group 1:2 Admit-Deny Statistics
=============================================================================
-----------------------------------------------------------------------------
Admitted Denied Admitted Denied
Sub-To-Net Sub-To-Net Net-To-Sub Net-To-Sub
Packet Validation Statistics (Packets) (Packets) (Packets) (Packets)
-----------------------------------------------------------------------------
Error 0 0 0 0
Fragments: Out-Of-Order 0 0 0 0
Fragments: All 0 0 0 0
Overload N/A 0 N/A 0
-----------------------------------------------------------------------------
Admitted Denied Admitted Denied
Sub-To-Net Sub-To-Net Net-To-Sub Net-To-Sub
Session Filter Statistics (Packets) (Packets) (Packets) (Packets)
-----------------------------------------------------------------------------
Session Filter: protectISPLan2
Entry: 10 0 0 0 0
Default Action 0 0 0 0
Session Filter: denyUnsolictedwMgntCntrl
Entry: 10 0 0 0 0
Entry: 20 0 0 0 0
Entry: 30 0 0 0 0
Entry: 40 0 0 0 0
Default Action 0 0 0 0
-----------------------------------------------------------------------------
Admitted Denied Admitted Denied
Sub-To-Net Sub-To-Net Net-To-Sub Net-To-Sub
Flow Policer Statistics (Packets) (Packets) (Packets) (Packets)
-----------------------------------------------------------------------------
System Flow Count Policers
Dos_Police_ICMPFlows 0 0 0 0
Subscriber Flow Count Policers
Dos_police_Flow_count 0 0 0 0
-----------------------------------------------------------------------------
Admitted Denied Admitted Denied
Sub-To-Net Sub-To-Net Net-To-Sub Net-To-Sub
TCP Validation Statistics (Packets) (Packets) (Packets) (Packets)
-----------------------------------------------------------------------------
TCP_protect 0 0 0 0
-----------------------------------------------------------------------------
Conclusion
The AA stateful packet filtering feature combined with AA layer 7 classification and control empowers operators with an advanced, next generation firewall functionality that is integrated within SR OS. This chapter focuses on traditional stateful and stateless session firewall functionality.