Saturday 16 March 2013

IOS - Zone Based Firewall - Part I

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.

Firewall policies are configured with the Cisco Policy Language (CPL), which employs a hierarchical structure to define inspection for network protocols and the groups of hosts to which the inspection will be applied.

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.
Cisco Policy Language (CPL) Configuration
  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.

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:
  • 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 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.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.
Controlling Access to the Router

The self zone is a zone created by default by the router. It has a permit policy by default, and it used to manage traffic directed to or generated by the router.
To control traffic to and from the IP addresses on the router itself one or many policies are needed.
If a policy is configured from any zone to the self zone, and no policy is configured from self zone to the router’s user-configurable interface-connected zones, all router-originated traffic encounters the connected-zone to self-zone policy on its return the router and is blocked. Thus, router-originated traffic must be inspected to allow its return to the self zone.

Self-zone policy has limited functionality as compared to the policies available for transit-traffic zone-pairs:
  • As was the case with classical stateful inspection, router-generated traffic is limited to TCP, UDP, ICMP, and complex-protocol inspection for H.323.
  • Application Inspection is not available for self-zone policies.
  • Session and rate limiting cannot be configured on self-zone policies.
Scenario

Requirements:
  • Define 3 security zones: inside, outside, dmz
zone security inside
zone security outside
zone security dmz
  • Protocols allowed from INSIDE to OUTSIDE: http, https, ftp, icmp, dns, ssh, telnet, ntp, ymsgr
 class-map type inspect match-any CMAP_INSIDE_TO_OUTSIDE_PROTOCOLS
 match protocol http
 match protocol https
 match protocol ftp
 match protocol icmp
 match protocol dns
 match protocol ssh
 match protocol telnet
 match protocol ntp
 match protocol ymsgr
  • Protocols allowed from OUTSIDE to DMZ: http, https, ftp, tacacs
class-map type inspect match-any CMAP_OUTSIDE_TO_DMZ_PROTOCOLS
 match protocol http
 match protocol https
 match protocol ftp
 match protocol tacacs
  • Protocols allowed from INSIDE to DMZ: http, https, ftp, icmp, tacacs, ssh 
class-map type inspect match-any CMAP_INSIDE_TO_DMZ_PROTOCOLS
 match protocol http
 match protocol https
 match protocol ftp
 match protocol icmp
 match protocol tacacs
 match protocol ssh
  • Match only traffic generated from inside zone(to outside)
class-map type inspect match-all CMAP_INSIDE_TO_OUTSIDE_TRAFFIC
 match access-group name FROM_INSIDE_NETWORK
 match class-map CMAP_INSIDE_TO_OUTSIDE_PROTOCOLS
  • Match only traffic generated to dmz zone(from outside)
class-map type inspect match-all CMAP_OUTSIDE_TO_DMZ_TRAFFIC
 match access-group name TO_DMZ_NETWORK
 match class-map CMAP_OUTSIDE_TO_DMZ_PROTOCOLS
  • Match only traffic generated from inside zone to dmz
class-map type inspect match-all CMAP_INSIDE_TO_DMZ_TRAFFIC
 match access-group name FROM_INSIDE_NETWORK
 match access-group name TO_DMZ_NETWORK
 match class-map CMAP_INSIDE_TO_DMZ_PROTOCOLS
ip access-list extended FROM_INSIDE_NETWORK
 permit ip 10.1.1.0 0.0.0.255 any
ip access-list extended TO_DMZ_NETWORK
 permit ip any 192.168.223.0 0.0.0.255
  • Configure policy-map for every zone-pair security
policy-map type inspect PMAP_INSIDE_TO_OUTSIDE
 class type inspect CMAP_INSIDE_TO_OUTSIDE_TRAFFIC
  inspect
 class class-default
  drop log
policy-map type inspect PMAP_INSIDE_TO_DMZ
 class type inspect CMAP_INSIDE_TO_DMZ_TRAFFIC
  inspect
 class class-default
  drop log
