> For the complete documentation index, see [llms.txt](https://docs.link11.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.link11.com/product-guides/web-ddos/setup.md).

# Setup

<figure><img src="/files/t5cnCAlMQ34lMAXuch2D" alt=""><figcaption></figcaption></figure>

## Prerequisites

* **Access to DNS** for the domain(s) you wish to protect
* **x.509 certificates** for the domains. Web DDoS can be used without these certificates, but some capabilities will be unavailable: Zero Touch WAF, Bot Management, provision of the proxy IP to the origin, etc.
* **IP address(es)** of the Web DDoS instance(s). These are provided by Link11.
* **Compatibility of your application(s)** with Web DDoS, as described below.
* **Site Shield**: After Web DDoS is activated, we strongly recommend you implement a [Site Shield](/product-guides/web-ddos/faq/site-shield.md) to reject all traffic that has not been cleaned by Link11.

## Application compatibility with Web DDoS

Most customer apps (web applications, mobile/native apps, etc.), can be protected by Web DDoS with no problems. However, the following points should be understood. If any of the below apply to your situation, contact Customer Support for assistance.

* If an app is stateless and does not use cookies, we need to disable our cookie challenge. Otherwise an app user might end up in a redirect loop and be blocked. If you still wish to use that challenge, we can create a workaround with two instances: one for mobile app users (without the challenge) and one for normal web browsers (including the cookie challenge).
* A native app might not be able to show captchas. Hence, we need to either [URL Whitelist](/product-guides/web-ddos/interface/url-whitelist.md) the API, or disable the captcha completely. The same workaround described above (using two instances) to still use captchas in normal web browsers can be done here.
* A user agent should be sent, so that in case False Positives occur from the Bot Management service, you can [whitelist the user agent](/product-guides/bot-management/interface/rules.md#id-botmanagement-rules-useragentwhitelistrule).

## **Sending Traffic to Link11**

To send traffic to the Link11 WebDDoS filtering solution, a DNS entry is needed pointing the A (or AAAA) record for the domain to the IP address provided by Link11. Please note that updating destination for the traffic may take some time, depending on the TTL set on the DNS provider.

If customer traffic is expected to be high, multiple instances may be needed to handle the total throughput. In these instances DNS records will be needed for all the configured instances. This can be accomplished by adding all the IP addresses provided by Link11 to the DNS A (or AAAA) record for the domain.

Setting a short TTL may be advisable to allow for configuration changes to propagate quickly.

## **Handling TLS**

Customers do not need to upload the x.509 certificate for TLS termination; instead, they can use a functionality called "[TLS Passthrough](/product-guides/web-ddos/interface/instances/tls-settings.md#tls-passthrough)" where the TLS connection is forwarded to the origin server.&#x20;

However, if customers do not use TLS termination, some functionalities are limited. For example, the Proxy IP is not visible to the origin server, and services like WAF and Bot Management are not available.

### Preserving client IP information

When customers upload their x.509 certificates to the Web GUI and activate TLS termination or use plain HTTP in Web DDoS, they can specify a certain HTTP header where Web DDoS inserts the requesting client IP (the default header is X-DDOSPROXY). On the origin server, customers can then analyze this HTTP header to use the client IP address in their application.

## **Uploading Your SSL Cert**

If you have ordered the feature *Secure SSL handling by Link11*, you can upload the appropriate SSL certificates to the https-secured WebGUI.

You may find the certificate upload a&#x74;*: Web DDoS > Instances > Instance Name > Edit*

<figure><img src="/files/o06IRynKiv2CYjrmGHFh" alt=""><figcaption></figcaption></figure>

For a complete upload the following files must be uploaded in .PEM forma&#x74;*: SSL Certificate, SSL Certificate private key.* Optionally *SSL Intermediate Certificates* can be uploaded as needed.

The SSL ciphers of the configuration are selected by best-common-practices.

There are two default setups. ECDHE and PFS are supported. SSLv2 and SSLv3 are disabled by default. TLS version 1.3 is preferred, but 1.2, 1.1 and 1.0 are also supported.

## Ensuring complete protection

When a customer begins using Web DDoS, they will receive their traffic on a new public IP address. However, if someone knows (or looks up) the customer's old IP addresses, they could send requests directly to the origins, and bypass Link11's filtering.

<figure><img src="/files/xaD7hCEiOMmx4lwWwO6Q" alt=""><figcaption></figcaption></figure>

Therefore, it is highly recommended that customers set up a "[site shield](/product-guides/web-ddos/faq/site-shield.md)" which blocks all incoming traffic that didn't originate from the Link11 IP ranges. This can be done at the edge router of the customer's hosting provider.

If such a "site shield" is not an option, we recommend customers use a new IP address range for the origin service. These addresses should never have been publicly associated with the customer in the past. Otherwise, sophisticated attackers might be able to get the origin IP ranges by looking at historical DNS information.