Showing posts with label ASA. Show all posts
Showing posts with label ASA. Show all posts

Sunday, 28 April 2013

ASA SSL - part II - Anyconnect


In order to configure the ASA for VPN access using the AnyConnect client, complete these steps:
  1. Configure a Self-Issued Certificate.
  2. Upload and Identify the SSL VPN Client Image.
  3. Enable Anyconnect Access.
  4. Create a new Group Policy.
  5. Configure Access List Bypass for VPN Connections.
  6. Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections.
  7. Add Users to the Local Database.
Scenario:
  • Configure a Self-Issued Certificate
By default, the security appliance has a self-signed certificate that is regenerated every time the device is rebooted. You can purchase your own certificate from vendors, such as Verisign or EnTrust, or you can configure the ASA to issue an identity certificate to itself. This certificate remains the same even when the device is rebooted.
  • Upload and Identify the SSL VPN Client Image
ciscoasa# copy tftp://172.20.1.6/anyconnect-win-3.0.11042-k9.pkg flash:
Address or name of remote host [172.20.1.6]?
Source filename [anyconnect-win-3.0.11042-k9.pkg]?
Destination filename [anyconnect-win-3.0.11042-k9.pkg]? 
webvpn
 anyconnect image disk0:/anyconnect-win-3.0.11042-k9.pkg 1
  • Enable Anyconnect Access.
webvpn
 port 8443
 enable outside
 anyconnect enable
  • Create a new Group Policy.
access-list SPLIT_TUNNEL standard permit 10.1.1.0 255.255.255.0
access-list PERMIT_ANY extended permit ip any any 

 group-policy SSLVPN internal
group-policy SSLVPN attributes
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
  • Configure Access List Bypass for VPN Connections.
sysopt connection permit-vpn
  •  Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections.
 ip local pool SVC_POOL 20.0.0.1-20.0.0.254

tunnel-group SSLVPN type remote-access
tunnel-group SSLVPN general-attributes
 address-pool SVC_POOL
 default-group-policy SSLVPN
 webvpn
tunnel-group-list enable
  •  Add Users to the Local Database.
username ANYCONNECT password CISCO
Verification: 
  • https://172.20.1.10:8443

  • anyconnect will be downloaded and installed automatically.
  •  SSLVPN connection will be automatically established after that

  • ASA outputs:
ciscoasa# show webvpn anyconnect
1. disk0:/anyconnect-win-3.0.11042-k9.pkg 1 dyn-regex=/Windows NT/
  CISCO STC win2k+
  3,0,11042
  Hostscan Version 3.0.11042
  Mon 12/10/2012  5:18:28.27
1 AnyConnect Client(s) installed

ciscoasa# show vpn-sessiondb anyconnect
Session Type: AnyConnect
Username     : ANYCONNECT                 Index        : 15
Assigned IP  : 20.0.0.1               Public IP    : 172.20.1.6
Protocol     : Clientless SSL-Tunnel
Encryption   : RC4                    Hashing      : SHA1
Bytes Tx     : 47604                  Bytes Rx     : 11501
Group Policy : SSLVPN                 Tunnel Group : SSLVPN
Login Time   : 18:45:49 UTC Sat Apr 27 2013
Duration     : 0h:06m:03s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

ASA SSL - part I - Clientless

Clientless SSL VPN (WebVPN) allows for limited but valuable secure access to the corporate network from any location.
A remote client needs only an SSL-enabled web browser to access http- or https-enabled web servers on the corporate LAN.
Clientless SSL VPN and ASDM must not be enabled on the same ASA interface. It is possible for the two technologies to coexist on the same interface if changes are made to the port numbers. It is highly recommended that ASDM is enabled on the inside interface, so WebVPN can be enabled on the outside interface.

Clientless SSL VPN provides secure and easy access to a broad range of web resources and web-enabled applications from almost any computer on the Internet. They include:

•Internal websites
•Web-enabled applications
•NT/Active Directory file shares
•E-mail proxies, including POP3S, IMAP4S, and SMTPS
•MS Outlook Web Access
•Application Access (that is, smart tunnel or port forwarding access to other TCP-based applications)

The user connects to the ASA firewall using a secure HTTP connection and logs in using a name and
a password provided. The firewall opens a special (customizable) portal page to the user, which mulates a browser, with URL address bar. The user may enter URLs for company resources, and the firewall resolves them using a configured DNS server and downloads the requested pages. Optionally, the firewall may apply an URL filter to restrict access to certain corporate resources, or even disallow URL entry at all, providing the user with a list of static bookmarks.

Using WebVPN you can download a special Java applet that implements port-forwarding. 
A browser plug-in is a separate program that a web browser invokes to perform a dedicated function, such as connect a client to a server within the browser window. The adaptive security appliance lets you import plug-ins for download to remote browsers in clientless SSL VPN sessions.

Cisco redistributes the following open-source, Java-based components to be accessed as plug-ins for web browsers in clientless SSL VPN sessions:
  • Citrix Client (ica)
  • Terminal Servers (rdp)
  • Terminal Servers Vista (rdp2)
  • SSH
  • Telnet
  • VNC
Scenario:

Enable WebVPN 
webvpn
 port 8443
 enable outside
 tunnel-group-list enable

Define a DNS server group
dns domain-lookup outside
DNS server-group DNS
    name-server 8.8.8.8

Define a group policy for WebVPN connection
 access-list WEBACCESS webtype permit url http://*.com

group-policy WEBVPN internal
group-policy WEBVPN attributes
 vpn-tunnel-protocol ssl-clientless
 webvpn
  filter value WEBACCESS
  url-entry enable

Define a connection-profile (tunnel-group) for WebVPN users
tunnel-group WEBVPN type remote-access
tunnel-group WEBVPN general-attributes
 default-group-policy WEBVPN
tunnel-group WEBVPN webvpn-attributes
 group-alias WEBVPN enable
 dns-group DNS

username ClientlessUser password CISCO
username ClientlessUser attributes
 group-lock value WEBVPN

Applications plug-in
ciscoasa#import webvpn plug-in protocol ssh,telnet tftp://172.20.1.6/ssh-plugin.jar
ciscoasa#import webvpn plug-in protocol vnc tftp://172.20.1.6/vnc-plugin.jar

Verification:
  • https://172.20.1.10:8443



  • ASA outputs:
ciscoasa# show vpn-sessiondb webvpn
Session Type: WebVPN
Username     : WEBVPN                 Index        : 6
Public IP    : 172.20.1.6
Protocol     : Clientless
Encryption   : RC4                    Hashing      : SHA1
Bytes Tx     : 2576                   Bytes Rx     : 19408
Group Policy : WEBVPN                 Tunnel Group : WEBVPN
Login Time   : 14:40:29 UTC Sun Apr 28 2013
Duration     : 0h:02m:39s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

Friday, 26 April 2013

ASA IPsec ezVPN server


Scenario:


  • IKE config
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400
  • Tunnel-Group and Tunnel Group Policies
tunnel-group ezVPN type remote-access
tunnel-group ezVPN general-attributes
 default-group-policy ezVPN
tunnel-group ezVPN ipsec-attributes
 ikev1 pre-shared-key TEST

 group-policy ezVPN internal
group-policy ezVPN attributes
 vpn-tunnel-protocol ikev1
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
 address-pools value ezVPN
where
  • SPLIT_TUNNEL is:
access-list SPLIT_TUNNEL standard permit 10.1.1.0 255.255.255.0 
  • address-pool ezVPN is:
ip local pool EZVPN 20.0.0.1-20.0.0.254


  • IPsec config

crypto ipsec ikev1 transform-set 3DES esp-3des esp-md5-hmac
crypto dynamic-map DYNAMIC 10 set ikev1 transform-set 3DES
crypto dynamic-map DYNAMIC 10 set reverse-route
crypto map VPN 100 ipsec-isakmp dynamic DYNAMIC
crypto map VPN interface outside
  • Authentication config
username VPN_USER password  CISCO
username VPN_USER attributes
 group-lock value ezVPN
Verification:

ciscoasa# show crypto ikev1 sa detail
IKEv1 SAs:
   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1   IKE Peer: 172.20.1.6
    Type    : user            Role    : responder
    Rekey   : no              State   : AM_ACTIVE
    Encrypt : 3des            Hash    : MD5      
    Auth    : preshared       Lifetime: 86400
    Lifetime Remaining: 85154

ciscoasa# show crypto ipsec sa detail
interface: outside
    Crypto map tag: DYNAMIC, seq num: 10, local addr: 172.20.1.2
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)
      current_peer: 172.20.1.6, username: CISCO
      dynamic allocated peer ip: 20.0.0.1
      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 12, #pkts decrypt: 12, #pkts verify: 12
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #pkts no sa (send): 0, #pkts invalid sa (rcv): 0
      #pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
      #pkts invalid prot (rcv): 0, #pkts verify failed: 0
      #pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
      #pkts invalid pad (rcv): 0,
      #pkts invalid ip version (rcv): 0,
      #pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
      #pkts replay failed (rcv): 0
      #pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
      #pkts internal err (send): 0, #pkts internal err (rcv): 0
      local crypto endpt.: 172.20.1.2/0, remote crypto endpt.: 172.20.1.6/0
      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 308A930C
      current inbound spi : 776D8DD3

ciscoasa# show ip local pool EZVPN
Begin           End             Mask            Free     Held     In use
20.0.0.1        20.0.0.254      0.0.0.0           253        0        1

Friday, 8 March 2013

ASA Active/Active Failover

The failover configuration requires two identical security appliances connected to each other through a dedicated failover link and, optionally, a stateful failover link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs.
In Active/Active Failover, both units can pass network traffic.
Active/Active Failover is only available on units that run in multiple context mode.
In Active/Active failover, you divide the security contexts on the security appliance into failover groups. A failover group is simply a logical group of one or more security contexts. You can create a maximum of two failover groups on the security appliance. The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default.
In an Active/Active failover configuration, failover occurs on a failover group basis, not a system basis.

Primary/Secondary Status
  • Determines which unit provides the running configuration to the pair when they boot simultaneously
  • Determines on which unit each failover group appears in the active state when the units boot simultaneously. Each failover group in the configuration is configured with a primary or secondary unit preference. 
Active/Standby Status

  • When a unit boots while the peer unit is not available, both failover groups become active on the unit.
  • When a unit boots while the peer unit is active (with both failover groups in the active state), the failover groups remain in the active state on the active unit regardless of the primary or secondary preference of the failover group until one of the following:
                1.A failover occurs.
                2.You manually force the failover group to the other unit with the no failover  active command
                 3.You configured the failover group with the preempt command, which causes the failover group to automatically become active on the preferred unit when the unit becomes available.
  • When both units boot at the same time, each failover group becomes active on its preferred unit after the configurations have been synchronized.
Failover Triggers

In Active/Active failover, failover can be triggered at the unit level if one of the following events occurs:

  • The unit has a hardware failure.
  • The unit has a power failure.
  • The unit has a software failure.
  • The no failover active or the failover active command is entered in the system execution space.
Failover is triggered at the failover group level when one of these events occurs:
  •  Too many monitored interfaces in the group fail.
  • The no failover active group group_id or failover active group group_id command is entered.

Configuration

1.Enable multiple context mode(on both devices)

ciscoasa(config)# mode multiple 

 ciscoasa(config)# show mode
Security context mode: multiple 

2.Configure contexts (on primary device)

admin-context CustomerA
context CustomerA
  allocate-interface GigabitEthernet0.100
  allocate-interface GigabitEthernet2
  config-url disk0:/admin.cfg
context CustomerB
  allocate-interface GigabitEthernet0.200
  allocate-interface GigabitEthernet2
  config-url disk0:/CustomerB.cfg

3.Configure failover group (on primary device)

failover group 1
  preempt
  polltime interface 1 holdtime 3
failover group 2
  secondary
  preempt
  polltime interface 1 holdtime 3
 4.Configure failover interface (on both devices)
failover lan unit primary (secondary on the second device)
failover lan interface failover GigabitEthernet1
failover link linkstate GigabitEthernet2
failover interface ip failover 1.1.1.1 255.255.255.252 standby 1.1.1.2
failover interface ip linkstate 2.2.2.1 255.255.255.252 standby 2.2.2.2
failover 

 5.Configure the virtual firewall (contexts) - ip addresses, policies, etc. 


