<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Just to flush out the details here, in case anyone is wondering. We
have a small number of domains that are DNSSEC signed, but those
under attack are not signed.<br>
<br>
In the past two days, I am seeing RRL kicking in heavily for queries
for host names or subdomains in the form:<br>
<br>
<variable>.example.com<br>
<br>
From IPv4 and IPv6 Google ip addresses. At the same time, but I see
a few of the 'no more TCP clients: quota reached' messages. Again,
after the RRL limit kicking in, rolling over to TCP is expected. <br>
<br>
I am seeing the 'attack' first against one domain for a period of
only a few(less than 5) minutes. And then the next day, another
flurry of activity against another domain lasting about 4 minutes.<br>
<br>
I am not sure what the goal is of the attackers yet. But in
bouncing the queries through Google does a pretty good job of hiding
their identity from me.<br>
<br>
I have logs with time stamps I can provide to Google if they are
interested. <br>
<br>
In this the amount of queries against one domain did catch my
attention in reviewing logs, but the roll over to TCP causing the no
more TCP clients: quota reached' made it more interesting to follow
up on. Esp to hear how the other side reacts to the TCP errors. I
guess Google would have to answer that question.<br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
<div class="moz-cite-prefix">On 11/01/14 22:45, Paul Vixie wrote:<br>
</div>
<blockquote cite="mid:5455A8D7.2000506@redbarn.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:54557CBA.3040808@lcrcomputer.net" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr">
<div style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px">
<div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="lyle@lcrcomputer.net" photoname="Lyle
Giese" src="cid:part1.08060802.04030608@lcrcomputer.net"
name="compose-unknown-contact.jpg" width="25px"
height="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true"
href="mailto:lyle@lcrcomputer.net" style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Lyle Giese</a></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Saturday,
November 01, 2014 5:37 PM</span></font></div>
</div>
</div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
Now on the TCP side, I am seeing 'no more TCP clients: quota
reached'. I am still not clear on what the other side is told
or what it thinks is going on at this point. My thought
process/logic is that a TCP Reset should be handled above the
application layer and that an application could not
create/generate that. Of course, I can be wrong on this point
and would welcome corrections.<br>
<br>
Now that I have written this, I suspose it's within reason
that an application can tell the upper layers, I am to busy to
handle that request, drop the TCP session and those layers use
the RST function to accomplish that.<br>
</div>
</blockquote>
<br>
yes. in general, when you receive a tcp connection that puts you
over your application layer quota, you close() it, possibly
shutdown()'ing it first. this will send a FIN immediately, and
send an RST if non-meta data keeps coming.<br>
<blockquote style="border: 0px none;"
cite="mid:54557CBA.3040808@lcrcomputer.net" type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<br>
But it sounds more and more like an DoS attempt against my
authoritative servers by exhausting TCP resources. And they
were utilizing Google's servers to assist in that process.
Not at all sure what the heck they would be trying to
accomplish hitting up my servers.</div>
</blockquote>
<br>
my intuition is that this is not a TCP attack per se. if you look
at the QNAME's google is sending you, they will probably be
pseudo-random subdomains of the zones you are authoritative for.
and if your zone is signed with DNSSEC, and has no wildcard, then
you may find that google's EDNS buffer size is not large enough to
contain the responses you are sending, so, you're sending TC=1 for
other reasons, and google is coming back with TCP a lot more often
than RRL could possibly cause them to do.<br>
<br>
in other words TCP is a side show, the real thrust of this attack
is likely elsewhere in your mix.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:54557CBA.3040808@lcrcomputer.net" type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">And I would assume
that it would take a lot more to accomplish a DoS attack
against Google's servers this way! But it's an excellent way
for the attackers to hide their identity from me as I see only
Google's IP addresses in the requests.<br>
</div>
</blockquote>
<br>
google has been doing their own version of RRL for a long time,
longer than DNS RRL has been specified, and they do a pretty good
job. however, pseudo-random subdomains are the attack du jour, and
google's rate limiting machinery might not be coping with it well.
even so, it would take a botnet-sized client population hammering
google public dns with pseudo-random subdomains of your zones to
get google to actually launch that number of simultaneous queries
toward your authority servers.<br>
<br>
i recommend analyzing your QNAMEs so that you can isolate the
target.<br>
<br>
google's dns people are certainly monitoring this thread and it's
my bet that they'll be in touch with you privately.<br>
<br>
<div class="moz-signature">-- <br>
Paul Vixie<br>
</div>
</blockquote>
<br>
</body>
</html>