Same here. Over 500 bans in 2 weeks. Crazy.
Thanks for this module @stephdl
1 Like
Iām seeing the same behavior on my machine. What steps need to be taken to change the OpenVPN port to something else? e.g. something thatās not port 1194?
Bob
If you mean openvpn roadwarrior setup, just go to the panel āOpenVPN-Roadwarrior/Serverā in the GUI and change the port and then change the port in the client config or download the a openvpn-config from the panel āOpenVPN-Roadwarrior/Roadwarrior Accountā. But Iām not sure that this will make it better. I had the same idea and changed to 1294. The number of bans was doubled. 
So I changed back. Today it seems teh mainhype is over. Only 5 IPs currently banned.
Donāt be mad about proper behavior of your app
Do you see any successful connection to your server?
NO
so this mean -> you are using common port to your OpenVPN server
this is not a abused
this is the punks trying to connect to you-> still no authorization -> (so no action) this is how you can see in your logs
You can change port to your OpenVPN <- for what???
They can scan you and find your OoenVPV port - no point
Ignore it
This is how your OpenVPV server respond to tricky questions like thatā¦
You can check your firewall and block it from there -> not recommended
If your attacker is clever ten he never back from the same IP address
Your OpenVPN server will ignorit any way
You are not exposed my friend but you can see whe is intersting in your OpenVpn server -> on the default por is many
Hopefully you can understand the background of this.
THIS IS NOT AN venerability - this is proper behavior of OpenVPN
please do we have guys with security background or juts scriptkids?
Be clever how you read infos from your firewall.
I agree it is normal behaviour, but I did move my SSH port to something else and I get next to none attempts to SSH into my server. So IMO it does work to use some āsecurity by obscurityā.
Are you 100% certain that this is not probing for one. How long is the āresponsibleā period after reporting to the owning party before publishing.
I was not stating that it was one, but it has all the hallmarks of a zero-day vulnerability. No previous āprobes/sniffsā for months followed by a massive number in a very short period.
Cheers.
Probably you canāt be 100% sure for nothing in security field but this behavior is the proper one.
You need have exposed one TCP or UDP port to be able to connect to your VPN.
Up to this days they are not known vulnerabilities to this protocol.
You can also use fail2ban module for better security.
Iāve been thinking about these intrusion attempts.
Hereās an extract from my openvpn log
Sat Sep 22 20:22:07 2018 85.106.103.214:80 SIGUSR1[soft,tls-error] received, client-instance restarting Sat Sep 22 20:26:16 2018 147.135.26.5:65139 TLS: Initial packet from [AF_INET]147.135.26.5:65139 (via [AF_INET]30.1.1.3%eth0), sid=6a22eb44 5adb63fe Sat Sep 22 20:27:17 2018 147.135.26.5:65139 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Sep 22 20:27:17 2018 147.135.26.5:65139 TLS Error: TLS handshake failed Sat Sep 22 20:27:17 2018 147.135.26.5:65139 SIGUSR1[soft,tls-error] received, client-instance restarting Sat Sep 22 20:27:20 2018 147.135.26.5:65139 TLS: Initial packet from [AF_INET]147.135.26.5:65139 (via [AF_INET]30.1.1.3%eth0), sid=6a22eb44 5adb63fe Sat Sep 22 20:28:20 2018 147.135.26.5:65139 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Sep 22 20:28:20 2018 147.135.26.5:65139 TLS Error: TLS handshake failed Sat Sep 22 20:28:20 2018 147.135.26.5:65139 SIGUSR1[soft,tls-error] received, client-instance restarting Sat Sep 22 20:35:19 2018 149.56.13.49:443 TLS: Initial packet from [AF_INET]149.56.13.49:443 (via [AF_INET]30.1.1.3%eth0), sid=6a22eb44 5adb63fe Sat Sep 22 20:36:19 2018 149.56.13.49:443 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Sep 22 20:36:19 2018 149.56.13.49:443 TLS Error: TLS handshake failed Sat Sep 22 20:36:19 2018 149.56.13.49:443 SIGUSR1[soft,tls-error] received, client-instance restarting Sat Sep 22 20:36:19 2018 149.56.13.49:443 TLS: Initial packet from [AF_INET]149.56.13.49:443 (via [AF_INET]30.1.1.3%eth0), sid=6a22eb44 5adb63fe Sat Sep 22 20:37:19 2018 149.56.13.49:443 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Sep 22 20:37:19 2018 149.56.13.49:443 TLS Error: TLS handshake failed Sat Sep 22 20:37:19 2018 149.56.13.49:443 SIGUSR1[soft,tls-error] received, client-instance restarting
All the in coming scans are from random ports.
Can the Nethserver firewall be set up to only NAT traffic to the OpenVPN server that comes FROM the OpenVPN port 1194? That should help eliminate most of the in comming rouge traffic.
if soā¦how?
Regards
Bob
Nethserver openvpn client config uses the nobind option that randomizes client ports which is recommended when using more VPN connections so blocking source ports is not possible with firewall.
https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN#Settinguptheconnection
1 Like
oh, thatās a shame. it seemed like a logical way to stop the intrusion attempts.
thanks
bob
OK, maybe I should keep quiet here before I jinx myself and my IP.
It looks like the list of IPs that were being hit continuously by this were harvested from somewhere. (Hopefully not this community). That would explain why the probes suddenly started back in August, out of nowhere, and why following a re-boot I did yesterday where I forced my cable ISP to give me a new IP I have seen only 2 attempts at connection in over 24 hours, where previously I was seeing hundreds, if not thousands per day.
Cheers.
2 Likes