ciscoasa(config)# changeto context CustomerA
interface GigabitEthernet0.100
 nameif insideA
 security-level 0
 ip address 10.100.100.1 255.255.255.0 standby 10.100.100.2
!
interface GigabitEthernet3
 nameif outside
 security-level 0
 ip address 192.168.223.100 255.255.255.0 standby 192.168.223.101 


ciscoasa(config)# changeto context CustomerB
nterface GigabitEthernet0.200
 nameif insideB
 security-level 0
 ip address 10.200.200.1 255.255.255.0 standby 10.200.200.2
!
interface GigabitEthernet3
 nameif outside
 security-level 0
 ip address 192.168.223.200 255.255.255.0 standby 192.168.223.201 

Command Replication


After both units are running in Active/Active faillover, commands are replicated from one unit to the other as shown:

  • Commands entered within a security context are replicated from the unit on which the security context appears in the active state to the peer unit.
  • Commands entered in the system execution space are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
  • Commands entered in the admin context are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
You can use the write standby command to resynchronize configurations that have become out of sync. For Active/Active failover, the write standby command behaves as shown:

  • If you enter the write standby command in the system execution space, the system configuration and the configurations for all of the security contexts on the security appliance is written to the peer unit. This includes configuration information for security contexts that are in the standby state. You must enter the command in the system execution space on the unit that has failover group 1 in the active state.
  • If you enter the write standby command in a security context, only the configuration for the security context is written to the peer unit. You must enter the command in the security context on the unit where the security context appears in the active state.



Verification

ciscoasa(config)# show failover group 1
  Last Failover at: 16:46:53 UTC Mar 8 2013
  This host:    Primary
                State:          Active
                Active time:    1652 (sec)
CustomerA Interface insideA (10.100.100.1): Normal (Monitored)
CustomerA Interface outside (192.168.223.100): Normal (Monitored)
CustomerB Interface insideB (10.200.200.1): Normal (Not-Monitored)
CustomerB Interface outside (192.168.223.200): Normal (Monitored)

  Other host:   Secondary
                State:          Standby Ready
                Active time:    452 (sec)
CustomerA Interface insideA (10.100.100.2): Normal (Monitored)
CustomerA Interface outside (192.168.223.101): Normal (Monitored)
CustomerB Interface insideB (10.200.200.2): Normal (Not-Monitored)
CustomerB Interface outside (192.168.223.201): Normal (Monitored)
  Stateful Failover Logical Update Statistics
Status: Configured.
RPC services   0          0          0          0        
        TCP conn 0          0          0          0        
UDP conn 0          0          0          0        
ARP tbl   3          0          0          0        
Xlate_Timeout   0          0          0          0        
IPv6 ND tbl   0          0          0          0        
SIP Session 0          0          0          0        
Route Session 0          0          0          0        
User-Identity 2          0          2          0         

ciscoasa(config)# show failover group 2
  Last Failover at: 16:46:51 UTC Mar 8 2013
  This host:    Primary
                State:          Standby Ready
                Active time:    0 (sec)


  Other host:   Secondary
                State:          Active
                Active time:    1656 (sec)

  Stateful Failover Logical Update Statistics
Status: Configured.
RPC services   0          0          0          0        
TCP conn 0          0          0          0        
UDP conn 0          0          0          0        
ARP tbl   0          0          0          0        
Xlate_Timeout   0          0          0          0        
IPv6 ND tbl   0          0          0          0        
SIP Session 0          0          0          0        
Route Session 0          0          0          0        
User-Identity 0          0          0          0         

ciscoasa(config)# show failover state
               State          Last Failure Reason      Date/Time
This host  -   Primary
    Group 1    Active         None
    Group 2    Standby Ready  None
Other host -   Secondary
    Group 1    Standby Ready  None
    Group 2    Active         None
====Configuration State===
Sync Done
====Communication State===
Mac set

Thursday, 7 March 2013

ASA Context Firewall

A single Cisco ASA appliance can be partitioned into multiple virtual firewalls known also as “Security Contexts”. Each security context acts as a separate firewall with its own security policy, interfaces and configuration. However, some features are not available for virtual firewalls, such as IPSEC and SSL VPN, Dynamic Routing Protocols, Multicast and Threat Detection.

In multiple security context mode we have three type of configuration file:


  • The System Configuration is the startup configuration and is similar to a standard single-mode configuration except no network interfaces are defined other than a specialized failover interface. This system configuration is where the network administrator adds and manages the security contexts.
  • The Admin Context is not restricted and can be used as any other security context. When logged in as admin, all other security contexts can be seen and administered including the system configuration. The Admin context must reside on flash memory.
  • The Context Configurations are created for each separate security context. These configurations contain the security policies, interface configurations, etc., specific only to that context.


Senario:



Requirements:
-Context CustomerA interfaces Gi0.100 (insideA), Gi1 (dmz), Gi2(outside)
-Context CustomerB interfaces Gi0.200 (insideB), Gi1 (dmz), Gi2(outside)
-Context admin (separate context)

context CustomerA
  allocate-interface GigabitEthernet0.100 insideA
  allocate-interface GigabitEthernet1 dmz
  allocate-interface GigabitEthernet2 outside
  config-url disk0:/customerA.cfg
context CustomerB
  allocate-interface GigabitEthernet0.100 insideB
  allocate-interface GigabitEthernet1 dmz visible
  allocate-interface GigabitEthernet2 outside
  config-url disk0:/customerB.cfg
admin-context admin
context admin
  config-url disk0:/admin.cfg

When you allocate interfaces to the context you can specify one of two optional flags:
  invisible for hiding hardware property in context (default)
  visible   for publishing hardware property in context

Changing between contexts and the system execution space

When you connect with a console cable on the appliance, you will log in the system configuration (or the system execution space). The “system execution space” is the global appliance space from where you can then enter into specific security contexts. If you are logged in the “system execution space” and issue a “show run” command, this will ONLY show you the global system configuration and NOT the various security contexts configurations. You will need to log into a specific security context in order to change or see its configuration.

