Tuesday, August 13, 2013

Zone-Based Policy Firewall, Part 2

In my previous post I touched on the four parts (Zones & Zone Members, Class Maps, Policy Maps and Zone Pairs) which make up a ZFW configuration. In this post I will explain the "actions" which are used to tell the router how to handle inbound and outbound traffic flows.

Actions

Actions are applied to Class Maps which as they're being nested in Policy Maps. (Don't worry if that sentence confuses you, it'll all become clear when I show you an example a little later on). As per Cisco's website, there are three actions to choose from:
  • Drop - Drops packets which are matched by the Class Map.
  • Pass - Allows packets which are matched by the Class Map through in one direction
  • Inspect - Works exactly like CBAC.

Drop

The "drop" action does exactly what its name implies - it drops traffic which is matched by a Class Map. A great place to use this action is the connection between your WAN interface and the router's "self" zone. You might recall at the end of my last post I mentioned that all traffic destined for and sourced from the router (aka the "self" zone) is allowed by default. By implementing the "drop" action you can close off this security hole.

Pass

Out of the three, the "pass" action is the most difficult to comprehend. It's not so bad, it's just that the other two are just really simple to understand.

The "pass" action allows traffic to flow in one direction only. If you'd like the return traffic to make it through the firewall, you must implement another "pass" rule which matches the return traffic. For example, if your PCs are connected to Fa0/0 ("LAN" zone) and your internet is connected to Fa0/1 ("WAN" zone), and you wanted to allow the PCs to access websites only, you'd need to do the following:

Source Zone: LAN-Zone
Destination: WAN-Zone
Match Criteria: Any Source IP & Any TCP Port Number to Any Destination IP & TCP Port Number 80

Source Zone: WAN-Zone
Destination: LAN-Zone
Match Criteria: Any Source IP & TCP Port Number 80 to Any Destination IP & Any TCP Port Number

As you can see, the two rules are mirrors of each other. The first rule allows the web request to go out and the next rule allows the web server's response back in. If you only implement one of the above rules the web browsing would not work.

You may be wondering why anyone would bother using the "pass" action when it would seem that the "inspect" action (see below) does exactly the same thing, but it only requires half the effort! Well, there are two reasons that I can think of off the top of my head.

The first reason is that "pass" uses less resources than the "inspect". This is because "pass" simply allows the traffic to go through, whereas "inspect" needs to track each and every connection and its state.

The second reason is that "inspect" cannot be used on traffic sourced from or destined for the router's "self" zone. This therefore means that if you want to control traffic to and from the router (rather than permitting it all as is the default), you can "pass" traffic which specifically matches your Class Maps. Doing this gives you the best of both worlds - it drops the traffic which is not supposed to be sent and received and passes the traffic which is.

Inspect

Finally we have "inspect". Inspect does exactly what a lot of people expect out of their firewalls after dealing with home-grade routers which do SPI (Stateful Packet Inspection). It "watches" the traffic that goes out and only allows the specific return traffic back in. All other inbound traffic is dropped. Further to this, once the connection is closed the return traffic will no longer be allowed through the firewall and it too will be dropped.

To put it simply, specific firewall rules are dynamically created and removed as needed to ensure only requested traffic is allowed through the firewall. This provides a level of security which the "pass" action does not. This is because "pass", if configured in the Outside to Inside direction will allow all traffic in, regardless of whether it is return traffic which was requested by an Inside host or if it is new traffic which was initiated by an Outside host.

Now let's take a look at the example we saw in the "pass" section above. Again, let's say your PCs are connected to Fa0/0 ("LAN" zone) and your internet is connected to Fa0/1 ("WAN" zone), and you want to allow the PCs to access websites only. This is how you'd do it:

Source Zone: LAN-Zone
Destination: WAN-Zone
Match Criteria: Match Protocol HTTP

