DDoS-Guard для Linux VPS: подключение и проверка защиты

DDoS-атака может сделать сайт недоступным даже тогда, когда сам Linux VPS настроен правильно и имеет достаточный запас процессора и памяти. При объемной атаке нежелательный трафик занимает внешний канал, а при атаке на веб-приложение большое число запросов перегружает Nginx, Apache, PHP или базу данных.

Локальный firewall помогает закрыть лишние порты и заблокировать отдельные адреса, но он начинает обрабатывать пакеты только после того, как они дошли до серверной инфраструктуры. Если канал уже заполнен, блокировка на самом VPS не возвращает сайту доступность.

DDoS-Guard решает эту задачу с помощью внешней фильтрации. В случае защиты сайта публичный трафик сначала поступает на инфраструктуру сервиса, проходит проверку и только затем передается на исходный веб-сервер. Linux VPS в такой схеме становится origin-сервером.

Подключение защиты затрагивает DNS, HTTPS, журналы веб-сервера, правила firewall и работу внешних интеграций. Ошибка в одном из этих элементов может привести к циклическим редиректам, неверному сертификату, потере реального IP посетителя или возможности обойти фильтрацию по прямому адресу VPS.

Разберем, как работает DDoS-Guard, чем защита сайта отличается от защиты сети, что подготовить перед подключением и как проверить результат после изменения маршрута трафика.

Как DDoS-Guard защищает сайт на Linux VPS

Для защиты веб-сайтов DDoS-Guard использует обратное проксирование. Домен направляется на защищенный адрес сервиса, а реальный IP веб-сервера указывается как адрес origin.

                    Посетитель
                         │
                         ▼
                   DNS домена
                         │
                         ▼
            Защищенная инфраструктура
                    DDoS-Guard
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
       Вредоносный трафик     Разрешенный трафик
              │                     │
              ▼                     ▼
         Блокируется          Linux VPS
                                    │
                                    ▼
                          Nginx или Apache
                                    │
                                    ▼
                            Сайт или API

Почему трафик фильтруется до сервера

Основная задача внешней защиты — не допустить, чтобы весь объем атаки дошел до канала и ресурсов origin-сервера. Инфраструктура фильтрации принимает соединения на себя и отделяет обычные запросы от аномальной активности.

Для владельца сайта это дает два практических преимущества:

• большая часть нежелательного трафика не достигает Linux VPS;
• публичный адрес сайта больше не обязан совпадать с реальным адресом веб-сервера.

Второй пункт важен для защиты от прямого обхода. Если атакующему известен origin IP, он может отправлять трафик непосредственно на VPS, минуя reverse proxy.

Какие уровни атак различают

Защита сайта через reverse proxy может фильтровать HTTP- и HTTPS-запросы, а сокрытие origin дополнительно снижает риск прямых сетевых и транспортных атак на адрес веб-сервера.

Но такой результат сохраняется только пока реальный IP не раскрыт и прямой доступ к нему ограничен. Если origin остается публично доступным, защитный контур можно обойти.

Чем DDoS-Guard отличается от firewall и WAF

Эти механизмы не заменяют друг друга. Firewall нужен для сетевой политики VPS, WAF — для защиты веб-приложения, а DDoS-фильтрация — для сохранения доступности при большом объеме нежелательного трафика.

Чем защита сайта отличается от защиты сети

Под названием DDoS-Guard могут подразумеваться разные продукты. Для владельца Linux VPS важно не смешивать защиту сайта через reverse proxy и защиту сетевой инфраструктуры.

Защита сайта

Защита сайта рассчитана на HTTP- и HTTPS-ресурсы:

• корпоративные сайты;
• интернет-магазины;
• личные кабинеты;
• веб-приложения;
• HTTP API;
• проекты на CMS;
• часть сценариев с WebSocket.

Домен направляется на защищенный адрес, после чего разрешенные запросы передаются на origin. При этом SSH, почта, VPN, СУБД и произвольные TCP- или UDP-службы не становятся защищенными только потому, что сайт подключен к reverse proxy.

Защита сети

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

Такие проекты требуют анализа маршрутизации, пропускной способности, адресов, протоколов и требований к доступности. Инструкция по изменению A-записи домена не заменяет проектирование сетевой защиты.

Что подготовить перед подключением защиты

Перед изменением маршрута нужно зафиксировать рабочее состояние сайта. Иначе после переключения будет трудно определить, связана ли ошибка с DDoS-Guard, DNS, сертификатом или исходной конфигурацией Linux VPS.

Соберите карту доменов и DNS-записей

Сохраните:

• основной домен;
• вариант с www;
• рабочие поддомены;
• A- и AAAA-записи;
• CNAME-записи;
• текущий TTL;
• MX-записи;
• служебные TXT-записи;
• адрес origin-сервера;
• контакты владельца DNS-зоны.

Проверить текущие записи можно командами:

dig +short A example.ru
dig +short AAAA example.ru
dig +short CNAME www.example.ru
dig +short MX example.ru

Вместо example.ru укажите рабочий домен. Результат лучше сохранить до переключения.

Уменьшите TTL заранее

Если для подключения нужно изменить DNS, TTL лучше уменьшить до переключения. При изменении TTL одновременно с A-записью рекурсивные DNS-серверы могут продолжать хранить старый адрес в течение прежнего срока.

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

Проверьте origin напрямую

До подключения защиты сайт должен стабильно работать на исходном сервере.

Проверка публичного домена:

curl -I https://example.ru/

Проверка конкретного IP с сохранением доменного имени для HTTPS и виртуального хоста:

curl -I \
    --resolve example.ru:443:203.0.113.10 \
    https://example.ru/

203.0.113.10 — пример адреса. Его нужно заменить реальным IP Linux VPS.

Параметр --resolve полезен и после переключения DNS: он позволяет проверить origin независимо от защищенного адреса.

Проверьте веб-сервер

Для Nginx:

sudo nginx -t
sudo systemctl status nginx --no-pager

Для Apache в Debian и Ubuntu:

sudo apache2ctl configtest
sudo systemctl status apache2 --no-pager

На других дистрибутивах служба может называться httpd.

Проверьте открытые порты

sudo ss -lntup

Нужно определить, какие службы используют публичный IP:

• HTTP и HTTPS;
• SSH;
• панель управления;
• почтовый сервер;
• FTP;
• VPN;
• базы данных;
• служебные API;
• системы мониторинга.

Эта информация понадобится при ограничении прямого доступа к origin. Нельзя закрывать весь адрес для интернета, не учитывая остальные сервисы.

Зафиксируйте обычную нагрузку

До переключения полезно записать:

• среднюю загрузку CPU;
• потребление оперативной памяти;
• число соединений;
• обычное время ответа;
• число запросов в минуту;
• долю ошибок 4xx и 5xx;
• объем входящего трафика.

Базовые показатели Linux:

uptime
free -h
df -h
sudo ss -s

Как подключить защиту сайта через reverse proxy

Названия команд и разделов панели зависят от выбранного тарифа и способа заказа, но техническая последовательность обычно одинакова.

Добавьте защищаемый ресурс

В настройках указываются:

• основной домен;
• дополнительные доменные имена;
• поддомены;
• IP origin-сервера;
• порт HTTP;
• порт HTTPS;
• схема соединения с origin;
• параметры SSL;
• дополнительные настройки приложения.

Если сайт открывается по адресам example.ru и www.example.ru, оба имени должны быть учтены в конфигурации защиты и сертификате.

Определите схему HTTPS

HTTPS-соединение состоит из двух возможных участков:

              Посетитель
                   │
              HTTPS-соединение
                   │
                   ▼
              DDoS-Guard
                   │
          HTTP или HTTPS к origin
                   │
                   ▼
               Linux VPS

Перед переключением выясните:

• какой сертификат используется на внешней точке;
• можно ли применить собственный сертификат;
• кто отвечает за его продление;
• используется ли HTTPS между DDoS-Guard и Linux VPS;
• проверяется ли сертификат origin;
• как передается информация об исходном протоколе;
• где настроен редирект с HTTP на HTTPS.

Если reverse proxy передает запрос на origin по HTTP, а приложение считает соединение незащищенным, может возникнуть циклический редирект. В таком случае нужно правильно обрабатывать служебный заголовок исходного протокола, а не отключать HTTPS для всего сайта.

Измените DNS

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

После изменения проверьте результат:

dig +short A example.ru
dig +short A www.example.ru
dig +short AAAA example.ru

Проверка через независимые резолверы:

dig @1.1.1.1 +short A example.ru
dig @8.8.8.8 +short A example.ru

