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.
This makes it easier to maintain and deploy more aggressive DDoS
mitigation when our main HTTPS services are under attack.
Network servers use HTTP for connectivity checks which do not use
keepalive and should also be a good use case for
This has the same reasoning as 9fcac6b105
other than these services being used for MTA-STS in addition to ACME and
redirects to the FAQ for the domains.
Our DNS servers only have HTTP(S) for obtaining certificates via ACME
with accounturi pinning along with redirecting people who visit the
domain in a browser to our server documentation. We also only permit 1
request for each HTTP(S) connection for these services so connections
are very short lived.
We'll need to do this in a less aggressive way for our web sites and our
services used to transfer significant amounts of data such as the update
servers since not all clients have TCP timestamps and will lose SACK and
window scaling with the current Linux SYN cookie design despite it being
possible to avoid that as FreeBSD does.
