Як уключыць Cloudflare "Under Attack" рэжым для абароны сайта ад DDoS-атак

Рэжым "Cloudflare Under Attack" — гэта аварыйная абарона для сайта, які падвяргаецца DDoS-атцы. Ён паказвае наведвальнікам кароткую праверку бяспекі і фільтруе шкодны бот-трафік, дазваляючы сапраўдным карыстальнікам дасягнуць сайта і зніжаючы нагрузку на сервер. Уключыць Under Attack Mode можна ў панэлі Cloudflare, выбраўшы сайт і перайшоўшы ў Security-раздзел. Гэта дазваляе за лічаныя хвіліны спыніць масавыя HTTP/HTTPS запыты. Але гэты рэжым — толькі частка абароны: для надзейнага выніку патрэбна правільная DNS-проксі-канфігурацыя, WAF-правілы, rate limiting, настройка кэша і бяспека сервера.

У гэтым гайдзе мы разглядзім, як уключыць Cloudflare Under Attack Mode, калі яго варта выкарыстоўваць, з якімі настройкамі спалучаць і як бяспечна вярнуцца да нармальнага рэжыму пасля атакі. Мэта — даць практычную “чэк-ліст” для дзейнасці ў момант панікі і дапамагчы як мага хутчэй аднавіць даступнасць сайта.

Што такое Cloudflare Under Attack Mode?

Under Attack Mode — гэта аварыйны ўзровень бяспекі Cloudflare. Пасля актывацыі Cloudflare правярае браўзэры наведвальнікаў, затрымліваючы доступ на некалькі секунд. Такі механізм стрымлівае аўтаматызаваны бот-трафік, простыя flood-інструменты і шкодных кліентаў, якія не падтрымліваюць браўзерныя функцыі.

Галоўная задача Under Attack Mode — барацьба з атакамі на прыкладным узроўні (Layer 7). Напрыклад, калі галоўная старонка атрымлівае тысячы GET-запытаў у секунду, ці login-старонка WordPress — масавыя POST-спробы, ці cart/пошукавыя формы — фэйкавы трафік, Under Attack Mode — першая дапамога.

Важна: Under Attack Mode фільтруе web-запыты, але калі атакуюць IP-сервера напрамую або Layer 3/4, трэба дадатковыя меры. DNS-запісы мусяць быць праз Cloudflare proxy, IP сервера — схаваны, а хостынг — абаронены. Для выбару бяспечнай інфраструктуры глядзіце Сэрвісы бяспечнага вэб-хостынгу і Устаноўка сертыфіката SSL.

Як распазнаць DDoS-атаку: што правяраць перад актывацыяй Under Attack?

Не кожнае замаруджанне — DDoS. Памылковы плагін, перагружаная база, няправільны кэш, высокі CPU cron — таксама даюць падобныя сімптомы. Перад уключэннем аварыйнага рэжыму варта хутка дыягнаставаць праблему. Але калі сервер не адказвае, карыстальнікі бачаць 502, 503, 504 памылкі, а ў логах — выбух запытаў, не варта марудзіць з актывацыяй.

Тыповыя прыкметы DDoS

Рэзкі рост трафіку ў 5–50 разоў ад звычайнага.
Сотні запытаў у секунду на адзін endpoint.
Трафік з розных краін з падобнымі user-agent.
Атакуюцца дарагія URL: admin, login, search, cart — у WordPress, WooCommerce, OpenCart і пад.
Перавышэнне лімітаў CPU, RAM, PHP-FPM, MySQL.
Cloudflare Analytics паказвае рэзкі рост 4xx/5xx памылак.
Карыстальнікі часам даходзяць да сайта, але бот-трафік не спыняецца.

Напрыклад, калі e-commerce сайт звычайна атрымлівае 2 000 запытаў у хвіліну, а за 10 хвілін паказчык вырас да 80 000, і 70% ідуць на cart/search — гэта Layer 7 атака. Тут варта ўключыць Under Attack Mode ў першыя 5 хвілін, а затым дадаць WAF- і rate limiting-правілы.

Калі варта выкарыстоўваць Cloudflare Under Attack Mode?

