Using Sinkholes to Deploy Decoy Networks

A more novel use of sinkholes is in the deployment of various kinds of decoy networks for entrapment, exposure, and intelligence-gathering purposes.

Note 

Decoy \De*coy'\ n. Anything intended to lead into a snare ; a lure that deceives and misleads into danger, or into the power of an enemy; a bait.

The two types of decoy networks we'll discuss in detail are the darknet and the honeynet. Both may be used to glean security intelligence, but one is particularly useful in the realm of secure network engineering.

Deploying Darknets

Generally , a darknet is a portion of routed, allocated IP space in which no responsive services reside. Such networks are classified as "dark" because there is seemingly nothing "lit up" inside these networks. However, a darknet does in fact include at least one server, designed to act as a packet vacuum . This server gathers and organizes the packets that enter the darknet, useful for real-time analysis or post-event network forensics.

Any packet that enters a darknet is unexpected. Because no legitimate packets should ever appear inside a darknet, those that do appear have either arrived by misconfiguration or by the more frequent scenario, having been sent by malware. This malware, scanning for vulnerable devices, will send packets into the darknet, thereby exposing itself to administrative security review. There is a slant of genius in this approach for finding worms and other propagating malware. Without false positives, and without signatures or complicated statistical analysis gear, a security administrator with properly deployed darknets can spot scanning (attempts made by malware to discover adjacent hosts suitable for propagation) in any size network. That's a powerful security tool. Further, packets arriving in the darknet expose innocuous network misconfigurations that network administrators will appreciate ironing out. Of course, darknets have multiple uses in the realm of security. They can be used to host flow collectors, backscatter detectors, packet sniffers, and intrusion detection systems. The elegance of the darknet is that it cuts down considerably on the false positives for any device or technology through simple traffic reduction.

