[strongSwan] How to block Netstat attacks from VPN users?

Noel Kuntze noel.kuntze at thermi.consulting
Mon Oct 14 12:30:17 CEST 2019


Hello Houman,

You can do that. I wonder though why that is a problem. Are they providing a private subnet on the link of your server?

Kind regards

Noel

Am 14.10.19 um 12:03 schrieb Houman:
> Hi Noel,
>
> That makes sense, thank you.
>
> I received a followup email from our server provider (about a new netscan attempt from one of our users today).
>
> """
> We would recommend that you set up a local firewall and block outgoing traffic to the following prefixes
> https://tools.ietf.org/html/rfc1918
> > 10.0.0.0/8 <http://10.0.0.0/8>
> > 172.16.0.0/12 <http://172.16.0.0/12>
> > 192.168.0.0/16 <http://192.168.0.0/16>
> Please block this range of RFC1918 on your server. 
> We would like to avoid further network abuse from your end.
> """
>
> Is this as simple as
>
> iptables -A FORWARD -d 10.0.0.0/8 <http://10.0.0.0/8> -j REJECT
> iptables -A FORWARD -d 172.16.0.0/12 <http://172.16.0.0/12> -j REJECT
> iptables -A FORWARD -d 192.168.0.0/16 <http://192.168.0.0/16> -j REJECT
>
> Or am I oversimplifying this?
>
> Many Thanks,
> Houman
>
>
> On Mon, 14 Oct 2019 at 13:02, Noel Kuntze <noel.kuntze at thermi.consulting> wrote:
>
>     Hello Houman,
>
>     Depends on if you have a whitelist or blacklist rule set.
>
>     With the ruleset you have provided in this email, you need to accept the stuff you want. So up to 5 new connections per second.
>
>     Kind regards
>
>     Noel
>
>     Am 14.10.19 um 10:40 schrieb Houman:
>     > 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 <http://10.10.0.0/17> <http://10.10.0.0/17> -d 10.10.0.0/17 <http://10.10.0.0/17> <http://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 <http://10.10.0.0/17> <http://10.10.0.0/17> -o enp2s0 -m policy --dir out --pol ipsec -j ACCEPT
>     > -A POSTROUTING -s 10.10.0.0/17 <http://10.10.0.0/17> <http://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 <http://10.10.0.0/17> <http://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 <houmie at gmail.com <mailto:houmie at gmail.com> <mailto:houmie at gmail.com <mailto:houmie at gmail.com>>> 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 <noel.kuntze at thermi.consulting> 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 <Thor.Simon at twosigma.com <mailto:Thor.Simon at twosigma.com> <mailto:Thor.Simon at twosigma.com <mailto:Thor.Simon at twosigma.com>> <mailto:Thor.Simon at twosigma.com <mailto:Thor.Simon at twosigma.com> <mailto:Thor.Simon at twosigma.com <mailto:Thor.Simon at twosigma.com>>>> 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 <houmie at gmail.com <mailto:houmie at gmail.com> <mailto:houmie at gmail.com <mailto:houmie at gmail.com>> <mailto:houmie at gmail.com <mailto:houmie at gmail.com> <mailto:houmie at gmail.com <mailto:houmie at gmail.com>>>>
>     >         >     Sent: Jul 30, 2019 10:18 AM
>     >         >     To: users at lists.strongswan.org <mailto:users at lists.strongswan.org> <mailto:users at lists.strongswan.org <mailto:users at lists.strongswan.org>> <mailto:users at lists.strongswan.org <mailto:users at lists.strongswan.org> <mailto:users at lists.strongswan.org <mailto:users at lists.strongswan.org>>>
>     >         >     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
>     >
>     >
>
>     -- 
>     Noel Kuntze
>     IT security consultant
>
>     GPG Key ID: 0x0739AD6C
>     Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C
>
>

-- 
Noel Kuntze
IT security consultant

GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191014/747de23a/attachment-0001.sig>


More information about the Users mailing list