costa at tsaousis.gr
Mon Feb 16 01:48:27 GMT 2015
The latest commit of FireHOL supports SYNPROXY.
There is a helper for it:
synproxy input|forward [ optional rule parameters ] [ dnat to
IP[:PORT] ] [ redirect to PORT ]
(of course use synproxy4 or synproxy6, since this requires some IPs to
SYNPROXY is a TCP 3-way-handshaking proxy. The clients connect to
SYNPROXY and only once the TCP sockets are established, the real
server will get the requests.
Practically this means that the real server will never see spoofed
packets and will never get a DDOS attacks. The SYNPROXY is highly
optimized for taking care exactly these cases.
The downside is that you have to know the TCP options the server uses
(FireHOL has the variable FIREHOL_SYNPROXY_OPTIONS that defines the
options used by the synproxy helper. They are: --sack-perm --timestamp
--wscale 7 --mss 1460).
SYNPROXY is somewhat tricky to work with at the firewall level, mainly
because it changes the flow the packets traverse. For example,
SYNPROXY sockets bypass the NAT mechanism, since the packets are
received by the firewall and are re-send to the real servers from the
firewall (via the OUTPUT chain in iptables, instead of the FORWARD).
Of course it does not alter the client IPs (it is not a proxy, like
squid or socks).
The version in FireHOL is already operational for handling servers on
localhost. For example the following will attach a SYNPROXY on your
web server running on the firewall:
synproxy input inface dsl0 dst YOUR_INTERNET_IP dport 80
It can also be used to protect servers you DNAT in your DMZ. For
example the following will attach a SYNPROXY for the traffic sent to a
web server at 10.1.1.1.
synproxy forward inface dsl0 dst YOUR_INTERNET_IP dport 80 dnat to 10.1.1.1
I am currently trying to figure out how to make it work for REDIRECTed traffic.
Articles about synproxy:
More information about the Firehol-devs