Як усталяваць серверны файрвол: абарона ад DDoS і шкодных ботаў

Усталяванне сервернага файрвола — гэта працэс, пры якім адкрыты застаюцца толькі неабходныя порты, а ўсё лішняе блакуецца; гэта першы пласт абароны ад DDoS, brute force і шкодных ботаў. На практыцы мэта — абмежаваць SSH-доступ, кантралявана адкрываць вэб-сэрвісы, ставіць ліміты на падазроныя запыты, маніторыць логаў і, калі магчыма, фільтраваць трафік на ўзроўні CDN/WAF да таго, як ён дасягае сервера.

Адразу пасля таго, як вы адкрываеце вэб-сервер у інтэрнэце, за некалькі хвілін вас пачнуць сканаваць порты, спрабаваць SSH, атакоўваць аўтаматызаваныя боты і фэйкавыя user-agent’ы. Асабліва для WordPress, e-commerce, панэляў, API ці гульнявых сервераў файрвол — не проста тэхнічны выбар, а абавязковы элемент стабільнасці. У гэтым гайдзе мы разглянем, як пабудаваць файрвол-архітэктуру на Linux-серверах — крок за крокам: UFW, firewalld, nftables, Fail2ban, вэб-аплікацыйныя файрволы і анты-DDoS падходы.

Важная праўда: лакальны файрвол не здольны спыніць буйныя DDoS-атакі. Калі атака ў 20 Gbps, 80 Gbps і больш дасягае дата-цэнтра або сеткавай інфраструктуры, пакеты могуць забіць ваш канал раней, чым OS пачне іх фільтраваць. Таму правільны шлях — шматпластавая абарона: DDoS абарона ад правайдара, CDN/WAF, OS-файрвол, rate limiting і аналіз логаў разам. Для выбару інфраструктуры наведайце Hostragons рашэнні для VPS і VDS сервераў, а для бяспечнага хостынгу — Hostragons пакеты веб-хостынгу.

Навошта серверны файрвол?

Серверны файрвол — гэта пласт бяспекі, які фільтруе сеткавы трафік па IP-адрасе, порце, пратаколе, стане злучэння і (часам) характарыстыках пакета. Просты прыклад: для сайта трэба адкрыць порты 80 і 443, а порт базы дадзеных 3306 павінен быць закрыты для інтэрнэту. SSH-порт 22 лепш адкрыць толькі для офіснага IP-адрасу, а не для ўсіх.

Файрвол не «выдаляе» ўсе атакі магічна. Яго мэта — зменшыць плошчу атакі. Чым менш адкрытых сэрвісаў, тым менш магчымасцяў для нападнікаў. Напрыклад, на свежым Linux-серверы могуць быць адкрыты SSH, панэль, пошта, база, monitoring-agent і тэст-сэрвісы — кожны з іх генеруе асобны рызыку. Добра настроены файрвол працуе па прынцыпе «па змаўчанні забараніць, дазволіць толькі неабходнае».

Разуменне DDoS і ботаў

Чым DDoS адрозніваецца?

DDoS — гэта атака, якая перашкаджае працы сэрвісу праз масавы трафік з многіх крыніц. Атакі могуць забіць вашу сетку, вычарпаць CPU/RAM або выклікаць «дарогія» аперацыі на application layer. Маленькі сервер, які атрымлівае 50 000 HTTP-запытаў у секунду, можа перастаць адказваць нават пры нармальнай прапускной здольнасці — з-за PHP-FPM, Node.js ці базы дадзеных.

Ці ўсе боты — шкодныя?

Не. Googlebot, Bingbot і некаторыя маніторы карысныя. Але шкодныя боты робяць сканаванне панэляў, спам у формах, крадуць кантэнт, злоўжываюць XML-RPC, ствараюць фэйкавыя рэгістрацыі і login-спробы. Мэта — фільтраваць не ўсіх, а толькі дрэнных па паводзінах: высокая памылка, шмат запытаў за кароткі час, ненатуральныя user-agent’ы, падазроныя URL-шаблоны.

Чэк-ліст перад усталяваннем

Самая вялікая рызыка — заблакаваць доступ да сервера для сябе. Таму перад зменамі зрабіце невялікую падрыхтоўку:

