This only applies to outbound NTP requests since we use notrack for our
UDP services and DNS-over-TLS for our local resolver. We'd have no need
for longer timeouts even if that wasn't the case.
This isn't used anymore despite inaccurate kernel configuration
documentation. The SYN_RECV queue is set based on the backlog value
just like the separate accept queue for established connections.
It's extremely useful to have this around for debugging network issues,
testing firewall rules and other purposes. It's not particularly useful
having nmap itself, but nping and to a lesser extent ncat are great to
have available.
This provides consistency with DDoS protection services placed in front
of the services rather than the behavior changing based on whether DDoS
protection is active. This doesn't help with protecting against attacks
since they'll almost always be targeting ports with services active or
exhausting inbound bandwidth via UDP reflection attacks. This appears to
be the standard approach used by most large tech companies.
Our network servers are spiking over the default burst limit of 5
packets during regular usage. It's unclear high this should be but 5
packets is definitely too low.
Now that the usage of synproxy is gated behind a SYN packet rate limit,
we can expand this to all our TCP services to have always enabled DDoS
protection instead of needing to deploy a stricter set of rules when the
servers are under attack. This is far better because there isn't always
a system administrator available to handle an ongoing attack.
We already used per-IP connection limits in nginx across the board but
those limits are applied far too late after a TLS connection has been
established and headers are sent rather than before. Using IPv6 /64
blocks means this is much more aggressive for IPv6, but many clients
will fall back to IPv4 due to the happy eyeballs approach. The nginx
limits are still useful due to HTTP/2 multiplexing and we'll need to
think over how to address IPv6 there.
