1

My setup consists of a public-facing VPS running NGINX, and a local machine running certain services. The VPS and the local machine are connected using WireGuard, and NGINX on the VPS is using WireGuard IPs to serve content from the services on the local machine. Some of the services on the local machine provide live video streaming and other features which rely on constant data streaming.

The local machine does not run NGINX, so the VPS is talking to the services on the local machine directly through WireGuard.

This is an extract from my NGINX configuration on the VPS:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

...
proxy_pass (a service on local machine);
proxy_set_header Host $host;
proxy_redirect http:// https://;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

As far as I know, all of these settings are required for the services to work but I am open to experimenting with different settings.

My question is whether with this setup either the WireGuard IP or the public IP of the local machine could be revealed, and how could I do an in-depth test to make sure they don't.

Thanks in advance!

1
  • 1
    You cannot rule out bugs in software. Ref e.g. heartbleed that may reveal such information in specific cases.
    – vidarlo
    Dec 25, 2022 at 14:19

2 Answers 2

1

The Wireguard IP possibly. I would have to dig a bit deeper. I would think your public facing IP would be ok, depending on which services are being run of course. I have had a similar setup in a lab be purposefully vulnerable due to services on the supposedly secure backend.

1
  • 1
    You cannot assume that your services are all hardened and there's no upcoming Heartbleed or something similar up the cybercriminal's sleeve. Dec 25, 2022 at 23:01
0

It might be that nginx reveals the upstream in some corner case, you might want to review/audit it to ensure you are using the right configuration, although I think even in case of failure it's only noted in the error_log, not to the client.

Revealing the wireguard IP should not be a problem, since they are private to your wireguard tunnel (unlike the IP of the other wireguard endpoint).

The main risk would be in the local machine outing itself, such as:

  • including its own ip in some header / link
  • sending a reply from their public ip
  • serving content on their public ip that can be correlated with the vps one

For good measure, I would configure the firewall to drop any traffic from/to the local machine that isn't going through wireguard (adapt as needed if that is also used for other purposes)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .