Article 4TQBS iptables SYNPROXY extension not working?

iptables SYNPROXY extension not working?

by
Pigi_102
from LinuxQuestions.org on (#4TQBS)
Hello !

I'm having a hard time getting SYNPROXY working on my ( iptables based ) firewall.

It's quite some time I've noticed that may servers ( in DMZ ) are under SYN flood attack and readed almost every link I've found to make this target working with no chance.
Code: |
| Internet ( eth0 )
|
+---------+
| +----- br0 (bridge for openvpn tun )
| |
| Fw +----- DMZ ( eth1 )
| |
+---------+
|
| Internal net ( eth2 )
|Easy setup, as you can see.

I have a bunch of rule ( INPUT OUTPUT FORWARD and NAT ) that are currently working, but I can't get in any way this three rules to work:
Code:/usr/sbin/iptables -t raw -I PREROUTING -i br0 -p tcp -m tcp --syn --dport 81 -j CT --notrack
/usr/sbin/iptables -A INPUT -i br0 -p tcp -m tcp -m conntrack --dport 81 --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1323
/usr/sbin/iptables -A INPUT -m conntrack --ctstate INVALID -j DROPIf I enable them, I can see the SYN packet ( from the br0 interface ) that enter the interface, but no SYN+ACK reply exiting:
Code:root@firewall:~# iptables -t raw -L -v -n
Chain PREROUTING (policy ACCEPT 418 packets, 67307 bytes)
pkts bytes target prot opt in out source destination
0 0 CT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 flags:0x17/0x02 CT notrack

root@firewall:~# iptables -L INPUT -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
17 1776 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 SYNPROXY tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 ctstate INVALID,UNTRACKED SYNPROXY sack-perm timestamp wscale 7 mss 1323
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID

other_host# telnet 10.0.1.51 81
Trying 10.0.1.51...
telnet: connect to address 10.0.1.51: Connection timed outThe SYNPROXY get triggered:

Code:root@firewall:~# iptables -t raw -L -v -n
Chain PREROUTING (policy ACCEPT 1453 packets, 360K bytes)
pkts bytes target prot opt in out source destination
4 240 CT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 flags:0x17/0x02 CT notrack

root@firewall:~# iptables -L INPUT -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
247 164K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
587 219K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 180 SYNPROXY tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 ctstate INVALID,UNTRACKED SYNPROXY sack-perm timestamp wscale 7 mss 1323
22 1000 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALIDbut also tcpdump confirm no SYN+ACK exit to the client:
Code:root@firewall:~# tcpdump -n -i br0 port 81
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes

14:39:32.755800 IP 10.0.1.18.32886 > 10.0.1.51.81: Flags [S], seq 521240151, win 29200, options [mss 1323,sackOK,TS val 2209244648 ecr 0,nop,wscale 7], length 0
14:39:33.784981 IP 10.0.1.18.32886 > 10.0.1.51.81: Flags [S], seq 521240151, win 29200, options [mss 1323,sackOK,TS val 2209245678 ecr 0,nop,wscale 7], length 0Values for the SYNPROXY are derived from tcpdump:

Code:root@firewall:~# tcpdump -pni br0 port 81
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:46:49.704573 IP 10.0.1.18.32922 > 10.0.1.51.81: Flags [S], seq 60519528, win 29200, options [mss 1323,sackOK,TS val 2209681605 ecr 0,nop,wscale 7], length 0
14:46:50.704828 IP 10.0.1.18.32922 > 10.0.1.51.81: Flags [S], seq 60519528, win 29200, options [mss 1323,sackOK,TS val 2209682606 ecr 0,nop,wscale 7], length 0
^CThe same thing happen on every interface I'm trying ( eth0 eth1 eth2 ) so it's not a problem on bridged interface

If I remove the SYNPROXY rules, everything works:

Code:other_host# telnet 10.0.1.51 81
Trying 10.0.1.51...
Connected to 10.0.1.51.
Escape character is '^]'.
^]
telnet> c
Connection closed.

root@firewall:~# tcpdump -n -i br0 port 81
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:49:00.998297 IP 10.0.1.18.32934 > 10.0.1.51.81: Flags [S], seq 1887031231, win 29200, options [mss 1323,sackOK,TS val 2209812901 ecr 0,nop,wscale 7], length 0
14:49:00.998517 IP 10.0.1.51.81 > 10.0.1.18.32934: Flags [S.], seq 3980734030, ack 1887031232, win 28960, options [mss 1460,sackOK,TS val 288190452 ecr 2209812901,nop,wscale 7], length 0
14:49:01.006907 IP 10.0.1.18.32934 > 10.0.1.51.81: Flags [.], ack 1, win 229, options [nop,nop,TS val 2209812910 ecr 288190452], length 0sysctl stuffs should be fine:
Code:net.netfilter.nf_conntrack_tcp_loose = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.conf.default.rp_filter = 1Does someone has some ideas on what to check and why it is not working ?

Distro is a slackware 14.2+ ( current ) and kernel is ( almost ) new one
Code:root@firewall:~# uname -a
Linux firewall.frumar.it 4.19.81-v7+ #1 SMP Sat Nov 2 00:21:44 CET 2019 armv7l BCM2835 GNU/Linuxipt_SYNPROXY is loaded:

Code:root@firewall:~# lsmod | grep SYN
ipt_SYNPROXY 16384 0
nf_synproxy_core 16384 1 ipt_SYNPROXY
x_tables 32768 16 xt_state,xt_LOG,xt_multiport,xt_owner,xt_nat,ipt_SYNPROXY,iptable_mangle,ip_tables,iptable_filter,xt_string,xt_tcpudp,iptable_raw,xt_recent,xt_connlimit,xt_CT,xt_conntrack
nf_conntrack 135168 12 xt_state,nf_conncount,xt_nat,ipt_SYNPROXY,nf_conntrack_ftp,nf_nat_ftp,xt_connlimit,xt_CT,xt_conntrack,nf_synproxy_core,nf_nat_ipv4,nf_natI'm really banging my head to wall :(

Thx, and apologize for my bad english.

Pierluigilatest?d=yIl2AUoC8zA latest?i=Cn2ksp4_wZo:wG78Q5y4piA:F7zBnMy latest?i=Cn2ksp4_wZo:wG78Q5y4piA:V_sGLiP latest?d=qj6IDK7rITs latest?i=Cn2ksp4_wZo:wG78Q5y4piA:gIN9vFwCn2ksp4_wZo
External Content
Source RSS or Atom Feed
Feed Location https://feeds.feedburner.com/linuxquestions/latest
Feed Title LinuxQuestions.org
Feed Link https://www.linuxquestions.org/questions/
Reply 0 comments