Contributed by Peter N. M. Hansteen on from the puffies-or-cookies-for-you dept.
One eagerly anticipated item is the arrival of TCP syncookies (read: another important tool in your anti-DDoS toolset) in PF. Henning Brauer (henning@) added the code in a series of commits on February 6th, 2018, with this one containing the explanation:
syncookies for pf.
when syncookies are on, pf will blindly answer each and every SYN with a syncookie-SYNACK. Upon reception of the ACK completing the 3WHS, pf will reconstruct the original SYN, shove it through pf_test, where state will be created if the ruleset permits it. Then massage the freshly created state (we won't see the SYNACK), set up the sequence number modulator, and call into the existing synproxy code to start the 3WHS with the backend host.
Add an - somewhat basic for now - adaptive mode where syncookies get enabled if a certain percentage of the state table is filled up with half-open tcp connections. This makes pf firewalls resilient against large synflood attacks.
syncookies are off by default until we gained more experience, considered experimental for now.
see http://bulabula.org/papers/2017/bsdcan/ for more details.
joint work with sashan@, widely discussed and with lots of input by many
The first release to have this feature available will probably be the upcoming OpenBSD 6.3 if a sufficient number of people test this in their setups (hint, hint). More info is likely to emerge soon in post-hackathon writeups, so watch this space!
(Comments are closed)
By Philipp (pb) on
Since details are sparse for the very moment, I was wondering what the real difference to the long existing synproxy is.
Given the commit message I see two points emerging:
- less allocation
- adaptiveness
- ...more? :-)
Comments
By Henning Brauer (henning) henning@openbsd.org on
synproxy protects the backend host, but not the firewall itself - a large synflood will still run the state table against its limit quickly.
The way syncookies are used here prevents *any* ressource allocation on the firewall until the client finishes up the 3WHS.
See the linked presentation for details...
Comments
By Philipp (pb) on
*head->desk* Not that I was listening to that talk in the first place..