‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 17, 2020 11:50 PM, Stuart Henderson <[email protected]> 
wrote:

> These packets are most likely sent from spoofed source addresses.
>
> Assuming this is the case, the address you are seeing on the packets
> would not be the attacker but the victim.

That totally makes sense because why would google be sending me all these DNS 
packets from different IP addresses from their network.

Here is an example of packet which was logged by Bro (now called Zeek) on my 
NSM and there are tons of these during a time window of 3 minutes:

{"ts":"2020-11-17T14:02:00.059396Z","uid":"CD5YJQ2eVZKX6bhyoj","id.orig_h":"74.125.18.1","id.orig_p":51423,"id.resp_h":"<MY_DNS_SERVER>","id.resp_p":53,"proto":"udp","trans_id":39451,"rcode":3,"rcode_name":"NXDOMAIN","AA":false,"TC":false,"RD":false,"RA":false,"Z":0,"rejected":false}

> PF doesn't support this type of request rate limiting on UDP
> connections. It's a bit dangerous to do so because in many cases it's
> trivial to spoof UDP packets and blocking packets from a source on the
> basis of this can result in you DoS'ing yourself. This isn't such a
> problem with TCP because only someone on the network path between
> you and the supposed source address (i.e. someone with access to
> the ACK packets) is likely to be able to successfully spoof packets.

I understand and that's what I thought. So there is no much point in me trying 
to add "max-src-states 10" for example to my pass in rule for DNS UDP traffic 
to my DNS servers.


> To mitigate this you might like to read the manual for your
> authoritative nameserver software about RRL (response rate limiting),
> many support it directly (including BIND and NSD), if not then you could
> front-end with something that can handle it itself like dnsdist.
>
> The DNS RRL techniques typically still reply to a proportion of queries
> (either directly with the answer, or with a "retry over TCP" response
> code) reducing impact if the source IP is also used by real queries as
> well as the attack traffic.

I've been looking into that in the past and as I am using PowerDNS 4.0.3 the 
only valid config parameters I could find and which I already have in place are 
the following:

overload-queue-length=1
max-tcp-connections=5

There is as far as I know no such parameter as "max-udp-connections".

Reply via email to