Как да активирате режима "Under Attack" на Cloudflare при DDoS атака?

Режимът "Under Attack" на Cloudflare е спешна защитна настройка, която филтрира трафика от ботове, показвайки на посетителите кратка проверка за сигурност. Чрез избиране на вашия сайт в Cloudflare панела и активиране на функцията "Under Attack Mode" в секцията Security, можете да забавите интензивните HTTP/HTTPS заявки в рамките на няколко минути, да защитите достъпа на реални потребители до сайта и да намалите натоварването на сървъра си. Важно е обаче да се отбележи, че този режим не е дългосрочно решение; той трябва да бъде комбиниран с правилните настройки на DNS прокси, WAF правила, ограничаване на скоростта, конфигурация на кеша и сигурността на произходния сървър.

В това ръководство ще разгледаме как да активирате режима "Under Attack" на Cloudflare, кога трябва да се използва, какви настройки трябва да го подкрепят и как безопасно да се върнете към нормалната работа след приключване на атаката. Целта е да предоставим приложим контролен списък, който да се прилага в момент на паника и да възстановим достъпността на вашия сайт възможно най-бързо.

Какво е режимът "Under Attack" на Cloudflare?

Режимът "Under Attack" на Cloudflare е спешно ниво на сигурност, предоставено от Cloudflare. Когато бъде активиран, Cloudflare подлага браузерите на посетителите на сайта на кратка проверка. Тази проверка обикновено отнема само няколко секунди и затруднява директното натоварване на сайта от автоматизирани ботове, инструменти за HTTP наводнения или злонамерени клиенти, извън браузъра.

Основната цел на този режим е да облекчи атаките на ниво приложение или Layer 7. Например, ако основната страница получава хиляди GET заявки в секунда, а страницата за вход в WordPress е подложена на интензивни POST опити, режимът "Under Attack" предоставя бърза първа реакция.

Важно е да се отбележи, че режимът "Under Attack" филтрира уеб заявките; обаче, ако IP адресът на вашия сървър е директно целен, или ако услугите ви извън Cloudflare са изложени, или атаката е на ниво Layer 3/4, ще са необходими допълнителни мерки. Затова е критично важно DNS записите да са проксирни през Cloudflare, IP адресът на произхода да бъде скрит и да се приложат правилните мерки за сигурност на хостинг страната. За сигурен избор на инфраструктура може да се свържете с Услуги за сигурен уеб хостинг и инсталация на SSL сертификат.

Симптоми на DDoS атака: Какво да проверите преди да активирате режима "Under Attack"?

Не всяко забавяне е DDoS атака. Понякога, неправилният плъгин, заключване на базата данни, висока CPU употреба от cron задачи или неправилни настройки на кеша могат да доведат до подобни резултати. Затова е полезно да направите бърза диагностика преди да активирате режима "Under Attack". Въпреки това, ако сървърът не може да отговори, потребителите получават грешки 502, 503, 504 и в логовете има необичайна експлозия на заявки, режимът трябва да бъде активиран незабавно.

Типични признаци на DDoS атака

• Рязко увеличение на трафика, което е 5, 10 или 50 пъти над нормалното за кратко време.
• Получаване на стотици заявки в секунда на една страница или крайна точка.
• Трафик от различни държави с подобни стойности на user-agent.
• Целеви URL адреси с високи разходи, като admin, login, search, cart в WordPress, WooCommerce, OpenCart или персонализирани софтуерни решения.
• Изчерпване на лимитите на CPU, RAM, PHP-FPM работници или MySQL връзки на сървъра.
• Рязко покачване на грешките 4xx и 5xx в Cloudflare Analytics.
• Истински потребители, които имат периодичен достъп до сайта, но бот трафикът изпраща постоянни заявки.

Например, ако един електронен магазин, който обикновено получава 2000 заявки на минута, достига 80000 заявки на минута в рамките на 10 минути, и 70% от тези заявки отиват към страницата за пазаруване или търсене, това е ясен знак за атака на Layer 7. В този сценарий режимът "Under Attack" трябва да бъде активиран в първите 5 минути, след което да се добавят специфични WAF и правила за ограничаване на скоростта за целевите URL адреси.