policy-map type inspect PMAP_OUTSIDE_TO_DMZ
 class type inspect CMAP_OUTSIDE_TO_DMZ_TRAFFIC
  inspect
 class class-default
  drop log
  • Apply policies to security zone-pairs
zone-pair security INSIDE_TO_OUTSIDE source inside destination outside
 service-policy type inspect PMAP_INSIDE_TO_OUTSIDE
zone-pair security INSIDE_TO_DMZ source inside destination dmz
 service-policy type inspect PMAP_INSIDE_TO_DMZ
zone-pair security OUTSIDE_TO_DMZ source outside destination dmz
 service-policy type inspect PMAP_OUTSIDE_TO_DMZ
  • Assign interfaces to zones
interface Ethernet1/0
 ip address 10.1.1.1 255.255.255.0
 zone-member security inside
interface Ethernet1/1
 ip address 192.168.223.100 255.255.255.0
 zone-member security dmz
interface FastEthernet2/0
 ip address 172.20.1.2 255.255.255.0
 zone-member security outside
  • Permit traceroute traffic from inside to outside
ip access-list extended UDP_TRACEROUTE_PORTS
 permit udp any any range 33434 33464
ip access-list extended ICMP_TRACEROUTE
 permit icmp any any time-exceeded
 permit icmp any any port-unreachable
class-map type inspect match-all CMAP_INSIDE_TO_OUTSIDE_TRACEROUTE
 match access-group name UDP_TRACEROUTE_PORTS
class-map type inspect match-all CMAP_OUTSIDE_TO_INSIDE_TRACEROUTE
 match access-group name ICMP_TRACEROUTE
policy-map type inspect PMAP_INSIDE_TO_OUTSIDE
 class type inspect CMAP_INSIDE_TO_OUTSIDE_TRAFFIC
  inspect
 class type inspect CMAP_INSIDE_TO_OUTSIDE_TRACEROUTE
  pass
 class class-default
  drop log
policy-map type inspect PMAP_OUTSIDE_TO_INSIDE
 class type inspect CMAP_OUTSIDE_TO_INSIDE_TRACEROUTE
  pass
 class class-default
  drop log
  •  Allow  only SSH and HTTPs access to router from zones outside and dmz.
ip access-list extended SSH_HTTPS_TRAFFIC
permit tcp any any eq 22
permit tcp any any eq 443
class-map type inspect match-all CMAP_HTTPS_SSH
match access-group name SSH_HTTPS_TRAFFIC
match protocol tcp
 policy-map type inspect PMAP_OUTSIDE_TO_SELF
class CMAP_HTTPS_SSH
inspect
policy-map type inspect PMAP_DMZ_TO_SELF
class CMAP_HTTPS_SSH
inspect
zone-pair security ZP_OUTSIDE_TO_SELF source outside destination self
service-policy type inspect PMAP_OUTSIDE_TO_SELF
!
zone-pair security ZP_DMZ_TO_SELF source dmz destination self
service-policy type inspect PMAP_DMZ_TO_SELF
  • Permit icmp from router to any destination
class-map type inspect match-all CMAP_ICMP
match protocol icmp
policy-map type inspect PMAP_SELF_TO_ANY
class CMAP_ICMP
inspect
zone-pair security ZP_SELF_TO_OUTSIDE source self destination outside
service-policy type inspect PMAP_SELF_TO_ANY
zone-pair security ZP_SELF_TO_DMZ source self destination dmz
service-policy type inspect PMAP_SELF_TO_ANY
Verification
R1#show zone security  
zone self
  Description: System defined zone
zone inside
  Member Interfaces:
    Ethernet1/0
zone outside
  Member Interfaces:
    FastEthernet2/0
zone dmz
  Member Interfaces:
    Ethernet1/1

 R1#show zone-pair security     
Zone-pair name INSIDE_TO_OUTSIDE
    Source-Zone inside  Destination-Zone outside
    service-policy PMAP_INSIDE_TO_OUTSIDE
Zone-pair name INSIDE_TO_DMZ
    Source-Zone inside  Destination-Zone dmz
    service-policy PMAP_INSIDE_TO_DMZ
Zone-pair name OUTSIDE_TO_DMZ
    Source-Zone outside  Destination-Zone dmz
    service-policy PMAP_OUTSIDE_TO_DMZ
Zone-pair name OUTSIDE_TO_INSIDE
    Source-Zone outside  Destination-Zone inside
    service-policy PMAP_OUTSIDE_TO_INSIDE
Zone-pair name ZP_OUTSIDE_TO_SELF
    Source-Zone outside  Destination-Zone self
    service-policy PMAP_OUTSIDE_TO_SELF
Zone-pair name ZP_DMZ_TO_SELF
    Source-Zone dmz  Destination-Zone self
    service-policy PMAP_DMZ_TO_SELF
Zone-pair name ZP_SELF_TO_OUTSIDE
    Source-Zone self  Destination-Zone outside
    service-policy PMAP_SELF_TO_ANY
Zone-pair name ZP_SELF_TO_DMZ
    Source-Zone self  Destination-Zone dmz
    service-policy PMAP_SELF_TO_ANY

R1#show policy-map type inspect zone-pair INSIDE_TO_OUTSIDE
 Zone-pair: INSIDE_TO_OUTSIDE
  Service-policy inspect : PMAP_INSIDE_TO_OUTSIDE
    Class-map: CMAP_INSIDE_TO_OUTSIDE_TRAFFIC (match-all)
      Match: access-group name FROM_INSIDE_NETWORK
      Match: class-map match-any CMAP_INSIDE_TO_OUTSIDE_PROTOCOLS
        Match: protocol http
          14 packets, 560 bytes
          30 second rate 0 bps
        Match: protocol ftp
          0 packets, 0 bytes
          30 second rate 0 bps
        Match: protocol icmp
          1 packets, 64 bytes
          30 second rate 0 bps
        Match: protocol dns
          64 packets, 2967 bytes
          30 second rate 0 bps
        Match: protocol ssh
          0 packets, 0 bytes
          30 second rate 0 bps
        Match: protocol telnet
          0 packets, 0 bytes
          30 second rate 0 bps
        Match: protocol ymsgr
          2 packets, 80 bytes
          30 second rate 0 bps
        Match: protocol https
          23 packets, 920 bytes
          30 second rate 0 bps
        Match: protocol ntp
          105 packets, 5880 bytes
          30 second rate 0 bps
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [2:1782]
        udp packets: [0:338]
        icmp packets: [0:6]
        im-yahoo packets: [0:85]
        Session creations since subsystem startup or last reset 208
        Current session counts (estab/half-open/terminating) [4:0:0]
        Maxever session counts (estab/half-open/terminating) [27:4:5]
        Last session created 00:00:03
        Last statistic reset never
        Last session creation rate 3
        Maxever session creation rate 33
        Last half-open session total 0
    Class-map: CMAP_INSIDE_TO_OUTSIDE_TRACEROUTE (match-all)
      Match: access-group name UDP_TRACEROUTE_PORTS
      Pass
        84 packets, 3360 bytes
    Class-map: class-default (match-any)
      Match: any
      Drop
        93 packets, 3800 bytes

Thursday 14 March 2013

IOS ACL -CBAC

  • Traffic Filtering
CBAC ( Context-Based Access Control) inspects traffic that travels through the firewall to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall's access lists to allow return traffic and additional data connections for permissible sessions.

CBAC does not provide intelligent filtering for all protocols; it only works for the protocols that you specify. If you do not specify a certain protocol for CBAC, the existing access lists will determine how that protocol is filtered. No temporary openings will be created for protocols not specified for CBAC inspection.
ip inspect name INSPECT icmp
ip inspect name INSPECT dns
ip inspect name INSPECT http
ip inspect name INSPECT https
ip inspect name INSPECT ftp

