Using black hole routing for network security monitoring – Part2

Black hole routing is now your friend. You are forwarding traffic not meant to be routed to a termination point on your network. Let’s look at some advanced ways to get more focused network security data from this traffic. For part 1, skip to the next post.

Advanced network monitoring

    • Forward the black hole routes to a passive Honeypot such as Nepenthes
      • This would entail having either the black hole router or the core router forward the traffic to the Honeypot as the next-hop for all the black holed routes.
      • The honey pot will accept connections and will let the operator know what the evil doer was up to. Ex. C2 channels, File transfers, protocol tunnelling, scanning, exploiting, etc.
    • Reconfigure or implement a DNS black list to point the blocked traffic to specific black hole networks. Traffic can be categorized using pre-built filters in the analysis station.
      • Known malware+spyware black list resolves to x.x.x.A
      • Domains, sub-domains or FQDNs that are unrelated to business needs (.tv, .sex) black list resolves to x.x.x.B
      • Domains, sub-domains or FQDNs considered security risks* (.ru, .cn, .ws, .cm, .info, etc.) black list resolves to x.x.x.C. Mcafee publishes a list of the riskiest TLDs, Mapping the mal web.
      • Blocked web sites due to company policy resolves to x.x.x.D
      • In maintenance or no longer available internal servers resolves to x.x.x.E
      • Other blocked content that is of no interest to network or security analysts resolves to 127.0.0.1
    • Advertise specific black hole routes that target nasty netblocks.
      • If there is a requirement in splitting traffic reaching specific routes, convert the link between the core router and the black hole router to an 802.1Q trunk with sub-interfaces. This way you can advertise each group of nasty routes on it’s own sub-interface. Reporting would know which 802.1Q tag is associated with which group of nasties.
      • The risk with explicitely blocking network blocks or domains, is the user community may not be aware they HAVE been blocked administratively. Such that a web page or email track back saying, hey the ressource you are trying to reach is blocked! Some type of advisory should be published that some domains or netblocks may be blocked, check list or contact your help desk.
    • Graph the traffic hitting each sub-interface or interface on the black-hole router using SNMP and Cricket or Cacti.
    • Run ntop, sancp or argus on the analysis station to get session data.
    • Find a way to generate tickets or events back into analysts consoles for interesting traffic hitting the black hole router.
      • 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

Recap of the benefits

  • Provides a looking glass into misconfigured, unauthorized, unexpected or inexistant traffic or destinations.
  • Cheap and easy to setup
  • Maintenance and operation can be very automated
  • Integrates with existing processes (ticketing, change management, backups, monitoring, logging)

Written by