From: Fatih USTA <fatihusta86@gmail.com>
To: Pigi <pigi@frumar.it>, netfilter@vger.kernel.org
Subject: Re: Trouble getting SYNPROXY to work.
Date: Tue, 12 Nov 2019 11:37:29 +0300 [thread overview]
Message-ID: <3abdbb03-e10c-938f-bfb1-5e10764e1a3f@gmail.com> (raw)
In-Reply-To: <3018728.1mgFJ8EcOk@topolinux>
Hi Pierluigi,
If you don't have ip address on br0 interface.
You have a routing problem.
Solution:
gw=192.0.2.1
gw_mac=00:00:00:00:00:01
server_or_other_internal_firewall=192.0.2.2
server_or_other_internal_firewall_mac=00:00:00:00:00:02
ip neigh add $gw lladdr $gw_mac dev br0
ip neigh add $server_or_other_internal_firewall lladdr
$server_or_other_internal_firewall_mac dev br0
ip route add $gw dev br0
ip route add $server_or_other_internal_firewall dev br0
ip route add default via $gw
If you have a IP address on br0 interface then you should check
net.ipv4.ip_forward sysctl parameters. (value should be 1)
My other advice to you.
1- Use external Ethernet for SYN Proxy.
/usr/sbin/iptables -A INPUT -m physdev --physdev-in $external_iface_eth0
-p tcp -m tcp -m conntrack --dport 81 --ctstate INVALID,UNTRACKED -j
SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1323
2- If you set 0 this parameters then you take the better performance.
net.ipv4.tcp_timestamps = 1
3- Last advice.
If you are using HTTPS connection then don't set wscale. And you may use
mss 1460.
Regards.
Fatih USTA
On 11.11.2019 23:46, Pigi wrote:
> Hi all,
> long post, so please apologize.
>
> 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.
>
>
> |
> | 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:
>
> /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 DROP
>
> If I enable them, I can see the SYN packet ( from the br0 interface ) that enter the interface, but no SYN+ACK reply exiting:
>
> 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 out
>
>
> The SYNPROXY get triggered:
>
> 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 INVALID
>
> but also tcpdump confirm no SYN+ACK exit to the client:
>
>
> 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 0
>
>
> Values for the SYNPROXY are derived from tcpdump:
>
> 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
> ^C
>
> The 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:
>
>
> 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 0
>
>
> sysctl stuffs should be fine:
>
> net.netfilter.nf_conntrack_tcp_loose = 0
> net.ipv4.tcp_timestamps = 1
> net.ipv4.conf.default.rp_filter = 1
>
> Kernel is ( almost ) new one
>
> 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/Linux
>
>
> ipt_SYNPROXY is loaded:
>
> 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_nat
>
>
> Also TRACE shows that the SYNPROXY get triggered:
>
> root@firewall# iptables -t raw -L -v -n
> Chain PREROUTING (policy ACCEPT 915 packets, 358K bytes)
> num pkts bytes target prot opt in out source destination
> 1 2 120 TRACE tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:82
> 2 2 120 CT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:82 flags:0x17/0x02 CT notrack
>
> Chain OUTPUT (policy ACCEPT 407 packets, 259K bytes)
> num pkts bytes target prot opt in out source destination
>
>
> root@firewall# iptables -L INPUT -v -n
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> num pkts bytes target prot opt in out source destination
> 1 78 81472 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 2 358 103K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> 3 2 120 SYNPROXY tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:82 state INVALID,UNTRACKED SYNPROXY sack-perm timestamp wscale 7 mss 1460
> 4 11 452 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
> 5 0 0 ACCEPT tcp -- * * 10.0.1.18 10.0.1.51 tcp dpt:82 /* Ntp da dmz
> ...
> ...
>
> And from the logs:
>
> raw:PREROUTING:rule:2 IN=br0 OUT= SRC=10.0.1.18 DST=10.0.1.51 ID=36524 DF PROTO=TCP SPT=53404 DPT=82 SEQ=3633093572 ACK=0 WINDOW=29200 RES=0x00
> raw:PREROUTING:policy:3 IN=br0 OUT= SRC=10.0.1.18 DST=10.0.1.51 ID=36524 DF PROTO=TCP SPT=53404 DPT=82 SEQ=3633093572 ACK=0 WINDOW=29200 RES=0x00
> mangle:PREROUTING:policy:1 IN=br0 OUT= SRC=10.0.1.18 DST=10.0.1.51 ID=36524 DF PROTO=TCP SPT=53404 DPT=82 SEQ=3633093572 ACK=0 WINDOW=29200 RES=0x00
> mangle:INPUT:policy:1 IN=br0 OUT= SRC=10.0.1.18 DST=10.0.1.51 ID=36524 DF PROTO=TCP SPT=53404 DPT=82 SEQ=3633093572 ACK=0 WINDOW=29200 RES=0x00
> filter:INPUT:rule:3 IN=br0 OUT= SRC=10.0.1.18 DST=10.0.1.51 ID=36524 DF PROTO=TCP SPT=53404 DPT=82 SEQ=3633093572 ACK=0 WINDOW=29200 RES=0x00
>
> As you can see, the packet get caught in rule 2 of raw table, PREEROUTING chain:
> 2 2 120 CT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:82 flags:0x17/0x02 CT
>
> then from rule 3 of the filter table, INPUT chain
> 3 2 120 SYNPROXY tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:82 state INVALID,UNTRACKED SYNPROXY sack-perm timestamp wscale 7 mss 1460
>
> but ( as already told ) no syn+ack goes out.
>
>
> Any idea on what to check ?
>
>
> Thx, and apologize for my bad english.
>
>
> Pierluigi
next prev parent reply other threads:[~2019-11-12 8:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 20:46 Trouble getting SYNPROXY to work Pigi
2019-11-12 8:37 ` Fatih USTA [this message]
2019-11-12 18:31 ` Pigi
2019-11-12 19:23 ` Neal P. Murphy
2019-11-12 20:42 ` Pierluigi Frullani Sinergy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3abdbb03-e10c-938f-bfb1-5e10764e1a3f@gmail.com \
--to=fatihusta86@gmail.com \
--cc=netfilter@vger.kernel.org \
--cc=pigi@frumar.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.