Direction of VLAN interface ACL

Root user and password in Ubuntu

By default, Ubuntu has a root password set as a hash. Sometimes, you can make a mistake, for example, remove your account from the group that allowed to use sudo. In a such cases, it's useful to have an access to the root user itself.
To set root password manually we should type in the shell:
sudo passwd

Assigning restrictions to logon locally, accessing computers from the network and other interesting user permissions on Windows

Today's task was to secure access to the Microsoft Windows 2008 server using GPO. That's an interesting topic to play with because there is a lot of different combinations exists to accomplish this. A combination of local and domain policies, NTFS permissions can be used. Here I will try to post a conclusions that arised after this work.
First of all I would like to talk about NTFS permission named "Traverse Folder". That's a very interesting permission because it allows us to tighten security to a highest level. Let's make an example. Let's say we want to access a folder under the following path: "C:\lala\dada\KEY". For user "Tony" to access folder "KEY" he has to have NTFS permissions for it, but not only for it. What about parent folders? In fact, he has to have a "Traverse Folder" permission on all the parent folders to access "KEY" folder. So we should modify all the parent folders permissions to give "Tony" access to "KEY"? Not at all. By default, GPO assign the following "User Right": "Bypass Traverse Checking" to "Administrators, Backup Operators, Users, Everyone, Local Service and Network Service" on workstations and servers and "Administrators, Authenticated Users, Everyone, Local Service, Network Service and Pre-Windows 2000 Compatible Access" on Domain Controllers.
This is the link to Microsoft support article that describes different incompatibilities that may appear after wrong modification of critical user rights like "Allow logon locally", "Access this computer from the network" etc.

Firestarter - another great GUI front-end to iptables

We can use apt-get install firestarter to get firestarter running. After startup wizard, our rules will be imported to the iptables. Even if firestarter's gui isn't running, firewall is actually working so we don't have to worry about it.
We can check firewall status by running:

sudo /etc/init.d/firestarter status

By default, GUI won't be started after computer reboot.
To override this, we should make a simple configuration changes to some files.
First of all, we need to add Firestarter to System - Preferences - Startup Applications. The add an entry stating:  

sudo firestarter --start-hidden

However, the password have to be specified to run this command, because it runs with root privileges. Moreover, we can't specify the password since this is logging script, so it just won't work at all. To get it working, we should edit /etc/sudoers file with any text editor or via sudo visudo command which is preferable.Then add the following line to the end of the file or it won't work:

[username] ALL=NOPASSWD: /usr/sbin/firestarter

That's it! Now are done and can start using firewall!

P.S. It's not recommended to start GUI automatically on system startup since it's a security breach.
P.P.S. Uninstalled it  after 1 day of using. Allows only 2 network interfaces to be configured as local or outside, making other interfaces to work improperly. For example, pings won't be allowed from those unconfigured interfaces at all. Maybe more inconveniences are present, but I haven't tested it any further. Moreover, after removing the Firestarter, ufw stopped working and I had to install Firestarter back and then remove it completely with apt-get remove purge command. It didn't heal ufw, so I had to completely remove it too and then install it back. Sounds ugly, isn't it?

UFW - simply great firewall for Linux

UFW is a very simple and powerful firewall which allows us to configure our policies in minutes!
Moreover, it allows us to configure forwarding traffic between interfaces and even NAT!
We can check UFW status by typing sudo ufw status or even just sudo ufw to see the list of available options.
By default, all outbound traffic is permitted. UFW is stateful firewall, so it tracks connections via maintaining connection table. Returning traffic permitted to pass through the firewall only if corresponding connection is in the table. Or simply, traffic allowed to return only if connection were originated from the inside network.
To open ports in the firewall, so inbound connections can be allowed, we have to add the rules. It's simple:

sudo ufw allow port number[/tcp|udp]

or 

sudo ufw deny port number[/tcp|udp] to block open ports.

To disable logging we can execute

sudo ufw logging off

Here are steps to configure routing and NAT.

First, packet forwarding need to be enabled.
We need to modify 2 configuration files:
1.  /etc/default/ufw change DEFAULT_FORWARD_POLICY to "ACCEPT".
2.  /etc/ufw/sysctl.conf uncomment /net/ipv4/ip_forward=1
After previous steps our Linux machine will begin to forward packets between it's interfaces!
Only NAT configuration left and it pretty straightforward.
We need to add rules to the /etc/ufw/before.rules file. We need to add the following string right to the top of the file after the header comments:

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

To enable Port Forwarding, also add the following string before COMMIT keyword. If ports to be forwarded are different on NAT device and destination then simply add :[portNumber]

-A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to 192.168.139.101:[portNumber]

Of course, ip networks and interface names should be replaced with appropriate. eth0 in this example is our outside interface on which translation will be performed. 192.168.0.0/24 subnet is our internal subnet which requires translation.
Only restarting the firewall left.

sudo ufw disable && sudo ufw enable

Securing Switch Access

If an interface is undergoing the restrict or protect condition, we might need to clear the learned MAC addresses so that a specific host can use the switch port. We can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security dynamic [address mac-addr | interface type mod/num]

Checking port states:

show port-security interface

show interfaces status err-disabled

show port-security

=================================================

Steps to enable dot1x authentication:

Switch(config)# aaa new-model

Switch(config)# radius-server host {hostname | ip-address} [key string]

Switch(config)# aaa authentication dot1x default group radius

Switch(config)# dot1x system-auth-control

Switch(config)# interface type mod/num
Switch(config-if)# dot1x port-control {force-authorized | forceunauthorized | auto}

Here, the 802.1x state is one of the following:
force-authorized—The port is forced to always authorize any connected client. No authentication is necessary. This is the default state for all switch ports when 802.1x is enabled.
force-unauthorized—The port is forced to never authorize any connected client. As a result, the port cannot move to the authorized state to pass traffic to a connected client.
auto—The port uses an 802.1x exchange to move from the unauthorized to the authorized state, if successful. This requires an 802.1x-capable application on the client PC.

