Подешавање безбедносног зида сервера: Заштита сервера од DDoS и ботова

Подешавање безбедносног зида сервера подразумева остављање отвореним само неопходних портова и блокирање свих непотребних приступа; оно представља први слој одбране против DDoS, brute force и злонамерног бот саобраћаја. У пракси, циљ је ограничити SSH приступ, контролисано отворити веб услуге, ставити ограничења на сумњиве захтеве, пратити логове и, ако је могуће, филтрирати саобраћај пре него што дође до сервера уз помоћ CDN/WAF као додатних мера заштите.

Чим отворите веб сервер за интернет, у року од неколико минута можете се сусрести са скенирањем порта, SSH покушајима, ботом за рањивости и лажним корисничким агентима. Посебно у структурама које користе WordPress, e-трговину, панеле, API или игре, безбедносни зид није само технички избор, већ је обавезан за континуитет. У овом водичу ћемо поставити архитектуру безбедносног зида корак по корак на Linux серверима; заједно ћемо размотрити UFW, firewalld, nftables, Fail2ban, веб апликациони безбедносни зид и приступе за смањење DDoS напада.

Почнимо са важном чињеницом: Локални безбедносни зид сервера сам по себи не може зауставити велике DDoS нападе. Када напад од 20 Gbps, 80 Gbps или више достигне дата центар или мрежну инфраструктуру, пакети могу попунити пропусни опсег пре него што стигну до сета правила вашег оперативног система. Због тога је правилан приступ слојевита безбедност: заштита од DDoS на нивоу провајдера, CDN/WAF, безбедносни зид оперативног система, ограничење брзине апликације и редовна анализа логова морају радити заједно. За избор одговарајуће инфраструктуре можете се упутити на страницу Hostragons решења за VPS и VDS сервере, а за опције безбедног хостинга на веб страни можете се упутити на Hostragons веб хостинг пакети.

Шта ради безбедносни зид сервера?

Безбедносни зид сервера је слој безбедности који филтрира мрежни саобраћај на основу изворне IP адресе, одредишне IP адресе, порта, протокола, стања везе и у неким случајевима особина пакета. На простом примеру, портови 80 и 443 треба да буду отворени за вашу веб страницу, али порт 3306, који се користи за базу података, не би требало да буде отворен за интернет. Уместо да свима дозволите пробу порта 22 за SSH, боље је дозволити само вашој канцеларијској IP адреси.

Основна сврха безбедносног зида није да магично уништи све нападе. Главни циљ је смањити површину напада. Што је површина напада мања, опције које нападач може испробати су мање. На пример, на недавно инсталираном Linux серверу, SSH, веб панел, поштанска служба, база података, агенти за мониторинг и тестне услуге могу бити отворени истовремено. Свака од њих представља посебан ризик. Добро конфигурисан безбедносни зид функционише на принципу "по подразумеваној вредности одбиј, дозволи оно што је потребно".

Разумевање DDoS и бот саобраћаја

Шта чини DDoS нападе различитим?

DDoS, или напади распоређеног одбијања услуге, имају за циљ да учине циљану услугу недоступном интензивним саобраћајем из великог броја извора. Напад понекад попуњава пропусни опсег, понекад троши ресурсе CPU и RAM сервера, а понекад активира скупоцене операције на нивоу апликације. На пример, мала апликација која прима 50.000 HTTP захтева у секунди, може постати недоступна чак и ако мрежна линија није заузета, због PHP-FPM, Node.js или базе података.

Да ли су сви ботови лоши?

Није. Googlebot, Bingbot и неки ботови за мониторинг су корисни. Међутим, злонамерни ботови могу вршити скенирање администраторских панела, отворено претраживање директоријума, спамовање формулара, копирање садржаја, злоупотребу XML-RPC, генерисање лажних уписа и покушаје пријаве. Стога, у управљању ботова, циљ није блокирати све ботове, већ правити разлику на основу понашања. Високи проценат грешака, велики број захтева у кратком временском периоду, заглавља која се не понашају као прави прегледачи и сумњиви образци URL адреса представљају важне сигнале.

Контролна листа пре почетка подешавања

Када пишете правило безбедносног зида на активном серверу, највећи ризик је да се закључате из сервера. Због тога је важно направити кратку припрему пре него што направите промене. Следећа контролна листа представља безопасан почетни приступ који се често користи у производним окружењима.

