Чеклист: готовим AlterCPA к DDoS-атакам
Чеклист: готовим AlterCPA к DDoS-атакам

Идеальной защиты от DDoS не существует. Смиритесь с этим фактом, ведь если вас действительно хотят уронить, вас уронят — финансовых ограничений в нашей сфере нет. Наша с вами задача — минимизировать потери и по максимум затруднить нашим оппонентом атаку. Но смиритесь сразу: уйти совсем без потерь не получится.

Важно! Всё, что я вам здесь расскажу, нужно применять до того, как в жопу вас клюнет жареный петух, на горе свистнет рак, грянет гром и начнётся сама DDoS-атака. Но мы с вами прекрасно знаем, что вы этого уже не сделали. Вооружаемся смирением и идём купировать последствия.

Эта инструкция предназначена для технических специалистов. Чтобы реализовать её достаточно качественно, вы должны понимать, как работать с серверами на Debian и иметь базовые знания о настройке nginx и администрировании Linux-серверов. Если таких специалистов в вашей команде нет, просто свяжитесь с поддержкой AlterCPA.

Подключаем прокси

Есть один прекрасный способ узнать внутренний адрес любой партнёрской сети. Достаточно взглянуть, откуда она отправляет постбеки, и прицельным залпом туда ударить. Например, в трекере AlterCPA Red вы легко можете увидеть IP-адрес источника постбека в журнале. Именно поэтому нужно направлять все постбеки и запросы интеграций через прокси — так мы сохраним реальный адрес ядра в тайне.

Что делать с прокси?

С организацией прокси-сервера есть два пути:

  1. Можно взять готовый прокси, например, купить у AstroProxy, как я ранее рассказывал. Плюсы подхода очевидны — делается быстро, а в случае атаки страдает какой-то другой сервис. Минусы тоже есть — работает любой сторонний сервис не совсем стабильно.
  2. Можно поднять свой собственный прокси-сервер. Плюсы в максимальной стабильности и высочайшей скорости работы за меньшую цену. Без минусов никуда, ведь такой сервер могут уложить тем самым DDoS-ом, но это купируется фаерволом с белым списком адресов.

Как купить AstroProxy, я уже рассказывал в блоге, потому разберём вариант со своим сервером.

Готовим прокси-сервер

Нам понадобится чистый сервер на свежем Debian. Возможно, подойдёт не совсем чистый и на Ubuntu, но лучше не рисковать.

Заходим на сервер по SSH от имени root и выполняем команду:

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

Через несколько минут установка будет завершена и скрипт выдаст данные сервера. Нам нужно взять строчки HTTP server и Authentication — их мы используем во всех настройках.

Настраиваем прокси в платформе

Глобальный прокси-сервер задаётся в «Расширенных настройках» (Управление — Настройки — Расширенные) ближе к низу страницы. Мы задаём следующие параметры:

  1. Ставим галочку «Использовать прокси для постбеков, фильтров и выгрузки» для защиты от нехороших вебмастеров и простых пользователей, которые могут перехватить наш IP в постбеке.
  2. Ставим галочку «Использовать прокси для интеграций с рекламодателями» для защиты от недобросовестных контрагентов, которые также легко могут увидеть наши адреса.
  3. В поле «Адрес» указываем наш прокси в виде IP:port, например 12.34.56.78:9999 для обычного HTTP, socks5://12.34.56.78:9999 для SOCKS5 с IP-адресом и socks5h://proxy.me:9999 для SOCKS5 с доменом.
  4. В поле «Логин и пароль» указываем имя пользователя с паролем через двоеточие, например mylogin:mypass или оставляем пустым для прокси без авторизации.

Настройки интеграции можно также задавать вручную. В разделе «Интеграция» добавьте такой код в каждый «Код предобработки» активных блоков:

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

Обратите внимание, что в некоторых интеграциях могут быть вложенные запросы в функции curl, куда $cc нужно передавать в третий параметр вручную.

Настраиваем прокси в хранилище сайтов

В хранилище прокси настраиваем через файл config.php, в него добавляем константы PROXY и PAUTH с сервером и авторизацией соответственно. Состав у них такой же, как и в настройках платформы.

Выглядеть будет вот так:

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

Сохраняем файл и на этом завершаем настройку прокси.

Разделяем серверы

Самый простой способ снизить эффективность DDoS-атаки — это развести её по разным точкам отказа. Платформа AlterCPA Pro из коробки поддерживает разделение на несколько серверов, в случае AlterCPA Cloud лучше озаботиться переездом на полную версию. Программа-минимум — завести фронт-сервер, программа-максимум — разделение сети на пять и более серверов.

Запускаем фронт-сервер

Простейший шаг, который рекомендуется сделать всем без исключения пользователям AlterCPA — завести фронт-сервер. Он будет отвечать за парковку пользовательских доменов и скрывать от них реальное расположение хранилища сайтов.

