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

[Noel Kuntze]

Hello Houman,

> Depends on what exactly you're doing on your server. It's not possible to 
> give you a generalized answer.

That's what I think.

Am 14.10.19 um 20:49 schrieb Houman:
> 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  
> wrote:
>
> Hello Houman,
>
> Depends on what exactly you're doing on your 

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

[Houman]

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 
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 

[strongSwan] Configuring site-to-site IPsec VPN to a Fortigate using certificates

[JR]

Hi

I am trying to configure a VPN tunnel between a Linux VM in Azure with a 
customer's Fortigate firewall. The Azure VM is behind an Azure load balancer, 
so has a different public IP from the local VM IP. The good news is that the 
configuration is working with PSK. However, when trying to use 
certificate-based authentication, the connection is not establishing. I can see 
the connection request coming in from the customer, but it fails to complete.

I am not sure what the "id" values should be for a Fortigate when using 
certificates. I have tried: IP address, FQDN, and Distinguished Name, but none 
appear to be working. We have tried using a third party "proper" certificate, 
and also a self-signed certificate (the below is based on the self-signed 
certificate. Both ends have the same self-signed/created CA root certificate 
installed).

Please see the logs and command outputs below. customer name and IPs have been 
sanitized.

Version: 5.6.2-1ubuntu2.4 (latest available on Ubuntu 18.04.2 LTS

Any help would be appreciated! We have spent three days trying to debug this 
without success.

Thanks

Julian


The output of swanctl -l:

(unnamed): #1, CONNECTING, IKEv2, d97222f0d8c960ed_i 4f771e61521bd11a_r*
  local  '%any' @ 172.26.0.85[500]
  remote '%any' @ 123.123.123.123[500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  passive: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE 
IKE_AUTH_LIFETIME IKE_MOBIKE

The output of swanctl -L:
customername: IKEv2, no reauthentication, rekeying every 14400s
  local:  172.26.0.85
  remote: 123.123.123.123
  local public key authentication:
    id: vpnrsa-ss.production.onecloud.companyname.cloud
    certs: C=GB, ST=County, O=CompanyName, OU=Technical Services, 
CN=vpnrsa-ss.production.onecloud.companyname.cloud
  remote public key authentication:
    id: vpn1.customername.gov.uk
  datacentre-customername: TUNNEL, rekeying every 3600s or 4608000 bytes
    local:  172.26.0.85/32 172.16.16.64/27 172.16.44.32/28 172.16.60.0/22 
172.16.30.196/32
    remote: 10.10.8.1/32 10.10.8.2/32 10.10.8.22/32 10.10.8.23/32 10.10.8.24/32 
10.10.8.25/32 10.10.8.45/32


The output of iptables -L:

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

The output of ip route show table all:

10.10.8.1 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.2 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.22 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.23 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.24 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.25 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
10.10.8.45 via 172.26.0.81 dev eth0 table 220 proto static src 172.26.0.85
default via 172.26.0.81 dev eth0 proto dhcp src 172.26.0.85 metric 100
168.63.129.16 via 172.26.0.81 dev eth0 proto dhcp src 172.26.0.85 metric 100
169.254.169.254 via 172.26.0.81 dev eth0 proto dhcp src 172.26.0.85 metric 100
172.26.0.80/28 dev eth0 proto kernel scope link src 172.26.0.85
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
127.0.0.1
broadcast 172.26.0.80 dev eth0 table local proto kernel scope link src 
172.26.0.85
local 172.26.0.85 dev eth0 table local proto kernel scope host src 172.26.0.85
broadcast 172.26.0.95 dev eth0 table local proto kernel scope link src 
172.26.0.85
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::20d:3aff:fe7e:9150 dev eth0 table local proto kernel metric 0 pref 
medium
ff00::/8 dev eth0 table local metric 256 pref medium

The output of  ip addr:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
    link/ether 00:0d:3a:7e:91:50 brd ff:ff:ff:ff:ff:ff
    inet 172.26.0.85/28 brd 172.26.0.95 scope global eth0
   valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe7e:9150/64 scope link
   valid_lft forever preferred_lft forever


The only configuration file change I have made is to create a customername.conf 
file in /etc/swanctl/conf.d with the following:

# customername
connections {

   customername {
  local_addrs  = 172.26.0.85
  

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

[Noel Kuntze]

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  -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  
> 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  
> > > 172.16.0.0/12  
> > > 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  
>  -j REJECT
> > iptables -A FORWARD -d 172.16.0.0/12  
>  -j REJECT
> > iptables -A FORWARD -d 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 
>  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  
>   -d 10.10.0.0/17 
>    -j DROP
> >     > -A FORWARD -m conntrack --ctstate NEW -m hashlimit 
> --hashlimit-upto 

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

[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 -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 
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 
> > > 172.16.0.0/12 
> > > 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  -j REJECT
> > iptables -A FORWARD -d 172.16.0.0/12  -j REJECT
> > iptables -A FORWARD -d 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 
> 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> -d 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> -o enp2s0 -m policy --dir out --pol ipsec -j ACCEPT
> > > -A POSTROUTING -s 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
> 

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

[Noel Kuntze]

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 
> > 172.16.0.0/12 
> > 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  -j REJECT
> iptables -A FORWARD -d 172.16.0.0/12  -j REJECT
> iptables -A FORWARD -d 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  
> 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   
> -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    >> 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 

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

[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
> 172.16.0.0/12
> 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 -j REJECT
iptables -A FORWARD -d 172.16.0.0/12 -j REJECT
iptables -A FORWARD -d 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 
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  -d 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  -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  hou...@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
>  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:
> > 

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

[Noel Kuntze]

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  -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  > 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  
> 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    >> 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 

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

[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 -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  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 
> 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 > > 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 mailto:hou...@gmail.com>>
>> > Sent: Jul 30, 2019 10:18 AM
>> > To: users@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.
>> >
>> > > timeprotocol 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 

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

[Houman]

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 
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  > 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 mailto:hou...@gmail.com>>
> > Sent: Jul 30, 2019 10:18 AM
> > To: users@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.
> >
> > > timeprotocol 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
>
>
>