netfilter/iptables synproxy; need help deciding

Paige Thompson paigeadele at gmail.com
Wed Oct 8 15:13:47 UTC 2014


On 10/08/14 18:06, Thijs Stuurman wrote:
> 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-----
> Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Paige Thompson
> Verzonden: Wednesday, October 8, 2014 4:51 PM
> Aan: Nanog
> Onderwerp: 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

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. 




More information about the NANOG mailing list