Лучшее решение для фронт-сервера — это PrivateFlare. Поддерживает установку нескольких серверов и позволяет выдавать эти серверы по отдельности разным группам вебов. Интеграция полуавтоматическая и описана в руководстве к сервису.

Альтернативный вариант — настроить встроенный фронт-сервер. Для этого нам потребуется один VPS по таким же рекомендациям, как и у PrivateFlare. Настраиваем его по стандартной инструкции.

Небольшой лайфхак: если зайти в подраздел «Диагностика» раздела «Настройки», там найдётся готовый скрипт для развёртывания фронт-сервера.

После настройки фронт-сервера, наше хранилище будет открываться всегда только с одного или нескольких известных нам IP-адресов. А значит, на основном сервере открываем файл конфигурации nginx в /etc/nginx/conf.d/altercpa.conf и в блоке хранилища сайтов и сайта по умолчанию прописываем белый список адресов:

allow 127.0.0.1;
allow 12.34.46.78;
deny all;

Где вместо 12.34.57.78 будет адрес нашего фронт-сервера. Директив allow может быть множество, каждая в своей строке — пригодится при использовании PrivateFlare с множеством нод.

Отделяем хранилище сайтов

Хранилище сайтов AlterCPA — штука удивительная и незаменимая. Она способна частично работать без основной системы, служить резервным каналом отправки лидов и даже частично фильтровать трафик, не затрагивая при этом ядро системы. Если вы, конечно, не забыли завести лендинги в своих офферах и не лишились тем самым идеального механизма спасения утопающих.

Конкретной инструкции по созданию отдельного хранилища сайтов нет, этим дао владеют исключительно специалисты команды AlterCPA. Но есть несколько намёков:

  1. В качестве хранилища можно использовать сервер средней мощности. Подойдёт средний VPS или минимальный Dedicated server. Настраиваем тем же скриптом, что и обычный сервер, потом просто удаляем MySQL.
  2. В расширенных настройках системы меняем привязку ClickServer с localhost на внешний IP-адрес сервера. Не забываем прикрыть порт фаерволом с допуском только с адресов хранилища.
  3. Заводим копию файлика go.php из хранилища сайтов, которая будет обрабатывать все запросы клоакинга, трекинга и прочих мелочей. Под случайным именем укладываем её в папку ядра. А в настройках нового хранилища сайтов указываем ссылку на этот файлик.
  4. Переносим все файлы из старого хранилища в новое. Не забываем поменять настройки в config.php и go.php хранилища.

Важно: после отделения хранилища сайтов от основной системы, необходимо вручную исправить настройки фронт-сервера. Для этого отредактируйте файл /etc/hosts и укажите в нём новые IP-адреса для поддомена с хранилищем сайтов.

Никто не запрещает сделать несколько хранилищ сайтов. Одно из них будет основным, а остальные могут синхронизироваться с ним через rsync, чтобы постоянно держать актуальные файлы. Не забудьте только исключить из синхронизации папку cms/db.

Если вы используете и фронт-сервер, и хранилище сайтов, появляется несомненное преимущество. В хранилище можно целиком отключить HTTPS, он просто не понадобится. Домен хранилища сайтов можно целиком удалить из DNS и связать хранилище с ядром и фронт-сервером, просто указав любой, в том числе вымышленный, домен в хост-файле.

Прикрываем основной домен

Взаимодействие внутри компонентов системы мы защитили и скрыли от любопытных глаз, но желательно закрыть и наш основной домен. В этом нам снова поможет PrivateFlare или отдельный фронт-сервер.

И здесь мы подходим к самому главному секрету: ваш основной домен, указанный в лицензии и используемый при настройке сети, не обязательно должен быть вашим реальным доменом. При использовании PrivateFlare вы просто паркуете совершенно другой домен и указываете ему в цели ваш системный домен — подмену сервис выполнит самостоятельно.

При работе с фронт-сервером, потребуется вручную переписать конфигурацию:

  1. В файле /root/webssl убираем строчку, которая загружает список доменов по ссылке.
  2. В файле /var/www/data/domains.txt указываем список внешних доменов.
  3. В файле /etc/nginx/snippets/proxy.conf указываем основной домен, вместо домена хранилища сайтов.

В дополнение, в файле /etc/nginx/snippets/proxy.conf можно также добавить подмену реального домена на наш «внешний» домен:

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

При работе в команде, никто не запрещает таким методом сделать несколько десятков доменов и раздавать каждому вебу или подразделению свой домен. Так в случае атаки легко можно будет вычислить крысу, которая слила данные.

Переносим систему на мощный сервер

Где-то на этом моменте мы внезапно приходим к осознанию, что защитой мы озаботились слишком поздно. За это время все явки и пароли нашего «сервера ядра» успели засветиться, и опытные атакующие обязательно его отыщут.

Пришло время переезда. Если вы используете AlterCPA Cloud, переезжать придётся в любом случае — большая часть нужных настроек там попросту не реализуема. Купите качественный выделенный сервер, что-нибудь уровня AX52-NVMe от Hetzner, и закажите переезд своей сети у команды поддержки AlterCPA.