Кога трябва да се използва режимът "Under Attack" на Cloudflare?

Режимът "Under Attack" на Cloudflare не е стандартна защитна настройка, която трябва да бъде постоянно активна. Тъй като той показва кратък екран на изчакване дори на реални посетители. Това може да повлияе на потребителския опит, особено на страниците, ориентирани към конверсия, в стъпките за плащане или в структури, които използват API. Най-добрата практика е да се активира временно по време на атака и след това да се пренастрои нивото на сигурност, когато трафикът се нормализира.

Подходящи ситуации за използване

• Ако сайтът получава интензивни и аномални HTTP/HTTPS заявки.
• Ако ресурсите на сървъра бързо се изчерпват и се увеличават грешките 502/503.
• Ако Cloudflare WAF все още не е конфигуриран с конкретни правила и е необходим бърз щит.
• Ако бот трафикът е значително по-висок от реалния потребителски трафик.
• Ако целевите уеб страници, формуляри, екрани за вход или крайни точки за търсене са под атака.

Ситуации за внимателно използване

• Ако се използва интензивен трафик от мобилни приложения, платежни услуги, webhook или API.
• Ако сте в период, в който ботът на търсачката извършва критични сканирания.
• Ако корпоративните ви потребители достъпват от стари браузъри или ограничени мрежови среди.
• Ако имате поддомейни, които не са зад проксито на Cloudflare.

Ако режимът "Under Attack" се прилага за целия домейн на сайтове с API трафик, някои интеграции могат да бъдат неуспешни. Затова, ако е възможно, трябва да се планират специални WAF правила, allowlist или различно ниво на сигурност за поддомейни на API. За подробен наръчник относно сигурността на API, можете да се запознаете с Ръководство за безопасност на API и ограничаване на заявките.

Как да активирате режима "Under Attack" на Cloudflare? Стъпка по стъпка приложение

Следващите стъпки представляват практичен контролен списък, подготвен за бързо действие по време на атака. Интерфейсът на Cloudflare може да показва малки промени с времето; обаче логиката остава същата: избирате домейна си, повишавате нивото на сигурност и валидирате входящия трафик през Cloudflare.

1. Влезте в Cloudflare акаунта си

Първо, влезте в Cloudflare акаунта си и изберете домейна, който е под атака. Уверете се, че работите върху правилната зона, ако управлявате множество домейни. Активирането на режима "Under Attack" на погрешен домейн ще загуби време и атаката ще продължи.

2. Проверете дали DNS записите са проксирни

За режимът "Under Attack" да бъде ефективен, уеб трафикът трябва да преминава през Cloudflare. Уверете се, че A, AAAA и CNAME записите в секцията DNS са с оранжево облаче, т.е. проксирни. DNS записи с сиво облаче (DNS only) не преминават през защитния слой на Cloudflare. Особено проверете www, коренния домейн и използваните поддомейни.

Ако IP адресът на произхода ви е видим в интернет, нападателите могат да заобиколят Cloudflare и да атакуват директно сървъра. Затова е силно допълнително предпазно средство да разрешите HTTP/HTTPS трафик само от IP диапазоните на Cloudflare в защитната стена на сървъра. Можете да получите помощ от вашия хостинг доставчик за това или да се насочите към Как се правят настройки на DNS за Cloudflare ръководство.

3. Активирайте режима "Under Attack" от секцията Security

След като отворите съответния домейн в Cloudflare панела, намерете опцията "Under Attack Mode" в екрана Security или Overview. Когато активирате тази опция, Cloudflare започва да показва на посетителите на сайта кратка страница за проверка. В някои панели тази настройка може да се вижда под Security Level като "I am Under Attack".

След активирането, промените обикновено влизат в сила бързо. В първите минути е необходимо да се следят Cloudflare Analytics, Security Events и консумацията на ресурси на сървъра. Ако CPU и броят на връзките започнат да намаляват, режимът работи. Въпреки това, ако грешките продължават да се увеличават, трябва да се напишат допълнителни правила.

4. Тествайте опита на реалните потребители