• Не затварајте активну SSH сесију; тестирајте са другим терминалом.
• Уверите се да ваш провајдер сервера нуди конзолу, VNC или приступ за опоравак.
• Листирајте тренутне отворене портове: прегледајте излаз ss -tulpn или netstat -tulpn.
• Забележите које портове користе веб, пошта, DNS, база података, панел и мониторинг услуге.
• Ако користите IPv6, планирајте и правила безбедносног зида за IPv6.
• Прво примените allow правила, а затим deny правила.
• Уверите се да је сет правила трајан; не би требало да се изгуби при поновном покретању сервера.

На пример, на типичном серверу који хостује само веб страницу, портови који би требало да буду отворени често су 80, 443 и ограничени SSH порт. Ако поштански сервер не ради, портови као што су 25, 465, 587, 993 не морају бити отворени. Ако се база података користи само изнутра, портови 3306 или 5432 би требало да буду затворени за спољни свет.

Који алат за безбедносни зид бисте требали да изаберете?

У свету Linux постоји више алата и већина управља истом инфраструктуром филтрирања, али са различитим лакоћама коришћења. За почетнике, UFW је једноставан и брз. У корпоративним или Red Hat базираним системима, firewalld је често коришћен. У напреднијим сценаријима, nftables нуди модерну и флексибилну структуру. Следећа табела олакшава избор.

Корак по корак подешавање безбедносног зида сервера

1. Одредите отворене портове и услуге

Први корак је видети шта је отворено. На Linux серверу, команда 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. Поставите подразумевану политику на затворено

У безбедним сетовима правила, подразумевани долазни саобраћај се одбија, а одлазни саобраћај се пушта по потреби. Овај приступ спречава случајно отварање услуга за интернет. У серверу на Ubuntu који користи UFW, логика је следећа: прво се дозвољава SSH, затим се отварају портови 80 и 443, а затим се подразумевана политика долазног саобраћаја поставља на deny, а безбедносни зид се активира.

Пример тока: Дозволите SSH за вашу администраторску IP адресу, отворите HTTP и HTTPS саобраћај, затворите непотребне портове, а затим активирајте. Отварање безбедносног зида без да се дозволи SSH је једна од најчешћих грешака, посебно на удаљеним серверима.

3. Ограничите SSH приступ

SSH је једна од услуга коју нападачи највише циљају. Сервер са отвореним подразумеваним портом 22 може да види стотине или хиљаде покушаја лога дневно. Најбезбеднији приступ је ограничити SSH приступ на одређене IP адресе. Ако користите статичку IP адресу, дозволите само вашу канцеларијску или VPN IP адресу. Ако немате статичку IP адресу, барем користите аутентификацију засновану на кључу и искључите унос лозинке.

• Онемогућите директан SSH приступ као root.
• Користите SSH кључ уместо лозинке.
• Ограничите кориснике помоћу AllowUsers или AllowGroups.
• Аутоматски блокирајте неуспеле покушаје помоћу Fail2ban.
• Ако користите администраторски панел, такође ограничите порт панела на IP.

Промена порта сама по себи не пружа безбедност, али може смањити аутоматске ботове. Ипак, права заштита долази од IP ограничења, чврсте аутентификације и праћења логова.

4. Контролисано отварање веб портова

За већину сервера који објављују веб странице, портови 80 и 443 су неопходни. Међутим, данас 443, односно HTTPS, треба да буде главни порт за саобраћај, док се 80 треба користити само за преусмеравање на HTTPS. Веб странице без SSL сертификата негативно утичу на поверење корисника и SEO перформансе. У овом тренутку, Hostragons SSL сертификати представља природну унутрашњу везу за упућивање читалаца на безбедно подешавање HTTPS.

Када отварате веб портове, обратите пажњу на понашање праве IP адресе. Ако користите CDN или обрнути прокси, боље је дозволити саобраћај на портовима 80 и 443 само из опсега IP адреса CDN-а, уместо да их отворите за цео интернет. На тај начин, иако нападач зна праву IP адресу сервера, не може директно приступити веб услузи.

5. Затворите базу података и унутрашње услуге за интернет