If the switch should expect to find multiple hosts present on the switch port, use the following interface configuration command:

Switch(config-if)# dot1x host-mode multi-host

Verifying dot1x operations:

show dot1x all

=================================================

DHCP Snooping
When DHCP snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports. A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the Errdisable state. DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

Configuration:

Switch(config)# ip dhcp snooping

Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]

By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies.

Switch(config)# interface type mod/num 

Switch(config-if)# ip dhcp snooping trust 

For untrusted ports, an unlimited rate of DHCP requests is accepted. If we want to rate-limit DHCP traffic on an untrusted port, use the following interface configuration command: 

Switch(config)# interface type mod/num  

Switch(config-if)# ip dhcp snooping limit rate rate

DHCP option-82 feature is enabled by default. We can enable or disable option-82 globally with the following configuration command:
Switch(config)# [no] ip dhcp snooping information option

Verifying:
Switch# show ip dhcp snooping [binding]
We can use the binding keyword to display all the known DHCP bindings that have been overheard.

Example:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 104
Switch(config)# interface range fastethernet 0/35 – 36
Switch(config-if)# ip dhcp snooping limit rate 3
Switch(config-if)# interface gigabitethernet 0/1
Switch(config-if)# ip dhcp snooping trust

IP Source Guard
IP Source Guard works by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP. Packets arriving on a switch port can be tested for one of the following conditions:
■ The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port ACL is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
■ The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.
If the address is something other than the one learned or statically configured, the switch drops the packet.

For the hosts that do not use DHCP, you can configure a static IP source binding with the following configuration command:
Switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type mod/num
Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface. 

Next, enable IP source guard on one or more switch interfaces with the following configuration commands:

Switch(config)# interface type mod/num

Switch(config-if)# ip verify source [port-security]

Verify the IP source guard status:
Switch# show ip verify source [interface type mod/num]

Dynamic ARP Inspection
When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database.
If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP caches.
We can configure DAI by first enabling it on one or more client VLANs with the following configuration command:
Switch(config)# ip arp inspection vlan vlan-range 
By default, all switch ports associated with the VLAN range are considered to be untrusted. We should identify trusted ports as those that connect to other switches.
Switch(config)# interface type mod/num
Switch(config-if)# ip arp inspection trust

If we have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, we can configure an ARP access list that defines static MAC-IP address bindings that are permitted:
Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log]
[Repeat the previous command as needed]
Switch(config-acl)# exit
Now the ARP access list must be applied to DAI with the following configuration command:
Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

Finally, we can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This doesn’t take the actual MAC addresses contained in the Ethernet header of the ARP reply. To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following configuration command:
Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Verification:

show ip arp inspection 

 

Interesting facts about ASA

In today's lab I found out quite a few interesting facts about ASA security algorithms.
Sample lab topology:

 MyHostComputer:
Adapter1 - XX.XX.XX.XX/24 - Internet
Adapter1 - 192.168.137.1/24 - bridged to ASA and CorporateHost
Adapter2 - 192.168.138.1/24 - bridged to RemoteClient

CorporateHost:
Adapter1 - 192.168.137.195/24 - VMware bridged interface
Loopback1 - 192.168.255.100 - bridged to ASA. Default gateway of host 192.168.255.254

ASA:
Ethernet0/0 - 192.168.137.254/24 - Outside interface
Ethernet0/1 - 192.168.255.254/24 - Inside interface

ASA config:

nat (outside) 0 access-list REMOTE_NAT0_ACL
nat (outside) 1 access-list REMOTE_NAT_ACL
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 access-list NAT1_ACL
global (outside) 1 interface
access-list REMOTE_NAT_ACL extended permit ip 192.168.200.0 255.255.255.0 any
access-list REMOTE_NAT0_ACL extended permit ip 192.168.200.0 255.255.255.0 192.168.255.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 192.168.255.0 255.255.255.0 remote_protected 255.255.255.0
access-list inside_nat0_outbound extended permit ip any 192.168.200.0 255.255.255.0
access-list outside_1_cryptomap extended permit ip 192.168.255.0 255.255.255.0 remote_protected 255.255.255.0
access-list NAT1_ACL extended permit ip 192.168.255.0 255.255.255.0 any
access-list INBOUND_PERMIT extended permit icmp host boss any
access-group INBOUND_PERMIT in interface outside

That is our initial data.

If you will take a closer look, you will notice that inbound pings are permitted through the appliance to the internal hosts. However, if I try to ping 192.168.255.100 from 192.168.137.1, I'm getting syslog message:
2010-02-20 12:30:47    Local4.Error    192.168.255.254    Feb 20 2010 12:30:50 192.168.255.254 : %ASA-3-305005: No translation group found for icmp src outside:boss dst inside:192.168.255.100 (type 8, code 0)
Well, why? There is no nat-control command in running config, inbound icmp are permitted. And message states, that no translation group for icmp. This is point to a decision that the problem is related to NAT, isn't it?
As I found out, the problem was related to ASA security algorithms. ASA is smart enough to understand, that packet is coming inbound, so the reply will come from inside interface to outside and PAT will be performed (be default, ASA doesn't track icmp connection in it's connections table). It means that the outbound packet (coming from inside to outside) will have it source address translated to IP address of outside interface of ASA (PAT). It means that host 192.168.137.1 will receive icmp reply from different address in contrast to address it was pinging. So it will drop the packet. So this process is totally useless and ASA decides to drop the packet as it first comes as icmp echo request. For pings to be successful, we need to add one more translation rule to NAT. Namely Identity NAT (NAT 0). That way the echo reply source address won't be translated as it goes through the ASA and will not be dropped by receiving host.
Therefore, to make it all works, we should add one more ACL:

