Аудит безопасности сети: проверка правил файрвола и сетевых сервисов

Введение: зачем нужен аудит сетевой безопасности

Неправильно настроенный файрвол или лишний открытый порт создают прямой вектор атаки на сервер. По данным практики администрирования, большинство успешных взломов начинается с банальной ошибки конфигурации: правило, разрешающее доступ с любого IP, забытый тестовый порт, отсутствие ограничений для IPv6. Аудит безопасности сети решает конкретную задачу: вы находите слабые места до того, как их найдет злоумышленник.

Эта статья дает пошаговую методику проверки правил iptables и nftables, сканирования открытых портов и оценки рисков сетевых сервисов. Вы получите готовые команды, критерии анализа и практические рекомендации по исправлению ошибок. Материал ориентирован на администраторов и DevOps-инженеров, которым нужен быстрый и проверяемый результат.

Процесс аудита включает пять этапов: инвентаризация сервисов, резервное копирование правил, анализ конфигурации файрвола, выявление открытых портов и устранение найденных проблем. Каждый этап описан ниже с примерами для актуальных версий Linux.

Подготовка к аудиту: что нужно знать перед началом

Перед изменением любых правил соберите информацию о системе. Зафиксируйте версию ОС, список запущенных сервисов и схему сети. Это поможет отличить легитимный сервис от подозрительного процесса и избежать блокировки нужного трафика.

Инвентаризация сетевых сервисов

Начните со списка запущенных служб. Команда systemctl показывает все активные юниты:

systemctl list-units --type=service --state=running

Для просмотра слушающих портов используйте ss или netstat. ss работает быстрее и показывает больше деталей:

ss -tulpn

Вывод содержит протокол, локальный адрес, порт и процесс. Например, строка tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3)) означает, что SSH слушает порт 22 на всех интерфейсах. Если вы видите 127.0.0.1:3306, MySQL доступен только локально, что безопасно. А вот 0.0.0.0:3306 уже требует проверки.

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

Резервное копирование текущих правил файрвола

Любое изменение файрвола может отрезать доступ к серверу. Создайте резервную копию до начала работ.

Для iptables:

iptables-save > /root/iptables-backup-$(date +%F).rules

Для nftables:

nft list ruleset > /root/nftables-backup-$(date +%F).nft

Проверьте, что файлы созданы и содержат правила. Восстановление выполняется командами iptables-restore < /root/iptables-backup-2026-08-13.rules или nft -f /root/nftables-backup-2026-08-13.nft. Храните копии вне сервера, например, в защищенном хранилище.

Проверка правил файрвола: iptables и nftables

Анализ правил показывает, какой трафик разрешен, какой блокируется и какие политики применяются по умолчанию. Ошибки здесь открывают доступ к сервисам, которые должны быть закрыты.

Анализ правил iptables

Базовые команды для просмотра правил:

iptables -L -v -n
iptables -S

Первая показывает таблицы с счетчиками пакетов и байтов, вторая выводит правила в формате, пригодном для повторного применения. Разберем вывод iptables -L -v -n:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  412 34567 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

Политика DROP для цепочки INPUT означает, что весь входящий трафик по умолчанию блокируется. Первое правило разрешает SSH с любого адреса, второе - HTTP, но счетчик пакетов равен нулю, то есть правило не используется. Неиспользуемые правила следует удалить: они создают ложное ощущение настройки и увеличивают поверхность атаки.

Обращайте внимание на порядок правил. iptables обрабатывает их сверху вниз до первого совпадения. Если разрешающее правило стоит выше запрещающего, запрет не сработает.

Анализ правил nftables

nftables использует другую структуру: таблицы, цепочки и правила. Просмотр полного набора:

nft list ruleset

Для конкретной таблицы:

nft list table inet filter

Пример вывода:

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        tcp dport 22 accept
        tcp dport 80 accept
    }
}

Структура понятнее, чем у iptables: цепочка input с политикой drop и двумя правилами accept. Приоритеты и хуки определяют, когда цепочка обрабатывает пакет. Проверяйте, что политика по умолчанию - drop, а разрешающие правила ограничены конкретными портами и адресами.

