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-IP...)
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@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_SYNP...
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.