След активиране на режима, тествайте сайта от различни мрежи. Необходимо е да се опитате да достъпите начната страница, страницата на продукта, страницата за вход и плащането от мобилен интернет, офис мрежа и, ако е възможно, от различна локация. Очакваният резултат е, че след екрана за проверка потребителят може да достъпи сайта. Ако потребителите попадат в безкраен цикъл на проверка, трябва да се проучат настройки, които блокират бисквитките, съвместимост на браузъра или конфликти с правилата за сигурност на Cloudflare.

5. Определете целевите URL адреси на атаката

Режимът "Under Attack" осигурява обща защита; обаче истинската ефективност идва от специфични правила за целите. Намерете най-често поисканите пътища в Cloudflare Security Events, Web Analytics, логовете за достъп на хостинга и логовете на приложението. Например, URL адреси като /wp-login.php, /xmlrpc.php, /search, /cart, /api/login или /checkout могат да бъдат под атака.

След като целевият URL адрес е определен, могат да бъдат предприети действия с WAF Custom Rules въз основа на критерии като държава, user-agent, метод на заявката, URI path или бот скор. Например, на IP адреси, които изпращат повече от разумен брой заявки в минута към определен входен край, може да им бъде приложен managed challenge. За WordPress сайтове, връзката Мерки за сигурност на WordPress представлява естествена възможност за вътрешна връзка.

Разлики между режима "Under Attack" и другите опции за сигурност на Cloudflare

Инструментите за сигурност на Cloudflare служат за различни цели. Режимът "Under Attack" е бърз и общ спешен филтър; WAF и ограничаването на скоростта предлагат по-целенасочени, устойчиви и по-балансирани решения за потребителския опит.

В практиката добрият подход за защита следва следния ред: Първо, режимът "Under Attack" намалява спешния натиск, след това се анализира моделът на атаката, добавят се правила за WAF и ограничаване на скоростта, и накрая, с конфигурации на кеша и защитната стена на произхода, защитата се укрепва.

Препоръчителни допълнителни настройки на Cloudflare по време на атака

Въпреки че режимът "Under Attack" може да бъде активиран с натискане на един бутон, успехът на защитата срещу DDoS зависи от поддържащите настройки. Следните предложения са най-често полезните приложения в реалните операции.

Създайте целенасочена защита с WAF правила

Cloudflare WAF ви позволява да предприемате действия въз основа на определени условия. Например, можете да приложите предизвикателство за POST заявки, идващи само на страницата /wp-login.php от определени държави. По този начин изолирате целта на атаката, без да натоварвате целия сайт.

• Отворете страниците за администратори и вход само за определени държави или IP диапазони.
• Блокирайте ненужни крайни точки, като XML-RPC.
• Приложете managed challenge за подозрителни стойности на user-agent.
• Ограничете клиентите, които правят твърде много заявки на определен URI path, с rate limit.

Настройте правилно нивото на кеширане

По време на DDoS атака, ако произходният сървър трябва да отговаря на всяка заявка, ресурсите бързо се изчерпват. Статичните файлове, изображения, CSS, JavaScript и кешируеми страници трябва да се обслужват от Cloudflare edge. В динамични структури като WordPress, плъгин за кеширане на страници, правила за кеширане на Cloudflare и подходящи заглавия cache-control могат да се използват заедно.

Например, на сайт с новини или блог, страниците, показвани на анонимни посетители, могат да бъдат кеширани за 5 до 30 минути. Тази проста настройка намалява TTFB стойностите дори в периоди извън атаката и облекчава ресурсите на хостинга. На темата за производителност можете да разгледате Ръководство за ускоряване на уебсайт.

Определете реалистични прагове за ограничаване на скоростта

Ограничаването на скоростта е особено ефективно на разходни крайни точки. Но ако праговете са определени произволно, истинските потребители могат да бъдат блокирани. Например, на страница за търсене на продукт, нормален потребител може да направи 5-15 търсения на минута; 100 търсения на минута е ненормално. На страницата за вход, 10 неуспешни опити в рамките на 5 минути е подозрително в повечето сценарии.

