[dns-operations] Botnets, botnets everywhere

[Peter Andreev]

2014-09-11 21:02 GMT+04:00 Cathy Almond <cathya at isc.org>:
> 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).

I agree that it looks like an attack on DNS infrastructure. However
yesterday I read a discussion between members of CENTR security
workgroup and met a very interesting opinion that domains in question
are belong to one of the biggest asian betting sites and it may be
their way to identify clients or something so. Despite that I've
counted these queries as malicious and moved all these domains to
blocklist.

>
> 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.

The main problem is the automatic identifying. Currently I see no
relations between different packets and have to cope with the problem
by hand.

>
> 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.

This is what I actually did.

>
> 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
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.