Feature Request: control server authentication

[smerschjohann]

Is this urgent?

No

Host OS

Fedora CoreOS

CPU arch

x86_64

VPN service provider

Custom

What are you using to run the container

docker run

What is the version of Gluetun

Running version v3.38.0 built on 2024-03-25T15:53:33.983Z (commit b3ceece)

What's the problem 🤔

The internal service exposes its complete configuration to unauthenticated local services and users. It is also possible to change the state of the VPN by restarting the VPN (and maybe other things).

A basic protection using an Authorization Header would be good to ensure no thirdparty that might know of the presence of gluetun can gain the VPN credentials.
Otherwise it's nice to have the API.

Share your logs (at least 10 lines)

# curl http://localhost:8000/v1/vpn/settings

{"type":"wireguard","provider":{"name":"*******","server_selection":{"vpn":"wireguard","target_ip":"0.0.0.0","countries":["********"],"categories":null,"regions":[],"cities":null,"isps":null,"names":null,"numbers":null,"hostnames":null,"owned_only":false,"free_only":false,"premium_only":false,"stream_only":false,"multi_hop_only":false,"port_forward_only":false,"openvpn":{"config_file_path":"","tcp":false,"custom_port":0,"pia_encryption_preset":""},"wireguard":{"endpoint_ip":"0.0.0.0","endpoint_port":0,"public_key":""}},"port_forwarding":{"enabled":false,"provider":"","status_file_path":"/tmp/gluetun/forwarded_port","listening_port":0}},"openvpn":{"version":"2.5","user":"","password":"","config_file_path":"","ciphers":null,"auth":"","cert":"","key":"","encrypted_key":"","key_passphrase":"","pia_encryption_preset":"","mssfix":0,"interface":"tun0","process_user":"nonrootuser","verbosity":1,"flags":null},"wireguard":{"private_key":"*************************","pre_shared_key":"","addresses":["10.5.0.2/32"],"allowed_ips":["0.0.0.0/0","::/0"],"interface":"tun0","mtu":1400,"implementation":"auto"}}

---
curl -X PUT --data '{ "status": "stopped"}' http://localhost:8000/v1/vpn/status
{"outcome":"stopped"}

Share your configuration

No response

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[qdm12]

Please change your issue title to a Feature request since this isn't a bug, and it isn't urgent. In the meantime, you can do one of the following:

• setup an http proxy with authentication in front of the gluetun control server to achieve this
• not publish the port of the server
• add host firewall rules to restrict which ip address has access to it

[smerschjohann]

Thanks for the feedback. Sure, I changed it accordingly. I was not really sure how to classify it myself. It reallly depends on how you use the gluetun. But yes, agreed, changed.

Depending on the setup a firewall won't be easily achievable, especially if you use it as a sidecar. But for all that might expose the port currently, I second your suggestions.

[ezekieldas]

The area of the Control Server, updaters (and a general security audit) has had my attention lately so I feel obliged to comment on this.

I suggest applying a different priority to this and/or adopting an interim solution so that these sensitive details aren't exposed. I understand this only becomes available when the control server port is exposed, however:

1. The endpoint /v1/vpn/settings itself isn't documented. Unless the participant reviews the source, they may not be aware of this exposure.
2. There are many, very good uses of the Control Server, some of which may have been quickly adopted, overlooking any vulnerabilities.
3. In certain environments, whereby Gluetun has become a trusted keystone in a security model, the realization of this vulnerability could be a total showstopper. Particularly in cases where any kind of org policy is involved.

For my own implementation, I'm willing to continue the risk, mainly because of 'add host firewall rules' noted above has always been the case for me.

While the ideal solution has been noted here, would it be possible to offer an interim solution, one that potentially makes this endpoint unavailable by way of a config option (eg, HTTP_CONTROL_SERVER_DISABLE_SETTINGS).