Checklist: preparing AlterCPA for DDoS attacks
Checklist: preparing AlterCPA for DDoS attacks

There is no perfect DDoS protection. Accept this fact, because if they really want to drop you, they will drop you – there are no financial restrictions in our industry. Our task is to minimize losses and make it as difficult as possible for our opponent to attack. But accept this right away: you won’t be able to survive with totally no losses.

Important! Everything that I will tell you here needs to be applied before the thunder claps and the DDoS attack itself begins. But you and I know very well that you have not done this. We arm ourselves with humility and go to stop the consequences.

This manual is intended for technical specialists. To implement it well enough, you must understand how to work with Debian servers and have basic knowledge of setting up nginx and administering Linux servers. If you don’t have such specialists on your team, just contact AlterCPA support.

Connect the proxy

There is one great way to find out the internal address of any affiliate network. Just look at where it sends postbacks from and hit there with a targeted volley. For example, in the AlterCPA Red tracker you can easily see the IP address of the postback source in the log. This is why we need to route all postbacks and integration requests through a proxy – this way we will keep the real core address secret.

What to do with proxies?

There are two ways to organize a proxy server:

  1. You can take a ready-made proxy, for example, buy from AstroProxy, as I previously told . The advantages of the approach are obvious – it is done quickly, and in case of an attack, some other service suffers. There are also disadvantages – any third-party service does not work very stably.
  2. You can set up your own proxy server. The advantages are maximum stability and the highest speed at a lower price. Can’t escape disadvantages here too, because such a server can be damaged by DDoS, but this is stopped by a firewall with a white list of addresses.

How to buy AstroProxy, I have already told on the blog, so let’s look at the option with your own server.

Preparing the proxy server

We will need a clean server on fresh Debian. Perhaps something not completely clean will work on Ubuntu, but it’s better not to risk it.

We log into the server via SSH as root and execute the command:

wget https://cpa.st/setup/proxy.sh && bash proxy.sh

After a few minutes, the installation will be completed and the script will display the server data. We need to take the lines HTTP server and Authentication – we use them in all settings.

Configuring the proxy in the platform

The global proxy server is set in “Advanced settings” (Control – Settings – Advanced) closer to the bottom of the page. We set the following parameters:

  1. Tick the “Use proxy for postbacks, filters and import” checkbox to protect against bad webmasters and ordinary users who can intercept our IP in the postback.
  2. Tick the “Use proxy for advertiser integrations” checkbox to protect against unscrupulous counterparties who can also easily see our addresses.
  3. In the “Address” field enter the proxy like IP:port, for example 12.34.56.78:9999 for regular HTTP, socks5://12.34. 56.78:9999 for SOCKS5 with an IP address and socks5h://proxy.me:9999 for SOCKS5 with a domain.
  4. In the “Authentication” field, enter the user name with a password separated by a colon, for example mylogin:mypass or leave it empty for a proxy without authorization.

Integration settings can also be set manually. In the “Integration” section, add the following code to each “Preprocessing code” of active blocks:

$cc['proxy'] = '193.23.50.56:10555';
$cc['pauth'] = 'yayebu:babuyagu';

Please note that some integrations may have nested queries within the curl functions, where $cc must be passed into the third parameter manually.

Configuring the proxy in the site storage

In the storage, we configure proxy through the config.php file, adding the PROXY and PAUTH constants to it with the server and authorization, respectively. Their composition is the same as in the platform settings.

It will look like this:

define( 'PROXY', '12.34.56.78:9999' );
define( 'PAUTH', 'daslogin:derparol' );

Save the file and complete the proxy setup.

Separating servers

The easiest way to reduce the effectiveness of a DDoS attack is to spread it across different points of failure. The AlterCPA Pro platform out of the box supports division into several servers. In the case of AlterCPA Cloud, it is better to worry about moving to the full version. The minimum program is to create a front server, the maximum program is to divide the network into five or more servers.

Start the front server

The simplest step that is recommended for all AlterCPA users without exception is to create a front server. It will be responsible for parking user domains and hiding the real location of the site storage from them.

