Windows Azure Pack: Web Sites Security Enhancements

  • Article

 

Applies To: Windows Azure Pack

After installation, you can enhance your security by implementing additional best practices. These include configuring IP filtering (also known as "blacklisting"), setting quotas to counter DoS attacks, and other steps.

Configure IP filtering

Setting an IP filter is very important because one of the easiest ways to launch a denial of service (DoS) attack is to launch the attack from inside the service itself. Therefore, at minimum, the hosting service provider should blacklist the farm from itself.

For example, if the web farm is deployed to a subnet, then the subnet IP addresses should be filtered to prevent web sites from calling back into the farm and launching (for example) a DoS attack.

To restrict tenant worker processes from accessing the IP address ranges corresponding to servers inside the Web Site cloud, you can configure IP filtering either in the Windows Azure Pack management portal or by using PowerShell.

To configure IP filtering in the Management Portal

To configure IP filtering in the Management Portal for Administrators, perform the following steps:

  1. In the left pane of the portal, choose Web Site Clouds.

  2. Select the web site cloud that you want to configure.

  3. Choose Block List.

  4. In the command bar at the bottom of the portal, choose Add.

  5. In the Enter an IP Address Range dialog, enter an IP address in the Start Address and End Address boxes to create the range.

  6. Click the check mark to complete the operation.

To configure IP filtering by using PowerShell

To configure IP filtering by using PowerShell, run the following PowerShell cmdlets on the controller. Replace <start-of-ip-blacklist-range> and <end-of-ip-blacklist-range> with valid IP addresses.

Add-pssnapin WebHostingSnapin
Set-Hostingconfiguration -WorkerRegKeyRejectPrivateAddresses 1
Set-Hostingconfiguration –WorkerRegKeyPrivateAddressRange <start-of-ip-blacklist-range>, <end-of-ip-blacklist-range>

Restart the Dynamic WAS Service

Finally, restart the Dynamic WAS Service (DWASSVC) on servers configured to run the web worker role. Run the following commands from an elevated command prompt:

net stop dwassvc
net start dwassvc

Set Quotas

To prevent Denial of Service (DoS) attacks, you should set quotas on CPU, memory, bandwidth and disk usage. These quotas can be configured in the Management Portal for Administrators as part of plan authoring.

When a plan has these quotas set and a web site belonging to the plan suffers a DoS attack or an inadvertent CPU spike, the web site will be stopped when the quotas are reached, thus stopping the attack.

The quotas mentioned are also helpful against attacks originating from within the farm. For example, a brute password attack from within the farm would consume a lot of CPU time and, assuming strong passwords are used, the CPU quota would be reached before the password could be broken.

Assign a separate set of credentials for each Web Sites role

As a security best practice after installation, you should edit the credential sets for the Web Server roles so that they are all unique. After creating new, unique accounts, you can update the credentials in the Management Portal for Administrators to use the new accounts.

To edit Web Sites server role credentials

  1. In the Management Portal for Administrators, click Web Site Clouds, and then choose the cloud that you want to configure.

  2. Click Credentials. Under User Name, you can verify whether the user names are unique among the Web Site roles (for example, they might all be 'Administrator', in which case they should be changed).

  3. Select one of the credential names (for example, Management Server Credential), and then click Edit in the command bar at the bottom of the portal.

  4. In the dialog box that appears (for example, Update Management Server Credential), provide a new user name and password.

  5. Click the checkmark to complete the operation.

  6. Repeat steps 3 through 5 until all credential sets are unique.

Change ("roll") credentials on a regular basis

As a security best practice, it is a good idea to change (or "roll") credentials on a regular basis. For the role services, it’s better to change both user name and password at the same time, not just the password. Changing both the user name and password avoids the "out of sync" problem that can occur when only the password is changed, but the change hasn’t been propagated completely throughout the environment.

When you change both username and password, both sets of credentials are temporarily available during the rollover process. For example, two disconnected systems that need to authenticate can still connect after the change. When the new credentials are in place and fully functioning on all systems, you can disable the old set.

Define a restrictive trust profile for .NET applications

For .NET applications, you should define a restrictive trust profile. By default, Windows Azure Pack: Web Sites runs in Full Trust mode to provide the broadest application compatibility possible. Choosing the optimal trust level involves a security versus compatibility tradeoff. Because each usage scenario is different, you should determine and follow your own best practices in securing the multi-tenant web servers in your environment.

Other Best Practices

Other Best Practices include using the principle of least privilege when creating user accounts, minimizing your network surface area, and modifying system ACLs to protect your file system and registry.

When creating accounts, use the principle of least privilege

When you create user accounts, apply the principle of least privilege to them. For more information, see Applying the Principle of Least Privilege to User Accounts on Windows.

Minimize your network surface area

Configure your firewall to minimize network surface area on internet facing servers. For information on Windows Firewall with Advanced Security, see the following resources (the references for Windows Server 2008 R2 are still useful for Windows Server 2012 and Windows Server 2012 R2).

Modify system ACLs to secure the file system and registry

The following downloadable utilities can help evaluate a server’s file system and registry security settings.

See Also

Deploy Windows Azure Pack: Web Sites