Настройка межсетевого экрана сервера: защита от DDoS-атак и вредоносных ботов

Настройка межсетевого экрана (фаервола) сервера — это процесс открытия только необходимых портов и блокировки всего лишнего доступа; он служит первым уровнем защиты от DDoS-атак, перебора паролей и вредоносного трафика ботов. Практически задача состоит в ограничении доступа по SSH, контролируемом открытии веб-сервисов, ограничении подозрительных запросов по частоте, мониторинге логов и, при возможности, фильтрации трафика на уровне CDN/WAF до попадания на сервер.

Сразу после подключения веб-сервера к интернету вы столкнётесь с порт-сканированием, попытками SSH-подключений, ботами, ищущими уязвимости, и поддельными User-Agent. Особенно актуальна настройка фаервола для сайтов на WordPress, интернет-магазинов, панелей управления, API или игровых серверов — это не просто технический выбор, а необходимость для стабильной работы. В этом руководстве мы шаг за шагом построим архитектуру фаервола для Linux-серверов: рассмотрим UFW, firewalld, nftables, Fail2ban, веб-фаервол и методы снижения DDoS.

Важно понимать: локальный фаервол не сможет самостоятельно остановить крупномасштабные DDoS-атаки. При атаке в десятки или сотни гигабит в секунду трафик может заполнить канал связи ещё до того, как пакеты достигнут правил ОС. Поэтому правильная стратегия — многоуровневая защита: DDoS-защита на уровне провайдера, CDN/WAF, фаервол ОС, ограничение частоты запросов в приложении и регулярный анализ логов должны работать вместе. Для выбора инфраструктуры рекомендуем ознакомиться с Решения для VPS и VDS серверов Hostragons, а для безопасного хостинга — с Пакеты веб-хостинга Hostragons.

Для чего нужен фаервол сервера?

Фаервол сервера — это слой безопасности, фильтрующий сетевой трафик по исходным и целевым IP, портам, протоколам, состоянию соединения и иногда по другим признакам пакетов. Проще говоря, для вашего сайта должны быть открыты порты 80 и 443, но порт базы данных 3306 не должен быть доступен из интернета. Для SSH (порт 22) гораздо безопаснее разрешить доступ не всем, а только с IP-адреса вашего офиса.

Основная цель фаервола — не уничтожить все атаки волшебным способом, а минимизировать поверхность атаки. Чем меньше возможностей для злоумышленника, тем меньше шансов на успешную атаку. Например, на только что установленном Linux-сервере могут одновременно работать SSH, веб-панель, почтовый сервис, база данных, мониторинг и тестовые сервисы — каждый из них создаёт отдельный риск. Хорошо настроенный фаервол действует по принципу «по умолчанию запретить, разрешить только необходимое».

Понимание DDoS-атак и ботов

Чем отличаются DDoS-атаки?

DDoS (распределённая атака отказа в обслуживании) — это попытка сделать сервис недоступным путём отправки огромного объёма трафика с множества источников. Атака может забивать канал связи, перегружать процессор и память сервера или вызывать тяжёлые операции на уровне приложений. Например, небольшой сервер с 50 000 HTTP-запросов в секунду может перестать отвечать, даже если сеть не перегружена, из-за ограничений PHP-FPM, Node.js или пула соединений с базой данных.

Все ли боты вредоносны?

Нет. Googlebot, Bingbot и другие поисковые боты полезны. Вредоносные боты же сканируют панели управления, ищут открытые каталоги, спамят формы, копируют контент, злоупотребляют XML-RPC, создают фальшивые учётные записи и пытаются войти в систему. Поэтому задача в управлении ботами — не блокировать их всех подряд, а фильтровать по поведению. Высокий процент ошибок, слишком много запросов за короткое время, заголовки, не похожие на реальные браузеры, и подозрительные URL — важные признаки.

Контрольный список перед настройкой

При написании правил фаервола на живом сервере главная опасность — случайно заблокировать себя. Поэтому перед изменениями делайте подготовку. Ниже — проверенный список для безопасного старта в продакшене.

