Ранее в статье на тему «Эффективная политика брандмауэра: базовая защита» мы заложили фундамент: разобрались, как анализировать инфраструктуру, выбрать политику по умолчанию, реализовать безопасное поведение при сбоях и выстроить базовую модель «запрещено всё, что не разрешено явно». Такая конфигурация уже даёт надёжную защиту от большинства типичных угроз. Но если ваша инфраструктура растёт, увеличивается нагрузка, появляются новые сервисы и требования — одного базового набора правил становится недостаточно, особенно в случае с VPS, где часто приходится балансировать между безопасностью и гибкостью.
Чтобы сохранить устойчивость и управляемость, брандмауэр должен не только блокировать трафик, но и адаптироваться к поведению клиентов, логировать действия в реальном времени, а при необходимости — реагировать автоматически.
Рассмотрим расширенные приёмы фильтрации и автоматизации, которые помогут:
- выявлять подозрительные подключения ещё до того, как они станут угрозой;
- отсекать аномальный трафик по нестандартным признакам (TTL, длина пакета, TCP-флаги);
- ограничивать нагрузку с помощью контроля частоты и количества соединений;
- подключать динамическую защиту через Fail2ban и другие инструменты;
- структурировать правила так, чтобы ими было удобно управлять даже в масштабируемой системе.
Это следующий шаг: от строгой, но статичной защиты — к умному, адаптивному и наблюдающему брандмауэру.
Политика обработки ICMP (типизация, риски, гибкая настройка)
Протокол ICMP (Internet Control Message Protocol) используется не для передачи данных, а для обмена служебной информацией между хостами. Он сообщает о недоступности узлов, ошибках маршрутизации, превышении времени в пути и других событиях в сети. Наиболее известный пример — команда ping, основанная на ICMP Echo Request (тип 8).
Однако помимо диагностики, ICMP может быть использован и злоумышленниками — для разведки, обхода фильтров, перенаправления трафика или перегрузки системы. Поэтому важно грамотно подойти к его фильтрации, не отключая полезные функции, но и не оставляя уязвимостей.
Типы ICMP, которые рекомендуется всегда блокировать
Эти сообщения считаются устаревшими, неиспользуемыми или потенциально опасными:
- Тип 4, код 0 — Source Quench (подавление источника): давно не используется, может применяться в атаках на производительность.
- Тип 6 — Alternate Host Address: исторически не применялся.
- Типы 1, 2, 7, 15 и выше — зарезервированы, устарели или экспериментальны.
Такие типы не несут диагностической ценности и могут быть безопасно заблокированы без ущерба для работы сети.
Типы, которые стоит блокировать в зависимости от среды
Некоторые ICMP-сообщения уместны только в локальных, доверенных сетях. В публичной инфраструктуре они чаще создают риски:
- Тип 5 — Redirect: позволяет маршрутизатору подсказать клиенту другой маршрут.
Полезно при отладке, но может использоваться для атак с подменой маршрутов.
- Тип 9 — Router Advertisement.
- Тип 10 — Router Solicitation.
Эти два типа связаны с автоконфигурацией маршрутов через IRDP (протокол обнаружения интернет-маршрутизаторов). Их имеет смысл разрешать только в частных сетях с контролируемой маршрутизацией. В остальных случаях они могут быть использованы для дезориентации клиентов.
Типы ICMP, которые обычно безопасно разрешить
Некоторые ICMP-сообщения являются важными и полезными для диагностики и нормальной сетевой работы. Их разумно разрешать, особенно если вы управляете инфраструктурой удалённо:
- Тип 8 — Echo Request: используется в ping-запросах.
- Тип 0 — Echo Reply: ответ на ping.
- Тип 3 — Destination Unreachable: позволяет понимать, почему не доставлен пакет.
- Тип 11 — Time Exceeded: сигнал о превышении TTL, используется в traceroute.
- Тип 12 — Parameter Problem: сообщает об ошибке в заголовке IP-пакета.
- Тип 13 и 14 — Timestamp Request и Reply: позволяют измерять задержки (встречаются редко, могут использоваться для анализа сети).
Общий подход
Ранее рекомендовалось полностью блокировать ICMP для повышения безопасности. Однако современная практика — применять гибкую политику: разрешать только необходимые типы, ограничивать источники, отслеживать частоту запросов. Это позволяет сохранить функции диагностики и снизить риски.
Полезно:
- фильтровать ICMP по типам и кодам, а не отключать весь протокол;
- ограничивать количество ICMP-пакетов в секунду (например, через iptables + limit);
- регистрировать подозрительные или неожиданные сообщения.
Таким образом, ICMP не стоит рассматривать как зло по умолчанию — при правильной настройке он остаётся важным инструментом администратора, не снижая уровень защиты.
Фильтрация по нестандартным параметрам (TTL, длина, TCP-флаги, фрагментация)
Помимо типовых фильтров по IP-адресу, порту и протоколу, iptables и nftables позволяют применять более тонкую и продвинутую фильтрацию — по параметрам, которые обычно не используются в базовой конфигурации. Эти методы могут быть полезны для защиты от специфических атак, анализа аномального поведения и дополнительной маскировки инфраструктуры.
Фильтрация по TTL (времени жизни пакета)
Параметр TTL в IP-заголовке показывает, сколько хопов (переходов между узлами) может пройти пакет, прежде чем будет отброшен. У разных операционных систем и устройств — свои значения по умолчанию.
Это позволяет:
- определить приблизительное расстояние до источника;
- выявить подмену IP (TTL может отличаться от ожидаемого);
- отфильтровать трафик, нехарактерный для легитимных клиентов.
Пример применения:
iptables -A INPUT -m ttl ! --ttl-eq 64 -j DROP
Такое правило отбросит все пакеты, у которых TTL не равен 64 — например, если вы знаете, что все ваши клиенты используют Linux с типичным TTL по умолчанию. Это не панацея, но может снизить шум от сканеров и ботов с других платформ.
Фильтрация по длине пакета
Некоторые типы атак (например, сканирование, fuzzing или попытки DoS) используют пакеты с нестандартной длиной. Также можно применять фильтрацию по длине для защиты от искажённых или минимальных запросов:
iptables -A INPUT -m length --length 0:32 -j DROP
Это правило отбрасывает слишком короткие пакеты (до 32 байт), которые редко встречаются в легитимном трафике, но часто используются при техническом сканировании.
Сравнение значений в заголовках пакетов
iptables поддерживает модуль u32, который позволяет обращаться к произвольным смещениям в IP-заголовке и сравнивать значения по маске. Это даёт возможность создавать фильтры на уровне отдельных байт — например, для защиты от спуфинга, нестандартных флагов, обхода фильтров.
Пример отбрасывания нестандартных TCP-флагов:
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
Это правило отбрасывает пакеты без TCP-флагов (NULL-сканирование) — одна из техник определения открытых портов без установления соединения.
Рассмотрим другие примеры.
- Отфильтровать XMAS-сканирование:
--tcp-flags ALL FIN,PSH,URG;
- Заблокировать пакеты с флагами SYN и FIN:
--tcp-flags SYN,FIN SYN,FIN
Фильтрация по фрагментации
Некоторые атаки используют фрагментированные IP-пакеты для обхода фильтров или перегрузки сервера. Брандмауэр можно настроить на блокировку или логирование таких случаев:
iptables -A INPUT -f -j LOG --log-prefix "FRAGMENTED: "
iptables -A INPUT -f -j DROP
Флаг -f означает, что обрабатываются фрагментированные IP-пакеты.
Сравнение поведения политик
Протокол | Команда Nmap | Политика порта | Ответ сервера | Интерпретация клиентом (Nmap) |
TCP | nmap -sT или -sS -Pn | ACCEPT | SYN/ACK | Открыт |
TCP | nmap -sT или -sS -Pn | DROP | Нет ответа | Фильтруется |
TCP | nmap -sT или -sS -Pn | REJECT | TCP RST (сброс соединения) | Закрыт |
UDP | nmap -sU -Pn | ACCEPT | Нет ответа | Открыт или фильтруется |
UDP | nmap -sU -Pn | DROP | Нет ответа | Открыт или фильтруется |
UDP | nmap -sU -Pn | REJECT | ICMP: порт недоступен (Port Unreachable) | Закрыт |
Значения в таблице:
- Открыт — порт принимает подключения, служба активно работает.
- Закрыт — порт доступен, но никакая служба на нём не запущена.
- Фильтруется — трафик блокируется брандмауэром или другим средством фильтрации, сервер не отвечает.
- Открыт или фильтруется — точное состояние определить невозможно: UDP не предоставляет обратной связи, и Nmap не может отличить открытый порт от отброшенного пакета.
Ограничение соединений и скорости: защита от перегрузки и сканирования
Ограничение соединений и частоты запросов — это один из важнейших механизмов защиты серверов от брутфорса, сканирования, DoS и паразитной нагрузки. Особенно актуален он для публичных сервисов: SSH, HTTP API, SMTP и т. д.
iptables и nftables позволяют гибко контролировать объём подключений с учётом контекста, IP-адреса, протокола и даже шаблона поведения клиента.
Практика: как контролировать количество соединений
Ограничение количества одновременных соединений с одного IP позволяет эффективно бороться с перегрузкой и автоматизированными скриптами.
Например:
- запретить одному клиенту устанавливать более трёх подключений к SSH;
- ограничить количество одновременных HTTP-соединений из одной подсети.
Можно также:
- ограничивать соединения по портам — с разными лимитами для SSH, HTTP, SMTP и т. д.;
- фильтровать по сетевому префиксу (например, ограничивать подключение не только по конкретному IP, но и по всей подсети /24, охватывающей до 256 адресов);
- исключать доверенные IP-адреса или подсети из ограничений — например, белый список для административных адресов или VPN-подключений.
Модули ограничения соединений можно комбинировать с масками, исключениями, условиями по интерфейсу, а также использовать только для определённых временных промежутков — например, в рабочие часы.
Контроль частоты: защита от всплесков активности
Если ваша цель — не запретить соединения, а контролировать их темп, подойдут модули, отслеживающие частоту срабатывания правил.
Это особенно полезно для:
- ограничения скорости попыток подключения (например, к SSH, SMTP, HTTP login);
- защиты от массовой отправки POST-запросов;
- контроля за частотой ICMP-запросов или ping-спама.
Дополнительные возможности:
- можно задавать окна времени (например, не более 10 подключений за 60 секунд);
- ограничивать по объёму трафика (в байтах), а не по количеству пакетов;
- отслеживать уникальные комбинации (IP + порт назначения);
- автоматически сбрасывать счётчик, если активность снизилась.
Поведенческая фильтрация через списки
Модуль recent позволяет отслеживать поведение конкретных IP-адресов и принимать решение на основе истории. Это основа для простых реализаций динамического файрвола:
- поместить IP в «чёрный список» после 3 неудачных попыток за 30 секунд;
- временно блокировать агрессивный источник на 5 минут;
- отслеживать количество обращений к определённому ресурсу.
Пример сценария
После двух подключений к порту 22 за короткий промежуток времени IP-адрес временно блокируется — это эффективно против скриптов брутфорса и не мешает нормальной работе.
Комбинация с логикой fail2ban
Для ещё большей автоматизации ограничения можно интегрировать iptables с внешними инструментами, такими как Fail2ban. Он анализирует логи (например, sshd или nginx) и добавляет IP-адреса в iptables при обнаружении подозрительной активности. Это позволяет не только ограничивать частоту подключений, но и учитывать контекст: неуспешные попытки авторизации, ошибки доступа, обращения к необычным путям.
Рекомендации по применению:
- Не устанавливайте слишком жёсткие лимиты для публичных сервисов — это может мешать легитимным пользователям. Лучше работать с доверенными диапазонами.
- Для чувствительных сервисов (например, SSH, API) всегда используйте ограничение попыток.
- Обязательно логируйте срабатывания лимитов — это поможет корректировать настройки и выявлять реальные атаки.
- Комбинируйте механизмы — лимиты по количеству, скорости, объёму и истории.
Ограничения не только защищают от злоумышленников, но и позволяют управлять нагрузкой, расставлять приоритеты в трафике, распределять ресурсы и обеспечивать устойчивость инфраструктуры при аномальной активности.
Интеграция с Fail2ban и другими инструментами автоматической блокировки
Даже самая строгая ручная конфигурация брандмауэра не заменит активной защиты в реальном времени. Чтобы повысить устойчивость сервера к атакам и снизить нагрузку на службы, статические правила iptables или nftables можно дополнить системами автоматического реагирования. Одна из самых надёжных и проверенных — Fail2ban.
Что делает Fail2ban
Fail2ban следит за системными логами (например, sshd, nginx, postfix) и ищет повторяющиеся подозрительные события: ошибки входа, переборы паролей, сканирования, обращение к несуществующим URL.
При достижении заданного порога он:
- временно блокирует IP через iptables или nftables;
- может отправить уведомление, запись в журнал или выполнить скрипт;
- снимает блокировку по таймеру, не требуя ручного вмешательства.
Таким образом, Fail2ban превращает ваш брандмауэр в динамическую систему защиты, реагирующую на попытки атаки в момент их возникновения.
Примеры типовых сценариев
- SSH-брутфорс — 5 неудачных попыток входа за 1 минуту → бан на 10 минут.
- Сканирование веб-сайта — многочисленные ответы 404 или обращения к запрещённым путям (/wp-login.php, /admin).
- POP3/SMTP атака на почтовый сервер — серия ошибок авторизации в течение 30 секунд.
- API-спам — слишком частые POST-запросы к эндпоинтам авторизации.
Как подключить Fail2ban к iptables
Fail2ban сам создаёт и управляет цепочками в iptables или nftables. Чтобы это заработало:
- Убедитесь, что в конфигурации Fail2ban:
/etc/fail2ban/jail.conf или /etc/fail2ban/jail.local
задано действие:
iptables-multiport или nftables-multiport
- Установите нужные фильтры (например, sshd, nginx-http-auth, postfix).
- Укажите параметры: количество попыток (maxretry), интервал (findtime), и длительность блокировки (bantime).
Пример блока в jail.local:
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 5
findtime = 60
bantime = 600
action = iptables-multiport[name=SSH, port=ssh, protocol=tcp]
Fail2ban добавит IP-адрес в собственную цепочку iptables, не нарушая основную политику фильтрации.
Расширение: интеграция с внешними системами
- CrowdSec — современный аналог Fail2ban с распределённой базой агрессивных IP-адресов и поддержкой реактивных сценариев.
- Rsyslog с анализатором логов — можно создавать собственные триггеры для блокировки.
- Собственные скрипты — Fail2ban может вызывать произвольные команды при срабатывании: отправка уведомлений, запись в базу, вызов webhook.
Зачем это нужно:
- Вы не загромождаете брандмауэр сотнями правил вручную — Fail2ban обновляет их по мере необходимости.
- Блокировки временные, и при ошибке пользователю не нужно обращаться к администратору — разблокировка произойдёт автоматически.
- Вы получаете активную систему наблюдения за поведением, дополняющую статическую фильтрацию.
- Уровень шума от сканеров, ботов и автоматических атак резко снижается — даже если они не нарушают брандмауэр напрямую.
Fail2ban — не замена iptables, а его дополнение. Он не фильтрует трафик сам, но даёт вашему брандмауэру возможность динамически адаптироваться к текущей угрозе. Это особенно важно, если сервер доступен из Интернета и принимает подключения от непредсказуемых клиентов.
Структура правил: одна цепочка или модульная архитектура
При построении правил фильтрации трафика важно не только что фильтровать, но и как структурировать конфигурацию. Это влияет на читаемость, масштабируемость и удобство поддержки брандмауэра. Особенно в средах, где появляются новые сервисы, меняются правила доступа или нужно поддерживать безопасность на постоянной основе.
Когда достаточно стандартных цепочек
Для минималистичных сценариев — например, если сервер обслуживает только один сервис и управляется вручную — вполне достаточно работать в рамках встроенных цепочек INPUT, OUTPUT и FORWARD. Все правила записываются в одну последовательность, которая обрабатывается сверху вниз. Однако с ростом числа сервисов или требований к безопасности такая схема быстро теряет управляемость.
Преимущества пользовательских цепочек
Создание дополнительных цепочек позволяет:
- группировать правила по сервисам или назначению — например, отдельные цепочки для SSH, HTTP, почты, внутреннего API;
- сократить дублирование условий — например, фильтрация по IP или интерфейсу может быть вынесена на уровень выше;
- улучшить читаемость — вместо огромного списка правил вы получаете логически разделённую структуру;
- проще включать/отключать подсистемы — например, временно отключить цепочку SSH при миграции.
Цепочки вызываются из основной с помощью правила -j имя_цепочки. Если пакет не обработан в пользовательской цепочке, он возвращается обратно и продолжает проходить по следующему правилу основной цепочки.
Структура для сервера с несколькими сервисами
Пример:
INPUT (цепочка по умолчанию)
↳ Проверка доверенного IP (общая фильтрация)
↳ Логирование подозрительных пакетов
↳ -j ICMP_CONTROL
↳ -j SSH_ACCESS
↳ -j WEB_ACCESS
↳ -j DEFAULT_DROP
В этом примере:
- ICMP_CONTROL разрешает echo request и reply, блокирует ненужные типы,
- SSH_ACCESS разрешает доступ на порт 22 только с определённых IP,
- WEB_ACCESS разрешает 80/443 с любого адреса,
- DEFAULT_DROP логирует и отбрасывает всё остальное.
Такая структура легко расширяется: например, можно добавить цепочку MAIL_ACCESS или ADMIN_PANEL, не трогая остальную логику.
Практические советы:
- Именуйте цепочки понятно и логично, избегайте сокращений вроде R1 и F2.
- Используйте единый стиль написания правил: сначала разрешения, затем запреты и логирование.
- Сначала вызывайте более специфичные цепочки, чтобы обработка происходила максимально быстро.
- Логируйте только в одном месте, не дублируйте сообщения в каждой цепочке — это создаёт лишний шум.
Такой подход облегчает командную работу, обновление конфигурации и аудит безопасности. Особенно важен он в ситуациях, где на одном сервере работают разные критичные сервисы с разными уровнями доступа.
Главное в статье
В этой статье мы разобрали продвинутые методы фильтрации и активной защиты, которые усиливают базовую политику брандмауэра:
- как использовать нестандартные параметры (TTL, длина пакета, TCP-флаги, фрагментация) для выявления подозрительного трафика;
- как ограничивать соединения и контролировать частоту обращений для защиты от перегрузки и автоматических атак;
- как подключить Fail2ban и другие инструменты для динамической блокировки вредоносных IP;
- как структурировать правила, чтобы сделать конфигурацию читаемой, управляемой и масштабируемой.
Такие меры превращают статичный набор правил в гибкую, адаптивную систему безопасности.
Чем лучше вы понимаете, какие пакеты приходят к вашему серверу и почему, тем проще предотвратить атаки до того, как они станут проблемой.
Читайте в блоге:
- Безопасность при аренде VPS сервера
- Как безопасно работать с паролями с помощью BcryptJS в JavaScript
- Как настроить файрвол в Ubuntu с помощью UFW