پیکربندی Zone Base Firewall(ترجمه فارسی بزودی در همین وبلاگ)

Zone Based Firewall Configuration Example

Zone Based Firewall is the most advanced method of a stateful firewall that is available on Cisco IOS routers. The idea behind ZBF is that we don’t assign access-lists to interfaces but we will create different zones. Interfaces will be assigned to the different zones and security policies will be assigned to traffic between zones. To show you why ZBF is useful, let me show you a picture:

Above you see a small network that has a LAN, DMZ and WAN with two ISPs. Let’s say our security policy looks like this:

• Traffic from the LAN is allowed to the WAN but only to HTTP and HTTPS servers.
• Traffic from the LAN is allowed to the DMZ unrestricted.
• Traffic from the DMZ is not allowed to the LAN.
• Traffic from the DMZ is allowed to the WAN but only for the DNS and HTTP servers.
• Traffic from the WAN is allowed to the LAN, but only to a FTP server.

If you want to achieve this using access-lists, you’ll have to create multiple access-lists and attach them to different interfaces inbound and/or outbound. To say the least, it becomes an administrative pain to do this. It’s possible but annoying.

With the zone based firewall, we won’t apply the security policies to the interfaces but to security zones. Interfaces will become members of the different zones. Here’s an example of the topology above with zones:

Above you see 3 zones; LAN, WAN and DMZ. The interfaces are assigned to the correct zone and now we can apply security policies to traffic between zones. For example:

• LAN to WAN
• LAN to DMZ
• WAN to LAN
• WAN to DMZ
• DMZ to WAN
• DMZ to LAN

To create a security policy for traffic between zones we have to create a zone pair. We have to configure zone pairs ourselves and apply a security policy to them to determine what traffic is permitted from one zone to another. All security policies are attached to the zone pairs. Now you have an idea what a zone based firewall is, let me show you how to configure this.

Configuration

We will use the following topology:

Above you see 3 routers and two zones called LAN and WAN. We will configure ZBF on R2. For connectivity, I’ll create a static route on R1 and R3 that points to R2:

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