interface FastEthernet2/0
 ip address 172.20.1.2 255.255.255.0
 ip access-group TRAFFIC-IN in
 ip inspect INSPECT out

ip access-list extended TRAFFIC-IN
 deny   ip any any log
Verification:
R1#show ip inspect sessions
Established Sessions
 Session 6696A4D4 (10.1.1.2:44279)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696CE8C (10.1.1.2:8)=>(8.8.8.8:0) icmp SIS_OPEN
 Session 669616FC (10.1.1.2:54196)=>(173.194.39.120:443) https SIS_OPEN
 Session 6696AFF4 (10.1.1.2:34012)=>(173.194.39.145:443) https SIS_OPEN
 Session 6696CBC4 (10.1.1.2:33813)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696BDDC (10.1.1.2:59747)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696C0A4 (10.1.1.2:53093)=>(192.168.223.129:21) ftp SIS_OPEN
 Session 669696EC (10.1.1.2:37786)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696A20C (10.1.1.2:50251)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696BB14 (10.1.1.2:51174)=>(8.8.8.8:53) dns SIS_OPEN
 Session 6696AD2C (10.1.1.2:48128)=>(109.100.26.54:80) http SIS_OPEN
By default, CBAC do not apply to router-generated traddic.
ip inspect name INSPECT icmp router-traffic

R1#show ip inspect sessions
Established Sessions
 Session 6696AFF4 (172.20.1.2:8)=>(192.168.223.129:0) icmp SIS_OPEN
  • Traffic inspection
Inspecting packets at the application layer, and maintaining TCP and UDP session information, provides CBAC with the ability to detect and prevent certain types of network attacks such as SYN-flooding.
A SYN-flood attack occurs when a network attacker floods a server with a barrage of requests for connection and does not complete the connection. The resulting volume of half-open connections can overwhelm the server, causing it to deny service to valid requests. Network attacks that deny access to a network device are called denial-of-service (DoS) attacks.

CBAC helps to protect against DoS attacks in other ways. CBAC inspects packet sequence numbers in TCP connections to see if they are within expected ranges—CBAC drops any suspicious packets. You can also configure CBAC to drop half-open connections, which require firewall processing and memory resources to maintain. Additionally, CBAC can detect unusually high rates of new connections and issue alert messages.

Packets entering the firewall are inspected by CBAC only if they first pass the inbound access list at the input interface and outbound access list at the output interface. If a packet is denied by the access list, the packet is simply dropped and not inspected by CBAC.

CBAC inspection tracks sequence numbers in all TCP packets, and drops those packets with sequence numbers that are not within expected ranges.

When CBAC suspects an attack, the DoS feature can take several actions:
•Generate alert messages
•Protect system resources that could impede performance
•Block packets from suspected attackers

CBAC uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established.

CBAC provides three thresholds against DoS attacks:
•The total number of half-open TCP or UDP sessions
•The number of half-open sessions based upon time
•The number of half-open TCP-only sessions per host

If a threshold is exceeded, CBAC has two options:
•Send a reset message to the end points of the oldest half-open session, making resources available to service newly arriving SYN packets.
•In the case of half open TCP only sessions, CBAC blocks all SYN packets temporarily for the duration configured by the threshold value. When the router blocks a SYN packet, the TCP three-way handshake is never initiated, which prevents the router from using memory and processing resources needed for valid connections.
ip inspect max-incomplete low 20
ip inspect max-incomplete high 30
ip inspect one-minute low 100
ip inspect one-minute high 120
ip inspect tcp max-incomplete host 10 block-time 5
Verification:
R1#show ip inspect config
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [100 : 120] connections
max-incomplete sessions thresholds are [20 : 30]
max-incomplete tcp connections per host is 10. Block-time 5 minutes.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name INSPECT
    dns alert is on audit-trail is off timeout 30
    http alert is on audit-trail is off timeout 3600
    https alert is on audit-trail is off timeout 3600
    ftp alert is on audit-trail is off timeout 3600
    icmp alert is on audit-trail is off timeout 10
