This is a continuation of previous articles on IaC shortcomings and resolutions. In this section, we discuss the IP restrictions between sender and receiver in cloud resources. Let us take the example of an application gateway and app services behind the gateway.  As a layer 7 resource, http proxy and http request rewrite capabilities, the gateway routes traffic by path to different app services. These app services can allow promiscuous web traffic or specify origin ip restrictions via ip restriction rules. With the rules specifying origin as gateway, there is some hardening but there is no restrictions to who the caller are behind the gateway and app services have the potential to determine that as well.

This is where some co-operation is needed between the application gateway and the app services. The gateway automatically adds additional headers to indicate the source ip of the traffic. The app services would have a rule for the gateway indicating the source ip block for the gateway typically in an ip-address-with-/32 prefix notation and additional filters for matching the values of anticipated source ip ranges behind the gateway. There are four headers in all out of which the x_forwarded_host and x_forwarded_for bear the hostnames and the ip ranges. 

The x_forwarded_host seldom works when the gateway hostname is specified. This is not a shortcoming but header is used to identify the original host requested by the client in the Host HTTP request header and since name to ip resolutions might involve several layers of resolution, the values specified in the header for the clients might not agree. It is useful in the case where the reverse proxies such as load balancers or CDNs are involved, the host names and ports may differ from the origin server handling the request. With SSL termination, the source IP becomes that of the gateway and so this header preserves the original url’s location. Leaving this header blank and using the other header works in most deployments.

The X-Forwarded-For header provides information about the client’s IP address (or a chain of proxy IP addresses) that initiated the request. When requests pass through multiple proxies or load balancers, each proxy adds its own IP address to the X-Forwarded-For header. Azure App Services can use this header to determine the original client IP address, even if the request came through intermediate proxies. Specifying the CIDR for IP ranges in a comma separated string works in most deployments to match the clients with the requests and allow them selectively through the gateway’s firehose traffic.

Together with source ip restrictions, these headers enable sufficient hardening to the web traffic at the app service.