Примерен подход: за /wp-login.php може да се приложи managed challenge на IP адреси, които правят повече от 10 заявки на минута, а на IP адреси, които правят повече от 50 заявки за 5 минути, може да им се наложи временно блокиране. За API крайни точки трябва да се предпочитат по-прецизни лимити на базата на потребителска сесия, IP адрес, токен и метод.

Скрийте IP адреса на произхода и го ограничете с защитна стена

Една от най-критичните грешки, когато се използва Cloudflare, е оставянето на IP адреса на произхода видим. Стари DNS записи, поддомейни, работещи с директен IP, уеб услуги, смесени с имейл записи, или компрометирани конфигурации могат да позволят на нападателите да достигнат до сървъра извън Cloudflare.

Сървърната страна трябва да отвори портове 80 и 443 само за IP диапазоните на Cloudflare. Освен това, SSH, панел, база данни и управляеми портове не трябва да остават отворени за интернет; трябва да се използват ограничения на IP, силни пароли, 2FA и, ако е възможно, VPN. Можете да се свържете с Настройки за безопасност на cPanel и конфигурация на защитна стена за VPS за сигурност на хостинга.

Специфични точки на внимание за WordPress, WooCommerce и корпоративни сайтове

Всеки уебсайт не притежава еднаква структура на трафика. Един блог сайт, магазин на WooCommerce и SaaS панел могат да доведат до различни резултати при активиране на режима "Under Attack" на Cloudflare. Затова критичните пътища трябва да бъдат определени в зависимост от типа сайт.

WordPress сайтове

Най-често целевите файлове в WordPress са пътищата /wp-login.php и /xmlrpc.php. Ако не използвате XML-RPC, блокирането му обикновено е безопасно. За администраторския панел може да се приложи ограничение по държава или IP. Освен това, правилата на Cloudflare не трябва да влизат в конфликт с плъгини за сигурност; твърде много механизми за предизвикателство могат да поставят потребителя в цикъл на проверка.

WooCommerce магазини

Страниците за количка, плащане и акаунт в WooCommerce изискват внимание. Тъй като тези страници са динамични, не трябва да се прилага агресивно кеширане. Докато режимът "Under Attack" е активен, уверете се, че URL адресите за обратни повиквания или webhook на платежния доставчик работят. Ако е необходимо, IP диапазоните на платежния доставчик трябва да бъдат добавени в allowlist или за съответния крайна точка трябва да бъде написано специално правило.

Корпоративни сайтове и сайтове, използващи API

Корпоративни портали, интеграции с CRM и мобилни приложения API може да не могат да обработят екрана за проверка на JavaScript. В такива случаи, вместо да прилагате режима "Under Attack" за целия домейн, е по-подходящо да управлявате поддомейна на API отделно. Например, докато www.example.com има активиран режим "Under Attack", за api.example.com може да бъде приложена сигурност, базирана на токен, ограничаване на скоростта и allowlist.

Метрики за наблюдение след активиране на режима "Under Attack"

За да разберете дали едно защитно средство работи, е необходимо числово наблюдение. Просто да можете да отворите сайта не е достатъчно; процентите на грешки, натоварването на сървъра и поведението на реалните потребители трябва да бъдат оценени заедно.

• Cloudflare Security Events: Показва колко заявки са били предизвикани или блокирани от какви правила.
• HTTP статус кодове: Трябва да се наблюдават промените в грешките 403, 429, 502, 503 и 504.
• Използване на CPU и RAM на сървъра: Очаква се спад след режима "Under Attack".
• PHP-FPM и MySQL връзки: Показва облекчението на приложеното ниво.
• Широчина на лента и брой заявки: Трябва да се сравни обемът на трафика с процента на филтрираните заявки.
• Реални преобразувания на потребителите: Трябва да се тестват изпращания на формуляри, поръчки, вход и стъпки за плащане.

Например, след активиране на режима "Under Attack", дори общият брой заявки да остане същият, ако заявките, достигнали до произхода, намалят с 60%, това означава, че Cloudflare слойът абсорбира значителния товар. Въпреки това, ако CPU използването на MySQL остава високо, атаката може да задейства специфична динамична заявка; в този случай трябва да се прегледат логовете на приложението.