*Mar 14 16:58:46.322: %FW-4-ALERT_ON: getting aggressive, count (2/30) current 1-min rate: 11

  • Alerts and Audit Trails

CBAC also generates real-time alerts and audit trails. Enhanced audit trail features use SYSLOG to track all network transactions; recording time stamps, source host, destination host, ports used, and the total number of transmitted bytes, for advanced, session-based reporting. Real-time alerts send SYSLOG error messages to central management consoles upon detecting suspicious activity. Using CBAC inspection rules, you can configure alerts and audit trail information on a per-application protocol basis. For example, if you want to generate audit trail information for HTTP traffic, you can specify that in the CBAC rule covering HTTP inspection.

CBAC does not provide intelligent filtering for all protocols; it only works for the protocols that you specify. If you do not specify a certain protocol for CBAC, the existing access lists will determine how that protocol is filtered. No temporary openings will be created for protocols not specified for CBAC inspection.
ip inspect alert-off
ip inspect name INSPECT icmp alert on
no ip inspect audit-trail
ip inspect name INSPECT tcp audit-trail on
Verification
 R1#show ip inspect config
Session audit trail is disabled
Session alert is disabledone-minute (sampling period) thresholds are [5 : 10] connections
max-incomplete sessions thresholds are [20 : 30]
max-incomplete tcp connections per host is 10. Block-time 5 minutes.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name INSPECT
    dns alert is off audit-trail is off timeout 30
    http alert is off audit-trail is off timeout 3600
    https alert is off audit-trail is off timeout 3600
    ftp alert is off audit-trail is off timeout 3600
    icmp alert is on audit-trail is off timeout 10    tcp alert is off audit-trail is on timeout 3600

*Mar 14 17:07:19.650: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session: initiator (10.1.1.2:33675) -- responder (172.20.1.1:23)
*Mar 14 17:08:08.390: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator (10.1.1.2:33675) sent 67 bytes -- responder (172.20.1.1:23) sent 117 bytes
  • Manual Port Mappings
ip port-map user-custom port tcp 65000 description CUSTOM_APPLICATION
ip inspect name INSPECT user-custom


IOS ACL - Part 1 Extended ACL, Reflexive ACL and Dynamic ACL

1. Basic ACL
Standard ACLs
Standard ACLs control traffic by the comparison of the source address of the IP packets to the addresses configured in the ACL.

access-list access-list-number {permit|deny} {host|source source-wildcard|any}
 access-list-number can be anything from 1 to 99
After the ACL is defined, it must be applied to the interface (inbound or outbound).

interface
ip access-group number {in|out}
Extended ACLs
Extended ACLs control traffic by the comparison of the source and destination addresses of the IP packets to the addresses configured in the ACL.

IP

access-list access-list-number
     [dynamic dynamic-name [timeout minutes]]
     {deny|permit} protocol source source-wildcard
     destination destination-wildcard [precedence precedence]
     [tos tos] [log|log-input] [time-range time-range-name]
ICMP

access-list access-list-number
     [dynamic dynamic-name [timeout minutes]]
     {deny|permit} icmp source source-wildcard
     destination destination-wildcard
     [icmp-type [icmp-code] |icmp-message]
     [precedence precedence] [tos tos] [log|log-input]
     [time-range time-range-name]
TCP

access-list access-list-number
     [dynamic dynamic-name [timeout minutes]]
     {deny|permit} tcp source source-wildcard [operator [port]]
     destination destination-wildcard [operator [port]]
     [established] [precedence precedence] [tos tos]
     [log|log-input] [time-range time-range-name]
UDP

access-list access-list-number
     [dynamic dynamic-name [timeout minutes]]
     {deny|permit} udp source source-wildcard [operator [port]]
     destination destination-wildcard [operator [port]]
     [precedence precedence] [tos tos] [log|log-input]
     [time-range time-range-name]
 access-list-number can be 100 to 199

