maybe some of you know how to fix this issue.
Cloudfront + WAF + SSL-VPN
If you use split-tunneling on your VPN and the company has people access from across different regions, then example.com in the VPN endpoint would resolve into a different ip than the one for end user. Thus going around the policy setup in your firewall and not meeting requirements in WaF ( due to end user not recieving NAT ip, due to not matching policy)
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 currently have 3 traffic managers, 1 entry point for our domain, which does geolocation routing to 2 other traffic managers. One global, one for the US.
These traffic managers are priority traffic managers which point to application gateways. By having the priority traffic managers, it allow us to have a 'failover' if one site / application gateway goes down.
The reason we have a application gateway in the different countries is to allow path manipulation so if the user is from the US, they get a /us path instead of a /.
I have configured our CNAMES like www. and blog. in the application gateways for both, global and US which works fine. I can point the CNAME records to the entry traffic manager no problem.
The problem I have having is pointing the A record root domain to the traffic manager. Since traffic managers don't have IP addresses, I get an error because in Azure, the root domain can be pointed at a traffic manager, but only one that uses external endpoints using a IP Address.
Has anyone else ran into this issue and have a way to solve it?
Thanks
Adding a root/apex domain to Azure Traffic Manager should be possible as it is integrated with Azure DNS. So, you should be able to create A record to ATM as shown below from Azure DNS,
So I have a VNet in Azure, which needs to resolve names to servers back in the on-premise environment. I can set the VNet to use custom DNS servers and specify our current DNS boxes Ips.
However, whenever I do that I seem to lose the ability to resolve any Azure-based names for VMs hosted in the Azure VNet.
So I added 168.63.129.16 to the list of custom DNS servers, but not much luck. I am thinking of adding 168.63.129.16 to the existing on-premise DNS boxes so it can be used to forward Azure based request to it.
Bottom line: I need to resolve names back to on-premise but keep Azure name resolution for all VMs within the VNet. I'll be also running AAD Domain Services on the same VNet (so my custom DNS server list wil need to add the 2 extra AAD DS IPs for it,
Any other ideas?
Your DNS is not able to resolve your Azure-based servers because it doesn't know about them, and if you're moving to us AAD DS then this will get worse. You will need to either join these machines to the domain (to auto-register with DNS) or manually add entries for them.
You won't be able to split your DNS between two different systems.
I've recently configured a point to site vpn on azure.
It's working pretty well on the client and root certificate principle.
My concern is more on the security side. Would it be possible to restrict the usage of the vpn only to some ips ? For example, there are sometimes, even if people have the client certificate for any reasons, I don't want them to be able to access the azure network from another location.
The security groups come after the vpn. Due to the way the vpn is working, the ip the user will have will be the ip assigned by Azure so I can't restrict by his origin.
Thank you !
This is not a supported solution but you can apply an in-bound NSG rule to the gateway subnet that allows 443, 500 and 4500 from the IPs that you want to allow connection from and block the rest. You have to be very careful not to block any outbound ports or any other ports as that may break the management plane for the VPN Gateway.
Other option is to configure a RADIUS server and configure the appropriate policies on it and point the VPN Gateway to it.
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?