Настройка на защитна стена на сървъра: Защита на сървъра от DDoS и ботове

Настройката на защитната стена на сървъра е процес, при който оставяте отворени само необходимите портове и блокирате всички ненужни достъпи; това е първият слой защита срещу DDoS, brute force и зловреден трафик от ботове. В практиката целта е да се ограничи SSH достъпа, да се отворят уеб услугите контролирано, да се приложат ограничения на подозрителните заявки, да се следят логовете и, ако е възможно, да се филтрира трафика преди да достигне до сървъра с помощта на CDN/WAF и други защитни решения от по-високо ниво.

Когато отворите уеб сървъра си за интернет, може да се сблъскате с порт сканирания, SSH опити, зловредни ботове и фалшиви потребителски агенти в рамките на минути. Особено ако работите с WordPress, електронна търговия, панели, API или игрови сървъри, защитната стена не е само технически избор, а задължителна мярка за поддържане на сигурността. В това ръководство ще изградим стъпка по стъпка архитектура на защитната стена за Linux сървъри; ще разгледаме UFW, firewalld, nftables, Fail2ban, защитна стена на уеб приложения и методи за намаляване на DDoS атаките.

Нека започнем с един важен факт: Локалната защитна стена на сървъра не може да спре големи DDoS атаки сама по себе си. Атака с обем 20 Gbps, 80 Gbps или по-висока, когато достигне до центъра за данни или мрежовата инфраструктура, може да запълни пропускателната способност преди пакетите да стигнат до правилата на вашата операционна система. Затова правилният подход е многослойна сигурност: защита от DDoS на ниво доставчик, CDN/WAF, защитна стена на операционната система, ограничаване на трафика на приложенията и редовен анализ на логовете, които работят в синхрон. За подходящ избор на инфраструктура може да се даде линк към Hostragons решения за VPS и VDS сървъри, а за сигурни опции за хостинг на сайта - към Hostragons пакети за уеб хостинг.

Какъв е приносът на защитната стена на сървъра?

Защитната стена на сървъра е слой защита, който филтрира мрежовия трафик на базата на изходящи и входящи IP адреси, портове, протоколи, състояние на връзката и в някои случаи характеристики на пакетите. С прост пример; за вашия уебсайт портовете 80 и 443 трябва да са отворени, но портът за базата данни 3306 не трябва да е отворен за интернет. Вместо да позволявате на всеки да опитва достъп до SSH на порт 22, е много по-сигурно да разрешите достъпа само от 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.
• Първо прилагайте правила за разрешаване, след това за блокиране.
• Уверете се, че наборът от правила е постоянен; не трябва да се губи при рестартиране на сървъра.

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

Кой инструмент за защитна стена да изберете?

В света на Linux има множество инструменти и повечето от тях управляват същата основна инфраструктура за филтриране с различни удобства за ползване. За начинаещи, UFW е прост и бърз. В корпоративни или системи, базирани на Red Hat, firewalld е разпространен. В по-сложни сценарии, nftables предлага съвременна и гъвкава структура. Следната таблица улеснява избора.

Стъпка по стъпка настройка на защитната стена на сървъра

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

Първата стъпка е да видите какво е отворено. Командата ss -tulpn на Linux сървър показва кои услуги слушат на кои портове. Например, ако 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 и трафика на ботове. Например, ако идват прекомерен брой нови връзки от един и същи IP адрес в секунда, може да приложите лимит. От страната на уеб сървъра, nginx предлага модулите limit_req и limit_conn, а Apache предлага mod_evasive или подобни решения. От страната на приложението, трябва да се поставят ограничения на скоростта за вход, търсене, пазаруване, плащане и API крайни точки.

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

Примерен сценарий за безопасна настройка с UFW

Проста безопасна начална настройка на уеб сървър на базата на Ubuntu или Debian може да бъде направена по следния начин: първо проверете наличните услуги, разрешете SSH достъп само от вашия администраторски IP адрес, отворете портовете 80 и 443, задайте входящия трафик по подразбиране на deny и проверете състоянието на UFW. Ако не можете да ограничите SSH достъпа до статичен IP, временно разрешете SSH за всички IP адреси и след това преминете на VPN или статично IP решение.