Как да деактивирате режима "Under Attack" след края на атаката?

Когато трафикът от атаката се нормализира, оставянето на режима "Under Attack" постоянно активен не се препоръчва за повечето сайтове. Защото показването на допълнителна проверка на всеки посетител може да повлияе на процента на конверсия, ефективността на сканиране и удовлетвореността на потребителите. Процесът на деактивиране също трябва да бъде извършен внимателно.

Стъпки за безопасно връщане към нормалното

• Изчакайте трафикът да се нормализира за поне 30-60 минути.
• Потвърдете, че в Cloudflare Security Events екранът количествата на предизвикателства и блокировки намаляват.
• Преди да деактивирате режима "Under Attack", уверете се, че целенасочените WAF и правила за ограничаване на скоростта са активни.
• Настройте нивото на сигурност на High или Medium, като по-балансирано ниво.
• Тествайте сайта от различни устройства и наблюдавайте процента на грешки 5xx.
• Следете логовете за 24 часа, за да видите дали атаката започва отново.

Като добра практика, след атаката трябва да се състави отчет за инцидента. Този отчет трябва да съдържа времето на начало на атаката, целевите URL адреси, най-високия брой заявки, предприетите действия, ефективните правила и постоянните подобрения. Този документ ще съкрати значително времето за реакция при следващия инцидент.

Чести грешки и какво да избягвате

По време на DDoS атака е необходимо бързо вземане на решения; обаче неправилните настройки могат да блокират и реални потребители. Следните грешки често се срещат особено под голям стрес.

• Да се предполага, че режимът "Under Attack" ще осигури защита без прокси настройки на DNS записите.
• Да оставите IP адреса на произхода открит и да не блокирате достъпа извън IP адресите на Cloudflare с защитна стена.
• Да приложите предизвикателство за целия домейн, без да тествате API, webhook и адреси за обратни повиквания на плащания.
• Да напишете твърде широки WAF блок правила, които блокират реални клиенти.
• Да приложите агресивно кеширане на страници, които не трябва да бъдат кеширани, като количка, плащане или потребителски панели.
• Да оставите режима активен с месеци след атака.
• Да вземате решения само на базата на екрана на Cloudflare, без да преглеждате логовете на сървъра.

Особено на сайтове за електронна търговия, блокирането на обратни повиквания за плащания може да доведе до значителни загуби на приходи. Затова, когато пишете правила за сигурност, е по-безопасно първо да тествате с действия log или managed challenge вместо блокиране. След като се види влиянието на правилото, може да се премине към по-сериозни действия.

Как да планирате по-устойчива защита на инфраструктурата на Hostragons?

Cloudflare предлага силен преден слой; обаче успешната защита срещу DDoS не завършва само на страна на CDN. Хостинг инфраструктурата, оптимизация на софтуера, конфигурация на SSL, управление на DNS и стратегии за резервно копие трябва да бъдат обмислени заедно. Основният подход за сайт, хостван на Hostragons, трябва да бъде следният: Cloudflare филтрира трафика, хостинг слойът посреща само чистия трафик, а приложението е оптимизирано, за да не генерира ненужно натоварване на базата данни.

Преди да се пусне нов проект, е важно домейнът да се управлява с правилните DNS записи, SSL сертификатът да бъде инсталиран безпроблемно, а ресурсите на уеб сървъра да са подходящи за вашия трафик профил. В този контекст, връзките проверка на домейн и регистрация на име на домейн, Пакети за уеб хостинг, решения за корпоративен хостинг и Безплатен SSL сертификат могат да помогнат на потребителя.

При проекти с висок трафик или с висок риск от атаки, вместо стандартен споделен хостинг, могат да се оценят по-контролирани опции като VPS или управляеми сървъри. По този начин защитната стена, уеб сървърът, PHP-FPM, Redis, object cache и конфигурации на базата данни могат да бъдат настроени по-гъвкаво. Въпреки това, независимо кой аспект на инфраструктурата е избран, режимът "Under Attack" на Cloudflare трябва да бъде позициониран само като спешен инструмент; постоянната архитектура за сигурност трябва да бъде подкрепена с WAF, анализ на логовете и редовни актуализации.

