Unanticipated OpenVPN boo-boo

[elorimer]

This is blindingly obvious and I've just noticed.

For several years now I have used the OpenVPN servers on the firmware, with very strong passwords and non-obvious usernames. I've also blocked all the other WAN-side openings, so I've thought my LAN was fairly safe.

For that reason, and being somewhat lazy and frequently up to my elbows in the fun stuff we can do, I've used a somewhat simple admin password. What I didn't realize is that the admin user is authorized for the OpenVPN servers as well. So I wasn't at all as secure as I thought.

It is perfectly clear from the server web page that this is so.

 

[JDB]

Disable user/password authentication and use certificates (ideally with passphrases) instead, much more secure!


Sent from my iPhone using Tapatalk

 

[Martineau]

Disable user/password authentication and use certificates (ideally with passphrases) instead, much more secure!

Given that most users rely on the single common certificate generated for 'Client', if they legitimately enable User/PW+Certificates authentication, perhaps to allocate unique static IPs, then as per @elorimer's post, unfortunately the 'admin' user is always eligible to be used to connect to the OpenVPN Server(s).

To close this exposure, a 'client-connect' script should be used to drop the 'admin' user from connecting to the OpenVPN Server(s).

NOTE: I confess that having stupidly mangled the passwords for the OpenVPN Server clients, I will admit that using 'admin' to remotely login to my router via the OpenVPN Server,whilst completely irresponsible, did get me out of an embarrassing potential 'locked-out' situation.

 

[elorimer]

To close this exposure, a 'client-connect' script should be used to drop the 'admin' user from connecting to the OpenVPN Server(s).

Might you have a hint on how to do this? I have a client-connect script in place now that does WOL for places in the LAN, so if I follow, the admin user would be allowed to connect, triggering some sort of disconnect?

One aspect of this is that the passwords I use for openvpn are longer than the password that the GUI itself will accept (max 16). I don't think I need the same level of security for the GUI that I have for openvpn, but I'd prefer not to downgrade my openvpn security.

 

[Martineau]

Might you have a hint on how to do this? I have a client-connect script in place now that does WOL for places in the LAN, so if I follow, the admin user would be allowed to connect, triggering some sort of disconnect?

Simply add the following to your 'client-connect' script:

[ $username == "admin" ] && exit 1

e.g. Syslog shows that 'admin' passed the authentication (NOTE: I'm on my LAN for the test!) , but the connection was refused before 'admin' could access anything.

RT-AC68U ovpn-server2[4140]: 10.88.8.157 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0

RT-AC68U ovpn-server2[4140]: 10.88.8.157 TLS: Username/Password authentication succeeded for username 'admin'

RT-AC68U ovpn-server2[4140]: 10.88.8.157 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
RT-AC68U ovpn-server2[4140]: 10.88.8.157 [client] Peer Connection Initiated with [AF_INET6]::ffff:10.88.8.157:33983
RT-AC68U ovpn-server2[4140]: client/10.88.8.157 MULTI_sva: pool returned IPv4=10.16.0.2, IPv6=(Not enabled)
RT-AC68U ovpn-server2[4140]: client/10.88.8.157 WARNING: Failed running command (--client-connect): external program exited with error status: 94
RT-AC68U ovpn-server2[4140]: client/10.88.8.157 PUSH: Received control message: 'PUSH_REQUEST'
RT-AC68U ovpn-server2[4140]: client/10.88.8.157 Delayed exit in 5 seconds

RT-AC68U ovpn-server2[4140]: client/10.88.8.157 SENT CONTROL [client]: 'AUTH_FAILED' (status=1)

RT-AC68U ovpn-server2[4140]: client/10.88.8.157 SIGTERM[soft,delayed-exit] received, client-instance exiting

P.S. My 'client-connect' script actually also creates a connection/Statistics/duration log

Time: Connect: Tue Nov 20 22:45:22 2018
 Common Name: client
 Username:    admin
 I/P:         10.88.8.157
 PORT:        33983
 MTU:         1500
 Protocol:
 Local  I/P:  10.16.0.1
 Static Remote I/P:  10.16.0.111
 Status: FAIL

 

[elorimer]

[ $username == "admin" ] && exit 1

With "admin" here being whatever the administrator username is. Which ain't that. Then I can change the admin password back to something less secure.

I think this automatic access of the admin to the openvpn connection is unfortunate; a trap for the unwary.

Also, I found that the custom configuration block has some nifty checking: if something is wrong there, the openvpn server won't start and fails silently. Since I use the same open-connect script for both servers, I think I will not experiment further until I have physical access.

 

[HarryH3]

If you already have changed the "admin" username to something non-obvious, then you're far safer than when leaving "admin" as the username for the administration account. The chances of someone guessing both the username and password is orders of magnitude lower. Most scripts are just doing attacks against common usernames (with admin at the top of the list) and passwords. It would take far more than a lifetime to scan all possible usernames and passwords, with the difficulty rising as you use more characters for each.

I wonder if the Intrusion Protection module can detect and block the IP of systems that attempt too many passwords? The inner workings of AiProtection seem to be a bit of a black hole, but someone out there must know the answer.