An upstream router interface, or entire router if you have the luxury, should be selected and configured for the Darknet. The router should be configured to protect itself; the Secure IOS Template or the Secure JunOS Template can be of use here. Otherwise the router should permit all packets to pass into the Darknet. The router can be configured to block all outbound packets from the Darknet.
The router should be configured for SNMP, and at a minimum traffic statistics should be collected from the interface facing the Darknet server. This is done for two reasons:
New malware, be it worms or bots or other, can be quickly detected based solely on Darknet interface traffic statistics.
Any outbound traffic is a bad sign and should generate an alert.
The Witty worm is an example where our Darknets alerted us within minutes of the release of the worm. This set of graphics from three distinct Darknets makes it quite clear something was amiss:
You can see the traffic statistics from a small subset of our Darknet pods at http://www.cymru.com/Reach/darknet.html.
There are myriad packages designed to collect router statistics, to include MRTG. The router can also be configured to export flows to a package of your choice. While this may be redundant for a Darknet, it may also provide a seamless way to integrate Darknet data into existing network monitoring infrastructure. We like the following packages, though your mileage may vary:
SiLK
Flow-tools
This router could also carry the Darknet management traffic. Your call here.
The router should be configured to send all Darknet prefix traffic to the SNIFFER NIC on the Darknet server. On a Cisco router, configure the route thusly:
The router, or an upstream router, should inject the Darknet prefix into your IGP. Details on how this is done is network dependent, but please contact Team Cymru if we can assist you with this task.
For our continuing example, we'll use 172.16.18.1 and 192.168.18.1 as the router IPs. The topology is now, in fine ASCII art: