I have setup the Secure Gateway to connect to my on premises DataPower and have exposed a local SOAP service. In the destination I have enabled User Authentication for mutual auth, and this is working well. In order to access the SOAP service the client must supply the cert. However this endpoint is still public, and I would prefer to restrict the network access to it for increased security.
I found this article:
Creating IP table rules for a Bluemix app for Secure Gateway
that shows how to implement this from a client such as NodeJS or WSL, however I want to restrict access to only API Connect in Bluemix. Thus I don't have the ability to lookup the IP address.
Is there an address range for the API Connect Gateway Clusters? I tried restricting the network to only the non-routable A/B/C networks but that closed off everything. Using mutual auth in the TLS Profile of APIC is working, but restricting the network would give us greater peice of mind.
This is not possible due to the nature of cloud-based solutions. IP addresses may change at any time, thus breaking the linkage.
Mutual TLS is an excellent solution and should provide robust security as long as your private keys are carefully protected.
Related
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.
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.
Hello I've been searching everywhere and did not found a solution to my problem, which is how can I access my API through the gateway configured endpoint only, currently I can access to my api using localhost:9000, and localhost:8000 which is the Kong gateway port, that I secured and configured, but what's the point of using this gateway if the initial port is still accessible.
Thus I am wondering is there a way to disable the 9000 port and only access to my API with KONG.
Firewalls / security groups (in cloud), private (virtual) networks and multiple network adapters are usually used to differentiate public vs private network access. Cloud vendors (AWS, Azure, etc) and hosting infrastructures usually have such mechanisms built in, e.g. Kubernetes, Cloud Foundry etc.
In a productive environment Kong's external endpoint would run with public network access and all the service endpoints in a private network.
You are currently running everything locally on a single machine/network, so your best option is probably to use a firewall to restrict access by ports.
Additionally, it is possible to configure separate roles for multiple Kong nodes - one (or more) can be "control plane" nodes that only you can access, and that are used to set and review Kong's configuration, access metrics, etc.
One (or more) other Kong nodes can be "data plane" nodes that accept and route API proxy traffic - but that doesn't accept any Kong Admin API commands. See https://konghq.com/blog/separating-data-control-planes/ for more details.
Thanks for the answers they give a different perspectives, but since I have a scalla/play microservice, I added a special Playframework built-in http filter in my application.conf and then allowing only the Kong gateway, now when trying to access my application by localhost:9000 I get denied, and that's absolutely what I was looking for.
hope this answer gonna be helpful for future persons in this same situation.
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.
From Bluemix I want to access an application in a customers data center using Secure Gateway service. I also want to give access to the destination (the customer application) to the Bluemix application only.
In the Secure Gateway dashboard under Advanced options of the gateway or the destination definition is a Network option where I can specify an IP address or address range plus port or port range. The help text says: "Set this destination to private to only allow access from specific IPs and ports." This is exactly what I am looking for.
But: How can I use this with a Bluemix app? I don't know the IP address of the Bluemix app. I am aware that I can figure it out but it is not static, the moment I stop and restart an app on Bluemix, the IP address may change. So this setting of the Network option would have to be done by some API call from the Bluemix application itself. Is this possible?
If not, why have this function at all?
The cloud application will use the "cap-sg-prd-<#>.integration.ibmcloud.com" hostname and the port they were given to connect into the cloud service. The client uses the destination configuration, which is downloaded to the client, to perform the backend, on-premises connection to their on-premises resource. So only their cloud application need to know about the cap-sg*/port number, all other connectivity is taken care by using the already established SecureGateway client connection.
In the form for the IP address you can also specify hostnames. You could try to provide the hostname of your Bluemix app. In my tests I did not succeed and had the entire connections cut off. Thus I cannot recommend trying to restrict connections right now.
By binding your Secure Gateway to the app or, even better, utilizing user-provided services to bind a database to an app you can leave the connection information internal to Bluemix. Here is a blog post with steps for user-provided services and on github is a demo for on-premise database integration utilizing the user-provided services and the Secure Gateway.
The hint regarding hostnames can be found in the Bluemix documentation for the Secure Gateway. The information about the Secure Gateway in the Knowledge Center is shy about it.