access-list inside_nat0_outbound extended permit ip 192.168.255.0 255.255.255.0 host boss

ASA ambiguities

ACL's:

• For a standard ACL, the addresses or networks you enter are addresses that the remote is trying to reach (destination addresses). Instead of source addresses as it is at IOS.

• Network mask is used in ASA ACL's instead of wildcard masks at IOS.

VPN with NAT-Traversal

I'm going to talk about an issue that arise when you are trying to setup Remote Access VPN for devices behind the NAT/PAT. For the IPsec tunnel to be negotiated, first there is an ISAKMP connection has to be established. It uses UDP on port 500. That means, that PAT device must be configure with port forwarding to VPN device on UDP port 500. That is about ISAKMP. When both ISAKMP phases are negotiated and ISAKMP connection are established, it's time to establish IPsec tunnel. Let's assume, that we are using ESP encapsulation for our IPsec. ESP is a network layer protocol, os it doesn't contain any layer 4 headers with port numbers. But somehow PAT device has to translate these connections. It is done through using of NAT-Traversal or IPsec over TCP. NAT-Traversal encapsulate ESP packet in a UDP header with destination port 4500. So to get VPN working, we have to configure port forwarding on our PAT device with redirection of both UDP port 500 and 4500. The same thing can be accomplished with IPsec over TCP, but with IPsec over TCP we have an ability to change ports on with our tunnels will be established.

P.S. AH can't be used along with PAT devices on it's way, because MD5 hash that it generates, include IP headers, which means, that changing them will completely brake the hash and the packet will be discarded on recieving device. For example, ESP doesn't calculate hash of the whole packet. Instead, it calculate it for payload only. So ESP is a protocol of my choice. Why do someone should use AH these days anyway?

Split tunneling defines what traffic from the user must go across the tunnel and what traffic can leave the client in clear text. Split tunneling policies are defined with the split-tunnel-policy command. The default split-tunneling policy is tunnelall, which means that, with the exception of DHCP and ARP packets, all traffic from the remote must go across the tunnel. You can exclude networks from being tunneled (excludespecified parameter) or include networks that should only be tunneled (tunnelspecified parameter). When overriding the default split tunneling policy, you must use the split-tunnel-networklist command to specify what destination networks are (tunnelspecified) or are not tunneled (excludespecified). These are defined in an extended or standard ACL. For a standard ACL, the addresses or networks you enter are addresses that the remote is trying to reach (destination addresses). For an extended ACL, the addresses off of the higher-level interface of the appliance (corporate office networks) are the source addresses in an ACL statement, and the destination addresses are the internal addresses of the remotes.

Sounds stupid. I should test it.

ASA translation policy order

When looking for a matching translation policy, the appliance goes through the following steps:
1. The appliance looks for an existing translation in the translation table; sometimes Cisco will refer to this as trying to find a “matching xlate slot” in the translation table.
2. If no entry exists in the translation table, the appliance looks for address translation exceptions in the nat 0 commands on a best-match basis.
3. If there are no matches on the Identity NAT commands, the appliance will try to find a match against the configured static NAT commands based on a best-match basis.
4. If there are no matches on the static NAT commands, the appliance will try to find a match against the configured static PAT (PAR) policies on a best match basis.
5. If no match is found within the PAR translation policies, the appliance then looks for a match in its policy nat and global commands with a corresponding ACL.
6. If there is not a match on a policy translation configuration, the appliance then looks for a match in its normal nat and global commands.
7. If a translation or translation policy doesn’t exist for the packet, the appliance will drop the packet if NAT control is enabled; if NAT control is not enabled, then the packet is not translated, but can flow through the appliance, assuming other appliance policies allow it.

SysLog

Logging Facilities
When syslog messages are sent to a server, it is important to indicate through which pipe the Security Appliance will send the messages. The single syslog service, syslogd, can be thought of as having multiple pipes. It uses the pipes to decide where to send incoming information based on the pipe through which the information arrives. Syslogd is a daemon/service that runs on UNIX machines. In this analogy, the logging facilities are the pipes by which syslogd decides where to send information it receives—that is, to which file to write. Eight logging facilities (16 through 23) are commonly used for syslog on the Cisco Security Appliance. On the syslog server, the facility numbers have a corresponding identification— local0 to local7. The following are the facility numbers and their corresponding syslog identification:
■ local0 (16)
■ local1 (17)
■ local2 (18)
■ local3 (19)
■ local4 (20)
■ local5 (21)
■ local6 (22)
■ local7 (23)
The default facility is local4 (20). To change the default logging facility on the Security Appliance, you use the logging facility facility command. The following command shows the logging facility changed to 21:
Pix(config)# logging facility 21

Logging Levels
Different severity levels are attached to incoming messages. You can think of these levels as
indicating the type of message. A Security Appliance can be configured to send messages at
different levels.

The lower the level number, the more severe the syslog message. The default severity level is 3 (error).
The level you specify causes the Cisco Security Appliance Firewall to send the messages of that level and below to the output location. For example, if you specify severity level 3 (error), a Security Appliance, such as the PIX, sends severity level 0 (emergency), 1 (alert), 2 (critical), and 3 (error) messages to the output location.

Configuring a Syslogd Server
Because syslogd was originally a UNIX concept, the features available in the syslogd products on non-UNIX systems depend on the vendor implementation. Features might include dividing incoming messages by facility or debug level or both, resolving the names of the sending devices, and reporting facilities. For information on configuring the non-UNIX syslog server, refer to the vendor’s documentation.

