Hi all
Joe Abley's email inspired me to take some action on this. For anyone who
doesn't know me I work at Inspire Net. Here's a brief description of what
we've done so far and what we intend to do.
We contacted the Open Resolver Project and arranged a report of the open
dns resolvers under our ASN (17705). This is a report that changes each
week so the first job was to script retrieving this weekly, matching IPs
vs. customers and emailing it somewhere useful (a ticketing system).
We then tackled some low hanging fruit. We found two categories of these:
1) A NetComm router (NB604N) that is in common use on ADSL connections in
NZ. We supplied this so we took responsibility for it. The particular
firmware that seems to be vulnerable is GAN5.CZ56T-B-NC.NZ-R4B031.EN. Newer
versions are fine, older versions are fine. It seems this version in
particular enables the DNS resolver by default but doesn't activate the
firewall for this. Our helpdesk resolved all of these by arranging a
firmware upgrade for them.
2) Being a smaller ISP we recognised many people on our processed list as
being a) people we know and b) having some technical clue. These people
have been contacted and encouraged to lock things down. We've supplied
handy links like Spamhaus's report on their big DDoS, Team Cymru's
educational video (http://www.youtube.com/watch?v=XhSTlqYIQnI) and Team
Cymru's guide to fixing the issue. The majority of these customers have
promptly fixed the issue.
With a bit more investigation it seems that the remaining open resolvers
fall in to two categories:
1) Bad CPEs. CPEs that run an open resolver by default open to the world.
TP-Link seems to be the biggest issue here. We didn't supply this but
intend on giving a bit of help to customers with fixing this.
2) Customers for one reason or another opening their DNS server to the
world (pinhole or firewall entry) AND not configuring an ACL for it. To me,
the practice of voluntarily opening a service to the world that one doesn't
understand is questionable, but the number of clued people that seem to do
this is non-trivial.
A key is having a nice organised person to drive this along; That isn't me
:)
Finally, some rough stats so far.
-Somewhere between 1 - 2% of our customers have this issue. This being so
high surprised me!
-By tackling my "low hanging fruit" we resolved approx. 15% of the open
resolvers. This was minimal effort.
-At our aimed rate of contact it will take 12 weeks for us to let all of
the customers know they have this issue and offer advice on it.
Finally, as a multi-choice question to the industry...
What should we do about the customers who don't fix this issue within a
reasonable time-frame once we've told them about it?
1) Do nothing
2) Contact them again
3) Block international port 53 requests going to them at our border routers
(can be done with minimal effort and load on the routers in question - I'm
quite against this though)
Any questions let me know. Will aim to update again in the future.
Cheers
Dave
On Wed, May 8, 2013 at 3:18 AM, Joe Abley
There seem to be a non-trivial number of open resolvers in the few NZ ASes I just checked. It would be good if there was a concerted effort into shutting them down, or otherwise neutering them so that they can't be effective amplifiers for DDoS attacks.
This is last decade's open mail relay problem, except with less spam, more packet love.
Begin forwarded message:
From: Jared Mauch
Subject: [outages] Open Resolver Project Date: 7 May 2013 10:52:53 EDT To: "outages(a)outages.org" X-Mailer: Apple Mail (2.1503) The Open Resolver Project made a mistake in the automation process of the weekly data import. If you're unaware of what it is, I suggest looking at the website - openresolverproject.org
If you operate a DNS server, or are a network operator, you should check your IP space for Open Resolvers. These are used in DDoS attacks and pose a significant risk to the global network.
The website has been restored to operation, but please take a moment and check your IPv4 space.
If you want a report based on your ASN, please e-mail dns-scan(a)puck.nether.net from a corporate e-mail address or something matching the RIR database entry.
Thanks,
- jared _______________________________________________ Outages mailing list Outages(a)outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog