IPv4 and IPv6 Greynets
Cisco Systems
Santa Barbara
93117
California
USA
fred@cisco.com
CAIA, Swinburne University of Technology
Hawthorn
3122
Victoria
Australia
wazz@bud.cc.swin.edu.au
CAIA, Swinburne University of Technology
Hawthorn
3122
Victoria
Australia
garmitage@swin.edu.au
Operations
IPv6 Operations
This note discusses a feature to support building Greynets for IPv4
and IPv6.
Darknets, also called "Network Telescopes" among other things, have
been deployed by several organizations including CAIDA, Team Cymru, and
the University of Michigan, to look at traffic directed to addresses in
blocks that are not in actual use. Such traffic becomes visible by
either direct capture (it is routed to a collector) or by virtue of its
backscatter (its resulting in ICMP traffic or transport layer
resets).
defines a 'Greynet' by extension, in
these words:
Darknets are often proposed to monitor for anomalous, externally
sourced traffic, and require large, contiguous blocks of unused IP
addresses - not always feasible for enterprise network operators. We
introduce and evaluate the Greynet - a region of IP address space
that is sparsely populated with "darknet" addresses interspersed
with active (or "lit") IP addresses. Based on a small sample of
traffic collected within a university campus network we saw that
relatively sparse greynets can achieve useful levels of network scan
detection.
In other words, instead of setting aside prefixes that an attacker
might attempt to probe and in so doing court discovery, Harrop proposed
that individual (or small groups of adjacent) addresses in subnets be
set aside for the purpose, using different host identifiers in each
subnet to make it more difficult for an address scan to detect them. The
concept has value in the sense that it is harder to map the addresses or
prefixes out of an attacker's search pattern, as their presence is more
obscure. Harrop's research was carried out using IPv4, and yielded interesting information.
It has been observed that address
scanning is less effective in IPv6
networks, as there are more addresses to scan. The observation is of
limited value, in that there are other approaches to identifying IPv6
systems, such as reading the 'Received:' lines in SMTP envelopes. Such
attacks can be limited by the use of Privacy
Addresses, which periodically change, rendering such historical
information less useful, but the fact is that such analytic methods
exist. Greynets are a tool that can be used to isolate and analyze
them.
Corporate IT departments and other network operators frequently run
collectors or other kinds of sensors. A collector is a computer system
on the Internet that is expressly set up to attract and "trap" nefarious
attempts to penetrate computer systems. Such systems may simply record
the attempt or the datagram that initiated the attempt
(darknets/greynets), or they may act as a decoy, luring in potential
attacks in order to study their activities and study their methods
(honey pots).
To accomplish this, we separate nefarious traffic from that which is
likely normal and important, studying one and facilitating the
other.
One obvious way to isolate and identify nefarious traffic is to
realize that it is sent to a prefix or address that is not
instantiated. If a campus uses an IPv4 /24 prefix or an IPv6 /56
prefix but contains less than 100 actual subnets, for example, we
might use only odd numbered subnets (128 of the 256 available in that
prefix), and not quite all of those. Knowing that the active prefixes
are more specific and therefore attract appropriate traffic, we might
also advertise the default prefix from the collector, attracting
traffic directed to the uninstantiated prefixes in that routing
domain.
A second question involves mimicking a host under attack; the
collector may simply record this uninvited traffic, or may reply as a
honeypot system.
IPv4 subnets usually have some unallocated space in them, if only
because CIDR allocates O(2^n) addresses to an IP Subnet and there are
not exactly that many systems there.
Similarly, with active IPv6 prefixes, even a very large switched
LAN is likely to use a small fraction of the available addresses. This
is by design, as discussed in section 2.5.1 of . If the addresses are distributed reasonably
randomly among the possible values, the likelihood of an attacker
guessing what addresses are in actual use is limited. This gives us an
opportunity with respect to unused addresses within a IP prefix.
Routers use IPv4 ARP and IPv6 Neighbor Discovery to determine the MAC
address of a neighbor to which a datagram needs to be sent. Both
specifications intend that when a datagram arrives at a router serving
the target prefix, but which doesn't know the MAC address of the
intended destination, it should:
Enqueue the datagram,
Emit a Neighbor Solicitation or ARP Request,
Await a Neighbor Advertisement or ARP Response, and
On receipt, dequeue and forward the datagram.
Once the host's MAC address is in the router's tables (and in so
doing the address proven valid), the matter is not an issue.
In , the Greynet is described as being
instantiated on an end-host that replies to ARP Requests for all
'dark' IP addresses. However, a small modification to router behaviour
can augment this model. As well as queuing or dropping a datagram that
has triggered an ARP Request or Neighbor Solicitation, the router
forwards a copy of this datagram over an independent link to the
Greynet's analytic equipment. This independent link may be a different
physical interface, a circuit, VLAN, tunnel, or in fact any place such
a datagram could be handled.
The analytic equipment will now receive two types of datagrams. Of
most interest will be those destined for 'dark' IP addresses. Of less
interest will be the irregular case where a datagram arrives for a
legitimate local neighbour who has, for some temporary reason, no MAC
address in the router's tables. Datagrams arriving for an IP
destination for which an ARP reply (or Neighbor Advertisement) has not
yet received might also be forwarded to the analytical equipment over
the independent link - or might not, if they are considered to be
unlikely to provide new analytic information.
Analytic equipment, depending on the router to recognize 'dark' IP
addresses in this manner, can easily track arrival patterns of
datagrams destined to unused parts of the network. It may also
optionally chose to respond to such datagrams, acting as a honeypot to
elicit further datagrams from the remote source.
If the collector replies directly, the attacker may be able to
identify the fact through information in or about the datagram -
datagrams sent to the same IP Subnet may come back with different TTL
values, for example. Hence, it may be advisable for the collector to
send the reply back through the tunnel and therefore as if from the
same IP Subnet. Naturally the collector in this scenario should not
respond to datagrams destined for 'lit' IP addresses - the intended
destination will eventually respond to the router's ARP or Neighbor
Solicitation anyway.
An obvious extension of the concept would include traffic
identified by other filters as appropriate to send to the collector.
For example, one might configure the system to forward traffic failing
a unicast reverse forwarding path (uRPF) check to the collector via the same tunnel.
The implication for router design applies to the IPv4 ARP and IPv6
Neighbor Discovery algorithms. It might be interesting to provide, under
configuration control, the ability to forward arriving datagrams that
trigger an ARP Request or Neighbor Solicit, and then fail to receive the
intended response, to an interface, circuit, VLAN, or tunnel to an
analytic system.
This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author's perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor's discretion.
This note describes a tool for managing IPv4 and IPv6 network
security. Like any tool, it has limitations and possible attacks. If
discarding traffic under overload is a good thing, then holding and
subsequently forwarding the traffic instead places a potential load on
the network and the router in question, and as such represents a
possible attack. Such an attack has obvious mitigations, however; one
simply, in a manner the operator deems appropriate, selects a subset of
the traffic to forward and discards the rest. In addition, this attack
is not new; it is only changed in character. A stream that would
instantiate the attack today results in a load of ARP or Neighbor
Solicit messages that all listening hosts must intelligently discard.
The new attack additionally consumes bandwidth that is presumably set
aside specifically for that purpose.
The question of exactly what subset of traffic is interesting and
economical to forward is intentionally left open. Key questions in
algorithm design include what can be learned from a given sample (are
bursts happening, and if so with what data?), what the impact on the
router and other equipment in question is, how that might be mitigated,
etc. Possible selection algorithms dependent only on state and
algorithms typically available in a router include:
All datagrams triggering an ARP Request or Neighbor Solicit,
The subset of those that are not responded to within some stated
interval and are therefore likely dark,
The subset of those that are new; if the address is currently
being solicited, forwarding redundant data may not be useful.
All such datagrams up to some rate,
All such datagrams matching (or not matching) a specified filter
rule,
etc.
Algorithms for learning about Internet attack behavior by observing
backscatter traffic have been used by CAIDA, University of Michigan,
Team Cymru, and others. Harrop extended them in his research. This
formulation of the notion originated in a discussion among the authors
in 2005. This note grew out of a conversation with Paul Vixie and Rhette
Marsh on Internet traffic sensors; they also made useful comments on it.
Albert Manfredi commented on the distinction between a LAN (as defined
by IEEE 802) and an IP subnet.
Tim Chown has observed that, at least
at this time, address scanning attacks in IPv6 have not been reported in
the wild. Rhette Marsh has suggested the structure of such an attack,
however, and Fred Baker has suggested approaches based on addressing
information exchanged by applications. Hence, we believe that such
issues may be relevant to IPv6 in the future, when IPv6 is a more
interesting target.
Greynets: a definition and evaluation of sparsely populated
darknets
Swinburne University of Technology, Melbourne,
Australia
Swinburne University of Technology, Melbourne,
Australia