Seems like my OpenVPN server has been hacked

[Sas]

I am running an ASUS AC68U with latest Merlin 384.6.

I recently logged into my router to find a lot of entries (all with username "UNDEF") in the client list for my single OpenVPN server, the majority of the IPs connecting were the same (54.207.11.46, which links to a very shady site).

I have WAN access enabled (and need it), but only over HTTPS (which in current versions is the only option), I also have ssh key only login allowed, and HTTPS access allowed on LAN. I also have Entware installed.

I have changed my admin password and have always used a non standard admin name. I turned off the VPN, but when I turn it back on, all the entries fill up again, so for now I am leaving it off.

Any suggestions on what I should do here? I am really at a loss as to how this could have happened with my setup, so if anyone else has any info on that as well, it would be greatly appreciated.

Thanks

 

[skeal]

I am running an ASUS AC68U with latest Merlin 384.6.

I recently logged into my router to find a lot of entries (all with username "UNDEF") in the client list for my single OpenVPN server, the majority of the IPs connecting were the same (54.207.11.46, which links to a very shady site).

I have WAN access enabled (and need it), but only over HTTPS (which in current versions is the only option), I also have ssh key only login allowed, and HTTPS access allowed on LAN. I also have Entware installed.

I have changed my admin password and have always used a non standard admin name. I turned off the VPN, but when I turn it back on, all the entries fill up again, so for now I am leaving it off.

Any suggestions on what I should do here? I am really at a loss as to how this could have happened with my setup, so if anyone else has any info on that as well, it would be greatly appreciated.

Thanks

Two things. Reset the router and manually config. Then never leave your router open to WAN. That is how you were hacked. Not your VPN.

Edit: Spelling

 

[Sas]

Two things. Reset the router and manually config. Then never leave your router open to WAN. That is how you were hacked. Not your VPN.

Edit: Spelling

So you are saying HTTPS or no, WAN is NEVER secure? Why not? Are you assuming they brute forced my username and password, or from some other vulnerability?

 

[skeal]

So you are saying HTTPS or no, WAN is NEVER secure? Why not? Are you assuming they brute forced my username and password, or from some other vulnerability?

They don't really have to brute force anything. The webui is so full of holes that Asus won't fix or hasn't fixed. The webui when exposed to wan can be hacked, it's a known issue. The underlying httpd I think is the issue.

 

[skeal]

WAN access without using a vpn is not a wise thing to do. Use your vpn to access your router and everything else you need. Do not ever expose webui or ssh to WAN, for any reason no matter how secure you think it is.

 

[Sas]

Ok, thanks for the advice. I am unfortunately away from home for the next few days, but I have setup a new VPN config and disabled WAN access and SSH access (even though it was passwordless key based). I will monitor it over the next couple of days via vpn only, so far there are no others on the new vpn, but I realize the whole thing could be compromised and will wipe it when I return.

 

[skeal]

Use an obscure port for your vpn server. Something high. The port scanners know which ports to scan so make it hard for them.

 

[M@rco]

Two things. Reset the router and manually config. Then never leave your router open to WAN. That is how you were hacked. Not your VPN.

Third: configure your VPN server on a non-default port
Fourth: Set 'Username / Password Auth. Only' to 'No' when configuring your VPN server (learned this one myself tonight on this great forum )

Darn, that @skeal guy is fast...

 

[Sas]

FWIW, none of the vulnerabilities listed here apply to my situation:

https://www.cvedetails.com/vulnerability-list/vendor_id-3447/Asus.html

So the curious cat in me really really wants to know how they did it (and why it appeared that only the OpenVPN access was compromised)...

 

[bitmonster]

Because you left WAN access open. Silly thing to do.

Just use VPN only as suggested.

Sent from my SM-G965F using Tapatalk

 

[bnhf]

I recently logged into my router to find a lot of entries (all with username "UNDEF") in the client list for my single OpenVPN server, the majority of the IPs connecting were the same (54.207.11.46, which links to a very shady site).

I'm not so sure that you've actually been hacked, but rather the hackers have been knocking right at the door. I recently updated an RT-AC68U on a release from last year to 384.6 and some of those same UNDEF entries showed up immediately. None were showing before the upgrade. Looking in the log, these IP addresses appear to be attempting TLS negotiation, but failing:

Oct  1 16:24:03 ovpn-server1[3213]: 199.33.123.22 TLS: Initial packet from [AF_INET6]::ffff:199.33.123.22:80, sid=6a22eb44 5adb63fe
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS Error: TLS handshake failed
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 SIGUSR1[soft,tls-errore-evaluate r] received, client-instance restarting
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS: Initial packet from [AF_INET6]::ffff:199.33.123.19:80, sid=6a22eb44 5adb63fe

I don't have WAN router admin access enabled, and never have. However, I have been using the standard OpenVPN port. I've changed the port and "upped my game" on encryption from 1024 bit keys to 2048 bit OpenVPN keys. I had actually been planning this anyway as 1024-bit encryption isn't really considered to be fully secure any longer. Getting a scare once in a while, is a good thing as far as I'm concerned -- as it always leads me to re-evaluate encryption, passwords and the like.

