Category Archives: English

Technical posts written in English.

The Evolution of Identity Services on Firewalls

The IP address is a basic attribute related to computer systems that rely on the TCP/IP protocol stack to establish network connectivity. As a result, the vast majority of access control rules deployed on Stateful Firewalls are based upon parameters present, for instance, in the IP,TCP,UDP and HTTP headers. Although this protocol-based approach has demonstrated to be powerful, the need for networks that are flexible enough to accommodate multiple classes of users (employees, contractors, guests) along with the increasing need for network mobility, has motivated the search for alternative ways of implementing access control. 

This article briefly examines the creation of firewall rules that include some sort of Identity-based information for the users initiating connection requests. As we will see later, in some scenarios identity information may also be associated with the servers.

The first generation is centered on the captive portal paradigm, mainly relying on downloadable ACLs to differentiate among users that are connecting through the firewall. The second, normally referred to as the ID Firewall, allows the creation of permissions based on MS AD user/group domain information. The third generation, known as the SGT Firewall, represents a true evolution because it provides integration not only between the firewall with the edge devices (such as wireless APs and LAN switches), which are the main source of user information, but also between the firewall with the switches that reside on the server side (as shown in the figure below).Image

To read the complete article, follow the link to the Cisco Support Community.

https://supportforums.cisco.com/docs/DOC-36198

