```This command will generate an OpenVPN static key and write it to the file `ta.key`. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA `.key` and `.crt` files.
+
```
+
This command will generate an OpenVPN static key and write it to the file `ta.key`. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA `.key` and `.crt` files.
In the server configuration, add:
+
```
tls-auth ta.key 0
```
+
In the client configuration, add:
```
tls-auth ta.key 1
@@ 1194,6 1197,7 @@
## proto udp
While OpenVPN allows either the TCP or UDP protocol to be used as the VPN carrier connection, the UDP protocol will provide better protection against DoS attacks and port scanning than TCP:
+
```
proto udp
```
@@ 1215,29 1219,39 @@
**OpenVPN Configuration:**
Create the following script and save it at: `/usr/local/sbin/unpriv-ip`:
+
```bash
#!/bin/sh
sudo /sbin/ip $*
```
+
Run `visudo` and add the following lines to allow the user 'user1' to execute `/sbin/ip` without a password:
+
```plaintext
user1 ALL=(ALL) NOPASSWD: /sbin/ip
```
+
To enable a group of users to execute `/sbin/ip` without a password, add:
+
```plaintext
%users ALL=(ALL) NOPASSWD: /sbin/ip
```
+
Add these lines to your OpenVPN configuration file:
+
```plaintext
dev tunX/tapX
iproute /usr/local/sbin/unpriv-ip
```
+
Please ensure you choose either 'tun' or 'tap' and replace `X` with a constant.
To set up a persistent interface as root and allow a user and/or group to manage it, use the following command (replace `tunX` with your chosen device):
+
```bash
openvpn --mktun --dev tunX --dev-type tun --user user1 --group users
```
+
Ensure that you replace `X` with the appropriate device number and specify either 'tun' or 'tap' in your configuration.## Run OpenVPN as an Unprivileged User
Further security measures can be enforced by modifying parameters in the `/usr/local/sbin/unpriv-ip` script.
@@ 1252,7 1266,7 @@
This command changes the working directory of the OpenVPN daemon to the `jail` subdirectory upon initialization. It then redefines its root filesystem to this directory, preventing any access to files outside the `jail` and its subdirectories. This is crucial for security, as any compromised server remains isolated from the rest of the server's filesystem.
-
### Caveats:
+
### Caveats
Since **chroot** changes the daemon's filesystem perspective, any necessary files for OpenVPN post-initialization should be placed within the `jail` directory, such as:
- the `crl-verify` file, or
@@ 1291,22 1305,29 @@
As an example, we will revoke the **client2** certificate, which we generated above in the "key generation" section of the HOWTO.
First, open up a shell or command prompt window and change directory to the **easy-rsa** directory as you did in the "key generation" section above. On Linux/BSD/Unix:
+
```
. ./vars
./revoke-full client2
```
+
On Windows:
+
```
vars
revoke-full client2
```
+
You should see output similar to this:
+
```
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
Note the "error 23" in the last line, indicating that a certificate verification of the revoked certificate failed.
The **revoke-full** script will generate a Certificate Revocation List (CRL) file named **crl.pem** in the **keys** subdirectory. This file should be copied to a directory accessible by the OpenVPN server, and CRL verification should be enabled in the server configuration:
+
```
crl-verify crl.pem
```
+
Now all connecting clients will have their certificates verified against the CRL, and any matching revoked certificates will result in the connection being dropped.
### CRL Notes
@@ 1332,45 1356,36 @@
- If using the `chroot` directive, ensure a copy of the CRL file is placed in the chroot directory, as the CRL file is read after the `chroot` call is executed.
- A common reason for certificate revocation is that a user forgets the password used to encrypt their private key. Revoking the original certificate allows for the generation of a new certificate/key pair with the same common name.
-
### Important Note on Mitigating "Man-in-the-Middle" Attacks
+
## Important Note on possible "Man-in-the-Middle" attack if clients do not verify the certificate of the server they are connecting to
-
To prevent a potential Man-in-the-Middle attack where an authorized client tries to impersonate the server to connect to another client, it is crucial to enforce server certificate verification by clients. For OpenVPN 2.1 and above, you can secure server certificates with specific key usage and extended key usage as outlined by RFC3280 for TLS connections:
| Client | digitalSignature | TLS Web Client Authentication |
-
| Client | keyAgreement | |
-
| Client | digitalSignature, keyAgreement | |
-
| Server | digitalSignature, keyEncipherment | TLS Web Server Authentication |
-
| Server | digitalSignature, keyAgreement | |
-
```
+
To avoid a possible Man-in-the-Middle attack where an authorized client tries to connect to another client by impersonating the server, make sure to enforce some kind of server certificate verification by clients. There are currently five different ways of accomplishing this, listed in the order of preference.
+
+
Option 1 for OpenVPN 2.1 and above: build your server certificates with specific key usage and extended key usage. The RFC3280 determine that the following attributes should be provided for TLS connections:
-
You can build your server certificates with the `build-key-server` script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:
| Client | digitalSignature | TLS Web Client Authentication |
+
| | keyAgreement | |
+
| | digitalSignature, keyAgreement | |
+
| Server | digitalSignature, keyEncipherment | TLS Web Server Authentication |
+
| | digitalSignature, keyAgreement | |
+
+
You can build your server certificates with the build-key-server script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:
```
remote-cert-tls server
-
```### Option 2, for OpenVPN 2.0 and below:
-
Build your server certificates with the **build-key-server** script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting **nsCertType=server**. Now add the following line to your client configuration:
-
```
-
ns-cert-type server
```
-
This will block clients from connecting to any server which lacks the **nsCertType=server** designation in its certificate, even if the certificate has been signed by the **ca** file in the OpenVPN configuration file.
-
### Option 3:
-
Use the **tls-remote** directive on the client to accept/reject the server connection based on the common name of the server certificate.
+
Option 2, for OpenVPN 2.0 and below: Build your server certificates with the build-key-server script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting nsCertType=server. Now add the following line to your client configuration:
-
### Option 4:
-
Use a **tls-verify** script or plugin to accept/reject the server connection based on a custom test of the server certificate's embedded X509 subject details.
+
```
+
ns-cert-type server
+
```
-
### Option 5:
-
Sign server certificates with one CA and client certificates with a different CA. The client configuration **ca** directive should reference the server-signing CA file, while the server configuration **ca** directive should reference the client-signing CA file.
+
This will block clients from connecting to any server which lacks the nsCertType=server designation in its certificate, even if the certificate has been signed by the ca file in the OpenVPN configuration file.
-
## Sample OpenVPN 2.0 Configuration Files
+
Option 3: Use the tls-remote directive on the client to accept/reject the server connection based on the common name of the server certificate.
-
Latest sample configuration files are available on [GitHub](https://github.com/OpenVPN/openvpn/tree/master/sample/sample-config-files).
+
Option 4: Use a tls-verify script or plugin to accept/reject the server connection based on a custom test of the server certificate's embedded X509 subject details.
Option 5: Sign server certificates with one CA and client certificates with a different CA. The client configuration ca directive should reference the server-signing CA file, while the server configuration ca directive should reference the client-signing CA file.
