Using black hole routing for network security monitoring – Part1

The average Network Administrator has control over all the tools to put in place effective black hole routing and reporting. The simple steps below should get you started and the prerequisites to getting there.

Executive summary

Static black routing and policy based black hole routing are great ways to securely offload traffic from your core routers or firewalls. The traffic that ends up being dropped could be known source or destination networks that should not be routed, but they could also be unexpected, misconfigured or malicious traffic that is being dropped. Keeping an eye on this traffic could pay off big time. NSM at work! But first how to do the basic setup.

Prerequisites

  • A spare router running Cisco IOS 12.2.x and up
  • A spare network tap or mirror port on your core route
  • A spare distributed network analyzer or workstation with wireshark
  • Console port access or out-of-band access to the router via a secure terminal server

An alternate way of processing the incoming traffic directly in a honeypot described here.

Physical setup

  • Connect the network tap to your core-router
  • Connect your black-hole-router to your network tap.
  • Connect your analyzer to the replication port of your network tap.
  • Connect your router to your out-of-band access

Logical setup on a cisco IOS router with a test route

    • Apply secure configuration guidelines to protect your black-hole-router. *
    • Configure a point to point routed interface on black-hole-router and your core-router.
    • Create the appropriate routing process
    • Make the black-hole-router a sub that will only advertise static routes
    • Add a redistribute static statement to your routing process
    • Create a null0 interface
    • On null0 configure no ip unreachable
    • Now create a test black hole route: ip route 10.255.255.1 255.255.255.255 Null0
! Example using eigrp IGP   

!   

ip classless   

!   

interface null0   

 no ip unreachable   

 no shutdown   

!   

router eigrp 1   

 redistribute static   

 eigrp stub static   

 network x.x.x.x # replace x.x.x.x with the network of the point-to-point interface   

 no auto summary   

!   

ip route 10.255.255.1 255.255.255.255 null0
  • Verify the route is showing up in the core router.
  • Send traffic to it from another network location. This traffic should be blackholed on the router. Check with your traffic analyzer, with a debug statement or a logged ACL on your router.

Applying the black hole route on a cisco IOS router Here you need to choose what type of black hole route to use. Can you inject a default black hole route, specific black routes routes or both. Your network may be architected so that you already have a black hole route somewhere that could be migrated to your new setup. You may wish only to black hole routes to certain networks (ie. bogon networks, known “bad net blocks” or AS). Use a bit of DNS foo to blackhole “bad” domains, sub-domains or FQDNs.

! Example using eigrp IGP   

!   

ip route 0.0.0.0 0.0.0.0 null0   

!

By creating a black hole route, all traffic that is now destined to networks with no explicit routing entries will end up on your new black hole router. After applying the route, the first order of business is making sure you have not broken anything during your maintenance window. You are doing this work in your lab or at least in a maintenace windows right, ;-). Make sure you can still reach your application servers, your proxies, external NATs, etc. Once you are satisfied save your configuration on the router.

Now, fire up your network analyzer. Traffic can now be categorized

  • There should be your typical misconfigured hosts, moritoring servers, deprecated DNS entries sending traffic to networks that do not exist.
  • Workstations trying to update software using non-proxied ports from internet vendor servers.
  • Management/monitoring software scanning ports of IPs for auditing purposes
  • And the famous other category

Yeah, fun with “other”. Non browser based applications trying to send web or ftp traffic without going through the designated proxies. Applications trying to reach internet addresses for which there are no proxy services. Having worked hard at designing your network to make use of NAT and proxies, you get to have a much easier time tracking down the above classes of traffic.

Benefits of this easy win approach

  • Cleaning most of the above classes of traffic will be beneficial for fixing operational problems.
  • Storing this traffic in your network analyzer can serve as an easy to maintain forensic archive for infection vectors.
  • A very cheap alternative to a honeypot.
  • Forensic history of problematic sources in the managed network.
  • Provides a list of workstations and their associated users that are risks to the managed LAN.
  • An easy way to archive the presence of traffic that was marked for deletion by other systems. (Policy based routing, DNS, proxies)
  • Can serve as a source of automated tickets for ops and events for security folks. As what needs to be fixed is always on the managed side of the LAN or WAN.
  • I would love to hear about other benefits

* – SANS IOS security guidelines or other security focused templates. Any mistake on this router can have nasty consequences. All your routers should be equally secure, audited, logged, change controlled, monitored and backed up.