Application Proxies are a very sensitive point in the organization, being the gatekeepers for most of the organization sensitive applications. Not only they are exposed to the Internet, they are also well known entry points. This is why we take security very seriously. In fact, this was one of the reasons we decided to build both Web Application Proxy and Azure Active Directory Application Proxy from scratch with a fresh code base.
Here are some security measures that apply to both solutions:
The best method to keep the bad guys out and protect your applications from various application attacks is implementing preauthentication. It means that users can access the application only after they were authenticated. The main role of the proxy is to enforce this preauthentication. This puts a very high bar on most attacks and is a strong mitigation for distributed denial of service (DDoS) attacks impact on the applications. In case DDoS attacks happen, only the authentication service that is dedicated for external users is bombarded, and the backed applications are not impacted.
A proxy, by its nature, protects the backend application from various attacks just by terminating the external SSL and HTTP session and starting another one with the backend application. This practice eliminates all layer 2 and 3 attacks. A recent example for such attack is the Heartbleed bug that exposed all applications running a specific SSL stack to attacks that read server memory by sending wrong data in the SSL protocol. If such application is protected by a proxy, this illegal request will never reach its server as the proxy will drop such SSL sessions.
It also ensures that the HTTP request is validated and well-formed before the request is passed to the published server.
The first step in good security practices is to reduce the attack surface. For us this means that we are exposing to the internet only to the bare minimum that is required to provide a service.
In Web Application Proxy, we are doing this by running the proxy directly on top of Windows HTTP.SYS layer and utilizing its capabilities to assure that all other traffic will be filtered by the Windows networking stack. We instruct HTTP.SYS to accept only traffic to the very specific URLs that are published. For example, if the admin decided to publish with external URL https://sp.contoso.com/site3 requests to other paths of this domain or to other domains will be filtered by HTTP.SYS and will not arrive to the proxy.
When the Azure Active Directory Application Proxy is used, all these requests to unpublished resources are filtered on our cloud service and will never reach your corporate network.
As another layer of protection, the proxy that is exposed to the internet runs the on-prem components in the context of an account called “network service”, which has very few privileges. This assures that even if an attacker somehow manage to run code in the context of the proxy service in Web Application Proxy or the Azure AD Application Proxy connector, it will have very little impact on the machine. This is why Web Application proxy is composed of two different services, one that is exposed to the internet and has very limited privileges and another one that is not exposed to the internet and performs actions that require more privileges like updating configuration or listening for a new URL.
An important security measure that is used to reduce the impact of attacker that gains full access to the proxy or connector machines is to make sure that it does not store passwords, not on the disk and not in memory. This is very different than the security practices of the past where edge components stored passwords in memory and in many cases also on the disk. The Application Proxies can achieve this because of the separation between the proxy functionality and the authentication and authorization that are done on AD FS and Azure AD.
Other than the issues described above there are hundreds of less prominent techniques and guidelines that we used when we developed the application proxies to assure security. Most of them derive from Microsoft Security Development Lifecycle (SDL), a process and framework that is used in Microsoft to develop more secure products and to share the experience we gain. The SDL Web site contain many more details on the value gained by using this practices.
Azure Active Directory Application Proxy takes security to the cloud scale. Its security model is even more robust than the traditional on-premises model. There is no traffic that is inbound to the organization. Everything is sent to the cloud. This means that all filtering and protection occurs in the cloud, only authenticated and valid traffic arrives to the corpnet.
Other than the benefit of keeping the bad traffic off the corpnet, the cloud approach also has the advantage of large and elastic scaling. It is one thing to knock down two machines on the DMZ with DDoS attack but it is a completely different story to knock down Azure Active Directory service that runs in much bigger scale. This again provides a strong level of protection for the published on-premise services and infrastructure.
Another benefit of the cloud is the ability to quickly update in case of vulnerability. We make sure that the cloud service is running on the most up-to-date networking stack and it is patched immediately if something is detected. All of this happens behind the scenes so there is absolutely no effort needed from the organization.
For more information on Azure Active Directory Application Proxy please see the following link: http://msdn.microsoft.com/en-us/library/azure/dn768219.aspx
Hiya. One thing that's missing in Windows Server 2012 R2 is the Security Configuration Wizard - or rather, it's there, but has not had any updates in a very long time, so it isn't really usable anymore. I've identified about 60 services that can be turned
off when hardening a WAP server, so the lack of wizard support for this is a real loss. I put some longer-form thoughts on this on the Geneva forum a while back, if you're interested.