• Не закрывайте активный SSH-сеанс, тестируйте через второе подключение.
• Убедитесь, что у вас есть доступ к консоли, VNC или режиму восстановления у провайдера.
• Просмотрите открытые порты с помощью команд ss -tulpn или netstat -tulpn.
• Запишите, какие порты используют веб, почта, DNS, база данных, панели и мониторинг.
• Если используете IPv6, продумайте правила для него отдельно.
• Сначала применяйте разрешающие правила (allow), потом запрещающие (deny).
• Убедитесь, что правила сохраняются после перезагрузки сервера.

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

Какой фаервол выбрать?

В Linux есть несколько инструментов, построенных на одном и том же ядре, но отличающихся удобством и функционалом. Для новичков 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. Установите политику по умолчанию как запрет

В безопасных конфигурациях входящий трафик по умолчанию блокируется, исходящий — разрешается по необходимости. Это предотвращает случайное открытие новых сервисов в интернет. На Ubuntu с UFW логика такова: сначала разрешите SSH, потом 80 и 443, затем измените политику по умолчанию на отказ и активируйте фаервол.

Пример: разрешите SSH для вашего IP, откройте HTTP/HTTPS, закройте лишние порты и только потом включайте фаервол. Открыть фаервол без разрешения SSH — частая ошибка, приводящая к потере доступа.

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

SSH — одна из самых атакуемых служб. Сервер с открытым портом 22 может получать сотни или тысячи попыток взлома в день. Самый надёжный способ — ограничить доступ по IP. Если у вас статический IP офиса или VPN, разрешите только их. Если нет, используйте ключи SSH и отключите пароль.

• Запретите вход под root через SSH.
• Используйте SSH-ключи вместо пароля.
• Ограничьте пользователей через AllowUsers или AllowGroups.
• Настройте Fail2ban для автоматической блокировки неудачных попыток.
• Если есть панель управления, ограничьте её порт по IP.

Смена порта SSH не даёт полной защиты, но снижает уровень шумовых атак. Реальная безопасность — в ограничении IP, сильной аутентификации и мониторинге логов.

4. Контролируемое открытие веб-портов

Для большинства сайтов нужны порты 80 и 443. Но сейчас HTTPS (443) должен быть основным, а 80 — только для перенаправления на HTTPS. Отсутствие SSL-сертификата снижает доверие пользователей и ухудшает SEO. В этом месте удобно вставить ссылку на SSL сертификаты Hostragons для правильной настройки HTTPS.

Если используете 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. Блокируйте переборы паролей с Fail2ban

Fail2ban анализирует логи и временно блокирует IP, с которых идут повторяющиеся неудачные попытки входа. Для SSH, nginx, Apache, Postfix, Dovecot, WordPress и панелей управления можно настроить «тюрьмы». Например, если за 10 минут с IP было 5 неудачных попыток SSH, IP блокируется на час — простой и эффективный способ защиты.

Будьте аккуратны с чрезмерно жёсткими правилами — можно заблокировать легитимных пользователей из-за ложных срабатываний. Сначала ставьте разумные таймауты, следите за логами и постепенно ужесточайте защиту.

7. Внедрите ограничение частоты запросов и лимиты соединений

Ограничение частоты (rate limiting) на уровне ОС помогает бороться с 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. Если IP статического нет, временно разрешите SSH всем, а потом переходите на VPN или фиксированный IP.

Пример настроек для IP 203.0.113.10: SSH только с этого адреса, веб-доступ для всех на 80 и 443, база данных, Redis, панель и тестовые порты закрыты. Такая конфигурация подходит для многих малых и средних сайтов. Для правильного доменного и DNS-направления рекомендуем Проверка домена и регистрация Hostragons.

Особенности firewalld и зональность

На AlmaLinux, Rocky Linux и RHEL часто используют firewalld. Он базируется на концепции зон: public — для интернет-интерфейсов, trusted — для доверенных сетей, drop — для тихого отброса нежелательного трафика. Важно понимать разницу между runtime (правила применяются сразу, но не сохраняются) и permanent (правила сохраняются, но требуют перезагрузки или reload).