• Не закрывайце актыўную SSH-сесію; тэстуйце ў другім тэрмінале.
• Праверце, ці ёсць у правайдара кансоль, VNC ці аварыйны доступ.
• Складзіце спіс адкрытых портаў: ss -tulpn або netstat -tulpn.
• Запішыце, якія порты выкарыстоўваюць вэб, пошта, DNS, база, панэль і monitoring.
• Калі карыстаецеся IPv6 — прадумайце правілы для яго.
• Спачатку дадавайце allow-правілы, потым deny.
• Упэўніцеся, што правілы захоўваюцца пасля рэстарту.

Напрыклад, для тыповага вэб-сервера трэба адкрыць толькі 80, 443 і SSH (абмежавана). Калі пошта не працуе — порты 25, 465, 587, 993 можна закрыць. Калі база дадзеных толькі для лакальных патрэб — 3306 або 5432 павінны быць закрыты для інтэрнэту.

Які файрвол выбраць?

У Linux ёсць некалькі інструментаў, кожны з якіх кіруе аднымі і тымі ж фільтрамі з розным UI. UFW просты для пачаткоўцаў. На Red Hat-падобных — firewalld. Для складаных задач — nftables. Табліца ніжэй дапамагае выбраць:

Пакрокавая ўстаноўка сервернага файрвола

1. Вызначце адкрытыя порты і сэрвісы

Пачніце з праверкі: ss -tulpn пакажа, што слухае ваш сервер. Напрыклад, nginx на 0.0.0.0:80 і 0.0.0.0:443 — вэб-трафік з усіх інтэрфейсаў. MariaDB на 0.0.0.0:3306 — рызыка; база павінна слухаць 127.0.0.1.

Правіла: нічога, што не трэба адкрываць у інтэрнэце, не павінна слухаць 0.0.0.0. Спачатку настройце сэрвіс, потым — файрвол. Так вы абаронены нават калі файрвол «выключаны».

2. Замаўчанні палітыка — закрыта

У бяспечных rule-set’ах па змаўчанні ўваход забаронены, выход дазволены толькі пры патрэбе. Гэта абараняе ад выпадковага адкрыцця новых сэрвісаў. На Ubuntu з UFW: спачатку дазвольце SSH, потым 80 і 443, затым зрабіце deny па змаўчанні і ўключыце файрвол.

Прыклад: дазвольце SSH для вашага IP, адкрыць HTTP/HTTPS, закрыць лішняе, уключыць файрвол. Не ўключайце файрвол без SSH-дазволу — гэта часта прыводзіць да страты доступу.

3. Абмежуйце SSH-доступ

SSH — галоўная мішэнь для атакавальнікаў. Калі port 22 адкрыты ўсім, сервер атрымлівае сотні/тысячы brute force у дзень. Лепшы шлях — дазваляць толькі ваш IP або VPN. Калі IP не пастаянны, выкарыстоўвайце ключы і адключыце паролі.

• Забароніце root-SSH.
• Выкарыстоўвайце толькі SSH-key.
• AllowUsers/AllowGroups — абмежуйце юзераў.
• Fail2ban — аўтаматычна блакуйце няўдалыя спробы.
• Панэль — абмежуйце доступ па IP.

Змяняць порт — не гарантыя бяспекі, але зменшае шум ад аўтаботаў. Рэальная абарона — IP-абмежаванне, моцная аўтэнтыфікацыя, маніторынг логаў.

4. Вэб-порты — адкрываем з розумам

Для большасці сайтаў патрэбны 80 і 443. Але цяпер 443 (HTTPS) — асноўны, 80 — толькі для перанакіравання. Без SSL сайт страчвае давер і SEO. Hostragons SSL сертыфікаты — натуральны ўнутраны лінк пра бяспечны HTTPS.

Калі выкарыстоўваеце CDN або рэверс-праксі, лепш адкрываць 80/443 толькі для IP-адрасоў CDN. Так атакоўнік не зможа атрымаць доступ, нават калі ведае IP сервера.

5. База і ўнутраныя сэрвісы — закрытая для інтэрнэту

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB і падобныя — рызыка, калі адкрыты для інтэрнэту. Redis без аўтэнтыфікацыі, Elasticsearch з адкрытым індэксам, MongoDB з адкрытым портам — прычына ўцечкі дадзеных. Гэтыя сэрвісы павінны слухаць толькі localhost або ўнутраную сетку.

Для сайта на адным серверы — база на 127.0.0.1. Калі база асобна — дазвольце толькі IP прыкладання. Порт 3306 або 5432 адкрыты ў інтэрнэце — распаўсюджаная памылка.