Отворене услуге као што су MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB и слично представљају озбиљан ризик. Недостатак аутентификације за Redis, неовлашћен приступ индексима за Elasticsearch или отворени порт за управљање за MongoDB изазвали су многе пропусте података у прошлости. Ове услуге би требало да слушају само на localhost или приватној мрежи, ако је то могуће.

На пример, за WordPress страницу која ради на истом серверу, база података треба да ради на 127.0.0.1. Ако користите посебан сервер за апликације и базе података, дозволите само приватну IP адресу сервера апликације. Остављање портова 3306 или 5432 отвореним за интернет представља познату грешку коју непрестано скенирају ботови.

6. Блокирајте покушаје brute force помоћу Fail2ban

Fail2ban прати логове и идентификује поновљене неуспешне покушаје пријаве, блокирајући одређену IP адресу на кратко. Могу се дефинисати затвори за SSH, nginx, Apache, Postfix, Dovecot, WordPress логин и неке панел услуге. На пример, блокирање IP адресе која направи 5 неуспешних SSH покушаја за 10 минута је једноставан, али ефектан почетак.

Будите опрезни при коришћењу агресивних правила у конфигурацији Fail2ban. Погрешан шаблон логова може блокирати и праве кориснике. Због тога је у првој фази боље задржати разумну вредност за bantime, праћити логове и касније постепено поошравати.

7. Додајте ограничења брзине и лимите за везе

Ограничење брзине на нивоу оперативног система може помоћи против DDoS и бот саобраћаја. На пример, ако долази преко мерењa нових веза из исте IP адресе у секунди, може се применити лимит. На страни веб сервера, за nginx могу се користити limit_req и limit_conn модули, а за Apache mod_evasive или слична решења. На страни апликације, такође треба поставити ограничење брзине за логин, претрагу, корпу, плаћање и API ендпоинте.

Конкретан пример: На страници за пријаву, 10 покушаја по IP адреси у минути може бити разумно. На ендпоинту за претрагу, 2-5 захтева у секунди може бити довољно. Ако пружате API, ограничење по кориснику, IP лимит и анализа понашања треба да буду заједно осмишљени. Тако нападач не може само променити IP адресу да би превазио све лимите.

Пример безбедне конфигурације са UFW

На веб серверу заснованом на Ubuntu или Debian, једноставна безбедна почетна конфигурација може бити постављена на следећи начин: прво проверите постојеће услуге, дозволите SSH приступ само из ваше администраторске IP адресе, отворите портове 80 и 443, подразумевано одбијте долазни саобраћај и потврдите статус UFW. Ако ваш SSH приступ не може бити ограничен на статичку IP адресу, можете привремено дозволити SSH из свих IP адреса, а затим прећи на VPN или статичко решење.

Пример одлука: Нека ваша администраторска IP адреса буде 203.0.113.10. SSH треба да долази само из ове IP адресе. Веб саобраћај треба да буде отворен за све на портовима 80 и 443. База података, Redis, панел и тест портови треба да буду затворени за спољни свет. Ова конфигурација представља добар почетак за многе мале и средње корпоративне веб странице. Да бисте исправно усмерили домен и DNS, можете упутити на страницу Hostragons упит за домен и регистрацију.

firewalld и концепт зона

У AlmaLinux, Rocky Linux и RHEL заснованим серверима, firewalld се често користи. firewalld ради на концепту зона. Јавна зона је за интерфејсе отворене за интернет, поуздана зона је за поверљиве приватне мреже, а зона drop се користи за тихо одбацивање непожељног саобраћаја. Најважнија тачка је разлика између runtime и permanent правила. Runtime правило се тренутно примењује, али може се изгубити при поновном покретању; permanent правило је трајно, али може захтевати поновно учитавање.

У корпоративним окружењима, коришћење firewalld са дефиницијама базираним на услугама олакшава ствари. На пример, можете отворити http и https услуге у јавnoj зони, а осигурати да ssh услуга буде доступна само из одређених IP адреса. Ако су управљачка мрежа, мрежа за резервно копирање и кориснички саобраћај на одвојеним интерфејсима, структура зона повећава безбедност и читљивост.

CDN, WAF и заштита на нивоу провајдера од DDoS напада

