[Pdns-users] TCP amplification attack notes

[Mike]

On 8/18/19 2:59 AM, Brian Candler wrote:
> On 18/08/2019 04:14, Mike wrote:
>> Â Â Â Â  I wanted to point out that I observed the same thing occuring
>> against my PowerDNS resolvers - I would get a low rate of TCP SYN's in
>> to port 53, the resolver would attempt to SYN-ACK these several times
>> without success, and then a new SYN would come in, starting the process
>> over again, so there is a small gain in amplification here but not like
>> ssdp or memcached for example.
>
> Thank you, that's very useful information.
>
> How low is "low rate" - that is, typically how many sockets are in
> SYN_RECV state?
>
> I am wondering if there would be any benefit trying to enable SYN
> cookies with a low threshold (esp. on authoritative servers where you
> can't block by source IP


In my case, I was seeing new SYN's  like every 5 or 8 seconds. Very low
rate.  Didn't really keep empirical data about sockets in SYN_RECV
however. As far as syn cookies go, I think the point here is that even
with, you would still be transmitting the SYN-ACK regardless. Syncookies
only help if you are getting flooded with SYN's and your queue is
already full, so not the case here.

What would be interesting in the case you cited, however, would be some
os-level filtering to penalize bad clients that never complete a
connection and drop their connection attempts for a configurable timeout
period. The easy part is dropping for the configurable timeout - ipset
has a nifty feature where addresses added to a set can be automatically
timed-out, and less efficient but still viable fail2ban can do it to.
The harder part is figuring out the list of bad clients who aren't
really real. I don't know any way that linux would expose information on
clients who initiate but don't complete a tcp connection (anyone got an
idea on that?). But then, you also have to consider what if someone just
spoofs SYN's from the query address of well known resolvers? You don't
want to start penalizing, say, google or cloudflare's open resolvers, if
someone just happens to know the (local to you) query address and starts
spoofing it, so you probably would then need an automatic whitelist for
any clients who have recently completed any tcp connection and allow
these to skip further checks. So at least, you would continue working as
normal with good clients, even if the possibility of sending them
useless SYN-ACK in this case. I see now a netfilter module I was not
aware of - SYNPROXY - which could probably serve as a good basis for
this idea....

In general I think this type of filtering would be a good 'secure by
default' configuration so that any tcp based services are automatically
and transparently limited in dealing with bad clients. I think this
could compliment syncookies since dropping the shit before any attempt
at a response is still a better policy. Although SYN-ACK sent back to a
spoofed address could be considered 'invalid' for any state-tracking,
not sending it in the first place would be hygienically better all around.


MIke-