DotNetPanel S&M Blog

Dynamic IP Restrictions Extension for IIS

A long waited tool has been released by iis team.

Check it out at http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1826

Overview

The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.

Features

• Seamless integration into IIS 7.0 Manager.
• Dynamically blocking of requests from IP address based on either of the following criteria:
  • The number of concurrent requests.
  • The number of requests over a period of time.
• Support for static list of IPs that are permanently denied or allowed access to the Web Site.
• Support for static list of Domain Names that are permanently denied or allowed access to the Web Site.
• Blocking of requests can be configurable at the Web Site or Web Server level.
• Configurable deny actions allows IT Administrators to specify what response would be returned to the client. The module support return status codes 403, 404 or blocking the requests entirely.
• Logging of denied requests in W3C format.
• Real-time display of currently blocked IP Addresses by using IIS Manager.
• Support for IPv6 addresses.

Benefits

Reduce the chances of a Denial of Service attack by dynamically blocking requests from malicious IP addresses

Dynamic IP Restrictions for IIS allows you to reduce the probabilities of your Web Server being subject to a Denial of Service attack by inspecting the source IP of the requests and identifying patterns that could signal an attack. When an attack pattern is detected, the module will place the offending IP in a temporary deny list and will avoid responding to the requests for a predetermined amount of time.

Minimize the possibilities of Brute-force-cracking of the passwords of your Web Server

Dynamic IP Restrictions for IIS is able to detect requests patterns that indicate the passwords of the Web Server are attempted to be decoded. The module will place the offending IP on a list of servers that are denied access for a predetermined amount of time. In situations where the authentication is done against an Active Directory Services (ADS) the module is able to maintain the availability of the Web Server by avoiding having to issue authentication challenges to ADS.

Maintain static lists containing IPs or domains that are begin denied to access the Web Server

Dynamic IP Restrictions for IIS maintains support for the functionality already provided by IPv4 Address and Domain Restrictions in IIS 7.0, thus allowing IT Administrators to build and use a static list of IP addresses and Domain Names that are denied or granted access.

Requirements

• Windows Server 2008 or Windows Vista SP1
• Internet Information Services 7.0 must be installed

Windows Installer for PHP 5.2.9 RC and PHP 5.3 Beta

Cross-Site Scripting in ASP.NET

Cross-site scripting attacks exploit vulnerabilities in Web page validation by injecting client-side script code. The script code embeds itself in response data, which is sent back to an unsuspecting user. The user's browser then runs the script code. Because the browser downloads the script code from a trusted site, the browser has no way of recognizing that the code is not legitimate, and Microsoft Internet Explorer security zones provide no defense. Cross-site scripting attacks also work over HTTP and HTTPS (SSL) connections.

One of the most serious examples of a cross-site scripting attack occurs when an attacker writes script to retrieve the authentication cookie that provides access to a trusted site and then posts the cookie to a Web address known to the attacker. This enables the attacker to spoof the legitimate user's identity and gain illicit access to the Web site.

Common vulnerabilities that make your Web application susceptible to cross-site scripting attacks include:

• Failing to constrain and validate input.
• Failing to encode output.
• Trusting data retrieved from a shared database.

Guidelines

The two most important countermeasures to prevent cross-site scripting attacks are to:

• Constrain input.
• Encode output.

Constrain Input

Start by assuming that all input is malicious. Validate input type, length, format, and range.

• To constrain input supplied through server controls, use ASP.NET validator controls such as RegularExpressionValidator and RangeValidator.
• To constrain input supplied through client-side HTML input controls or input from other sources such as query strings or cookies, use the System.Text.RegularExpressions.Regex class in your server-side code to check for expected using regular expressions.
• To validate types such as integers, doubles, dates, and currency amounts, convert the input data to the equivalent .NET Framework data type and handle any resulting conversion errors.

For more information about and examples of how to constrain input, see .

Encode Output

Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases. HtmlEncode replaces characters that have special meaning in HTML-to-HTML variables that represent those characters. For example, < is replaced with &lt; and " is replaced with &quot;. Encoded data does not cause the browser to execute code. Instead, the data is rendered as harmless HTML.

Similarly, use HttpUtility.UrlEncode to encode output URLs if they are constructed from input.

