On 2023/07/19 19:54, mabi wrote:
> ------- 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.
For rules that pass traffic to your authoritative DNS servers,
I don't think you need much longer than the time taken to answer a
query. So could be quite a bit less.
> > (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?
Usually carp/ospf will enter the state table before the machines start
seeing large amounts of packets and stay there, which is what you would
normally want. If the state table is full, you have more problem
opening new connections that require state to be added than you do
maintaining existing ones.
fwiw I typically use this on ospf+carp machines, "pass quick proto
{carp, ospf} keep state (no-sync) set prio 7"
> > 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.
DNS server software is written with this type of traffic in mind, and
has more information available (from inside the DNS request packet)
to make a decision about what to do with it, than is available in a
general-purpose packet filter like PF.
Also it stores the tracking information in data structures that have
been chosen to make sense for this use (and common DNS servers default
to masking on common subnet sizes, reducing the amount they have to
store compared to tracking the full IP address).
http://man.openbsd.org/nsd.conf#rrl
https://bind9.readthedocs.io/en/latest/reference.html#response-rate-limiting
https://www.knot-dns.cz/docs/2.4/html/reference.html#module-rrl
