Securing access to GRR server (important!)¶
GRR is a powerful system. However, with power comes responsibility and potential security risks.
If you’re running GRR for anything besides simple demo purposes, it’s extremely important to properly secure access to GRR server infrastructure. Because:
- Anybody who has root access to your GRR server effectively becomes root on all systems running GRR client talking to your GRR server.
- Anybody who has direct write access to GRR datastore effectively becomes root on all systems running GRR client talking to your GRR server.
Consequently, it’s important to secure your GRR infrastructure. Please follow a security checklist below.
GRR Security Checklist¶
- Generate new CA/server keys on initial install. Back up these keys somewhere securely (see Key Management).
- Maximally restrict SSH access (or any other kind of direct access) to GRR server machines.
- Make sure GRR web UI is not exposed to the Internet and is protected.
For a high security environment:
- Make sure GRR’s web UI is served through an Apache or Nginx proxy via HTTPS. If you’re using any kind of internal authentication/authorization system, limit access to GRR web UI when configuring Apache or Nginx. See user authentication documentation.
- If there’re more than just a few people working with GRR, turn on GRR approval-based access control
- Regenerate code signing key with passphrases for additional security.
- Run the http server serving clients on a separate machine to the workers.
- Ensure the database server is using strong passwords and is well protected.
- Produce obfuscated clients (repack the clients with a different Client.name setting)