Summary of Steps

To prevent cross-site scripting, perform the following steps:

<system.web>



  <pages buffer="true" validateRequest="true" />

</system.web>

  

You can disable request validation on a page-by-page basis. Check that your pages do not disable this feature unless necessary. For example, you may need to disable this feature for a page if it contains a free-format, rich-text entry field designed to accept a range of HTML characters as input. For more information about how to safely handle this type of page.

To test that ASP.NET request validation is enabled

1. Create an ASP.NET page that disables request validation. To do this, set ValidateRequest="false", as shown in the following code example.
   
   

   <%@ Page Language="C#" ValidateRequest="false" %>
   
   <html>
   
    <script runat="server">
   
     void btnSubmit_Click(Object sender, EventArgs e)
   
     {
   
       // If ValidateRequest is false, then 'hello' is displayed
   
       // If ValidateRequest is true, then ASP.NET returns an exception
   
       Response.Write(txtString.Text);
   
     }
   
    </script>
   
    <body>
   
     <form id="form1" runat="server">
   
   
   
       <asp:TextBox id="txtString" runat="server" 
   
                    Text="<script>alert('hello');</script>" />
   
       <asp:Button id="btnSubmit" runat="server"   
   
                   OnClick="btnSubmit_Click" 
   
                   Text="Submit" />
   
     </form>
   
    </body>
   
   </html>
   
   
   
     
