Backgroound Image

Cisco ISR Project – Cloud Web Security config (13 of ?)

In our deployment each location will have a dedicated internet connection.  Since we want to restrict access to specific URLs (sorry, no porn, no Netflix, and no Facebook) we need each location to have a filter in place.  However, that seems cumbersome to manage.  It would be nice to have a centralized management point for all locations, as they will all have the same policy.

Enter Cisco Cloud Web Security.  There is an ISR connector that routes all web traffic through Cisco datacenters where traffic policies are applied.  First things first, this is a subscription-based service, so a subscription must be purchased.  Once that is done and the account is set up (the purchaser will receive a couple e-mails on account creation and provisioning) then it’s time to get things moving.

Before starting the configuration two things must be done. A company key needs to be created, and a certificate needs to be downloaded.  To create the key log in to the CWS portal and click the Admin tab, then in the menu bar select Management, and then click Company Key.

Company Key

Make sure you store the company key in a secure location.  If you lose it you will need to revoke and regenerate it, which means that all devices will also need to be reconfigured.

There should also be an e-mail sent with a certificate that must be installed on the router to establish the CWS tunnel.

Now on to the actual configuration.  You will need to have the following information handy:

  • CWS certificate
  • LAN subnet
  • Tower 1 IP
  • Tower 2 IP
  • Company key

First, the certificate install.  From a config prompt run these commands:

crypto pki trustpoint cws-trustpoint
revocation-check none
enrollment terminal
cry pki authenticate cws-trustpoint

It will prompt you to enter the certificate.  Paste in the certificate (including the Begin and End lines).  After the certificate enter a blank line and then hit the Enter key.  It should then prompt to accept the new certificate.

The next step is to create a couple ACLs.  The first is a simple ACL to specify the source LAN, and the second is a whitelist of IP addresses to avoid CWS.

access-list 80 permit      

ip access-list extended cws-whitelist
 permit tcp any
 permit tcp any
 permit tcp any

Make sure to enter the correct LAN subnet in ACL 80.  If there are any additional IPs that should be added to the whitelist then add them to the cws-whitelist ACL.

Next is importing the Cisco CWS certificate from Cisco.  This does require external access and DNS to be configured on the router.  Here’s the command for that import:

crypto pki trustpool import url

Now comes the actual CWS tunnel configuration:

parameter-map type cws-tunnel global
tower ipv4                                              
tower ipv4                                             
license 0  123123123123                                             
redirect-list 80
download interval 10
acl name cws-whitelist

Make sure to set the correct Tower IPs, and enter the Company Key that was generated through the CWS portal.  One thing to be aware of is the “fail-open” line.  This line configures the router to allow all web traffic if there is a CWS failure.  This can be configured to drop all traffic by changing it to “fail-close”

Almost done, the next step is to set the inbound and outbound interfaces for the tunnel.

int gi0/0/0cws-tunnel in

int gi0/0/1cws-tunnel out tunnel-number 150

For each interface (and sub-interface) that will have end-user traffic that needs to be filtered use the “cws-tunnel in” command.  For the outbound connection the tunnel number must be specified.  This will automatically create two tunnels, one for the tunnel number specified, and another tunnel that is incremented by 1.  In the example above tunnel 150 would be created as primary, and tunnel 151 would be created as a backup.  The primary tunnel uses the destination of Tower 1, and the backup uses the Tower 2 IP.

Last comes some commands to make CWS play nice with the IWAN configuration that’s been done so far.  Since there are VRFs, and ZBF rules there are some extra steps.

Configure the IKE profile to use the IWAN-SECONDARY VRF:

crypto ikev2 profile cws_ikev2_profile_150
 match fvrf IWAN-SECONDARY

Create a route map for routes back to the inside network:

route-map INET-Internal permit 10
 description Return routing for Local Internet Access
 match ip address InternalNetworks
 set global

The last step is to apply the VRF, route map, and zone membership.

interface Tunnel150
 description CWS connector internal primary tunnel
 ip vrf forwarding IWAN-SECONDARY
 tunnel vrf IWAN-SECONDARY
 zone-member security Internet
 ip policy route-map INET-Internal 

interface Tunnel151
 description CWS connector internal secondary tunnel
 ip vrf forwarding IWAN-SECONDARY
 tunnel vrf IWAN-SECONDARY
 zone-member security Internet
