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?
Related
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 am more a C# dev than a network admin and I am not understanding what happened.
I have a website hosted on an Azure Web App and I started to get a lot of repetitive requests from IP address 172.16.5.1, to a point that it affected the web server stability
The only way I found to fix the problem is to block this IP address, but I still have questions.
1) Is blocking the IP the best solution to the problem?
2) After googling, I found that this IP address is in the range of Private IP addresses. How can a private address reach my public web server?
3) Could it be another resource from my Azure subscription that could be making these requests?...I only have a web app configured so I don't know where these requests could come from internally
4) Can this be a DDoS attack?
This IP Address is private range as you found it, but needs more information to answer your couriosity.
I could say that’s not the best solution, you need to find out which resources on your Azure that use that IP and see why it sends a request to Web App.
This is possible when your Web App connected to the Virtual Network, discuss with your Network Admin or System Architect.
I’m quiet sure that your Web App is connected to Virtual Network or could be another instance of your Web App requesting each other.
I’m not quiet sure that was an external DDoS attack.
That appears to be the default gateway for a subnet. Check the Networking blade to see if you are integrated with a VNet. I would expect that probes from something in the VNet (AppGW, Azure Firewall, NVA, etc.) would come from the instance IP of that resource and not the default gateway, but you really need to see the subnet range and know what's in there. If this is a WebApp that is integrated with a VNet via point-to-site VPN, then maybe this is something from the VNet Gateway, like Keep Alives. That might be apparent in a network trace. Blocking that IP could result in some other service marking the WebApp as unhealthy and not routing traffic to it.
Lots of conjecture here, but like Rudy said, you're not getting an external DDOS attack from a private IP.
Upon reading Azure documentation I still cannot figure out if we can design routing for our Express Route in the way described below.
We are planning to use one proxy server(with one public ip) for all O365 traffic. ( dedicated only for O365 ). Obviously, some of the O365 traffic can and should use ER, but some need to use internet (CDN, DNS, etc).
The goal is to announce proxy server ip toward ER as a /32 and toward internet as /22.
My concern is "assymetric routing" . Can this type of routing create the problem when Microsoft will send traffic to our proxy server via the ER while egress path from our AS lies via internet ?
PS. I am aware that some of the traffic should not be "proxied" or undergo DPI. Thats a security requirement.
You should not have any trouble with the configuration. Given that you are using 2 different address spaces/ CIDRs of Public IP's Provided by your ISP.
The /32 public IP will be advertised to Azure Microsoft Peering over the express route via BGP. Azure, on the other hand, Azure would advertise the Public IP's of the services that you are using. Which can be controlled via Route Filters. Note: The ASN and Public IP needs to be validated for the NAT.
Coming to the Asymmetric aspect that you are concerned about. The o365 services will not propagate the routes to other non-O365 services such as Storage/CDN/DNS.
That said, whatever is coming from the 22 CIDR will be serviced by the non-O355 service and will go over the internet.
The fear for asymmetry occurs when you are consuming the O365 services over the internet instead of consuming them over the express route. Then, there are chances of asymmetry.
Instance 1:
CIDR /22 advertised to Azure over express route and you accidentally consume the O-365 services over the internet. Since, within the O365 cloud the route is populated to use the express route, the return traffic from Azure will come over the ExR circuit. This would be labeled as asymmetric route.
I hope I have clarified your doubt about the architecture. Let me know if you have any further questions as you proceed with this configuration.
So I have setup a web app, virtual network, application gateway using this link. I also added a virtual network gateway to the vnet so that I can integrate my web app to the vnet.
Now correct me if I am wrong but isn't the purpose of integrating your web app with virtual network to make it more secure? if so then I should only be able to access my web app through the application gateway public IP correct?
Currently when I hit the the myapp.azurewebsites.net, I get to the application.
Do I have to do something extra here?
You are mixing several different things here.
Application gateway is just a proxy (more or less). It has no control over whatever server it is routing traffic to. It cannot magically make it not accept traffic not from application gateway. That is for the server to decide (in your case you need to use web.config as far as I remember to restrict incoming IP addresses only to the IP addresses of the application gateway). So adding application gateway to the mix doesnt make it more or less secure.
Vnet integration works only one way, FROM the webapp inside the Vnet. Things inside the vnet cannot talk back to the webapp using "internal" vnet traffic, they have to use external IP address. So this wont really help you.
If you want your webapp to be available only inside the VNet your best bet is App Service Environment, but its a lot more expensive :(
We've got an API micro-services infrastructure hosted on Azure VMs. Each VM will host several APIs which are separate sites running on Kestrel. All external traffic comes in through an RP (running on IIS).
We have some API's that are designed to accept external requests and some that are internal APIs only.
The internal APIs are hosted on scalesets with each scaleset VM being a replica that hosts all of the internal APIs. There is an internal load balancer(ILB)/vip in front of the scaleset. The root issue is that we have internal APIs that call other internal APIs that are hosted on the same scaleset. Ideally these calls would go to the VIP (using internal DNS) and the VIP would route to one of the machines in the scaleset. But it looks like Azure doesn't allow this...per the documentation:
You cannot access the ILB VIP from the same Virtual Machines that are being load-balanced
So how do people set this up with micro-services? I can see three ways, none of which are ideal:
Separate out the APIs to different scalesets. Not ideal as the
services are very lightweight and I don't want to triple my Azure VM
expenses.
Convert the internal LB to an external LB (add a public
IP address). Then put that LB in it's own network security
group/subnet to only allow calls from our Azure IP range. I would
expect more latency here and exposing the endpoints externally in
any way creates more attack surface area as well as more
configuration complexity.
Set up the VM to loopback if it needs a call to the ILB...meaning any requests originating from a VM will be
handled by the same VM. This defeats the purpose of micro-services
behind a VIP. An internal micro-service may be down on the same
machine for some reason and available on another...thats' the reason
we set up health probes on the ILB for each service separately. If
it just goes back to the same machine, you lose resiliency.
Any pointers on how others have approached this would be appreciated.
Thanks!
I think your problem is related to service discovery.
Load balancers are not designed for that obviously. You should consider dedicated softwares such as Eureka (which can work outside of AWS).
Service discovery makes your microservices call directly each others after being discovered.
Also take a look at client-side load balancing tools such as Ribbon.
#Cdelmas answer is awesome on Service Discovery. Please allow me to add my thoughts:
For services such as yours, you can also look into Netflix's ZUUL proxy for Server and Client side load balancing. You could even Use Histrix on top of Eureka for latency and Fault tolerance. Netflix is way ahead of the game on this.
You may also look into Consul.io product for your cause if you want to use GO language. It has a scriptable configuration for better managing your services, allows advanced security configurations and usage of non-rest endpoints. Eureka also does these but requires you add a configuration Server (Netflix Archaius, Apache Zookeeper, Spring Cloud Config), coded security and support accesses using ZUUL/Sidecar.