We discuss a number of strategies worms could use in an IPv6-based
Internet to ?nd new targets. We separate these into two categories, widearea and local-area searches, somewhat mirroring the IPv6 address architecture. We argue that worms will use different types of information
sources to ?rst determine existing networks and establish a presence there,
and then spread locally inside an organization. We hope to illustrate that
simple reliance on the IPv6 address space for protection against scanning
worms is not a wise defensive strategy, and we suggest areas where
research could assist in detecting and limiting future worm propagation.
Worm propagation strategies in an IPv6 Internet
Comments
One response to “Worm propagation strategies in an IPv6 Internet”
-
A good (and timely) paper; worth putting the URL in: https://www.cs.columbia.edu/~smb/papers/v6worms.pdf .
Thoughts:
Bellovin and Cheswick; no surprises there :-). Good to see they’re still “on the case”.
Good discussion of the decomposition of address space, and a handy contextual reference of “which RFC covers what”. I can imagine a bunch of people taking the “No site will have 2^16 subnets” assertion as a challenge ;-).
Egads, people running RIP on IPv6 networks…
Encoding Ethernet card manufacturer ID in stateless autocfg addresses… this initially appears to be is quite a lose…
The nearest-anycast server identification trick is a new one on me; I can see that being used “for real”. This is another reason to do “something more interesting” for host name resolution (although LDAP is useful in very many other ways…)
Some of the other techniques mentioned (DNS zone xfer, passive eavesdropping, host cfg / log file squinting, routing protocols, server logs (the other side of the transaction), P2P, search engine querying, SNMP querying of router tables) are “usual suspects” in IPv4 context, but their continued validity in v6 context is worth seeing confirmed. Fortunately, the validity of techniques to lock these protocols down in an IPv4 context, should work in an IPv6 context too – although it’s necessary to note that a device which is dual-stacking may well need locking down twice, once for each IP stack version.
The issue of low-numbered addresses is interesting and timely; a human-friendly standard imposing a lumpiness in search space. It suggests care might be worth taking to spread static addresses in infrastructure designs. Having just read another piece on the story of Bletchley Park, I’m reminded of the common German practice of starting Enigma messages with the bigraph “HH” as an analogous hook into search space reduction.
On finishing reading, this paper looks like the first of a series; the final paragraph and its coverage of “future work” suggests more interesting things are to come.
While it’s not strictly on topic for this paper, it also strikes me that, given the new size of search space, a suitably-configured tarpit server in an enterprise would make the job of a worm unequipped with prior knowledge of internal addressing and required to fall back on brute force, very difficult indeed…
Leave a Reply