** Additional Reading

  1. A more detailed description of the first generation (https://alexandremspmoraes.wordpress.com/2012/01/27/cisco-firewalls-and-user-based-access-control/)
  2. Illustrating the use of RADIUS Authorization Profiles on Cisco IOS  (https://alexandremspmoraes.wordpress.com/2012/02/02/cisco-ios-authentication-proxy-and-radius-authorization-profiles/)

 

Advertisements

Leave a comment

Filed under English, Firewalls, Identity, Security

FLEX VPN: Sample LAN-to-LAN configuration with Dynamic Routing

As a follow on to our FLEX VPN Overview  (http://wp.me/p1loe7-fJ) and to the first post presenting a sample configuration  (http://wp.me/p1loe7-hX), we will now examine a site-to-site scenario that relies on Cisco EIGRP to forward packets over the VPN tunnel. The only modification in our reference environment was the replacement of static routes by a dynamic routing protocol on the participant ISR G2 routers. Some new commands (not explored in the first article) will be used here in an attempt to help you build a tool set that might be handy on your monitoring and troubleshooting tasks.

Figures 1 and 2, respectively summarize the main settings on the HUB and on the SPOKE. Using a routing protocol not only brings scalability to your deployment but also simplies maintenance.

Figure 1: Main settings on HUB1

As depicted in the topologies, the EIGRP adjacency is built over the GRE Tunnel interface (whose subnet is 10.190.1.0/24). After the routers become neighbors, the LAN subnets that need IPSec protection services (10.200.101.0/24 on the HUB and 10.200.201.0/24 on the SPOKE) are advertised to the remote peer. Detailed reachability information for our sample network is provided in Figure 5.

Figure 2: Main settings on SPOKE1

Figure 3 registers the type of information unveiled by the show crypto ikev2 session detail command.

Figure 3: Detailed information about the IKEv2 Session

Figure 4 brings a partial output of the show crypto ipsec sa command and characterizes that the tunnel in place, which is secured by the profile IPSEC-PROFILE1, uses the GRE protocol (notice the permit 47 statement on the IPSEC FLOW).

Figure 4: Information about the IPSec SA and Tunnel interface

Figure 5 reveals connectivity details from the HUB perspective. The show ip route command clearly demonstrates that the EIGRP updates flow trough the GRE tunnel, whereas the show ip cef commands are insightful with respect to forwarding activities. Notice that the show ip cef exact-route even displays the underlying interface used to reach the tunnel destination (172.20.1.1, associated with Loopback 2000 on the SPOKE).

Figure 5: Routing and Forwarding information

It would be instructive at this point to compare the current scenario with that one covering static routes (http://wp.me/p1loe7-hX), document the commands already analyzed and make sure you understand the overall structure (and building blocks) of a FLEX VPN policy.

** Related Posts:

** Additional Reading:

Leave a comment

Filed under English, Security, VPN

Hello World: Simple LAN-to-LAN Flex VPN configuration

Having discussed the motivations behind FLEX VPN (http://wp.me/p1loe7-fJ) and presented information about positioning of Cisco IOS VPN solutions (http://wp.me/p1loe7-gy), it’s now time to jump to some practical scenarios.

Our site-to-site topology consists of two ISR G2 routers connected by a GRE interface, as depicted in Figures 1. The Integrated Services Routers rely on static routes to direct traffic to the tunnel and reach the protected networks (10.200.101.0/24 on the HUB1 site and 10.200.201.0/24 on SPOKE1 site). Authentication is performed by Pre-shared Keys (PSK) defined within a crypto ikev2 keyring. The main settings for this  environment are summarized for HUB1 and SPOKE1 on Figures 1 and 2, respectively.

This sample configuration is also useful to illustrate the overall structure of a FLEX VPN policy. The main building blocks are:

  • IKEv2 profile: basically defining how authentication is handled and what identities to consider. Settings such as the keyring (for PSK) and crypto trustpoint (for rsa-sig) are established here. The complete set of parameters contained in the IKEv2 profile are displayed with the show crypto ikev2 profile command.
  • IPSec Profile: determines the transform-set for IKE phase 2 (IPSec SA) and points to the IKEv2 profile. This type of profile is tied to the interface (similar to what we did for a crypto-map) by means of the tunnel protection ipsec profile command.

Other important entities (not shown in the configuration) are:

  • IKEv2 proposal: specifies the algorithms used to secure the IKE phase 1 SA. Take a look at Figure 3 and use the show crypto ikev2 proposal command to obtain more information about this policy component.
  • IKEv2 policy:  selects the IKEv2 proposal and VRFs where to place the VPN packets. Figure 4 registers the settings for the default IKEv2 policy.

Figure 1: Main Configs on router HUB1

It’s interesting to observe that FLEX provides extra flexibility with regards to the authentication process (that can even be asymmetric). Some possibilities are listed below:

  • The HUB can use a pre-shared key with all the spokes (which is not the ideal) but still have an individual key to authenticate each of the remotes. In previous models if the HUB had to share a key with all the spokes, that key would be known to all the routers involved. (And therefore it would be easy for spokes to spoof one another).
  • Digital certificates (rsa-sig method) can be used to authenticate both sides.
  • You can use digital certificates to authenticate the hub and PSK for the spokes.
  • There is also support for the Elliptic Curve Digital Signature Algorithm (ecdsa-sig) and for the Extensible Authentication Protocol (EAP).
  • Although you can configure only one local authentication method, multiple remote authentication methods are allowed, so that you can cope with different types of peers connecting to a certain router (normally the central element in your topology).

Figure 2: Main configs on router SPOKE1

Figure 3 provides visibility about the IKEv2 and IPSec SAs corresponding to our configuration. Notice that the show crypto session detail command is particularly useful to obtain summarized information about the Security Associations in place, interfaces in use for protected traffic and even encrypted/decrypted packets. The command also characterizes that the IPSec flow is protecting GRE packets (protocol 47) between HUB1 (172.20.20.11) and SPOKE1 (172.20.20.1).

Figure 3: Information about the IKEv2 and IPSec Security Associations

Figure 4 allows us to gain additional insight about this basic deployment. For instance, it reveals:

  • The default IKEv2 policy and how it binds to the default proposal (not shown in the configuration)
  • Some characteristics of the tunnel interface (source/destination, GRE-based, MTU and attached IPSec profile).
  • Another quick way of displaying encrypted and decrypted packets.

Figure 4: IKEv2 Policy, Tunnel Interface and Encrypted Packets

This is the very first article covering sample configurations… So stay tuned for more !

** Related Posts:

** Additional Reading:

Leave a comment

Filed under English, Security, VPN

Zone-based Firewall and Cisco Security Manager – basic concepts

The initial articles in the Zone-based Policy Firewall (ZFW) series concentrated on basic ZFW behavior and capabilities. The current post shift gears a little bit, by quickly discussing how the Cisco Security Manager (CSM) software can facilitate the operation and maintenance of a network protected by the Zone Firewall.

As depicted in Figure 1, if you are already acquainted with graphical configuration of firewall policies (for ASA and even other vendors’ products), you will notice that the philosophy is basically the same. The traditional logic for rule construction (involving sources, destinations and services) is still there… Yes, that’s it: benefit from the abstraction provided by CSM to build the logical rules and the software will take care of translating them to the CLI commands that materialize the ZFW functionality.

Figure 1 also illustrates another interesting possibility: you can create a ZFW policy on CSM and assign it to multiple devices. This is really relevant when you need, for instance, to deploy multiple branches that have similar rules.

Figure 1: Zone-based Firewall rule table on CSM

Figure 2 shows that you can import the active settings on a live Cisco IOS device and share it on CSM. It’s important to highlight that you can select the types of settings to be imported for later use (ZFW rules, AAA configuration, general platform information and much more).

Figure 2: Sharing device policies through CSMth

Figure 3 displays the CSM Configuration Archive feature, which allows you to keep track of configuration versions (a kind of information that is certainly useful for auditing and meeting compliance requirements). By selecting a saved configuration you can see the configuration commands delivered to the device (Transcript Viewer).

Figure 3: Configuration Archive and CLI Transcript

This was just a quick review of the CSM capabilities regarding the Zone Firewall. It’s naturally recommended that you review the previous ZFW posts and, if possible, that you navigate through the CSM GUI.

** Related Articles:

** Further Reading:

Leave a comment

Filed under English, Firewalls, Security

Firewalls and UC Security

Convergent networks that convey  data, voice and video in an integrated manner are spread all around. And this is not just because people consider convergence something fashionable but, rather, because organizations have realized how the concept of Collaboration can contribute to business efficiency and productivity. Of course this convergence promise sounds appealing but along with business relevance comes the responsibility of providing adequate security…

Network Security principles are well mapped and you might be asking what is so special about integrating voice and video.

I will start by saying that the new service possibilities associated with Collaboration are materialized by a set of application protocols that have specific characteristics and networking requirements and, as such, bring new challenges. As usual, from the perspective of network security professionals, the first step is precisely to understand the protocols involved.

And, please, never forget that there is no magic black box approach… Although firewalls constitute one indispensable protection element of an UC Security solution, there are many other resources that need to be taken into account for any practical implementation. For instance, LAN switch, router and IP Phone security features.

Read the complete article on the Cisco Support Community page…

https://supportforums.cisco.com/docs/DOC-24159

Leave a comment

Filed under English, Firewalls, Security

GET VPN or Flex VPN…? Do I need both ?

– How Flex is GET ? – What do you get from FLEX ?

On two recent posts we summarized the concepts and motivations pertaining to Flex VPN and GET VPN, two important IPSec-based solutions offered by Cisco. But the availability of these two VPN paradigms may eventually generate some confusion: – Which way to go ? – Do I need both… ?

The figure below provides the backdrop for our current discussion. The two technologies are actually complementary:

  • GET VPN is designed for use within environments that do not have the public/private addressing issue and is well suited for materializing what I frequently name the Secure Intranet Service. FLEX is more flexible in that sense because it allows you to deal with either Intranet or Internet-related scenarios.
  • GET VPN is tunnel-less in nature and aims at scenarios in which the trust level is shared by VPN participants. An attractive by-product of not using tunnels: GET is very adequate to encrypt multicast, because the same distribution tree built in the WAN to forward the clear text multicast packets is equally available for ciphered ones. (Remember the IP Header Preservation inherent to GET…)
  • FLEX is tunnel-based and is able to handle environments involving dynamic (on demand) tunnel setup between spokes, EasyVPN style deployments (when the remote behaves as a hardware client) and many more.
  • GET VPN employs group-based Security Associations (SAs), as opposed to the point-to-point SAs that appear on tunnel-based VPNs (including the FLEX VPN framework). Again, this is possible as a result of the trust level parity that characterizes remote sites on INTRANET-only deployments. This is not a limitation of FLEX, which was conceived to cover a broader spectrum of VPN styles ( for which you cannot assume the same trust level for every site).
  • GET VPN is used for site-to-site only, whereas FLEX VPN is able to work with site-to-site and Remote Access (RA VPN) deployments at once.
  • GET VPN was designed to take advantage of the inherent full-mesh capabilities of MPLS networks. Of course FLEX can be employed on any-to-any clouds but, given that it is tunnel-based, its logical configuration possibilities will be hub-and-spoke and spoke-to-spoke.
  • FLEX VPN requires IKEv2 while GET VPN currently supports only IKEv1. (Of course there are plans to add IKEv2 to the GET VPN side of life at some point in time… :-)) The key information to remember: immediate IKEv2 support is less critical for GET (which presupposes private transport) than for FLEX VPN, a technology aimed at tunnel-based scenarios that involve Internet-based transport.

Flex VPN or GET VPN: quick comparison

The good news: if you have a security license on your Cisco ISR G2, the two options are available simultaneously allowing you to select the option that better fits the needs of your specific environment (eventually you will end up employing both). Some general guidelines are presented below:

  • For INTRANET-only site-to-site scenarios, GET may prove very appealing. Policy distribution and key management tasks are centralized and the Group SA concept is really convenient. The other key differentiator (associated with its tunnel-less nature) is encrypted multicast.
  • On the other hand, for any environment that includes external connections (INTERNET, EXTRANETS and the like), go FLEX. It provides an unified and structured approach for VPN creation and can handle so many connectivity options. And, remember, it relies on IKEv2 for SA negotiation (much more secure than its v1 counterpart).
  • If you want to stick to a single way of dealing with all VPNs (site-to-site and Remote Access), FLEX is the answer. Although not offering the Group SA, it covers everything. As discussed in the FLEX article, you can end up with a single block of configuration at the hub and be prepared to terminate any VPN connection.
  • If necessary, you can still leverage both technologies at the same router (GET for INTRANET site-to-site interconnection) and FLEX for all the rest.

** Notes:

** Related Posts:

Leave a comment

Filed under English, VPN

Building secure and scalable INTRANETS with GET VPN

The term Virtual Private Network (VPN) is employed to define technologies designed to reproduce the characteristics of a private network even when traffic is being transported over a shared infrastructure. The common motivation behind the various VPN options are to extend the reach of corporate networks in a secure and inexpensive manner.

But the word security has a broad meaning and may represent very distinct resources when considered from the standpoint of each of the VPN technologies. For instance, two of the main categories of VPNs (IPSec and MPLS-VPN) are optimized to solve complementary problems and present challenges that are also complementary.  A brief summary is presented below:

  • The IPSec Framework provides answers for questions such as data confidentiality, integrity, peer authentication and management of cryptographic keys. And, interesting enough, all of these tasks are accomplished by means of standardized protocols and algorithms, a fact that contributed to render IPSec almost omnipresent when the subject is VPN. On the other hand, classic IPSec uses point-to-point negotiations between the communicating parties, which brings significant challenges, mainly in terms of routing, when deployed on a large network.
  • The MPLS-VPN service, by its own nature, provides logical segmentation of the transport network and optimized routing (any-to-any) but establishes no definition in what refers to the typical problems solved by IPSec (confidentiality, integrity and the like).

Keeping in mind the capabilities just presented, let’s consider the demand of building the Intranet of a large company that uses Unified Communications among its sites (the traffic nature is any-to-any) and that, in order to comply with market regulations, is supposed to take advantage of the services beneath the IPSec umbrella.

In an initial analysis, two simple-minded solutions could be provided:

  • Build IPSec Security Associations (SAs) between each remote entity and HQ. Well, this approach would not be satisfactory because it could compromise the acceptable end-to-end delay budget for voice traffic (150 ms). Moreover we would be giving up the full-mesh appeal of MPLS networks.
  •  Create sessions betwen each pair of remote sites, so that you keep inter-branch traffic from crossing HQ. Besides being almost unmanageable from a configuration point of view, such a scenario would require that each VPN gateway in the remote location (typically a router) supported a very large of concurrent tunnels, thus impacting the cost.

If the mere superimposition of IPSec on MPLS does not meet the specified project goals, would it be possible to develop a new technology that could benefit from the IPSec security services without losing the optimized connectivity provided by MPLS ?

As a matter of fact, this was exactly what Cisco did. Building upon RFC 3507 (Group Domain of Interpretation – GDOI) and assuming that on Intranets you don’t need to worry about the private/public address issue, the Group Encrypted Transport VPN (GET VPN) came to existence. The main charateristics of GET VPN are listed in the following:

  • Definition of group-based Security Associations instead of the traditional point-to-point SAs. This choice is justifiable because we are dealing with Intranets, in which the same degree of trustworthiness can be assumed for the remote routers.
  • The access control function, which allows a VPN gateway (Group Member or GM in the GET VPN context) to be accepted in a given group, is performed by an element called the Key Server (KS). The KS is also responsible for centrally distributing the cipher keys and encryption policies that will be used by the GMs.
  • IP Header Preservation in the encrypted packet, without changing the standard ESP format. This means that a GET VPN packet is a particular case of IPSec and, therefore, the algorithms and hardware in place can be reused.

GET VPN: IP Header Preservation

Some direct results of the basic GET VPN definitions:

  1. IP Header preservation ensures that the encrypted packets use the same routing table available for the clear text traffic, thus avoiding the creation of a new layer of routing for the VPN packets.
  2. The DSCP information is automatically copied to the external IP header and your Quality of Service (QoS) investments (classification and marking) remain valid for the VPN traffic.
  3. It is possible to account for network utilization on a per-user basis, irrespectively of packets being encrypted. This represents an advance in terms of visibility when compared to classic IPSec.
  4. Because Group Members (GMs) own the the key to decrypt the packets sent by any member of the group, the distribution of encrypted multicast traffic becomes natural ( in an identical manner that would be employed for clear text). It is important to highlight that GET VPN is the first technology to truly deliver on the promise of encrypting IP multicast (without requiring any tunneling artifice such as GRE).
  5. The management of encryption policies becomes much easier because it is centrally conducted by the Key Server. This is particularly relevant for Service Providers that will not need to configure VPN tunnels and interesting traffic definitions in hundreds of devices anymore.

Relationships between GET VPN elements

An important aspect to keep in mind is that a router enabled for GET VPN still comes with the classic IPSec solutions provided by Cisco. For example, you can leverage GET VPN to securely build your Intranet and traditional IPSec to establish a VPN connection though the Internet. Another fact to be aware of is that the same router may participate in multiple distinct groups, thus providing a simple solution to isolate departments within the same company.

** Additional Reading:

** Related Posts:

Leave a comment

Filed under English, VPN