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 <http://192.168.0.0/16> -j REJECT > iptables -I FORWARD 2 -d 172.16.0.0/12 <http://172.16.0.0/12> -j REJECT > iptables -I FORWARD 2 -d 10.0.0.0/8 <http://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 <http://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 <http://10.10.10.0/24> -o eth0 -m policy > --dir out --pol ipsec -j ACCEPT > -A POSTROUTING -s 10.10.10.0/24 <http://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 <http://10.10.10.0/24> -d 10.10.10.0/24 > <http://10.10.10.0/24> -j DROP > -A FORWARD -d 10.0.0.0/8 <http://10.0.0.0/8> -j REJECT --reject-with > icmp-port-unreachable > -A FORWARD -d 172.16.0.0/12 <http://172.16.0.0/12> -j REJECT --reject-with > icmp-port-unreachable > -A FORWARD -d 192.168.0.0/16 <http://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 <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 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 <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 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 <http://10.10.0.0/17> -o enp2s0 -p tcp -m policy > --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 > -j TCPMSS --set-mss 1360 > COMMIT > # 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 <[email protected]> > wrote: > > Hello Houman, > > Depends on what exactly you're doing on your server. It's not possible to > give you a generalized answer. > You shouldn't script with iptables though. Use iptables-save and -restore > (save prints out a serialised form of your loaded iptables rules, restore > loads data in said form). > > Kind regards > > Noel > > Am 14.10.19 um 14:30 schrieb Houman: > > Hello Noel, > > > > It's a bare-metal server that I'm renting (it's not a virtual server) > so I assume that it should be in its own private subnet. I have tried to > follow up with them, but their support doesn't communicate very well in > English. All I could gather is the following: > > > > 1) Based on the ROOT SERVER SERVICE AGREEMENT, the scanning of foreign > networks or foreign IP addresses is not permitted. > > 2) These RFC1918 networks are not reachable via my external interface > (Then why is it a problem? I don't understand them) > > > > I did some further research. It seems it is better to do the REJECT > rule only on the interface that is connected to the Internet. Otherwise, I > could be blocking LAN or vpn peer-to-peer communications. > > > > |export INET_IFACE=$(ip route get 8.8.8.8 | awk -- '{printf $5}')| > > |iptables -A FORWARD -o $INET_IFACE -d 10.0.0.0/8 <http://10.0.0.0/8> > <http://10.0.0.0/8> -j REJECT iptables -A FORWARD -o $INET_IFACE -d > 172.16.0.0/12 <http://172.16.0.0/12> <http://172.16.0.0/12> -j REJECT > iptables -A FORWARD -o $INET_IFACE -d 192.168.0.0/16 <http://192.168.0.0/16> > <http://192.168.0.0/16> -j REJECT| > > Do you agree with this? Or is it rather unnecessary for a StrongSwan > server? > > > > Thanks, > > Houman > > > > > > > > > > On Mon, 14 Oct 2019 at 14:00, Noel Kuntze > <[email protected]> wrote: > > > > Hello Houman, > > > > You can do that. I wonder though why that is a problem. Are they > providing a private subnet on the link of your server? > > > > Kind regards > > > > Noel > > > > Am 14.10.19 um 12:03 schrieb Houman: > > > Hi Noel, > > > > > > That makes sense, thank you. > > > > > > I received a followup email from our server provider (about a new > netscan attempt from one of our users today). > > > > > > """ > > > We would recommend that you set up a local firewall and block > outgoing traffic to the following prefixes > > > https://tools.ietf.org/html/rfc1918 > > > > 10.0.0.0/8 <http://10.0.0.0/8> <http://10.0.0.0/8> > <http://10.0.0.0/8> > > > > 172.16.0.0/12 <http://172.16.0.0/12> <http://172.16.0.0/12> > <http://172.16.0.0/12> > > > > 192.168.0.0/16 <http://192.168.0.0/16> <http://192.168.0.0/16> > <http://192.168.0.0/16> > > > Please block this range of RFC1918 on your server. > > > We would like to avoid further network abuse from your end. > > > """ > > > > > > Is this as simple as > > > > > > iptables -A FORWARD -d 10.0.0.0/8 <http://10.0.0.0/8> > <http://10.0.0.0/8> <http://10.0.0.0/8> -j REJECT > > > iptables -A FORWARD -d 172.16.0.0/12 <http://172.16.0.0/12> > <http://172.16.0.0/12> <http://172.16.0.0/12> -j REJECT > > > iptables -A FORWARD -d 192.168.0.0/16 <http://192.168.0.0/16> > <http://192.168.0.0/16> <http://192.168.0.0/16> -j REJECT > > > > > > Or am I oversimplifying this? > > > > > > Many Thanks, > > > Houman > > > > > > > > > On Mon, 14 Oct 2019 at 13:02, Noel Kuntze > <[email protected]> wrote: > > > > > > Hello Houman, > > > > > > Depends on if you have a whitelist or blacklist rule set. > > > > > > With the ruleset you have provided in this email, you need to > accept the stuff you want. So up to 5 new connections per second. > > > > > > Kind regards > > > > > > Noel > > > > > > Am 14.10.19 um 10:40 schrieb Houman: > > > > Hi Noel, > > > > > > > > Actually based on my firewall config, I think I have to > DROP it instead of ACCEPT if it's over the 5/sec limit? Don't you agree? > > > > > > > > iptables -I FORWARD 2 -m conntrack --ctstate NEW -m > hashlimit --hashlimit-name NETSCAN --hashlimit-mode srcip --hashlimit-srcmask > 32 --hashlimit-above 5/s -j DROP > > > > > > > > So I replace *hashlimit-upto* with *hashlimit-above* > following with a DROP. > > > > > > > > This is my current firewall settings based on your previous > suggestion. If Iptables is clever enough to DROP the connection if > hashlimit-upto is exceeded, it should work as well. > > > > > > > > # iptables-save > > > > *filter > > > > :INPUT DROP [6374:460035] > > > > :FORWARD DROP [7119:2071794] > > > > :OUTPUT ACCEPT [19665335:23255290771] > > > > -A INPUT -i lo -j ACCEPT > > > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j > ACCEPT > > > > -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT > > > > -A INPUT -p tcp -m tcp --dport 2022 -j ACCEPT > > > > -A INPUT -p udp -m udp --dport 500 -j ACCEPT > > > > -A INPUT -p udp -m udp --dport 4500 -j ACCEPT > > > > -A FORWARD -s 10.10.0.0/17 <http://10.10.0.0/17> > <http://10.10.0.0/17> <http://10.10.0.0/17> <http://10.10.0.0/17> -d > 10.10.0.0/17 <http://10.10.0.0/17> <http://10.10.0.0/17> > <http://10.10.0.0/17> <http://10.10.0.0/17> -j DROP > > > > -A FORWARD -m conntrack --ctstate NEW -m hashlimit > --hashlimit-upto 5/sec --hashlimit-burst 5 --hashlimit-mode srcip > --hashlimit-name NETSCAN -j ACCEPT > > > > -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT > > > > -A FORWARD -m policy --dir out --pol ipsec -j ACCEPT > > > > COMMIT > > > > # Completed on Mon Oct 14 08:30:14 2019 > > > > # Generated by iptables-save v1.6.1 on Mon Oct 14 08:30:14 > 2019 > > > > *nat > > > > :PREROUTING ACCEPT [222978690:20761159044] > > > > :INPUT ACCEPT [1143238:398065963] > > > > :OUTPUT ACCEPT [245876:24207759] > > > > :POSTROUTING ACCEPT [245876:24207759] > > > > -A POSTROUTING -s 10.10.0.0/17 <http://10.10.0.0/17> > <http://10.10.0.0/17> <http://10.10.0.0/17> <http://10.10.0.0/17> -o enp2s0 > -m policy --dir out --pol ipsec -j ACCEPT > > > > -A POSTROUTING -s 10.10.0.0/17 <http://10.10.0.0/17> > <http://10.10.0.0/17> <http://10.10.0.0/17> <http://10.10.0.0/17> -o enp2s0 > -j MASQUERADE > > > > COMMIT > > > > # Completed on Mon Oct 14 08:30:14 2019 > > > > # Generated by iptables-save v1.6.1 on Mon Oct 14 08:30:14 > 2019 > > > > *mangle > > > > :PREROUTING ACCEPT [76920955633:50815277695359] > > > > :INPUT ACCEPT [27612054762:8305407205459] > > > > :FORWARD ACCEPT [49298861266:42508240159831] > > > > :OUTPUT ACCEPT [34323442858:39692165780388] > > > > :POSTROUTING ACCEPT [83603096494:82195502934979] > > > > -A FORWARD -s 10.10.0.0/17 <http://10.10.0.0/17> > <http://10.10.0.0/17> <http://10.10.0.0/17> <http://10.10.0.0/17> -o enp2s0 > -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m > tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 > > > > COMMIT > > > > > > > > On Mon, 14 Oct 2019 at 11:14, Houman <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>>> 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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>>>> 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 <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>>>> > > > > > Sent: Jul 30, 2019 10:18 AM > > > > > To: [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>>> > > > > > Subject: [strongSwan] How to block Netstat > attacks from VPN users? > > > > > > > > > > Hello, > > > > > > > > > > I had an interesting abuse notification that > someone has run a netstat through our VPN. > > > > > > > > > > > time protocol src_ip > src_port dest_ip dest_port > > > > > > > --------------------------------------------------------------------------- > > > > > > Tue Jul 30 13:38:01 2019 UDP > 136.243.xxx.xxx 21346 => 172.20.10.17 21346 > > > > > > Tue Jul 30 13:38:01 2019 UDP > 136.243.xxx.xxx 21346 => 172.20.10.19 21346 > > > > > > > > > > I was wondering if there is a good way to > block all VPN users from running hacker tools such as netstat (port scanning) > altogether. Is there a reliable way to do that with iptables? > > > > > > > > > > I came across this snippet that should block > port scans, but I'm not sure if that would block a VPN user after all since > the VPN traffic is masqueraded. > > > > > > > > > > iptables -A port-scan -p tcp --tcp-flags > SYN,ACK,FIN,RST RST -m limit --limit 1/s -j RETURN > > > > > iptables -A port-scan -j DROP --log-level 6 > > > > > iptables -A specific-rule-set -p tcp --syn -j > syn-flood > > > > > iptables -A specific-rule-set -p tcp > --tcp-flags SYN,ACK,FIN,RST RST -j port-scan > > > > > > > > > > Any suggestions, please? > > > > > Many Thanks, > > > > > Houman > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Noel Kuntze > > > > IT security consultant > > > > > > > > GPG Key ID: 0x0739AD6C > > > > Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E > E40B 0739 AD6C > > > > > > > > > > > > > > -- > > > Noel Kuntze > > > IT security consultant > > > > > > GPG Key ID: 0x0739AD6C > > > Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C > > > > > > > > > > -- > > Noel Kuntze > > IT security consultant > > > > GPG Key ID: 0x0739AD6C > > Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C > > > > > > -- > Noel Kuntze > IT security consultant > > GPG Key ID: 0x0739AD6C > Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C > -- 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
