[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56A8D4FD.3010904@ruecker.fi>
Date: Wed, 27 Jan 2016 14:32:29 +0000
From: Thomas B. Rücker <thomas@...cker.fi>
To: oss-security@...ts.openwall.com, pool@...ts.ntp.org, linuxbrad@...il.com
Cc: team@...urity.debian.org, secalert@...hat.com
Subject: Re: shodan.io actively infiltrating ntp.org IPv6 pools
for scanning purposes
-----BEGIN PGP SIGNED MESSAGE-----
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, ntp.org 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:
> http://netpatterns.blogspot.de/2016/01/the-rising-sophistication-of-ne
twork.html
>
>
>
In summary, some machines (which seem related to the shodan.io scanning
project)
> are actively participating in pool.ntp.org as IPv6 endpoints.
> However, clients connecting to them for NTP timesync, are
> subsequently scanned by probes originating from *.scan6.shodan.io
> 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 2.rhel.pool.ntp.org | grep -E
> ':[[:xdigit:]]00[[:xdigit:]]$' 2a03:b0c0:3:d0::18:b001 $ dig +short
> -x 2a03:b0c0:3:d0::18:b001 analog.data.shodan.io. ```
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 "example.org". 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:
analog.data.shodan.io 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 rock.scan6.shodan.io)
>
> pool.ntp.org 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 ntp.org admins: can those rogue server be expunged from the
> pools, and the whole shodan.io 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)
.
Cheers,
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlao1P0ACgkQfkVKO9VkYGlXxwCeLZoe5ANFbCyOKtaESwagM54k
fk0AnRP4OrloTSsT1zJdO13jpBkyQLDa
=BShC
-----END PGP SIGNATURE-----
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.