Implementing a darknet is relatively simple. In fact, here are five easy steps:

  1. Select one or more unused regions of IP address space from your network that you'll route into your darknet. This could be a /16 prefix of addresses or larger, or all the way down to a single (/32) address. More addresses result in a more statistically accurate perception of unsolicited network activity. I recommend selecting several address segments, such as a /29 from each of several internal networks, and a /25 from your public (external) network allocation, for example. There's no reason you can't darknet a region of your internal private address space (for example, RFC 1918 space, 10.0.0.0/8). In fact, by selecting regions of your internal network to darknet, you'll be able to see internal scanning that you may miss if you only darknet external (public) network segments. Another strategy that can be considered by organizations utilizing specific routing for their internal networks is to rely upon the "most specific route wins" rule of routing (usually distributed through some kind of interior gateway protocol). Meaning, if I use the 10.1.1.0/24 and the 10.2.1.0/24 networks internally, I can just route the entire 10.0.0.0/8 network into my darknet. I know that if my network is properly configured, the darknet will receive all 10.0.0.0/8 traffic except for the networks within it that I'm specifically using/routing (these likely have static routing entries in my network infrastructure).

  2. Next, you'll configure your physical topology. You'll need a router or (layer-3) switch that will forward traffic into your darknet, a server with ample storage to serve as your data collector, and an ethernet switch you'll use to connect these components and optional components in the future such as an IDS sensor or protocol analyzer. For the router, you may elect to use an existing internal or external (or both, though it is not recommended) gateway devicemost "enterprise" darknets (as opposed to those of telecom carriers ) are located inside one of the organization's DMZs and segregated from the rest of the network. Therefore, you may consider using a firewall to do this job in lieu of one of your routers. We recommend, however, that you use your external gateway router for external darknets, and an internal layer-3 switch for your internal darknets. Either way, the key item to consider is that you'll configure this routing device to forward the darknet-destined traffic it receives out of a dedicated darknet ethernet interface (through the switch) to the collector server that you'll configure to accept such packets. The collector server must also have a dedicated darknet interface that will receive those packets. For management, the collector server will also require at least one additional ethernet interface (to be placed on a separate management LAN). Make sure you follow your own best practices for network device security as you can be guaranteed that all sorts of nasties will be flowing through this network segment very soon. Fight the urge to quickly utilize an existing DMZ switch for the purpose of connecting these components unless you're comfortable configuring the VLAN so that no broadcast packets will make their way into the darknetremember, the darknet is for illegitimate traffic only, so we don't want legitimate broadcasts from your other LANs encroaching on darknet turf. Figure 10-3 depicts an example of this configuration.

    image from book
    Figure 10-3: A reference physical topology for darknets

  3. In order for our collector server to avoid having to ARP (address resolution protocol) for every address in the darknet space, we'll configure the router to forward the darknet-destined traffic to a unique endpoint IP address on the server's darknet ethernet interface. In order to accomplish this, we suggest dedicating a /30 network for your point-to-point between your router and the darknet interface, such as 192.0.2.0/30. This would make your router's Ethernet interface 192.0.2.1/30 and the collector server could be reached via 192.0.2.2/30. Interface configuration depends largely on the platforms you've selected so we'll assume you're comfortable setting that up on your own. Once that's done, you'll simply enter the appropriate routing statements to the switch to forward all your darknet traffic to 192.0.2.2 on the collector server, and you're home free:

     router#conf t router(config)# ip route 10.0.0.0 255.0.0.0 192.0.2.2 router(config)# ^z router# wr 

    You should now be receiving darknet traffic. An example logical topology is shown in Figure 10-4.

    image from book
    Figure 10-4: A reference logical topology for darknets

  4. What to do with the traffic once it gets there is another story. The server should be configured not to respond to any data it receives on its darknet interface. Of course, it will ARP for its configured address (192.0.2.2/30 only) in order to establish communications with the router; however, all other packets should be discarded by some sort of host-based firewall. As mentioned earlier, no management whatsoever should occur on the darknet interfaceyou'll need to configure another ethernet interface on which to perform management and administration. The default route for the system should be the management interface's gateway. For the necessary firewall, your platform selection of the server will impact your firewall selection, but we recommend using a BSD-based system and pf, ipf, or ipfw2 as your firewall. Whether or not firewall logging should be enabled largely depends on what you'd do with it. We use logfile analysis tools that require logging to be turned on (so that the logs can be parsed and alerts generated); however, depending on several hardware and software choices and the size of your darknet, this logging may severely degrade darknet performance. As an additional safety measure (firewalls can crash or be accidentally turned off), it is a good idea to null-route the darknet traffic should it accidentally go unfiltered . An example null-route under FreeBSD might look like this:

     route add -net 10.0.0.0/8 127.0.0.1 -blackhole 
  5. Now that your darknet is humming and you've protected your darknet collector server, you need to store the data in a format useful to your analysis and forensics tools. The most obvious choice would be pcap-formatted binary files as they are nearly ubiquitous in that most network analysis applications can operate on them. The easiest way to do this on an ongoing basis is to use the tcpdump program's built-in rotation feature. The tcpdump program is provided by the Network Research Group of the Lawrence Berkeley National Laboratory. An example tcpdump command line to accomplish the log rotation for us is

     tcpdump -i en0 -n -w darknet_dump --C125 

    In this example, tcpdump is told to listen on the en0 interface, number-to- name (DNS) resolution is disabled, and a file named darknet_dumpN is written for every 125 million bytes committed, where N increments to make the filenames unique.

    Another helpful tool that makes it easy to visualize flows of traffic is the argus software. Although its configuration is too involved to detail here, we utilize argus regularly to watch for interesting flows in our darknets. Argus provides a keen flow-based summary interface that should help you understand exactly what's going on in terms of malicious traffic flows.

    In order to visualize the volume of traffic entering your darknet, interface counter-based tools such as MRTG (see http://www.mrtg.org/) by Tobias Oetiker should do the trick. MRTG can help you produce beautiful graphs of your not-so-beautiful darknet traffic. There are also dozens of tools out there to parse firewall logs that can be a quick and easy alternative to the more complicated pcap-based analysis tools or argus. Keep in mind the performance problems you'll have with text-based logging of the packet filter and subsequent parsing of those files.

    There are literally dozens of tools that can be used within your darknet. To get you started, here's what you'd find in some of ours:

    • An IDS sensor (Bro, Snort, et al.)

    • A packet sniffer (tcpdump as describe earlier)

    • A flow analyzer (argus, netflow export from router, SiLK, flow-tools )

    • A firewall log-file parser that populates RRD databases for graphing

    • MRTG to graph traffic counters

    • p0f (by Michal Zalewski) to categorize platforms of infected/scanning devices

    Tip 

    We highly recommend following the comprehensive step-by-step guide to deploying your own darknets developed by Rob Thomas and the rest of Team Cymru. It can be found at http://www.cymru.com/Darknet/. In it, they take you through all the steps needed to set up the darknet network, select and size equipment, configure the recommended software tools, and even provide some operational hints and guidelines for security administrators. Team Cymru also provides some of the best secure configuration templates available for BIND, IOS, and JUNOS.

Deploying Honeynets

Like a darknet, a honeynet is generally a portion of routed, allocated IP space. However, instead of providing a destination where packets go to die, the destination mimics an actual service (or many services), thereby allowing the connection (handshake) to take place, and establishing a complete two-way dialogue. A honeypot, or the system mimicking an actual service, is meant to be a tightly held and constantly monitored resource that is intended to lure attackers to probe it and/or infiltrate it. While there are a few different types of honeypots, they all have the same goal: learn the tactics and garner as much information as possible about the attacker.

Physical Honeypots

Physical honeypots are whole machines inside the honeynet with their own IP address, operating system, and service-mimicking tools.

Virtual Honeypots

Virtual honeypots are "software-simulated" complete honeypot systems within the honeynet that mimic environmental conditions such as the operating system, network stack, and services provided as decoys. One physical server may provide a network of thousands of virtual honeypots.

Low-Interaction Honeypots

Low-interaction honeypots (the most prevalent type of honeypot in use today) are designed to lure an attacker with one or more presumably exploitable vulnerabilities, establish dialogue, and capture the first few packets of communication with the attacker. Obviously, the attacker or the autonomous malicious software that is conversing with the honeypot will eventually realize the target is unable to be exploited, but before that occurs, valuable information can be exposed, such as the exploitation tactic or the signature of the malicious software. Such low-interaction honeypots are used today to model spammers' tactics (attempting to derive heuristics such as timing characteristics of spammer SMTP transactions, for example).

There are only a few commercial implementations of honeynet technology in general, but the most popular implementation is found in the open source project, honeyd, by Niels Provos. More information on acquiring and setting up honeyd may be found at http://www.honeyd.org.

Tip 

honeyd is designed to be a virtual honeypot/honeynet that can simulate a number of different operating systems and software components suitable for attracting attackers.

Another low-interaction form of honeypot worth mentioning is a novel concept by Tom Liston called LaBrea. LaBrea (named after the tar pit) is a software daemon (service) that is capable of generating autonomous responses to connection requests across potentially enormous blocks of IP addresses. In short, it creates an environment attractive to scanning/propagating malware, but it has one nasty trick. As soon as the malware attempts to connect, LaBrea slows down the network stack of the sender, sometimes quite significantly. Figuratively speaking, the network stack of the malware-infected system gets stuck in a tar pit. Therefore, there is no interaction at the application layer, but significant interaction at layer 4 when the (TCP) connection handshake attempts take place. LaBrea is even capable of ARPing for all of the virtual IP addresses in its configuration without assigning them to the host system's interfaces, which makes setting it up incredibly easy. More information on LaBrea can be found at http://labrea. sourceforge .net/labrea- info .html.

Note 

Several research bodies have concluded that low-interaction honeypots are a viable tactic against high-performance propagating worms by slowing them down in order to protect network infrastructure. We postulate that the configuration required to realize this benefit is obtuse at best. However, LaBrea and honeyd may both be configured to create such a worm-unfriendly environment.

High-Interaction Honeypots

High-interaction honeypots are less used, but exceedingly valuable. As opposed to simply capturing the first few transactions in a dialogue between an attacker and the honeypot, a high-interaction honeypot is designed to let an attacker completely infiltrate the system on which the honeypot resides. In this scenario, useful information captured will not only include the probing technique and the exploitation used, but it will also allow the security administrator to watch over the attacker once he gains access to the system, unwittingly exposing his intentions and tools.

There is a nonprofit organization known as The Honeynet Project (see http://www.honeynet.org/) that produces a great deal of intelligence and some easy-to-use tools designed to enable users to deploy high-interaction honeypots. They also provide excellent forensics-type tools to analyze the data collected during infiltrations into the honeypots.

Tip 

The Honeynet Project (http://www.honeynet.org/) publishes a number of fantastic tools for use in deploying your own honeynets. We recommend paying particular attention to the Honeywall, Termlog, and Sebek tools. Likewise, the project team has also developed an excellent book on the psychology, tactics, and tools used by attackers as gleaned through honeynet technologies. The book, Know Your Enemy, which at the time of this writing is in its second edition, is available through the http://honeynet.org web site and proceeds from its sales are used to help fund honeynet research.

Recommendations for the Use of Honeynets

For research organizations or those with a lot of money and time to burn (do you know of any?), honeypots can be an invaluable tool, but we do not recommend utilizing honeypots inside the everyday enterprise. However, while not suitable for everyday use, when an innocuous piece of malicious software rears its ugly head and no sniffer or forensics tools help identify the problem to the extent that your administrator can solve it, a honeynet may be implemented on demand in order to establish communication by posing as a target the malicious software is expecting, thereby exposing enough information in order to adequately identify the attack. Another on-demand use is as a means to verify a suspected infiltration. Therefore, it should be another arrow in the security administrator's quiver.

One implementation worth mentioning is in use at one of the world's largest chipmakers. They have, throughout their network, Linux servers running VMWare, on top of which are running four virtual machines, one for each of the Windows OS varieties common within the enterpriseNT, 2000, 2003, and XP. Each is kept current with the standard corporate patch levels. The Linux OS monitors those for traffic and changes, as a means of detecting new worms (or other threats) that may circulate within the enterprise. They're essentially using this environment as a combination honeynet and IDS for worms. More details on this implementation may be found at http://phoenixinfragard.net/meetings/past/200407hawrylkiw.pdf.



Extreme Exploits. Advanced Defenses Against Hardcore Hacks
Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
ISBN: 0072259558
EAN: 2147483647
Year: 2005
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net