Admin context is a special context that allows logging in the firewall remotely (using ssh, telnet or https). This context must be configured first. The firewall don't let you create any other contexts until you configure the admin context.
ciscoasa# changeto context CustomerA
ciscoasa/CustomerA#
interface insideA
 nameif insideA
 security-level 100
 ip address 10.100.100.1 255.255.255.0
!
interface dmz
 nameif dmz
 security-level 50
 ip address 192.168.1.1 255.255.255.0
!
interface outside
 nameif outside
 security-level 0
 ip address 192.168.223.100 255.255.255.0

ciscoasa/CustomerA# show interface ip brief
Interface                  IP-Address      OK? Method Status                Protocol
insideA                    10.100.100.1    YES manual up                    up
dmz                        192.168.1.1     YES manual up                    up
outside                    192.168.223.100 YES manual up                    up
ciscoasa/CustomerA# show interface dmz
Interface dmz "dmz", is up, line protocol is up
MAC address 00ab.cd92.5201, MTU 1500
IP address 192.168.1.1, subnet mask 255.255.255.0
  Traffic Statistics for "dmz":
41 packets input, 9527 bytes
8 packets output, 640 bytes
32 packets dropped




ciscoasa# changeto context CustomerB
ciscoasa/CustomerB#
interface insideB
 nameif insideB
 security-level 100
 ip address 10.200.200.1 255.255.255.0
!
interface dmz
 nameif dmz
 security-level 50
 ip address 192.168.1.2 255.255.255.0
!
interface outside
 nameif outside
 security-level 0
 ip address 192.168.223.101 255.255.255.0
ciscoasa/CustomerB# show interface ip brief
Interface                  IP-Address      OK? Method Status                Protocol
insideB                    10.200.200.1    YES manual up                    up
dmz                        192.168.1.2     YES manual up                    up
outside                    192.168.223.101 YES manual up                    up
ciscoasa/CustomerB(config-if)# show interface dmz
Interface dmz "dmz", is up, line protocol is up
System name GigabitEthernet1
MAC address 00ab.cd92.5201, MTU 1500
IP address 192.168.1.2, subnet mask 255.255.255.0
  Traffic Statistics for "dmz":
0 packets input, 0 bytes
2 packets output, 56 bytes
0 packets dropped

 Save Configuration Changes in Multiple Context Mode

You can save each context (and system) configuration separately(write memory), or you can save all context configurations at the same time (write memory all).

Security Appliance Context Packets Classification 

  • Unique Interfaces - happens when one interface is allocated only to one context.
  • Unique MAC Addresses - if multiple contexts share an interface, then the classifier uses the interface MAC address. The security appliance lets you assign a different MAC address in each context to the same shared interface, whether it is a shared physical interface or a shared subinterface. By default, shared interfaces do not have unique MAC addresses; the interface uses the physical interface burned-in MAC address in every context.
  • NAT configuration - if you do not have unique MAC addresses, then the classifier intercepts the packet and performs a destination IP address lookup. All other fields are ignored; only the destination IP address is used. To use the destination address for classification, the classifier must have knowledge about the subnets located behind each security context. The classifier relies on the NAT configuration to determine the subnets in each context. 

Wednesday, 6 March 2013

ASA Transparent Firewall


  • Information about ASA Transparent Mode

Transparent firewall mode transforms ASA into a layer 2 bridging device. In transparent mode the firewall is not a routed hop and the firewall acts as a "bump in the wire". In transparent mode the security appliance connects the same network on its inside and outside ports. Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network; it is unnecessary to re-address IP.

Even though the transparent mode acts as a bridge, Layer 3 traffic, such as IP traffic, cannot pass through the security appliance unless you explicitly permit it with an extended access list. The only traffic allowed through the transparent firewall without an access list is ARP traffic. ARP traffic can be controlled by ARP inspection.

When the security appliance runs in transparent mode, the outbound interface of a packet is determined by a MAC address lookup instead of a route lookup. Route statements can still be configured, but they only apply to security appliance-originated traffic.

Unlike routed mode, which requires an IP address for each interface, a transparent firewall has an IP address assigned to the entire device.

The transparent security appliance uses an inside interface and an outside interface only. If your platform includes a dedicated management interface, you can also configure the management interface or subinterface for management traffic only.

For multiple context mode, each context must use different interfaces; you cannot share an interface across contexts.

When ASA firewall modes are changed (from routed to transparent and viceversa) the adaptive security appliance clears the configuration.

  •  Configuration


firewall transparent
interface BVI1
 ip address 192.168.1.3 255.255.255.0
interface GigabitEthernet0
 nameif inside
 bridge-group 1
 security-level 100
interface GigabitEthernet1
 nameif outside
 bridge-group 1
 security-level 0


The firewall will  forward frames based on destination MAC addresses.
In transparent mode like in routed mode the firewall will perform stateful inspection of the traffic that pass from the higher to lower security zone by default.
As exception some layer 2 traffic is permitted to move from the lower security zone.


  • Default allowed MAC Addresses
These destination MAC addresses are allowed by default through the transparent firewall. Any MAC address not on this list is dropped.

TRUE broadcast destination MAC address equal to FFFF.FFFF.FFFF
IPv4 multicast MAC addresses from 0100.5E00.0000 to 0100.5EFE.FFFF
IPv6 multicast MAC addresses from 3333.0000.0000 to 3333.FFFF.FFFF
BPDU multicast address equal to 0100.0CCC.CCCD
AppleTalk multicast MAC addresses from 0900.0700.0000 to 0900.07FF.FFFF

  • ARP inspection

By default, all ARP packets are allowed through the security appliance.
ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing)
ARP inspection ensures that an attacker cannot send an ARP response with the attacker MAC address, so long as the correct MAC address and the associated IP address are in the static ARP table.
ARP inspection compares ARP packets with static ARP entries in the ARP table.

arp inside 192.168.1.1 ca00.2ae2.001c

 To enable ARP inspection, enter the following command:
arp-inspection interface_name enable [flood | no-flood]
Where flood forwards non-matching ARP packets out all interfaces, and no-flood drops non-matching packets.

  • Ether-type Access List

In routed mode, some types of traffic cannot pass through the security appliance even if you allow it in an access list. Alternatively, the transparent firewall can allow any traffic through with either an extended access list (for IP traffic) or an EtherType access list (for non-IP traffic).