EDIT: BTW, none of those UNDEF entries showed any traffic over the VPN, 0 MBytes Received, 0 MBytes Sent.

 

[bitmonster]

Any issues with upping the port number and encryption level? Did you just have to change the client settings or re-export the VPN file? I am using Windows, Linux (Kubuntu) and Android (OpenVPN Client paid app).

 

[bnhf]

Any issues with upping the port number and encryption level? Did you just have to change the client settings or re-export the VPN file? I am using Windows, Linux (Kubuntu) and Android (OpenVPN Client paid app).

Everything seems to be working great, and it's been very quiet up in the more rarefied air of "unassigned" ports. AsusWRT- Merlin is super convenient for generating matching OpenVPN client files, but I actually wanted to have multiple unique clients and a GUI to manage the lot. I'm using xca, which I highly recommend. You can import your existing Merlin cryptography, but it's just as easy to start fresh.

xca is cross-platform, and can be found here. Works for a variety of crypto purposes:

https://sourceforge.net/projects/xca/

And here's a tutorial for using it to generate OpenVPN keys and certificates. It'll manage a revocation list too:

https://www.cult-of-tech.net/2016/05/setting-up-openvpn-certificates/

 

[RMerlin]

UNDEF means something connected to the port, but never completed authentication. In most case it indicates just a port scanner looking for something open. Switching to a port different than 1194 will usually get rid of these.

I have WAN access enabled (and need it)

Since you have a working OpenVPN server, you really don't need it.

 

[DonnyJohnny]

Nice to see once in a while someone posting these for awareness.

 

[Sas]

I'm not so sure that you've actually been hacked, but rather the hackers have been knocking right at the door. I recently updated an RT-AC68U on a release from last year to 384.6 and some of those same UNDEF entries showed up immediately. None were showing before the upgrade. Looking in the log, these IP addresses appear to be attempting TLS negotiation, but failing:

Oct  1 16:24:03 ovpn-server1[3213]: 199.33.123.22 TLS: Initial packet from [AF_INET6]::ffff:199.33.123.22:80, sid=6a22eb44 5adb63fe
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS Error: TLS handshake failed
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 SIGUSR1[soft,tls-errore-evaluate r] received, client-instance restarting
Oct  1 16:24:08 ovpn-server1[3213]: 199.33.123.19 TLS: Initial packet from [AF_INET6]::ffff:199.33.123.19:80, sid=6a22eb44 5adb63fe

I don't have WAN router admin access enabled, and never have. However, I have been using the standard OpenVPN port. I've changed the port and "upped my game" on encryption from 1024 bit keys to 2048 bit OpenVPN keys. I had actually been planning this anyway as 1024-bit encryption isn't really considered to be fully secure any longer. Getting a scare once in a while, is a good thing as far as I'm concerned -- as it always leads me to re-evaluate encryption, passwords and the like.

EDIT: BTW, none of those UNDEF entries showed any traffic over the VPN, 0 MBytes Received, 0 MBytes Sent.

THANK YOU for this, it explains a lot. When I looked more closely at the logs it was exactly as you said, and I previously noticed 0 bytes sent or received but still thought they were actually connected. While I am confused as to why they would even show up in the VPN client list (if they are not really connected), this does put my mind at ease that I have not in fact been hacked.

Still, I have disabled WAN and am only using VPN now, which is fine after all.

 

[Sas]

UNDEF means something connected to the port, but never completed authentication. In most case it indicates just a port scanner looking for something open. Switching to a port different than 1194 will usually get rid of these.



Since you have a working OpenVPN server, you really don't need it.

@RMerlin Do you think it might be good to simply not show these UNDEF records in the connected list (if that is something you have control over)? After all, the logs catch the bad attempts, and I think for most people it will be very confusing and panic inducing (as in my case)...

 

[RMerlin]

@RMerlin Do you think it might be good to simply not show these UNDEF records in the connected list (if that is something you have control over)?

No, because they can provide helpful information while troubleshooting connection issues.

 

[Brenneke]

Third: configure your VPN server on a non-default port
Fourth: Set 'Username / Password Auth. Only' to 'No' when configuring your VPN server (learned this one myself tonight on this great forum )

What kind of a port number should one use instead of default?
Please explain how the Password Auth. Only setting affects security. I set this to No for my VPN client and lost internet.

 

[M@rco]

What kind of a port number should one use instead of default?

You can choose a random port, preferably not used by any popular service. Using a non-default port reduces the chance of being targeted.

Please explain how the Password Auth. Only setting affects security. I set this to No for my VPN client and lost internet.

This setting affects your VPN Server. Besides the need to authenticate with a username and password a client now additionally needs to provide a certificate. This certificate is included in the .ovpn config which you can export on the VPN Server page and is needed for a client to be able to connect. Adding a certificate to the authentication requirements is what increases security compared to user/pass only.