[strongSwan] How to block Netstat attacks from VPN users?
Houman
houmie at gmail.com
Mon Oct 14 20:49:49 CEST 2019
Hello Noel,
I just tried the suggested solution below and sadly it blocks the entire
VPN.
iptables -I FORWARD 2 -d 192.168.0.0/16 -j REJECT
iptables -I FORWARD 2 -d 172.16.0.0/12 -j REJECT
iptables -I FORWARD 2 -d 10.0.0.0/8 -j REJECT
Unless I have inserted the rules at the wrong spot, it doesn't look good.
See below, please:
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:33:31 2019
*mangle
:PREROUTING ACCEPT [54716:20906174]
:INPUT ACCEPT [26852:4628015]
:FORWARD ACCEPT [27829:16271441]
:OUTPUT ACCEPT [25477:18649644]
:POSTROUTING ACCEPT [52098:34734180]
-A FORWARD -s 10.10.10.0/24 -o eth0 -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
# Completed on Mon Oct 14 18:33:31 2019
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:33:31 2019
*nat
:PREROUTING ACCEPT [1575:110530]
:INPUT ACCEPT [28:8296]
:OUTPUT ACCEPT [429:29655]
:POSTROUTING ACCEPT [429:29655]
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --dir out --pol ipsec -j
ACCEPT
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Oct 14 18:33:31 2019
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:33:31 2019
*filter
:INPUT DROP [1:40]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [102:15526]
-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.10.0/24 -d 10.10.10.0/24 -j DROP
-A FORWARD -d 10.0.0.0/8 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 172.16.0.0/12 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 192.168.0.0/16 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -m policy --dir out --pol ipsec -j ACCEPT
COMMIT
If this doesn't work I have to fallback to your initial solution:
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
With the following outcome:
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:40:26 2019
*filter
:INPUT DROP [192413:18329342]
:FORWARD DROP [340475:90672719]
:OUTPUT ACCEPT [425183776:485173348374]
-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 18:40:26 2019
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:40:26 2019
*nat
:PREROUTING ACCEPT [133256521:12349660945]
:INPUT ACCEPT [805996:248685578]
:OUTPUT ACCEPT [151185:15397949]
:POSTROUTING ACCEPT [151185:15397949]
-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 18:40:26 2019
# Generated by iptables-save v1.6.1 on Mon Oct 14 18:40:26 2019
*mangle
:PREROUTING ACCEPT [47285409804:29854894928171]
:INPUT ACCEPT [16114043471:4661974048771]
:FORWARD ACCEPT [31166444886:25192112917092]
:OUTPUT ACCEPT [20092152323:23622919704514]
:POSTROUTING ACCEPT [51247881050:48812187889401]
-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
# Completed on Mon Oct 14 18:40:26 2019
The latter doesn't stop the VPN, but I won't know it really prevents
someone from running netscan until someone tries a new attempt again. :)
What do you think?
Many Thanks,
Houman
On Mon, 14 Oct 2019 at 17:05, Noel Kuntze <noel.kuntze at thermi.consulting>
wrote:
> Hello Houman,
>
> Depends on what exactly you're doing on your server. It's not possible to
> give you a generalized answer.
> You shouldn't script with iptables though. Use iptables-save and -restore
> (save prints out a serialised form of your loaded iptables rules, restore
> loads data in said form).
>
> Kind regards
>
> Noel
>
> Am 14.10.19 um 14:30 schrieb Houman:
> > 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 <http://10.0.0.0/8>
> -j REJECT iptables -A FORWARD -o $INET_IFACE -d 172.16.0.0/12 <
> http://172.16.0.0/12> -j REJECT iptables -A FORWARD -o $INET_IFACE -d
> 192.168.0.0/16 <http://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> <http://10.0.0.0/8>
> > > > 172.16.0.0/12 <http://172.16.0.0/12> <http://172.16.0.0/12>
> > > > 192.168.0.0/16 <http://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> <
> http://10.0.0.0/8> -j REJECT
> > > iptables -A FORWARD -d 172.16.0.0/12 <http://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> <
> 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> <http://10.10.0.0/17> -d 10.10.0.0/17 <
> http://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> <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> <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> <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>> <mailto: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>>> <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 <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>>> <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 <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>>> <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 <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
> >
> >
>
> --
> 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/bcd7df5a/attachment-0001.html>
More information about the Users
mailing list