Локални безбедносни зид доноси одлуке тек након што пакети стигну до сервера. Код великих DDoS напада, циљ је филтрирати саобраћај пре него што стигне до сервера. Стога је CDN, WAF и заштита од DDoS на нивоу провајдера кључна. CDN испоручује статички садржај на ивичним локацијама, WAF филтрира злонамерне захтеве на нивоу апликације, а заштита провајдера апсорбује или очисти велике нападе на нивоу мреже.

У идеалном моделу, ваши DNS записи пролазе кроз CDN, права IP адреса сервера је сакривена, а ваш безбедносни зид сервера прихвата само 80 и 443 из опсега IP адреса CDN-а. Управљачки портови су доступни само преко VPN или статичке IP адресе. Овакав модел смањује вероватноћу напада на директну IP адресу и омогућава вам да зауставите бот саобраћај пре него што стигне до апликације. За садржаје који истовремено обрађују безбедност веба и перформансе, можете користити везу водичи за убрзавање и безбедност веб сајта.

Мере на нивоу апликације против ботова

Блокирање ботова није само питање IP забране. Модерни ботови могу користити прокси, мобилне мреже, IP адресе из дата центара и променљиве корисничке агенте. Због тога је потребан приступ фокусиран на понашање. Много покушаја пријаве из исте IP адресе у кратком временском периоду, константно генерисање 404, учесталост wp-login.php или xmlrpc.php, образац кликова различит од нормалног корисника и сумњива заглавља треба анализирати.

• Користите ограничење брзине у формама за пријаву и регистрацију.
• Искључите или ограничите непотребан XML-RPC приступ.
• Заштитите управљачки панел различитим URL-ом, IP ограничењем и вишефакторском аутентификацијом.
• Филтрирајте сумњиве user-agent и реферер образце на нивоу WAF.
• У формама уравнотежено користите CAPTCHA или механизме за верификацију ботова.
• Додајте контроле кључа, потписа, квоте и временских ознака за API ендпоинте.

У управљању ботова важно је не нарушити корисничко искуство. Прекомерна употреба CAPTCHA, агресивно блокирање или погрешне блокаде по држави могу наштетити вашим правим клијентима. Због тога, мерење, тестирање и постепено пооштравање представљају најбољи метод.

Праћење логова и правила за аларм

Мислити да је подешавање завршено је уобичајена грешка. Безбедносни зид је живај систем и треба редовно пратити. У auth.log или secure датотеци треба пратити SSH покушаје, аномалну густину захтева у nginx access логовима, повећање 404 и 500 у error логовима и праћење CPU и броја веза у системским метрикама. Чак и једноставан аларм може уштедети минуте када напад почне.

Примери прагова за почетак могу бити следећи: 100 или више 404 захтева из исте IP адресе у року од 5 минута, више од 20 покушаја на страници за пријаву у року од 1 минута, CPU употреба која остаје изнад 90% током 10 минута, број веза који је три пута већи од нормалног. Ови прагovi се разликују од сајта до сајта; важно је знати ваш нормални профил саобраћаја.

Уобичајене грешке и начини да их избегнете

• Активирање безбедносног зида без давање SSH дозволе: Може вас довести до губитка приступа на удаљеном серверу. Увек тестирајте са другом сесијом.
• Заборављање IPv6: Уколико је IPv4 затворен, услуга може остати отворена преко IPv6.
• Остављање базе података отвореном за интернет: Портови као што су 3306, 5432, 6379 и 9200 континуирано скенирају ботови.
• Користити CDN и оставити праву IP адресу отвореном: Нападач може заобићи CDN и директно напасти сервер.
• Мењање правила без документације: У хитним ситуацијама може бити тешко разумети шта које правило ради.
• Не креирати резервни план за приступ: Ако правилo доведе до проблема, прекид може бити продужен.

Практичан пример политике безбедносног зида

За мали корпоративни веб сајт, сажета политика може бити следећа: долазни саобраћај је подразумевано затворен; 443 је отворен за све посетиоце; 80 је отворен само за преусмеравање на HTTPS; SSH је доступан само из VPN или статичке администраторске IP адресе; база података је на localhost или приватној мрежи; ако се користи CDN, 80 и 443 су отворени само за IP опсеге CDN; Fail2ban прати SSH и веб покушаје пријаве; логови се шаљу на централизовани алат за мониторинг.

