Fun with Darknets

Published: 2007-07-08
Last Updated: 2007-07-08 01:21:16 UTC
by Kevin Liston (Version: 1)
0 comment(s)

When I write Darknet, I mean "a portion of routed, allocated IP space in which no active services or servers reside" not "a private virtual network where users connect only to people they trust."

Every environment is different, so you need to use the architecture to your advantage when placing your darknet sensors.  At one of my clients', they have a unique full-proxied environment where the desktops do not have direct outbound access to the Internet and all non-proxied Internet-bound traffic ends up on their core-routers where it times-out.  By placing a sensor in this loop I can capture all of the traffic initiated from internal clients that is trying to get out to the Internet but is not properly proxied.  This means that I see a lot of misconfigured traffic, but it also means I see all of the botnets trying to phone home. 

In it's initial stages I only had argus and p0f running on the sensor.  The drive would fill up within a week because of the huge amount of misconfigured traffic that was landing on the core-routers, traffic that served no purpose but only to die.  This type of traffic was caused by typos in syslog configs which sent firewall logs off to never-never land, or BOOTP requests intended for decommissioned servers, things of that nature.  After many weeks of working with operations teams we cleared up a lot of the wasted traffic and can now collect full-packet captures via snort for additional analysis.

An external sensor was placed to listen for traffic intended to an internal-only block of IPs.  On this sensor we see what scans are targeting our neighborhood of the Internet,  and backscatter from attacks that spoofs our IP space (for some reason, I only see the APAC region targeted this way.)

I've found that no single tool provides all of the information that I need.  Argus, with its assumptions about flows, doesn't always render backscatter properly and it's difficult to tell when a scan is targeting our network, or if our IP was spoofed to disguise a scan on another network.  Other times, full-packet captures are overkill and p0f logs are all I need to see if a particular scan hit us or not.  No single tool satisfies our requirements (no surprise there.)  I'm still thinking about what I want to use to synthesize all of these data-sources into a more-complete picture.

As a next step, I'm looking into running snort with a very stripped down rule-set (due to the nature of the Darknet, content-based rules are all but useless) to immediately notify our security staff of suspected internal infections (e.g. a SYN sent to establish an IRC connection to a known-malicious host,) and add some visualization via afterglow to see if that adds any capabilities to the analyst.

The Darknet has been very useful in confirming reports sent to the Handlers.  It's paid for itself by helping clean up misconfigured systems and aided in locating unmanaged infected systems on our network.  Darknets are also much safer and easier to justify to management than Honeypots.  So if you're looking for something fun to do at work, give a Darknet a thought.

----------------------------------------------------------------

Kevin Liston (kliston -at- isc.sans.org)

Keywords:
0 comment(s)

Comments


Diary Archives