Building a Redundant Web Farm

I am working on a Windows Shared Hosting project at the moment, utilising WebsitePanel in a redundant IIS web farm configuration to load balance the application processing as well as make the configs and content redundant.

I have written about it a little so far, but came across Scott Forsyth’s blog yesterday which I wish I had found these videos earlier! They pretty much cover everything I have learnt so far, but also go in to storage replication with DFS (which I was going to use a horrible robocopy script to do) and more details on how everything works.

I will only be posting the videos most useful for me, but you can view the whole series on dotnetslackers.com, or via his blog.

Securing IIS. Thwarting the Hacker (Week 23)

Why You Shouldn’t Use Web Gardens in IIS (Week 24)

How to Setup an Active Directory Domain (Week 26)

DFS-R for Web Server Replication (Week 27)

IIS 7.x Shared Configuration – Advanced Tips and Tricks (Week 29)

WordPress on Windows

I currently run my WordPress site on a Windows Server with IIS. With WordPress being PHP, and I assume, design to run optimally on a LAMP infrastructure, there are a few hidden extras you need to do, in order to make use of WordPress’ full functionality.

1. WordPress Version

When you download your version of WordPress, make sure you download the version labelled “wordpress-<Version>-IIS”. I don’t actually know if there are differences in the code between the standard and IIS versions of WordPress, it mainly just looks like they add additional files:

• install.sql (MySQL deployment script)
• manifest.xml (for Windows Live Writer integration)
• parameters.xml (for Windows Web App Gallery)

To be honest, it looks like the IIS version is the version that Microsoft uses to deploy WordPress using its Web Platform Installer.

2. Permalinks

