Is there a new OpenVPN exploit


(Ralf Jeckel) #21

Same here. Over 500 bans in 2 weeks. Crazy.
Thanks for this module @stephdl


(bob) #22

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


(Ralf Jeckel) #23

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. :roll_eyes: So I changed back. Today it seems teh mainhype is over. Only 5 IPs currently banned.


(Zimny) #24

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


(Zimny) #25

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.


(Rob Bosch) #26

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


(Eddie Atherton) #27

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.


(Zimny) #28

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.


(bob) #29

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


(Markus Neuberger) #30

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


(bob) #31

oh, that’s a shame. it seemed like a logical way to stop the intrusion attempts.
thanks
bob


(Eddie Atherton) #32

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.