Difference between revisions of "Synproxy"

From nftables wiki
Jump to navigation Jump to search
(Linked early synproxy patchset announcemen with detailed operational description.)
(Intro: added note to disable nf_conntrack_tcp_loose.)
Line 1: Line 1:
A netfilter synproxy intercepts new TCP connections and handles the initial 3-way handshake using syncookies instead of [[Connection_Tracking_System|conntrack]] to establish the connection. Running synproxy on a listening server port thus prevents a [https://en.wikipedia.org/wiki/SYN_flood SYN flood] attack on that port from consuming limited conntrack resources.
A netfilter synproxy intercepts new TCP connections and handles the initial 3-way handshake using syncookies instead of [[Connection_Tracking_System|conntrack]] to establish the connection. Running synproxy on a listening server port thus prevents a [https://en.wikipedia.org/wiki/SYN_flood SYN flood] attack on that port from consuming limited conntrack resources.
When using synproxy it is important to disable the conntrack loose tracking option:
<source>
% echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
</source>
With this setting the final handshake ACK from the remote host will be marked INVALID and won't create a new conntrack entry. In our accept rule for such connections we explicitly accept these "INVALID" packets and pass them along to our listening service (see examples below).





Revision as of 16:14, 8 April 2021

A netfilter synproxy intercepts new TCP connections and handles the initial 3-way handshake using syncookies instead of conntrack to establish the connection. Running synproxy on a listening server port thus prevents a SYN flood attack on that port from consuming limited conntrack resources.

When using synproxy it is important to disable the conntrack loose tracking option:

% echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose

With this setting the final handshake ACK from the remote host will be marked INVALID and won't create a new conntrack entry. In our accept rule for such connections we explicitly accept these "INVALID" packets and pass them along to our listening service (see examples below).


Anonymous synproxy

An anonymous synproxy exists in the context of the single rule to which it is attached. The following ruleset configures an anonymous synproxy for port tcp/8888:

table ip anon_synproxy_demo {

    chain PRE {
        type filter hook prerouting priority raw; policy accept;

        tcp dport 8888 tcp flags syn notrack
    }

    chain IN {
        type filter hook input priority filter; policy accept;

        tcp dport 8888 ct state invalid,untracked synproxy mss 1460 wscale 7 timestamp sack-perm
        ct state invalid drop
    }
}

Support for anonymous synproxy was added in nftables 0.9.2.


Named synproxy

table ip foo {

    synproxy https-synproxy {
        mss 1460
        wscale 7
        timestamp sack-perm
    }

    synproxy other-synproxy {
        mss 1460
        wscale 5
    }

    chain pre {
        type filter hook prerouting priority raw; policy accept;

        tcp dport 8888 tcp flags syn notrack
    }

    chain bar {
        type filter hook forward priority filter; policy accept;

        ct state invalid,untracked synproxy name ip saddr map {
            192.168.1.0/24 : "https-synproxy", 
            192.168.2.0/24 : "other-synproxy",
        }
    }
}

Support for using synproxy named objects was added in nftables 0.9.3.


See also