За средње велике e-трговинске сајтове, поред тога, IP адресе за повратне позиве за плаћање треба ставити на allowlist, администраторски панел треба ставити иза VPN, за API треба применити ограничење по кориснику, а WAF треба активирати правила за SQL инјекције и XSS, планирати привремено филтрирање по држави или ASN. Овај план треба да буде написан; применом унапред одређених процедура смањује се време прекида у случају напада.

Тестирање: Да ли правила заиста раде?

Након подешавања безбедносног зида, тестирање мора бити обавезно. Скенирајте отворене портове из друге мреже, потврдите да SSH ради само из дозвољене IP адресе, проверите да ли је веб сајт доступан преко HTTPS, уверите се да је порт базе података затворен за спољни свет. Ако користите CDN, пошаљите директан HTTP захтев на праву IP адресу сервера и потврдите да је блокиран.

Током тестирања, избегавајте агресивно скенирање које може наштетити производним системима. Циљ је извршити безбедну верификацију. Такође, након сваке промене, извезите или забележите сет правила. На тај начин, у случају проблема, лакше је вратити се на претходну здраву конфигурацију.

План одржавања и ажурирања

Безбедност сервера није једнократна инсталација, већ редован процес одржавања. Када се дода нова услуга, потреба за портом треба прегледати, а када се стара услуга уклони, релевантне дозволе треба обрисати, безбедносна ажурирања треба применити на време, а логови периодично проверавати. Извршити проверу отворених портова најмање једанпут месечно, а сваког тромесечја прегледати сет правила за безбедносни зид представља добар практичан почетак.

Поред тога, план резервног копирања је део стратегије безбедности. DDoS напад може прекинути приступ, али ransomware или неовлашћени приступ могу довести до губитка података. Безбедно хостовање, SSL, управљање доменима и резервне копије треба разматрати заједно. У том контексту, Ставке на које треба обратити пажњу при избору безбедног хостинга и Како се изводи инсталација SSL сертификата представљају природне наставне везе.

Закључак

Подешавање безбедносног зида сервера не чини сервер потпуно невидљивим за DDoS и ботове; али озбиљно смањује површину напада, смањује ризик од неовлашћеног приступа и омогућава вам да контролисаније реагујете на инциденте. Најбољи резултат се добија комбинацијом DDoS заштите на нивоу провајдера, CDN/WAF, строгих политика порта, ограничења SSH, Fail2ban-а, ограничења брзине и редовног праћења логова.

Ако покрећете нови пројекат, планирање политике безбедносног зида од самог почетка је лакше од каснијег исправљања. Док процењујете сервер, хостинг, домен и SSL инфраструктуру на Hostragons, размислите о вашим безбедносним потребама да бисте створили издржљивије веб окружење. Ако вам је потребно, почните са малом контролном листом: затворите отворене портове, ограничите SSH, обавезно користите HTTPS и пратите логове.

Често постављана питања

Да ли безбедносни зид сервера потпуно блокира DDoS нападе?

Не. Локални безбедносни зид може смањити мале и неке нападе на нивоу протокола, али за велике DDoS нападе потребна је заштита на нивоу провајдера, као и коришћење CDN и WAF.

Који портови треба да остану отворени на веб серверу?

На типичном веб серверу, портови 80 и 443 остају отворени. SSH порт треба да буде доступан само за администраторске IP адресе. Портови за базу података и унутрашње услуге треба да остану затворени за интернет.

Да ли да користим UFW или firewalld?

UFW нуди лакши почетак за Ubuntu и Debian. firewalld је често коришћен у AlmaLinux, Rocky Linux и RHEL системима. За напредне и специфичне сценарије, nftables може бити одабран.

Могу ли зауставити бот саобраћај само IP блокадом?

Обично не. Модерни ботови користе различите IP адресе и прокси. Поред блокаде IP адреса, треба користити ограничења брзине, WAF правила, анализу понашања, CAPTCHA и ограничења на нивоу апликације.

Који је највећи ризик при подешавању безбедносног зида?

Највећи ризик је прекид SSH приступа због погрешног правила. Стога, прво треба дефинисати SSH дозволу, тестирати са другом сесијом и имати спреман приступ конзоли провајдера.