How to DDoS Protect your Linux server

This guide is a generic process for protecting an application or service on any Linux distribution.

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 Minecraft, "HLDS" (Half Life / Source games) or Teamspeak 3. 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.

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.

For example:

# netstat -lnp | grep srcds_linux
tcp 0 0 10.17.22.2:27015 0.0.0.0:* LISTEN 6305/srcds_linux
udp 0 0 10.17.22.2:27015 0.0.0.0:* 6305/srcds_linux

In this case there is a half life dedicated server on 27015 (TCP and UDP). In this case you could create a port of type "TCP & UDP" or two port entries one for UDP and TCP. It is recommended to check to see if we support any Layer 7 profiles suitable for your application. 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.

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. 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 tcpdump.

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

There are other options for controlling outgoing connections including Policy Based routing which advanced users can do if they prefer.

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.