R3(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2

Now we can configure the firewall.

Configure the Zones

First we will create the two zones, we only have two of them:

R2(config)#zone security LAN
R2(config)#zone security WAN

Secondly we will assign the interfaces to the correct zone:

R2(config)#interface fastEthernet 0/0
R2(config-if)#zone-member security LAN

R2(config)#interface fastEthernet 0/1 
R2(config-if)#zone-member security WAN

Let’s verify the configuration of the zones:

R2#show zone security 
zone self
  Description: System defined zone

zone LAN
  Member Interfaces:
    FastEthernet0/0

zone WAN
  Member Interfaces:
    FastEthernet0/1

The zones are active and interfaces have been assigned to them, now we can create the zone pairs.

Configure the Zone Pairs

R2(config)#zone-pair security LAN-TO-WAN source LAN destination WAN
R2(config-sec-zone-pair)#description LAN-TO-WAN TRAFFIC

R2(config)#zone-pair security WAN-TO-LAN source WAN destination LAN
R2(config-sec-zone-pair)#description WAN-TO-LAN TRAFFIC

Above I create two zone pairs. One for traffic from our LAN to the WAN, and another for traffic from the WAN to our LAN. A description is optional but recommended if you have many zones. Let’s verify our configuration:

R2#show zone-pair security 
Zone-pair name LAN-TO-WAN
Description: LAN-TO-WAN TRAFFIC
    Source-Zone LAN  Destination-Zone WAN 
    service-policy not configured
Zone-pair name WAN-TO-LAN
Description: WAN-TO-LAN TRAFFIC
    Source-Zone WAN  Destination-Zone LAN 
    service-policy not configured

Now we have zones, zone pairs and interfaces that are assigned to the zones. By default all traffic will be blocked. Let’s see if this is true:

R1#ping 192.168.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

As you can see I’m unable to ping from one zone to another by default. Our next step is to implement some security policies to decide what we are allowed to do or not.

Security Policies

Security policies are similar to policy-maps for QoS with the MQC where we use class-maps to select traffic. There are three actions that we can apply to traffic:

• Pass: traffic is permitted.
• Drop: traffic is dropped.
• Inspect: traffic is permitted and inspected so that return traffic is allowed.

We’ll start with a simple security policy that allows ICMP traffic from the LAN to the WAN:

R2(config)#class-map type inspect ICMP
R2(config-cmap)#match protocol icmp

R2(config)#policy-map type inspect LAN-TO-WAN
R2(config-pmap)#class type inspect ICMP
R2(config-pmap-c)#inspect

I will create an inspect class-map that uses NBAR to match ICMP traffic and a policy-map called LAN-TO-WAN to assign an action to the class-map. I will use inspect as it will allow the traffic to pass from the LAN zone to the WAN zone but also allows the return traffic. Now we can apply the policy-map to the zone pair:

R2(config)#zone-pair security LAN-TO-WAN
R2(config-sec-zone-pair)#service-policy type inspect LAN-TO-WAN

Policy-maps are directly attached to the zone pair that we created earlier. Let’s verify that our configuration is working:

R1#ping 192.168.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

As you can see our ping from R1 to R3 is now successful. What about the other way around?

R3#ping 192.168.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

ICMP traffic from R3 to R1 is now allowed as expected. To check the current active security policies you can use the following command:

R2#show policy-map type inspect zone-pair 
 Zone-pair: LAN-TO-WAN

  Service-policy inspect : LAN-TO-WAN

    Class-map: ICMP (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:30]

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

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        4 packets, 96 bytes

Above you can see that ICMP traffic is allowed from the LAN zone to the WAN zone while all other traffic (class-default) will be dropped.

Let’s create another rule, let’s say that R3 is allowed to telnet to R1. We’ll create a new class-map, policy-map and attach it to the correct zone-pair:

R2(config)#class-map type inspect TELNET
R2(config-cmap)#match protocol telnet

R2(config)#policy-map type inspect WAN-TO-LAN
R2(config-pmap)#class type inspect TELNET
R2(config-pmap-c)#inspect

R2(config)#zone-pair security WAN-TO-LAN
R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-LAN

Let’s verify our configuration:

R3#telnet 192.168.12.1
Trying 192.168.12.1 ... Open

As you can see above we are now able to telnet from R3 to R1.

R2#show policy-map type inspect zone-pair | begin WAN-TO-LAN
 Zone-pair: WAN-TO-LAN

  Service-policy inspect : WAN-TO-LAN

    Class-map: TELNET (match-all)
      Match: protocol telnet
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [0:20]

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

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

As you can see telnet traffic is allowed, all other traffic will be dropped.

Zone Self

With the configuration above we have security rules between the LAN and WAN zones, but what about R2 itself? Is it protected by our zone based firewall? Let’s find out!

R3#telnet 192.168.23.2
Trying 192.168.23.2 ... Open

R3 is able to telnet to R2 without any problems. This is because R2 doesn’t belong to the WAN or LAN zone but to another zone called the self zone. By default all zones are allowed to reach the self zone, so if we don’t want this we’ll have to create another zone pair:

R2(config)#policy-map type inspect WAN-TO-SELF

I will create a policy-map called WAN-TO-SELF but I won’t use any class-maps. By default there is always the class-default and it will drop all traffic. Let’s create the zone pair:

R2(config)#zone-pair security WAN-TO-SELF source WAN destination self
R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-SELF

Let’s verify our work:

R3#ping 192.168.23.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show policy-map type inspect zone-pair WAN-TO-SELF
 Zone-pair: WAN-TO-SELF

  Service-policy inspect : WAN-TO-SELF

    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        15 packets, 360 bytes

Above you can see the drops in the class-default. This will prevent the WAN zone from sending traffic to the self zone. The LAN zone will still be able to reach R2.

I hope this example has helped you to understand zone based firewalls, if you have any questions feel free to ask!

Copyright protected by Digiprove © 2013 Rene Molenaar
Read more: http://networklessons.com/security/zone-based-firewall-configuration-example/#ixzz2luuZfIZ0