I’ve reads lots of people who suggest setting up a reverse proxy in order to use things like docker containers.
I setup an openvpn on my Synology and I’m wondering if I should setup a reverse proxy as well.
As far as I lnow, I would have to open ports 443 and 80 which is kinda dangerous.
Any help?
A reverse proxy just allows you to route your connections from outside your network to specific servers inside your network.
If you have servers for Jellyfin, Synology, OwnCloud, and a wiki, you have to remember your public IP, which probably changes unless you’ve paid extra for a static, and the port that each server is listening on to reach it outside your network. This quickly gets cumbersome.
However, with a reverse proxy you can do the following:
Doing this will allow you to simply type in synology.yourdomain.tld instead of 123.456.789.000:1111 or whatever. It’s a big deal when you’re running 15 servers at home.
Multi-domain, multi-subpath on a single IP&port (instead of lots of ports and ip to remember). Also, easy and centered certificate management. Reverse proxy is not necessary on local network and non-public facing server, but it’s nice to have. If you are connecting to whatever running on the containers through VPN, there’s probably no need to set it up
If you still want reverse proxy, synology already have a built in reverse proxy UI on top of nginx, so it is easy to set up.
This is a trade off between security and convenience.
It is more secure to only have the OpenVPN server running, then when you’re remote, you connect via VPN, then access internal resources like your docker containers. Once you are connected via VPN, you are part of your internal LAN, so you would access like you would at home. But this is slightly less convenient because you must connect via VPN to access internal network resources.
The reverse proxy approach allows you to direct external traffic to internal docker containers with HTTPS encryption (this needs setting up). That means remote users do not need to connect via VPN, making it more convenient. But this is also less secure. Although the traffic can be encrypted by HTTPS, you are still exposing your docker containers to the internet to some degree (there can be ways to reduce this), so to the extent the container has weaknesses, they may be exploitable. And if you don’t setup your containers correctly, or you accidentally misconfigured something, you would be exposed.
Generally, if you are the only remote user (or the remote users are people you trust enough to give them VPN access), then VPN is probably better unless you don’t like the extra step of connecting to VPN.
As far as I lnow, I would have to open ports 443 and 80 which is kinda dangerous.
Only if you want to expose the server.
setting up a reverse proxy in order to use things like docker containers.
It’s just a lot easier to use e.g. jellyfin.my.server instead of remembering the IP and port every time. Up to you.
Without a reverse proxy to route domains/subdomains to the internal containers/ports, you will have to expose container ports to the host. And then you have to open the firewall to expose the separate ports for each service. With a reverse proxy you only have to expose the web ports 80/443, and the proxy should do all the internal routing.
Plus, with a modern reverse proxy you can also have automated certificates (under certain conditions).
I use a reverseproxy for my public domains. I have a few public services (portfolio page, wiki, nextcloud, etc) and it’s easier to manage everything with one box to route everything together.
Many reasons:
HTTPS.
Ideally, HTTPS works like this:
Without a reverse proxy you won’t be able to host more than 1 service per port (bye bye 443), and most applications don’t even bother with HTTPS support and don’t have any functionality to deal with certificates and encryption. That’s where a proper http server with SSL support that can act as a reverse proxy, comes in and solves all of that.
Hacker protection. In case your server is feeling down, as you get attacked by many requests, you can just stop the reverse proxy, and still have your private access to the server. Proper logging will also show you what’s going on.
One place to see where all the websites exist. In case you have a docker container here, another one there, and a service running without a container, all listening to ports and doing their things, it’s easy to forget what you actually have. But in the reverse proxy config you can quickly see what exists, how you can access it, where it resides, etc. All in one place.
But honestly it’s all about that HTTPS.
I’d prefer a VPN over a reverse proxy. Generally far safer and secure. Also easier to setup and maintain. No weird, unique setups for this and that.
Personally the only thing I open a port for anymore is VPN. I don’t trust anything else.
I’m obviously missing something, but if you have OVPN set up, why not just use it to vpn into your local network? Then you’ll have access to all of your servers and only have the vpn port exposed (which needs an encryption key to get through). Or are you trying to allow other users to easily reach these services? That would be the only use case I can see for not just using WireGuard or OVPN to remote into your home LAN.
1. Create a single point of access to the file transfer server
As long as you have your firewalls and reverse proxies configured correctly, no one can directly access any file transfer server. Everyone must go through a reverse proxy. When this happens, you can focus on monitoring what is going in and out through the reverse proxy.
2. Simplify access control tasks
Since you have only one point of access, you can centralize access control on that point of access. For example, you can simply create a set of IP access rules on a reverse proxy, rather than specifying the IP addresses that are allowed to connect on each server. If the user tries to connect from an unauthorized IP, the reverse proxy can immediately terminate the attempt.
3. Move user credentials to a more secure location
Most user credentials are simply stored on the file transfer server itself. Therefore, if the file transfer server is placed on the DMZ, it can be easily caught by an aggressive attacker. By moving the server to the internal network and deploying a reverse proxy to control access, you can provide better security for these credentials and the data that is protected accordingly.
4. Reduce the risk of sensitive data
Given the extensive amount of information we regularly share with business partners, customers, and field employees, I’m pretty sure some of that information is not for public use. I’m sure you don’t want your personal information, trade secrets, prototype blueprints, payroll spreadsheets, or financial data to leak to the public or fall into the hands of others.
However, if the file transfer server is located in the DMZ, then all the confidential data stored in its hard drive will attract identity thieves, corporate spies, fraudsters, and other scammers. One way to mitigate this risk is to deploy reverse proxies.
Using reverse proxies, you will have the option to move DMZ-based file transfer servers to internal networks where they are less vulnerable to attack.
5. Help to achieve compliance
Many de facto standards and government-imposed regulations do not allow data to be stored in a highly vulnerable area, such as a DMZ. For example, PCI-DSS (Payment Card Industry - Data Security Standard) explicitly requires that credit card information be stored on an internal network isolated from the DMZ.
But what if you want to share sensitive data with an organization, such as a trading partner, that does not have access to your internal network?
One solution that complies with the regulatory requirements is to place a reverse proxy in the DMZ and allow your trading partners to connect securely to your back-end servers through that proxy. Using a special reverse proxy technique (such as a DMZ stream), you can share sensitive information with external partners even if you do not put information on the DMZ or grant direct access to a back-end server.
6. Reduce capital and operating expenses
Let’s review the questions raised in items 4 and 5 of this list. One of the traditional ways to solve these problems is to install two sets of servers. One set on the DMZ serves external clients and the other serves internal clients. The downside of this solution is that it is obviously very expensive, and because you need to manage two sets of servers, it puts an additional burden on an already overworked administrator.
If you use reverse proxies, you do not have to set up two sets of servers. All of your servers can be placed on your internal network and can serve both your internal and external clients.
7. Allow transparent maintenance of back-end servers
The changes you make to the server running behind the reverse proxy will be completely transparent to the end-user. Even if you shut down a secure file transfer server (assuming it belongs to a cluster) for maintenance, upgrade, or replacement, the end-user will not notice it.
8. Enable load balancing and failover
Reverse proxies such as Jscape MFT Gateway already support high availability approaches such as load balancing and failover. This will allow you to eliminate downtime and increase productivity. In most cases, you typically set up a cluster and add a file transfer server to it. The reverse proxy will then enforce load-balancing algorithms, such as polling, weighted polling, minimum connections, weighted minimum connections, or random numbers, to distribute the load between servers in the cluster.
When the server is shut down, the system automatically fails over to the next server, and users can continue their secure file transfer activities.
so what would be the choice of reverse proxy?
let’s limit it to docker container ones.
If you dont know, then you dont need it.
Its a solution to a specific problem/desire.
I’m a noob to all this too and have done a lot of reading the last few months. I don’t see a need for a reverse proxy to a personal server if you have a VPN set up on your devices already. It just seems to add another layer of complexity and vulnerability. Just bookmark your server and container IPs and share with all devices. I’d be grateful if anyone could point out if and why I’m wrong.
Keep in mind just because you use a reverse proxy does not mean you need to expose services to the internet, they can all be used internally with split-horizon dns, can be easier to remember than a bunch of IP:Port info.
Exposing 443 is not too dangerous, most internet traffic is handled over 443 it is also TCP so it requires a handshake versus amplify attacks are over UDP which does not.
If you plan to expose any of your services to the internet you are 100% better off using a reverse proxy with a free url from duckdns. You can also look at load balancing and fail2ban.
Keep in mind if all of your services are in a compose file using the same bridge network you can remove the docker exposed ports also, on services for me like bitwarden, nextcloud, code-server I do not have any ports exposed from the containers since swag handles them on the internal network, this lowers your threat model even more.
As far as I lnow, I would have to open ports 443 and 80 which is kinda dangerous.
Why is this dangerous?
I “had” to use it at one company i worked at that blocked anything but port 80, to be able to RDP home and then access whatever i liked.
Thanks for your explanation.
Synology offers a free DDNS (which I currently use besides the VPN).
I use Plex so I had to expose port 32400 and port 1194 for Openvpn.
I haven lots of docker containers so yeah, writing an address is definitely better than an IP.
You’re a bit confused. The majority of the features you’re describing fall under Dynamic DNS. That’s free nearly anywhere you go. Most aftermarket router software comes built in with DDNS features and as you said, you could also run an application to handle that in or out of a docker container. It doesn’t need to be on or have anything to do with a reverse proxy.
A reverse proxy can do two things really well:
Serve as an SSL offloader. All incoming traffic comes in and hits the reverse proxy, where all your SSL certs are hosted. Then it passed traffic back to your backend services, and you no longer need to use HTTPS. This can be helpful to relieve resources on your backend service, as HTTPS isn’t always easy for low resource clients.
You can handle multiple incoming requests on the same port. All traffic goes to the reverse proxy and the proxy says okay, traffic from service1.domain.com:443 goes to service1 on port 80. Service2.domain.com:443 goes to service2 on port 8080. Etc.
easy and centered certificate management
This is a big feature for me personally.