«Стоит ли поставить CDN перед сервером?» — первый вопрос, который задаёт себе большинство людей после покупки офшорного сервера, и у него нет единого ответа, потому что на самом деле это два вопроса под одной обложкой. Отражение атаки и сохранение анонимности — разные задачи с разными решениями, и договорённость, решающая одну из них, может незаметно свести на нет другую.
Эта путаница дорого обходится в обоих направлениях. Одни ставят крупный американский CDN перед контентом, ради которого выбрали хостинг, игнорирующий DMCA, и тем самым возвращают канал для жалоб именно тому посреднику, которого пытались избежать. Другие не делают вообще ничего, получают флуд на уровне приложений, который сетевая фильтрация в принципе не способна увидеть, и делают вывод, что защита от DDoS — обман. Это руководство разделяет две задачи, объясняет, что на самом деле делает каждый уровень защиты, и большую часть текста посвящает тому, что решает исход в любом случае: шести способам, которыми исходный адрес утекает, даже когда всё остальное настроено правильно.
Две задачи, которые выглядят как одна
Всё, что вы ставите перед сервером, выполняет одну из двух задач: удерживает атаку подальше от него или удерживает в тайне его адрес. Эти задачи достаточно похожи, чтобы их путали, и достаточно различны, чтобы решение не той из них было пустой тратой денег.
| Что вас беспокоит | Что это действительно решает | Что не решает |
|---|---|---|
| Объёмный флуд, забивающий ваш канал (уровни 3 и 4) | Фильтрация на периметре сети хостера, включена в каждый тариф | Ничего из того, что вы установите на сервере, — к этому моменту канал уже заполнен |
| Прикладной флуд запросов, которые выглядят настоящими (уровень 7) | CDN или WAF, кеширование, ограничение частоты запросов, более дешёвые эндпоинты | Пакетная фильтрация — она видит корректный HTTP и пропускает его |
| Сервер не должен быть доступен напрямую | Фронт (CDN или собственный узел) плюс файрвол, пропускающий только его | Один лишь CDN, если источник по-прежнему отвечает всему интернету |
| Никто не должен узнать, кто им управляет | Регистрация без KYC, приватная оплата, дисциплина в ведении аккаунтов | Любой объём инфраструктуры — это вопрос идентичности, а не техники |
| Контент должен пережить жалобы | Юрисдикция и хостер, который не реагирует на них | CDN, который добавляет канал для жалоб, а не убирает его |
Перечитайте последнюю строку дважды — именно на ней люди чаще всего ошибаются. Всё остальное на этой странице — инженерия. Эта строка — нет.
Что уже делает ваш хостер и где это заканчивается
Фильтрация уровней 3 и 4 включена в каждый тариф, который мы продаём, без доплаты, и работает на периметре сети, а не на вашем сервере — это единственное место, где она вообще может работать, поскольку насыщенный канал невозможно исправить чем-либо, запущенным позади него. Трафик безлимитный, поэтому атака не превращается в счёт. Для подавляющего большинства того, что люди называют «DDoS», на этом история заканчивается.
Того, что она не видит, — другого рода. Пятьсот запросов в секунду к поисковому эндпоинту с сорока тысяч домашних адресов — это не искажённый трафик, это просто трафик. Slowloris-соединения, по одному заголовку раз в несколько секунд каждое, сами по себе выглядят пристойно. Форма входа, забрасываемая настоящими POST-запросами, на уровне пакетов неотличима от загруженного понедельника. Пакетный фильтр здесь бессилен, потому что с пакетами всё в порядке.
Есть одно направление трафика, по которому мы всё же вмешиваемся, и об этом стоит сказать прямо: атаки и массовый спам, исходящие из нашей сети, могут блокироваться через null-route, чтобы сохранить работоспособность остальной инфраструктуры. Это операционная мера, а не содержательная — подробнее это различие раскрыто в нашем руководстве о хостинге, игнорирующем DMCA.
Что скрывает CDN — и какой канал для жалоб вы получаете в придачу
Механизм прост и по-настоящему эффективен. Ваш домен резолвится в адреса провайдера, клиенты подключаются к ним, а провайдер сам забирает данные с вашего источника. Реальный адрес никогда не появляется в соединении клиента, поэтому его не может атаковать тот, кто знает только домен. Тот же приём объясняет, почему прикрытие CDN работает для прокси, устойчивых к цензуре: цензор видит трафик к адресу, который он не может позволить себе заблокировать.
Вместе с этим приходят три вещи, и ни одна не спрятана в мелком шрифте:
- TLS терминируется на периметре провайдера. Внутри сети провайдера трафик — открытый текст, так и задумано: именно это позволяет работать кешированию и фильтрации. Всё, что вводят ваши пользователи, попадает к третьей стороне раньше, чем к вам.
- Канал для жалоб, которого раньше не было. Жалобы можно подавать напрямую на CDN, и CDN на них реагирует: пересылает вам, называет вашего хостера или отключает вас. Если вы выбрали офшор именно потому, что жалобы уходят в никуда, размещение американского посредника впереди заново соединяет цепочку, за разрыв которой вы заплатили.
- Аккаунт. Адрес электронной почты, способ оплаты, часто номер телефона — всё это привязано к вашему домену и хранится бессрочно. Подробнее об этом ниже, потому что обычно это самое слабое звено во всей схеме.
Ничто из этого не делает CDN неправильным выбором. Это лишь решение с двумя сторонами: отличное для магазина или приложения с реальными пользователями и реальной нагрузкой уровня 7, и откровенно контрпродуктивное для публикаций, которые привлекают жалобы на удаление. Наш собственный ответ на этот вопрос на странице о хостинге, игнорирующем DMCA, всегда был короткой версией того же самого: для устойчивости к удалению используйте уже имеющуюся у вас сетевую фильтрацию и обойдитесь без CDN.
Шесть способов, которыми исходный адрес всё равно утекает
Это самый важный раздел, потому что скрытность — не товар, который покупают, а свойство, которое либо поддерживают, либо теряют, обычно в течение нескольких дней, из-за одной из шести причин. Исходные серверы находят каждый день даже за безупречно настроенным CDN.
- Журналы Certificate Transparency. Каждый публично доверенный сертификат, выданный для вашего домена, в течение нескольких минут публикуется в открытых, постоянных и доступных для поиска журналах. Публикуют не ваш адрес, а ваши имена хостов —
staging,mail,vpn, поддомен, который вы однажды настроили ещё в 2024 году. Каждое из них — кандидат на резолвинг, и достаточно одной записи, не указывающей на фронт, чтобы всё закончилось. - История DNS. Сервисы passive-DNS архивируют каждый адрес, в который когда-либо резолвился ваш домен. Переход за CDN впоследствии не отменяет публикацию уже записанного — скрытность должна начинаться до первого резолвинга домена, иначе вам нужен новый адрес, а не новый фронт.
- Записи, которые нельзя проксировать, и те, что вы забыли. Записи почтовых серверов должны указывать на что-то доступное. То же касается забытой записи
AAAA, если вы проксировали только IPv4, старого имени хоста для FTP или панели, wildcard-записи или «временного» тестового сервера, которому уже три года. - Всё, что отправляет сервер. Письмо с источника несёт его адрес в заголовках
Received— письмо о сбросе пароля само раскрывает адрес. Вебхуки, исходящая загрузка изображений, превью ссылок, пингбэки, проверки обновлений и системы отчётов о сбоях — всё это обращается наружу с реального адреса, и его узнает любой, кто заставит ваше приложение обратиться к контролируемому им хосту. - Сканирование всего интернета. Каждый адрес IPv4 непрерывно сканируется и индексируется публичными сервисами, а результаты доступны для запроса за секунды. Если ваш источник отвечает на порту 443 вашим сертификатом или отдаёт главную страницу на любой заголовок Host, найти совпадение — вопрос одного запроса по хешу тела страницы, отпечатку сертификата или хешу favicon. Так находят большинство исходных серверов, и это ничего не стоит тому, кто ищет.
- Приложение, которое рассказывает о себе. Абсолютные URL и редиректы с необработанным адресом внутри, открытые эндпоинты статуса или метрик, подробные трассировки стека с именами внутренних хостов, заголовки, раскрывающие бэкенд, и виртуальный хост по умолчанию, который с готовностью отдаёт ваш сайт любому, кто обратится по адресу.
Как закрыть источник так, чтобы к нему мог обращаться только фронт
Скрытность, которая держится лишь на том, что никто не угадает адрес, — не скрытность вообще. Схема работает только тогда, когда источник отказывается разговаривать с кем угодно, кроме фронта, — тогда утёкший адрес становится досадной мелочью, а не событием.
- Запрет по умолчанию, затем разрешение для фронта. Принимайте 80 и 443 только с опубликованных диапазонов адресов провайдера и обновляйте этот список автоматически — диапазоны меняются, а устаревший список откроется или закроется в самый неподходящий момент. Всё остальное, включая SSH, должно жить в туннеле или на управляющем адресе, как описано в нашем чек-листе для первого часа настройки VPS.
- Аутентифицируйте фронт. Клиентские сертификаты между CDN и вашим источником — обычно называемые authenticated origin pulls — означают, что даже верный адрес вместе с верным заголовком Host не даёт ничего без сертификата.
- Лучше: вообще без входящих портов. Исходящий туннель от источника к периметру — будь то собственный коннектор CDN или WireGuard до узла, которым управляете вы, — означает, что источник никогда не слушает на публичном интерфейсе. Сканирование не найдёт то, что не отвечает, и это самая надёжная версия всей схемы.
- Один виртуальный хост, один заголовок Host. Сервер по умолчанию не должен возвращать ничего полезного. Если ваш сайт открывается по адресу, сканер найдёт совпадение в течение недели.
- Уберите почту с веб-источника. Почта обязана быть доступной и обязана себя идентифицировать; держите её на отдельной машине, как и предполагает наше руководство по почтовому серверу.
- Проверяйте извне. Любая проверка из этого списка бессмысленна, если запущена с самого сервера. Тестируйте из сети, которая вам не принадлежит.
Собственный фронт-узел вместо CDN
Третий вариант обычно пропускают, потому что у него нет маркетингового бюджета: небольшой VPS в роли публичного лица, зашифрованный туннель обратно к машине, которая хранит данные, и nginx или HAProxy, передающие трафик между ними. Снаружи это выглядит как обычный веб-сервер. Настоящий сервер находится где-то ещё, и у него вообще нет входящих портов.
Вы получаете скрытность без посторонних участников схемы — без стороннего аккаунта, без внешнего канала для жалоб, без чужака, терминирующего ваш TLS. Вы также получаете разделение по юрисдикциям, которое иначе трудно купить: фронт там, где пользователи, данные там, где закон вам подходит, выбранные из наших семи локаций. А поскольку при регистрации не была привязана никакая личность, фронт одноразовый — сожжённый адрес заменяется за минуты, а не выторговывается.
Чего вы не получаете — так это ёмкости anycast-сети. У одного узла ёмкость одного узла, и хотя наша сетевая фильтрация защищает его точно так же, как и любой другой сервер, по-настоящему крупная объёмная атака — это состязание по пропускной способности, которое выигрывает глобальная сеть. Честная позиция такова: фронт-узел — правильный ответ для сокрытия тяжёлого или дорогого бэкенда — хранилища, GPU-сервера, почтового сервера, базы данных — и для разделения юрисдикций. Он не заменяет CDN при устойчивой нагрузке уровня 7.
Выбор в одной таблице
| Ваша ситуация | Схема | Обоснование |
|---|---|---|
| Публикации, привлекающие жалобы на удаление | Напрямую, без CDN, в осознанно выбранной юрисдикции | CDN добавляет канал для жалоб, которого у вашего хостера намеренно нет |
| Магазин или SaaS с реальными пользователями и нагрузкой уровня 7 | CDN спереди, источник закрыт только для его диапазонов | Уровень 7 — это именно та задача, для которой создан CDN |
| Конечная точка обхода блокировок в стране с цензурой | Прикрытие через CDN | Цензор видит адрес, который не может позволить себе заблокировать |
| Большой объём статического или медиатрафика | CDN для разгрузки через кеш | Суть в пропускной способности и задержке; скрытность — побочный эффект |
| Анонимность — главное требование | Собственный фронт-узел или вообще ничего спереди | Сторонний аккаунт — это идентификационная запись, которой раньше не было |
| Тяжёлый бэкенд, который стоит скрыть | Фронт-узел плюс исходящий туннель | Дорогая машина никогда не появляется в публичном интернете |
Аккаунт — обычно самое слабое звено
Рассмотрите ситуацию, когда инфраструктура безупречна, а бумажная сторона — нет. За сервер заплатили Monero, без документов, удостоверяющих личность, и без адреса электронной почты — схема, описанная на наших страницах о хостинге без KYC. Затем открывается аккаунт CDN с картой, личным адресом и номером телефона, с указанием домена, который он защищает. Этот аккаунт — более прочная и долговечная идентификационная запись, чем что-либо на сервере, и хранится он компанией, которая отвечает на повестки, — это полностью сводит на нет приватность оплаты.
Исправление несложное, просто его легко забыть: если цель — анонимность, то либо фронт принадлежит вам, либо аккаунт перед ним настолько же одноразовый и неатрибутируемый, как и сервер за ним. Опсек сервера подробно разбирает эту дисциплину, а наш честный ответ об анонимности офшорного хостинга прямо говорит о том, какие звенья цепи обычно рвутся первыми. Почти никогда — технические.
Проверка собственной уязвимости за десять минут
Каждый из пунктов ниже — то, что заинтересованная сторона проверит в первые же минуты. Проверьте их сами, с машины, которая не является сервером, до того, как вам понадобятся ответы.
- Составьте список всех имён хостов, на которые вы когда-либо получали сертификат. Найдите свой корневой домен в поисковике по Certificate Transparency и зарезолвьте каждый результат. Всё, что не указывает на фронт, — утечка, включая хосты, которыми вы больше не пользуетесь.
- Изучите собственную историю DNS. Запрос к passive-DNS покажет адреса, в которые резолвился ваш домен до CDN. Если вчерашний источник — это и сегодняшний источник, скрытности никогда не было.
- Спросите источник напрямую.
curl -sI --resolve example.com:443:198.51.100.10 https://example.com/— если сайт отвечает, ваш файрвол не ограничивает доступ фронтом, и любой, у кого есть адрес-кандидат, подтвердит это одним запросом. - Спросите его грубо.
curl -skI https://198.51.100.10/не должен вернуть ничего узнаваемого. Виртуальный хост по умолчанию, отдающий вашу главную страницу, — самая частая ошибка из всех перечисленных здесь. - Проверьте все типы записей, а не только A.
dig +short AAAA example.com,dig +short MX example.comи то же самое для каждого поддомена, обнаруженного в журналах прозрачности. Непроксированный IPv6 — классика жанра. - Отправьте себе письмо из приложения. Запустите сброс пароля и прочитайте всю цепочку заголовков
Received. Если адрес источника там есть, значит, он есть и в каждом письме, которое вы когда-либо отправляли. - Убедитесь, что порты закрыты. Из посторонней сети команда
nmap -Pn -p80,443 198.51.100.10должна показать filtered, а не open. - Проверьте по сканерам. Найдите отпечаток своего сертификата и хеш favicon главной страницы в публичном индексе сканирования интернета. Если ваш источник проиндексирован, именно так его и найдут.
Если адрес уже сожжён
Считайте, что он сожжён навсегда. Адрес, попавший в passive-DNS и в индексы сканирования, остаётся в постоянной публичной записи, и никакое изменение конфигурации это не отменит. Ответные действия — механические, а не хитрые.
- Сначала устраните утечку. Переход на новый адрес без закрытия дыры воспроизведёт ту же ситуацию в течение нескольких дней, и вы потратите миграцию, ничему не научившись.
- Затем переезжайте. Разверните замену — в другой юрисдикции, если причина была юридической, а не технической, — восстановите данные и переключитесь. Поскольку с первым сервером не была связана никакая личность, это чистый старт, а не переговоры, — практичный, неброский результат покупки серверов без истории аккаунта.
- Подготовьте переключение заранее, до чрезвычайной ситуации. Короткий TTL DNS-записи, конфигурация, которую можно развернуть заново из репозитория, и протестированное восстановление превращают тяжёлый день в двадцать минут. Этим не занимаются во время атаки.
- Правильно выведите старый адрес из эксплуатации. Не оставляйте старый сервер на старом адресе с тем же содержимым — это живое подтверждение для любого наблюдателя, и оно поддерживает запись свежей.
Коротко
Сетевая фильтрация справляется с объёмными атаками, идёт вместе с сервером и не стоит ничего сверх этого. CDN справляется с прикладным уровнем и скрывает источник ценой посредника, который терминирует ваш TLS, отвечает на жалобы и знает, кто вы. Собственный фронт-узел покупает скрытность без посредника, но без глобальной ёмкости. Юрисдикция решает правовой вопрос, и ни один из трёх вариантов его не затрагивает. И все три сводятся на нет одной непроксированной записью, одним письмом с источника или одним виртуальным хостом по умолчанию.
Выбирайте исходя из цели, а не по привычке, а затем потратьте десять минут на аудит — он находит больше реальной уязвимости, чем любое обновление тарифа. Если вам нужна такая архитектура без третьей стороны, небольшой VPS в роли фронта и вся настоящая работа на выделенном сервере позади него — схема, которую мы чаще всего видим у тех, кого уже однажды нашли.