I'm trying to learn about why reverse proxy servers are useful. I just read...
Security and anonymity – By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.
https://www.nginx.com/resources/glossary/reverse-proxy-server/
Why is it helpful that the identity of your backend servers are hidden? Couldn't one just still attack them through the reverse proxy server like how any normal client visiting the app would access them?
You can fine-tune the access restrictions for every request, apply rate-limiting and load-balancing so a possible attack may not bring down your whole infrastructure. Especially the load-balancing aspect is key. Additionally, the only server visible to the internet is the reverse proxy, so it's not a trivial task to map your entire server structure as it would be if you exposed them all.
A common use-case is setting the reverse proxy up as the SSL gateway so you can communicate via HTTP behind the firewall. Failover for non-responding servers is also possible. Adding additional servers to the setup is trivial this way.
Apart from this, the immediate benefit is a centralized setup that you don't have to replicate for all the servers behind the firewall. Also, a reverse proxy enables you to expose only HTTP/HTTPS port for one external IP address but have multiple services running with local IPs you can route wherever you want.
Please note that this question likely belongs on Server Fault since it's related to network and server infrastructure.
“A reverse proxy can hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them. You can place your reverse proxy in an internet facing DMZ, but hide your web servers inside a non-public subnet.” [ 1 ]
“By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.” [ 2 ]
There is a question related to this topic here.
Hope it helps
Related
Halo, i’m a dev recently diving into cloudflare security layers and got few questions on a website security which is deployed to cloudflare. I’m using Pages and my domain is directly hosted by cloudflare Registrar. I’m also using the security layers provided with cloudflare infrastructure, including [ Bots, DDos, Settings, Page Shield ], which can be found in security tab of my domain in cloudflare dashboard. Below list is my questions:
security layers in use: [ Bots, DDos, Settings, Page Shield ]
I’m using firebase hosting to link my firebase functions with the domain which is hosted by cloudflare. In this case, do the above listed security layers of cloudflare automatically protect the firebase hosting resources or traffics?
I’m using cloudflare workers to manage Durable Objects. The Workers’ functions are also linked to the same root domain with different subdomain. In this case, do the above listed security layers of cloudflare automatically protect the Worker traffics?
the proxy status of firebase hosting connection is “DNS only” mode(not “Proxied” mode), since in the case of Proxied, the dns connection does not work(i didn't figure out the reason yet..). In this case, it makes me feel like the firebase hosting resources are not being protected since the orange switch in DNS dash is turned off
please consider the cloudflare plan is Pro
Thank you in advance [:
For the products you are listing, Cloudflare is implemented as a reverse proxy.
This means that from an end user perspective, when they try to connect to your services, their traffic reaches Cloudflare first (since a proxied record resolves to a Cloudflare anycast IP). Cloudflare carries out the features and security services that are configured, then forwards the HTTP requests to your origin infrastructure as specified in your Cloudflare DNS tab. This is true when the traffic is directed to proxied records.
For records in DNS-only mode, Cloudflare only performs DNS resolution (answering to the DNS query for that DNS record). Once this is done, the client will connect directly to the specified resource and the traffic will not be flowing through the Cloudflare network, meaning Cloudflare cannot provide proxy services in this scenario.
For a full explanation, I recommend the following documentation page
I am struggling to have a simple service acting as a reverse proxy in Azure.
I need it because the API that I want to communicate with uses IP whitelisting. That's why I want to set up a reverse proxy service with a static IP. My application (whose IP is cannot be static) would communicate with the target API via the reverse proxy.
With some research I found the following options:
Creating a Web App with some custom IIS config - I'm not sure if that's still valid, because the guides I found are pretty old
API Management - that seems pretty heavy and I've heard it's not going to be easy to configure
Application Gateway - that requires a VNet, which I do not even need.
Azure Function with Proxy - I think that option is no longer available with Functions V4. What's more, I would have to also set up NAT Gateway to have a single outbound IP. That seems overly complicated.
Creating a custom Web App with code that does the proxy logic
All these options seem to be too complicated for a simple task that I need. Basically, I want to have public reverse proxy, when I hit https://my-reverse-proxy.com/*, the proxy would return data from https://my-whitelisted-api.com/*.
Is there any easier alternative?
Most of the Azure services where you host your app has a single outbound ip or a range of outbound ip-addresses that can be whitelisted, but it's hard to know if that works in your case as you did not mention in what Azure service you host your app.
A generic solution could be that you provision an Nginx proxy in Azure Container Apps. Then you will will have the Container Apps Environment public ip address as outbound ip to whitelist. Beware though that anyone can call your proxy from any ip, which means that you are completely disabling the protection they put in place by whitelisting ips and opening up their API to the whole world. So without knowing your circumstances, this would probably not be recommended.
We currently have VM environment setup with an internal network and a DMZ network. Historically we had no open ports between these environments, but needs arose for communication between the internet and services/APIs running on our internal servers.
We decided to use our DMZ network as a proxy/gateway, where we specifically use Kong Gateway, exposing ports 80/443 to the internet, and then proxying/forwarding requests through a different port opened up between the DMZ server and the specific internal server that needs to handle this communication. A random, non-standard, high port is being used for all requests between the DMZ server and our internal network, and we then use a reverse proxy on our internal server to route specific request via hostnames to specific APIs/services on the internal server.
Now, we're in the process of converting our internal environment to a k8s cluster, and I'm interested in knowing if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server. But my networking and security knowledge is not good enough to say if this is actually true, and it just provides a false sense of extra security, in which case, we'd have the exact same level of security with exposing those same ports directly on our internal k8s cluster, while simplifying the overall infrastructure.
if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
You probably want a "Gateway" outside the cluster, with a static IP-address. The nodes in the cluster are more dynamic, you want to throw away the old and create new when upgrading e.g. the linux kernel.
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server.
The book Zero Trust Networks is good about this. Things has changed, the older way of using "DMZ" to protect internal networks, called "perimeter security" is now replaced with a "Zero Trust Networking" model. Now every host (or Pod) should be responsible for its security, on Kubernetes, to get this hardened, you can use a "Service Mesh" to implement mutual TLS between all services, see e.g. istio.
I have a server (that I don't control, but on my network) that uses unsecured web sockets to communicate. Rather than allow communication directly with that server from outside the network, I'm wanting to set up a secure proxy that uses secured web sockets to receive the requests from outside the network, and then forward those on to the real server within the network. That way, the unsecure traffic never leaves the network and any communication with outside the network is done via the secured proxy.
What would be the best way of achieving this?
If you're talking about having the internal communication still over regular HTTP, but only have communication to the external world over HTTPS, then this is a common practice. HAProxy supports this, and the general term is called "Terminating SSL" or "Terminating TLS".
You can read more about it here: TLS termination proxy
We have a cisco load balancer on-premise which routes traffic to our DMZ Servers on-premise
We want to use Azure Load Balancer or Azure Solutions (AG) which can balance traffic to our DMZ Servers on-premise, basically replace the CISCO with Azure
Is it possible? we have SFT/HTTPS sites currently hosted on our DMZ Environment.
TIA
What you're proposing isn't the use-case for Application Gateways. Application Gateways are Layer 7 load balancers / reverse proxies. What you want to do is almost treat them as a one-site forward proxy. It's not a good architecture and even if it were possible would ultimately be more costly in the long-run since you would pay for data egress as your App Gateway accepts requests and then forwards on to your web servers via an outbound connection over the Internet. They then receive the response headers/body from your web servers and again send that result on to the original caller.
In that scenario, you are forced to have to use end-to-end SSL for your applications, removing any possibility of using the App Gateway for SSL offload in the future. If your traffic isn't encrypted or doesn't need to be, the predictability of the source and destination of your traffic increases the security risk to your website's users and your company.
You also have the possible security implications of this type of architecture. Your web servers still need to be accessible at the very least by your Application Gateway, which means they are either freely available on the Internet anyway (in which case why bother with an App Gateways at all) or they're firewalled at a single layer and permit only traffic from the source IP address of your Application Gateway.
The bad news with the firewall approach is that you cannot assign a static public IP address to an Application Gateway, it is forced as Dynamic. Realistically the public IP won't change until the App Gateways are rebooted but you should know that when, not if, they do, your firewall rules will be wrong and your App Gateways won't be able to get to your DMZ servers any more, which means an outage. The only true solution for that is a firewall that can do URI based firewall rules...the impact there is cost (time and CPU) to perform a DNS lookup, see if the traffic is from the App Gateway by its DNS address - something like bd8f86bb-5d5a-4498-bc0c-e1a48b3873bf.cloudapp.net and then either permit or deny the request.
As discussed above, a further security consideration is that your traffic will be fairly consistently originating from one location (the App Gateways) and arriving at your DMZ. If there's a well defined source of traffic, that fact could be used in an attack against your servers/DMZ. While I'm sure attacking this is non-trivial, you damage your security posture by making source and destination traffic predictable across the Internet.
I've configured a good number of Application Gateways now for Enterprise applications and out of morbid curiosity I had a go at configuring a very basic one using HTTP to do what you're attempting - fortunately (yes, fortunately) I received an HTTP 502 so I'm going say that this isn't possible. I'll add that I'm glad it isn't possible because it's a Bad Idea (TM).
My suggestion is that you either migrate your DMZ servers to Azure (for the best performance/network latency) or implement a VPN or (preferably) ExpressRoute. You'll then be able to deploy an Application Gateway using the correct architecture where you terminate your users' connections at the App Gateway and that re-transmits the request within your RFC1918 network to your DMZ servers which respond within the network back to the App Gateway and ultimately back to the requestor.
Sorry it's not what you wanted to hear. If you're determined to do this, perhaps nginx could be made to?