To allow any traffic with EtherTypes other than IPv4 and ARP, you need to apply an EtherType access list, even from a high security to a low security interface.
Because EtherTypes are connectionless, you need to apply the access list to both interfaces if you want traffic to pass in both directions.
access-list access_list_name ethertype {deny | permit} {ipx | bpdu | mpls-unicast | mpls-multicast | any | hex_number}

 any keyword specifies access to anyone.

bpdu keyword specifies access to bridge protocol data units, which are permitted by default.

deny keyword denies access if the conditions are matched. If an EtherType access list is configured to deny all, all ethernet frames are discarded. Only physical protocol traffic, such as auto-negotiation, is still allowed.

hex_number argument indicates any Ethertype that can be identified by a 16-bit hexadecimal number greater than or equal to 0x600. (See RFC 1700, "Assigned Numbers," for a list of EtherTypes.)

ipx keyword specifies access to IPX.

mpls-multicast keyword specifies access to MPLS multicast.

mpls-unicast keyword specifies access to MPLS unicast.

permit keyword permits access if the conditions are matched.





Tuesday, 5 March 2013

ASA MPF - QoS

The ASA supports the following QoS features:

  • Traffic shaping - configure the ASA to transmit packets at a fixed slower rate
  • Policing -  limit the maximum bandwidth used per flow
  • Priority queuing - for critical traffic that cannot tolerate latency, such as Voice over IP (VoIP), you can identify traffic for Low Latency Queuing (LLQ) so that it is always transmitted ahead of other traffic
A token bucket is a formal definition of a rate of transfer. It has three components: a burst size(Bc), an average rate(CIR), and a time interval. Although the average rate is generally represented as bits per second, any two values may be derived from the third by the relation shown as follows:

average rate = burst size / time interval

1. Traffic shaping

Traffic shaping must be applied to all outgoing traffic on a physical interface.
Traffic shaping is implemented when packets are ready to be transmitted on an interface, so the rate calculation is performed based on the actual size of a packet to be transmitted, including all the possible overhead such as the IPsec header and L2 header.
The shaped traffic includes both through-the-box and from-the-box traffic.

-create the policy-map

policy-map TRAFFIC_SHAPE
 class class-default
  shape average 512000

-apply the service-policy to one interface

service-policy TRAFFIC_SHAPE interface inside
-verify
ciscoasa(config)# show service-policy shape
Interface inside:
  Service-policy: TRAFFIC_SHAPE
    Class-map: class-default
      shape (average) cir 512000, bc 2048
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

2.Policing

-Define the traffic flows that you want to manipulate
access-list policing_http extended permit tcp any any eq www
class-map policing_traffic
match access-list policing_http

access-list ICMP extended permit icmp any any
class-map policing_ICMP
 match access-list ICMP


-create the policy-map 

policy-map policing_traffic
 class policing_traffic
  police output 56000
  police input 56000
 class policing_ICMP
  police input 8000
  police output 8000

-apply the service-policy to one interface or globaly

 service-policy policing_traffic interface outside
-verify 

ciscoasa(config-pmap-c)# show service-policy interface outside
Interface outside:
  Service-policy: policing_traffic
    Class-map: policing_traffic
      Output police Interface outside:
        cir 56000 bps, bc 1750 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps
      Input police Interface outside:
        cir 56000 bps, bc 1750 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps
    Class-map: policing_ICMP
      Input police Interface outside:
        cir 8000 bps, bc 1500 bytes
        conformed 20 packets, 21118 bytes; actions:  transmit
        exceeded 5 packets, 7570 bytes; actions:  drop
        conformed 0 bps, exceed 352 bps
      Output police Interface outside:
        cir 8000 bps, bc 1500 bytes
        conformed 58 packets, 30324 bytes; actions:  transmit
        exceeded 25 packets, 36398 bytes; actions:  drop
        conformed 0 bps, exceed 1696 bps

3.Priority queuing

The security appliance supports two kinds of priority queuing – standard priority queuing and hierarchical priority queuing

3.A Standard priority queuing

-Create the priority queue on the interface where you want to configure the standard priority queuing. 
This is done in global configuration mode with the priority-queue interface_name command. Notice this will place you in priority queue configuration mode where you can optionally manipulate the size of the queue with the queue-limit number_of_packets command. You can also optionally set the depth of the hardware queue with the tx-ring-limit number_of_packets command. Remember that the hardware queue forwards packets until full, and then queuing is handled by the software queue (composed of the priority and best effort queues).

priority-queue outside 
-Define the traffic flows that you want to manipulate

class-map priority_voice
 match dscp ef 

-create the policy-map 

policy-map priority_voice
 class priority_voice
  priority
-apply the service-policy to one interface  or globaly

service-policy priority_voice interface outside 

Traffic matching priority_voice class-map is serviced using priority queue. All other traffic will use the Best Effort queue. 
The priority queuing can be used only for outgoing packets.

-verify
ciscoasa(config)# show service-policy priority
Interface outside:
  Service-policy: priority_voice
    Class-map: priority_voice
      Priority:
        Interface outside: aggregate drop 0, aggregate transmit 0

3.B Priority queuing and policy queuing

You can also configure standard priority queuing and policing for different class maps within the same policy map.
-create the policy-map
priority-queue inside
policy-map QoS_TRAFFIC
 class priority_voice
  priority
 class policing_ICMP
  police input 16000
  police output 16000
-apply the policy-map to one interface or globaly
service-policy QoS_TRAFFIC interface inside
-verify
ciscoasa(config)# show service-policy interface inside
Interface inside:
  Service-policy: QoS_TRAFFIC
    Class-map: priority_voice
      Priority:
        Interface inside: aggregate drop 0, aggregate transmit 0
    Class-map: policing_ICMP
      Input police Interface inside:
        cir 16000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps
      Output police Interface inside:
        cir 16000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps
    Class-map: class-default

3.C Hierarchical priority queuing

This queuing approach allows you to shape traffic and allow a subset of the shaped traffic to be prioritized. 
With this approach, you do not configure a priority queue on the interface.

-Define the traffic flows that you want to manipulate
access-list ike extended permit udp any any eq isakmp
class-map voice_traffic
 match dscp ef
