[Firehol-devs] synproxy

[Tsaousis, Costa]

Hi all,

Using the latest commit of firehol, synproxy is secure. I have used a
mark to isolate it completely from the rest of the firewall. It can
now co-exist with all other features. The only prerequisite for safe
usage is to place the synproxy statements before any NAT you have in
firehol.conf.

Remember, synproxy() bypasses NAT and packet filtering. The action you
specify to it will be executed independently of the rest of the
firewall.

You can enable it for any TCP server, with just one line.

I already use it like this:

# Setup a SYNPROXY on port 2200 and send it to SSH server:
synproxy4 in   inface "${wan}" dst XXX.XXX.XXX.XXX dport 2200 redirect
to 22 loglimit "SYNPROXY SSH"

# Setup a SYNPROXY on port 80 for the local web server
synproxy4 in   inface "${wan}" dst XXX.XXX.XXX.XXX dport 80 accept
loglimit "SYNPROXY WEB"

# Setup a SYNPROXY on port 80 and send it to the web server at 10.1.1.1
synproxy4 pass inface "${wan}" dst XXX.XXX.XXX.XXX dport 80 dnat to
10.1.1.1 loglimit "SYNPROXY web at 10.1.1.1"

In all examples XXX.XXX.XXX.XXX is the IP the client thinks is the server.

You can also use it with custom actions, like the TRAP_AND_REJECT on
the iptrap wiki page. Actually I use synproxy as a curtain in front of
my home adsl for all ports. Then all illegal ports are trapped the
client is blacklisted. This guarantees that we blacklist clients that
actually passed the TCP 3-way handshake.

My home netdata server at http://www.tsaousis.gr:19999/ is served via
a synproxy too.

To check the iptables statements it generates, you can use the
'explain' mode of firehol. You will be surprised! Especially the
redirect example will blow your mind ! (the SYN packet packet loops
inside the machine, leaves with outface lo and comes back in with
inface lo).

Costa

PS: I also added iprange functionality to firehol. You can now define
ip ranges in src and dst like this: 10.1.1.1-10.1.1.127 (just use a
hyphen to specify a range).


On Thu, Feb 19, 2015 at 3:39 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> 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