Under Attack Mode — не стандартная пастаянная абарона. Ён паказвае ўсім карыстальнікам экран з праверкай, што можа знізіць канверсію, замарудзіць аплату або API-інтэграцыі. Лепшая практыка: уключаць часова падчас атакі і вяртаць стандартныя ўзроўні, калі трафік стабілізуецца.

Рэкамендаваныя выпадкі

Ненармальны рост HTTP/HTTPS-трафіку.
Сервер хутка перагружаецца, памылкі 502/503 растуць.
Cloudflare WAF не наладжаны, патрэбна хуткая абарона.
Бот-трафік істотна перавышае карыстальніцкі.
Мішэнню атакі з’яўляюцца web-старонкі, формы, login, search-endpoint’ы.

З асаблівай асцярожнасцю

Актыўна выкарыстоўваюцца API, мобільныя прыкладанні, webhook, аплатныя інтэграцыі.
Крытычныя для SEO боты скануюць сайт.
Карпаратыўныя карыстальнікі заходзяць з старых браўзераў або абмежаваных сетак.
Ёсць subdomain’ы без Cloudflare proxy.

Для API-трафіку Under Attack Mode можа выклікаць збоі: лепш для такіх subdomain’аў выкарыстаць асобныя WAF-правілы, allowlist або іншы ўзровень бяспекі. Глядзіце Кіраўніцтва па бяспецы API і абмежаванні хуткасці для падрабязнасцяў.

Як уключыць Cloudflare Under Attack Mode: крок за крокам

Гэта чэк-ліст для хуткай рэакцыі падчас атакі. Cloudflare інтэрфейс можа мяняцца, але логіка простая: выбіраеце свой дамен, павышаеце ўзровень бяспекі, прымушаеце Cloudflare правяраць кожнага наведвальніка.

1. Уваходзьце ў Cloudflare і выбірайце дамен

Зайдзіце ў Cloudflare, выберыце дамен пад атакай. Калі кіруеце некалькімі даменамі, пераканайцеся, што дзейнічаеце ў патрэбнай зоне — памылка з выбарам дамена страціць час, а атака працягнецца.

2. Праверце, што DNS-запісы proxied

Абарона працуе, калі web-трафік ідзе праз Cloudflare. У DNS-раздзеле пераканайцеся, што A, AAAA і CNAME — з аранжавым cloud (proxied). Grey cloud (DNS only) не абараняе ад атак. Асабліва правярайце www, root і ўсе subdomain’ы.

Калі IP сервера адкрыты, атакуючыя могуць абыйсці Cloudflare і напрамую атакаваць сервер. На firewall трэба дазваляць HTTP/HTTPS толькі з IP-Cloudflare. Падтрымку можна атрымаць у хостынгу або глядзець як наладзіць DNS для Cloudflare.

3. Уключыце Under Attack Mode у Security-раздзеле

Адкрыйце дамен у Cloudflare, знайдзіце Under Attack Mode у Security ці Overview. У некаторых панэлях гэта I am Under Attack у Security Level. Пасля ўключэння карыстальнікі ўбачаць кароткую праверку. Змяненні звычайна ўступаюць у сілу за некалькі хвілін. Адразу сочыце за Cloudflare Analytics, Security Events, нагрузкай сервера. Калі CPU і connections падаюць — абарона працуе. Калі памылкі застаюцца — дадавайце дадатковыя правілы.

4. Пратэстуйце вопыт сапраўдных карыстальнікаў

Пасля актывацыі праверце сайт з розных сетак: мабільнага інтэрнэту, офісу, з іншай геаграфіі. Тэстуйце галоўную, login, cart, checkout. Калі пасля праверкі сайт даступны — усё добра. Калі карыстальнікі не могуць прайсці challenge, магчыма, праблемы з cookie, несумяшчальнасць браўзера або канфлікт Cloudflare-правілаў.

5. Вызначце атакуемыя URL

Under Attack Mode — агульны шчыт, але найлепшы вынік даюць спецыяльныя правілы для найбольш атакуемых шляхоў. Аналізуйце Cloudflare Security Events, Web Analytics, серверныя і праграмныя логи. Напрыклад, /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, /checkout — частыя мішэні.