class-map ike
 match access-list ike
-create the priority policy-map 

policy-map priority_traffic
 class ike
  priority
 class voice_traffic
  priority

-create the hierachical policy-map

policy-map hierarchical_priority
 class class-default
  shape average 512000
  service-policy priority_traffic

-apply the service-policy to one interface
service-policy hierarchical_priority interface outside

-verify


ciscoasa(config)# show service-policy interface outside
Interface outside:
  Service-policy: hierarchical_priority
    Class-map: class-default
      shape (average) cir 512000, bc 2048
     
      (pkts output/bytes output) 0/0
      (total drops/no-buffer drops) 0/0
      Service-policy: priority_traffic
        Class-map: ike
          priority
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
        Class-map: voice_traffic
          priority
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
        Class-map: class-default
          Default Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

4.Supported feature combinations per interface

•Standard priority queuing (for specific traffic) + Policing (for the rest of the traffic).

You cannot configure priority queuing and policing for the same set of traffic.

•Traffic shaping (for all traffic on an interface) + Hierarchical priority queuing (for a subset of traffic).

You cannot configure traffic shaping and standard priority queuing for the same interface; only hierarchical priority queuing is allowed. For example, if you configure standard priority queuing for the global policy, and then configure traffic shaping for a specific interface, the feature you configured last is rejected because the global policy overlaps the interface policy.

Typically, if you enable traffic shaping, you do not also enable policing for the same traffic, although the ASA does not restrict you from configuring this.


Monday, 4 March 2013

ASA MPF - TCP traffic inspection/normalization


1. Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps

Example:access-list SSH extended permit tcp any any eq ssh class-map SSH match access-list SSH



2. Create the TCP-MAP

ciscoasa(config)# tcp-map TCP_NORMALIZATION
ciscoasa(config-tcp-map)# ?
TCP-map configuration commands:
  check-retransmission    Check retransmit data, disabled by default
  checksum-verification   Verify TCP checksum, disabled by default
  default                 Set a command to its defaults
  exceed-mss              Packet that exceed the Maximum Segment Size set by
                          peer, default is to allow packet
  invalid-ack             Packets with invalid ACK, default is to drop packet
  no                      Negate a command or set its defaults
  reserved-bits           Reserved bits in TCP header are set, default is to
                          allow packet
  seq-past-window         Packets that have past-window seq numbers, default is
                          to drop packet
  syn-data                TCP SYN packets that contain data, default is to
                          allow packet
  synack-data             TCP SYN-ACK packets that contain data, default is to
                          drop packet
  tcp-options             Options in TCP header
  ttl-evasion-protection  Protection against time to live (TTL) attacks,
                          enabled by default
  urgent-flag             Urgent flag and urgent offset set, default is to
                          clear flag and offset
  window-variation        Unexpected window size variation, default is to allow
                          connection

Example:

tcp-map TCP_NORMALIATION
  check-retransmission
  checksum-verification
  reserved-bits clear

3.Create the Layer 3/4 policy map

policy-map policy_inside
 class SSH
  set connection advanced-options TCP_NORMALIZATION

4.Apply the policy map using a service policy (global or at interface-level)

service-policy policy_inside interface outside 


ASA MPF - SMTP traffic inspection

1. Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps

access-list SERVER_SMTP permit tcp any host 10.1.1.2 eq 25
class-map SMTP_SERVER
 match access-list SERVER_SMTP


2. Create a inspection policy map in order to tune the SMTP engine inspection

Example: Mask SMTP server banner. Reject email sent from email addresses that contain any of the next string "porn.com" "online-game.com". Firewall should accept only email to addresses in domain "test.com".  Reject emails with more than 10 invalid-recipients.  Drop any e-mails that
have a body greater than 35,000 characters.

regex BANNED_EMAILS "(.*porn\.com|.*online-game\.com)"
policy-map type inspect esmtp SMTP_INSPECT
 parameters
  mail-relay test.com action drop-connection log
 match invalid-recipients count gt 10
  reset
 match sender-address regex BANNED_EMAILS
  reset
 match body length gt 35000
  drop-connection log

3.Create the Layer 3/4 policy map
Restrict number of the SMTP connection to 100. Set the number of half-opened (embryonic connection) for SMTP to 50.

policy-map policy_inside
 class SMTP_SERVER
  inspect esmtp SMTP_INSPECT
  set connection conn-max 100 embryonic-conn-max 50 

4.Apply the policy map using a service policy (global or at interface-level)

service-policy policy_inside interface inside 

Sunday, 3 March 2013

ASA MPF -FTP traffic inspection

1. Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps


class-map FTP match port tcp eq ftp

2. Create a inspection policy map in order to tune the FTP engine inspection

Example: Mask the FTP server banner; Mask the system information replay; Disallow the use of commands DELE and RMD; Deny download of .doc files.


regex TXT ".*\.txt"
regex ZIP ".*\.zip"
regex DOC ".*\.doc"
class-map type inspect ftp match-all DENIED_COMMANDS
 match request-command dele rmd
policy-map type inspect ftp FTP_INSPECT
 parameters
  mask-banner
  mask-syst-reply
 match filename regex DOC
  reset
 class DENIED_COMMANDS
  reset log



3.Create the Layer 3/4 policy map



policy-map policy_inside
 class FTP
  inspect ftp strict FTP_INSPECT 

4.Apply the policy map using a service policy (global or at interface-level)

service-policy policy_inside interface inside

5. Verification:

FTP output without traffic inspection


root@bt:~# ftp 192.168.223.129
Connected to 192.168.223.129.
220-FileZilla Server version 0.9.41 beta
220-written by Tim Kosse (Tim.Kosse@gmx.de)
220 Please visit http://sourceforge.net/projects/filezilla/

Name (192.168.223.129:root): test
331 Password required for test
Password:
230 Logged on
Remote system type is UNIX.
ftp> ls
200 Port command successful
150 Opening data channel for directory list.
-r--r--r-- 1 ftp ftp             22 Mar 03 21:45 configurations.zip
-r--r--r-- 1 ftp ftp          10752 Feb 02 13:38 test.doc
-r--r--r-- 1 ftp ftp             22 Mar 03 21:45 example1.txt
-r--r--r-- 1 ftp ftp             22 Mar 03 21:45 example2.txt
226 Transfer OK
ftp> 