To configure syslog on UNIX, follow these steps:
Step 1 On SunOS, AIX, HPUX, or Solaris, as root, make a backup of the /etc/ syslog.conf file before modifying it.
Step 2 Modify /etc/syslog.conf to tell the UNIX system how to sort out the syslog messages coming in from the sending devices—that is, which logging-facility.level goes in which file. Make sure there is a tab between the logging-facility.level and file-name.
Step 3 Make sure the destination file exists and is writable.
Step 4 The #Comment section at the beginning of syslog.conf usually explains the syntax for the UNIX system.
Step 5 Do not put file information in the ifdef section.
Step 6 As root, restart syslogd to pick up changes.
For example, if /etc/syslog.conf is set for local7.warn /var/log/local7.warn
warning, error, critical, alert, and emergency messages coming in on the local7 logging facility are logged in the local7.warn file. Notification, informational, and debug messages coming in on the local7 facility are not logged anywhere.

Configuration for RADIUS authentication

That is it.

aaa new-model
!
!
aaa authentication login default group radius local
aaa authorization exec default local group radius

!

radius-server host 192.168.137.195 auth-port 1812 acct-port 1813 key 7 13061E010803

ASA Site-to-Site IPsec VPN

Today, I would like to write about the simplest configuration of ASA for Site-to-Site IPsec VPN.
I'm going to post configuration example along with comments about every particular command.

!--- Configure the outside interface.
!interface Ethernet0/1
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0 
!--- Configure the inside interface.
!interface Ethernet0/2
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0 
!-- Output suppressed
!passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
 domain-name default.domain.invalid

access-list 100 extended permit ip any any
access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 
10.20.10.0 255.255.255.0 
!--- This access list (inside_nat0_outbound) is used 
!--- with the nat zero command. This prevents traffic which 
!--- matches the access list from undergoing network address translation (NAT).
!--- The traffic specified by this ACL is traffic that is to be encrypted and
!--- sent across the VPN tunnel.  This ACL is intentionally 
!--- the same as (outside_1_cryptomap).
!--- Two separate access lists should always be used in this configuration. 

access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 

10.20.10.0 255.255.255.0
!--- This access list (outside_cryptomap) is used 
!--- with the crypto map outside_map 
!--- to determine which traffic should be encrypted and sent 
!--- across the tunnel.
!--- This ACL is intentionally the same as (inside_nat0_outbound).  
!--- Two separate access lists should always be used in this configuration.pager lines 24
mtu inside 1500
mtu outside 1500
no failover
asdm image disk0:/asdm-613.bin
asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 10.10.10.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
!--- NAT 0 prevents NAT for networks specified in 
!--- the ACL inside_nat0_outbound.
access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 172.16.1.2 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
http server enable
http 0.0.0.0 0.0.0.0 dmz
no snmp-server location
no snmp-server contact
!--- PHASE 2 CONFIGURATION ---!
!--- The encryption types for Phase 2 are defined here. 

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
!--- Define the transform set for Phase 2.

 crypto map outside_map 1 match address outside_1_cryptomap
!--- Define which traffic should be sent to the IPsec peer.
crypto map outside_map 1 set peer 172.17.1.1
!--- Sets the IPsec peer

crypto map outside_map 1 set transform-set ESP-DES-SHA
!--- Sets the IPsec transform set "ESP-AES-256-SHA"
!--- to be used with the crypto map entry "outside_map".

 crypto map outside_map interface outside
!--- Specifies the interface to be used with 
!--- the settings defined in this configuration. 

!--- PHASE 1 CONFIGURATION ---!
!--- This configuration uses isakmp policy 10.   
!--- The configuration commands here define the Phase 
!--- 1 policy parameters that are used. 

crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption des
 hash sha
 group 1
 lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
!
tunnel-group 172.17.1.1 type ipsec-l2l
!--- In order to create and manage the database of connection-specific 
!--- records for ipsec-l2l—IPsec (LAN-to-LAN) tunnels, use the command
!--- tunnel-group in global configuration mode.
!--- For L2L connections the name of the tunnel group MUST be the IP 
!--- address of the IPsec peer. 

tunnel-group 172.17.1.1 ipsec-attributes
 pre-shared-key *
!--- Enter the pre-shared-key in order to configure the 
!--- authentication method.

Dividing traffic for NAT'ing and for any type of VPN's.

Access-lists have to divide traffic for NAT'ing. Then they can be applied for NAT as a route-map or source list.
As I got it, top lines should deny traffic with private source and private destination and bottom lines should permit traffic with private source and any destination.
Example:

access-list 100 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 100 deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 100 deny ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255

.....

access-list 100 permit ip 192.168.10 0.0.0.255 any

By the way, this is good example for summarization. If private subnets can be summarized, it will be easier to define access-list and it will be much shorter.

VPN using Virtual Tunnel Interface (VTI) with IP Security (IPSec)

I'm going to speak about two different ways to configure IPsec VPN's. The first way is to configure VPN using traditional crypto map's and the second one is to implement Virtual Tunnel Interfaces(VTI). VTI, actually, is a better and newer way to design VPN. The question is - is it compatible with non-Cisco devices?
The are several important advantages of VTI:

• Ability to send multicast across VPN;
• Dynamic routing;
• Ability to apply QoS to traffic going through the tunnel;
• Easier to configure of ZFW, because Tunnel interface can be a member of any security zone. Thus, providing more easier and granular configuration of traffic inspections;

Configuration examples.
First one is traditional VPN:

=================================================

crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
 lifetime 1800
crypto isakmp key 12345 address 55.104.78.135

!
crypto ipsec transform-set branch_transform esp-aes 256 esp-sha-hmac
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
 description Tunnel to55.104.78.135
 set peer 55.104.78.135
 set transform-set branch_transform
 match address 100
!
interface FastEthernet0/0
 ip address 95.104.78.135 255.255.255.0
 duplex auto
 speed auto
 crypto map SDM_CMAP_1

!
access-list 100 remark IPSec Rule
access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

=================================================

The second one is using VTI:
=================================================
crypto isakmp policy 1

 encr aes 256

 authentication pre-share

 group 2

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

crypto isakmp keepalive 10 periodic

!

!

crypto ipsec transform-set S2S_TS esp-aes 256 esp-sha-hmac

!

crypto ipsec profile FOO_IPSEC_PROFILE

 set transform-set S2S_TS

!

!

interface Loopback1

 ip address 192.168.30.1 255.255.255.0

!

interface Tunnel1

 ip address 192.168.20.2 255.255.255.0

 tunnel source FastEthernet0/0

 tunnel destination 95.104.78.135

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile FOO_IPSEC_PROFILE

!

interface FastEthernet0/0

 ip address 95.104.78.150 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet0/1

 ip address 192.168.137.70 255.255.255.0

 duplex auto

 speed auto

=================================================

As with all other tunnels, it's important to keep an accurate routing table, so the interesting traffic will be forwarded to the tunnel. 

Also, QoS can be applied to the tunnel.

==================

policy-map FOO
class class-default
shape average 128000

 !

interface Tunnel0

service-policy output FOO

==================

Commands for verification:

• show interfaces tunnel 1
• show crypto session detail 
• show policy-map interface tunnel 1 (displaying QoS policy, associated with tunnel)
  
• show ip route 

DoS protection with ZFW

When your router's DoS counters exceed the default or configured values, the router will reset one old half-open connection for every new connection that exceeds the configured max-incomplete or one-minute high values, until the number of half-open sessions drops below the max-incomplete low values. The router will send a syslog message if logging is enabled, and if an intrusion prevention system (IPS) is configured on the router, the firewall router will send a DoS signature message via Security Device Event Exchange (SDEE). If the DoS parameters are not adjusted to your network's normal behavior, normal network activity may trigger the DoS protection mechanism, causing application failures, poor network performance, and high CPU utilization on the Cisco IOS Firewall router.

 Zone-Policy Firewall provides protection from DoS attack by default when a Zone-Policy Firewall is applied. The DoS protection is enabled on the zone-pair, in the direction in which the firewall is applied, for each class-map that the firewall policy is configured to inspect. DoS protection is only applied to network traffic if the inspect action is applied to traffic matching the class-map. Zone-Policy Firewall provides several adjustable values to protect against DoS attacks.

While you cannot "disable" your firewall's DoS protection, you can adjust the DoS protection so that it will not take effect unless a very large number of half-open connections are present in your firewall router's session table.

Follow this procedure to tune your firewall's DoS protection to your network's activity:

1. Be sure your network is not infected with viruses or worms that could lead to erroneously large half-open connection values and attempted connection rates. If your network is not a "clean slate," there is no way to properly adjust your firewall's DoS protection.

2. Define a parameter-map and set the max-incomplete high values to very high values:

parameter-map type inspect DoS-param-map

 max-incomplete high 20000000

 one-minute high 100000000

 tcp max-incomplete host 100000 block-time 0

Apply the parameter-map to every class-map's inspection action:

policy-map type inspect z1-z2-pmap

 class type inspect my-cmap

 inspect DoS-param-map

Note: If your router is running Cisco IOS Software Release 12.4(11)T, you do not need to raise the default DoS Protection values, because they are already set to their maximum limits.

This will prevent the router from providing DoS protection for the time being while you observe your network's connection patterns. If you wish to leave DoS protection disabled, stop following this procedure now.

3. Clear the Cisco IOS Firewall statistics, using the following command:

clear zone-pair counter

4. Leave the router configured in this state for some time, perhaps as long as 24 to 48 hours, so you can observe the network's pattern over a full day's activity cycle. While the values are adjusted to very high levels, your network will not benefit from Cisco IOS Firewall or IPS DoS protection.

5. After waiting for some observation period, check the DoS counters with the following command. The parameters you must observe to tune your DoS protection are highlighted in bold text:

router#sh policy-map type inspect zone-pair priv-pub

 Zone-pair: priv-pub

Service-policy inspect : priv-pub-pol

 Class-map: priv-pub-cmap (match-all)

Match: access-group 111

Match: class-map match-any all-proto-cmap

 Match: protocol tcp

 24009 packets, 671569 bytes

 30 second rate 0 bps

 Match: protocol udp

 42403 packets, 3244932 bytes

 30 second rate 0 bps

 Match: protocol icmp

 6 packets, 240 bytes

 30 second rate 0 bps

 Inspect

 Packet inspection statistics [process switch:fast switch]

 tcp packets: [14239:726275]

 udp packets: [43748:1572372]

 icmp packets: [2:19]

 Session creations since subsystem startup or last reset 46282

 Current session counts (estab/half-open/terminating) [45:22:10]

 Maxever session counts (estab/half-open/terminating) [92:46:33]

Last session created 00:00:45

Last statistic reset never

Last session creation rate 1

Maxever session creation rate 270

Last half-open session total 0

 Class-map: class-default (match-any)

Match: any 

 Drop (default action)

80254 packets, 8678464 bytes

Note: If the software image installed in your router is not Cisco IOS Software Release 12.4(11)T or newer, you will not see the "maxever session creation rate" statistic in your "sh policy-map type inspect zone-pair" output.

6. Configure the parameter-map's "max-incomplete high" to a value 25 percent higher than your router's indicated maxever session count half-open value. A 1.25 multiplier offers 25 percent headroom above observed behavior.

For example:

Maxever session count (estab/half-open/terminating) [92:46:33]

46 * 1.25 = 58, thus, configure:

parameter-map type inspect DoS-param-map

 max-incomplete high 58

7. Configure "max-incomplete low" to the value your router displayed for its maxever session count half-open value.

For example:

Maxever session counts (estab/half-open/terminating) [92:46:33]

Thus, configure:

parameter-map type inspect DoS-param-map

 max-incomplete low 46

