3 ms·
I am running all my production servers with LXD. Letting my services and deamons doing it's job in a lx-container. If I do need to expose a service to the publi
by Aldipower 6y ago
I am running all my production servers with LXD. Letting my services and deamons doing it's job in a lx-container. If I do need to expose a service to the public I port-forward or reverse-proxy to the internal containers ips. This adds an additional layer of security. Emphasis on _additional_, hopefully not the only one. :)
This makes it more unlikely that a accidentally open database port without authorization makes it to the public.
- Qerub 6y agoWon't this forwarding/proxying make the internal services not see the actual source IP addresses making access logs less useful? (Sure, if you're proxying HTTP there's X-Forwarded-For but that's more configuration to get right and there are other protocols.) It sounds like you would be better served by a firewall, ideally both on the server node and in front of it.
- jlokier 6y ago> Won't this forwarding/proxying make the internal services not see the actual source IP addresses making access logs less useful? Not when forwarding. When port forwarding using DNAT only, the internal container or VM service sees the remote IP address. As you say, HTTP has X-Forwarded-For. Because it is common to have one or more stages of HTTP reverse proxying these days for Internet-facing services for robustness (for example NginX proxy -> Python application), you'll probably have X-Forwarded-For configured already.