Если в DNS опубликовано несколько A-записей, каждая из них должна соответствовать принятой схеме. Старый адрес среди записей позволит части запросов идти напрямую.

Учитывайте IPv6

AAAA-запись требует отдельной проверки. Если защита подключена только для IPv4, а IPv6 продолжает указывать на Linux VPS, пользователи и атакующие смогут обращаться к origin в обход защищенного маршрута.

Перед изменением AAAA нужно выяснить:

• поддерживает ли выбранная услуга IPv6;
• обслуживает ли веб-сервер сайт по IPv6;
• используют ли IPv6 другие службы;
• есть ли отдельный защищенный адрес IPv6;
• можно ли временно отказаться от AAAA без нарушения работы проекта.

Настройте передачу реального IP посетителя

После подключения reverse proxy соединение с Linux VPS устанавливает инфраструктура DDoS-Guard. Без дополнительной настройки веб-сервер будет видеть адрес прокси вместо адреса посетителя.

Это влияет на:

• журналы доступа;
• веб-аналитику;
• rate limit;
• географические ограничения;
• блокировку подозрительных клиентов;
• расследование инцидентов;
• логику приложения.

Для Nginx используется модуль определения реального IP. Общая структура выглядит так:

# Добавьте только официальные сети reverse proxy.
set_real_ip_from PROXY_NETWORK;

# Укажите заголовок, используемый поставщиком услуги.
real_ip_header REAL_IP_HEADER;

real_ip_recursive on;

PROXY_NETWORK и REAL_IP_HEADER — заполнители. Их нужно заменить значениями из актуальной документации или настроек подключенной услуги.

После изменения конфигурации:

sudo nginx -t
sudo systemctl reload nginx

Ограничьте прямой доступ к origin

Пока реальный IP Linux VPS доступен для обычных HTTP- и HTTPS-подключений из интернета, защиту можно обойти.

Перед ограничением доступа составьте список разрешенных источников:

• официальные сети DDoS-Guard;
• адреса администраторов;
• системы мониторинга;
• внешние интеграции;
• платежные сервисы;
• callback-серверы;
• поисковые и технические роботы, если они обращаются к origin напрямую;
• другие балансировщики и прокси.

Правила firewall нельзя строить по диапазонам из старых статей или форумов. Используйте актуальный список, предоставленный сервисом для подключенного продукта.

До закрытия прямого доступа проверьте, что:

• домен уже указывает на защищенную инфраструктуру;
• сайт стабильно открывается через нее;
• HTTPS работает;
• все нужные поддомены подключены;
• реальный IP посетителя передается корректно;
• мониторинг использует правильный маршрут;
• остальные службы VPS не будут заблокированы.

Проверьте способы раскрытия origin

Даже после изменения основной A-записи реальный адрес может оставаться доступным через:

• старые DNS-записи;
• AAAA-запись;
• служебный поддомен;
• панель управления;
• почтовые записи;
• API;
• другой сайт на том же VPS;
• историю DNS;
• письма, отправленные непосредственно с сервера;
• прямые ссылки на IP.

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

Как проверить DDoS-Guard после подключения

Открытие главной страницы подтверждает только базовую доступность. Полная проверка должна охватывать DNS, HTTPS, origin, журналы и пользовательские функции.

Проверьте внешний маршрут

dig +short A example.ru
dig +short AAAA example.ru

Полученные адреса должны соответствовать принятой схеме. Если A указывает на защиту, а AAAA — на origin, маршрут остается неодинаковым для IPv4- и IPv6-клиентов.

Проверьте HTTP и HTTPS

curl -I http://example.ru/
curl -I https://example.ru/

Проверьте:

• коды ответов;
• редирект с HTTP на HTTPS;
• отсутствие цикла перенаправлений;
• основной вариант домена;
• время ответа;
• служебные заголовки;
• страницы, отличные от главной.

Проверьте внешний сертификат

echo |
openssl s_client \
    -connect example.ru:443 \
    -servername example.ru \
    2>/dev/null |
openssl x509 \
    -noout \
    -subject \
    -issuer \
    -dates \
    -serial

Команда показывает сертификат, который получает внешний пользователь. Он может отличаться от файла, установленного непосредственно на Linux VPS.

Проверьте:

