Hey again @zach. You have been a great help and appreciate all the help.
I do have a question that revolves around HTTPS requests to the pritunl web server. Currently we have to have our ports open to 0.0.0.0/0 so when a Raspi Pi connects it communicates to the Pritunl Server, pulls the profile, and connects. Is there a way of securing ourselves from threat vectors brute forcing into our web server? I looked into Dynamic Firewall but this would leave our devices from communicating to the internet which we will need.
Would appreciate any help on this on better securing our Pritunl Server.
The rate of login attempts is controlled by the settings below. It defaults to 30 attempts every 600 seconds.
sudo pritunl set app.auth_limiter_count_max 30
sudo pritunl set app.auth_limiter_ttl 600
There’s not really any possibility of a brute force attack because only administrators have a password and administrators should be configuring strong passwords. User authentication is generally handled by the single sign-on provider and the login limits would be controlled there. Configuring a Yubikey for the administrators will provide the best protection.
For the general security of the web server the systemd web server should be enabled with sudo pritunl set app.web_systemd true as documented in the Securing Pritunl documentation this provides better isolation for the external web server process. The release currently in development has also significantly increased the security of the web console with an additional NaCl based pre-authentication. The internal web server in the pritunl Python process signs a token that is stored in the session cookie and this is then validated by the external Go pritunl-web server process before routing the request to the internal web server. With this almost all the handlers will be blocked before reaching the internal Python process. During the development of this the existing security was also extensively reviewed.
The lowest risk and recommended configuration is to have the web server open to 0.0.0.0/0 with device authentication and dynamic firewall. With the two layer web server any attack would need to get through the two different web frameworks in different languages one being Go the other Python and with the upcoming release two different session validation methods one NaCl and the other HMAC-SHA. Device authentication eliminates all single sign-on vulnerabilities and verifies each physical device using the TPM or Apple Secure Enclave. Dynamic firewall eliminates all attacks on the VPN ports which are C based processes running with elevated privileges.
I will look into adding sudo pritunl set app.web_systemd true to provide better isolation.
When it comes to Device authentication, I would like to implement this on a Raspberry Pi 4/5 but as far as I know, Raspberry Pi’s don’t come with TPM built-in. I would need to purchase an add-on using the GPIO pins. If I can still use device authentication without TPM, I have over 5000+ Raspi Pis that are going to connect. Would the process be as follows:
a) Have my script ready to onboard all devices
b) Run sudo pritunl override-device-key which will not ask me for a pin to register my devices for the next 8 hours.
c) Run my script which will onboard 5000+ devices and presto.
Question though: If my Raspi Pi disconnects and reconnects, will I need to register my Raspi Pi each time it does this?
I will look into Dynamic Firewall. If my understanding is correct, this will not allow me to ssh into servers in AWS if this is enabled since I am using WG or OpenVPN ports?
If the TPM is properly implemented it shouldn’t change. The TPM uses a procedural key, it takes the input parameters such as the encryption algorithm and attributes. Then on the TPM a key is derived from the input parameters that will always be the same for those input parameters. As long as the TPM isn’t reset even if the OS is reinstalled and the profile is reimported it will still maintain it’s device authentication validation.
The dynamic firewall won’t effect SSH access. The security group in AWS should be left the same. On AWS the VPN ports should be open. Then on the server when dynamic firewall is enabled the Pritunl server creates iptables rules that block access only the VPN ports for servers that have the dynamic firewall enabled. Once a client completes the pre-connection authentication through HTTPS the clients public IP is added to the allow ipset for that VPN port.