Using proxies is a long-established technique in network security. Most people encounter them in the form of forward proxies, for example VPN services designed to hide an IP from a server to access geo-restricted content. That way, the server sees the VPN server’s IP address rather than the client’s. But this becomes a problem if you're apply Active Directory access controls based on IP address. Here's how UserLock solves this problem to identify the true client IP.

An IP proxy server stands between you and the internet. It's there to keep you safe from any danger you might run into on the wild web. In other words, it separates you from and keeps your identity private on the websites you browse.

Often, organizations use reverse proxies, designed to shield externally facing servers such as web servers from attacks or to implement load balancing.

For any publicly accessible web server, both functions are essential as a way of dynamically distributing traffic across multiple servers and to block malicious traffic before it reaches the server.

From the attacker’s point of view, a defender using a proxy in this way means that the internal identity and IP address of a server is no longer visible, making it a much smaller target.

However, a complication is that proxies have the effect of hiding a client’s true IP address behind the proxy’s IP address, which makes it more difficult to apply security policies to them on an individual basis.

For admins, the most important number in networking is always an IP address. It is used to identify and log individual devices or clients as they connect, as a way of routing packets between networks, and to monitor and control access to wider network resources.

Over time, the latter function — monitoring, control and logging — has become more significant. Today, when an admin wants to understand what is happening on their network, the first piece of information they will look for is a log containing IP addresses and the connections made by them.

Anything that compromises the ability to see a client’s true IP address risks creating problems for security solutions, including an identity and access management (IAM) software such as UserLock. It’s an example of how implementing security in one layer can make life harder in others. Thankfully, with UserLock, it doesn't have to be that way.

Microsoft’s Internet Information Services (IIS) web platform offers a good example. As a server, IIS is unusual. Most servers are internal resources that should only be reachable from outside the network via a firewalled channel such as a VPN. IIS, by contrast, can also be configured to serve both internal Intranet and external web users at the same time via HTTPS, a feature which ups the stakes when it comes to security.

That’s why a proxy of some kind will always be used to secure an IIS network, especially those open to external traffic. But doing so means that your access security solution can no longer see the IPs of clients connecting from outside the network, on the other side of the proxy. This often limits the ability to accurately log users and apply access control restrictions, such as geo-location or restrictions based on IP address.

Fortunately, the X-Forwarded-For (XFF) HTTP header offers a standardized way around this that allows the true IP address to be forwarded through the proxy. With XFF enabled in the proxy, all admins need to do is to add the proxy’s IP address in the advanced setting of the UserLock IISProxyList. That allows UserLock to capture true client IP addresses while distinguishing them from the IP of the proxy.

One approach to proxying IIS is simply to use the proxy functions built into IIS itself.  Behind the scenes, IIS comprises several modules, with proxy functions such as load balancing and security handled by Application Request Routing (ARR). Using this, admins can make client IP addresses visible to UserLock through XFF by configuring the preserve client IP in the following header setting.

UserLock must also know how to identify client IP addresses passed to it through the proxy. Assuming that XFF has first been configured in IIS, this is done by entering the proxy’s IP address in UserLock’s advanced settings IisProxyList. This allows UserLock to distinguish clients from the proxy itself (see UserLock guidance).

A caveat in all this is that external IP addresses can easily be spoofed, including those passed through a proxy using XFF. There is no single solution to this problem although implementing IIS header manipulation detection in IIS or using a web application firewall (WAF), intrusion detection system, or a firewall in front of the proxy are ways to address the issue.