Hi Noel, Actually based on my firewall config, I think I have to DROP it instead of ACCEPT if it's over the 5/sec limit? Don't you agree?
iptables -I FORWARD 2 -m conntrack --ctstate NEW -m hashlimit --hashlimit-name NETSCAN --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-above 5/s -j DROP So I replace *hashlimit-upto* with *hashlimit-above* following with a DROP. This is my current firewall settings based on your previous suggestion. If Iptables is clever enough to DROP the connection if hashlimit-upto is exceeded, it should work as well. # iptables-save *filter :INPUT DROP [6374:460035] :FORWARD DROP [7119:2071794] :OUTPUT ACCEPT [19665335:23255290771] -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m tcp --dport 2022 -j ACCEPT -A INPUT -p udp -m udp --dport 500 -j ACCEPT -A INPUT -p udp -m udp --dport 4500 -j ACCEPT -A FORWARD -s 10.10.0.0/17 -d 10.10.0.0/17 -j DROP -A FORWARD -m conntrack --ctstate NEW -m hashlimit --hashlimit-upto 5/sec --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name NETSCAN -j ACCEPT -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT -A FORWARD -m policy --dir out --pol ipsec -j ACCEPT COMMIT # Completed on Mon Oct 14 08:30:14 2019 # Generated by iptables-save v1.6.1 on Mon Oct 14 08:30:14 2019 *nat :PREROUTING ACCEPT [222978690:20761159044] :INPUT ACCEPT [1143238:398065963] :OUTPUT ACCEPT [245876:24207759] :POSTROUTING ACCEPT [245876:24207759] -A POSTROUTING -s 10.10.0.0/17 -o enp2s0 -m policy --dir out --pol ipsec -j ACCEPT -A POSTROUTING -s 10.10.0.0/17 -o enp2s0 -j MASQUERADE COMMIT # Completed on Mon Oct 14 08:30:14 2019 # Generated by iptables-save v1.6.1 on Mon Oct 14 08:30:14 2019 *mangle :PREROUTING ACCEPT [76920955633:50815277695359] :INPUT ACCEPT [27612054762:8305407205459] :FORWARD ACCEPT [49298861266:42508240159831] :OUTPUT ACCEPT [34323442858:39692165780388] :POSTROUTING ACCEPT [83603096494:82195502934979] -A FORWARD -s 10.10.0.0/17 -o enp2s0 -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 COMMIT On Mon, 14 Oct 2019 at 11:14, Houman <[email protected]> wrote: > Hello Noel, > > Thanks for your solution, I just tried it: > > iptables -I FORWARD 2 -m conntrack --ctstate NEW -m hashlimit > --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-upto 5/s -j ACCEPT > > But I got this error message: > > iptables v1.6.1: hashlimit: option "--hashlimit-name" must be specified > > I googled and added the missing name like this: > > iptables -I FORWARD 2 -m conntrack --ctstate NEW -m hashlimit > --hashlimit-name NETSCAN --hashlimit-mode srcip --hashlimit-srcmask 32 > --hashlimit-upto 5/s -j ACCEPT > > Do you agree with this approach to prevent VPN users from running Netscans? > > Many Thanks, > Houman > > > On Wed, 31 Jul 2019 at 14:51, Noel Kuntze <[email protected]> > wrote: > >> Hello Houman, >> >> A "netscan" attack isn't actually anything worthy of an abuse email. >> It's not part of a benign usage pattern of a VPN service, but it itself >> isn't illegal or anything. >> You can only slow down such scans by rate limiting the number of new >> connections using the hashlimit match module, for example. >> >> E.g. -A FORWARD -m conntrack --ctstate NEW -m hashlimit --hashlimit-mode >> srcip --hashlimit-srcmask 32 --hashlimit-upto 5/s -j ACCEPT >> >> Kind regards >> >> Noel >> >> Am 30.07.19 um 16:39 schrieb Houman: >> > Sorry I mistyped. I meant Netscan. >> > >> > The abuse message was saying: *NetscanOutLevel: Netscan detected from >> xx.xx.xx.xx* >> > >> > This is possible though, that VPN users run a netscan and scan the >> ports. Am I correct? >> > >> > Thanks, >> > >> > On Tue, 30 Jul 2019 at 15:30, Thor Simon <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > I don't think netstat does what you think it does. It is a _local_ >> tool. Perhaps the "abuse notification" you received is a phishing attack? >> > >> > Hae a look at the manual page: >> > >> > http://manpages.ubuntu.com/manpages/trusty/man8/netstat.8.html >> > >> > ________________________________ >> > From: Houman <[email protected] <mailto:[email protected]>> >> > Sent: Jul 30, 2019 10:18 AM >> > To: [email protected] <mailto:[email protected]> >> > Subject: [strongSwan] How to block Netstat attacks from VPN users? >> > >> > Hello, >> > >> > I had an interesting abuse notification that someone has run a >> netstat through our VPN. >> > >> > > time protocol src_ip src_port dest_ip >> dest_port >> > > >> --------------------------------------------------------------------------- >> > > Tue Jul 30 13:38:01 2019 UDP 136.243.xxx.xxx 21346 => >> 172.20.10.17 21346 >> > > Tue Jul 30 13:38:01 2019 UDP 136.243.xxx.xxx 21346 => >> 172.20.10.19 21346 >> > >> > I was wondering if there is a good way to block all VPN users from >> running hacker tools such as netstat (port scanning) altogether. Is there >> a reliable way to do that with iptables? >> > >> > I came across this snippet that should block port scans, but I'm >> not sure if that would block a VPN user after all since the VPN traffic is >> masqueraded. >> > >> > iptables -A port-scan -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m >> limit --limit 1/s -j RETURN >> > iptables -A port-scan -j DROP --log-level 6 >> > iptables -A specific-rule-set -p tcp --syn -j syn-flood >> > iptables -A specific-rule-set -p tcp --tcp-flags SYN,ACK,FIN,RST >> RST -j port-scan >> > >> > Any suggestions, please? >> > Many Thanks, >> > Houman >> > >> > >> > >> >> -- >> Noel Kuntze >> IT security consultant >> >> GPG Key ID: 0x0739AD6C >> Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C >> >> >>
