As part of a broader organisational restructure, data networking research at Swinburne University of Technology has moved from the Centre for Advanced Internet Architecture (CAIA) to the Internet For Things (I4T) Research Lab.

Although CAIA no longer exists, this website reflects CAIA's activities and outputs between March 2002 and February 2017, and is being maintained as a service to the broader data networking research community.

Greynets

Overview

Greynets are a natural evolution of darknets1, a technique where large contiguous blocks of unused-yet-valid IP addresses are monitored for inbound IP packets that have no particular reason to be there. In this section we describe the greynet concept and detail what this project will develop.

1.1   Background - Darknets

Darknets [3,4,5,6] have become reasonably well known over the past few years as a technique for identifying unexpected and/or unsolicited network traffic. Large contiguous blocks of unused-yet-valid IP addresses are monitored for inbound IP packets and inferences are drawn from the packets that eventually arrive. Darknets are referred to as being 'dark' because they consist of IP addresses that have no legitimate associated activity. Packets can arrive at darknet addresses (because the IP addresses making up a darknet are valid and routable) but no packets are ever emitted from darknet addresses. Darknets are passive collectors of packets.

A large number of the packets arriving at darknet addresses represent probes and scans by hosts that are speculatively mapping the darknet itself. The sources usually do not realise they are sending packets into a monitored darknet space. Systems using darknet techniques have also been called network telescopes, internet motion sensors and black holes. Despite different names and implementation goals, they are at heart the same concept.

By alerting us to unsolicited network-scanning activity, darknets can play an extremely useful part in broader intrusion detection systems and systems for detecting the existence of virus-infected PCs. Darknets themselves are fairly easy to build, requiring only a low-end PC and a free, open-source unix-like operating system (such as FreeBSD or a Linux variant). Unfortunately, many darknet deployments assume that large, unused blocks of contiguous IP addresses are available - at least a /24, and more typically a /16 or larger. Not a hard requirement to meet for Internet service providers (ISPs) or research networks, but problematic for many enterprise networks and smaller ISPs. In fact, enterprise networks are more likely to have only scattered blocks of free IP addresses (perhaps four, eight or more at a time) or simply have individual IP addresses scattered amongst active addresses.

1.2  Greynets – sparsely populated Darknets

In this context we introduce the concept of a greynet ([1], [2]) - a region of network address space that is sparsely populated with 'darknet' addresses. (An alternative term could be 'sparse darknet'.) A greynet is a region of IP address space that is sparsely populated with 'darknet' addresses interspersed with active (or 'lit') IP addresses. Figure 1 shows these associations.

Internal, small scale darknets are of value to enterprise network operators because they can provide an early warning of internal hosts launching hostile scans against other parts of the enterprise network. Unlike networks run for research, enterprise networks are generally not concerned with detecting wider Internet activity unless it is threatening them directly. Scans and probes originating externally are of a moderate concern, as the potential to infect is limited to hosts unprotected by the enterprise firewall (e.g. the enterprise's public servers). Scans and probes originating internally, however, are of grave concern as the code generating the scan has moved past the network's outer defenses.

Additionally, greynets might be the only possible way to deploy passive network monitoring in enterprise networks, due to a combination of IP address scarcity and allocation techniques (automated or manual) that lead to scattered clusters of allocated and unallocated addresses. Additionally, interspersing 'darknet' addresses among valid hosts within subnets, in a sense hides the passive sensors, making it harder for malware (such as self-propagating viruses) to avoid hitting a greynet address while it searches for infection targets.

Figure 1 Greynet listeners interspersed among real ‘lit’ hosts and unmonitored IP addresses

1.3  An implementation using FreeBSD

A number of interesting implementation opportunities that arise from the model of greynets for enterprises.

Many enterprise networks (and some cable modem-based ISPs) utilise DHCP for assignment and management of 'live' IP addresses. Clearly the dynamic assignment and re-assignment of IP addresses can conflict with a greynet's set of potential listeners. There are two solution paths - either the greynet proactively requests a set of DHCP assigned addresses for its own use (removing them from circulation), or the greynet and DHCP server are integrated such that the IP addresses monitored are always equal to the DHCP server's pool of unallocated addresses at any given time. We plan to explore tight integration of our greynet service with FreeBSD’s DHCP server, to illustrate the potential for greynet monitoring in enterprise networks and DHCP-based ISPs.

                        Figure 2a Link layer view                                     Figure 2b Logical network layer view

Figure 2 A greynet monitoring host with a number of presences on multiple VLANs across an enterprise network

Some ISPs (particularly many broadband ADSL-based services) utilise PPPoE (PPP over Ethernet) or PPPoA (PPP over ATM) for connection management and public IP address assignment. Similar to the previous point regarding DHCP, we plan to explore the tight integration of our greynet service with FreeBSD’s PPPoE server daemon, to illustrate the potential for greynet monitoring in ADSL-based ISPs.

Thirdly, the use of VLANs by many large enterprise networks makes it relatively easy to implement a greynet that crosses subnet boundaries. Consider the case where different IP subnets are carried by separate ethernet VLANs across an enterprise backbone. A single FreeBSD box attached to a backbone switch's trunk port could activate multiple concurrent VLAN interfaces and give an onboard greynet application visibility into multiple subnets/VLANs at the same time. Figure 2 illustrates how a single box could centrally monitor the entire enterprise network by configuring various permutations to sparsely span multiple VLANs.

1.4  Deliverables

Our goal is to create a set of an easily deployable software tools running on the FreeBSD operating systems to implement a system that:

  • Is capable of attaching to multiple VLANs of an enterprise network concurrently
  • Occupy multiple IP addresses on these VLANs concurrently by taking out DHCP leases from an existing server or performing the DHCP server function itself and using all unused IP addresses as greynet listeners (or alternatively, integrate with a PPPoE server daemon to provide similar IP address occupancy in a PPPoE environment).
  • Monitor these IP addresses passively for inbound packets
  • Log locally and be capable of reporting via SNMP the current state of the greynet
  • Be managed through a secure web interface

The major consequence of this project will be the release of our source code (either under GPL or BSD-style open source license) to the research community via Sourceforge or an equivalent avenue (and the CAIA website).


1 In the application layer the terms ‘darknet’ and ‘greynet’ have also been co-opted to refer to groups of content servers whose identities are largely hidden from the internet-using public. In this project we use the terms to refer to IP-layer entities instead.



Last Updated: Monday 8-Dec-2008 14:00:10 AEDT | Maintained by: Amiel Heyde (amiel@swin.edu.au) | Authorised by: Grenville Armitage (garmitage@swin.edu.au)