------- Original Message ------- On Wednesday, July 19th, 2023 at 9:32 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> If PF is struggling as it is, there's a good chance it will buckle > completely if it has to do source tracking too That is also something I thought might be the case :| > Did you already tweak timeouts for the rule passing UDP DNS traffic? > Defaults are 60s/30s/60s for udp.first, udp.single and udp.multiple > respectively, that is much too high for a very busy DNS server - > you can set them on the specific rule itself rather than changing > defaults for all rules. For an auth server which is expected to > respond quickly they can be cranked way down. Yes, this at least I did since quite some time now and use the following timeout settings: set timeout udp.first 20 set timeout udp.multiple 20 set timeout udp.single 10 Do you think I could go even lower? When I check the PF state entries during such a DDoS I see mostly states with the "SINGLE" state. > (If that is still too many states, I wonder if your network might > actually be happier if you "pass quick proto udp to $server port 53 no > state" and "pass quick proto udp from $server port 53 no state" right at > the top of the ruleset). That's actually an excellent idea to bypass PF states and hence consume less resources... Next thing to try out. I was also thinking I should use "no state" with CARP and OSPF rules in pf.conf so that in case the PF state table entries is full it does not prevent such important protocols to function. What do you think, would that also work? > Are you already using your DNS server's response rate limiting features? Not yet, as I still believe I should stop as much as possible such traffic at the firewall before it even reaches the network behind my firewall. So at the software/daemon/service level it would be my last line of defense.