Примерният набор от решения може да изглежда така: 203.0.113.10 да бъде администраторският IP адрес. SSH трябва да идва само от този IP. Уеб трафикът да остане отворен за всички през 80 и 443. Базата данни, Redis, панелът и тестовите портове да останат затворени за външния свят. Тази структура е добро начало за много малки и средни корпоративни уебсайтове. За правилно пренасочване на домейни и DNS може да се даде линк към Hostragons проверка на домейн и регистрация.

firewalld с логика на зони

firewalld е широко използван в сървъри, базирани на AlmaLinux, Rocky Linux и RHEL. Работи с концепцията за зони. Публичната зона е за интерфейси, отворени за интернет, доверената зона е за надеждни частни мрежи, а зоната drop служи за тихо отхвърляне на нежелан трафик. Най-важното е разликата между runtime и permanent правила. Runtime правилото се прилага веднага, но може да се загуби при рестартиране; permanent правилото е постоянно, но може да се наложи презареждане.

При използване на firewalld в корпоративни среди, определенията на базата на услуги улесняват работата. Например, можете да отворите услугите http и https в публичната зона и да осигурите достъп до SSH услугата само от определени IP адреси. Ако управленската мрежа, мрежата за резервни копия и потребителският трафик са на отделни интерфейси, структурата на зоните повишава сигурността и четимостта.

CDN, WAF и защита от DDoS на ниво доставчик

Локалната защитна стена взема решения след като пакетите достигнат до сървъра. При големи DDoS атаки целта е да се филтрира трафика преди да достигне до сървъра. CDN, WAF и DDoS защита на ниво доставчик следователно са критични. CDN предоставя статично съдържание в ръбовите локализации, WAF филтрира злонамерени заявки на ниво приложение, а защитата на доставчика абсорбира или почиства обемни атаки на мрежово ниво.

В идеалния модел DNS записите ви преминават през CDN, истинският IP адрес на сървъра е скрит, а защитната стена на сървъра приема само трафик от IP диапазоните на CDN за портове 80 и 443. Управленските портове обаче трябва да бъдат достъпни само през VPN или статичен IP. Тази структура намалява вероятността от атака директно на IP адреса и позволява да елиминирате трафика от ботове преди да достигне до приложението. За съдържание, което разглежда въпросите на уеб сигурността и производителността, може да се използва линк към Ръководства за ускоряване и сигурност на уебсайт.

Мерки на ниво приложение срещу ботове

Блокирането на ботове не се състои само от списъци с IP адреси. Съвременните ботове могат да използват прокси, мобилни мрежи, IP адреси от центрове за данни и променливи потребителски агенти. Затова е необходим поведенчески подход. Опити за вход от един и същи IP адрес за кратко време, постоянно генериране на 404 грешки, натрупване на wp-login.php или xmlrpc.php, различен модел на кликвания от нормален потребител и подозрителни заглавия трябва да бъдат анализирани.

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

Управлението на ботове трябва да запази потребителския опит. Прекаленото използване на CAPTCHA, агресивното блокиране или неправилните блокировки по държави могат да навредят на вашите реални клиенти. Затова измерването, тестването и стъпковото затягане са най-добрият подход.

Наблюдение на логовете и правила за аларми

Често е грешка да се мисли, че настройката е завършена. Защитната стена е живо устройство и трябва да бъде наблюдавана редовно. Трябва да се следят опити за SSH в auth.log или secure файла, необичайна плътност на исканията в nginx access логовете, нарастване на 404 и 500 грешките в error логовете, следене на системните метрики като CPU и брой връзки. Дори проста аларма може да спести минути, когато започне атака.

Примерни прагови стойности за начало могат да бъдат: над 100 404 искания от един и същи IP адрес в рамките на 5 минути, над 20 опита на страницата за вход в рамките на 1 минута, CPU използване над 90% в продължение на 10 минути, брой връзки, който е 3 пъти над нормалното. Тези прагове могат да се различават в зависимост от сайта; важно е да знаете нормалния трафик профил.

Чести грешки и начини за избягване

• Активиране на защитната стена без разрешение за SSH: Може да доведе до загуба на достъп до отдалечен сървър. Винаги тествайте с втори сесия.
• Забравяне на IPv6: Докато IPv4 е затворен, IPv6 услугите могат да останат отворени.
• Оставяне на базата данни отворена за интернет: Портовете 3306, 5432, 6379 и 9200 постоянно се сканират от ботове.
• Използване на CDN, но оставяне на истинския IP отворен: Нападателят може да атакува сървъра директно, като заобиколи CDN.
• Промяна на правилата без документация: В спешни случаи ще бъде трудно да разберете какво прави всяко правило.
• Не създаване на резервен план за достъп: Ако няма конзолен достъп в случай на неправилно правило, прекъсването се удължава.

Пример за практическа политика на защитната стена

Обобщената политика, прилагана за малък корпоративен уебсайт, може да изглежда така: входящият трафик е затворен по подразбиране; 443 е отворен за всички посетители; 80 е отворен само за пренасочване към HTTPS; SSH е достъпен само от IP адрес на администратор, базата данни е на localhost или частна мрежа; ако се използва CDN, 80 и 443 разрешават само IP диапазони на CDN; Fail2ban следи опитите за SSH и уеб вход; дневните логове се изпращат към централен мониторингов инструмент.

За среден електронен търговски сайт, в допълнение, IP адресите за обратни извиквания на плащанията се добавят в allowlist, административният панел се поставя зад VPN, при API се прилага лимит на базата на потребител, активират се правила за SQL инжектиране и XSS на WAF, и се планира временно филтриране на базата на държава или ASN. Важно е този план да бъде написан; вместо да се вземат решения в момент на атака, прилагането на предварително определена процедура намалява времето на прекъсване.

Тестове: Действат ли правилата наистина?

След настройката на защитната стена, тестовете са задължителни. Направете сканиране на отворените портове от различна мрежа, уверете се, че SSH достъпът работи само от разрешените IP адреси, проверете дали сайтът е достъпен през HTTPS и се уверете, че портът за базата данни е затворен за външния свят. Ако използвате CDN, проверете дали директната HTTP заявка до истинския IP адрес на сървъра е блокирана.

По време на тестовия процес избягвайте агресивни сканирания, които могат да повредят производствените системи. Целта е да се направи безопасна проверка. Освен това, след всяка промяна експортирайте набора от правила или го запишете. Така ще бъде по-лесно да се върнете към предишната здрава конфигурация, ако възникне проблем.

План за поддръжка и актуализация

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

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

Заключение

Настройката на защитната стена на сървъра не прави сървъра напълно невидим за DDoS и ботове; но значително намалява повърхността на атаката, намалява риска от неразрешен достъп и ви позволява да реагирате на инциденти по-контролирано. Най-добрите резултати се постигат чрез съвместно прилагане на защита от DDoS на ниво доставчик, CDN/WAF, строги портови политики, ограничения на SSH, Fail2ban, ограничаване на скоростта и редовно наблюдение на логовете.

Ако стартирате нов проект, планирането на политиката за защитна стена от самото начало е много по-лесно, отколкото да я коригирате по-късно. Когато оценявате вашата инфраструктура за сървъри, хостинг, домейни и SSL в Hostragons, обмислете и вашите нужди от сигурност, за да създадете по-устойчива уеб среда. Ако е необходимо, започнете с малък контролен списък: затворете отворените портове, ограничете SSH, направете HTTPS задължителен и наблюдавайте логовете.

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

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

Не. Локалната защитна стена може да намали малки и някои атакуващи на ниво протокол, но за големи 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, да тествате с втори сесия и да имате готов конзолен достъп от доставчика.