The best front server solution is PrivateFlare. Supports the installation of multiple servers and allows you to distribute these servers individually to different affiliate teams. The integration is semi-automatic and is described in the service manual.

An alternative option is to set up a built-in front server. To do this, we will need one VPS according to the same recommendations as PrivateFlare. We configure it according to the standard instructions.

A small life hack: if you go to the “Diagnostics” subsection of the “Settings” section, you will find a ready-made script for deploying a front server.

After setting up the front server, our storage will always be opened only from one or several IP addresses known to us. This means that on the main server we open the nginx configuration file in /etc/nginx/conf.d/altercpa.conf and in the site and default site storage block we register a white list of addresses:

allow 127.0.0.1;
allow 12.34.46.78;
deny all;

Where instead of 12.34.57.78 there will be the address of our front server. There can be many allow directives, each in its own line – useful when using PrivateFlare with many nodes.

Separating site storage

The AlterCPA website storage is an amazing and irreplaceable thing. It can partially work without the main system, serve as a backup channel for sending leads, and even partially filter traffic without dealing with the core of the system. Unless, of course, you forgot to create landing pages in your offers and thereby lost the ideal mechanism for saving drowning leads.

There are no specific instructions for creating a separate website repository – this data is owned exclusively by the specialists of the AlterCPA team. But there are a few hints:

  1. A medium-power server can be used as storage. An average VPS or minimal dedicated server will do. We configure it using the same script as a regular server, then simply remove MySQL.
  2. In the advanced system settings, change the ClickServer binding from localhost to the external IP address of the server. Don’t forget to cover the port with a firewall allowing access only from storage addresses.
  3. Create a copy of the go.php file from the site storage, which will process all requests for cloaking, tracking and other little things. Under a random name put it in the kernel folder. And in the settings of the new site storage enter the link to this file.
  4. Transfer all files from the old storage to the new one. Don’t forget to change the settings in config.php and go.php storage.

Important: after separating the site storage from the main system, you must manually correct the front server settings. To do this, edit the /etc/hosts file and specify in it new IP addresses for the subdomain with site storage.

Nobody forbids making several site storage sites. One of them will be the main one, and the others can synchronize with it via rsync to always keep the latest files. Just remember to exclude the cms/db folder from synchronization.

If you use both front server and site storage, there is a definite advantage. You can completely disable HTTPS in the storage – you simply won’t need it. The site storage domain can be completely removed from DNS and the storage can be linked to the core and front server by simply specifying any domain, including a fictitious one, in the host file.

Covering the main domain

We protected the interaction within the system components and hid it from prying eyes, but it is advisable to close our main domain as well. PrivateFlare or a separate front server will help us with this again.

And here we come to the biggest secret: your main domain specified in the license and used when setting up the network does not have to be your real domain. When using PrivateFlare, you simply park a completely different domain and point it to your system domain as the target – the service will perform the substitution on its own.

When working with a front server, you will need to manually rewrite the configuration:

  1. In the file /root/webssl we remove the line that loads the list of domains from the link.
  2. In the file /var/www/data/domains.txt we specify a list of external domains.
  3. In the file /etc/nginx/snippets/proxy.conf we specify the main domain instead of the site storage domain.

In addition, in the file /etc/nginx/snippets/proxy.conf you can also add a substitution of the real domain for our “external” domain:

sub_filter 'mysecret.domain' $host;
sub_filter_once off;
sub_filter_types text/plain application/json;

When working in a team, no one forbids making several dozen domains using this method and distributing their own domain to each affiliate or team. This way, in the event of an attack, it will be easy to identify the rat that leaked the data.

Transfer the core to a powerful server

Somewhere at this point, we suddenly realise that we took care of protection too late. During this time, all the addresses of our “kernel server” have become visible, and experienced attackers will definitely find it.

It’s time to move. If you use AlterCPA Cloud, you will have to move in any case – most of the necessary settings are simply not implementable there. Buy a quality dedicated server, something like the AX52-NVMe from Hetzner, and have your network moved by AlterCPA support team.

