Security Archives - My Tech Gnome

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

Posted on July 27, 2016February 9, 2023 by Dan Kelcher

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
exit
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 1.2.3.4 0.0.0.0

ip access-list extended cws-whitelist
permit tcp any 10.0.0.0 0.255.255.255
permit tcp any 172.16.0.0 0.31.255.255
permit tcp any 192.168.0.0 0.0.255.255

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 http://www.cisco.com/security/pki/trs/ios_core.p7b

Now comes the actual CWS tunnel configuration:

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

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 http://whoami.scansafe.net and see the correct Company name.

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

Posted on June 13, 2016February 9, 2023 by Dan Kelcher

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 ?)

Posted on May 20, 2016February 9, 2023 by Dan Kelcher

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

exit-address-family

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

ip dhcp excluded-address vrf IWAN-Guest 192.168.254.1 192.168.254.19

ip dhcp pool IWAN-Guest

vrf IWAN-Guest

network 192.168.254.0 255.255.255.0

default-Router 192.168.254.1

dns-server 8.8.8.8

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

inspect

class class-default

drop

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

class type inspect Guest-RTR-DHCP

pass

class type inspect Guest-RTR-ICMP

inspect

class class-default

drop

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

class type inspect RTR-Guest-DHCP

pass

class type inspect RTR-Guest-ICMP

inspect

class class-default

drop

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 192.168.254.1 255.255.255.0

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 0.0.0.0 0.0.0.0 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 192.168.254.0 0.0.0.255 192.168.0.0 0.0.255.255

deny ip 192.168.254.0 0.0.0.255 172.16.0.0 0.15.255.255

deny ip 192.168.254.0 0.0.0.255 10.0.0.0 0.255.255.255

permit ip 192.168.254.0 0.0.0.255 any

!

ip access-list extended Guest-Out

permit ip 192.168.254.0 0.0.0.255 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 ?)

Posted on May 20, 2016February 9, 2023 by Dan Kelcher

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.

Class maps are created (and specify ACLs as needed)
Policy maps are created (and specify class maps as needed)
Security zones are created
Zone pairs are created, with source and destination specified, then the policy map is applied
Interfaces are assigned to security zones
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 10.0.0.0/8 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

inspect

class class-default

drop

Policy-map type inspect ACL-In-Policy

class type inspect Inspect-ACL-In-Class

inspect

class type inspect PASS-ACL-In-Class

pass

class class-default

drop

Policy-map type inspect ACL-Out-Policy

class type inspect Inspect-ACL-Out-Class

inspect

class type inspect PASS-ACL-Out-Class

pass

class class-default

drop

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.