[Firehol-devs] synproxy

[Tsaousis, Costa]

Hi all,

wiki page for synproxy added:

https://github.com/ktsaou/firehol/wiki/Working-with-SYNPROXY

Costa


On Fri, Feb 20, 2015 at 2:25 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> 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