В корпоративных сетях firewalld облегчает работу через сервисы. Например, http и https можно включить в public, ssh — только с определённых IP. Если управление, бэкап и пользовательский трафик идут через разные интерфейсы, зоны повышают безопасность и удобство администрирования.

Защита на уровне CDN, WAF и провайдера

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

Идеальная схема: DNS указывает на CDN, реальный IP сервера скрыт, фаервол пропускает трафик только с IP CDN на порты 80 и 443, административные порты доступны только через VPN или фиксированные IP. Такой подход снижает риск прямых атак, а ботов можно блокировать на WAF. Подробнее о безопасности и ускорении сайта смотрите в Руководства по ускорению веб-сайта и безопасности.

Меры против ботов на уровне приложений

Блокировка ботов — это не просто занесение IP в чёрный список. Современные боты используют прокси, мобильные сети, дата-центровые IP и меняют User-Agent. Поэтому нужен поведенческий анализ. Например, большое число попыток входа с одного IP, постоянные 404, интенсивное обращение к wp-login.php или xmlrpc.php, непривычные паттерны кликов и подозрительные заголовки требуют отдельного внимания.

• Используйте ограничение частоты на формах входа и регистрации.
• Ограничьте или отключите XML-RPC, если он не нужен.
• Защитите панель управления нестандартным URL, IP-фильтрами и двухфакторной аутентификацией.
• Фильтруйте подозрительные User-Agent и Referer на уровне WAF.
• Внедряйте CAPTCHA или невидимые проверки ботов в формах.
• Для API добавляйте ключи, подписи, квоты и контроль времени запросов.

Важно не ухудшать удобство для легитимных пользователей. Чрезмерное использование CAPTCHA, чрезмерные блокировки и ошибочные фильтры по странам могут навредить клиентам. Поэтому применяйте измерения, тесты и постепенное ужесточение.

Мониторинг логов и правила оповещения

Не думайте, что раз настроили — значит забыли. Фаервол — живой механизм, его надо регулярно мониторить. Следите за попытками входа в auth.log или secure, за аномалиями в access.log nginx, ростом ошибок 404 и 500, загрузкой CPU и количеством соединений. Даже простое оповещение при подозрительной активности может выиграть несколько минут при атаке.

Например, пороговые значения для старта: более 100 404 с одного IP за 5 минут, более 20 попыток входа за минуту, CPU выше 90% на протяжении 10 минут, количество соединений в 3 раза выше обычного. Значения зависят от сайта, главное — знать нормальный профиль трафика.

Типичные ошибки и как их избежать

• Включить фаервол без разрешения SSH: потеря доступа к серверу. Всегда тестируйте с двух сессий.
• Игнорировать IPv6: при закрытом IPv4 сервисы могут оставаться доступными по IPv6.
• Оставлять базы данных открытыми: порты 3306, 5432, 6379, 9200 — частая цель ботов.
• Использовать CDN, но не скрывать реальный IP: злоумышленники могут атаковать напрямую сервер.
• Менять правила без документации: сложно понять, что и зачем сделано при срочных исправлениях.
• Отсутствие плана резервного доступа: при ошибках без консоли доступ невозможен, простой простой затягивается.

Пример практической политики фаервола

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

Для интернет-магазина среднего масштаба дополнительно разрешают IP callback платежных систем, панель управления закрывают за VPN, для API вводят пользовательские квоты, на WAF включают правила против SQL-инъекций и XSS, готовят временные фильтры по странам и ASN. Важно иметь письменный план — в момент атаки быстрее и спокойнее применять заранее отработанные действия.

Проверка: работают ли правила?

После настройки обязательно тестируйте. Выполните сканирование портов с другого сегмента сети, убедитесь, что SSH доступен только с разрешённых IP, проверьте доступность сайта по HTTPS, убедитесь, что порты баз данных закрыты.