| Related sites for http://www.cymru.com/Darknet/ |
| Planet_Index A selective general catalog of categorized websites. | | RFC_1688 IPng Mobility Considerations. W. Simpson. August 1994. | | HelpDesk_Pro Features CGI source code, auto SMS messaging alerts, multi-platform compatibility, database management, automated call queue. | | Columbia_Ultimate_Users_(CUusers_org) The digital conference room for users of Columbia Ultimate's The Collector System, which runs its Standard edition on the jBASE and IBM UniVerse databases. | | RFC_0453 Meeting Announcement to Discuss a Network Mail System. M.D. Kudlick. February 1973. | | RFC_1727 A Vision of an Integrated Internet Information Service. C. Weider, P. Deutsch. December 1994. | | Scott_Rosenberg\'s_Wordyard Blog on technology, society, politics, and the blogosphere from a founder of Salon. | | OFTP___File_transfer_protocol OFTP : a secure X25 or TCP/IP file transfer protocol | | Slashdot__Refund_for_Windows_action Further commentary from the early stages of the movement. | | Palm_OS_Database_Comparison_Review Excellent review of the available database software for the PalmPilot. | | FragRead A tool to easily view any part of large text or log files. [Win32] | | MAAD_Interactive_Agency Services cover interactive point of sale, digital branding, interactive, visualisation, visual FX, and graphic design Based in Newcastle Upon Tyne, United Kingdom. | | RFC_1653 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. July 1994. | | NZBSites_com Listing of NZB sites, showing the availability of RSS feed and/or forum per site. | | Exception_Handling__A_False_Sense_Of_Security Explains why most members of the C++ community vastly underestimate the skills needed to program with exceptions and therefore underestimate the true costs of their use. By Tom Cargill. | | Agape_Media_design Offer web design, maintenance, and hosting services. | | My_Business_Online Web design and hosting for small businesses. Located in Eden Prairie, Minnesota, United States. | | CQD_WebWorks Specialists in providing inexpensive web design and hosting to small and medium businesses, clubs, associations and individuals. Based in Edinburgh, Scotland. | | Globalization_Jobs A community for people seeking jobs and for agencies/companies posting openings in the I18N, L10N and G11N categories. | | Leach,_Les Specializing in design using ASP and VB scripting, DHTML, Flash, Shockwave, PHP programming and HTML. |
|
Team Cymru - The Darknet Project  About Us Services · Bogon Reference · Darknet Project · IP to ASN Mapping · Consulting · Training · Investigations Monitoring Reading Room News Contact Us!16W361 S. Frontage RoadSuite 100Burr Ridge, IL 60527USPhone: +1 312 924 4000Fax: +1 630 887 8651team-cymru@cymru.com Team Cymru is a specialized Internet security research firm dedicated to making the Internet more secure. By researching the 'who' and 'why' of malicious Internet activity worldwide, Team Cymru helps organizations identify and eradicate problems in their networks. The Darknet Project[ Introduction ][ Building a Darknet - Network ] [ Building a Darknet - Server ] [ Managing a Darknet ] [ Now What? ] [ Similar Efforts ] [ Feedback and Questions ] Changes in version 1.4Added snippet samples for ntp.conf and resolv.conf.Added ipf rules for NTP and DNS (thanks to Victor Wilson for the suggestion!).Added ipf logging suggestions and examples.Changes in version 1.2Added additional routing suggestions.Aesthetic changes.IntroductionTracking compromised machines can be difficult. Security solutions oftendon't scale to the size of larger networks. Technologies such as IDS areflawed, producing copious false positives. When solutions are scaled to fitthe larger providers, they often require considerable care and feeding, thustaking time away from problem mitigation. There must be a better way!Enter the Darknet! A Darknet is a portion of routed, allocated IP spacein which no active services or servers reside. These are "dark" becausethere is, seemingly, nothing within these networks.A Darknet does in fact include at least one server, designed as a packetvacuum. This server gathers the packets and flows that enter the Darknet,useful for real-time analysis or post-event network forensics.Any packet that enters a Darknet is by its presence aberrant. Nolegitimate packets should be sent to a Darknet. Such packets may havearrived by mistake or misconfiguration, but the majority of such packets aresent by malware. This malware, actively scanning for vulnerable devices,will send packets into the Darknet, and this is exactly what we want.Darknets have multiple uses. These can be used to host flow collectors,backscatter detectors, packet sniffers, and IDS boxes. The elegance of theDarknet is that it cuts down considerably on the false positives for anydevice or technology.The goals of the Darknet are simple - to increase awareness, and to easemitigation. With a Darknet in place, it is far easier to determine theamount of naughty traffic on a network, as well as the sources of saidtraffic.Deploying a DarknetBuilding a Darknet - NetworkThe first step in deploying a Darknet is to locate a suitable home. Werecommend first determining the amount of address space you plan to allocateto the Darknet. At a minimum we recommend a /24, though smaller addressspace - even up to a /32 - will work. You could even allocate a single /32from each of several /24s to make the Darknet very difficult to detect. Themore address space you allocate to the Darknet, the greater your visibilityand statistical sampling.Remember the rule of routing - the most specific prefix wins. This is agreat advantage for a Darknet. If you have a /16 for your enterprise, youcan route the entire /16 to your Darknet, with more specific routes in yourIGP carrying production traffic to the proper places. As with all things,carefully ponder and test this configuration prior to deployment.Do not use bogon addressspace. Bogon space is avoided by many scanners and malware. Because bogonspace does not include vulnerable hosts, there is no return on theinvestment for the malware. Use only allocated, routed space for theDarknet.Note: While this document uses IPv4 exclusively, an IPv6 Darknetis also a viable solution. Future versions of this document may include IPv6examples, depending largely on Rob's caffeine intake.A /32, not within the allocated Darknet space, needs to beassigned for both the management IP and the sniffer IP.The next step is to set aside the physical and logical space for theDarknet. You will need:The Darknet IP prefix.A sniffer IP NOT in the Darknet space.A management IP NOT in the Darknet space.A distinct VLAN or hub for the Darknet space.We strongly recommend against putting the Darknet in the same collisiondomain or VLAN as other subnets. The goal of the Darknet is to providecredible data, thus it is critical to avoid "poisoning" the Darknet withlegitimate traffic.We recommend against putting the Darknet IPs into your publicly visibleDNS. DNS RRs such as darknet-sniffer.your.net are just abit obvious. ;)For our example, we'll use the following (these are BOGONS, so do not use them!): Darknet prefix = 10.18.18.0/24 Sniffer IP = 172.16.18.2 Management IP = 192.168.18.2 Darknet VLAN = 855 Managemetn VLAN = 222An upstream router interface, or entire router if you have the luxury,should be selected and configured for the Darknet. The router should beconfigured to protect itself; the Secure IOSTemplate or the Secure JunOSTemplate can be of use here. Otherwise the router should permit allpackets to pass into the Darknet. The router can be configured to block alloutbound packets from the Darknet.The router should be configured for SNMP, and at a minimum trafficstatistics 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 Darknetpods at http://www.cymru.com/Reach/darknet.html.There are myriad packages designed to collect router statistics, toinclude MRTG. The router can also beconfigured to export flows to a package of your choice. While this may beredundant for a Darknet, it may also provide a seamless way to integrateDarknet data into existing network monitoring infrastructure. We like thefollowing packages, though your mileage may vary:SiLKFlow-toolsThis router could also carry the Darknet management traffic. Your callhere.The router should be configured to send all Darknet prefix traffic to theSNIFFER NIC on the Darknet server. On a Cisco router, configure the routethusly: router#conf t router(config)# ip route 10.18.18.0 255.255.255.0 172.16.18.2 router(config)# ^Z router# wrThe router, or an upstream router, should inject the Darknet prefix intoyour IGP. Details on how this is done is network dependent, but pleasecontact Team Cymru if we can assist youwith this task.For our continuing example, we'll use 172.16.18.1 and 192.168.18.1 as therouter IPs. The topology is now, in fine ASCII art: _______________________________________________ ____________________________________WAN <-| some.internal.ip.here - ROUTER - 172.16.18.1 |-> VLAN 855 <-| 172.16.18.2 DARKNET-SERVER-SNIFFER | |_______________________________________________| | | | DARKNET | | SERVER | _______________________________________________ | |WAN <-| some.internal.ip.here - ROUTER - 192.168.18.1 |-> VLAN 222 <-| 192.168.18.2 DARKNET-SERVER-MGMT | |_______________________________________________| |____________________________________|Building a Darknet - ServerEveryone has a favorite server platform and operating system. We providethese suggestions as a guideline, and you should feel free to modify them tofit your environment. The goal of a Darknet is to increase awareness, not toincrease workload.We recommend either Solaris 8 or FreeBSD 4.8 or 4.9. These have bothproven stable in our deployments. Your mileage may vary.The server must have two NICs. One is for sniffing, and the other is formanagement. Again it is imperative that we not contaminate our Darknet withlegitimate traffic, to include our own management traffic. In our example wepick FreeBSD 4.8 and assign the two NICs thusly: em0 - SNIFFER NIC - 172.16.18.2 fxp0 - MGMT NIC - 192.168.18.2The default route for the box, if any, should point to the gateway on themanagement subnet, e.g. the gateway upstream from the fxp0 interface in ourexample. Do not point any routes out of the SNIFFER NIC. If you can go withstatic routes and no default, all the better to protect the Darknet server.Default routes are not always necessary. route add -net <mgmt-subnet> 192.168.18.1We also recommend adding a null route on the box for the allocatedDarknet prefix. This adds a bit of extra protection, and ensures that theDarknet server can not answer packets destined for the Darknet prefix. BothSolaris and FreeBSD support blackhole routes, which are implementedthusly: route add -net 10.18.18.0/24 127.0.0.1 -blackholeRemember to update the boot files so that this route is implemented atreboot.We recommend a single CPU box, at least 1.8GHz for Intel, with at least200GB of hard drive space. This depends entirely on the amount of data youchoose to log. In one of our Darknet pods, we can log a gigabyte per hourfrom a single /16. Ultimately disk space and I/O are likely to be yourstrictest bottlenecks. Ensure that you monitor the disk space utilizationand I/O throughput on the Darknet server.We recommend using UTC (aka GMT) as the timezone on all of your Darknetservers. A standard timezone will make cross-Darknet correlation a muchsimpler task. This can be accomplished by copying the proper timezone file,usually named "GMT," to /etc/localtime. Don't forget to synchronize timewith two or more NTP servers. In our example, the management servers192.168.1.9 and 192.168.2.9 will be our NTP servers. There are severalfeatures for NTP configuration, but at a minimum you want the following inyour ntp.conf file: # Our NTP servers. server 192.168.1.9 server 192.168.2.9You likely want DNS running on your Darknet server. In our example wewill use the management servers 192.168.1.9 and 192.168.2.9 as our DNS nameservers (they also serve NTP). Be careful with DNS and sniffing! Be sure touse the -n flag with tcpdump so that your Darknet serverdoesn't attempt to resolve each IP in your sniffer output. Our/etc/resolv.conf file should now include: search first.domain.here second.domain.here so.on.and.so.on nameserver 192.168.1.9 nameserver 192.168.2.9We're now going to add some software to our Darknet server. We use andrecommend the following:ArgustcpdumpIP FilterA discourse on how to build and implement each is beyond the scope ofthis treatise. Each comes with ample build and installation documentation.We will cover only certain tweaks here.Argus and tcpdump should be configured to listen on the SNIFFER NIC only,in our example em0. The remote management daemon for Argus should be boundto the MGMT NIC only, e.g. fxp0, on port 2002 in our example. It should notbe bound to the SNIFFER NIC.Argus should be run as a daemon, and ideally started at boot. Here is asuggested template for your /etc/argus.conf file. # /etc/argus.conf# 01 MAY 2004 robt@cymru.com## Run Argus as a daemonARGUS_DAEMON=yes## Now select a _unique_ Argus ID for this Darknet server.# Configure all Darknet servers with their own, unique# Argus ID.ARGUS_MONITOR_ID=5## Select a port on which the Argus daemon will listen for# remote management and queries. We've already chosen# TCP 2002 as our port.ARGUS_ACCESS_PORT=2002## We only want to sniff the em0 port.ARGUS_INTERFACE=em0## Store the flows in an output file. Rotate this file# regularly with a script.ARGUS_OUTPUT_FILE=/var/log/argus/argus-id5-log## Log the PID of the Argus daemon.ARGUS_SET_PID=yes## Set to promiscuous mode.ARGUS_GO_PROMISCUOUS=yes## Decision time. How often do you wish to receive reports# on long-lived flows? A small number here is safe, because# there should be _NO_ long lived flows in a Darknet. The# Darknet isn't supposed to actually complete a connection# request, after all. We'll set this to five seconds.ARGUS_FLOW_STATUS_INTERVAL=5## It's wise to regularly output the Argus daemon stats.# These can be very helpful when debugging problems. We'll# set this to 60 seconds.ARGUS_MAR_STATUS_INTERVAL=60## While we don't use these statistics regularly, they can# be handy at times. Go ahead and collect them.ARGUS_GENERATE_RESPONSE_TIME_DATA=yesARGUS_GENERATE_JITTER_DATA=yes ## MAC address information should be uninteresting, because# all packets will have the source MAC of the upstream# router.ARGUS_GENERATE_MAC_DATA=no## Capturing only headers can hinder analysis efforts. If# you have the CPU and disk space, gather all the bits in# each packet.ARGUS_CAPTURE_DATA_LEN=1518## Optimize the libpcap filters.ARGUS_FILTER_OPTIMIZER=yes## Do not filter the packets; grab them all.ARGUS_FILTER=""## The ability to run tcpdump under the Aegis of Argus is# one of its most powerful features. This combines the# flow logging with packet payload. If you have the CPU# and disk capacity, enable this feature. Remember to# rotate these logfiles!ARGUS_PACKET_CAPTURE_FILE="/var/log/argus/argus-id5-tcpdump"#IP Filter should be configured to block everything in and out of theSNIFFER NIC interface. In our example this is the em0 interface, IP address172.16.18.2. You may wish to log any hits on the block rules so thatdebugging and alerts are easy to accomplish; it's not a bad idea to do thesame on the pass rules as well. If you choose to log the rule hits, rememberto start ipmon with the proper flags.Modify /etc/ipf.rules (/etc/opt/ipf/ipf.conf in Solaris)thusly: # Prevent any traffic from entering and exiting the em0 # SNIFFER NIC. block in log quick on em0 from any to any block out log quick on em0 from any to any #But won't this block the traffic we're attempting to log? No, both Argusand tcpdump insert themselves beneath ipf, gathering all the packets andflows before ipf blocks the traffic.The Darknet server is now configured with SSH on TCP 22 and an Argusremote flow collection port on TCP 2002. Both should be configured to bindonly to the MGMT NIC, not the SNIFFER NIC. These should also be protectedusing ipf. Remember we are managing this device out of band from the Darknetnetwork. # Lock down management access to the fxp0 MGMT NIC. pass in quick on fxp0 proto tcp from <mgmt-subnet> to 192.168.18.2 port = 22 keep state pass in quick on fxp0 proto tcp from <mgmt-subnet> to 192.168.18.2 port = 2002 keep state block in log quick on fxp0 from any to any #Depending on the functions and management methods of your Darknet server,you may wish to permit outbound connections from the MGMT NIC, permitinbound ICMP, etc. Here is an example of a complete FreeBSD Darknet server/etc/ipf.rules (Solaris /etc/opt/ipf/ipf.conf) file. In thisexample the management subnets are 192.168.1.0/24 and192.168.2.0/24. For guidelines on permissable ICMP messages, pleasesee our ICMPPacket Filtering guide. It is wise to test new filter sets from an outof band management port, e.g. the console, to avoid locking yourself out ofthe Darknet server. Remember to modify this filter set to fit yourenvironment and adhere to applicable security policies.# /etc/ipf.rules# 01 MAY 2004 robt@cymru.com## em0 172.16.18.2 SNIFFER NIC# fxp0 192.168.18.2 MGMT NIC## 192.168.1.0/24 ORD NOC# 192.168.2.0/24 LHR NOC## Prevent any traffic from entering and exiting the em0# SNIFFER NIC.block in log quick on em0 from any to anyblock out log quick on em0 from any to any## Lock down SSH, Argus, and SNMP access to the fxp0 MGMT NIC.pass in quick on fxp0 proto tcp from 192.168.1.0/24 to 192.168.18.2 port = 22 keep statepass in quick on fxp0 proto tcp from 192.168.2.0/24 to 192.168.18.2 port = 22 keep statepass in quick on fxp0 proto tcp from 192.168.1.0/24 to 192.168.18.2 port = 2002 keep statepass in quick on fxp0 proto tcp from 192.168.2.0/24 to 192.168.18.2 port = 2002 keep statepass in quick on fxp0 proto udp from 192.168.1.0/24 to 192.168.18.2 port = 161 keep statepass in quick on fxp0 proto udp from 192.168.2.0/24 to 192.168.18.2 port = 161 keep state## Permit SSH outbound to the management subnets.pass out quick on fxp0 proto tcp from 192.168.18.2 to 192.168.1.0/24 port = 22 keep statepass out quick on fxp0 proto tcp from 192.168.18.2 to 192.168.2.0/24 port = 22 keep state# Permit syslog outbound to the management subnets.pass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.1.0/24 port = 514 keep statepass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.2.0/24 port = 514 keep state# # Permit DNS outbound to the DNS name servers.pass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.1.9 port = 53 keep statepass out quick on fxp0 proto tcp from 192.168.18.2 to 192.168.1.9 port = 53 keep statepass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.2.9 port = 53 keep statepass out quick on fxp0 proto tcp from 192.168.18.2 to 192.168.2.9 port = 53 keep state## Permit NTP outbound to the NTP servers.pass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.1.9 port = 123 keep statepass out quick on fxp0 proto udp from 192.168.18.2 to 192.168.2.9 port = 123 keep state## Permit some ICMP from the management subnets and the upstream router.pass in quick on fxp0 proto icmp from 192.168.1.0/24 to 192.168.18.2 icmp-type echopass in quick on fxp0 proto icmp from 192.168.2.0/24 to 192.168.18.2 icmp-type echopass in quick on fxp0 proto icmp from 192.168.18.1 to 192.168.18.2 icmp-type echopass in quick on fxp0 proto icmp from 192.168.1.0/24 to 192.168.18.2 icmp-type echoreppass in quick on fxp0 proto icmp from 192.168.2.0/24 to 192.168.18.2 icmp-type echoreppass in quick on fxp0 proto icmp from 192.168.18.1 to 192.168.18.2 icmp-type echoreppass in quick on fxp0 proto icmp from 192.168.1.0/24 to 192.168.18.2 icmp-type timexpass in quick on fxp0 proto icmp from 192.168.2.0/24 to 192.168.18.2 icmp-type timexpass in quick on fxp0 proto icmp from 192.168.1.0/24 to 192.168.18.2 icmp-type unreachpass in quick on fxp0 proto icmp from 192.168.2.0/24 to 192.168.18.2 icmp-type unreach## Permit some outbound ICMP for debugging purposes.pass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.1.0/24 icmp-type echopass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.2.0/24 icmp-type echopass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.18.1 icmp-type echopass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.1.0/24 icmp-type echoreppass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.2.0/24 icmp-type echoreppass out quick on fxp0 proto icmp from 192.168.18.2 to 192.168.18.1 icmp-type echorep## Block everything else.block in log quick on fxp0 from any to anyblock out log quick on fxp0 from any to any#Once you have the desired filter set in place, reload your IP Filterfirewall with: ipf -f /etc/ipf.rulesNow fire up tcpdump on the em0 interface to see if the packets to ourDarknet prefix, 10.18.18.0/24, are arriving. After launching tcpdump, send afew packets to sundry addresses within 10.18.18.0/24. If your chosen Darknetprefix is accessible from the Internet, it won't take long before thenaughty packets arrive. tcpdump -n -i em0Next test that you can connect to the Argus port from your remotemanagement stations. ra -zn -S 192.168.18.2 -P 2002If you see packets with tcpdump and flows with Argus, congratulations!You now have an operational Darknet. :)A clever alternative is to use a host-based system. One suggestion is touse Linux and iptables. Route a small prefix (e.g. a /25) to a Linux boxthat is a "log and drop" iptables firewall. The data can be pulled from thelogs to produce results similar to the Darknet configuration detailedhere.Using a DarknetManaging a DarknetManaging a Darknet shouldn't be an arduous task. There is the usualhealth checking of both the router and the Darknet server. We recommendusing SNMP on both to monitor interface usage. It is unlikely to ever bezero bps or pps. We also strongly recommend monitoring the processes on theDarknet server, to include cron, syslog, Argus, and tcpdump. Keep a closeeye on the disk space on the Darknet server, as that can fill up rapidlyduring periods of high network stress.Tools such as rancid, netsnmp, and Big Brother can be of great use here. Any toolshould integrate with your existing network management and monitoring, ofcourse.We recommend rotating the created logfiles, as they can become quitelarge. tcpdump can be told to rotate the log file when it reaches a set sizewith the -C flag. This example rotates the file and names it"darkdumpN" (where N is an incrementing number) when it reaches 150MB insize. tcpdump -i em0 -n -w darkdump -C150Scripts can also be used to rotate log files.As with all things keep patches and code current and secure. Regularlyaudit your Darknet. This is not the host you want compromised when a nastybit of malware visits your network.Patrick Green of the OxCERT team at Oxford University, UK, has puttogether a great paper on the practical use of a Darknet. Our thanks to Patfor authoring the paper and permitting us to host it here. You will find thepaper at http://www.team-cymru.org/documents/dark-watcher.pdf.Now What?So you have a Darknet - now what do you do with it? There are a varietyof ways to peruse the collected data, and myriad uses for that data.Perhaps you've heard that there is a bot that exploits Microsoft Windows2000 open shares. This bot scans on TCP port 445, and you wish to know howmuch of that traffic is reaching (or sourced within) your network. A quickArgus query to your Darknet will help to answer that question. The query isconstructed using tcpdump pattern matching syntax. See the ra man page for moreexamples. host$ ra -n -S 192.168.18.2 -P 2002 tcp dst port 445 ra: Trying 192.168.18.2 port 2002 ra: connected Argus Version 1.8 30 Apr 04 17:37:11 tcp x.150.51.121.3601 o> y.10.73.47.445 TIM 30 Apr 04 17:37:11 tcp x.116.125.168.4935 o> y.10.12.121.445 TIM 30 Apr 04 17:37:11 tcp x.116.125.168.4936 o> y.10.12.121.445 TIM 30 Apr 04 17:37:11 tcp x.116.125.168.5000 o> y.10.12.121.445 TIM 30 Apr 04 17:37:11 tcp x.116.125.168.1031 o> y.10.12.121.445 TIM 30 Apr 04 17:37:11 s tcp x.71.44.187.1776 -> y.10.66.129.445 REQ 30 Apr 04 17:37:11 s tcp x.23.37.181.3771 -> y.10.76.251.445 REQ 30 Apr 04 17:37:11 s tcp x.116.125.168.4899 -> y.10.12.121.445 REQ 30 Apr 04 17:37:11 s tcp x.11.195.39.20753 -> y.10.11.95.445 REQ 30 Apr 04 17:37:11 s tcp x.152.176.33.3157 -> y.10.111.235.445 REQ 30 Apr 04 17:37:11 s tcp x.240.143.78.22232 -> y.10.78.235.445 REQ 30 Apr 04 17:37:11 s tcp x.193.133.77.1351 -> y.10.101.71.445 REQ 30 Apr 04 17:37:11 s tcp x.222.19.238.1344 -> y.10.103.232.445 REQSure enough there is a fair bit of TCP 445 scanning occuring. The firstcolumn of IPs are the sources; these can now be reported to the systemowners. What has compromised these hosts? Unclear, but what is clear is thatsomething is wrong - remember, no legitimate packets should ever enter aDarknet.Slammer was a worm that sent packets to UDP 1434. Argus and a Darknet canspot these easily enough. host$ ra -n -S 192.168.18.2 -P 2002 udp and dst port 1434 ra: Trying 192.168.18.2 port 2002 ra: connected Argus Version 1.8 30 Apr 04 17:29:28 udp x.203.21.178.1467 -> y.10.19.234.1434 TIM 30 Apr 04 17:29:34 udp x.113.223.139.3881 -> y.10.103.192.1434 TIM 30 Apr 04 17:29:34 udp x.199.169.118.2292 -> y.10.87.15.1434 TIM 30 Apr 04 17:29:35 udp x.143.147.57.3954 -> y.10.66.161.1434 TIM 30 Apr 04 17:29:35 udp x.28.152.110.3979 -> y.10.71.103.1434 TIMThe data files can also be perused in batch mode with custom shell andPerl scripts.One use is to match up the flows with known malware signatures.You can use this data to alert customers to problems within theirnetworks. For example, if you flag 300 Slammer scans from a customernetwork, you can contact them with the source IP and UTC timestamp of thescan. They can then take action to clean the reported hosts. If you'rereporting infected hosts to peers or other providers, you can run the listthrough the Team Cymru WHOISserver to make notification list easier to assemble.You can use the data for statistical analysis. This is an excellentmethod by which you can begin to quantify the amount of "trouble" on yournetwork. You can even create a simple "garbage meter" based on the trafficentering your Darknets.  Customers and management will appreciate the proactive nature ofDarknets, meaning you can "spot bot" and other malware before it is used forspam or DDoS.You could readily host IDS boxes in your Darknet, thus matching on theknown fingerprints.Best of all you can use your Darknet deployment and data to convinceothers to do the same. Darknets aren't just for providers. They will fitnicely in enterprise and (supposedly) disconnected networks.Additional BitsSimilar EffortsThe Darknet concept is not new or the creation of TeamCymru. Lots of brilliant folks are doing similar things, and weappreciate their contributions. The folks at CAIDA have their NetworkTelescope project. The folks at the University of Michigan have their Internet Motion Sensor project.Feedback and CorrectionsWe hope this page and project are useful to you. Please feel free toshare suggestions, comments, and references with Team Cymru. Direct your commentsto team-cymru@cymru.com.       Copyright © 2008 Team Cymru, Inc. Site design bySavvyByte LLC. |
|