Типичные ошибки конфигурации файрвола

Разрешение всех портов с любого IP. Правило ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 в цепочке INPUT отключает файрвол. Проверяйте, что таких правил нет.
Отсутствие ограничений на исходящий трафик. Если сервер скомпрометирован, он может свободно отправлять данные наружу. Настройте правила для OUTPUT.
Игнорирование IPv6. Многие администраторы настраивают только IPv4, оставляя IPv6 открытым. Проверьте ip6tables -L -v -n или nft list ruleset для семейства inet6.
Неправильная обработка RELATED,ESTABLISHED. Без правила ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED сервер не сможет отвечать на исходящие соединения. Но это правило должно стоять первым, чтобы не пропускать новые входящие пакеты.

Выявление открытых портов и оценка рисков

Сканирование портов показывает, что видит внешний наблюдатель. Сопоставьте результаты с инвентаризацией сервисов и закройте все лишнее.

Сканирование портов с помощью nmap

Базовое сканирование локальной машины:

nmap -sT localhost

Полное сканирование всех TCP-портов удаленного хоста:

nmap -sS -p- 192.168.1.10

Определение версий сервисов:

nmap -sV 192.168.1.10

Ключ -sT использует полное TCP-соединение, -sS - SYN-сканирование, которое быстрее и менее заметно. -p- проверяет все 65535 портов, без него nmap сканирует только 1000 наиболее популярных. -sV пытается определить версию сервиса, что нужно для поиска известных уязвимостей.

Анализ открытых портов и сервисов

Результат nmap показывает состояние порта: open, closed или filtered. Open означает, что сервис доступен. Closed - порт закрыт, но хост отвечает. Filtered - трафик блокируется файрволом, что затрудняет определение состояния.

Сопоставьте открытые порты с процессами:

lsof -i :22
ss -tulpn | grep :22

Для каждого открытого порта задайте вопрос: нужен ли он, кто должен иметь к нему доступ, какая версия сервиса работает. Порт 22 для SSH - норма, если доступ ограничен доверенными IP. Порт 23 для telnet - критическая проблема, так как трафик передается без шифрования. Порт 3306 для MySQL, открытый наружу, - прямой путь к утечке данных.

Оценка рисков: какие сервисы наиболее уязвимы

Критерии оценки: известные уязвимости версии, слабая аутентификация, отсутствие шифрования, доступность из внешней сети. Наибольший риск создают:

Старые версии SSH. Версии до OpenSSH 7.6 содержат известные уязвимости. Проверьте ssh -V и обновите пакет.
Открытые базы данных. MongoDB, Redis, Elasticsearch без аутентификации регулярно становятся источником утечек. Никогда не открывайте их наружу.
Незащищенные веб-интерфейсы. Панели управления без HTTPS и ограничения по IP перехватываются за минуты.
Службы удаленного доступа. VNC, RDP без VPN - частая цель брутфорса.

Если вы используете облачную инфраструктуру, проверьте также состояние гостевых агентов. Например, для виртуальных машин на Timeweb Cloud без QEMU Guest Agent недоступны бэкапы и сброс пароля root, что усложняет восстановление после инцидента. Установка выполняется командой sudo apt install qemu-guest-agent -y с последующим запуском через systemctl.

Исправление найденных проблем: практические рекомендации

После анализа правил и портов переходите к исправлениям. Вносите изменения по одному и сразу проверяйте доступность сервисов.

Закрытие ненужных портов

Для iptables добавьте запрещающее правило:

iptables -A INPUT -p tcp --dport 3306 -j DROP

Для nftables:

nft add rule inet filter input tcp dport 3306 drop

Правило должно стоять после разрешающих правил для доверенных адресов, если такие есть. Проверьте результат повторным сканированием nmap.

Ограничение доступа по IP-адресам

Разрешайте доступ к чувствительным сервисам только с доверенных подсетей. Пример для SSH с офисной сети 203.0.113.0/24:

iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Для nftables:

nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 22 accept
nft add rule inet filter input tcp dport 22 drop

Если администраторы работают с разных адресов, используйте VPN. Настройка VPN-доступа снижает риск брутфорса SSH на порядок.

Обновление и настройка сервисов