If you want to make use of a permalink structure other than the default (http://www.domain.com/?p=123), then you need to add a Web.Config file to the root directory of your WordPress content with the following:

<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="wordpress" patternSyntax="Wildcard">
<match url="*" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>

If you change your Permalink structure to Month and Name (http://blog.demongreen.co.uk/2011/05/sample-post/), then when you try and browse by Category or Tag, then you will receive a 404: File not found error.

3. Scheduled Tasks

I am still working out how to get the Google Sitemap XML plugin to automatically generate the Sitemap.xml for this site.

I also get issues when trying to schedule posts to auto-publish.

Both issues may be because there is no WGET or Cron feature in Windows, so I will have to do more research and get back to you.

IIS 7.5 with ARR and Shared Config Web Servers UPDATE

I have been trying to see if I can build a web farm at work based on IIS 7.5, utilising Microsoft’s Web Farm Framework. I did mention that I was struggling with it before, well I have got it to work.

I think I mucked around a bit too much with the first ARR server and backend web servers that I deployed, so deleted them and recreated them (using SysPrep on Hyper-VMs), and hey presto I got it working first time.

I haven’t really documented it, but essentially, install IIS and the Web Platform Installer on the ARR server and the back end servers. Install the Web Farm Framework on the ARR server and create your farm; adding the two back end web servers. The ARR server will contact the Web Platform Installer on the back end web servers and install the necessary components. Only once this is done, do you then enable the Shared Configuration on the back end web servers, because the Web Platform Installer can not install the necessary components with Shared Configuration enabled.

I will try and get more detailed notes up once I have done it myself!

IIS 7.5 with ARR and Shared Config Web Servers

I am trying to build a web farm, based on IIS 7.5, with a front end web server running the Application Request Routing module, feeding content from two backend content web servers with a Shared Configuration. The web content is hosted on a NAS device.

I can pretty much get things working with one ARR server and 1 backend content server, however the moment I add the second content server, everything goes pearshaped.

The problem seems to be the second content server losing permissions to the Shared Content share, even though it works from the get go. The moment I start adding web sites, then I get an issue.

Any help would be appreciated!

Beat Hackers At Their Own Game With A Hackerbasher Site

On any given morning, a look through my production Web server’s logs will show that my server farm is under a barrage of attacks. Hackers and crackers with automated IP port scanners can swamp a Web site with bogus requests and failed logons.

The sheer volume of this traffic can reduce response times and overload service request logs. Failed logon attempts (sometimes several hundred in a minute) can obliterate legitimate security reporting in the event viewer. Even if the hacker never gains access to anything, your Web site suffers. I use several procedures to minimize the attack surface. But even after hardening the server and putting it behind a firewall, it is still vulnerable to attacks on port 80.

How It Works

Legitimate users don’t normally go to a Web site by typing an IP address, but automated tools do. Humans use the domain name. The log files from Hackerbasher for the past two years prove this. The only nonhacker traffic to Hackerbasher has been the occasional request for an invalid URL or an unresponsive domain. I’ll explain why Hackerbasher gets these requests later.

Setting Up Your Hackerbasher

1. Open the Microsoft Management Console (MMC) with the IIS snap-in.

2. Assign one host header (or several) to each Web site there so that no virtual server is mapped to an IP address on port 80 without a host header name. Unless you have a good reason not to do so, make sure that no Web server is using “All Unassigned” IP addresses (see below).

I got the idea for Hackerbasher one morning back in 2002 while I was wading through endless IIS logs tracking a worm. I noticed that the hackers weren’t attacking the sites by their domain names but by their IP addresses. I was sure there was an automated tool out there systematically trolling through my IP pool looking for something listening on port 80. So, I thought, why not route all the IP:80 requests to a dead end in cyberspace? I then used host headers to do exactly that and called it Hackerbasher.

3. Create a Web site that points to an empty directory (preferably not on the C: drive). You can use the standard defaults in the site creation wizard and call the site whatever you want. Remember, it doesn’t need a registered domain name since it won’t be listed in any DNS servers. Also, don’t install any server extensions like FrontPage® or SharePoint®.

4. Once you have created the site, right-click on it and select Properties. Click the Directory Security tab and select Integrated Windows Authentication, then click OK. Be sure to uncheck Anonymous Access and Basic Authentication as shown in (see below).

5. On the Web Site tab, click the Advanced button. Use the Add button on the Advanced Multiple Web Site Configuration window to select each IP address that you want to assign to Hackerbasher. For me, this is all the IP addresses that are visible to the public.

6. Apply your changes and recheck your list to make sure that all your IP addresses are on it. If an IP address is already assigned to some other Web site, the MMC will give you an error message telling you there is a conflict. All you need to do is go back through the other Web site Identities and find the one(s) using an IP address on port 80 without a host header.

7. On the Web Site tab, make sure that Enable Logging is checked; I use the W3C Extended Log File Format. Next, click the Properties button next to Active log Format and the Extended Logging Properties window will open.

8. On the General Properties tab, select the log time period you prefer (I use Daily). Select the Extended Properties tab and then select the extended properties that you want to have appear in your log file. I check all of the extended properties, except Process Accounting.

In this article, I will present an easily implemented strategy that uses HTTP 1.1 host headers to divert port 80 attacks away from unsecured public Web sites into a dead end where they can’t do damage. My site, called Hackerbasher, stops the automated attack and records the details about the attack along with the IP address used by the attacker. Hackerbasher doesn’t require any special software and its only cost is the time it takes to set it up on your server. You also get the added benefit of being able to monitor port 80 attacks in a single log file.

Many of these attackers appear to be crackers/thrillseekers who simply want to break into something. Crackers usually sniff around for the obvious stuff such as unsecured databases and leftover developer sample files. Obviously, some attackers are on a mission to get in and do damage.

The IIS log files for the Hackerbasher site will now fill up with a list of IP addresses that aren’t legitimate. There are a host of programs that you can use to pull these IP addresses in a firewall or back in to an IIS plugin that will block them in future so they don’t even get to your web server.

Hardening Your Web Server

There are a number of procedures I typically follow in preparing one of my Web servers to go live on the Internet: