Implementing Flood Control to Protect Your SharePoint Server

* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

What is Flooding?

Flooding as a malicious computer term is becoming almost a household term, through the media news regarding denial of service attacks on different corporations, in different industries, for different purposes. SharePoint portals are a particularly attractive target since businesses will tend to rely on them for virtual teams, therefore attacking on with a flood attack could cause a disruption of businesses that could prove an exceptional benefit for competitors. A flood attack in general, is a targeted flood of information geared to a certain service or sets of services so that requesting data from an arbitrary resource is not possible.

How are flood attacks triggered?

Floods can be tripped by malicious users in a variety of ways, intentionally or unintentionally. Intentionally flooding is usually performed by using prewritten, language independent applications (however not typically in .NET since languages such as C# or VB.NET do not allow the granularity of threading and managed process execution that is needed for effective flooding applications). There are several that a person can just download, type in a target, and let it execute. Otherwise more talented parties will create a flooding application tiered towards a client to effectively render the targeted network or server obsolete. Unintentional flooding usually happens with a user inadvertently executing a worm or virus within the network that it can propagate across, which will later trip a flooding attack internally against the SharePoint portal.  

Didn’t ISA Server 2004 Have Flood Control?

ISA Server 2004 did have flood control, to a certain extent. In regards to control, ISA server 2004 more provided methods that would allow a person certain mechanisms of protection against certain, defined flooding attacks, however didn’t provide a needed universal solution (quota capability). Within a flood attack, there is certain information that has to be extracted during and after the attack to properly secure a SharePoint environment from future attacks:

  • Is the gateway (ISA) under attack, or is SharePoint directly under attack?
  • What type of flooding attack is it? DDOS? DOS? Worm? Known virus?
  • What service is being attacked?
  • Is the service currently down or under possibility of being brought down?
  • Is forensic analysis possible on the attacked server?
  • How can this attack be prevented in the future?

What does ISA Server 2006 Offer in Terms of Flood Control?

ISA Server introduces a new feature which is called Flood Resiliency, meant to enhance the amount of flood control that you can offer to protect your vital SharePoint assets. This new feature enhances your visibility and control over flood attacks during and after they occur.

The granular flood controls offered by ISA server 2006 are meant to mitigate flood risks to your environment through a variety of mechanisms, mostly be specifying connection limits.

There are several things that it is meant to protect against:

  • Worms and Viruses That Trip Floods
  • Various DOS (Denial of Service) Attacks
  • Various DDOS (Distributed Denial of Service) Attacks (one in which more than one machine is taken over to perform the attack)
  • SYN Flag attacks (spoofing attacks)

Step 1 — Open the ISA Administration Interface

Firstly, you must directly interact with the ISA server by logging onto the ISA Server machine either directly, through MSTSC, RDC, or other remote software such as DameWare, Tilovi, or others.

Start -> All Programs -> Microsoft ISA Server -> ISA Server Management

Step 2 Enter Into The ISA General Configuration Screen

With the ISA main server window:

Select your ISA server -> Select Configuration -> Select General

Step 3 Enter Into the Additional Security Policy Screen and Flood Control Dialog

With the ISA General Configuration Screen;

Scroll Down to Details -> Select Additional Security Policy -> Select Configure Flood Mitigation Settings

Step 4 Setup Flood Control and Additional Options

This is the main dialog for setting up and configuring flood control for your SharePoint environment. The first step is to check the box labeled Enable mitigation for flood attacks and worm propagation. Under this box, you will see a variety of settings related to how ISA server will deal with and handle certain flood attacks:

  • Limit TCP connection requests per minute per IP address
  • Limit TCP concurrent connections per IP address
  • Limit TCP half-open connections
  • HTTP requests per minute, per IP address
  • Non-TCP concurrent sessions per IP address
  • Limit non-TCP new sessions per minute, per rule
  • Limit TCP and non-TCP denied messages
  • Set event trigger for denied packets per minute, per IP address

The last box is logging records that are related to a possible flood attack, allowing forensic insight into attacks after the fact so that they can be properly prevented following. The log can also have limits set on it as well if you are an organization that is attacked very frequently. Because these logs could possibly increase dramatically, throttling the records that are written can be controlled.

Within each of the panes, configure how you believe your flood control should be structured. There is no standardized process to it, since smaller organizations or those within a non competitive industry are not likely to be attacked. Within each of the dialogs, there will be a small description that will allow you to know exactly what is being configured.

For example, the first selection within this flood mitigation dialog is to Limit TCP connection requests per minute per IP address. When you open this dialog, you will see four main things:

  • Mitigation Title In this case, the Mitigation Title is Limits TCP connection requests per minute per IP address.
  • Limit Specify the amount of requests that you wish to set as the threshold, the default is 600
  • Custom Limit (applies to IP exceptions) This is the limit that you wish to apply to all IP’s, the default is set to 6000.
  • Mitigation Description  —  Within in this specific pane, the description is Mitigates work propagations that occur when an infected host scans the network for vulnerable hosts. Also mitigates flood attacks that occur when an attacker send numerous TCP connect messages. This dialog will of course change when you configure or view different settings through the flood control settings.

These settings should not be hastily set because they will determine your overall flood control. Typically, before this dialog is entered, they are discussed with network and security personnel, documented, and then put into effect. These configurations should be documented so that configuration management can take place effectively and that if and when a security incident should occur, intended implementations should be compared to intentional configurations. This can weed out possible internal threats, and ensure that all of your security mechanisms are following corporate standards and guidelines.