6. Fail2ban — абарона ад brute force

Fail2ban маніторыць логаў і блакуе IP, што шмат разоў няўдала спрабуе ўваход. Для SSH, nginx, Apache, Postfix, Dovecot, WordPress login і панэляў можна настроіць jail. Напрыклад, калі 5 няўдалых SSH за 10 хвілін — IP блакуецца на гадзіну.

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

7. Rate limiting і ліміты злучэнняў

Для абароны ад DDoS і ботаў можна абмежаваць частату злучэнняў на OS-узроўні. Напрыклад, з аднаго IP — не больш X злучэнняў у секунду. Для nginx — limit_req і limit_conn, для Apache — mod_evasive. Для аплікацый — ліміты login, search, cart, payment, API.

Прыклад: login — 10 спроб за хвіліну на IP, search — 2-5 запытаў за секунду. Для API — ліміт па token, па IP, паводле паводзін. Так атакоўнік не абыйдзе ліміты проста змяняючы IP.

Прыклад бяспечнай ўстаноўкі UFW

На Ubuntu/Debian можна зрабіць просты старт: праверыць сэрвісы, дазволіць SSH толькі з вашага IP, адкрыць 80 і 443, па змаўчанні закрыць уваход, праверыць статус UFW. Калі няма сталага IP — часова дазвольце SSH для ўсіх, затым перайдзіце на VPN/сталы IP.

Прыклад: ваш IP — 203.0.113.10. SSH — толькі з яго, вэб — адкрыты ўсім, база, Redis, панэль, тэсты — закрыты. Гэта добры старт для малых/сярэдніх сайтаў. Для правільнай работы DNS — Hostragons праверка дамена і рэгістрацыя.

firewalld і zone-логіка

На AlmaLinux, Rocky, RHEL часта выкарыстоўваюць firewalld. У ім zone — public (адкрыта для інтэрнэту), trusted (для ўнутраных сетак), drop (для блакавання). Важна: runtime — адразу, але знікае пасля рэстарту; permanent — пастаянна, патрабуе reload.

З firewalld зручна адкрываць сэрвісы па zone. Напрыклад, http/https — у public, ssh — толькі для вашага IP. Калі сетка падзелена на management, backup, user — zone павялічваюць бяспеку і зручнасць.

CDN, WAF і правайдарскі DDoS

Лакальны файрвол фільтруе пакеты толькі пасля таго, як яны дасягнулі сервера. Пры вялікіх DDoS задача — фільтраваць да сервера. CDN, WAF, DDoS ад правайдара — крытычныя. CDN выдае статыку з edge-локацый, WAF фільтруе шкодныя application-запыты, правайдар абараняе ад сеткавых масавых атак.

Ідэальна: DNS — праз CDN, IP сервера — схаваны, файрвол — адкрыты толькі для CDN, management — праз VPN або сталы IP. Гэта зніжае рызыку атак па IP і ботаў. Для комплекснай бяспекі і хуткасці сайта — Кіраўніцтва па павышэнню хуткасці і бяспецы сайта.

Абарона ад ботаў на application layer

Абарона ад ботаў — не толькі IP-ban. Сучасныя боты выкарыстоўваюць proxy, мабільныя сеткі, змяняюць user-agent’ы. Таму трэба аналізаваць паводзіны: шмат login, масавыя 404, wp-login.php/xmlrpc.php-актыўнасць, нехарактэрныя клікі і загалоўкі.

• Rate limiting на login/registration.
• Забарыць або абмежаваць XML-RPC.
• Панэль — іншы URL, IP-абмежаванне, MFA.
• Фільтрацыя user-agent/referer на WAF.
• CAPTCHA ці невідочны бот-чэк у формах.
• API — ключы, подпісы, квоты, timestamp.

Не перашчыруйце: лішняя CAPTCHA, агрэсіўны ban або country block шкодзіць рэальным кліентам. Працуйце па ступенях, тэстуйце, аналізыруйце.

Маніторынг логаў і алерты

Думаць, што «ўстаноўка завершана» — памылка. Файрвол — жывая сістэма, патрабуе маніторынгу. auth.log/secure — SSH-спробы; nginx access — аномальны трафік; error — рост 404/500; сістэмныя метрыкі — CPU, злучэнні. Просты алерт — зэканоміць хвіліны пры атацы.

