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-boun...@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.
