Nginx as Reverse Proxy for multiple servers binded to proxy using UNIX sockets - how to reached in LAN

[Francis Daly]

On Tue, Oct 16, 2018 at 09:23:33PM +0200, Stefan Müller wrote:

Hi there,

> 1. documentation
>    Is there any additional document for the -c command. I find only:
>     1. http://nginx.org/en/docs/switches.html

That page indicates that "-c" means that this nginx instance uses this
named config file instead of the compiled-in default one. I'm not sure
what other documentation is possible.

>    but none of them says that it will start an independent instances of
>    nginx.

Every time you run the nginx binary, you run a new instance of nginx,
independent of any other.

Not all command-line argument combinations to nginx mean that it should
run a web server that never exits; many combinations mean "do this one
thing and exit".

The one command-line argument that is used to interact with an
already-running nginx -- -s -- does that interaction by sending a signal
to the appropriate process-id, in exactly the same way that the "kill"
or "pkill" binaries would. The new short-term nginx instance is still
independent of the already-running one, in the same way that "kill"
would be independent of it.

> 2. command line
>    I assume, that the command line parameters refer to a single
>    instance environment. How do I use the command line parameters for a
>    specific instance? Is it like this nginx -V "pid
>    /var/run/nginx-user1.pid"?

Command-line parameters are used when you start a new instance of
nginx. They do not refer to any other instance (with the one "-s"
exception mentioned above).

> 3. root and non-root
>    only the master / proxy server instance need root access in order to
>    bind to ports <1024 and change its user-id to the one defined in
>    the|user <https://nginx.org/en/docs/ngx_core_module.html#user>|
>    directive in the main context of its .conf file.
>    The other / backend instances don't have to be started as root as
>    they don't need to bind to ports, they communicate via UNIX sockets
>    so all permission are managed by the user account management.
>    That is the same, what you said, isn't it?

Yes.

An nginx that wants to "listen" on a place that only root can "listen"
on, or write to places that only root can write to, needs to start as
root. Any other nginx does not need to. (Again, excepting "-s".)

> 4. all in all there two layers of isolation
>     1. dynamic content provide such as PHP

nginx does not "do" PHP. Or much in the way of "dynamic" content (in
the sense that it seems to be meant here).

>        each "virtual host" / server{} blocks has its own PHP pool. So

That's not an nginx thing, but it is a thing that you can configure if
you want to.

>        the user for pool server{}/user1/ cannot see  the pool
>        server{}/user2/. If /user1/ gets hacked, the hacker won't get
>        immidate acceass to /user2/ or the nginx  master process, correct?

"PHP" is (probably) run under a fastcgi server, as whatever system user
you want that service to run as. You can run multiple fastcgi servers
if you want to, each under their own user account.

nginx can be a client of that server if you use "fastcgi_pass" in your
nginx config that points to the server.


You have nginx-main, starts as root then switches to userM. "The browser"
is a client of this server.

You have (multiple) nginx-userN, runs as userN. nginx-main is a client
of this server.

You have (multiple) php-userP, runs as userP. nginx-userN is a client
of this server.

What specific threat model are you concerned with here?

When a thing gets hacked, is that thing running under the control of root,
or userM, or one of the multiple userNs, or one of the multiple userPs?

The access the outsider gains will (presumably) not exceed the access
that that user has. "root" will be able to access lots of things. "userM"
must be able to access the "userN" listening socket. "userN" must be
able to access the matching "userP" listening socket. "userP" must be
able to access the php files.

>     2. independent instances of nginx.
>        In case the master process is breach for what ever reason, the
>        hacker cannot see the other serves as long as he won't get root
>        privileges of the machine and there is the same exploit in the
>        other servers, correct?

Again, I'm unsure what threat model you are concerned about here.

If someone breaks the main nginx to get "root" access, they have root
access. If they break the main nginx to get "userM" access, they will
be able to access nginx-userN (because userM can do that). Is that
enough access to also break nginx-userN so that they can get "userN"
access? (nginx-main and nginx-userN run the same binary. Is the breakage
due to configuration, which might be different between the two? Or due
to something inherent, which will be the same between the two?)

Without trying to be dismissive: if someone can break nginx to gain user
access, it is unlikely to be you or me that they will be attacking first.

I think that based on history, "badly written CGI scripts" (which in
this case corresponds to "badly written PHP") is the most likely way
that web things will be broken. In this design, that PHP runs under
the control of the fastcgi server, as a user userP. If that happens,
the outsider will have access as userP to do whatever the PHP script
and fastcgi server allow them to do. nginx is not involved except as
(probably) an initial pass-through tunnel.

If userP has access to turn off your fridge or reconfigure your nginx-main
or send a million emails or read secret files on your filesystem, then
the outsider will probably have access to do those things too.

Only you can decide what level of risk you're happy with.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org