Reverse HTTP Proxy

In order for the Qrator Labs reverse HTTP proxy to be able to protect the servers serving your resource, you need to ensure that all incoming traffic destined for the resource is always routed to the reverse proxy.

To do this, you need to:

  1. Configure DNS such that traffic to the servers goes through the reverse proxy.

  2. Change the IP addresses of the servers in case the servers are already under attack.

    If you leave the same IP address that was used before, the attacker will be able to send traffic to the server directly, bypassing the Qrator Labs reverse proxy.

  3. Set up a firewall on the servers so that only traffic from trusted networks is allowed.

    If the server does not drop connections from unknown networks, the attacker will still be able to detect it by brute forcing IP addresses. This allows traffic to be sent directly to the server, bypassing the Qrator Labs reverse proxy.

DNS configuration

In the DNS zone settings, change the A record for your domain to the reverse proxy IP address that appears as Qrator IP in your dashboard. Note that the changes are not immediately visible to other DNS servers and users. The exact time it takes to update an A record depends on its TTL value.

The Qrator Labs network is ready to handle traffic and implement protection as soon as the traffic starts arriving at the reverse proxy.

Changing the current IP address


This instruction should be followed if you're already under a DDoS attack.

Sometimes an attacker has an archive of old DNS records for your domain. So even after you change your A record to Qrator IP, an attacker may redirect the traffic to the real server IP, bypassing the reverse proxy.

To protect yourself from such an attack vector, change the upstream IP address:

  1. Make sure that the DNS A record for the desired domain points to Qrator IP.
  2. Get a new IP address from your ISP that has never been used for your site before. Do not publish the new IP address anywhere or use it in your DNS records. If possible, it's better to get an IP address from a different network than the previous one.
  3. In your Qrator Labs dashboard, add the new IP address as an upstream address. Delete the previous upstream, whose IP address may be known to an attacker.
  4. Stop processing requests to the former IP address.

Qrator Labs will start using the updated upstream list as soon as you save it in your dashboard.

Firewall configuration

If the IP addresses for the upstreams are taken from the same range, an attacker may try to find the actual server IP address by going through the addresses in the same network that the previous IP address belonged to. This happens if you use addresses from the same own network or from the same ISP.

To protect against detection, configure firewall rules such that the server only responds to requests from Qrator Labs networks and from your trusted networks, and drops all other connections. If none of the servers responds to connection attempts from the attacker, the attacker will not be able to know which address to direct the attack to.

Ensure that the list of allowed subnets from where requests will be processed includes four Qrator Labs subnets:


You can also add to this list a trusted office network and some employees' IP addresses if they plan to make requests bypassing the reverse proxy. Connections from all other addresses must be denied at the firewall level.

Depending on the upstream operating system, you can either use only iptables rules for plain HTTP, or combine them with rules for iptables supporting conntrack and ipset modules. We recommend using both conntrack and ipset because it makes the iptables rule set smaller (thereby making it easier to maintain) and faster (fewer rules means fewer requests per incoming packet).

You can make sure that the configuration for ports 80 and 443 is correct in the Utilities → Vulnerabilities section.

Here are some examples of scripts that do this configuration for iptables.

The examples may not fit your configuration

The following example scripts may not work or have an undesirable effect on your server. It depends on which iptables configuration is currently in use. Be careful not to use the scripts in the examples if you are not sure that they are suitable for your case.

Example of iptables configuration for plain HTTP




iptables -N trusted_nodes
    iptables -A trusted_nodes -s $IP -j RETURN

iptables -A trusted_nodes -j DROP
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j trusted_nodes

Example of iptables configuration with conntrack and ipset support




ipset -N trusted_nodes hash:net
    ipset -A trusted_nodes $IP

iptables -N qrator
iptables -A qrator -m set --match-set trusted_nodes src -j ACCEPT
iptables -A qrator -j DROP

iptables -A INPUT -p tcp -m multiport --dports 80,443 --state NEW -j qrator