Monthly Archives: January 2012

Cisco Firewalls and user-based access-control

The current post concentrates on the creation of rules that may include, not only the IP addresses of source and destination systems interconnected by Cisco firewalls, but also identity information related to the users initiating the connection requests. Before we start creating this new category of rules, it is advisable to get familiar with a set of relevant concepts.

The AAA (Authentication, Authorization and Accounting) architecture defines a modular way for these three security functions to interact. The AAA components may be easier visualized if associated with the questions they were designed to answer:

  • Authentication deals with answering the question “who is the user ?”
  • Authorization is in charge of defining “what the user (previously authenticated) is allowed to do”
  • Accounting relates to the question “what the user did ?”. Through this process, the accounting client collects user activity information and sends it to the accounting server.

The AAA framework may be applied to provide identity-based control on two complementary domains:

  • Control of regular users that need to pass traffic through the firewall: the mechanisms employed by Cisco firewalls to materialize this functionality are the Cut-through Proxy (on ASA family) and Authentication Proxy (on IOS). RADIUS is optimized for this type of task.
  • Control of administrative users that are required to configure and monitor the devices themselves. TACACS+ is optimized for the tasks that involve command authorization and accounting.

The following figure summarizes typical questions that should be answered before you start configuring user-based access control through the firewall. Other posts will detail some of the available solutions.

The basics of user-based access control through Cisco firewalls

** Related Posts:


Leave a comment

Filed under English, Identity, Security

Cisco Zone-based Policy Firewall: Controlling Intrazone traffic

This post is intended to explain basic concepts pertaining to intrazone traffic within a Cisco Zone-based Policy Firewal (ZFW) environment. Before we start the discussion itself, it is relevant to emphasize that there have been major changes in the ZFW intrazone behavior since the inception of IOS 15.X.

On IOS 12.X releases, traffic between interfaces belonging to the same zone was allowed to cross the firewall without inspection.  More precisely, in this group of releases, it was not even possible to define intrazone ZFW policies.

Starting on IOS 15.0(1)M, intrazone traffic is blocked by default.
IOS 15.X releases allow the creation of intrazone policies (source and destination of traffic in the same zone). An example of such a policy is presented in the figure, for which we want to allow only ICMP and UDP traffic among interfaces that are member of the INSIDE zone.
It is important to observe that ZFW intrazone policies employ the same building blocks that have been used so far.

Controlling intrazone traffic with the Cisco Zone-based Policy Firewall

** Topics for Study:

  • Examine the show commands documented in this example.
  • Apply L3 restrictions to limit intrazone traffic. Your policy should only allow PING between the and subnets, while still permitting NTP from to the server.
  • What command can be used to display the ZFW policy structure ?

** Related Posts:


Filed under English, Firewalls, Security

Cisco Zone-based Policy Firewall: Understanding the self zone

In the articles presented so far, we have studied situations in which inspected traffic is crossing the router-based firewall (instead of being directed to any of the router addresses).

The default operation of the Cisco Zone-based Policy Firewall (ZFW)  is to allow traffic to an from the router interfaces,  irrespectively of zone-pair security settings. If there is a need to modify this behavior, a system-defined zone, whose reserved name is self, must come into the scene.

Although interfaces are not directly assigned to the self zone, this special zone handles packets travelling from any router interface to a non-self zone (and conversely). You should keep in mind, though, that policies involving the self zone are still unidirectional.

Some facts about our reference topology are registered below:

  • The policy construction employs the classic building blocks. The only particularity is that one of the interconnected zones is the self zone.
  • The OUT-SELF zone-pair security is controlling packets sourced from the OUTSIDE zone and directed to the router interfaces. Packets originated by the router are not being inspected.
  • Policies involving the self zone are more meaningful when they include L3 restrictions (materialized by ACLs).
  • The activation of logging occurs in the same manner as already analyzed for non-self zones.

Inspecting router-bound traffic with the Cisco Zone-based Policy Firewall

** Topics for Study:

  • Make sure you understand the handling of IOS object-groups.
  • Revisit the post related to ACL integration into a ZFW scenario.
  • Construct a ZFW policy to control traffic originated by the router and destined to the OUTSIDE zone. You should allow only ICMP Echo and Echo Reply messages from interface F0 to the subnet.
  • Update the ZFW policy analyzed in this post to limit telnet sessions going to the router. Telnet should only be allowed from sources located in the subnet and directed to the Fo interface.
  • Review the articles related to logging in the ZFW series (both for dropped packets and connection setup/teardown).

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

HTTP Inspection on non-standard ports with the Cisco Zone-based Policy Firewall

The current post uses the ip port-map command as an auxiliary resource to enable HTTP inspection on the Cisco Zone-based Policy Firewall (ZFW).

In our reference topology HTTP is enabled on ports 2002 and 2003 for host The ip port-map command simply instructs the router to treat these ports as HTTP and not as generic TCP. With this type of setup, any specific L7 configuration that applies to HTTP (on its default port) would equally be valid for the non-standard range of ports.

Inspecting HTTP on non-standard ports with the Cisco Zone-based Policy Firewall

** Topics for Study:

  • Play with the ip port-map command for other protocols. What is the default port for SIP ? And for MGCP ?
  • What is different in the audit-trail message in this example when contrasted to the connection logging messages for a single channel protocol like telnet ? (If needed, revisit previous posts in the ZFW series).
  • Does the ip port-map command apply to Context Based Access Control (CBAC) ?

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

FTP Inspection with the Cisco Zone-based Policy Firewall

Having analyzed the basic L4/L3 configuration  principles for the Cisco Zone-based Policy Firewall (ZFW), we will now illustrate some L7 options.

Before we start the practical examples, it is interesting to characterize the main usages of L7 inspection on a stateful firewall:

  • Fixing up misbehaved protocols, such as those that dynamically negotiate data connections inside the control channel. Classic examples are FTP and the telephony signaling protocols (SIP, H.323 framework, SCCP, MGCP).
  • Perform Network Address Translation (NAT) at the application level for those protocols that embed the IP address in the L7 messages. This is critical within NAT and Port Address Translation (PAT) environments.
  • Use the application knowledge to filter based on additional criteria pertaining to the specific L7 protocol, rather than just L4/L3.

The figure depicts a reference scenario for FTP inspection on the ZFW:

  • The INSIDE client starts an FTP session to the translated address of the server (
  • Instead of matching based on an L4 clause, there is a match protocol ftp statement under the class-map named L7-CLASS1.
  • The first audit-trail message shows the creation of the FTP control connection (over port TCP/21).
  • The second log message shows a sample FTP data session (and the corresponding NAT operation).

It is important to emphasize that in this sample network we are not performing any special filtering. We are just using L7 knowledge for fixup purposes.

Reference topology for FTP inspection with the Cisco Zone-based Policy Firewall
** Topics for Study:
  • Review basic FTP operations
  • What are typical commands (inside an FTP control channel) that trigger the setup of a data channel ?
  • It is important to compare these new audit-trail messages with those for single channel protocols that use TCP as transport (such as telnet in previous ZFW-related posts). What has changed ?

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

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” [ ].

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 ( and the responder ( 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, whereas the outside uses the address Considering that the hosts are interconnected by the firewall, machines on the inside need to configure the address 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 ( 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