ip policy route-map INET-Internal

Running the command “show cws-tunnel status” should show the tunnel as being UP-ACTIVE

From a client machine you should be able to browse to and see the correct Company name.

Security control mapping – CIS CSC Top 20, NIST CSF, and NIST 800-53

I am working on a security project with a colleague, and instead of tackling one of the bigger standards we decided to create a road map and work towards it.  Essentially, the goal is to align with NIST 800-53.  That framework is way too complex for an environment with essentially a non-existent security policy.  Instead, we will tackle the CIS Critical Security Controls (SANS Top 20, CSC, or whatever else you want to call it) first, then the NIST CyberSecurity Framework (CSF), and then tackle the NIST 800-53.

The CSC is designed with the idea that it focuses on the most critical controls, so it is the best starting point.  By layering NIST CSF we add more controls, but they are less critical.  Finally, NIST 800-53 is where we would hit a level of maturity.  The nice thing with all of these is that the frameworks do build on each other.  Controls in CSC can be mapped to the CSF and 800-53, and the controls in CSF can be mapped to 800-53.  This means that work done on one control isn’t wasted.  The issue that we had was actually understanding what that meant for the overall project.  How much mapping was actually happening?

Before getting into the answer to that question we’ll look at the controls discussed.

The CSC framework has 20 controls, NIST CSF has 98 controls, and NIST 800-53 has 256 controls.

Here are links to info about each control:

CSC Poster This shows all the controls, a bit of detail on each, the background of the CSC, and has the mapping info for other controls.

To actually get the CSC controls you have to sign up here.  There’s some good info there, which includes a file with the mapping info in Excel format, the controls in Excel, a PDF with more detail on each control, and a PDF on testing and validating an environment based on the CSC framework.

The NIST CSF info can be found here, and here’s the Excel file with the controls.  The Excel file also contains the mapping info.

Then there’s the NIST 800-53, which can be found here.

Now, a quick note: This info is based off CSC v.6, NIST CSF (I believe it’s 1.0, but I can’t find version info) and NIST 800-53 Rev. 4.

With the mapping of controls I only wanted to find unique controls that were mapped.  There are often times where multiple controls map to a single control.  I counted the first, and excluded the subsequent.  This means that controls later in the list are likely to have fewer mappings listed as they are not mapping to unique controls.  Also, just because a control is mapped does not mean it is complete.  It’s more like it is started, and will likely need to be revised when looking at the higher frameworks.

On to the fun-

If you complete the CSC then it would map to 67 of the 98 CSF Controls (68.37%)

If you complete the CSC then it would map to 114 of the 256 800-53 Controls (44.53%)

If you complete the CSF then it would map to 155 of the 256 800-53 Controls (60.55%)

If you complete the CSC, then do the CSF it would map to 193 of the 256 800-53 Controls (75.39%)

As you can see, there’s definately a benefit to working through the controls in this order.

Now, like a good student, I am going to show my work.  The attached Excel file is a list of all the mapping info.  I compiled information from the above sources to make this.  The layout is the same as I had previously used.  The first four tabs list the details of the controls that are mapped, as well as the controls that are missed.  Then there are three “Summary” tabs with the specific control data removed.

Download the mapping file.

Cisco ISR Project – Guest network config (11 of ?)

Since offering a Guest Wifi network has become a pretty standard practice it’s something that will be added to the ISRs at the branch locations.  However, since this is a guest network it is untrusted and should not have access to the internal network.

The first step is to create a VRF for the guest network.  This will prevent traffic from the guest network from ever being exposed to the routes to the internal network.

vrf defInition IWAN-Guest

    address-family ipv4


The guest machines will require DHCP, so the router will be configured to hand out IPs.  For the DHCP range the was selected, and the IPs from 1 to 19 are excluded.  The Google DNS server at is set as the guest DNS server.

ip dhcp excluded-address vrf IWAN-Guest

ip dhcp pool IWAN-Guest

    vrf IWAN-Guest




 Next comes the class maps for traffic filtering.  We are going to allow DHCP and ICMP between the router and the guest network, as well as allow outbound traffic.  Based on the security needs ICMP can be removed, and the protocols allowed outbound can be restricted.