Named ACLs
 IP named ACLs allows standard and extended ACLs to be given names instead of numbers.
ip access-list {extended|standard} name

2.Reflexive ACL

Reflexive access lists contain only temporary entries; these entries are automatically created when a new IP session begins (for example, the reflexive ACL is triggered by an outbound packet), and the entries are removed when the session ends. Reflexive access lists are not themselves applied directly to an interface, but are "nested" within an extended named IP access list that is applied to the interface.

Restrictions on Using Reflexive Access Lists
Reflexive access lists do not work with some applications that use port numbers that change during a session. For example, if the port numbers for a return packet are different from the originating packet, the return packet will be denied, even if the packet is actually part of the same session.

The TCP application of FTP is an example of an application with changing port numbers. With reflexive access lists, if you start an FTP request from within your network, the request will not complete. Instead, you must use Passive FTP when originating requests from within your network.
ip access-list extended nameA
   permit protocol any any reflect nameB [timeoutseconds]
ip access-list extended nameC
   evaluate nameB
interface
  ip access-group nameA out
  ip access-group nameC in
3.Dynamic ACL

Dynamic ACL is dependent on Telnet, authentication (local or remote), and extended ACLs.
Dynamic ACL configuration starts with the application of an extended ACL to block traffic through the router. Users that want to traverse the router are blocked by the extended ACL until they Telnet to the router and are authenticated. The Telnet connection then drops and a single-entry dynamic ACL is added to the extended ACL that exists. This permits traffic for a particular time period; idle and absolute timeouts are possible.

access-list access-list-number dynamic name {permit|deny} [protocol]
{source source-wildcard|any} {destination destination-wildcard|any}
[precedence precedence][tos tos][established] [log|log-input]
[operator destination-port|destination port]
4. Scenario 

A. Basic ACL

Requirements inside to outside
-permit outside DNS
-permit www access
-permit https access
-permit FTP access (active mode)
-permit ping and traceroute

Requirements outside to inside
-permit www access to server 10.1.1.2
-protect for fragmented packets

Note: FTP is a TCP based service exclusively. A typical FTP session operates using two channels: a command (or control - port 21) channel and a data channel.The port used for the data channel can differ depending on which data transfer mode is used. For Active mode the data channel port is 20. For Passive mode the data channel port is a random port >1023. In Active mode an user connects from a random port on a file transfer client to port 21 on the server. It sends the PORT command, specifying what client-side port the server should connect to. This port will be used later on for the data channel and is different from the port used in this step for the command channel.In Pasive mode client still initiates a command channel connection to the server.In this case instead of sending the PORT command, it sends the PASV command, which is a request for a server port to connect to for data transmission. When the FTP server replies, it indicates what port number it has opened for the ensuing data transfer. 

ip access-list extended TRAFFIC-IN
 deny   ip any any fragments
 permit tcp any any established
 permit udp any eq domain any
 permit udp any eq ntp any
 permit tcp any eq ftp-data any
 permit icmp any any echo-reply
 permit icmp any any time-exceeded
 permit icmp any any port-unreachable
 permit tcp any host 10.1.1.2 eq www
 deny   ip any any log
ip access-list extended TRAFFIC-OUT
 permit udp any any eq domain
 permit tcp any any eq www
 permit tcp any any eq 443
 permit udp any eq ntp any
 permit tcp any any eq ftp
 permit tcp any any eq ftp-data
 permit icmp any any echo
 permit udp any any range 33434 33464
 permit tcp host 10.1.1.2 eq www any
 deny   ip any any log

interface FastEthernet2/0
 ip address 172.20.1.2 255.255.255.0
 ip access-group TRAFFIC-IN in
 ip access-group TRAFFIC-OUT out
