[Firehol-devs] synproxy

[Tsaousis, Costa]

Hi all,

synproxy works. SYNPROXY is very tricky.

The template is:

synproxy input|forward [ optional rule parameters ] action ACTION

Where ACTION is DNAT, REDIRECT, ACCEPT, REJECT, DROP or a custom
action defined with the action helper.

Redirection and dnat work perfectly.

Be very careful with SYNPROXY though. The way it works in the kernel
may leave your system open. For example, a SYNPROXY on port 80 with a
transparent web proxy on the same machine, may allow attackers to use
your proxy (because the traffic generated by SYNPROXY appears to be
generated from localhost). I tried in the current version to eliminate
this issue by adding a new option for FIREHOL_TRUST_LOOPBACK. The
default was 1. Now there are 3 possible values: 'loose' (the same with
1 in the previous versions), 'strict' that trusts only traffic from/to
localhost IPs (127.0.0.0/8 and ::1) and 'no' (the old 0). If you use
SYNPROXY with REDIRECT, FireHOL will stop with an error if the setting
is not 'strict', to prevent a possible misuse.

The next few days, I will try to isolate the SYNPROXY completely.

Costa


On Mon, Feb 16, 2015 at 3:48 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> 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
> be defined)
>
> 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.
>
> Experiment freely...
>
> Articles about synproxy:
>
> https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html
>
> http://people.netfilter.org/hawk/presentations/devconf2014/iptables-ddos-mitigation_JesperBrouer.pdf
>
> http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/
>
> Costa