I'm looking into developing a system via Google's App Engine for PHP. I'm now pretty well underway, but realized that I don't know a good way to deny incoming traffic from countries known for their nefarious inhabitants.
On other sites, I just block subnets via .htaccess. However, I'm now beginning to think it's impossible outside of using Google's own PHP request header designating the country code.
See their doc here: https://developers.google.com/appengine/docs/php/
It would be easy to just block it that way, but I'm not sure this would be the optimal way.
Any insight would be appreciated.
You can use the dos.yaml file to blacklist subnets. You create a dos.yaml file in the root directory of your application and then block IPs or entire subnets as specified here. Note that this file is limited to a maximum of 100 entries.
Once you have a list of country subnets which you wish to block (which you could obtain from a list like this or this), you can populate the dos.yaml file manually. Alternatively, you can use a script like this one to populate the file.
In addition to the DOS attack protection mentioned in #rudolph1024's answer it is now possible to enable a fully-featured firewall (still beta, recently released) to protect your GAE application.
From App Engine firewall:
The App Engine firewall enables you to control access to your App
Engine app through a set of rules that can either allow or deny
requests from the specified ranges of IP addresses.
Create a firewall to:
Allow only traffic from within a specific network
Ensure that only a certain range of IP addresses from specific networks can access your app. For example, create rules to allow only
the range of IP addresses from within your company's private network
during your app's testing phase. You can then create and modify your
firewall rules to control the scope of access throughout your release
process, allowing only certain organizations, either within your
company or externally, to access your app as it makes it's way to
public availability.
Allow only traffic from a specific service
Ensure that all the traffic to your App Engine app is first proxied through a specific service. For example, if you use a
third-party Web Application Firewall (WAF) to proxy requests directed
at your app, you can create firewall rules to deny all requests except
those that are forwarded from your WAF.
Block abusive IP addresses
While Google Cloud Platform has many mechanisms in place to prevent the various attacks, you can use the App Engine firewall as
another mechanism to block traffic to your app from IP addresses that
present malicious intent.
You should use the App Engine firewall as your primary option for
shielding your app from denial of service attacks or similar forms of
abuse. You can blacklist IP addresses or subnets so that requests
routed from those addresses and subnets are denied before it reaches
your App Engine app.
For details about creating rules and configuring your firewall, see
Controlling App Access with Firewalls.
The firewall appears to be intended to replace the DOS protection. From Denial of service (DoS) protection service:
Tip: You should instead use the App Engine firewall for reliable protection as well as the improved features, access, and
management through the Cloud Platform Console, gcloud command-line
tool, and Admin API.
You still need to collect the IP ranges for the country in your particular case, to configure the firewall.
Related
Some of my apps are not working from some customers site, I later discovered that this was because I am using the default websites for my app hosting that is the url is myapp.azurewebsites.net which was not whitelisted on the customers firewall. The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.
If i were to create CNAME record which has a CNAME pointer to the azure default web app for example myapp.mywebsite.com points to myapp.azurewebsites.net, will this get around the issue ? Or do I need to whitelist myapp.azurewebsites.net Or its IP address that is the IP address of myapp.azurewebsites.net ?
Firstly, by default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. So, typically, anyone with the URL without any specific local network/firewall/proxy restrictions can access the WebApp URL.
As I understand, your WebApp is open to the public and only a few users (on a specific network), have trouble accessing the site. Plus, there are no access restrictions that you have implemented from the WebApp side.
Just to highlight,
Network administrators often deploy proxy servers, firewalls, or other
devices, which can help secure and give control over how users access
the internet. Rules designed to protect users can sometimes block or
slow down legitimate business-related internet traffic. This traffic
includes communications between you and Azure over the URLs listed
here.
Reference : Allow the Azure portal URLs on your firewall or proxy server
So, on case-case basis, for the affected network, you may have them add appservice.azure.com (Azure App Services) in the allowed list.
Or
As your customer performed – “The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.” have them add the URLs to allowedlist.
Or
Since IP address of your WebApp (see the reasons for the change), the best route would be for you to set up a custom domain for your WebApp.
Kindly check this doc - Tutorial: Map an existing custom DNS name to Azure App Service
The CNAME maps to the app's default hostname instead, which is less susceptible to change. | | Wildcard | *.contoso.com | CNAME record. |
-- As a side note (as indicated above), by setting up access restrictions, you can define a priority-ordered allow/deny list that controls network access to your app. Which is the opposite of your scenario, just sharing as FYI, in case you wish to know about access restrictions from WebApp side. Set up Azure App Service access restrictions
I have App Service which is classic web app written in Node.js. Let's say that my app have 2 endpoints: /SecuredEndpoint and /ClassicEndpoint. /SecuredEndpoint should be secured, meaning only certain IP addresses are allowed to access it. ClassicEndpoint on the other hand is public to whole internet.
I've found out that in Azure I can specify Access Restrictions to whole service for certain IP addresses (I can block/allow access based on IP address). But I would like to secure not the whole app but only certain endpoints.
Can someone help me how can I achieve that in Azure?
To restrict certain IP addresses is to restrict ACL in the networking layer. Access Restrictions are effectively network ACLs. However, it is implemented in the App Service front-end roles, which are upstream of the worker hosts where your code runs. In this case, you could consider selecting to use two app services for each endpoint. You can read supported security in the Azure app service.
Alternatively, you may allow certain IP addresses in your special code. Google some samples for such a feature. It might be like this SO thread. For App Service on Windows, you can also restrict IP addresses dynamically by configuring the web.config. For more information, see Dynamic IP Security.
In addition, If you are interested in securing Back-end App Service Web Apps with VNets and Service Endpoints, you could have a look at this blog.
Given that I create an Azure 'App Service'
How do I ensure that this service is only callable from ...
A.> 2 existing external servers (whose IP addresses will be known)
B.> 3 other App Services which I will be creating, but whose IP Addresses may not be known since I may need to scale those out (Over multiple additional instances)
To clarify... Is there some Azure service that will allow me to treat this collective of machines (both real and virtual) as a single group, such that I can apply some test on incoming requests to see if they originate from this group?
on Azure WebApps, You may wish to know; the IP Restrictions (https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions) allow you to define a list of IP addresses that are allowed to access your app. The allow list can include individual IP addresses or a range of IP addresses defined by a subnet mask. When a request to the app is generated from a client, the IP address is evaluated against the allow list. If the IP address is not in the list, the app replies with an HTTP 403 status code.
You can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to in your websites. With Azure WebApps you can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Additionally, VNET Integration gives your web app access to resources in your virtual network but does not grant private access to your web app from the virtual network. Private site access is only available with an ASE configured with an Internal Load Balancer (ILB).
If you haven’t checked this already, checkout Integrate your app with an Azure Virtual Network for more details on VNET Integration (https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet)
I strongly suggest dropping the whole what's my IP approach and throwing in OAuth. Azure AD gives you access tokens with moderate effort —
Service to service calls using client credentials (shared secret or certificate)
Else, TLS client authentication would be next on my list. Although that tends to really suck if you have to deal with several programming stacks, TLS offloaders and what not.
I have a Azure Traffic Manager over a geo distributed cloud service. I need to lock down my cloud services which are primarily web apis so that they are accessible to only a certain range or IP ADDRESSES. Is there a way to achieve this? Or may be there are ways to restrict IP addresses on cloud services. But with a combination of traffic manager on top of that would that work?Does traffic manager flow the source ip address to the cloud services?
Traffic Manager cannot filter traffic. It just responds to DNS queries from clients.
The source IP address will be the original one because the traffic doesn't go through Traffic Manager, it only tells the caller where to go, and the caller then calls your service directly.
Late to the party but: if you ended up using a whitelist on for example an Azure App Service than you will need to add the addresses of Traffic Manager as well. Otherwise Traffic Manager will not be able to check the health of your App and report it as degraded.
You can find it here: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#traffic-manager-endpoint-monitoring
Direct link: https://azuretrafficmanagerdata.blob.core.windows.net/probes/azure/probe-ip-ranges.json
Also late to the party but we were restricting our App Services by IP address and all of a sudden our traffic managers started to display degraded after working fine for years. After lots of investigation we think that Azure added some new traffic managers that were on different IP addresses so they were getting blocked by our IP restrictions. The original restrictions had included a small range of IP addresses for the traffic manager but this list looks like its expanded. The best solution is to allow the traffic manager through, not based on its IP address buts its service tag as below :
I want to provide failover proof url for my service endpoint to users using traffic management. I have a service instance running at http://vm1.cloudapp.net/myservice:8888/index.html. If this instance goes down then the service auto starts on vm2 at http://vm2.cloudapp.net/myservice:8888/index.html n vice versa.
I want azure to hide the underlying service urls to user and expose the service at http://myservice.trafficmanager.net
Is this possible? If so, how ? From reading the documentation of traffic manager service, it looks like you can failover only at DNS level and not at url endpoint level
There are several parts to this.
Firstly, you are right that Traffic Manager works at the DNS level. It doesn't see your HTTP traffic and hence doesn't see the full URL. Since your two services instances have different DNS names, there's no issue here--you configure Traffic Manager with both names as separate 'endpoints', and Traffic Manager will direct traffic to those endpoints by providing one or other in each DNS response.
Secondly, you want to hide the URL paths. Since Traffic Manager works at the DNS level, it doesn't see your HTTP traffic and hence doesn't see the URL, only the domain name. Therefore this is something you have to handle at the application level (just as you would for a single-instance service that doesn't use Traffic Manager).
The only thing to be careful of is to make sure you configure the correct URL port and path in the Traffic Manager endpoint monitoring configuration. Just make sure that Traffic Manager shows your endpoints as 'Online', and you're good.
Jonathan