Hardening controller: protect prometheus and webssh paths with authentication #1546
Description
Improve security for the controller endpoints by hardening prometheus and webssh access mechanisms:
- prometheus and webssh endpoints are currently protected by random paths, comparable to API tokens/secrets.
- This only works for requests made through authenticated controller access.
Enhance the security posture of controller:
- Prevent accidental exposure of prometheus and webssh endpoints, which could potentially allow attackers to enumerate resources or misuse UI functionality, even though random paths mean the risk is low and comparable to an API token/secret.
Proposed solution
- Remove prometheus paths from /defaults as they are not actually used from the UI.
- Protect prometheus endpoint with basic authentication.
- Protect webssh endpoint with basic authentication using a token (rather than only relying on random path).
Additional context
Currently, if an attacker discovers and accesses the prometheus or webssh web path:
- Prometheus: could enumerate firewall devices connected to controller. Unlikely due to random path, but an improvement is possible by requiring authentication as well.
- WebSSH: with access and some JS manipulation, UI could be employed to connect to other machines, but an attacker still needs the password to connect. This is akin to having a web-based putty—does not pose a fundamental security risk—however, path protection is random (comparable to a secret).
Both limitations have been worked around and can be improved with additional authentication.
See also