class-map type inspect match-any Guest-RTR-ICMP

    match access-group name Guest-ICMP-In

class-map type inspect match-any RTR-Guest-ICMP

    match access-group name Guest-ICMP-Out

class-map type inspect match-any Guest-RTR-DHCP

    match access-group name Guest-DHCP-In

   class-map type inspect match-any RTR-Guest-DHCP

 match access-group name Guest-DHCP-Out

class-map type inspect match-any Guest-Outside-Class

    match protocol dns

    match protocol http

    match protocol https

    match protocol ftp

    match access-group name Guest-Out

The policies are configured to pass DHCP traffic and inspect everything else.

Policy-map type inspect Guest-Outside-Policy

    class type inspect Guest-Outside-Class


    class class-default


Policy-map type inspect Guest-Self-Policy-In

    class type inspect Guest-RTR-DHCP


    class type inspect Guest-RTR-ICMP


    class class-default


Policy-map type inspect Guest-Self-Policy-Out

    class type inspect RTR-Guest-DHCP


    class type inspect RTR-Guest-ICMP


    class class-default


A zone will need to be created for the guest network

zone security Guest

The new zone will need to be configured to communicate with the router and internet zone, and the policies will need to be applied

zone-pair security Guest-Router source Guest destination self

    service-Policy type inspect Guest-Self-Policy-In

zone-pair security Router-Guest source self destination Guest

    service-Policy type inspect Guest-Self-Policy-Out

zone-pair security Guest-Internet source Guest destination Internet

    service-Policy type inspect Guest-Outside-Policy

 Next the guest interface will be created.  The VLAN 999 is being assigned for the guest network, and so a correlating subinterface will be created.  The IP used here needs to match the default gateway that was set earlier in the DNS settings

interface GigabitEthernet0/0/0.999

    description Guest-Network

    encapsulation dot1Q 999

    vrf forwardIng IWAN-Guest

    ip address

    ip nat inside

    zone-member security Guest

 Then a NAT statement is required to translate addresses.

ip nat inside source route-map NAT-Guest interface GigabitEthernet0/0/1 vrf IWAN-Guest overload

 A static route is needed to allow access to the outside network.

ip Route vrf IWAN-Guest GigabitEthernet0/0/1

A route map was used in the NAT statement to identify inside machines, so that route map needs to be created

Route-map NAT-Guest permit 10

    match ip address Guest-Internet

    match interface GigabitEthernet0/0/1

Lastly, we will create the ACLs.  Again, these ACLs can be adjusted to restrict traffic as needed.

ip access-list extended Guest-DHCP-In

    permit udp any eq bootpc any eq bootps


ip access-list extended Guest-DHCP-Out

    permit udp any eq bootps any eq bootpc


ip access-list extended Guest-ICMP-In

    permit icmp any any echo

    permit icmp any any echo-reply


ip access-list extended Guest-ICMP-Out

    permit icmp any any echo

    permit icmp any any echo-reply


ip access-list extended Guest-Internet

    deny ip

    deny ip

    deny ip

    permit ip any


ip access-list extended Guest-Out

    permit ip any

Now all that is needed is to assign the Guest SSID to VLAN 999 and configure switch ports accordingly.

Cisco ISR Project – Router access rules (9 of ?)

Now that most connectivity has been configured the next step will be creating access rules to restrict access as needed, as well as grant access where needed.  This is going to primarily apply to the branch routers, but the HQ routers can (and should) be configured similarly.

Before we get into what that means let’s cover how this is going to work.

Much to my chagrin, gone are the days of the “permit any any established” rules.  Those have been replaced with packet inspection to perform the stateful firewall feature.  What this means is that inbound packets are inspected to see if they match an existing outbound flow.  If the traffic is part of an established flow then it is allowed.  If not, then it’s dropped.

This gets a bit more complicated with the addition of the Zone-based Firewall (ZBF) in the ISR.  Instead of applying rules to the interface they are applied to the zone pairs.

Here’s the high level flow.

  1. Class maps are created (and specify ACLs as needed)
  2. Policy maps are created (and specify class maps as needed)
  3. Security zones are created
  4. Zone pairs are created, with source and destination specified, then the policy map is applied
  5. Interfaces are assigned to security zones
  6. ACLs are created for traffic definitions

