Sunday, December 16, 2012

cisco IOS zbfw t-shoot thoughts and tips

One thing that becomes challenging with  cisco zone based firewalls ; is the trouble-shooting. When using zbfw, we must be aware of the policies layout, and the access allowed.

If it's not allowed, you're not going anywhere.

Take this simple zbfw class+policy

router3825#sh run | s class-map
class-map type inspect match-all icmp
 match protocol icmp
class-map type inspect match-all HTTP
 match protocol http
class-map type inspect match-any NAMtraffic
 match protocol telnet
 match protocol ssh
 match protocol http
 match protocol https
class-map type inspect match-any WEBtraffic
 description match any web traffic on default 80/443 ports
 match protocol http
 match protocol https
class-map type inspect match-all SSHfgt
 match access-group name fgt-management
class-map type inspect match-any POP
 match protocol pop3
 match protocol pop3s
 match protocol smtp
class-map type inspect match-any management-traffic
 description allow for  traffic to anything that we might manage
 match protocol ssh
 match protocol telnet
 match protocol snmp
 match class-map SSHfgt
class-map type inspect match-all NAMicmp
 description allow icmp thru
 match protocol icmp
class-map type inspect match-any ipsec-security
 description "for ipsec traffic from inside hosts nat-t,ike,esp,only "
 match access-group name ipsec-out
class-map type inspect match-all DNS
 match protocol dns
class-map type inspect match-all HTTPend


router3825#sh run | s policy-map
policy-map type inspect zp_in2nam
 class type inspect NAMtraffic
 class type inspect NAMicmp
 class class-default
policy-map type inspect zp_in2out
 class type inspect icmp
 class type inspect HTTP
 class type inspect POP
 class type inspect management-traffic
 class type inspect DNS
 class type inspect WEBtraffic
 class type inspect ipsec-security
 class class-default

All traffic type that you want inspection for, must be included in the class-map type inspect and policy-map type inspect.

Traffic that does not run on well-known ports, needs to be carefully scrutinized and reviewed.

For example to allow ssh outbound to a none common port, I created a ACL list with the servers involved.

Extended IP access list fgt-management
    10 permit tcp any host 38.xx.xx.2 eq 21022 (1 match)
    20 permit tcp any host 174.xx.xx.xx eq 21023
    30 permit tcp any host eq 21024

The above three lines are my fortigate firewalls that sits outside of my inside zone. Since theses ports involved ,are not normal SSH ports ( tcp/22) I used this custom ACL to allow traffic to the destinations.

The class-map that uses the above lines;

class-map type inspect match-all SSHfgt
 match access-group name fgt-management

vrs my standard management class-map;

class-map type inspect match-any management-traffic
 description allow for  traffic to anything that we might manage
 match protocol ssh
 match protocol telnet
 match protocol snmp
 match class-map SSHfgt

You notice how I nested a class-map within another class-map :)  So later on, when we define the inspect policy, we can now define inspection for all management-traffic class and inspect all management protocol destinations.

 class type inspect management-traffic

This line above, will cause inspection for anything listed in management-traffic class, that we defined earlier on and above.

Becarefull of your  default class. It's typically set for drop and drop is the  best-practice, when building your architect and security policies.

 class class-default

If it was not defined with a proper action, than you should drop the traffic.

Now to debug a zbfw, we use any of the following debug cmds;

router3825#debug  policy-firewall ?
  L2-transparent  Policy-Firewall transparent firewall debug
  control-plane   Policy-Firewall Control-plane debug
  detail          Policy-Firewall detailed debug
  events          Policy-Firewall events debug
  function-trace  Policy-Firewall function-trace debug
  list            Policy-Firewall Conditional debug
  mib             Debug IOS firewall MIB
  obj-creation    Policy-Firewall object creations debug
  obj-deletion    Policy-Firewall object deletions debug
  packet-path     Policy-Firewall packet-path debug
  protocol        Policy-Firewall protocol debug
  timers          Policy-Firewall timers related events debug

debug policy-firewall detail is probably the most commonly used debug option and will display very useful session info;

*Dec 16 21:08:13.227: FIREWALL*: NEW PAK 694FA100 (0: (0: tcp
*Dec 16 21:08:13.227: FIREWALL*: FSO feature object 0x70D08020 found
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: SIS_OPEN
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: Pak 0x694FA100 IP: s=72.xx.x.xx (GigabitEthernet0/0), d= (GigabitEthernet0/1), len 404, proto=tcp
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 result: SKIP packet 0x694FA100 (72.xx.xx.xx:56922) ( bytes 404 ErrStr = Retransmitted Segment
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 inspection ret_val = 5l4_result->fw_dp_insp_err_code = 19session->appl_insp_flags = 1
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: Got a FW only session
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 inspection returned 5

If you don't find matches in the firewall policy sesssion, than you need to revisit your class-map  and police for errors or if  you referenced  ACLs, police the src/dst and wildcard masks.

A few  other items to be aware of;

The  policy-map type inspect is an top down match, until a match is made, the default action is  handled by the class-default inspection. So keep that in mind when your dealing  10+ lines of  class-map and within the service-policy inspect.

Traffic in one zone, needs an inspect policy for the direction that the traffic originate. So in my above example, I have nothing defined in any of the external-2-inside zones. I'm only allowing and inspecting traffic from a in2out direction.

If you have any modules or other devices, they will need security zone configurations;

router3825#sh ver | i nam                                
1 cisco nam sensor(s), nam monitoring on slot 2

router3825#sh running-config interface analysis-Module 2/0
Building configuration...

Current configuration : 179 bytes
interface Analysis-Module2/0
 description NAM login root/root webui admin/admin kfelix/
 ip address
 zone-member security nam
 hold-queue 60 out

router3825#sh zone-pair security source  inside destination nam
Zone-pair name in2nam
Description: zone for traffic from inside to NM-NAM
    Source-Zone inside  Destination-Zone nam
    service-policy zp_in2nam
router3825#sh zone-pair security source nam destination inside

Notice how I don't have any thing for the NAM-to-inside direction.  But I do have a security zone name nam and a zone-pair for in2nam.

Lastly, a interface can only be in one zone-member,  BUT can be in multiple zone-pairs.

To wrap up, zbfw is interesting and simpler for a ios-engineer than a cisco ASA, but be aware of class-map, inspect types within your policy, and the proper zone-pairing. ZBFW is also easier to t-shoot and configure than CBAC imho.

Ken Felix
freelance network security engineer
kfelix at hyperfeed dot-com

No comments:

Post a Comment