OpenBSD Journal

a2k18 Hackathon preview: Syncookies coming to PF

Contributed by Peter N. M. Hansteen on from the puffies-or-cookies-for-you dept.

As you may have heard, the a2k18 hackathon is in progress. As can be seen from the commit messages, several items of goodness are being worked on.

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 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)

  1. 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? :-)

    1. By Henning Brauer (henning) 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...

      1. By Philipp (pb) on

        *head->desk* Not that I was listening to that talk in the first place..


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]