8. Cisco IOS Software Release 12.4(11)T introduced a new counter to track the maximum one-minute rate the router has reached since the last restart or statistic reset. If you have Cisco IOS Software Release 12.4(11)T or a newer software version, you may simply apply the "maxever session creation rate" value for the "one-minute low" value in your parameter map.

For example:

Maxever session creation rate 270

Thus, configure:

parameter-map type inspect DoS-param-map

 one-minute low 270

9. Configure the parameter-map's "max-incomplete high" to a value 25 percent higher than your router's indicated maxever session creation rate value. A 1.25 multiplier offers 25 percent headroom above observed behavior.

For example:

Maxever session creation rate 270

270 * 1.25 = 338 (after rounding), thus, configure:

parameter-map type inspect DoS-param-map

 one-minute high 338

12. You will need to define a value for "ip inspect tcp max-incomplete host" according to your understanding of your servers' capability.

13. Repeat this procedure for every inspect-type class-map contained within a policy-map that must have unique DoS protection requirements. As mentioned in Step 2 of this procedure, you may define one parameter that has very high DoS parameters for class-maps that will not need DoS protection, and use different parameter-maps for specific class-maps that need unique levels of DoS protection. If DoS protection is not required for a given policy-map's class-map's traffic, you should configure high limits for the DoS protection values, and apply the high limits to all relevant class-maps' inspection. If your router is loaded with Cisco IOS Software Release 12.4(11)T or later, the DoS protection is already effectively disabled through the default high DoS protection values.

14. Monitor your network's DoS protection activity. Ideally, you should use a syslog server and record occurrences of DoS attack detection. If detection happens very frequently, you may need to monitor and adjust your DoS protection parameters.

Defining granular policies.

Example how to create class-maps. First, we can specify class map with match-any statement and then combine it with access-list in second class-map along with match-all keyword to define policy for particular subnet/host:

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120

 The second class-map means: check  the match of both access-list and ANY of the protocol specified in first class-map.

ZFW L7 in-depth packet analysis

Application inspection can be applied on HTTP traffic to control unwanted use of HTTP’s service port for other applications such as IM, P2P file sharing, and tunneling applications that can redirect otherwise firewalled applications through TCP 80. 

First of all, we need to specify class-map for in-depth analysis headers inside HTTP, for example. 

! configure the actions that are not permitted
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation

Draw attention at http keyword in class-map definition. It specifies that it's not just a regular class map, but an HTTP traffic inspection map.
Then,

! define actions to be applied to unwanted traffic
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log

The part beyond is really important, because without it we won't be allowed to apply this class-map to a regular policy-map. We will apply it as service-policy to a regular policy-map. There is a http keyword in policy-map definition also.
Then, let's create standard http class-map:

! define class-map for stateful http inspection
class-map type inspect match-any http-cmap
 match protocol http

And after all of these, we can finally create our last policy-map:

! define policy-map, associate class-maps and actions
policy-map type inspect priv-pub-pmap
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap

I would like to say it once again - if we didn't associate first class-map with with policy-map (those, specified with http keyword), then it would be impossible to attach this class-map to a regular policy-map at the end.

Working example:

class-map type inspect match-any Int2Pub
 match protocol https
 match protocol dns
 match protocol icmp
class-map type inspect match-any http-cmap
 match protocol http
class-map type inspect http match-any http-aic-cmap
 match  request port-misuse any
 match  req-resp protocol-violation
!
!
policy-map type inspect http http-aic-pmap
 class type inspect http http-aic-cmap
  reset
  log
 class class-default
policy-map type inspect priv-pub-pmap
 class type inspect Int2Pub
  inspect
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap
 class class-default
!
zone security private
zone security public
zone-pair security Int2PubZone source private destination public
 service-policy type inspect priv-pub-pmap
!
interface FastEthernet0/0
 ip address 192.168.255.254 255.255.255.0
 zone-member security private
 !
interface FastEthernet0/1
 ip address 192.168.137.100 255.255.255.0
 zone-member security public

Zone-Based Firewall and Firewall concepts

Cisco IOS Classic Firewall stateful inspection (formerly known as Context-Based Access Control, or CBAC) employed an interface-based configuration model, in which a stateful inspection policy was applied to an interface. All traffic passing through that interface received the same inspection policy. This configuration model limited the granularity of the firewall policies and caused confusion of the proper application of firewall policies, particularly in scenarios when firewall policies must be applied between multiple interfaces.

Zone-Based Policy Firewall (also known as Zone-Policy Firewall, or ZFW) changes the firewall configuration from the older interface-based model to a more flexible, more easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. ZFW’s default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from stateful inspection’s model where traffic was implicitly allowed until explicitly blocked with an access control list (ACL). 

Rules For Applying Zone-Based Policy Firewall

Router network interfaces’ membership in zones is subject to several rules that govern interface behavior, as is the traffic moving between zone member interfaces:

• A zone must be configured before interfaces can be assigned to the zone.
  
• An interface can be assigned to only one security zone.
  
• All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
  
• Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
  
• In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.
  
• The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.
  
• Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.
  
• Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.
  
• If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
  
• From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).
  
• The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

A security zone should be configured for each region of relative security within the network, so that all interfaces that are assigned to the same zone will be protected with a similar level of security. For example, consider an access router with three interfaces:

• One interface connected to the public Internet
  
• One interface connected to a private LAN that must not be accessible from the public Internet
  
• One interface connected to an Internet service demilitarized zone (DMZ), where a Web server, Domain Name System (DNS) server, and e-mail server must be accessible to the public Internet
  

In this example, each zone holds only one interface. If an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone. Additionally, the hosts’ traffic to hosts in other zones is similarly affected by existing policies.
Typically, the example network will have three main policies:

• Private zone connectivity to the Internet
  
• Private zone connectivity to DMZ hosts
  
• Internet zone connectivity to DMZ hosts
  

