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- _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
