1. Introduction
Internet security is important with the increasing attacks that are happening every day. Many internet and browsing security solutions exist, but some are not very easy to use or maybe the question is how can I enable them?
In this reference, we are detailing out a few options how browsing security can be provided to end customers leveraging various forms of redirect available in the XR software and acceleration by the hardware to provide high scale.
2. Concept
The concept of redirect is to intercept a packet from a subscriber that matches certain criteria and instead of forwarding it on to the regular destination, apply a special action to such packets so that customized responses can be given to the client.
In order to provide seamless security and on the right type of packet, the classification is of key, eg what are we trying to protect.
2.1 Intercept
To redirect, we need to intercept first, and there are various ways of defining what to intercept.
To review the simple basic session initiation there are different areas of where we can intercept:
The DNS request can be intercepted or the intial TCP handshake or at the HTTP session level.
All these different areas have pros and cons as to what value they can bring and have a bearing on the performance of the intercepting router.
2.1.1 HTTP interception
An HTTP interception is very neat as it will capture the original HTTP request from the client, possibly conditional to the ip address as to where it wanted originally to go to. The Interceptor replays in this case the TCP handshake giving the client the idea that it is talking to the server it wanted to connect with, but instead of provding a page with details, the interceptor provides a HTTP redirect directive page telling the browser to connect to a different server instead whereby a warning page or the like can be provided.
The following diagram shows how http redirect or intercept would operate
This methodology obviously requires a “lite” http server implementation or minimally a partial tcp stack to be able to complete the TCP handshake. In ASR9000/XR the http intercept/redirect implements a light-weight tcp stack that replays the sequence and ack’s depending on what the client expects and fakes that the response comes from the original intended server (“spoofing”).
It also needs to implement the ability to respond with a (customized) HTTP response providing that redirect.
Since the TCP stack in this implementation is not stateful and the response page is static, the performance is rather good as it only needs to reply with 2 packets per http session attempt.
The downside of this approach is that you need to main a list of IP addresses of bad servers that you want to be intercepted and redirected to the warning page server.
Generally, domain based redirections are better in case malicious servers change their IP, but generally keeping their domain name the same.
So intercepting DNS requests is probably a better alternative.
2.1.2 DNS interception
DNS interception is a simpler solution to implement, easier to maintain, more comprehensive and can provide more overall security. It eliminates the need of maintain a blacklist of ip addresses or anything that needs to be maintained on the router or gateway itself.
By using a DNS service that maintains a black list of domains, querying that server will allow for a better response based on the latest details.
The defacto cloud service for DNS requests like this is of course Cisco UMBRELLA.
By capturing the original DNS requests and sending them over to umbrella to provide the responses, the client will then be more sure to only connect to servers and services that are known to be clean”.
The redirection of these packets can be either by leaving the original IP headers in tact (and forcing them in a different way then what the routing table would have done), or we can rewrite the destination ip address to more easily send them to the right target server.
2.2 Redirect
In essence XR provides 3 ways of redirection:
- Access-list based Forwarding
- Layer 3 redirect
ABF allows for the original headers to be in tact, but routed differently not following the routing table. This requires the receiving host to accept the destination ip address in the header that is not his but it allows for the original packet headers to remain in tact.
L3 redirect is more powerful, as it won’t depend on intermediate routers to have the same routing policy. In fact since the destination is rewritten it naturally goes to the destination we would want.
3. Using Umbrella to provide security using Layer 3 redirects
Umbrella uses 2 well known anycast addresses notably 208.67.222.222 and 208.67.220.220
By intercepting any dns traffic and setting the destination domain servers to one of these addresses we can allow the cisco cloud service of Umbrella to provide us the latest responses for the designated servers for the requested domain/host.
IF the server/domain is classified as malicious one is returned the Umbrella security page explaining that a connection to a dangerous site/server was attempted.
When umbrella identified that you were attempting to connect to a bad page, a standard connection broke page is displayed from any of the anycast ip addresses like this:
Or a custom more “friendly” block page can be provided also based on your Umbrella policy:
3.1 Configuration template
The config consists of an access-list to capture DNS traffic (udp/53) and use that in a policy-map for PBR (policy based routing) to set a new destination ip address. This is all hardware accelerated and the checksum etc is all dynamically updated in the pipeline.
All unclassified traffic is transmitted as normal and left untouched.
Finally we apply this PBR policy map to the subscriber/user facing interface.
ipv4 access-list dns
10 permit udp any any eq domain
!
!
class-map type traffic match-any PBR-DNS
match access-group ipv4 dns
end-class-map
!
!
policy-map type pbr UMBRELLA
no class type traffic class-default
!
class type traffic PBR-DNS
set destination-address ipv4 208.67.220.220
transmit
!
class type traffic class-default
!
class type none class-default
transmit
!
end-policy-map
interface GigabitEthernet0/14/1/18.100
description ServiceInterface_to_USER
service-policy type pbr input UMBRELLA
ipv4 address 10.86.188.82 255.255.255.128
load-interval 30
encapsulation dot1q 100
3.2 Seeing it in action
The following sample topology is used for the demo of UMBRELLA using the configuration above.
For this lab test we’re not using the official UMBRELLA dns service, but a lab DNS server at address 10.86.188.49.
On the client we’ll initiate a domain resolution to the cisco official dns server ns1.cisco.com at 72.163.5.201
Clients configuration:
RP/0/RSP0/CPU0:A9K-BNG#sh run | i name-server
domain name-server 72.163.5.201
From the client we’ll initiate a name resolution via a ping to a hostname for a well known legitimate page like www.google.com and have the dns being redirected.
Here is the client log of what happens:
First lets look at the host cache of the device.
RP/0/RSP0/CPU0:A9K-BNG#sh hosts
Default domain is not set
Name/address lookup uses domain service
Name servers: 72.163.5.201
Host Flags Age(hr) Type Address(es)
mail.cisco.com (perm, OK) ** IP 173.36.7.6
There is only one static entry in here, and nothing else.
Now initiate the resolution to the name server.
RP/0/RSP0/CPU0:A9K-BNG#ping www.google.com
10:49:32.615 : domain_services[1173]: defaultnamelookup_vrf_search_node: Namelookup not present for VRF default.
10:49:32.615 : domain_services[1173]: domain_getname: VRF does not exist,defaultnamelookup_vrf_search_node fails
10:49:32.615 : domain_services[1173]: dns_vrf_search_node: VRF default not found in domainlist DB
10:49:32.615 : domain_services[1173]: name_cache_lookup_vrf: Domain list does not exist for VRF default.
10:49:32.615 : domain_services[1173]: defaultnamelookup_vrf_search_node: Namelookup not present for VRF default.
10:49:32.615 : domain_services[1173]: name_cache_lookup_vrf: Defaultdomain not present for VRF default
10:49:32.619 : domain_services[1173]: Domain Services: res_querydomain(www.google.com, (null), 1, 28)
10:49:32.619 : domain_services[1173]: Domain Services: res_query(www.google.com, 1, 28)
10:49:32.619 : domain_services[1173]: res_mkquery(0, www.google.com, 1, 28)
10:49:32.619 : domain_services[1173]: in res_send the value of v_circuit is 0
10:49:32.619 : domain_services[1173]: DNS domain_res_send: vrf-name default specified in the request: Error: No error
10:49:32.619 : domain_services[1173]: domain_res_send: try 0 of max 2
10:49:32.619 : domain_services[1173]: Querying server address = 72.163.5.201
10:49:32.619 : domain_services[1173]: defaultnamelookup_vrf_search_node: Namelookup not present for VRF default.
10:49:32.619 : domain_services[1173]: DNS: VRF default is not configuredfor source interface
10:49:32.619 : domain_services[1173]: domain_res_send: select timeout = 2
10:49:32.649 : domain_services[1173]: DNS query returns: reply code 0, number of answers 0
10:49:32.649 : domain_services[1173]: domain_res_send: try 1 of max 2
10:49:32.847 : domain_services[1173]: got answer
10:49:32.847 : domain_services[1173]: Get host entry for www.google.com from query
10:49:32.848 : domain_services[1173]: Start age timer 86400 sec for www.google.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 49.1.1.1, timeout is 2 seconds:....
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/14 ms
If we now check the DNS cache on this client, we can see the resolved domain and (fake) ipaddress:
RP/0/RSP0/CPU0:A9K-BNG#show hosts
Thu Oct 12 10:50:28.797 EDT
Default domain is not set
Name/address lookup uses domain service
Name servers: 72.163.5.201
Host Flags Age(hr) Type Address(es)
mail.cisco.com (perm, OK) ** IP 173.36.7.6
www.google.com (temp, OK) 0 IP 49.1.1.1
At the same time we can also verify the ASR9000 to see what it has been doing with the redirection with the following command.
RP/0/RP0/CPU0:ASR9922#show policy-map type pbr interface g 0/14/1/18.100
Thu Oct 12 11:02:16.882 EDT
GigabitEthernet0/14/1/18.100 input: UMBRELLA
Policy Name: UMBRELLA
Class PBR-DNS
Classification statistics (packets/bytes) (May be 10secs old)
Matched : 2/166
Transmitted statistics (packets/bytes) (May be 10secs old)
Total Transmitted : 2/166
Class class-default
Classification statistics (packets/bytes) (May be 10secs old)
Matched : 1837/118959
Transmitted statistics (packets/bytes) (May be 10secs old)
Total Transmitted : 1837/118959
4. Conclusion
Leveraging cisco umbrella without touching any clients is super simple with the ASR9000’s PBR capability to intercept and redirect DNS to umbrella!!
Xander Thuijs
Principal Engineer IOS-XR/ASR9000
Cisco Systems 2017