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
and
router3825#sh run | s policy-map
policy-map type inspect zp_in2nam
class type inspect NAMtraffic
inspect
class type inspect NAMicmp
inspect
class class-default
drop
policy-map type inspect zp_in2out
class type inspect icmp
inspect
class type inspect HTTP
inspect
class type inspect POP
inspect
class type inspect management-traffic
inspect
class type inspect DNS
inspect
class type inspect WEBtraffic
inspect
class type inspect ipsec-security
inspect
class class-default
drop
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 50.xxx.xx.xx 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
inspect
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
drop
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:1.1.1.2:56922) (0:74.124.125.120:80) 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=74.124.145.120 (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) (74.125.135.120:80) 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;
e.g
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 22.22.22.1 255.255.255.252
zone-member security nam
hold-queue 60 out
end
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
router3825#
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