Для спецыфічных URL можна задаць WAF Custom Rules па краіне, user-agent, метадзе, URI path, bot score. Напрыклад, для login-endpoint — managed challenge для IP з больш як 10 запытаў у хвіліну. Для WordPress рэкамендуецца Заходы бяспекі WordPress.

Адрозненні Under Attack Mode і іншых Cloudflare-інструментаў

Cloudflare прапануе розныя механізмы абароны. Under Attack Mode — хуткая агульная аварыйная фільтрацыя; WAF і Rate Limiting — больш гнуткія і збалансаваныя для карыстальнікаў.

Адрозненні Under Attack Mode і іншых Cloudflare-інструментаў
Функцыя	Што робіць?	Калі выкарыстоўваць?	Вплыў на карыстальнікаў
Under Attack Mode	Додае праверку ўсім наведвальнікам, зніжае бот-трафік.	Падчас DDoS ці HTTP flood.	Карыстальнікі бачаць экран чакання.
WAF Custom Rules	Прапісвае правілы для URL, IP, краін, user-agent.	Калі вядомы pattern атакі, трэба мэтанакіраваная абарона.	Мінімальны ўплыў пры правільнай настройцы.
Rate Limiting	Абмежуе колькасць запытаў з кліента.	На login, search, API, cart.	Можа абмежаваць сапраўдных карыстальнікаў, калі ліміты няправільныя.
Bot Fight Mode	Зніжае просты бот-трафік.	Пры пастаяннай сярэдняй актыўнасці ботаў.	Звычайна мінімальны ўплыў.
Cache Rules	Сервіруе статыку і дынаміку з edge-сервераў.	Для зніжэння нагрузкі на сервер.	Пры правільнай настройцы — паляпшае якасць.

Практычна абарона будуецца так: спачатку Under Attack Mode для зніжэння ціску, затым аналіз pattern’у атакі, дадаюцца WAF і rate limiting, потым наладжваецца кэш і firewall на серверы.

Дадатковыя Cloudflare-настройкі падчас атакі

Under Attack Mode — гэта проста кнопка, але поспех абароны залежыць ад падтрымліваючых наладаў.

Таргетаваная абарона з WAF-правіламі

Cloudflare WAF дазваляе задаваць actions для канкрэтных умоў. Напрыклад, challenge для POST-запытаў на /wp-login.php з пэўных краін. Так вы абараняеце мішэні, не замаруджваючы ўсю платформу.

Доступ да admin/login — толькі для пэўных IP/краін.
Блакіруйце endpoint’ы, якія не выкарыстоўваюцца (XML-RPC).
Managed challenge для падазроных user-agent.
Rate limit для URI з частымі запытамі.

Правільны кэш

Падчас атакі сервер не павінен адказваць на кожны запыт. Статыка (малюнкі, CSS, JS) і кэшуемыя старонкі павінны сервіраваць з Cloudflare edge. Для WordPress — кэш-плагін, Cloudflare cache rules, cache-control headers.

На сайтах з навінамі/блогам старонкі для гасцей можна кэшаваць на 5–30 хвілін. Гэта зніжае TTFB і нагрузку. Для аптымізацыі глядзіце Кіраўніцтва па павышэнню хуткасці сайта.

Рэалістычны rate limiting

Rate limiting эфектыўны для дарагіх endpoint’аў, але ліміты павінны быць разумнымі. Напрыклад, у product search карыстальнік робіць 5–15 запытаў у хвіліну, 100 — ненармальна. Для login — 10 няўдалых спроб за 5 хвілін — падазрона.

Схема: для /wp-login.php managed challenge пры 10+ запытах за хвіліну, block пры 50+ за 5 хвілін. Для API — больш гнуткія ліміты па IP, token, session, method.

Схавайце origin IP і абмежуйце firewall

Часта робяць памылку, пакідаючы origin IP адкрытым. Старыя DNS, subdomain’ы, mail-запісы, канфігурацыі — усё гэта дазваляе абыйсці Cloudflare. Firewall на серверы мусіць адкрываць 80/443 толькі для Cloudflare IP. SSH, панэль, база — толькі па IP, з моцным паролем, 2FA/VPN. Для бяспекі глядзіце параметры бяспекі cPanel і Канфігурацыя брандмаўэра VPS.

Асаблівасці для WordPress, WooCommerce і карпаратыўных сайтаў

