[dns-operations] Botnets, botnets everywhere

[Cathy Almond]

On 11/09/2014 13:38, Peter Andreev wrote:
> Hello,
> 
> We run a public resolver and a few days ago I noticed a lot of very
> weird queries, like the following:
> 
> 16:11:41.450794 IP 217.195.66.253.37426 > 62.76.76.62.53: 42580+ A?
> swfjwvtkhqx.www.feile8888.com. (47)
> 16:11:41.450796 IP 91.209.124.75.50584 > 62.76.76.62.53: 37269+ [1au]
> A? izhsccxedub.www.feile666.com. (57)
> 
> For the total amount of SLDs of 11, the only common in those queries
> are random labels on the left side. One of those SLDs is an
> online-shop, another is online-casino, so I concluded that our
> resolver is being used to bombard NSes of corresponding SLDs with
> queries.
> I'd like to ask the respected community, how do you detect and protect
> against such activity? Will RRL help me if all suspected queries come
> with random qname?
> 
> Thank you in advance.
> 

There's a lot of this about.

We did awhile back wonder if it was botnet-related, but I've not (yet)
seen any persuasive evidence that it is.

Our current thinking (based on evidence from some of our customers, and
also from Nominum's analysis presented at the Warsaw DNS-OARC workship
earlier this year) that the majority of these recent query spates are
intended as an attack on the domain (e.g. feile8888.com) or the
nameserver hosting it.  Once overwhelmed with query traffic, the DNS
servers cease responding, or only respond sporadically.  These
authoritative server admins may also be deploying RRL to protect
themselves too - but from your perspective, they're non-responding
either way (with one exception - which is if they respond with the TC
bit set to encourage a TCP-based query instead).

The attackers appear to be making use of open resolvers (lists of which
are readily available) presumably in order to ensure that the queries
come from a whole range of clients, and possibly to provide another
level of obscurity for the actual source.

If you're running a public recursive server, you may be seeing the
queries both directly and indirectly.  The indirect queries are likely
being forwarded to you by other servers or by insecure CPE devices that
proxy queries to port 53 on their WAN interface by forwarding them to
the ISP provider's DNS servers.

There are quite a few things you can do to alleviate the problem,
including limiting access to your open resolvers, identifying and
blocking traffic that is coming to you via broken CPE devices, and
identifying and communicating with admins of open resolvers that are
forwarding to you.

Other techniques include making yourself authoritative for the domains
that are under attack (you can usually identify them from the traffic -
some admins have scripted solutions), and/or using a DNS RPZ domain to
block the queries - although you need a version of DNS RPZ that includes
the qname-wait-recurse option that you'll want to set to 'yes' to make
the rewriting occur prior to iteration.

If you're running BIND, we're working on some new recursive rate
limiting techniques that we're quite keen to get more exposure to - they
involve rate-limiting queries to servers that are becoming
non-responsive.  I presented on the most recent evolution of those
earlier this week at UKNOF29 in Belfast (they were earlier aired at
IETF90 in Toronto and some useful suggestions taken on-board).

https://indico.uknof.org.uk/conferenceOtherViews.py?view=standard&confId=31

See Nominum's session at 9:40 with further analysis of the traffic, and
mine at 10:00 on various mitigation techniques.

Hope this helps?

(And also, I'm very keen to hear/see evidence of other causes and
sources of this type of query traffic)

Cathy