2. Run the page. It displays Hello in a message box because the script in txtString is passed through and rendered as client-side script in your browser.
3. Set ValidateRequest="true" or remove the ValidateRequest page attribute and browse to the page again. Verify that the following error message is displayed.
   
   

   A potentially dangerous Request.Form value was detected from the client (txtString="<script>alert('hello...").
   
     

   This indicates that ASP.NET request validation is active and has rejected the input because it includes potentially dangerous HTML characters.
   
   

   Response.Write
   
   
   
   <% =
   
     

   Search your pages to locate where HTML and URL output is returned to the client.

   Step 3. Determine Whether HTML Output Includes Input Parameters

   Analyze your design and your page code to determine whether the output includes any input parameters. These parameters can come from a variety of sources. The following list includes common input sources:
   
   

   • Form fields, such as the following.
     

     Response.Write(name.Text);
     
     Response.Write(Request.Form["name"]);
     
     Query Strings
     
     Response.Write(Request.QueryString["name"]);
     
       
   • Query strings, such as the following:
     
     

     Response.Write(Request.QueryString["username"]);
     
       
   • Databases and data access methods, such as the following:
     

     SqlDataReader reader = cmd.ExecuteReader();
     
     Response.Write(reader.GetString(1));
     
       

     Be particularly careful with data read from a database if it is shared by other applications.
     

   • Cookie collection, such as the following:
     

     Response.Write(
     
     Request.Cookies["name"].Values["name"]);
     
       
   • Session and application variables, such as the following:
     
     

     Response.Write(Session["name"]);
     
     Response.Write(Application["name"]);
     
       
     <%@ Page Language="C#" AutoEventWireup="true"%>
     
     
     
     <html>
     
       <form id="form1" runat="server">
     
         <div>
     
           Color:&nbsp;<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><br />
     
           <asp:Button ID="Button1" runat="server" Text="Show color" 
     
              OnClick="Button1_Click" /><br />
     
     
     
           <asp:Literal ID="Literal1" runat="server"></asp:Literal>
     
         </div>
     
       </form>
     
     </html>
     
     
     
     <script runat="server">
     
       private void Page_Load(Object Src, EventArgs e)
     
       {
     
         protected void Button1_Click(object sender, EventArgs e)
     
         {
     
           Literal1.Text = @"<span style=""color:" 
     
             + Server.HtmlEncode(TextBox1.Text)
     
             + @""">Color example</span>";
     
         }           
     
       }
     
     </Script>
     
       

     Potentially Dangerous HTML Tags

     While not an exhaustive list, the following commonly used HTML tags could allow a malicious user to inject script code:
     
     

     <img src="BLOCKED SCRIPTalert('hello');">
     
     
     
     <img src="java&#010;script:alert('hello');">
     
     <img src="java&#X0A;script:alert('hello');">
     
       
     <style TYPE="text/javascript">
     
     
     
       alert('hello');
     
     </style>
     
       

     When you find ASP.NET code that generates HTML using some input, you need to evaluate appropriate countermeasures for your specific application. Countermeasures include:
     
     

     Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
     
       
     Response.Write(HttpUtility.UrlEncode(urlString));
     
       
     <%@ Page Language="C#" ValidateRequest="false"%>
     
     
     
     <script runat="server">
     
     
     
       void submitBtn_Click(object sender, EventArgs e)
     
       {
     
         // Encode the string input
     
         StringBuilder sb = new StringBuilder(
     
                                 HttpUtility.HtmlEncode(htmlInputTxt.Text));
     
         // Selectively allow  <b> and <i>
     
         sb.Replace("&lt;b&gt;", "<b>");
     
     
     
         sb.Replace("&lt;/b&gt;", "");
     
         sb.Replace("&lt;i&gt;", "<i>");
     
         sb.Replace("&lt;/i&gt;", "");
     
         Response.Write(sb.ToString());
     
       }
     
     </script>
     
     
     
     <html>
     
       <body>
     
     
     
         <form id="form1" runat="server">
     
           <div>
     
             <asp:TextBox ID="htmlInputTxt" Runat="server" 
     
                          TextMode="MultiLine" Width="318px"
     
                          Height="168px"></asp:TextBox>
     
             <asp:Button ID="submitBtn" Runat="server" 
     
                          Text="Submit" OnClick="submitBtn_Click" />
     
           </div>
     
         </form>
     
     
     
       </body>
     
     </html>
     

URL Rewrite Module - Go Live release

Today IIS team has made the Go Live release of URL Rewrite Module for IIS 7.0 available for download. This release contains significant functionality and performance improvements and it is believed to have a quality level suitable for production deployments.

Update for IIS 7.0 FastCGI module

IIS team has recently released an update for IIS 7.0 FastCGI module that fixes compatibility problems with several popular PHP applications. In particular, the update changes the behavior of FastCGI module in the following ways:

1. REQUEST_URI server variable set by FastCGI module now includes query string and path info. Previously, lack of the query string in this server variable caused the popular CMS application Drupal to not work with FastCGI on IIS 7.0
2. REQUEST_URI server variable now contains the originally requested URL path before any URL rewriting was performed. Prior to this fix, the server variable used to contain a final rewritten URL, which caused problems when using URL rewriting to enable “pretty permalinks” for popular blog engine Wordpress.

Note that above mentioned problems do not exist in IIS 6.0 FastCGI Extension, which always has been setting the REQUEST_URI server variable correctly.

The update is available for download from the following locations:

• Update for Windows Server 2008
• Update for Windows Server 2008 x64 Edition
• Update for Windows Server 2008 for Itanium-based Systems
• Update for Windows Vista SP1
• Update for Windows Vista SP1 for x64 based Systems

Warning: if your PHP application was coded in a way so that it relied on the REQUEST_URI server variable to contain the requested URL without a query string or to contain the final rewritten URL, then installing this update may break your application. Before applying the update, please make sure that your application does not rely on incorrect behavior of FastCGI module.

Don’t run production ASP.NET Applications with debug=”true” enabled

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.

Doing so causes a number of non-optimal things to happen including:

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)

2) Code can execute slower (since some additional debug paths are enabled)

3) Much more memory is used within the application at runtime

4) Scripts and images downloaded from the WebResources.axd handler are not cached

This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.  This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources.  Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers).  If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

One scenario that several people find very useful is to compile/pre-compile an application or associated class libraries with debug symbols so that more detailed stack trace and line error messages can be retrieved from it when errors occur. 

The good news is that you can do this without having the have the <compilation debug=”true”/> switch enabled in production.  Specifically, you can use either a web deployment project or a web application project to pre-compile the code for your site with debug symbols, and then change the <compilation debug=”true”/> switch to false right before you deploy the application on the server. 

The debug symbols and metadata in the compiled assemblies will increase the memory footprint of the application, but this can sometimes be an ok trade-off for more detailed error messages.

If you are a server administrator and want to ensure that no one accidentally deploys an ASP.NET application in production with the <compilation debug=”true”/> switch enabled within the application’s web.config file, one trick you can use with ASP.NET V2.0 is to take advantage of the <deployment> section within your machine.config file.

Specifically, by setting this within your machine.config file:

<configuration>

    <system.web>

          <deployment retail=”true”/>

    </system.web>

</configuration>

You will disable the <compilation debug=”true”/> switch, disable the ability to output trace output in a page, and turn off the ability to show detailed error messages remotely.  Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).

Setting this switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leakages.  There isn’t a ton of documentation on this switch – but you can learn a little more about it here.

URL Rewrite for IIS7

Finally Microsoft has released URL Rewrite Module for IIS 7.0 CTP1. Many hosting providers were asking about this.

Now you can move a php website hosted with Apache to IIS7 and manage to get url rewrite rules to work in minutes.

Download from http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1691

Forum at http://forums.iis.net/1152.aspx

Documentation at http://learn.iis.net/page.aspx/460/using-url-rewrite-module/

IIS 6.0 HTTP compression

I'm sure you guys know about http compression settings from IIS 6 can seriously improove your web site load speed but ever wondered how to enable http compression for .aspx, .asmx, .php files?

Well wonder no more.

To add one or more file types to the server-wide static compression configuration

Note

To remove one or more file types from the server-wide static compression configuration, repeat the previous two commands, leaving out the file type you want to remove.

To add one or more file types to the server-wide dynamic compression configuration

Note

To remove one or more file types from the server-wide dynamic compression configuration, repeat the previous two commands, leaving out the file type you want to remove.

Related Information

For a detailed discussion of how HTTP compression works, how to test compression, and detailed compression configuration options, see Using HTTP Compression for Faster Downloads.

Finally to test your configuration use this tool:

http://www.port80software.com/tools/compresscheck.asp

PHP security

Ever wanted to know more about securing your php web sites? The information and tools from PHPSecInfo is the perfect place to start.

PhpSecInfo provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.

Linux Losing Market Share to Windows Server

Surfing the internet and some news websites last night I found 2 very and i mean very interesting articles. Finally some of my predictions came true.

Linux Losing Market Share to Windows Server

Windows Server Woos Linux Customers

Windows Server 2008 Features Address Linux Challenge

DotNetPanel Integration API

Have you ever wanted to interact with DotNetPanel from your website or your application?

You can find a document we use for our integration partners describing methods intended for creating and maintaining state for user accounts, hosting spaces and so on at http://www.dotnetpanel.com/downloads/?CategoryID=8

You can also download DotNetPanel Web Portal sources (VS2005 solution) from our site and take a look how to it interacts with DotNetPanel ES by using SOAP.

The Windows 2008 Road Show is coming to a city near you!

Microsoft is hosting a World Wide Windows Server 2008 Road Show.  This is a unique opportunity to learn about and gets hands-on experience with our latest Web server technology-Microsoft Windows Server 2008 and Internet Information Services 7.  Myself and probably some of my teammates will be at EMEA road shows and hope you can come out and join us!

Now DotNetPanel offers support for Windows Server 2008, IIS7 and FTP7. Check out the press release here. We have a surprise for all atendees but i can't tell you now what is it all about.

ABOUT THE TRAINING:
IIS 7 is our most ambitious Web server to date and has many features that directly benefit the hosting community. IIS 7 will reduce total cost of ownership, improve manageability, and create new business opportunities.

Here are a few examples of what you can do with IIS 7:

Starting the DotNetPanel Blogs

Hello everyone. I'm Dan Petru, Sales & Marketing Specialist at DotNetPanel Software.

I am extremely pleased to be the first starting this blog. I will try to post interesting stuff here.

I always wanted to have a blog but I never had the time. So much information cross my eyes daily and sometimes I have to write my thoughts because I keep to forgetting things.

I have 3 years experience in hardware, 2 years in selling software and 2 years in the hosting world and .net software. I'm the guy for pretty much anything in everything. In the last year I’ve managed to build a small size datacenter from 0 and a hosting environment based on Microsoft and DotNetPanel software that pretty much runs by itself. We would probably meat at the EMEA Hosting Roadshows that we plan to participate.

I hope I will be at least the half as fast they are.

See you soon!