Розныя сайты — розныя трафік-патэрны. Для блога, WooCommerce або SaaS Under Attack Mode будзе працаваць па-рознаму.

WordPress

Галоўныя мішэні — /wp-login.php і /xmlrpc.php. Калі XML-RPC не патрэбны — блакіруйце. Для admin — абмежаванне па IP/краіне. Не дапускайце канфлікту паміж Cloudflare-правіламі і security-плагінамі — занадта шмат challenge можа замкнуць карыстальніка ў ланцугу праверкі.

WooCommerce

Старонкі cart, checkout, account — дынамічныя, кэшаваць іх агрэсіўна нельга. Падчас Under Attack Mode пераканайцеся, што payment callback/webhook працуюць. Для payment-правайдэра дадайце IP у allowlist або стварыце спецыяльнае правіла.

Карпаратыўныя і API-сайты

Парталы, CRM-інтэграцыі, mobile API — не ўсе могуць праходзіць JS challenge. Для такіх subdomain’аў лепш асобны рэжым: www.example.com — Under Attack, api.example.com — token security, rate limiting, allowlist.

Якія метрыкі маніторыць пасля запуску Under Attack Mode?

Абараняцца — мала; трэба маніторыць вынік: памылкі, нагрузку, паводзіны карыстальнікаў.

Cloudflare Security Events: колькі запытаў challenge/block.
HTTP-коды: 403, 429, 502, 503, 504.
CPU/RAM сервера: павінны падаць пасля запуску абароны.
PHP-FPM/MySQL connections: паказчык разгрузкі прыкладання.
Bandwidth/request’ы: параўнаць аб’ём і долю фільтраваных.
Канверсіі: тэст форм, заказаў, login, checkout.

Прыклад: пасля Under Attack Mode агульная колькасць request’аў не змяншаецца, але да origin трапляе на 60% менш — Cloudflare фільтруе нагрузку. Калі MySQL CPU усё яшчэ высокі — магчыма, атака ідзе праз спецыфічны дынамічны запыт; аналізуйце логи.

Як бяспечна выключыць Under Attack Mode пасля DDoS-атакі?

Пасля стабілізацыі трафіка Under Attack Mode не варта трымаць пастаянна: ён пагаршае канверсію, crawling і задавальненне карыстальнікаў. Капаць трэба так жа асцярожна, як уключаць.

Чэк-ліст вяртання да нармальнага рэжыму

Пачакаць 30–60 хвілін стабільнага трафіку.
Пераканацца, што challenge/block запытаў у Cloudflare падае.
Перад выключэннем Under Attack — WAF/rate limiting мусяць працаваць.
Пераключыць Security Level на High або Medium.
Пратэставаць сайт з розных прылад, паглядзець 5xx памылкі.
Маніторыць логи 24 гадзіны на магчымы рэцыдыў.

Добрая практыка — стварыць інцыдэнтны рапарт: час пачатку, мішэні, пік запытаў, прынятыя меры, эфектыўныя правілы, пастаянныя паляпшэнні. Такі дакумент скарачае час рэакцыі на наступную атаку.

Частыя памылкі і як іх пазбегнуць

У DDoS-інцыдэнце трэба дзейнічаць хутка, але памылковыя налады могуць блакіраваць сапраўдных карыстальнікаў.

Уключаць Under Attack Mode без proxied DNS — абарона не працуе.
Пакідаць origin IP адкрытым і не абмяжоўваць firewall.
Без тэставання challenge для ўсіх endpoint’аў API/webhook/payment — могуць не працаваць.
Занадта агульныя WAF block-правілы — блакіруюць кліентаў.
Кэшаваць дынамічны cart, checkout, user-panel — страчваецца функцыянал.
Пасля атакі трымаць Under Attack Mode месяцамі.
Ня аналізаваць серверныя логи, абапірацца толькі на Cloudflare.

У e-commerce blocking payment callback — рэальная страта даходу. Лепш спачатку тэставаць правілы з log/challenge, потым ужываць block.

Як спланаваць устойлівую абарону з Hostragons?