Transfer everything to IPv6

Modern server equipment always comes with IPv6 addresses. And my favorite Hetzner provides an entire subnet of IPv6 addresses per server. It would be a shame not to take such a huge advantage, because out of sextillions of addresses, it’s simply impossible to guess the right one.

Since all interaction with the main core of the system and site storage occurs through intermediate servers, we proceed as follows:

  1. On each server we create an additional IPv6 interface with a random address from the subnet available to us.
  2. In the files /etc/hosts we write only the IPv6 addresses of the target servers.
  3. On front servers, in the config responsible for proxying, in the proxy_pass directive we specify an IPv6 address instead of a domain.
  4. In the nginx configuration files we specify allow only from IPv6 addresses.
  5. In the nginx configuration files we specify listen directives only in direct connection to specific IPv6 addresses, and remove IPv4 completely.

This way we deprive attackers of the most important thing – IPv4 addresses available for attack, forcing them to look for specific internal “secret” addresses that no one except system administrators knows.

Preparing CloudFlare

Even when using a front server, separating servers and connecting PrivateFlare, it is recommended to add another layer of protection – actually, DDoS protection. Yes, those same DDoS defenders are needed only here, after all the other preparation. In theory, absolutely any service is suitable for us – the differences in them are minimal. Therefore, we will use CloudFlare on the free plan.

Move your domain to CloudFlare

If we end up here, everything is bad. It is advisable for the domain to immediately be on CloudFlare and never show its real data anywhere. After the transfer, it is recommended to change the IP addresses on all servers – they are already lit up.

The transfer procedure is as standard as possible: click Add site, indicate our system domains and site storage, add them with a free plan and get the NS servers that need to be assigned to the domain. First, we transfer the entire DNS records. We are waiting for activation.

Подготавливаем DNS-записи

Usually DNS records are transferred to CloudFlare without any problems, just make sure of a few facts:

  1. All records are configured with proxying. This means they show an orange cloud with an arrow through it, and not a gray cloud with an arrow going around it.
  2. Added two entries for @ – one with type A and an IPv4 address, the other with type AAAA and an IPv6 address. We don’t need extra address records.
  3. Added an entry for www with type CNAME and address @ or domain name. It is better to add the www entry via CNAME, so as not to make mistakes when transferring.
  4. The entry for the r subdomain of the site store has been removed from DNS. We will not need it – we have already configured all interaction with the storage using direct addresses.
  5. There is no MX record that points somewhere to the main server. CloudFlare will highlight such an entry with an exclamation mark.

These settings are equally suitable for both the main system domains and site storage domains. To summarize: recordings on IPv4 and IPv6, recording on www and that’s it, proxy is enabled everywhere.

Idea for a honeypot: we create a mail subdomain with some completely wrong IP address. For example, the address of our favorite competitors. This is how we supposedly expose some address from our infrastructure and directly invite attackers to attack it.

Making fine tuning

Some settings are critical for fast operation:

  1. In the SSL/TLS – Overview section, select the Flexible encryption mode instead of Full. This way you will greatly reduce the load on encrypting connections on your server by transferring it to CloudFlare.
  2. In the SSL/TLS – Edge certificates section, enable Always use HTTPS and Automatic HTTPS rewrites. Additionally, activate HSTS.
  3. In the Security – Settings section, select Security level with the value Essentially Off. This is what you will later switch to I’m under attack!

Immediately familiarize yourself with the Rules sections, they will be useful to you during the attack. With their help, you can block attackers or grant access to trusted users using a white list of IP addresses.

Instead of conclusion

The approximate cost of the “perfect” infrastructure created according to these instructions is about $300 per month, setup costs are about $500-1000 once. The implementation pays for itself in about half an hour with the weakest attack.

When the real attack comes, you won’t be safe. Humble yourself, this is an objective reality. But with these instructions you can make life much more difficult for attackers and reduce your own damage. Don’t panic, just call Reznik. Reznik will come and silently save your world.