Verification
R1#show ip access-lists
Extended IP access list TRAFFIC-IN
    5 deny ip any any fragments
    10 permit tcp any any established (5859 matches)
    20 permit udp any eq domain any (213 matches)
    50 permit tcp any eq ftp-data any (1 match)
    60 permit icmp any any echo-reply (17 matches)
    70 permit icmp any any time-exceeded (325 matches)
    80 permit icmp any any port-unreachable (43 matches)
    90 permit tcp any host 10.1.1.2 eq www (1 match)
    9999 deny ip any any log (53 matches)
Extended IP access list TRAFFIC-OUT
    10 permit udp any any eq domain (213 matches)
    20 permit tcp any any eq www (3228 matches)
    30 permit tcp any any eq 443 (1032 matches)
    50 permit tcp any any eq ftp (43 matches)
    60 permit tcp any any eq ftp-data (3 matches)
    70 permit icmp any any echo (17 matches)
    80 permit udp any any range 33434 33464
    90 permit tcp host 10.1.1.2 eq www any (6 matches)
    9999 deny ip any any log (56 matches)
B.Reflexive ACL
Requirements
-permit all traffic (TCP,UDP,ICMP) from inside to outside

Note: for this task remove all previous configured ACL
ip access-list extended TRAFFIC-OUT
 permit tcp any any reflect MIRROR
 permit udp any any reflect MIRROR
 permit icmp any any reflect MIRROR
 deny   ip any any log
ip access-list extended TRAFFIC-IN
 evaluate MIRROR
 deny   ip any any log

interface FastEthernet2/0
 ip address 172.20.1.2 255.255.255.0
 ip access-group TRAFFIC-IN in
 ip access-group TRAFFIC-OUT out
Verification
R1#show ip access-lists                
Reflexive IP access list MIRROR
     permit tcp host 173.194.34.79 eq 443 host 10.1.1.2 eq 36798 (45 matches) (time left 269)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 56413 (2 matches) (time left 179)
     permit tcp host 173.194.41.79 eq 443 host 10.1.1.2 eq 32899 (24 matches) (time left 268)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 50338 (2 matches) (time left 178)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 34574 (2 matches) (time left 178)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 42713 (2 matches) (time left 178)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 38732 (2 matches) (time left 178)
     permit tcp host 173.194.39.184 eq 443 host 10.1.1.2 eq 45214 (336 matches) (time left 269)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 58391 (2 matches) (time left 176)
     permit tcp host 173.194.39.145 eq 443 host 10.1.1.2 eq 33936 (24 matches) (time left 266)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 41884 (2 matches) (time left 176)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 48723 (2 matches) (time left 171)
     permit udp host 8.8.8.8 eq domain host 10.1.1.2 eq 35283 (2 matches) (time left 171)
     permit icmp host 8.8.8.8 host 10.1.1.2  (1037 matches) (time left 299)
Extended IP access list TRAFFIC-IN
    10 evaluate MIRROR
    9999 deny ip any any log (29 matches)
Extended IP access list TRAFFIC-OUT
    10 permit tcp any any reflect MIRROR (215 matches)
    20 permit udp any any reflect MIRROR (38 matches)
    30 permit icmp any any reflect MIRROR (545 matches)
    40 deny ip any any log
C. Dynamic ACL
Requirements
-permit ping traffic from outside (authenticated IP) to the inside
aaa new-model
aaa authentication login CONSOLE none
aaa authorization exec default local
username CISCO autocommand access-enable host timeout 10
username CISCO password 0 test_ping
ip access-list extended TRAFFIC-IN
 evaluate MIRROR
 permit tcp any host 172.20.1.2 eq telnet
 dynamic PING_ACCESS permit icmp any any
 deny   ip any any log
Verification:
Extended IP access list TRAFFIC-IN
    10 evaluate MIRROR
    15 permit tcp any host 172.20.1.2 eq telnet (342 matches)
    20 Dynamic PING_ACCESS permit icmp any any
       permit icmp host 192.168.223.129 any (4 matches) (time left 595)
       permit icmp host 172.20.1.1 any (5 matches) (time left 315)

    9999 deny ip any any log (57 matches)




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>