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

2019-10-14 Thread 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?

2019-10-14 Thread 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

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

2019-10-14 Thread 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?

2019-10-14 Thread 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?

2019-10-14 Thread 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?

2019-10-14 Thread 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?

2019-10-14 Thread 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?

2019-10-14 Thread 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?

2019-10-14 Thread 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
>
>
>

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

2019-07-31 Thread Noel Kuntze 
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.
>
> > 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




signature.asc
Description: OpenPGP digital signature

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

2019-07-30 Thread 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 
> 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
>
>
>
>

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

2019-07-30 Thread Thor Simon 
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 
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