Cloudflare — моцны CDN-шчыт, але поўная абарона залежыць ад хостынгу, аптымізацыі праграм, SSL, DNS і бэкапаў. Для сайта на Hostragons: Cloudflare фільтруе трафік, хостынг абслугоўвае толькі чыстыя запыты, прыкладанне — не стварае лішнюю нагрузку на базу.

Перад запускам праекта — настройце DNS, усталюйце SSL, падбярыце рэсурсы пад трафік. Для гэтага глядзіце Праверка дамена і рэгістраванне дамена, Пакеты вэб-хостынгу, рашэнні для карпаратыўнага хостынгу, Бясплатны SSL сертыфікат.

Для высокатрафічных праектаў выбірайце VPS або managed server — гэта дазваляе гнутка наладжваць firewall, PHP-FPM, Redis, object cache, базу. Але незалежна ад інфраструктуры, Under Attack Mode — толькі аварыйны інструмент; пастаянная абарона — гэта WAF, логи і рэгулярныя абнаўленні.

Хуткі чэк-ліст: першыя 15 хвілін DDoS

Час крытычны. Гэта спіс дзеянняў для тэхнічнай каманды/уладальніка сайта ў першыя 15 хвілін:

Увайдзіце ў Cloudflare, выберыце правільны дамен.
Праверце proxied DNS-запісы.
Уключыце Under Attack Mode.
Пратэстуйце галоўную, login, cart, checkout, API.
Аналізуйце Cloudflare Security Events — вызначце атакуемыя URL.
Дадайце WAF/rate limiting для самых атакуемых шляхоў.
Праверце CPU, RAM, PHP-FPM, MySQL.
Пратэстуйце, ці можна абыйсці абарону — прамой доступ да origin IP.
Пераканайцеся, што payment/webhook/інтэграцыі працуюць — магчыма, патрэбна allowlist.
Фіксуйце ўсе дзеянні з часам.

Практычна практыкаваць гэты спіс — гэта зніжае паніку і павышае якасць рэакцыі. Для буйных сайтаў рэкамендуецца дакументаваць працэс як інцыдэнтны план.

Часта задаваемыя пытанні

Ці абараняе Cloudflare Under Attack Mode сайт цалкам?

Не. Under Attack Mode эфектыўны супраць HTTP/HTTPS flood і ботаў, але не гарантуе поўную абарону. Неабходна proxied DNS, схаваны origin IP, WAF, rate limiting, кэш, firewall.

Ці шкодзіць Under Attack Mode SEO?

Кароткатэрмінова — звычайна не. Але пры працяглым выкарыстанні можа пагоршыць crawling і досвед карыстальнікаў. Таму пасля атакі варта вяртацца да таргетаваных правілаў.

Як доўга трэба трымаць Cloudflare Under Attack Mode?

Пакуль атака не скончыцца; на практыцы — 30–60 хвілін пасля стабілізацыі трафіку, а затым паступова адключаць. Перад гэтым — падрыхтаваць WAF/rate limiting.

Ці ўплывае Under Attack Mode на API/аплату?

Так, можа ўплываць. Некаторыя API-кліенты, webhook’і, payment callback не праходзяць браўзерную праверку. Таму варта тэставаць усе endpoint’ы, пры патрэбе — allowlist або асобныя Cloudflare-правілы.

Ці патрэбныя дадатковыя меры на хостынгу пры Cloudflare?

Так. Cloudflare — гэта CDN-абарона, але origin IP трэба хаваць, firewall — абмежаваць, праграму — абнаўляць, кэш — наладжваць. Бяспечны хостынг — важная частка DDoS-устойлівасці.

Вынік

Cloudflare Under Attack Mode — хуткі і эфектыўны аварыйны інструмент для сайта падчас DDoS-атакі. Пры правільнай DNS-проксі-настройцы ён зніжае бот-трафік, нагрузку на сервер і павышае шанцы сапраўдных карыстальнікаў дасягнуць сайта. Найлепшы вынік дае сумеснае выкарыстанне WAF, rate limiting, кэш-аптымізацыі і firewall на origin-серверы.

Каб зрабіць сайт устойлівым да атак, рэгулярна аналізуйце інфраструктуру, DNS і SSL. Азнаёмцеся з хостынг-, domain- і SSL-рашэннямі Hostragons, каб стварыць бяспечную і надзейную платформу для свайго сайта.