Category Archives: Firewalls

Basic Configuration of the Cisco Zone-based Policy Firewall in Transparent Mode

In previous posts we studied many aspects of the Cisco Zone-based Policy Firewall (ZFW) operation:

  • How the ZFW compares with Context Based Access Control (CBAC)
  • Building blocks of a Zone-based firewall policy
  • The default deny behavior of the ZFW
  • How to build a simple L4 policy with the Zone firewall
  • How to log connections and dropped packets a ZFW environment
  • Integration of the Zone firewall with Access Control Lists (ACLs)
  • How to integrate the ZFW with Network Address Translation (NAT) and ACLs

The next step in our series about the Zone-based Firewall is to illustrate a basic configuration for ZFW operating in transparent mode. If you are not acquainted with the basic concepts pertaining to transparent firewalling, please check the post: “Quick Review of Firewall Connectivity options: Routed Mode and Transparent Mode” [ https://alexandremspmoraes.wordpress.com/2012/01/19/quick-review-of-firewall-connectivity-options-routed-mode-and-transparent-mode/ ].

It is easy to observe in the reference topology that the building blocks for the zone-based firewall policy are identical to those already studied. The significant change has to do with connectivity and not with rule construction. The figure also registers an audit-trail message and the command used to verify established sessions.

Reference topology for the Cisco Zone-based Policy Firewall in transparent mode
** Notes:
  • The audit-trail message and the show policy-firewall session command clearly show that the connection initiator (10.5.5.1) and the responder (10.5.5.2) are on the same IP subnet.
  • As discussed before, we could add L3/L4 restrictions to the basic inspection policy.
  • The ZFW interfaces shown in the figure (F0 and F1) are assigned to bridge-group 1.
  • The IP address of the ZFW needs to be configured in a Bridged Virtual Interface (BVI). Specifically, interface bvi 1, to match the bridge-group number. It is important to emphasize, however, that this IP is not used as a gateway address when hosts on interfaces F1 and F0 need to communicate.
  • To interconnect this BVI with the other IP-enabled interfaces, you need to enable Integrated Routing and Bridging (IRB) on your Cisco IOS router. This is accomplished with the bridge irb and bridge 1 route ip configuration commands.

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Quick Review of Firewall Connectivity options: Routed Mode and Transparent Mode

Before it can start enforcing access control policies between domains of trust, firewalls need to be inserted in the network topology. The two basic firewall connectivity options, Routed Mode and Transparent Mode,  are briefly examined below:

  • Routed Mode: in such an arrangement, the firewall works as a Layer 3 element (much like a router) from the perspective of hosts connecting to it. Each of its interfaces is assigned to a different logical subnet and the packets are conditionally routed between them. In the reference scenario, the inside interface has the IP address 192.168.2.2, whereas the outside uses the address 172.20.20.2. Considering that the hosts are interconnected by the firewall, machines on the inside need to configure the address 192.168.2.2 as their L3 gateway in order to reach outside destinations.
  • Transparent Mode: the firewall acts as conditional (transparent) bridge, forwarding frames between interfaces using Layer 2 information. In this case, the two interfaces represented in the figure are connected to the same L3 subnet and the inside hosts use the external router (192.168.1.1) as their gateway to reach outside destinations. The great motivation for this connectivity model  relates to the fact that the firewall can be inserted in the network without impacting the existent IP addressing scheme (which may be quite convenient in various situations).

    Contrasting firewall connectivity options: routed-mode and transparent-mode

A technical term may sound not so intuitive the first time you hear it. For example, during a presentation, a customer once told me that he did not understand why “his transparent firewall was blocking everything“. “After all, it was supposed to be transparent…”

I just registered this situation to emphasize one key point: the term “transparent” relates with “transparent bridging” (the basic bridging technology for Ethernet interfaces). It is used with connectivity in mind and does not imply less security.

Actually, as we will see in other posts, the construction of firewall policies is basically the same for transparent and routed modes.

** Notes:

  • Transparent mode is often called bridge mode. (Why ?)
  • A transparent firewall is sometimes referred to as a stealth firewall (because it is not used as an L3 gateway).
  • A transparent firewall is very interesting to add filtering capabilities between elements that require L3 adjacency. This is the case for two neighbor routers running an Interior Gateway Protocol (IGP) such as OSPF or EIGRP.
  • Another common use of a transparent firewall is in a multicast routing scenario. The firewall just bridges the multicast packets and does not participate in multicast routing.

** Topics for Study:

  • Do a quick review of transparent bridging technology
  • What is a Bridged Virtual Interface (BVI) ?

** Related Posts:

 

Leave a comment

Filed under English, Firewalls, Security

Deploying the Cisco Zone-based Policy Firewall with ACLs and NAT

After presenting the correct way of adding ACL restrictions to a Cisco Zone-based firewall policy, it is time to examine how Network Address Translation (NAT) interacts with a Cisco ZFW deployment. Our particular environment (Figure 1) actually contains a combination of stateful inspection, an L3 rule (ACL) and NAT.

To facilitate understanding, we start by briefly describing our reference scenario:

  • Inspection (controlled by class-map TOP-CLASS2) defines that only those application protocols carried over TCP are allowed from the OUTSIDE to the INSIDE zone.
  • The ACL2 access-list limits the source hosts (subnet 172.18.2.0/24) that can initiate inbound connections to the server 10.5.5.5.
  • The two previous conditions are united under the match-all class-map JOINT2.
  • The server address 10.5.5.5 is seen on the global address space (after source NAT) as 172.18.2.5.

Figure 1: Reference scenario combining Cisco Zone-based Firewall, ACLs and NAT

If you ever integrated Cisco IOS regular interface ACLs with NAT, you will notice that the ACL used by ZFW now refers to the real address of the destination host (instead of the mapped address). This is a critical change to be aware of.

Figure 2 provides further visibility for the topology under analysis, in the specific case of a telnet session initiated by the outside client (172.18.2.20) and bound to the translated address of the server (172.18.2.5):

  • The first Syslog message shows how the address translation is created.
  • The audit-trail log message highlights that the responder is 10.5.5.5 (real address), meaning that the ZFW process understands NAT.
  • The show policy-firewall session command confirms that the inbound connection is established with the real address (from the ZFW standpoint).

Figure 2: Details about the Zone-based Firewall, ACLs and NAT integration

** Topics for Study:

  • Think about the integration of a classic IOS interface access-list with NAT. What is the advantage of referring to the real address (as done by ZFW) ?
  • Revisit some other categories of IOS NAT (for instance, destination NAT and Port Address Translation). How can you display the active translations ? Can you have more than one interface configured with the ip nat outside command ?
  • Consider the integration of CBAC with NAT and ACLs. Does CBAC refer to the real address ?  Or to the mapped address ? (Why ?)
  • Rebuild the ACL shown in this example using the concept of object-group.

** Related Posts:

2 Comments

Filed under English, Firewalls, Security

Integrating ACLs with the Cisco Zone-based Policy Firewall

A previous article about the Cisco Zone-based Policy Firewall (ZFW) exemplified the construction of a simple L4 policy. Several other posts in the ZFW series underlined the fact that we cannot use interface ACLs in a ZFW environment (to avoid breaking the stateful inspection activities).

The current post builds upon our past discussions and documents the correct way of configuring ACLs within a zone-based firewall policy.

The focus of the policy structure depicted below is on the class-map called JOINT1, which specifies two simultaneous conditions that must be met for packets to flow from the INSIDE to the OUTSIDE zone:

  • Inspection happens at L4 for application protocols that use either TCP or UDP transport. This is governed by the class-map TOP-CLASS1, already studied in the article Building a simple policy with the Cisco Zone-based Firewall.
  • Restrictions that involve combination of source and destination addresses and L4 ports are imposed the extended access-list ACL1. This ACL is called by the match-all class-map JOINT1.
Sample Zone-based Firewall policy that includes an Access Control List
The figure also shows a simple Syslog message associated with the scenario. An NTP session from the host 172.18.1.10 to the server 172.18.2.20 was allowed by class JOINT1. This means that this particular connection was in accordance with both rules contained in this class.
** Notes:
  • The object-groups referred to by access-list ACL1 are those defined in the post ‘The use of object-groups in Cisco IOS software’.
  • There is no interface ACL in this setup. The ACL rules are taken care of as part of one of the building blocks of a Zone-based firewall policy. It is important to emphasize that this is the correct manner of inserting L3/L4 restrictions into a basic ZFW L4 inspection policy.
  • The log keyword cannot be configured as part of an Access Control Entry (ACE) that is used inside a ZFW class-map.
  • Newer releases of IOS allow you to list the existent class-maps and policy-maps with the show running-config class-map and show running-config policy-map commands.

** Topics for study:

** Related Posts:

 

Leave a comment

Filed under English, Firewalls, Security

The use of object-groups in Cisco IOS Software

Access Control Lists (ACLs) have been available for quite while and represent a very useful resource for activities such as packet filtering and traffic classification. This latter usage of ACLs has applications in many practical scenarios, some of which are listed below:

  • Filtering routing updates
  • Defining the interesting traffic to be encrypted by an IPSec tunnel
  • Establishing traffic that will undergo Network Address Translation (NAT)
  • Differentiate traffic classes using criteria such as source and destination addresses, IP protocol type and L4 ports involved.

Cisco IOS 12.4.20T added support to object-groups, a feature that undoubtedly helps anyone that needs to deal with access-lists. Figure 1 brings a set of sample network and service object-groups and teaches how to display those groups already configured.

Figure 1: Sample IOS object-groups

Figure 2 demonstrates the structure of the IOS Access Control Lists that employ object-groups. It should be observed that the logic of ACL contruction, in this case, is a bit different. Instead of specifying a sequence of sources, destinations and services, this new type of IOS ACL refers to service object-groups, source network object-groups and destination network object-groups (in this order). Figure 2 includes a practical example of IOS ACL that uses the sample object-groups defined in Figure 1.

Figure 2: Structure of IOS Access Control Lists (ACLs) that use object-groups

 
 
Figure 2 brings some additional information about Cisco IOS:
  • The ip access-list logging hash-generation command is used to correlate an Access Control Entry (ACE) enabled for logging with the Syslog message it generates. This important feature was introduced in IOS 12.4.22T and may be used by management tools to locate an entry in the rule table upon receipt of a Syslog message.
  • The show running-config | section command was used to display the  occurrences of access-list statements. Notice that this is more than a simple string match.
** Topics for study:
  • Investigate how the show running-config | section command compares with other CLI output filtering options such as show run | include and show run | begin.
  • Contrast the construction logic of IP extended ACLs with the access-lists presented in this post.
  • Reproduce the network topology shown in Figure 1 ( including the ACL and object-groups) and analyze the log messages issued by the IOS router.
  • Research the other options available for the object-group command. Is it possible to specify a range of IP addresses ?

Leave a comment

Filed under English, Firewalls, Security

Logging dropped packets with the Cisco Zone-based Policy Firewall

The previous post about the Cisco Zone-based Policy Firewall (ZFW) discussed how to log connection setup and termination. The current one will focus on making information about dropped packets visible (by means of Syslog messages). The auxiliary configuration element that gets the job done is the parameter-map type inspect that has the reserved name global.

Figure 1 brings a summary of the topology and associated ZFW policy employed in the posts so far.

Figure 1: Reference topology and associated ZFW policy

Figure 2 shows how to turn on the logging of packets dropped by the Cisco Zone-based Policy Firewall. Some points to be aware of:
  • This action of logging dropped packets is disabled by default.
  • The settings inside the global parameter-map apply to all the classes and are not available as options under the default or user-defined parameter-maps (which were analyzed in the previous ZFW post).
  • When a packet is dropped by the drop action under a class, the class name is registered in the Syslog message.
  • Syslog messages that represent packets dropped as a result of the default denybehavior (which was the subject of a previous post) do not contain a class name.

    Figure 2: Logging dropped packets with the Cisco Zone-based Policy Firewalls

 ** Topics for Study:
  • Compare the parameter-maps examined up to now: default, global and user-defined.
  • Contrast the tasks of logging connections and dropped packets in a ZFW scenario.
  • Make sure you understand the difference between class-based drops and packets dropped by the default-deny behavior of the ZFW.
  • Remember that the default and global categories of parameter-maps were introduced in Cisco IOS 15.X. Pre-15 releases used a different syntax to log dropped packets.

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Logging connections in the Cisco Zone-based Policy Firewall

In a previous post, we learned how to build a simple policy with the Cisco Zone-based Policy Firewall (ZFW). The current post goes one step further, by discussing some connection logging tasks in a ZFW environment.

The feature in charge of generating the Syslog messages related to connection setup and teardown for the ZFW is named audit-trail, which, as can be verified in Figure 1, is set to ‘off’ by default.

To modify this original behavior in the sample scenario of Figure 1, we defined a new parameter-map called TRACKING and bound it to the  TOP-CLASS1 class-map, as part of the inspect action. (It is simportant to emphasize that  all the other settings of the Default parameter-map remained unchanged).

This approach of creating a customized parameter-map brings more flexibility to the deployment because you could have, for instance, another class-map without the audit-trail mechanism enabled.

Figure 1: Parameter-maps and the Cisco Zone-based Policy Firewall (ZFW)

Figure 2 brings two sample audit-trail syslog messages for a telnet session going from the INSIDE zone to the OUTSIDE. It also teaches how to display information about an active connection by means of the show policy-firewall session command.

Figure 2: Sample audit-trail messages for the Cisco Zone-based Policy Firewall

 ** Topics for Study:

** Related Posts:

1 Comment

Filed under English, Firewalls, Security

Building a simple policy with the Cisco Zone-based Firewall

This quick post is aimed at illustrating the relationships among the ZFW building blocks available in the Class-Based Policy Language (CPL). To achieve that, we will build a very simple ZFW policy that employs only L4 inspection.

Some important aspects to observe in the scenario of Figure 1:

  • The top-level class-map TOP-CLASS1 specifies that only UDP and TCP connections are allowed from the source to the destination zone. Any other traffic (such as ICMP, GRE or IPSec) will be blocked when trying to flow from the INSIDE to the OUTSIDE zone.
  • The inspect action in the TOP-CLASS1 class-map is in charge of creating the entries in the state table (for allowed connections) and handling return traffic.
  • There is no interface ACL in this scenario. It is important to emphasize that interface ACLs are not part of a ZFW structure because they do interfere in the return traffic, thus breaking stateful inspection. The correct way of leveraging ACLs will be covered in another post.
  • The reserved class named class-default takes care of dropping and logging the packets that do not fall in the definition of the TOP-CLASS1 class-map.
  • Given that ZFW policies are unidirectional in nature, no connections can be initiated from the OUTSIDE zone to the INSIDE. (Unless we define a second zone-pair security statement interconnecting the OUTSIDE to the INSIDE).
  • In the event you needed to add another internal interface to the environment (for instance F2), the basic requirement would be to assign F2 to the INSIDE zone. (All the settings in the OUTBOUND1 policy would automatically apply).
  • In this first example we are not worried about specific application protocols or IP address restrictions yet.

Figure 1: Sample ZFW Policy using only Layer 4 Protocols

Figure 2 registers some important commands to verify ZFW policy structure:

  • The show zone security command provides information about the security zones already configured in the router. Notice that there is a system defined zone called SELF, which includes the router addresses. (Packets to and from the router on a ZFW scenario are handled by the SELF zone, which will be discussed in another post).
  • The show policy-firewall config zone-pair command summarizes the ZFW building blocks in use. It is a quick way of viewing the policy structure.

Figure 2: Viewing ZFW Policy Structure

 

** Related Posts:

 

 

Leave a comment

Filed under English, Firewalls, Security

Zone Policy Firewall: Understanding the default deny behavior

As mentioned in the initial post about the Zone-based Policy Firewall, the Cisco’s ZFW approach provides a much easier way of materializing the default-deny behavior that characterizes dedicated firewall appliances.

The following figure illustrates three typical situations that may happen on a ZFW environment:

  • Scenario 1: the source and destination interfaces have been assigned to security zones but there is no policy definition (connecting these two zones) yet.
  • Scenario 2: the source interface has not been assigned to any zone and is trying to connect to a router interface that belongs to a security zone.
  • Scenario 3: only the destination interface is assigned to a security zone.
Sample scenarios with default-deny behavior on the ZFW

It is important to observe that all of the cases represented in the previous figure relate to implicit drops promoted by the ZFW (and not a drop condition configured inside a user-defined class-map ). This second category of drop will be dealt with in a specific post: Logging dropped packets with the Cisco Zone-based Policy Firewall.

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Building Blocks for a Cisco Zone-based Firewall policy

This post briefly discusses class-maps and policy-maps (the main components of a ZFW policy) and their relevant attributes. If you are familiar with QoS configuration on Cisco IOS routers, you will quickly detect the similarities between the Class-based Policy Language (CPL) and the MQC (Modular QoS CLI). One important difference to be highlighted is that ZFW employs type inspect class-maps and policy-maps (and not the regular maps used within the QoS domain).

A class-map type inspect is used to identify groups of packets that have some property in common. Two simple examples are the group of HTTP packets (classified by means of a match protocol statement) and packets that travel from network A to network B (classified with the aid of an access-list bound to a match access-group statement).

A policy-map type inspect is employed to assign actions for classes previously defined with class-map type inspect commands. The available actions for packets that meet the selection criteria for a certain class are inspect, pass, police and drop. A brief description of each of these actions follows:

  • inspect: used to detect connection requests and provide the appropriate openings for return traffic. (Similar to what is achieved with the ip inspect command within a CBAC environment).
  • pass: this unidirectional action is equivalent to a permit statement inside an ACL and is not capable of handling return traffic. The pass action fits well for dealing with stateless flows such as traffic encrypted with Encapsulating Security Payload (ESP) protocol.
  • drop: corresponding to the ACL deny statements, this action is used to block undesired traffic trying to cross the firewall. The policy-maps of type inspect include a reserved class named class-default, which typically provides an easy way of discarding packets that did not fall in any of the previous classes (within the policy-map).
  • police: designed to provide rate-limiting functionality for classified traffic that is subject to the inspect action. (Not available for the special purpose class called class-default).

The Class-based Policy Language (CPL) provides a very structured and logical way of building firewall policies. You normally start by defining classification criteria for flows (by using class-maps) and refer to these classes within a policy-map (sequence of actions applied to classified packets).

The next step is to employ zone security statements to establish the domains of trust in a given topology (‘zones’) and rely on zone-pair security commands to define the source and destination zones to which the ZFW policy will apply. It is important to observe that:

–  The policy-map is attached to the zone-pair security using a service-policy type inspect command.

– The service-policy type inspect is activated when you assign router interfaces to zones (by using ‘zone-member security‘ commands at the interface level).

– You can have a set of predefined policy-maps that are applied on demand to an existent zone-pair. This is useful, for instance,  if you have a situation in which policy may change during the working hours or for troubleshooting purposes. (It is very helpful to think about your possible policies and their building blocks before you need to deploy them…)

– If you assign two interfaces to different zones without defining a zone-pair security, there will be no traffic flowing between these zones (and, consequently, no connectivity between the interfaces belonging to them).

The relationships between the elements of ZFW policy are summarized in the following figure.

Building Blocks for a ZFW Policy

** Related Posts:

 

Leave a comment

Filed under English, Firewalls, Security