• соответствие имени домена;
• дату окончания;
• издателя;
• серийный номер;
• вариант с www;
• другие защищаемые поддомены.

Проверьте origin отдельно

curl -I \
    --resolve example.ru:443:203.0.113.10 \
    https://example.ru/

Эта проверка помогает отделить ошибку origin от проблемы внешней фильтрации. После ограничения firewall команда будет работать только с разрешенного административного адреса.

Проверьте реальный IP в журналах

Для Nginx:

sudo tail -f /var/log/nginx/access.log

Для Apache в Debian и Ubuntu:

sudo tail -f /var/log/apache2/access.log

Откройте сайт с известного внешнего подключения и сравните адрес в журнале. Если отображается только адрес reverse proxy, проверьте заголовок и доверенные сети.

Пройдите пользовательские сценарии

Проверьте не только статические страницы:

• вход в личный кабинет;
• административную часть CMS;
• формы обратной связи;
• поиск;
• корзину;
• оформление заказа;
• загрузку файлов;
• API;
• WebSocket;
• callback от платежных систем;
• обмены с внешними сервисами;
• долгие HTTP-запросы;
• фоновые задания.

Фильтрация может затронуть нестандартные методы HTTP, большие тела запросов, продолжительные соединения или автоматические обращения внешних систем.

Наблюдайте за сервером после переключения

uptime
free -h
df -h
sudo ss -s

Дополнительно контролируйте:

• ошибки Nginx или Apache;
• журналы приложения;
• ответы 403 и 429;
• ответы 499, 502, 503 и 504;
• число соединений;
• нагрузку PHP;
• состояние СУБД;
• статистику DDoS-Guard;
• время ответа до и после подключения.

Прямой тариф DDoS-Guard или модуль для ispmanager

Защиту сайта можно заказать непосредственно у DDoS-Guard. Отдельно существует совместный модуль DDoS-Guard для панели ispmanager. Оба варианта используют внешнюю фильтрацию, но различаются составом функций, способом управления и ограничениями.

Модуль для ispmanager подходит, когда сайт уже размещен на Linux VPS с этой панелью и требуется доступный вариант базовой внешней защиты одного домена.

Прямые тарифы DDoS-Guard подходят, если проекту нужен другой набор функций, несколько независимых доменов, расширенные правила, особые требования к поддержке или инфраструктура не использует ispmanager.

Как DDoS-Guard сочетается с BitNinja

DDoS-Guard и BitNinja работают на разных уровнях.

• DDoS-Guard фильтрует трафик во внешней инфраструктуре до передачи запросов на сайт.
• BitNinja устанавливается на Linux-сервер и защищает веб-приложения и серверные службы.

BitNinja может закрывать сценарии, которые не относятся к внешней DDoS-фильтрации:

• поиск вредоносных файлов;
• подозрительные обращения к веб-приложению;
• сканирование служб;
• атаки на CMS;
• блокировку вредоносных IP;
• исходящий спам;
• часть сценариев WAF.

Совместная схема может использоваться как многоуровневая защита: внешний трафик проходит через DDoS-Guard, а разрешенные запросы дополнительно контролируются средствами, работающими на Linux VPS.

Типичные ошибки и диагностика

Сайт не открывается после переключения

Проверяйте по уровням:

1. Какой адрес возвращает DNS.
2. Добавлен ли домен в защищаемый ресурс.
3. Правильно ли указан origin.
4. Работает ли Nginx или Apache.
5. Разрешено ли подключение от сетей reverse proxy.
6. Настроен ли внешний SSL-сертификат.
7. Нет ли прямой AAAA-записи.
8. Не сохранился ли старый адрес в DNS-кеше.

Возник циклический редирект

Цикл часто возникает по такой схеме:

Посетитель подключается по HTTPS
              │
              ▼
DDoS-Guard передает запрос на origin по HTTP
              │
              ▼
Origin перенаправляет запрос на HTTPS
              │
              ▼
Сценарий повторяется

Нужно проверить:

• протокол между DDoS-Guard и origin;
• заголовок исходной схемы;
• настройки доверенных прокси;
• правила редиректа в Nginx или Apache;
• настройки CMS и приложения;
• дублирующие правила в нескольких компонентах.

Не отключайте HTTPS-редирект на постоянной основе. Исправьте определение исходного протокола.

В журналах потерялся IP клиента

Проверьте:

1. Какой заголовок передает DDoS-Guard.
2. Поддерживает ли его веб-сервер.
3. Добавлены ли актуальные доверенные сети.
4. Использует ли формат журнала восстановленный адрес.
5. Не обращаетесь ли вы к origin напрямую во время теста.

После изменения создайте тестовый запрос с известного внешнего IP и сравните запись в журнале.

Origin остается доступен напрямую

Проверьте доступ по реальному адресу с передачей доменного имени:

curl -I \
    --resolve example.ru:443:203.0.113.10 \
    https://example.ru/

Если команда успешно работает с любого внешнего адреса, HTTP- или HTTPS-доступ к origin не ограничен.

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

Легитимный запрос блокируется

Для разбора соберите:

• точное время;
• URL;
• метод HTTP;
• IP клиента;
• код ответа;
• идентификатор события;
• заголовки;
• размер тела запроса;
• фрагмент журнала origin;
• описание ожидаемого результата.

Не отключайте всю фильтрацию из-за одного запроса. Сначала определите конкретное правило и оцените, безопасно ли создать узкое исключение.

Как отличить атаку от проблемы приложения

Для вывода нужны данные DDoS-Guard, сетевые метрики, журналы веб-сервера и показатели приложения. Один высокий показатель CPU не подтверждает DDoS-атаку.

Заключение

DDoS-Guard защищает сайт на Linux VPS, принимая HTTP- и HTTPS-трафик во внешней инфраструктуре и передавая на origin только разрешенные запросы. Такая схема снижает нагрузку на сервер и скрывает его реальный адрес от обычных посетителей.

Защита сайта не означает автоматическую защиту всего VPS. SSH, почта, VPN, СУБД и другие службы могут продолжать работать напрямую. Для них требуется собственная сетевая политика или отдельная услуга защиты.

Перед подключением нужно сохранить DNS-записи, проверить origin, определить схему HTTPS и зафиксировать все службы, использующие публичный IP. После переключения проверяются A и AAAA, внешний сертификат, реальный IP посетителя, пользовательские функции сайта и ограничения прямого доступа.

Прямые тарифы DDoS-Guard и совместный модуль для ispmanager используют сходный принцип фильтрации, но отличаются составом функций и ограничениями. Выбирать вариант нужно по архитектуре проекта, числу доменов и требованиям к защите, а не только по стоимости.

DDoS-фильтрация остается одним уровнем безопасности. Linux VPS по-прежнему нуждается в обновлениях, безопасном SSH, firewall, резервных копиях, мониторинге и защите веб-приложений.

Что почитать дальше

Для комплексной защиты Linux VPS будут полезны следующие материалы:

• BitNinja: многоуровневая защита Linux-сервера — как серверный агент защищает сайты, службы и файлы после прохождения внешнего трафика.
• Почему нельзя экономить на безопасности сервера — какие уровни защиты нужны помимо DDoS-фильтрации.
• Диагностика ошибок SSL-сертификата — как проверить домен, цепочку, SNI и сертификат на внешней точке HTTPS.

Когда стоит обратиться к специалистам

Подключение одного сайта можно выполнить самостоятельно, если понятны DNS, HTTPS, работа reverse proxy и правила firewall. Схема усложняется при нескольких доменах, IPv6, API, почте, внешних интеграциях и нескольких origin-серверах.

В IPWAY будет доступна управляемая схема защиты на базе Linux VPS, панели ispmanager, модуля DDoS-Guard и серверной защиты BitNinja. Модуль DDoS-Guard подключается как дополнение к ispmanager и предназначен для защиты сайтов, а BitNinja дополняет его средствами, работающими непосредственно на сервере.

Кратко

• DDoS-Guard фильтрует трафик до его передачи на Linux VPS.
• Защита сайта через reverse proxy не охватывает автоматически все службы сервера.
• Перед подключением нужно сохранить DNS и проверить origin напрямую.
• AAAA-запись может создать обход защиты по IPv6.
• Веб-сервер должен доверять реальному IP только от официальных сетей прокси.
• Прямой доступ к origin по HTTP и HTTPS нужно ограничить после проверки нового маршрута.
• Модуль для ispmanager отличается от прямых тарифов DDoS-Guard функциональностью и условиями.
• DDoS-фильтрация не заменяет firewall, WAF, обновления, мониторинг и резервные копии.