Налады Cloudflare — гэта правільная канфігурацыя DNS, SSL/TLS, міжсеткавага экрана (WAF), правілаў бяспекі, фільтрацыі ботаў і кэшавання, каб зрабіць сайт хуткім, абароненым і ўстойлівым да DDoS-атак. Для максімальна надзейнай базавай канфігурацыі неабходна дадаць дамен у Cloudflare, дакладна перанесці DNS-запісы, па магчымасці абраць рэжым SSL Full (Strict), уключыць кіраваныя правілы WAF, ужываць выклік (challenge) альбо абмежаванне хуткасці (rate limit) для падазроных запытаў, а падчас атакі кантралявана задзейнічаць рэжым «Under Attack Mode».
Cloudflare працуе як CDN і ахоўны пласт, што размяшчаецца паміж вашым сайтам і наведвальнікамі. Калі карыстальнік заходзіць на сайт, запыт спачатку трапляе ў сетку Cloudflare; там шкоднасны трафік фільтруецца, статычныя файлы могуць выдавацца з кэшу, а легітымныя запыты накіроўваюцца на ваш асноўны (origin) сервер. Такая архітэктура дае сур’ёзныя перавагі асабліва для WordPress, WooCommerce, карпаратыўных сайтаў, SaaS-панэляў і наведвальных кантэнтавых праектаў. Аднак няправільна выкананыя налады Cloudflare здольныя спарадзіць памылкі SSL, бясконцыя цыклы перанакіравання, праблемы з доступам да адмін-панэлі, старонкі, якія не абнаўляюцца праз кэш, ды ўразлівасці бяспекі.
У гэтым гайдзе мы крок за крокам разгледзім, як наладзіць Cloudflare з нуля, уключыць крытычныя опцыі для аховы сайта, карэктна выкарыстоўваць DDoS-ахову ў патрэбным сцэнары і аптымізаваць прадукцыйнасць без шкоды для бяспекі. Калі вы хочаце стварыць хуткую, бяспечную і стабільную інфраструктуру для свайго сайта, важна закласці трывалы падмурак з боку дамена, хостынгу і SSL: Рэгістрацыя дамена, Пакеты вэб-хостынгу, SSL-сертыфікат.
Што такое Cloudflare і якая яго роля ў ахове сайта?
Cloudflare — гэта воблачная платформа бяспекі і прадукцыйнасці, якая прапануе кіраванне DNS, CDN, абарону ад DDoS, міжсеткавы экран для вэб-дадаткаў, падаўленне ботаў, кіраванне SSL/TLS і аналітыку трафіку. У традыцыйнай мадэлі наведвальнік падключаецца непасрэдна да вашага хостынг-сервера; у выпадку з Cloudflare наведвальнік спачатку звяртаецца да перыферыйных сервераў Cloudflare. Дзякуючы гэтаму шкоднасны трафік можна адфільтраваць яшчэ да таго, як ён дасягне асноўнага сервера.
Напрыклад, невялікі сайт на WordPress звычайна апрацоўвае 2 000 наведвальнікаў за дзень і 20–30 запытаў у хвіліну. Падчас простай HTTP-флуд-атакі гэтая лічба можа падскочыць да 20 000 запытаў у хвіліну. Ваш сервер перастане спраўляцца праз абмежаванні працэсара, памяці або колькасці злучэнняў. Cloudflare падзяляе гэты трафік, абапіраючыся на рэпутацыю IP, аналіз паводзінаў, абмежаванне хуткасці (rate limiting), праверку на робата (challenge) і DDoS-сігнатуры, што дазваляе сапраўдным наведвальнікам бесперашкодна трапляць на сайт.
Cloudflare не з’яўляецца «чароўнай палачкай», якая вырашае ўсе праблемы. Ён эфектыўны толькі ў спалучэнні з магутнай хостынг-інфраструктурай, абноўленым ПЗ, надзейнымі паролямі, рэзервовым капіяваннем, SSL і правільнай канфігурацыяй сервера. Асабліва для WordPress па-ранейшаму крытычна важныя абнаўленні тэм і плагінаў, ахова адмін-панэлі і палітыка складаных пароляў: WordPress хостынг, Бяспека WordPress.
Кантрольны спіс падрыхтоўкі перад наладкай Cloudflare
Перад пераходам на Cloudflare варта правесці некалькі базавых праверак — гэта паменшыць верагоднасць праблем з доступам і SSL пасля міграцыі. Асабліва для сайтаў з жывым трафікам варта планаваць змены DNS загадзя.
- Зрабіце выпіску бягучых DNS-запісаў: Зафіксуйце запісы A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC і паддамены.
- Праверце IP-адрас хостынгу: Памылковы A-запіс прывядзе да перанакіравання сайта на чужы сервер.
- Праверце стан SSL: Калі на асноўным серверы ёсць сапраўдны SSL, вы зможаце выкарыстоўваць рэжым Full (Strict) у Cloudflare.
- Звярніце ўвагу на паштовыя запісы: MX і звязаныя з поштай запісы CNAME/A звычайна павінны быць з адключаным проксі (DNS only).
- Зрабіце рэзервовую копію: Бэкап DNS і сайта дазволіць хутка адрабіць сітуацыю пры памылковых дзеяннях.
- Абярыце час для тэхнічнага перапынку: Змена nameserver-аў хоць і бачная за некалькі хвілін, але глабальнае распаўсюджванне можа заняць да 24 гадзін.
Практычны падыход для карпаратыўных сайтаў такі: спачатку DNS-запісы пераносяцца адзін у адзін, затым проксі ўключаецца толькі для вэб-трафіку — www і асноўнага дамена. Для сэрвісаў накшталт пошты, FTP, cPanel, webmail дзейнічаем асцярожна, зыходзячы са сцэнару выкарыстання. Напрыклад, калі для доступу да cPanel вы карыстаецеся асобным паддаменам, лепш пакінуць яго ў рэжыме DNS only, каб пазбегнуць праблем: Кіраванне cPanel хостынгам.
Як наладзіць DNS у Cloudflare?
Наладка Cloudflare пачынаецца з дадання вашага дамена ў панэль кіравання. Cloudflare скануе існуючыя DNS-запісы і паказвае іх спіс. Аўтаматычнае сканаванне можа знайсці не ўсе запісы, таму ручная праверка абавязковая.
1. Дадайце дамен у Cloudflare
Пасля ўваходу ў уліковы запіс Cloudflare дадайце сайт праз крок «Add a site». Пасля выбару тарыфнага плана праверце DNS-запісы. Для асноўнага дамена звычайна прысутнічае A-запіс, для www — CNAME-запіс. Прыклад структуры:
- A-запіс: example.com → 192.0.2.10
- CNAME-запіс: www → example.com
- MX-запіс: example.com → ваш паштовы правайдэр
- TXT-запісы: Запісы спраўджання SPF, DKIM, DMARC
Ключавы момант тут — якія запісы будуць праходзіць праз проксі Cloudflare. Для A і CNAME, што адказваюць за вэб-трафік, можна ўключыць аранжавую хмарку. Для паштовага трафіку, FTP і сэрвісаў, якія патрабуюць прамога доступу да сервера, выбіраецца шэрая хмарка, гэта значыць DNS only.
2. Змяніце Nameserver-ы
Cloudflare выдасць вам два адрасы nameserver-аў. Там, дзе вы набывалі дамен, заменіце бягучыя nameserver-ы на гэтыя значэнні. Для даменаў, зарэгістраваных у Hostragons, кіраваць nameserver-амі можна праз даменную панэль: Кіраванне даменам. Пасля змены чакайце, пакуль статус у панэлі Cloudflare не зменіцца на «Active».
3. Правільна абярыце рэжым проксі
Калі аранжавая хмарка актыўная, HTTP/HTTPS-трафік ідзе праз Cloudflare і прымяняюцца функцыі бяспекі. Калі шэрая — Cloudflare толькі выконвае ролю DNS-рэзолвера. Для вашага сайта проксі павінен быць уключаны; для паддаменаў кшталту mail.example.com, ftp.example.com або серверных панэляў кіравання проксі звычайна лепш трымаць выключаным.
Налады SSL/TLS: максімальна бяспечная канфігурацыя
Параметр SSL/TLS у Cloudflare вызначае, як будзе шыфравацца злучэнне паміж браўзерам і Cloudflare, а таксама паміж Cloudflare і асноўным серверам. Няправільны рэжым SSL — адна з самых частых крыніц памылак Cloudflare.
Розніца паміж Flexible, Full і Full (Strict)
| Рэжым SSL | Cloudflare — Наведвальнік | Cloudflare — Сервер | Рэкамендацыя |
|---|---|---|---|
| Flexible | HTTPS | HTTP | Не рэкамендуецца, акрамя часовага выкарыстання; можа выклікаць цыклы перанакіравання і рызыкі бяспекі. |
| Full | HTTPS | HTTPS | На серверы ёсць SSL, але праверка сертыфіката не строгая. |
| Full (Strict) | HTTPS | HTTPS, сапраўдны сертыфікат | Найбольш бяспечны стандартны варыянт; выкарыстоўвайце яго, калі ёсць магчымасць. |
У прафесійным асяроддзі ваша мэта — Full (Strict). Для гэтага на асноўным серверы павінен быць усталяваны сапраўдны SSL-сертыфікат. Можна выкарыстоўваць Let’s Encrypt, камерцыйны SSL або Origin Certificate ад Cloudflare. На хостынг-пакетах Hostragons вы можаце бяспечна карыстацца гэтым рэжымам, правільна наладзіўшы ўстаноўку і абнаўленне SSL: Устаноўка SSL-сертыфіката.
Always Use HTTPS і Automatic HTTPS Rewrites
Опцыя «Always Use HTTPS» перанакіроўвае HTTP-запыты на HTTPS. «Automatic HTTPS Rewrites» дапамагае пераўтварыць некаторыя HTTP-рэсурсы ўнутры старонкі на HTTPS. Аднак для сайтаў з праблемай змешанага змесціва (mixed content) галоўнае рашэнне — назаўжды перавесці HTTP-спасылкі ў базе даных і тэме на HTTPS.
Будзьце асцярожныя з HSTS
HSTS загадвае браўзерам падключацца да вашага сайта толькі праз HTTPS. Гэта магутная мера бяспекі, але пры няправільнай канфігурацыі SSL наведвальнікі могуць страціць доступ. Таму перад уключэннем HSTS пераканайцеся, што Full (Strict), сапраўдны SSL, паддамены і перанакіраванні працуюць бездакорна. На пачатковым этапе бяспечней пратэставаць з невялікім значэннем max-age.
Налады WAF Cloudflare для аховы вэб-дадаткаў
WAF (Web Application Firewall) фільтруе запыты, накіраваныя на SQL-ін’екцыі, XSS, уключэнне файлаў, шкоднасныя паводзіны ботаў і вядомыя ўразлівасці дадаткаў. Налады WAF асабліва важныя для WordPress, Joomla, Laravel, самапісных панэляў і інтэрнэт-крам.
Уключыце кіраваныя правілы (Managed Rules)
Managed Rules — гэта гатовыя наборы правілаў бяспекі, якія абнаўляе Cloudflare. Калі вы карыстаецеся WordPress, спецыяльныя правілы для WordPress, агульныя правілы OWASP і сігнатуры вядомых уразлівасцяў (CVE) паменшаць паверхню атакі. Здаровы падыход: падчас першага ўкаранення адсочваць спрацоўванне правілаў у рэжыме «Log» або з нізкім узроўнем уздзеяння, праверыць ілжывыя спрацоўванні, а затым прымяніць «Block» або «Managed Challenge».
Абараніце крытычныя вобласці з дапамогай Custom Rules
Карыстальніцкія правілы забяспечваюць дакладковую ахову з улікам структуры вашага сайта. Напрыклад, вы можаце дазволіць доступ да старонак уваходу кшталту wp-login.php або /admin толькі з пэўных краін альбо адпраўляць на challenge запыты з падазронымі user-agent на канкрэтныя URI. Аднак важна не забараніць сапраўдных карыстальнікаў. Калі ў інтэрнэт-краме выпадкова адправіць на challenge старонку аплаты, гэта прывядзе да страты канверсіі.
Практычны прыклад: на карпаратыўным сайце, арыентаваным на Беларусь, для шляху /wp-admin можна прымяніць Managed Challenge да запытаў з-за мяжы. Але калі ёсць аддаленыя супрацоўнікі або замежныя офісы, спатрэбіцца белы спіс IP-адрасоў. Такі падыход значна змяншае колькасць атак поўнага перабору (brute force), захоўваючы доступ для ўпаўнаважаных карыстальнікаў.
Як наладзіць абарону ад DDoS?
DDoS-атака мае на мэце зрабіць ваш сайт або сервер недаступным праз празмерны трафік. Галоўная перавага Cloudflare — здольнасць прыняць гэты трафік на сваю глабальную сетку і перадаваць на асноўны сервер толькі ачышчаныя запыты. Але для дасягнення найлепшага выніку DDoS-ахову трэба разглядаць не як пасіўную опцыю, а як план абароны, сканфігураваны пад канкрэтны сцэнар.
1. Трымайце проксі для вэб-трафіку актыўным
DDoS-ахова Cloudflare працуе для запісаў з уключаным проксі. Калі ваш асноўны дамен і www-запіс не пад аранжавай хмаркай, вэб-трафік ідзе наўпрост на сервер, і Cloudflare не можа яго фільтраваць. Таксама важна, каб ваш асноўны IP-адрас не быў публічна вядомы. Старыя DNS-запісы, загалоўкі лістоў або прамы доступ па IP могуць дазволіць атакавальнікам абыйсці Cloudflare.
2. Выкарыстоўвайце Security Level і Challenge
Security Level вызначае, ці будзе наведвальнік атрымліваць праверку (challenge) у залежнасці ад яго ацэнкі рызыкі. У звычайны час узроўню «Medium» дастаткова для большасці сайтаў. Падчас атакі або падазронай актыўнасці можна падняць да «High» або часова ўключыць «I’m Under Attack Mode». Гэты рэжым паказвае наведвальніку кароткую прамежкавую старонку праверкі, таму ён уплывае на карыстальніцкі досвед і яго не рэкамендуецца трымаць уключаным пастаянна.
3. Абмяжуйце інтэнсіўнасць запытаў праз Rate Limiting
Rate limiting выкарыстоўваецца для абмежавання колькасці запытаў з аднаго IP або кліента за пэўны прамежак часу. Напрыклад, калі на старонку ўваходу за 1 хвіліну прыходзіць больш за 20 запытаў, можна ўжыць challenge — гэта знізіць рызыку brute force. З API-эндпоінтамі трэба быць акуратнейшымі: калі ў вас ёсць мабільныя дадаткі або інтэграцыі, агрэсіўныя ліміты без замеру рэальнага аб’ёму выклікаюць памылковыя блакіроўкі: Бяспека API і інтэграцый.
4. Абмяжуйце асноўны сервер толькі Cloudflare
Для павышанай бяспекі на серверным файрволе можна дазволіць HTTP/HTTPS-трафік толькі з дыяпазонаў IP Cloudflare. Такім чынам, нават ведаючы ваш асноўны IP, атакавальнік не зможа падключыцца наўпрост. Гэта патрабуе асцярожнасці: спіс IP Cloudflare трэба падтрымліваць актуальным, а кіраўнічыя доступы (SSH, панэль кіравання, сэрвісы бэкапу) разглядаць асобна.
Ахова ад ботаў і меры супраць Brute Force
Бот-трафік не заўсёды шкодны: пошукавыя боты накшталт Googlebot неабходныя для індэксацыі. Праблему ўяўляюць спам-боты, інструменты збору даных (scraping), падробленыя спробы ўваходу і аўтаматызацыя, што спажывае рэсурсы. Сістэма аховы ад ботаў Cloudflare дапамагае адрозніваць такі трафік па паводніцкіх сігналах.
- Bot Fight Mode: Можна выкарыстоўваць для памяншэння простага бот-трафіку, але абавязкова пратэстуйце на інтэграцыях.
- Turnstile: Больш зручная для карыстальніка альтэрнатыва CAPTCHA для формаў.
- Ахова старонкі ўваходу: Шляхі wp-login.php, xmlrpc.php і /admin можна абмежаваць асобнымі правіламі.
- Кантроль XML-RPC: Калі не выкарыстоўваецца ў WordPress, яго варта заблакіраваць — гэта зніжае рызыку brute force.
- Памяншэнне спаму ў формах: На кантактных формах можна камбінаваць Turnstile і rate limit.
Канкрэтны прыклад: калі на сайце WordPress праз xmlrpc.php паступаюць тысячы POST-запытаў у хвіліну, спажыванне працэсара рэзка ўзрастае. Карыстальніцкае правіла Cloudflare, якое блакуе запыты да xmlrpc.php або дазваляе іх толькі з IP неабходных сэрвісаў (напрыклад, Jetpack), прыкметна знізіць нагрузку на сервер.
Кэш і прадукцыйнасць: як паскорыць сайт без шкоды для бяспекі
Cloudflare моцны не толькі ў бяспецы, але і ў прадукцыйнасці. Аддаючы статычныя файлы з бліжэйшай да наведвальніка кропкі, ён скарачае час загрузкі старонкі. Але кэшаваць усё запар няправільна: старонкі аўтарызаваных карыстальнікаў, кошык, аплата, асабісты кабінет і персаналізаваны кантэнт трэба выключыць з кэшу.
Рэкамендаваныя налады кэша
- Caching Level: Стандартны варыянт падыходзіць большасці сайтаў.
- Browser Cache TTL: Для статычных файлаў можна выбраць 1 тыдзень ці даўжэй.
- Cache Rules: Такія вобласці, як /wp-admin, /cart, /checkout, /my-account, павінны быць bypass.
- Always Online: Дае абмежаваную карысць пры часовых збоях; на дынамічных сайтах чаканні павінны быць рэалістычнымі.
- Purge Cache: Пасля змены дызайну або кантэнту лепш ачышчаць кэш канкрэтнага URL, а не ўвесь адразу — гэта больш кантралявана.
Важны таксама ўзровень хостынгу. LiteSpeed, NVMe-дыскі, актуальная версія PHP і правільны плагін кэшавання разам з Cloudflare даюць лепшы вынік: LiteSpeed хостынг, Паскарэнне сайта.
Рэкамендаваны стартавы профіль бяспекі Cloudflare
Табліца ніжэй паказвае бяспечны стартавы профіль для большасці малых і сярэдніх сайтаў. Паколькі трафік, ПЗ і бізнес-мадэль кожнага сайта адрозніваюцца, налады трэба адсочваць на аснове жывых даных.
| Налада | Рэкамендаванае значэнне | Чаму гэта важна? |
|---|---|---|
| SSL/TLS | Full (Strict) | Забяспечвае скразны правераны HTTPS. |
| Always Use HTTPS | Уключана | Перанакіроўвае HTTP-трафік на бяспечнае злучэнне. |
| WAF Managed Rules | Уключана | Аўтаматычна фільтруе вядомыя вэб-атакі. |
| Security Level | Medium | Забяспечвае збалансаваную ахову ў паўсядзённым рэжыме. |
| Under Attack Mode | Толькі падчас атакі | Ужывае дадатковую праверку падчас масіраваных DDoS. |
| Rate Limiting | Кантралявана для ўваходу і API | Змяншае brute force і злоўжыванні. |
| Cache Rules | Bypass для дынамічных старонак | Прадухіляе памылкі ў кошыку, аплаце і панэлі. |
| DNSSEC | Уключана, калі падтрымліваецца | Дае дадатковую ахову ад падмены DNS. |
Тыповыя памылкі Cloudflare і іх вырашэнне
Бясконцы цыкл перанакіравання
Звычайна ўзнікае, калі рэжым SSL у Cloudflare — Flexible, а на асноўным серверы настроена перанакіраванне на HTTPS. Рашэнне: усталяваць на серверы сапраўдны SSL і пераключыць рэжым Cloudflare на Full ці, лепш, Full (Strict).
Памылкі 521, 522 і 525
Памылка 521 азначае, што сервер адхіліў злучэнне, 522 — тайм-аўт, 525 — праблема з SSL-узгадненнем. Праверце, ці не блакуе файрвол IP Cloudflare, ці запушчаны сервер хостынгу, ці сапраўдны SSL-сертыфікат і ці вядуць DNS-запісы на правільны IP.
Не бачныя абнаўленні ў адмін-панэлі
Звычайна выклікана агрэсіўнымі правіламі кэшавання. Выключыце з кэшу адмінку, кошык, аплату і старонкі ўліковых запісаў. У WordPress інтэграцыя плагіна кэшавання з ачысткай кэшу Cloudflare палягчае задачу.
Праблемы з поштай
Вэб-проксі Cloudflare не апрацоўвае паштовы трафік. MX-запісы павінны быць дакладнымі, а запісы, што паказваюць на паштовы сервер, — у рэжыме DNS only. Калі не хапае TXT-запісаў SPF, DKIM і DMARC, магчымыя праблемы з дастаўкай лістоў.
Пакрокавы кантрольны спіс бяспечнай наладкі Cloudflare
Прыведзеная ніжэй паслядоўнасць дае бяспечную і практычную дарожную карту для пачаткоўцаў:
- 1. Дадайце дамен у Cloudflare і параўнайце DNS-запісы з бягучым правайдэрам.
- 2. Уключыце проксі для асноўнага дамена і www-запісу для вэб-трафіку.
- 3. Для пошты, FTP і сэрвісаў кіравання выкарыстоўвайце DNS only.
- 4. Змяніце nameserver-ы ў даменнай панэлі.
- 5. Усталюйце сапраўдны SSL на асноўным серверы і абярыце Full (Strict) у Cloudflare.
- 6. Уключыце опцыі Always Use HTTPS і Automatic HTTPS Rewrites.
- 7. Уключыце WAF Managed Rules; у першыя дні адсочвайце логі і ілжывыя спрацоўванні.
- 8. Вызначце rate limiting або managed challenge для старонак уваходу.
- 9. З дапамогай Cache Rules наладзьце bypass дынамічных вобласцей.
- 10. Падчас атакі падвысьце Security Level і пры патрэбе часова ўключыце Under Attack Mode.
- 11. Заплануйце ўзмацненне сервернага файрвола паводле IP Cloudflare.
- 12. Штотыдзень правярайце Security Events, Analytics і DNS-запісы.
Гэты кантрольны спіс дапамагае зменшыць колькасць памылак, асабліва пры першаснай наладцы. Для высоканаведвальных інтэрнэт-крам або сайтаў з членствам лепш уносіць змены ў гадзіны нізкага трафіку і сачыць за метрыкамі канверсіі.
Маніторынг аналітыкі і падзей бяспекі Cloudflare
Пасля ўстаноўкі Cloudflare праца не сканчаецца; сапраўдная каштоўнасць выяўляецца падчас маніторынгу і паляпшэння. У раздзеле Security Events вы можаце ўбачыць, колькі запытаў і якія правілы заблакіравалі, з якіх краін або IP-дыяпазонаў ідзе атака, якія URL-адрасы з’яўляюцца цэллю. Гэтыя даныя дазваляюць пры напісанні карыстальніцкіх правілаў дзейнічаць не наўздагад, а на падставе доказаў.
Напрыклад, калі ў логах вы бачыце 18 000 няўдалых запытаў да /wp-login.php за 24 гадзіны, замест простага павышэння агульнага ўзроўню бяспекі лепш стварыць спецыяльны rate limit і challenge менавіта для гэтай кропкі. Падобным чынам, калі ваш API-эндпоінт інтэнсіўна выкарыстоўваецца, замест ужывання жорсткага правіла да ўсяго сайта лепш нацэліцца на канкрэтную шкоднасную камбінацыю метаду, краіны або user-agent.
Ці дастаткова аднаго Cloudflare?
Cloudflare — гэта магутны пласт, але бяспеку трэба разглядаць як шматузроўневую сістэму. Калі ваш хостынг-сервер не абнаўляецца, у ПЗ ёсць уразлівасці, пароль адмінкі слабы або няма палітыкі рэзервовага капіявання, Cloudflare не ліквідуе ўсе рызыкі. Надзейны падыход павінен спалучаць бяспечны хостынг, актуальную версію PHP, рэгулярныя бэкапы, SSL, плагіны бяспекі, карэктныя правы доступу да файлаў і кантроль доступу.
Правільны выбар хостынг-пакету ў інфраструктуры Hostragons разам з Cloudflare дапаможа вам стварыць больш стабільную архітэктуру бяспекі і прадукцыйнасці. Па меры росту трафіку пераход з агульнага хостынгу на VPS або воблачны сервер можна разглядаць з пункту гледжання лімітаў рэсурсаў і ўстойлівасці да атак: VPS сервер, Карпаратыўныя хостынг-рашэнні.
Выснова: збалансаваны падыход да бяспечных налад Cloudflare
Правільныя налады Cloudflare складаюцца з безпамылковага пераносу DNS-запісаў, рэжыму SSL Full (Strict), правілаў WAF, кантраляванай аховы ад ботаў, абмежавання хуткасці, карэктных выключэнняў з кэшу і спецыяльных DDoS-рэжымаў на час атакі. Для дасягнення найлепшага выніку ставіцеся да налад не як да аднаразовага дзеяння, а як да працэсу забеспячэння бяспекі, які рэгулярна ўдасканальваецца на аснове даных аб трафіку.
Коратка: прапускайце вэб-трафік праз проксі, абараняйце асноўны сервер, выкарыстоўвайце строгі рэжым SSL, наладжвайце WAF і правілы rate limit у адпаведнасці з вашым рэальным выкарыстаннем. Калі вы хочаце стварыць надзейную аснову з боку дамена, хостынгу або SSL, вы можаце азнаёміцца з рашэннямі Hostragons і спланаваць інфраструктуру, якая адпавядае патрэбам вашага сайта: Хостынг-пакеты Hostragons.
Частыя пытанні
Які рэжым SSL самы бяспечны для налад Cloudflare?
Увогуле, самы бяспечны рэжым SSL — гэта Full (Strict). У гэтым рэжыме паміж наведвальнікам і Cloudflare, а таксама паміж Cloudflare і асноўным серверам выкарыстоўваецца HTTPS, і асноўны сертыфікат праходзіць праверку. Для гэтага на серверы павінен быць усталяваны сапраўдны SSL-сертыфікат.
Ці працуе DDoS-ахова Cloudflare на бясплатным плане?
Cloudflare прапануе базавую DDoS-ахову нават на бясплатным плане. Аднак пашыраны WAF, больш дэталёвае абмежаванне хуткасці, кіраванне ботамі і карпаратыўныя інструменты даступныя на платных планах. Пры гэтым правільна наладжаны бясплатны план можа забяспечыць значную ахову для малых і сярэдніх сайтаў.
Ці трэба трымаць Under Attack Mode уключаным пастаянна?
Не. Рэжым Under Attack Mode варта выкарыстоўваць часова, толькі падчас атакі. Калі ён уключаны пастаянна, сапраўдныя наведвальнікі будуць бачыць дадатковы экран праверкі, што негатыўна ўплывае на карыстальніцкі досвед. У звычайны час WAF, rate limiting і адпаведны Security Level з’яўляюцца больш збалансаваным рашэннем.
Ці патрэбны хостынг, калі я карыстаюся Cloudflare?
Так. Cloudflare забяспечвае пласт бяспекі і прадукцыйнасці перад вашым сайтам; файлы, база даных і сам дадатак па-ранейшаму размяшчаюцца на хостынгу або серверы. Таму надзейная хостынг-інфраструктура застаецца базавым патрабаваннем нават пры выкарыстанні Cloudflare.
Ці могуць налады кэшу Cloudflare выклікаць праблемы ў інтэрнэт-крамах?
Пры няправільнай канфігурацыі — так. Дынамічныя старонкі, такія як кошык, аплата, уліковы запіс карыстальніка і панэль кіравання, павінны быць выключаны з кэшу. Калі статычныя файлы кэшуюцца, а персаналізаваны кантэнт абыходзіць кэш, Cloudflare можна бяспечна выкарыстоўваць для інтэрнэт-крам.
