Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Jan 2016 14:32:29 +0000
From: Thomas B. Rücker <>
Subject: Re: actively infiltrating IPv6 pools
 for scanning purposes

Hash: SHA1

On 01/27/2016 11:24 AM, Luca BRUNO wrote:
> [cross-posted to pool-ntp and oss-sec]
> Hi, while reviewing network logs this morning I spotted some
> anomalies related to scan probes, pools and IPv6.
> It looks like Brad already observed and blogged about this some
> days ago, but I haven't seen this discussed in the usual ntp-pools,
> Debian and oss-sec ML, so I'm reposting this here: 
In summary, some machines (which seem related to the scanning
> are actively participating in as IPv6 endpoints. 
> However, clients connecting to them for NTP timesync, are
> subsequently scanned by probes originating from *
> hosts.
> Confirming original report from Brad, I can add that those scanners
> seem to implement some kind of rate-limiting: they will timeout NTP
> and won't re-scan recent clients when doing multiple/subsequent NTP
> requests. Moreover, this is not targeted/restricted to the Debian
> pool only, but plague the whole IPv6 pool, as seen on a sample
> query to the RedHat pool:
> ``` $ dig +short -t AAAA | grep -E
> ':[[:xdigit:]]00[[:xdigit:]]$' 2a03:b0c0:3:d0::18:b001 $ dig +short
> -x 2a03:b0c0:3:d0::18:b001 ```

While it's quite possible that the nodes are being run by Shodan, I
don't see conclusive proof of that just yet.
The reverse DNS, in my understanding could point to anything, including
"localhost" and "". It only gets confirmed by doing another
DNS request, a forward lookup, for the previously received FQDN and
comparing it to the initial IPv6 address.

In the example at hand this fails, as a lookup yields: has no AAAA record
While whois data for the IPv6 address shows this to be a digitalocean
droplet, just like mentioned by the linked blogpost regarding the other
addresses. So there is no obvious association with Shodan.

> (Upon querying this server for NTP, the machine immediately got
> IPv6-scanned by
> services are the default NTP servers in many default
> configurations (at least most of Linux distro) and I guess that
> this kind of behavior is dangerously increasing the exposure level
> of way too many systems.
> For admins: can those rogue server be expunged from the
> pools, and the whole situation clarified? (Brad's post
> has a comprehensive endpoints list and helper tools for detection)
> For oss-sec crowd: is there anything we can do to improve the
> situation and avoid similar cases in the future? Should
> crowd-sourced and fundamental services like this be encouraged to
> move to a stronger WoT?

I think it would be good if someone would ask Shodan for a statement.
This could clarify the above issue.

- From a security PoV I find this a fascinating and efficient approach to
finding hosts in, by design, sparsely populated IPv6 subnets. Just goes
to show, that if you don't want scans to reach your network, you should
run a perimeter firewall (determining sensible rules is on another page)



Version: GnuPG v2


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.