Mask FTP banner and system information replay:

Connected to 192.168.223.129.
220-************************************
220-***************************************
220 *******************************************************

Name (192.168.223.129:root): test
331 Password required for test
Password:
230 Logged on
Remote system type is XXXXXXXXXXXXXXXXXXXXXXXXXX.
ftp>

t@bt:~# ftp 192.168.223.129

Deny DELE and RMD commands

ftp> dele example1.txt
421 Service not available, remote server has closed connection

%ASA-5-303005: Strict FTP inspection matched Class 21: DENIED_COMMANDS in policy-map FTP_INSPECT, Reset connection from inside:10.1.1.2/55339 to outside:192.168.223.129/21
%ASA-4-507003: tcp flow from inside:10.1.1.2/55339 to outside:192.168.223.129/21 terminated by inspection engine, reason - inspector reset unconditionally.
%ASA-6-302014: Teardown TCP connection 44 for outside:192.168.223.129/21 to inside:10.1.1.2/55339 duration 0:00:11 bytes 256 Flow closed by inspection

Deny download of .doc files

ftp> get test.doc
local: test.doc remote: test.doc
200 Port command successful
421 Service not available, remote server has closed connection

%ASA-6-302013: Built outbound TCP connection 46 for outside:192.168.223.129/20 (192.168.223.129/20) to inside:10.1.1.2/56273 (10.1.1.2/56273)
%ASA-6-302014: Teardown TCP connection 46 for outside:192.168.223.129/20 to inside:10.1.1.2/56273 duration 0:00:00 bytes 187 TCP FINs
%ASA-4-507003: tcp flow from inside:10.1.1.2/55340 to outside:192.168.223.129/21 terminated by inspection engine, reason - inspector reset unconditionally.
%ASA-6-302014: Teardown TCP connection 45 for outside:192.168.223.129/21 to inside:10.1.1.2/55340 duration 0:00:38 bytes 428 Flow closed by inspection
%ASA-6-302014: Teardown TCP connection 47 for outside:192.168.223.129/0 to inside:10.1.1.2/40729 duration 0:00:00 bytes 0 Parent flow is closed


Any other command works

ftp> get example2.txt
local: example2.txt remote: example2.txt
200 Port command successful
150 Opening data channel for file transfer.
226 Transfer OK
363 bytes received in 0.00 secs (747.9 kB/s)
ftp> 

ftp> put example3.txt
local: example3.txt remote: example3.txt
200 Port command successful
150 Opening data channel for file transfer.
226 Transfer OK
443 bytes sent in 0.00 secs (16022.9 kB/s)
ftp> 

ASA MPF - HTTP traffic inspection

1. Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps

access-list http_80 extended permit tcp any any eq www class-map httptraffic match access-list http_80

2. Create a inspection policy map in order to tune the http engine inspection

Example: Match URLs with domain name yahoo.com, facebook.com, youtube.com

regex domainlist1 "\.yahoo\.com"regex domainlist2 "\.facebook\.com"regex domainlist3 "\.youtube\.com"
class-map type regex match-any DomainBlockList
 match regex domainlist1
 match regex domainlist2
 match regex domainlist3
class-map type inspect http match-all BlockDomainsClass
 match request header host regex class DomainBlockList

3. Define the actions you want to perform on each Layer 3/4 class map by creating a Layer 3/4 policy map
Example: Inspect HTTP traffic. Reset TCP connection upon any HTTP protocol violation.Reset HTTP connection to URLs with domain name yahoo.com, faceboo.com, youtube.com.  Restrict number of the HTTP connection to 300. Reset the number of half-opened (embryonic connection) for HTTP to 50.

policy-map type inspect http http_inspection_policy
  parameters
  protocol-violation action drop-connection
  class BlockDomainsClass
    reset log
policy-map inside-policy
  class httptraffic
   inspect http http_inspection_policy
    set connection conn-max 300 embryonic-conn-max 50 

4.Apply the policy map using a service policy (global or at interface-level)

service-policy inside-policy interface inside


5. Verification:

ciscoasa#  show service-policy interface inside 
Interface inside:  Service-policy: inside-policy    Class-map: httptraffic      Inspect: http http_inspection_policy, packet 20678, drop 22, reset-drop 12      Set connection policy: conn-max 300 embryonic-conn-max 50         current embryonic conns 0, current conns 0, drop 0
ciscoasa#  show service-policy inspect http     
Interface inside:  Service-policy: inside-policy    Class-map: httptraffic      Inspect: http http_inspection_policy, packet 20678, drop 22, reset-drop 12        protocol violations          packet 2        class BlockDomainsClass          reset log, packet 12        class BLOCK_URL          reset log, packet 0
 ciscoasa# show logging
%ASA-6-302013: Built outbound TCP connection 10797 for outside:31.13.72.39/80 (31.13.72.39/80) to inside:10.1.1.2/56587 (192.168.223.150/56587)
%ASA-5-415008: HTTP - matched Class 22: BlockDomainsClass in policy-map http_inspection_policy, header matched - Resetting connection from inside:10.1.1.2/56587 to outside: 31.13.72.39/80
%ASA-5-304001: 10.1.1.2 Accessed URL 31.13.72.39:http://www.facebook.com/
%ASA-4-507003: tcp flow from inside:10.1.1.2/56587 to outside:31.13.72.39/80 terminated by inspection engine, reason - reset unconditionally.
%ASA-6-302014: Teardown TCP connection 10797 for outside:31.13.72.39/80 to inside:10.1.1.2/56587 duration 0:00:00 bytes 0 Flow closed by inspection


Friday, 1 March 2013

ASA MPF - general information

Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS, IPS, CSC, TCP normalization. to the traffic transiting the firewall.


Modular Policy Framework Features

Modular Policy Framework supports the following features:
•QoS input policing
•TCP normalization, TCP and UDP connection limits and timeouts, and TCP sequence number randomization
•CSC
•Application inspection
•IPS
•QoS output policing
•QoS standard priority queue
•QoS traffic shaping, hierarchical priority queue