Бърз контролен списък: Първите 15 минути по време на DDoS атака

Времето е критично по време на атака. Следният списък обобщава действия, които техническият екип или собственикът на сайта могат да предприемат през първите 15 минути.

• Влезте в Cloudflare панела и изберете правилния домейн.
• Проверете дали DNS записите са оранжеви, т.е. проксирни.
• Активирайте режима "Under Attack".
• Тествайте начната страница, входа, количката, плащането и API крайни точки.
• Определете целевите URL адреси от Cloudflare Security Events екрана.
• Добавете специфични WAF или правила за ограничаване на скоростта за най-атакуваните пътища.
• Контролирайте състоянието на CPU, RAM, PHP-FPM и MySQL на сървъра.
• Тествайте дали има директен достъп до IP адреса на произхода.
• Разгледайте дали е необходимо allowlist за платежни доставчици, webhook и критични интеграции.
• Записвайте всички действия с времеви отпечатък.

Ако този списък се упражнява редовно, паниката по време на истинска атака ще намалее и качеството на реакцията ще се подобри. За големи сайтове, документализацията на този процес като план за реагиране на инциденти е препоръчителна.

Често задавани въпроси

Режимът "Under Attack" на Cloudflare осигурява ли пълна защита на сайта?

Не. Режимът "Under Attack" на Cloudflare е ефективен за намаляване на трафика от ботове и наводнения на HTTP/HTTPS; обаче, сам по себе си не осигурява пълна защита. Трябва да се използва в комбинация с проксирни DNS записи, скрит IP на произхода, WAF правила, ограничаване на скоростта, кеш и настройки на защитната стена на сървъра.

Влияе ли режимът "Under Attack" на SEO?

Краткосрочната употреба обикновено не причинява сериозни щети на SEO. Въпреки това, ако режимът остане активен за дълго време, ефективността на сканиране от търсачките и потребителският опит могат да бъдат засегнати. Затова е по-здравословно да се деактивира режимът след атаката и да се продължи с целенасочени правила за сигурност.

Колко дълго трябва да остане активен режимът "Under Attack"?

Той може да остане активен, докато интензитетът на атаката не намалее; на практика, след като трафикът се нормализира, е препоръчително да продължите мониторинга поне 30-60 минути и след това да го изключите постепенно. Преди деактивиране, WAF и правила за ограничаване на скоростта трябва да бъдат готови.

Влияе ли режимът "Under Attack" на API или платежни системи?

Да, може да повлияе. Защото някои API клиенти, webhook услуги и системи за обратни повиквания на плащания не могат да завършат браузърната проверка за сигурност. Затова критичните крайни точки трябва да се тестват, и ако е необходимо, трябва да се определят allowlist или специални правила на Cloudflare.

Трябва ли да се вземат допълнителни мерки на хостинг страната при използване на Cloudflare?

Да. Cloudflare осигурява силна защита на предния слой; обаче, IP адресът на произхода трябва да бъде скрит, защитната стена трябва да позволява само необходимия трафик, софтуерът трябва да се поддържа актуален и конфигурацията на кеша трябва да бъде правилно настроена. Сигурната хостинг инфраструктура е важна част от устойчивостта на DDoS.

Заключение

Режимът "Under Attack" на Cloudflare е ефективен инструмент за бърз дъх при атака от DDoS на сайт. Когато е активиран с правилната конфигурация на DNS прокси, той намалява трафика от ботове, намалява натоварването на сървъра и увеличава шансовете на реалните потребители да достигнат сайта. За най-добри резултати този режим трябва да се подкрепя с WAF правила, ограничаване на скоростта, оптимизация на кеша и сигурност на защитната стена на произхода.

Ако искате вашият уебсайт да работи по-устойчиво на атаки, редовно преглеждайте инфраструктурата, управлението на DNS и конфигурацията на SSL. Можете да разгледате хостинг, домейни и SSL решения на Hostragons, за да осигурите по-сигурна и устойчива основа за вашия сайт.