Thanks for clearing that up Rene.
Rene, in the following config lifted from the CCP default policy:
policy-map type inspect ccp-permit class class-default zone-pair security ccp-zp-out-self source out-zone destination self service-policy type inspect ccp-permit
Does not specifying anything as the class-default result in all traffic being dropped? Does the class-default have an implicit drop in this situation?
Since this is the service-policy for traffic from the outside to the inside I’m assuming that a class-default not being defined would result in a drop action.
That’s right. The default action will be drop:
R1#show policy-map type inspect ccp-permit Policy Map type inspect ccp-permit Class class-default Drop
This seems to be for traffic from the outside to the “self” zone (the router itself), it’s not for traffic from outside > inside.
They probably use something like this to disable management (telnet/ssh/snmp) to the router from the outside.
Thanks Rene. I meant self zone. I think that this config would be ideal for blocking all external traffic from the router itself. It would make for a very secure config.
That’s right. The self zone is often forgotten. It’s best to implement something like this to drop everything from the outside to the router itself. If you want to use SSH from the outside, it’s best to include a source IP address instead of opening TCP 22 for the entire world.
I’m wanting to include a section in my ZBPF to deny access to certain URLs. Some websites are suggesting to use a parameter-map type regex whilst others are suggesting using a class-map match-any.
! parameter-map type regex url-blacklist-pmap pattern *.example.com vs class-map match-any URL_BLOCK match protocol http host "example.com" !
I am interested in doing this to try and block various telemetry attempts by 3rd parties as the hosts file is often quite useless at this. Some use URLs hardcoded with their phone home addresses inside .DLLs to circumvent detection. Can you offer any suggestions using the correct syntax?
Good question…your first example uses the URL filter, the second one uses NBAR.
Both will do the job, the configuration with NBAR is probably much easier though. It’s also possible that there is a performance difference between the two.
Here’s a working example how you can use the parameter-map. It blocks youtube.com and permits anything else, I just tested this in my lab and it works:
hostname R2 ! ip cef ! parameter-map type urlfpolicy local URL_FILTER block-page message "YOU ARE NOT AUTHORIZED" parameter-map type urlf-glob YOUTUBE pattern youtube.com parameter-map type urlf-glob ALLOWED_URLS pattern * multilink bundle-name authenticated ! class-map type inspect match-all HTTP match protocol http class-map type urlfilter match-any BLOCK_YOUTUBE match server-domain urlf-glob YOUTUBE class-map type urlfilter match-any ALLOW match server-domain urlf-glob ALLOWED_URLS ! policy-map type inspect urlfilter URL_FILTER parameter type urlfpolicy local URL_FILTER class type urlfilter BLOCK_YOUTUBE reset class type urlfilter ALLOW allow policy-map type inspect WAN-TO-SELF class class-default drop policy-map type inspect WAN-TO-LAN class type inspect TELNET inspect class class-default drop policy-map type inspect LAN-TO-WAN class type inspect ICMP inspect class type inspect HTTP inspect service-policy urlfilter URL_FILTER class class-default pass ! zone security LAN zone security WAN zone-pair security LAN-TO-WAN source LAN destination WAN description LAN-TO-WAN TRAFFIC service-policy type inspect LAN-TO-WAN zone-pair security WAN-TO-LAN source WAN destination LAN description WAN-TO-LAN TRAFFIC service-policy type inspect WAN-TO-LAN zone-pair security WAN-TO-SELF source WAN destination self service-policy type inspect WAN-TO-SELF ! interface GigabitEthernet0/1 ip address 192.168.12.2 255.255.255.0 zone-member security LAN duplex auto speed auto media-type rj45 ! interface GigabitEthernet0/2 ip address 192.168.23.2 255.255.255.0 zone-member security WAN duplex auto speed auto media-type rj45 ! end
why did you use many “inspect” command , in the class-map , in the policy-map (2 times) and in the zone-pair
which one of them should be the one to allow the return traffic ? and which one of them can I replace with drop or pass?
Also regarding the WAN-TO-SELF should I create LAN-To-SELF deny access from the inside zone?
Thanks a lot
Ali, I just tried what you suggested re the LAN-TO-SELF as per the following on my 1841 just for interest’s sake:
! policy-map type inspect LAN-TO-SELF class class-default drop ! zone security LAN ! zone-pair security LAN-TO-SELF source LAN destination self service-policy type inspect LAN-TO-SELF ! interface FastEthernet0/0 ip address 192.168.1.3 255.255.255.0 zone-member security LAN speed 100 full-duplex !
You just lock yourself out of the router if you do this and will have to console back in to fix it. You would have to associate an access-list with the policy allowing at least some access to the self zone for it to be useful.
As Rene shows in his config the following is effective for blocking all access from the WAN to the router:
policy-map type inspect WAN-TO-SELF class class-default drop
I use this on my ZBPF and find that scans from external sites like GRC’s ShieldsUp! and Pen-Test Tools can’t get in or get a response from my router.
Rene, do you see this as being all you need for an effective firewall or do you suggest adopting other measures in the config as well?
Hi Ali and Matt,
About the many inspect commands…the thing is that the class-map that is used for inspection is a different one than the regular class-map. The same thing applies to the policy-map. For example, take a look at this code:
policy-map type inspect LAN-TO-WAN class type inspect ICMP inspect
The “policy-map type inspect” part only refers to the policy-map called LAN-TO-WAN and specifies that it’s an “inspect type” policy-map. The same thing applies to the class-map we use here.
The only command that does inspection, is the “inspect” command.
About where to use inspect. Let’s look at two different options:
policy-map type inspect LAN-TO-WAN class type inspect ICMP inspect
If you configure it like above, then ICMP traffic is allowed to go from LAN to WAN…AND the return traffic is permitted.
If you use pass instead of inspect, you’ll have to do something like this:
policy-map type inspect LAN-TO-WAN class type inspect ICMP pass
policy-map type inspect WAN-TO-LAN class type inspect ICMP pass
Creating a LAN-TO-SELF zone-pair is useful when you want to restrict traffic from LAN to SELF. you could add one and only permit something like SSH with a source IP.
Your WAN-TO-SELF policy-map looks good Matt. You can always add more class-maps to it for traffic that you do want to permit (SSH perhaps). Dropping everything by default from the outside is a good idea.
Thanks for the reply Rene. If in your above example where you use two policy-maps both with a pass instead of one with inspect, will the second policy-map allow all ICMP traffic to access the router that originates from the WAN? If so, I would have thought that this would be a huge security hole in a firewall.
Hi Matt W,
I have made the lab based on your question and indeed the ICMP traffic coming from the WAN router will be be allowed to reach the router. Here below the result of the lab when doing ping from the WAN router. As you can see, 5 ICMP packets have passed. That´s why it is always recommended to use inspect instead of pass to have more security.
Hope I could answer your question.
Service-policy inspect : WAN-TO-LAN
Class-map: ICMP (match-all) Match: protocol icmp Pass 5 packets, 400 bytes Class-map: class-default (match-any) Match: any Drop 0 packets, 0 bytes
19 posts were merged into an existing topic: Zone Based Firewall Configuration Example
Long time reader and just joined nice plac to be. I have a question on this do I still need to have ACL’s I cannot tell if this is neccessary this is my WAN connection on a lab 1921
interface GigabitEthernet0/0 description WAN_TO_INTERNET ip address dhcp ip access-group 100 in no ip unreachables ip flow ingress ip flow egress ip nat outside ip inspect FIREWALL out ip virtual-reassembly in duplex auto speed auto no cdp enable end
Do still need the ip access-group ACL with ZBFW?
This text will be hidden
Nice to have you with us. As for your question, the above configuration of Gi0/0 interface has
access list 100 in configured and also has
inspect FIREWALL out configured for inspection of returning traffic. However, no zones have been configured here.
If you implement a ZBFW then you will no longer require the ACL configuration since all criteria on whether or not to allow a packet through are configured using zone-pair security policies.
I hope this has been helpful!
Please let me know what IOS version and Router you used in your example. I have Cisco 3700 series in GNS3 with the following IOS
(C3725-ADVENTERPRISEK9-M), Version 12.4.
I don’t see any options or commands for Zone.
You can use the Cisco feature navigator to find which IOS image you will need:
I couldn’t find the 3725 in the platform list as it’s probably too old. Looking at the 3825, it’s probably the advanced enterprise image you need:
according to Zone Self rule.
R2(config)#policy-map type inspect WAN-TO-SELF R2(config)#zone-pair security WAN-TO-SELF source WAN destination self R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-SELF
Will all the data send back from ISP to LAN be dropped because of R2 Zone Self rule?
The self zone is only for packets that are destined for the router itself, not for packets that are flowing through the router (like from WAN to LAN).
If you want to permit return traffic that originated from the LAN to the Internet, then you’ll need to use a inspect rule in your LAN-TO-WAN zone-pair.
thank for your explain.