Modular Policy Framework Configuration Overview

  1. Identify the traffic on which you want to perform Modular Policy Framework actions by creating Layer 3/4 class maps
  2. If one of the actions you want to perform is application inspection, and you want to perform additional actions on some inspection traffic, then create an inspection policy map
  3. If you want to match text with a regular expression within inspected packets, you can create a regular expression or a group of regular expressions (a regular expression class map). 
  4. Define the actions you want to perform on each Layer 3/4 class map by creating a Layer 3/4 policy map. 
  5. Determine on which interfaces you want to apply the policy map using a service policy.
  • Creating a Layer 3/4 Class Map
ASA1(config-cmap)# class-map TEST
ASA1(config-cmap)# match ?      
mpf-class-map mode commands/options:
  access-list                 Match an Access List
  any                         Match any packet
  default-inspection-traffic  Match default inspection traffic:
                              ctiqbe----tcp--2748      dns-------udp--53    
                              ftp-------tcp--21        gtp-------udp--2123,3386
                              h323-h225-tcp--1720      h323-ras--udp--1718-1719
                              http------tcp--80        icmp------icmp        
                              ils-------tcp--389       ip-options-----rsvp  
                              mgcp------udp--2427,2727 netbios---udp--137-138
                              radius-acct----udp--1646 rpc-------udp--111    
                              rsh-------tcp--514       rtsp------tcp--554    
                              sip-------tcp--5060      sip-------udp--5060  
                              skinny----tcp--2000      smtp------tcp--25    
                              sqlnet----tcp--1521      tftp------udp--69    
                              waas------tcp--1-65535   xdmcp-----udp--177    
  dscp                        Match IP DSCP (DiffServ CodePoints)
  flow                        Flow based Policy
  port                        Match TCP/UDP port(s)
  precedence                  Match IP precedence
  rtp                         Match RTP port numbers
  tunnel-group                Match a Tunnel Group

A typical class map will only support one match command. The only exception is the use of match tunnel-group along with some other match commands.
  •  Creating a Layer 3/4 Policy Map
ASA1(config)# policy-map TEST
ASA1(config-pmap)# class TEST
ASA1(config-pmap-c)# ?
MPF policy-map class configuration commands:
  exit             Exit from MPF class action configuration mode
  help             Help for MPF policy-map class/match submode commands
  no               Negate or set default values of a command
  police           Rate limit traffic for this class
  priority         Strict scheduling priority for this class
  quit             Exit from MPF class action configuration mode
  service-policy   Configure QoS Service Policy
  set              Set connection values
  shape            Traffic Shaping
  user-statistics  configure user statistics for identity firewall
  csc              Content Security and Control service module
  flow-export      Configure filters for NetFlow events
  inspect          Protocol inspection services
  ips              Intrusion prevention services
  • Creating an Inspection Policy Map
Modular Policy Framework lets you configure special actions for many application inspections.
Used to tune the inspect engine parameters.
ASA1(config)# policy-map type inspect ?
configure mode commands/options:
  dcerpc             Configure a policy-map of type DCERPC
  dns                Configure a policy-map of type DNS
  esmtp              Configure a policy-map of type ESMTP
  ftp                Configure a policy-map of type FTP
  gtp                Configure a policy-map of type GTP
  h323               Configure a policy-map of type H.323
  http               Configure a policy-map of type HTTP
  im                 Configure a policy-map of type IM
  ip-options         Configure a policy-map of type IP-OPTIONS
  ipsec-pass-thru    Configure a policy-map of type IPSEC-PASS-THRU
  ipv6               Configure a policy-map of type IPv6
  mgcp               Configure a policy-map of type MGCP
  netbios            Configure a policy-map of type NETBIOS
  radius-accounting  Configure a policy-map of type Radius Accounting
  rtsp               Configure a policy-map of type RTSP
  sip                Configure a policy-map of type SIP
  skinny             Configure a policy-map of type Skinny

An inspection policy map consists of one or more of the following elements.
                   -Traffic matching command
                   -Inspection class map
                   -Parameters
ASA1(config)# policy-map type inspect http TEST_HTTP
ASA1(config-pmap)# ?
MPF policy-map configuration commands
  class        Policy criteria
  match        Specify policy criteria via inline match
  parameters   Specify this keyword to enter policy parameters.
The action that can be applied to an inspection policy map 
  drop-connection  Drop connection
  log              Generate a log message
  reset            Close connection with a TCP reset message

When you enable an inspection engine in the Layer 3/4 policy map, you can also optionally enable actions as defined in an inspection policy map
ASA1(config)# policy-map TEST
ASA1(config-pmap)# class TEST
ASA1(config-pmap-c)# inspect http TEST_HTTP

You can specify multiple class or match commands in the policy map
  • Applying Actions to an Interface 
To activate the Layer 3/4 policy map, create a service policy and applies it to one or more interfaces or  applies it globally to all interfaces
ASA1(config)# service-policy TEST interface inside
  • Default Layer 3/4 Class Maps
class-map inspection_default
 match default-inspection-traffic
class-map class-default
 match any

  • Default Layer 3/4 Policy Map
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp 


  • Default Inspection Policy Map

 policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512

  • Default service-policy (global service-policy)

 service-policy global_policy globalservice-policy global_policy global
  • List of application priorities
The inspection action with higher priority will be preferred in case of conflict
  1. CTIQBE
  2. DNS
  3. FTP
  4. GTP
  5. H323
  6. HTTP
  7. ICMP
  8. ICMP error
  9. ILS
  10. MGCP
  11. NetBIOS
  12. PPTP
  13. Sun RPC
  14. RSH
  15. RTSP
  16. SIP
  17. Skinny
  18. SMTP
  19. SNMP
  20. SQL*Net
  21. TFTP
  22. XDMCP
  23. DCERPC
  24. Instant Messaging
Conflict cases:
  • packet/flow matches multiple classes within the same policy-map
-For a given feature type, the flow can match only one class, based on the order the classes are configured in the policy map.

-For different feature type feature actions from all classes are combined

  • packet/flow matches multiple classes in multiple policy-map (interface and global)
-For a given feature type, the flow can match only the class configured at interface-level.

-For different feature type feature actions from all classes (configured at interface-level and at global-level) are combined

-if traffic match classes at ingress and egress interfaces the action depends on traffic type (statefull vs stateless).