Because the DMZ is exposed to the public Internet, the DMZ hosts might be subjected to undesired activity from malicious individuals who might succeed at compromising one or more DMZ hosts. If no access policy is provided for DMZ hosts to reach either private zone hosts or Internet zone hosts, then the individuals who compromised the DMZ hosts cannot use the DMZ hosts to carry out further attack against private or Internet hosts. ZFW imposes a prohibitive default security posture. Therefore, unless the DMZ hosts are specifically provided access to other networks, other networks are safeguarded against any connections from the DMZ hosts. Similarly, no access is provided for Internet hosts to access the private zone hosts, so private zone hosts are safe from unwanted access by Internet hosts.

Steps to configure ZFW:

1. Define zones.
   
2. Define zone-pairs.
   
3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair.
   
4. Define policy-maps to apply action to your class-maps’ traffic.
   
5. Apply policy-maps to zone-pairs.
   
6. Assign interfaces to zones. 
   
   

Configuring Zone-Based Policy Firewall Class-Maps:

Class-maps define the traffic that the firewall selects for policy application. Layer 4 class-maps sort the traffic based on these criteria listed here. These criteria are specified using the match command in a class-map:

• Access-group—A standard, extended, or named ACL can filter traffic based on source and destination IP address and source and destination port.
  
• Protocol—The Layer 4 protocols (TCP, UDP, and ICMP) and application services such as HTTP, SMTP, DNS, etc. Any well-known or user-defined service known to Port-Application Mapping can be specified.
  
• Class-map—A subordinate class-map that provides additional match criteria can be nested inside another class-map.
  
• Not—The not criterion specifies that any traffic that does not match a specified service (protocol), access-group or subordinate class-map will be selected for the class-map.
  

Class-maps can apply match-any or match-all operators to determine how to apply the match criteria. If match-any is specified, traffic must meet only one of the match criteria in the class-map. If match-all is specified, traffic must match all of the class-map’s criteria in order to belong to that particular class.

class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp 

HTTP traffic must encounter the match protocol http first to make sure the traffic is handled by the service-specific capabilities of HTTP inspection. If the match lines are reversed, so traffic encounters the match protocol tcp statement before it compares it to match protocol http, the traffic is simply classified as TCP traffic, and inspected according to the capabilities of the Firewall’s TCP Inspection component. This is a problem for certain services such as FTP, TFTP, and several multimedia and voice signaling services such as H.323, SIP, Skinny, RTSP, and others. These services require additional inspection capabilities to recognize the more complex activities of these services. So, more specific rules should by positioned before less specific.

Class-maps can apply an ACL as one of the match criteria for policy application. If a class-map’s only match criterion is an ACL and the class-map is associated with a policy-map applying the inspect action, the router applies basic TCP or UDP inspection for all traffic allowed by the ACL, except that which ZFW provides application-aware inspection. This includes (but not limited to) FTP, SIP, Skinny (SCCP), H.323, Sun RPC, and TFTP. If application-specific inspection is available and the ACL allows the primary or control channel, any secondary or media channel associated with the primary/control is allowed, regardless of whether the ACL allows the traffic.
If a class-map applies only ACL 101 as the match criteria, an ACL 101 appears as this:

access-list 101 permit ip any any

All traffic is allowed in the direction of the service-policy applied to a given zone-pair, and corresponding return traffic is allowed in the opposite direction. Therefore, the ACL must apply the restriction to limit traffic to specific desired types. Note that the PAM list includes application services such as HTTP, NetBIOS, H.323, and DNS. However, in spite of PAM’s knowledge of the specific application’s use of a given port, firewall only applies sufficient application-specific capability to accommodate the well-known requirements of the application traffic. Thus, simple application traffic such as telnet, SSH, and other single-channel applications are inspected as TCP, and their statistics are combined together in the show command output. If application-specific visibility into network activity is desired, you need to configure inspection for services by application name (configure match protocol http, match protocol telnet, etc.).

Compare the statistics available in the show policy-map type inspect zone-pair command output from this configuration with the more explicit firewall policy shown further down the page. This configuration is used to inspect traffic from a Cisco IP Phone, as well as several workstations that use a variety of traffic, which includes http, ftp, netbios, ssh, and dns:

class-map type inspect match-all all-private
 match access-group 101
!         
policy-map type inspect priv-pub-pmap
 class type inspect all-private
  inspect
 class class-default
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

While this configuration is easy to define and accommodates all traffic that originates in the private zone (as long as the traffic observes the standard, PAM-recognized destination ports), it provides limited visibility into service activity, and does not offer the opportunity to apply ZFW’s bandwidth and session limits for specific types of traffic. This show policy-map type inspect zone-pair priv-pub command output is the result of the previous simple configuration that uses only a permit ip [subnet] any ACL between zone-pairs. As you can see, most of workstation traffic is counted in the basic TCP or UDP statistics:

stg-871-L#show policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub
 
  Service-policy inspect : priv-pub-pmap
 
    Class-map: all-private (match-all)
      Match: access-group 101
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [413:51589]
        udp packets: [74:28]
        icmp packets: [0:8]
        ftp packets: [23:0]
        tftp packets: [3:0]
        tftp-data packets: [6:28]
        skinny packets: [238:0]
 
        Session creations since subsystem startup or last reset 39
        Current session counts (estab/half-open/terminating) [3:0:0]
        Maxever session counts (estab/half-open/terminating) [3:4:1]
        Last session created 00:00:20
        Last statistic reset never
        Last session creation rate 2
        Maxever session creation rate 7
        Last half-open session total 0
 
    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

By contrast, a similar configuration that adds application-specific classes provides more granular application statistics and control, and still accommodates the same breadth of services that was shown in the first example by defining the last-chance class-map matching only the ACL as the last chance in the policy-map:

class-map type inspect match-all all-private
 match access-group 101