Прыклад пачатковых thresholds: за 5 хвілін — больш за 100 404 з аднаго IP, за 1 хвіліну — 20 login-спроб, CPU — 90%+ 10 хвілін, connections — у 3 разы больш нармальнага. Значэнні — індывідуальныя, важна ведаць свой baseline.

Тыповыя памылкі і як іх пазбегнуць

• Уключыць файрвол без SSH-дазволу: Страта доступу да сервера. Тэстуйце ў другім тэрмінале.
• Забыліся пра IPv6: Сэрвісы могуць быць адкрыты па IPv6 нават калі IPv4 закрыты.
• База адкрыта ў інтэрнэце: Порты 3306, 5432, 6379, 9200 скануюцца ботамі пастаянна.
• CDN, але адкрыты рэальны IP: Атакоўнік абыходзіць CDN і атакуе сервер.
• Змяняць правілы без дакументацыі: У экстранай сітуацыі цяжка зразумець, што і навошта.
• Адсутнасць аварыйнага доступу: Памылковы rule — і няма кансолі.

Прыклад практычнай палітыкі файрвола

Для малога бізнес-сайта: уваход закрыты па змаўчанні; 443 — адкрыты ўсім; 80 — толькі для перанакіравання; SSH — толькі для VPN/сталага IP; база — толькі localhost або ўнутраная сетка; CDN — 80/443 толькі для яго IP; Fail2ban маніторыць SSH/login; логаў адпраўляюцца ў цэнтральны маніторынг.

Для сярэдняй e-commerce: allowlist callback IP для аплаты, панэль — за VPN, API — квоты на карыстальніка, WAF — SQL injection/XSS фільтры, часовыя country/ASN-фільтры. Палітыка павінна быць напісаная — так вы дзейнічаеце па плане, а не імпульсіўна.

Тэставанне: ці працуюць правілы?

Пасля ўстаноўкі файрвола — абавязкова тэстуйце. З іншай сеткі скануйце порты, праверце SSH на IP, праверце HTTPS, упэўніцеся, што база закрыта для знешніх. Калі CDN — праверце, што рэальны IP не даступны з інтэрнэту.

Не рабіце агрэсіўныя сканы на прадуктыў, толькі бяспечныя праверкі. Пасля кожнай змены экспартуйце/фіксуйце правілы — так лёгка вярнуць працу пры праблеме.

План абслугоўвання і абнаўлення

Бяспека — не разовая задача, а працэс. Калі дадаеце сэрвіс — пераглядайце порты; выдаляеце — выдаляйце дазволы. Абнаўляйце бяспеку ў тэрмін, правярайце логаў. Раз на месяц — скануйце адкрытыя порты, раз у тры месяцы — пераглядайце ruleset.

Бэкап — частка стратэгіі. DDoS можа перашкодзіць доступу, а ransomware/ўзлом — страціць дадзеныя. Падумайце пра бяспечны хостынг, SSL, дамен, бэкап разам. Для гэтага — Што трэба ўлічваць пры выбары бяспечнага хостынгу і Як усталяваць сертыфікат SSL.

Вынік

Файрвол не робіць сервер «нябачным» для DDoS і ботаў, але значна зніжае плошчу атакі, рызыку несанкцыянаванага доступу і дае вам кантроль над рэакцыяй. Найлепшы вынік — калі разам працуюць правайдарскі DDoS, CDN/WAF, строгая палітыка партоў, SSH-абмежаванне, Fail2ban, rate limiting, маніторынг логаў.

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

Пытанні і адказы

Ці можа файрвол цалкам заблакаваць DDoS?

Не. Лакальны файрвол абараняе ад малых атак і пэўных пратаколаў, але для буйных DDoS патрэбны правайдарскі анты-DDoS, CDN і WAF.

Якія порты павінны быць адкрыты на вэб-серверы?

Тыпова — 80 і 443. SSH — толькі для адміністратара па IP. База і ўнутраныя сэрвісы — закрыты для інтэрнэту.

UFW ці firewalld?

Для Ubuntu/Debian — UFW прасцей. Для AlmaLinux, Rocky, RHEL — firewalld. Для складаных і спецыяльных задач — nftables.

Ці можна спыніць бот-трафік толькі IP-ban’ам?

Амаль ніколі. Сучасныя боты змяняюць IP, выкарыстоўваюць proxy. Трэба rate limiting, WAF-правілы, аналіз паводзінаў, CAPTCHA, application-квоты.

Якая самая вялікая рызыка пры настройцы файрвола?

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