Maybe a diagram will help.  This diagram shows the commands needed to allow traffic to flow from the inside IP range of from the inside interface Gi0/0/0 to any IP on the outside interface Gi0/0/1.  Lines in red are the commands.

Access Control

For the ISR deployment there are a number of rules that we need to allow for the creation of VPN tunnels on the external interfaces.  Now, let’s get to what the basic config will look like.

This is all CLI commands, so you will need to be at a config prompt.  The first command is simply logging packets that are dropped by the policies.

parameter-map type inspect global

 log dropped-packets

The next step will be class maps.  There are five maps, inside to outisde, and then both pass and inspect traffic between the outside and the router.

class-map type inspect match-any Inside-Outside-Class

    match protocol ftp

    match protocol icmp

    match protocol udp

    match protocol tcp

class-map type inspect match-any Inspect-ACL-Out-Class

    match access-group name ACL-RTR-Out

class-map type inspect match-any PASS-ACL-In-Class

    match access-group name ESP-In

    match access-group name GRE-In

class-map type inspect match-any PASS-ACL-Out-Class

    match access-group name ESP-Out

class-map type inspect match-any Inspect-ACL-In-Class

    match access-group name ACL-RTR-In

Next comes the policy maps.  These are the policies that specify the classes that were just created.

Policy-map type inspect Inside-Outside-Policy

    class type inspect Inside-Outside-Class


    class class-default


Policy-map type inspect ACL-In-Policy

    class type inspect Inspect-ACL-In-Class


    class type inspect PASS-ACL-In-Class


    class class-default


Policy-map type inspect ACL-Out-Policy

    class type inspect Inspect-ACL-Out-Class


    class type inspect PASS-ACL-Out-Class


    class class-default


By looking at the policies it’s easy to see that we will be passing inbound ESP and GRE traffic (the ACLs will follow), as well as outbound ESP traffic.  Everything else that is allowed through the ACLs will be inspected.

The next step will be to create the security zones for the ZBF.

zone security Internet

zone security MPLS

zone security default

For now we are just creating a zone for each connection type.  More zones will be added later as the config is built out.

Now that the zones are created we create zone pairs, which link a source and destination zone and apply one of the policies that were created to the traffic between those zones.  One thing to be aware of is the router itself uses the “Self” zone.  That means that traffic to the router will use the “Self” zone, so we can use that in the zone pairs.

zone-pair security Router-Internet source self destination Internet

    service-Policy type inspect ACL-Out-Policy

zone-pair security Router-MPLS source self destination MPLS

    service-Policy type inspect ACL-Out-Policy

zone-pair security Inside-Internet source default destination Internet

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Inside-MPLS source default destination MPLS

    service-Policy type inspect Inside-Outside-Policy

zone-pair security Internet-Router source Internet destination self

    service-Policy type inspect ACL-In-Policy

zone-pair security MPLS-Router source MPLS destination self

    service-Policy type inspect ACL-In-Policy

The next step is to associate the interfaces with the corresponding security zones.  Since there are only two actual zones (Internet and MPLS) this is pretty straightforward.  All the other interfaces are using the default zone for now.  Replace the interface in red with the correct interface for your deployment.

int gi0/0/1

    zone-member security Internet

int gi0/0/2

    zone-member security MPLS

Now the only thing left to do would be to create the ACLs.  The ACLs here are based off a Cisco IWAN document.  There are a number of areas where they can be tweaked.  The obvious change would be disabling ICMP if that is a requirement for your environment.  Another change would be to put in specific addresses instead of “any” for the VPN related rules.  I would strongly recommend making at least the inbound rules more restrictive.

ip access-list extended ACL-RTR-In

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any echo

    permit icmp any any echo-reply

    permit icmp any any ttl-exceeded

    permit icmp any any port-unreachable

    permit udp any any gt 1023 ttl eq 1

ip access-list extended ACL-RTR-Out

    permit udp any any eq non500-isakmp

    permit udp any any eq isakmp

    permit icmp any any

    permit tcp any any eq 8080

    permit udp any any eq domain

ip access-list extended ESP-In

    permit esp any any

ip access-list extended ESP-Out

    permit esp any any

ip access-list extended GRE-In

    permit gre any any

Now that these rules are in place the routers should still establish the VPN tunnels, and traffic from the outside world should be restricted.