class-map type inspect match-all private-ftp
 match protocol ftp
 match access-group 101
class-map type inspect match-any netbios
 match protocol msrpc
 match protocol netbios-dgm
 match protocol netbios-ns
 match protocol netbios-ssn
class-map type inspect match-all private-netbios
 match class-map netbios
 match access-group 101
class-map type inspect match-all private-ssh
 match protocol ssh
 match access-group 101
class-map type inspect match-all private-http
 match protocol http
 match access-group 101
!
policy-map type inspect priv-pub-pmap
 class type inspect private-http
  inspect
 class type inspect private-ftp
  inspect
 class type inspect private-ssh
  inspect
 class type inspect private-netbios
  inspect
 class type inspect all-private
  inspect
 class class-default!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

The more-specific configuration provides this substantial granular output for the show policy-map type inspect zone-pair priv-pub command:

stg-871-L#sh policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub

  Service-policy inspect : priv-pub-pmap

   Class-map: private-http (match-all)
    Match: protocol http
    Match: access-group 101
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [0:2193]

      Session creations since subsystem startup or last reset 731
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [0:3:0]
      Last session created 00:29:25
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 4
      Last half-open session total 0

   Class-map: private-ftp (match-all)
    Match: protocol ftp
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [86:167400]
      ftp packets: [43:0]

      Session creations since subsystem startup or last reset 7
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [2:1:1]
      Last session created 00:42:49
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 4
      Last half-open session total 0

   Class-map: private-ssh (match-all)
    Match: protocol ssh
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [0:62]

      Session creations since subsystem startup or last reset 4
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [1:1:1]
      Last session created 00:34:18
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 2
      Last half-open session total 0
 
   Class-map: all-private (match-all)
    Match: access-group 101
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [51725:158156]
      udp packets: [8800:70]
      tftp packets: [8:0]
      tftp-data packets: [15:70]
      skinny packets: [33791:0]

      Session creations since subsystem startup or last reset 2759
      Current session counts (estab/half-open/terminating) [2:0:0]
      Maxever session counts (estab/half-open/terminating) [2:6:1]
      Last session created 00:22:21
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 12
      Last half-open session total 0
 
   Class-map: class-default (match-any)
    Match: any 
    Drop (default action)
      4 packets, 112 bytes

Another added benefit of using a more granular class-map and policy-map configuration, as mentioned earlier, is the possibility of applying class-specific limits on session and rate values and specifically adjusting inspection parameters by applying a parameter-map to adjust each class’s inspection behavior.

Configuring Zone-Based Policy Firewall Policy-Maps

The policy-map applies firewall policy actions to one or more class-maps to define the service-policy that will be applied to a security zone-pair. When an inspect-type policy-map is created, a default class named class class-default is applied at the end of the class. The class class-default’s default policy action is drop, but can be changed to pass. The log option can be added with the drop action. Inspect cannot be applied on class class-default. 

Zone-Based Policy Firewall Actions

ZFW provides three actions for traffic that traverses from one zone to another:

• Drop—This is the default action for all traffic, as applied by the "class class-default" that terminates every inspect-type policy-map. Other class-maps within a policy-map can also be configured to drop unwanted traffic. Traffic that is handled by the drop action is "silently" dropped (i.e., no notification of the drop is sent to the relevant end-host) by the ZFW, as opposed to an ACL's behavior of sending an ICMP “host unreachable” message to the host that sent the denied traffic. Currently, there is not an option to change the "silent drop" behavior. The log option can be added with drop for syslog notification that traffic was dropped by the firewall.
  
• Pass—This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections or sessions within the traffic. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is useful for protocols such as IPSec ESP, IPSec AH, ISAKMP, and other inherently secure protocols with predictable behavior. However, most application traffic is better handled in the ZFW with the inspect action.
  
• Inspect—The inspect action offers state-based traffic control. For example, if traffic from the private zone to the Internet zone in the earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router permits return traffic sent from Internet-zone hosts in reply to private zone connection requests. Also, inspect can provide application inspection and control for certain service protocols that might carry vulnerable or sensitive application traffic. Audit-trail can be applied with a parameter-map to record connection/session start, stop, duration, the data volume transferred, and source and destination addresses.

Actions are associated with class-maps in policy-maps:

conf t
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Parameter-maps offer options to modify the connection parameters for a given class-map’s inspection policy.

Configuring Zone-Policy Firewall Parameter-Maps

Parameter-maps specify inspection behavior for ZFW, for parameters such as DoS protection, TCP connection/UDP session timers, and audit-trail logging settings. Parameter-maps are also applied with Layer 7 class and policy-maps to define application-specific behavior, such as HTTP objects, POP3 and IMAP authentication requirements, and other application-specific information.
Inspection parameter-maps for ZFW are configured as type inspect, similar to other ZFW class and policy-objects:

stg-871-L(config)#parameter-map type inspect z1-z2-pmap
stg-871-L(config-profile)#?
parameter-map commands:
  alert           Turn on/off alert
  audit-trail     Turn on/off audit trail
  dns-timeout     Specify timeout for DNS
  exit            Exit from parameter-map
  icmp            Config timeout values for icmp
  max-incomplete  Specify maximum number of incomplete connections before
                  clamping
  no              Negate or set default values of a command
  one-minute      Specify one-minute-sample watermarks for clamping
  sessions        Maximum number of inspect sessions
  tcp             Config timeout values for tcp connections
  udp             Config timeout values for udp flows

Specific types of parameter-maps specify parameters applied by Layer 7 application inspection policies. Regex-type parameter-maps define a regular expression for use with HTTP application inspection that filters traffic using a regular expression:

parameter-map type regex [parameter-map-name]

Protocol-info-type parameter-maps define server names for use with instant messaging application inspection:

parameter-map type protocol-info [parameter-map-name]