[strongSwan] How to block Netstat attacks from VPN users?
Houman
houmie at gmail.com
Mon Oct 14 14:30:33 CEST 2019
Hello Noel,
It's a bare-metal server that I'm renting (it's not a virtual server) so I
assume that it should be in its own private subnet. I have tried to follow
up with them, but their support doesn't communicate very well in English.
All I could gather is the following:
1) Based on the ROOT SERVER SERVICE AGREEMENT, the scanning of foreign
networks or foreign IP addresses is not permitted.
2) These RFC1918 networks are not reachable via my external interface (Then
why is it a problem? I don't understand them)
I did some further research. It seems it is better to do the REJECT rule
only on the interface that is connected to the Internet. Otherwise, I could
be blocking LAN or vpn peer-to-peer communications.
export INET_IFACE=$(ip route get 8.8.8.8 | awk -- '{printf $5}')
iptables -A FORWARD -o $INET_IFACE -d 10.0.0.0/8 -j REJECT
iptables -A FORWARD -o $INET_IFACE -d 172.16.0.0/12 -j REJECT
iptables -A FORWARD -o $INET_IFACE -d 192.168.0.0/16 -j REJECT
Do you agree with this? Or is it rather unnecessary for a StrongSwan server?
Thanks,
Houman
On Mon, 14 Oct 2019 at 14:00, Noel Kuntze <noel.kuntze at thermi.consulting>
wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191014/3581c40c/attachment-0001.html>
More information about the Users
mailing list