1

I've recently started to automate a lot of my tasks for my private VPS. A significant part of working with this server is ensuring the nginx webserver, which handles a reverse proxy to multiple applications and a static website, is running and correctly configured.

Though when working with complex configs or debugging problems only working over bash+ssh has become a problem for me. It's also been a problem when just wanting to look at configs without actually connecting to the server e.g. on the go with a phone.

So I've decided to move my nginx configs to a private git repository and have them, with a CI tested their first, deployed onto the server. This approach has solved a lot of problems and simplified the workflow. But I would now like to make this repository public to enable users to ensure for themselves what e.g. access is being logged as part of providing transparency over the usage/ processing of their data.

My question is then: How much risk do I take by publishing these configs and is there any part that should be censored?

2

IMO, there should be nothing in your nginx config that is secret. It should not directly contain credentials. There should not be any secret paths or secret headers or secret query params that bypass authentication. The filesystem path to your TLS private key is not useful to an attacker. The filesystem path of a basic auth password file is not useful to an attacker. Rewrites and redirects and log format should not be useful to an attacker.

It might be that your config has some kind of bug that allows an attacker to attack your app (e.g. send http request headers that the app thinks are only set by nginx), and no attacker knew about it, but once they see your config they'll know and be able to attack your site/app. The bug was there already, but nobody knew. This is like open sourcing the app's source code - maybe someone will find bugs now that it is easier to inspect.

So, it should be safe to publish your nginx config, but only if it was developed while knowing that it will be published, or reviewed before being published.

3
  • 1
    Yours is a fair point. However, the nginx config could contain route information and that might expose IPs that could be use in further attack. Is it possible to keep the routing information aside?
    – borcho
    Apr 8 at 16:59
  • Very much depends on the architecture and app, I think. I guess mostly nginx will refer to app server on localhost (or even unix domain sockets), so nothing secret there. How are RFC 1918 internal IP addresses useful? You need to protect from SSRF anyway. Secret backends accessible over the internet - use wireguard or ssh tunnel, I guess.
    – Z.T.
    Apr 8 at 17:04
  • Thank you for your advice. It's really appreciated. I will most likely give my configs to a friend with more experience for review before publishing.
    – Cobalt
    Apr 8 at 17:33
0

Well if it is unsafe then you should rethink your design. As long as you properly set access control to your password file: nginx keeps password in a separate file, and keep your server private keys safe and well hidden. Make sure nginx only gets as much permission as it needs and no other process gets to access nginx privy files. If you can make sure that your password hashing algorithm is good enough all but a zillion or so easily guessed password even if password file gets compromised and because no one probably needs to remember the password, make sure it has enough entropy.

IN OTHER WORDS, follow Kerckhoffs's principle. You may hide your nginx configs if it makes you feel safe but if your security relies on it, you are in trouble. Information that must be private, like passwords and cryptographic keys, keep them in separate file and keep good access control to keep them safe.

1
  • 1
    I can't mark two answers as 'correct' but thank you for your advice. It's really appreciated
    – Cobalt
    Apr 8 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.