How to DDoS Protect your Windows server

How to DDoS Protect your Windows server

This guide is a generic process for protecting an application or service on Windows.

Step 1. Identify what service you are trying to protect

There may be guides in this Knowledgebase specific to your application. You can use the search box above to search for specific keywords such as Bedrock. There are numerous Linux tutorials as well, these may be useful in advisory capacity for Windows server operators regardless of target Operating System. If you can find a specific tutorial we recommend following the steps we have provided for you, these are well tested instructions.

Not all guides are platform specific, if you are looking to protect a website or web service (e.g API) we recommend following the platform independent Website setup guide.

If you can not find a specific tutorial we still recommend reading some of the examples provided for a general guide. The primary difference between guides is the service port numbers (which will be specific to your service / application).

Step 2. Identify what method of protection you require

If your application / game makes outgoing connections (such as to register with a game server operator or list service) then will require a GRE/IP-in-IP tunnel. This technology is require to make outgoing connections with the provided filtered IP. If your application purely acts on incomming connections you may choose either the tunnel (encapsulated) method, or the simpler Reverse Proxy method.

If you wish to use a tunnel you should visit the "Tunnels" page of the dashboard and define a tunnel between our filtering edges and your backend server. Once defined (and you have defined at-least one Port referencing the tunnel) you can install the tunnel and verify it's status.

On Windows Tunnels are less easily supported than on Linux, if your application requires a Tunnel and supports both Operating Systems we strongly recommend you consider using Linux. We have a guide on setting up a GRE/IP-in-IP tunnel on Windows which should be carefully followed when persuing this method. No tunneling application setup is required for Reverse Proxy methods.

Step 3. Identify the ports your application / service uses

It is recommended that you specify the ports you wish to protect explicitly ("Port" type filtering). You can identify the ports that your service is using using netstat (netstat -a). You can also use a GUI tool like Process Explorer to identify the ports in use by a given application.

You should use forward the TCP and UDP ports required using our interface. Some games / applications have specific profiles (e.g to mitigate a game specific attack). In this case you could use the A2S profile as this is a Valve / Half Life game server. Ports can be added to your service on the "Ports" page in the dashboard.

You should also ensure that the ports your application uses are allowed through the Windows Firewall.

Step 4. Setup

First you will want to setup your tunnel if you are using one. For general advice on the operation of tunnels see the page on Tunnels and the Windows tunnel guide). Once your tunnel is installed and you have verified that communication is sane over the tunnel proceed.

For a Reverese Proxy setup no specific configuration of your backend server is required. You will of course however want to ensure that there is no firewalls or similar software that may interfere with communication from the backend communication IP we have provided you and your service.

Step 5. Tunnel Specific: Check your application bindings

If using a tunnel you will want to ensure that your application is bound to the tunnel IP.

NOTE: While binding to 0.0.0.0 may work depending on your application it is generally advisable to explicitly bind services.

To bind your application consult it's documentation. This option may be known as the listen ip, server ip or main ip. Some applications may be supply this via configuration file or via an argument. For hlds based servers for example there is the -ip <INTERNALIP> parameter.

Next, if your service makes outgoing connections (for example self-registration with a server list) you should verify that these connection or packets are sent over the tunnel. The IP binding you have done previously should cover this. However some applications are not well written and will instead transmit packets over the servers primary interface regardless of configuration. You can check that outgoing connections (TCP) are made over the tunnel using netstat and that outgoing packets (TCP or UDP) are forwarded over the tunnel using Wireshark.

If your application does not support binding configuration, or missbehaves with outgoing connections you may want to use ForceBindIP to override your applications behaviour. This will force communication over the tunnel regardless of the applications coded behaviour.

Step 6. Check your application

Check that your application is accessible over your filtered IP. This can usually be accomplished by connecting the same way you would normally with your client (or web browser). You should check that communication is occuring over the provided filtered IP and that your backend server IP is not leaked anywhere.