Here we can see two things - The first is that the required configuration is half the size of the "pass" configuration. The second thing is that there is a "match protocol" statement instead of an ACL-like statement. By using "match protocol" the router will is able to perform protocol specific firewalling where required - for example, where FTP is concerned. (If you're not too sure what I mean, have a quick read about Passive and Active FTP connections and the port numbers which they use).

Summary

In conclusion there is no "best" action out of the three. They each have their uses and more often than not you may find that you use a combination of the three in all of your setups.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Monday, August 12, 2013

Zone-Based Policy Firewall, Part 1

Cisco's Zone-Based Policy Firewall (ZFW) can be quite confusing when you first start looking in to it, so over the next couple of blog posts I hope to provide readers with some useful information. Having said that, I'll do my best to avoid reinventing the wheel given that Cisco has already done a great job of documenting ZFW.

ZFW Parts

ZFW is made up of several "parts", which, once all put together form a fully functional firewall. These parts are:
  • Zones & Zone Members
  • Class Maps
  • Policy Maps
  • Zone Pairs

Zones & Zone Members

As the name suggests, ZFW requires that you put interfaces in to zones. The idea is that you put your interfaces in to zones and then apply inter-zone firewall rules which will permit or deny traffic flows.
There are two types of you need to be aware of:
  • User Configurable
  • "self"
User Configurable zones are zones which you configure yourself (dah!). How many you create, what you name them and how many interfaces you assign to the zones to is totally up to you. For example, if you have three interfaces which are used for LAN traffic and one interface which is used for WAN traffic, you may want to create a "LAN" zone and a "WAN" zone and put the interfaces in to their corresponding zones. Alternatively, you may use one interface for your LAN, another for your Servers and another for your WAN. You could then create a "Server" zone along with the "LAN" and "WAN" zone and have each interface allocated to its own zone.

The "self" zone is completely different to the User Configurable zone. For starters, you cannot rename it and you cannot allocate any interfaces to it. Instead, the "self" zone is a system zone which is dedicated to permitting and denying traffic destined for the router itself. For example, telnetting or SSH'ing in to the router to configure it.

Finally, a Zone Member is a the term used to describe an interface which has been put in to a zone. For example, if you put Fa0/0 in the "LAN" zone, it is a member of the "LAN" zone.

Zone Traffic

Cisco's "Rules For Applying Zone-Based Policy Firewall" explains what happens when traffic flows through these zones. However, I feel that their explanations may be a little too techy for those who are new to the subject so below I have provided my translations:

  • A zone must be configured before interfaces can be assigned to the zone.
  • An interface can be assigned to only one security zone.

You must define zones that you want to use (e.g "SERVER", "LAN", "WAN" etc). Once you have done that, you need to put your interfaces in to their corresponding zones. Note, interfaces can only be put in to a single 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.

If you put Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone, hosts connected to these two interfaces will not be able to communicate by default. However, if both interfaces were in the same zone (e.g "WAN"), they will be able to communicate by default.

  • 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.

To allow two hosts who reside in different zones (e.g  Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone) you need to configure a policy.

  • 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.

Unlike the situation mentioned above where traffic between Fa0/0 in the "LAN" zone and Fa0/1 in the "WAN" zone is not allowed by default, traffic which is destined for the router itself is allowed by default. In other words, hosts connected to Fa0/0 and Fa0/1 can telnet, ping, SSH, SNMP poll, etc the router without having to configure any policies.

  • 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.

As mentioned previously, if Fa0/0 and Fa0/1 are in the same zone, they can communicate with one another by default. If they are in different zones they cannot communicate by default, but a policy can be configured to allow it. However, this dot point explains that if Fa0/0 is in the "LAN" zone and F0/1 has not been put in to any zone, hosts connected to these interfaces will not be able to communicate at all.

  • 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).

Situations may arise where you want to use ZFW on some interfaces but not others. For example, you want to use ZFW on your WAN interface but you don't deem it necessary to use it on your LAN and Server interfaces. As mentioned above you can't simply put your WAN interface in a ZFW zone and leave your LAN and Server interfaces without zone configurations as zoned and non-zoned interfaces cannot communicate. The solution to this problem is to put your LAN and Server interfaces in to a zone and configure it to "pass" all traffic. (I will expand on this point in my next blog post).

  • 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.

I'm not too sure why Cisco put this dot point at the end of the list given that it appears that they're making reference to the "self" zone dot point earlier on in the list. Anyway, this point is saying that "although traffic to and from the self zone is enabled by default, a policy can be implemented to restrict the traffic which is destined for the router.

Before I wrap this section up I must stress the importance of implementing a policy on the "self" zone. As mentioned above, all traffic sourced from and destined for the router (aka the "self" zone) is permitted by default. This means that if you've got telnet, SSH, HTTP, HTTPS, SNMP, FTP, etc enabled on your router, be aware that by default people on the internet can also attempt to exploit these protocols.

Class Maps

Class Maps are used to to define the firewall rules. You can create as many as you like and use them on as many zones as you like (through the use of a Policy Map). Further to this, using the the "match-any" and "match-all" statements in your Class Maps allows for very granular rules.

Policy Maps

Policy Maps are used to group multiple Class Maps in to a single policy. (More on this in my next blog post).

Zone Pairs

In order to apply your firewall rules, you must attach a Policy Map to a Zone Pair. (This will also be expanded on in my next blog post).

Update 

Part 2 of this series has been published.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Sunday, August 4, 2013

Subnetting Made Easy, Part 3

Note: For the previous post in this series, please see the "Subnetting Made Easy, Part 2" post.

Recently I received an e-mail from a reader who was having trouble with one of their labs. The lab required them to write an ACL which matches only part of a subnet, as opposed to the whole subnet which is what is commonly seen in lab environments. The details are as follows:

Network Address: 192.168.0.192 /27
Usable Addresses: 192.168.0.193 - 192.168.0.222
Subnet Mask: 255.255.255.224
Wildcard Mask: 0.0.0.31

The range of addresses inside the subnet which need to be matched are:

Match Addresses: 192.168.0.193 - 192.168.0.206

In order to create the ACL, the author needs to find out which wildcard mask matches only the above mentioned addresses.

The Solution

The solution I use to answer this question is the same one I use when I'm summarising routes. I convert the necessary octet to binary and then find the least significant bit that matches both the lowest IP address and highest IP address in the range. In this case the details are as follows:

Octet: 4th (given that the network address is a /27)
Lowest IP: 192.168.0.193
Highest IP: 192.168.0.206

            /25 /26 /27 /28 /29 /30 /31 /32
            128  64  32  16   8   4   2   1
Network:     1    1   0   0   0   0   0   0  = 192
Lowest IP:   1    1   0   0   0   0   0   1  = 193
Highest IP:  1    1   0   0   1   1   1   0  = 206

As highlighted above, first, second third and fourth most significant bits match. The fifth bit however, does not. This therefore means the fourth bit is the one we're looking for. From this we can deduce the following:

Network Address: 192.168.0.192 (the 192 is because of the 128 + 64 as shown above)
Subnet Mask: 255.255.255.240 (/28) - (This is because the four most significant bits match)
Wildcard Mask: 0.0.0.15 - (Inverse of the Subnet Mask - 255 - 240 = 15)

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.