OpenVPN tls-auth Option is Critical

Someone attempted a very noisy attack against my router’s built-in OpenVPN server today.  While there was no chance this person could guess my encryption parameters to gain access, he or she did manage to cause a denial of service.

The log excerpt looks like a whole lot of these:

Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:22475 TLS: Initial packet from [AF_INET]148.163.126.72:22475 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:57036 TLS: Initial packet from [AF_INET]148.163.126.72:57036 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS handshake failed
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS handshake failed
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:55183 TLS: Initial packet from [AF_INET]148.163.126.72:55183 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:12142 TLS: Initial packet from [AF_INET]148.163.126.72:12142 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS handshake failed
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 SIGUSR1[soft,tls-error] received, client-instance restarting

Basically, it’s an “Initial packet” followed 60 seconds later by three error messages.  It’s this 60-second delay that the attacker was careless with.  By sending close to one new attack every second, this person managed to screw up the router’s port forwarder, which is a problem everyone notices right away.

A major part of the solution is to ensure an extra key is configured on the server.

tls-auth static.key 0

This requires some changes to the client profile.  After a successful server change, the log looks much better.

Sep  6 18:04:55 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)
Sep  6 18:04:55 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)
Sep  6 18:04:57 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)
Sep  6 18:04:57 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)
Sep  6 18:06:15 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)
Sep  6 18:06:15 vpnserver1[8112]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]74.91.120.143:2302 (via [AF_INET]%eth0)

The attacker is now prevented from attempting any handshake, which seems to make the server more stable.

 

Leave a Reply

Your email address will not be published. Required fields are marked *