Обновите все пакеты до актуальных версий:

apt update && apt upgrade -y

Для сервисов с известными уязвимостями проверьте changelog и примените патчи. Измените стандартные порты, если это оправдано: например, перенос SSH с 22 на нестандартный порт снижает количество автоматических атак, но не заменяет ограничение по IP. Настройте строгую аутентификацию: отключите вход по паролю для SSH, используйте ключи.

Подготовка к внедрению новых сервисов: чек-лист безопасности

Каждый новый сервис расширяет поверхность атаки. Следуйте чек-листу, чтобы минимизировать риски.

Определение требований к сети

Изучите документацию сервиса. Определите порты, протоколы и зависимости. Например, веб-приложение на Nginx требует порт 80 или 443, а база данных PostgreSQL - порт 5432, но только для внутреннего взаимодействия. Зафиксируйте, кто должен иметь доступ: все пользователи, конкретные подсети или только локальные процессы.

Настройка файрвола перед запуском

Создайте правила до запуска сервиса. Для веб-сервера, доступного всем:

nft add rule inet filter input tcp dport 443 accept

Для внутренней базы данных, доступной только с сервера приложений 10.0.0.5:

nft add rule inet filter input ip saddr 10.0.0.5 tcp dport 5432 accept
nft add rule inet filter input tcp dport 5432 drop

Запускайте сервис только после применения правил. Проверьте, что порт не открыт для всех.

Тестирование безопасности нового сервиса

После запуска выполните сканирование:

nmap -sV -p 443 ваш-сервер

Проверьте конфигурацию на типовые ошибки: слабые пароли, дефолтные учетные записи, отсутствие шифрования. Для веб-приложений используйте nikto или аналогичные сканеры. Убедитесь, что сервис не открывает дополнительные порты, о которых вы не знали.

Автоматизация аудита: инструменты и скрипты

Регулярный аудит вручную отнимает время. Автоматизация снижает вероятность пропуска критических изменений.

Использование Lynis для аудита безопасности

Lynis - инструмент с открытым исходным кодом для аудита Linux-систем. Установка:

apt install lynis

Запуск проверки:

lynis audit system

Отчет сохраняется в /var/log/lynis.log. Lynis проверяет конфигурацию файрвола, открытые порты, обновления пакетов и сотни других параметров. Результаты включают warnings и suggestions с конкретными рекомендациями. Запускайте проверку еженедельно через cron.

Создание собственного скрипта проверки

Базовый скрипт для быстрой проверки портов и правил:

#!/bin/bash
echo "=== Открытые порты ==="
ss -tulpn
echo "=== Правила iptables ==="
iptables -L -v -n
echo "=== Правила nftables ==="
nft list ruleset

Сохраните файл как audit.sh, сделайте исполняемым и добавьте в cron:

chmod +x audit.sh
0 3 * * 0 /root/audit.sh > /var/log/audit-$(date +\%F).log

Скрипт запускается каждое воскресенье в 3:00 и сохраняет вывод в лог. Для более глубокой автоматизации используйте готовые решения: OpenVAS для сканирования уязвимостей, Trivy для контейнеров, Wazuh для мониторинга. Подробнее об автоматизации читайте в руководстве по инструментам и скриптам для регулярных проверок.

Заключение: регулярный аудит как часть культуры безопасности

Аудит сетевой безопасности - не разовая акция, а регулярная процедура. Проверяйте правила файрвола и открытые порты минимум раз в месяц, а после любых изменений инфраструктуры - немедленно. Автоматизируйте рутинные проверки и храните резервные копии конфигураций.

Ключевые шаги: инвентаризация сервисов, резервное копирование правил, анализ iptables и nftables, сканирование портов nmap, закрытие лишнего и ограничение доступа. Внедрение новых сервисов выполняйте по чек-листу: сначала файрвол, потом запуск, затем тестирование.

Для углубленного изучения темы используйте материалы базы знаний: практический hardening Linux-сервера с готовыми конфигами, аудит сетевого периметра с Nmap и комплексный план аудита для DevOps. Регулярная проверка - это страховка от инцидентов, которые обходятся дороже, чем час на анализ правил.