Почему фильтрация на edge меняет правила игры
Когда сервер приложения сам выполняет проверки безопасности, каждый вредоносный запрос всё равно доходит до него, потребляет CPU, открывает соединение с базой данных и конкурирует с реальными пользователями за ресурсы. cdn.com.tr переносит эту проверку на edge, поэтому попытки инъекций, зондирование сканерами и мусорный трафик отклоняются далеко от origin и никогда не касаются вашего кода или базы данных. Это разница между сервером, который падает под атакой, и тем, который её почти не замечает, потому что недобросовестная нагрузка поглощается распределённой сетью, созданной именно для этого.
Управляемый набор правил WAF
Веб-файрвол приложений проверяет метод запроса, путь, заголовки и тело на соответствие правилам, распознающим известные классы атак: SQL-инъекции, межсайтовый скриптинг, включение удалённых файлов, path traversal и command injection среди прочих. Эти правила поддерживаются централизованно, так что вы получаете обновления без редактирования собственной конфигурации, что особенно важно для таких платформ, как WordPress и устаревший PHP, где само приложение может медленно патчиться. Вы можете включить защиту по доменам и добавить поверх собственные правила разрешения и запрета для путей, специфичных для приложения.
Поглощение DDoS-флудов
Распределённая атака типа «отказ в обслуживании» пытается исчерпать вашу пропускную способность, отправляя намного больше трафика, чем способен обработать единственный origin. Поскольку cdn.com.tr выставляет ваш домен за распределённым edge, объёмные флуды распределяются по сети и фильтруются до того, как сконцентрируются на вашем сервере, а кэшированные ответы продолжают отдаваться с edge даже во время атаки. Практический результат в том, что ваш origin остаётся доступным для легитимных посетителей именно в те моменты, когда незащищённый сайт «лёг» бы.
Ограничение частоты запросов и защита от ботов
Не каждая угроза — это сигнатура; иногда это просто слишком много запросов от одного клиента. Ограничение частоты запросов позволяет ограничить, как часто IP может обращаться к чувствительным эндпоинтам вроде форм входа, сброса пароля или дорогих маршрутов API, что останавливает brute-force credential stuffing и агрессивный скрапинг, не блокируя обычных пользователей. В сочетании с правилами доступа по странам и IP это даёт способ остановить недобросовестную автоматизацию, которую пропустил бы файрвол, основанный только на сигнатурах, — и всё это настраивается по доменам из панели.
Скрытие origin устраняет обходной путь
Файрвол на edge работает только если атакующие не могут его обойти, а классическая ошибка — оставить origin-сервер доступным по его реальному IP. cdn.com.tr рекомендует заблокировать origin так, чтобы он принимал соединения только от edge, и держать его адрес вне публичного DNS, а значит единственный путь к вашему приложению проходит через уровень безопасности. Такое origin shielding превращает WAF из опциональной «лежачей полицейской» в обязательный контрольный пункт, а также сокращает поверхность атаки, доступную сканерам по всему интернету.
Единая политика безопасности для всех ваших приложений
Публикуете ли вы сайт на WordPress, устаревший портал на PHP или API на контейнерах — одна и та же модель edge-безопасности применяется, как только домен направлен через cdn.com.tr. Это значит, что не нужно поддерживать отдельный стек файрвола для каждого приложения: вы подключаете домен, включаете WAF, задаёте лимиты запросов, и политика защищает его единообразно. Для команд, работающих с несколькими сайтами или сервисами, эта согласованность делает безопасность управляемой, а не борьбой в каждом проекте по отдельности.
Как настроить, шаг за шагом
Направьте домен через edge
Добавьте хост в аккаунт CDN и направьте его DNS на edge cdn.com.tr. С этого момента каждый запрос к домену сначала попадает на edge-узел, что является обязательным условием для работы любой политики безопасности — файрвол помогает только если через него действительно проходит весь трафик.
Включите WAF для домена
Включите веб-файрвол приложений в панели для этого домена. Управляемый набор правил сразу начинает проверять запросы на типовые сигнатуры атак, такие как SQL-инъекции, межсайтовый скриптинг (XSS) и path traversal, без каких-либо изменений в вашем приложении.
Скройте и заблокируйте origin
Как только трафик начнёт идти через edge, ограничьте origin так, чтобы он принимал соединения только от cdn.com.tr, и перестаньте публиковать его реальный IP в публичном DNS. Это закрывает обходной путь, при котором атакующий бьёт напрямую по origin, минуя WAF полностью.
Добавьте лимиты запросов и правила доступа
Настройте ограничение частоты запросов на чувствительных эндпоинтах, таких как /wp-login.php, /xmlrpc.php или маршрут аутентификации вашего API, и добавьте правила разрешения/запрета по странам или IP, где нужно. Это останавливает brute-force и скрапинг до того, как они израсходуют ресурсы приложения.
Подтвердите TLS и принудительный HTTPS
После настройки Auto SSL включите редирект на HTTPS, чтобы каждый запрос апгрейдился до TLS на edge. Это гарантирует, что трафик, проверяемый и перенаправляемый к origin, зашифрован сквозным образом для посетителей.
Наблюдайте, затем настраивайте
Просматривайте, что блокирует WAF, убедитесь, что легитимный трафик не попадает под блок, и корректируйте правила или исключения для редких ложных срабатываний. Безопасность — это политика, которую вы постепенно уточняете, а не переключатель, который включается один раз, и панель даёт видимость, чтобы делать это безопасно.
Примеры сценариев
Сайт на WordPress включает WAF и ограничивает частоту запросов к /wp-login.php и /xmlrpc.php, отсекая brute-force ботов на edge, так что процесс PHP и база данных вообще не затрагиваются атакующим трафиком.
JSON API на контейнерах публикуется с включённым WAF и лимитами запросов по маршрутам, так что попытки скрапинга и инъекций фильтруются до того, как достигнут сервиса, а origin заблокирован так, что принимает только соединения от edge.
Перед резонансным запуском сайт полагается на поглощение DDoS на edge и кэшированную доставку, так что внезапный всплеск — реальные посетители это или атака — распределяется по сети, а не обрушивает origin.
Часто задаваемые вопросы
Нужно ли менять код приложения, чтобы использовать WAF?
Нет. Файрвол работает на edge, на пути запроса, поэтому проверяет и блокирует трафик до того, как он достигнет вашего приложения. Вы включаете его по доменам в панели; ваш код, фреймворк и конфигурация сервера остаются точно такими же.
Какие атаки WAF реально останавливает?
Управляемый набор правил нацелен на распространённые классы веб-атак, включая SQL-инъекции, межсайтовый скриптинг, path traversal, включение удалённых файлов и command injection, плюс недобросовестный объём через ограничение частоты запросов. Он предназначен для перехвата автоматизированного зондирования и попыток эксплуатации, составляющих основную массу враждебного веб-трафика.
Могут ли атакующие обойти WAF, обратившись напрямую к origin?
Только если вы оставите origin открытым. Рекомендуемая настройка блокирует origin так, чтобы он принимал соединения только от edge cdn.com.tr, и держит его реальный IP вне публичного DNS, поэтому единственный путь к вашему приложению проходит через уровень безопасности, а атаки напрямую на origin отсекаются.
Может ли WAF по ошибке заблокировать легитимных посетителей?
Ложные срабатывания возможны у любого файрвола, поэтому панель позволяет видеть, что блокируется, и добавлять исключения для конкретных путей или клиентов. Практический подход — включить защиту, понаблюдать за результатами и настроить правила так, чтобы настоящий трафик проходил, а атаки оставались заблокированными.
Чем защита от DDoS отличается от WAF?
Они решают разные задачи. WAF проверяет содержимое отдельных запросов на вредоносные шаблоны, тогда как защита от DDoS справляется с чистым объёмом, распределяя и поглощая флуды по распределённому edge. Серьёзная атака часто включает и то, и другое, поэтому оба уровня работают вместе перед вашим origin.
Замедляет ли включение защиты работу сайта?
Edge уже находится на пути запроса ради кэширования, поэтому добавление проверки WAF там не создаёт отдельного хопа, а кэшированные ответы по-прежнему отдаются быстро. На практике тот же уровень, что защищает вас, вас же и ускоряет, поскольку заблокированный и кэшированный трафик никогда не нагружает origin.