IIS X-Forward-For ISAPI Filter
A recent customer issue came up where they were load balancing servers but we unable to get the true client address logged in their IIS logs. They had their servers fronted by a BIG-IP and when clients would make requests the address passed to the server was the internal address and not that of the client. This is a common issue with proxies and fortunately there is a standard for forwarding client information. It is the HTTP X-Forwarded-For header which is handled by most proxies. So, I set out to find an existing ISAPI filter to replace the c-ip (client ip) log value in IIS with the contents of the X-Forwarded-For header (if it exists). I was amazed to find that I couldn't find a single instance of any open source (or even commercial) filter that would do this. So, I dug out Visual Studio and whipped up a filter that does just that. It's very basic and contains no user configuration so all you need to do is plug it into your Web Applications list of ISAPI Filters within the IIS Administration and you're set to go. We've released the source under the iControl End User License Agreement (available in any iControl SDK download). You can download it here. If you find a way to optimize this filter, please let me know and I'll update the sources here. After 24-hours of posting, a customer already returned some performance testing on the filter indicating that it only effected the traffic by less than 1 percent. I'm sure there are ways to optimize the memory allocation in the filter to speed this up a bit more, but I'll leave that for the community to work on. Oh, and it should be noted that the X-Forwarded-For header isn't supported the same way across all proxy products so you'll want to make sure you test this out before using it. It is expecting the header to only contain an IP Address as it does a straight substitution on the value in the c-ip section of the log entry. Enjoy! -JoeMicrosoft IIS (Internet Information Services)
F5 Networks solutions engineers have worked with Microsoft IIS for over a decade, finding more and more ways for the BIG-IP system to accelerate, optimize, scale, and secure Microsoft IIS deployments. Our deployment guides and iApp templates for IIS are a result of this knowledge and experience, enabling organizations to spend valuable time and resources on other projects. And not only does F5 save your time and resources, but when the BIG-IP system relieves IIS servers from tasks such as compression, caching, and SSL processing, each server is able to devote more resources to running applications and can service more user requests. The following simple, logical configuration example shows the many different options for SSL processing on the BIG-IP system available in the iApp template and deployment guides for IIS. Seehttps://f5.com/solutions/deployment-guidesto find the appropriate deployment guide for quickly and accurately configuring the BIG-IP system for Microsoft IIS. If you have any feedback on these or other F5 guides or iApp templates, leave it in the comment section below or email us at solutionsfeedback@f5.com. We use your feedback to help shape our new iApps and deployment guides.
IIS 6.0 WebDAV Buffer Overflow
Today we are reminded that old software can include new and critical security findings. Microsoft IIS 6.0 on Windows Server 2003 R2 is vulnerable to buffer overflow which leads to remote code execution. This is due to inproper validation of the If: header which is used in WebDAV. This issue is covered by CVE-2017-7269. The vulnerability is exploited by sending a malicious PROPFIND method to the vulnerable server. By default, this method is disabled on ASM. However, it is crucial for the proper function of WebDAV, so policies which protect this kind of application have probably enabled it. IIS 6.0 Despite being a 15 year old product which is not officially supported by Microsoft anymore - The web still uses IIS 6.0 in very large numbers. A search in Shodan shows that over 600k servers are still live: https://www.shodan.io/search?query=iis+6.0 Mitigation with attack signatures ASM users are encouraged to use the following attack signature to detect exploitation attempts for this vulnerability: content:"PROPFIND"; depth:8; headercontent:"If: <http://"; pcre:"/^If: <http:\/\/[^>]*?[\x80-\xFF]{5}/Hm"; This signature is due to be included in the next ASU, being released early April.