Переводим всё на IPv6

Современное серверное оборудование всегда идёт в комплекте с IPv6-адресами. А мой любимый Hetzner предоставляет целую подсеть адресов IPv6 на каждый сервер. Грешно не воспользоваться таким огромным преимуществом, ведь из секстильонов адресов угадать нужный попросту не выйдет.

Раз всё взаимодействие с основным ядром системы и хранилищем сайтов идёт через промежуточные серверы, мы действуем следующим образом:

  1. На каждом сервере заводим дополнительный интерфейс IPv6 со случайным адресом из доступной нам подсети.
  2. В файлах /etc/hosts прописываем только IPv6-адреса целевых серверов.
  3. На фронт-серверах в конфиге, отвечающем за проксирование, в директиве proxy_pass вместо домена указываем IPv6-адрес.
  4. В файлах конфигурации nginx прописываем allow только с IPv6-адресов.
  5. Там же в файлах конфигурации nginx указываем директивы listen только в прямой привязке к конкретным IPv6-адресам, убираем IPv4 совсем.

Так мы лишаем атакующих самого главного — доступных для атаки IPv4-адресов, заставляя их выискивать конкретные внутренние «секретные» адреса, которые кроме сисадминов никто и не знает.

Готовим CloudFlare

Даже при использовании фронт-сервера, разделении серверов и подключении PrivateFlare, рекомендуется добавить ещё один слой защиты — собственно, защиту от DDoS. Да, те самые DDoS-защитники нужны только тут, после всей остальной подготовки. В теории, нам подойдёт совершенно любой сервис — различия в них минимальны. Поэтому использовать мы будем CloudFlare на бесплатном тарифе.

Переносим домен на CloudFlare

Если мы оказались тут — всё плохо. Домену желательно сразу же быть на CloudFlare и никогда нигде не светить свои реальные данные. После переноса рекомендуется сменить IP-адреса на всех серверах — они уже засветились.

Процедура переноса максимально стандартная: нажимаем Add site, указываем наши домены системы и хранилища сайтов, добавляем их с бесплатными тарифом и получаем NS-серверы, которые нужно задать домену. Записи DNS по началу переносим целиком. Ждём активации.

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

Как правило, DNS-записи переносятся в CloudFlare без особых проблем, достаточно убедиться в нескольких фактах:

  1. Все записи настроены на проксирование. Это значит, у них показывается рыжее облачко со стрелочкой сквозь него, а не серое облачко со стрелочкой в обход.
  2. Добавлены две записи для @ — одна с типом A и адресом IPv4, другая с типом AAAA и адресом IPv6. Лишние адресные записи нам не нужны.
  3. Добавлена запись для www с типом CNAME и адресом @ или название домена. Запись www лучше добавлять именно через CNAME, чтобы не ошибаться при переносе.
  4. Запись для поддомена r хранилища сайтов удалена из DNS. Она нам не пригодится — мы уже настроили всё взаимодействие с хранилищем по прямым адресам.
  5. Нет записи типа MX, которая указывает куда-то на основной сервер. Такую запись CloudFlare подсветит восклицательным знаком.

Эти настройки одинаково подходят и основным доменам системы, и доменам хранилища сайтов, Резюмируя: записи на IPv4 и IPv6, запись на www и всё, везде включен прокси.

Идея для ханипота: заводим поддомен mail с каким-нибудь совершенно левым IP-адресом. Например, адресом наших любимых конкурентов. Так мы якобы засвечиваем какой-то адрес из нашей инфраструктуры и напрямую предлагаем злоумышленникам по нему ударить.

Проводим тонкие настройки

Некоторые настройки критично необходимы для быстрой работы:

  1. В разделе SSL/TLS — Overview выберите режим шифрования Flexible вместо Full. Так вы сильно снизите нагрузку по шифрованию соединений на своём сервере, переложив это на CloudFlare.
  2. В разделе SSL/TLS — Edge certificates включите Always use HTTPS и Automatic HTTPS rewrites. Дополнительно, активируйте HSTS.
  3. В разделе Security — Settings выберите Security level со значением Essentialy Off. Именно его вы потом переключите в I’m under attack!

Сразу же ознакомьтесь с разделами Rules, они пригодятся вам во время атаки. С их помощью можно блокировать атакующих или выдавать доступ проверенным пользователям по белому списку IP-адресов.

Вместо заключения

Примерная стоимость «идеальной» инфраструктуры, созданной по этой инструкции, составляет около $300 в месяц, расходы на настройку — около $500-1000 единовременно. Внедрение окупается примерно за полчаса самой слабенькой атаки.

Когда начнётся реальная атака, вы не будете в безопасности. Смиритесь, это объективная реальность. Но с этой инструкцией вы сможете значительно усложнить жизнь атакующим и снизить свой собственный урон. Не паникуйте, просто призывайте Резника. Резник придёт и молча спасёт ваш мир.