netfilter/iptables synproxy; need help deciding

Hi,

I guess syncookies wasn't enough and the SYNPROXY target is a relatively
new addition to netfilter. If I remember correctly this has been a part
of BSD PF for quite some time and is pretty easy to get up and working.
I recently tried to set this up on one of my gateways considering that
it's just one less uncovered means for somebody to be a dick that I have
to deal with in the future. But, after spending some time researching
and asking on Freenode I have been unable to determine whether or not it
works, or even makes any sense. I'm starting to think it's a moot point.
pastie.org/private/gjsypxkpjs8kuev0tlbxrw#22 (iptables rules, plenty of
things to pick at but please try to focus on the subject of synproxy for
the purpose of this e-mail.)

based on the following table I want to say its not working because it
seems to never change:
http://pastie.org/private/xwct5opbb0aajcko2tnpw

more info on /proc/stat/synproxy:http://www.spinics.net/lists/netdev/msg264350.html

My only guess is that you can't do this at all with NAT because it
relies on conntrack or maybe it will only work with SNAT? I don't
understand this well enough to say; are proper firewall rules really a
science that need to be understood that far in depth? Why is this not
documented? This tutorial seems to indicate that you could use this with
a NAT'd network:
http://www.academia.edu/6773989/Homemade_DDoS_Protection_Using_IPTables_SYNPROXY

I really would like to come to some closure on this subject. Whether it
needs to be done right or not done at all, I'm tired of it looming over
me. I really want to believe I should do the very best to have all
mitigation techniques already in place, but I'm having a hard time
understanding why this is next to impossible to figure out if it's so
important. #netfilter on freenode is next to no help, the mailing list
seems to be unavailable.... the things people are saying about how I
should "just switch" back to using pf seem like a drastic solution when
people in #netfilter are so content (yet many of them have never heard
of synproxy before.)

Any thoughts on this are appreciated,

-Paige

I set up a bridge at home to filter traffic using iptables with synproxy. I tried to adjust the lines so that it would log hits but that wouldn't work
It gave me a message to read dmesg why it didn't work but dmesg had no information in it.
However, when I turned on the lines in my iptables configuration file (bash script to load in the rules basicly) it did filter out a SYN attack and the output of "cat /proc/net/stat/synproxy" showed the syn_received go up. (see https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html)

A tcpdump on the bridge confirmed the packets coming in and on my server behind it they didn't so that worked while I would perfectly fine access the apache service.

I haven't done any further testing, just got the setup to work late last night.

Kind regards / Vriendelijke groet,
IS Group
Thijs Stuurman

Powered by results.

Wielingenstraat 8 | T +31 (0)299 476 185
1441 ZR Purmerend | F +31 (0)299 476 288
http://www.is.nl | KvK Hoorn 36049256

IS Group is ISO 9001:2008, ISO/IEC 27001:2005,
ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified.

-----Oorspronkelijk bericht-----

Yeah, I have no way to test for sure but I can tell you this which I
forgot to mention:

All of my services still work with these rules
-A PREROUTING -d 172.16.20.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
-A PREROUTING -d 172.16.40.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
-A PREROUTING -d 172.16.80.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack

None of my services worked with this rule:
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack

I sort of get it, but I totally don't get it. I'm not sure what traffic that second rule is matching (or if the -d even works in the raw table maybe thats bunk too.) I don't think the first set are working,
but I have no way to test it either.

Try the examples given here: https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html

Your line make no sense to me:

"""
-A PREROUTING -d 172.16.20.98/32 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
"""

The first entry should register it in the raw table and this is for SYN only, RST, ACK etc' should be handled by an INVALID filter together with "sysctl -w net/netfilter/nf_conntrack_tcp_loose=0".

So only for the SYN packets you configure the SYNPROXY as such:

iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -I INPUT -p tcp -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460

In my case I believe I adjusted the INPUT on the second line to FORWARD as my box functions as a bridge. I'll check and mail you when I get home.

Kind regards / Vriendelijke groet,
IS Group
Thijs Stuurman

Powered by results.

Wielingenstraat 8 | T +31 (0)299 476 185
1441 ZR Purmerend | F +31 (0)299 476 288
http://www.is.nl | KvK Hoorn 36049256

IS Group is ISO 9001:2008, ISO/IEC 27001:2005,
ISO 20.000-1:2005, ISAE 3402 en PCI DSS certified.

-----Oorspronkelijk bericht-----