Как проверить работу файрвола: диагностика правил и тестирование портов в Linux и Windows

Проверить работу файрвола можно за четыре шага: подтвердить, что служба запущена и правила загружены в ядро, просканировать порт с трёх точек обзора, найти в логах запись о сброшенном пакете и убедиться, что порт слушает само приложение. Если с localhost порт отвечает, а с внешнего хоста приходит таймаут, блокировка стоит на фильтрации, а не в сервисе.

Ниже собраны команды для iptables, nftables, ufw, firewalld и Windows Defender Firewall, разбор состояний open, closed и filtered в nmap, чтение pfirewall.log и журнала Security, а также причины, по которым добавленное правило молчит. Отдельный блок отведён безопасной работе на удалённом сервере, чтобы тестирование не закончилось потерей SSH.

Зачем проверять файрвол и какие риски это несёт

Правила файрвола устаревают быстрее, чем кажется. Сервис переехал с 8080 на 8443, в систему добавили Docker с публикацией портов, подключили VPN или обновили дистрибутив с другим набором правил по умолчанию, и часть клиентов получает таймаут. Ещё один частый сценарий: администратор копирует набор правил с тестового стенда, где политика INPUT стояла в ACCEPT, а на проде политика DROP и разрешающих правил в конце цепочки нет.

Обратная ошибка стоит не меньше: уверенность, что порт закрыт, при пустом наборе правил. Проверка нужна перед аудитом, после любой правки конфигурации и при разборе жалоб «сервис недоступен». Смотреть придётся шире, чем кажется: между клиентом и приложением стоят security groups облака, NAT на маршрутизаторе, host-based файрвол и фильтры самого приложения.

Проверку делают с трёх точек обзора: на самом сервере (localhost), из соседней подсети и из интернета. Результаты почти всегда различаются, и разница показывает, где именно теряется пакет.

Как не потерять доступ к серверу при тестировании

Главный риск работы на удалённой машине один: правило, закрывающее 22 порт, применяется раньше, чем вы успеваете его откатить. Держите резервный путь настройки: KVM или IPMI, консоль облачного провайдера, последовательный порт. Через него правило снимается, даже если SSH перестал отвечать.

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

echo 'iptables -P INPUT ACCEPT; iptables -F' | at now + 10 minutes
atq
atrm 3

Для systemd-дистрибутивов та же логика выполняется через systemd-run --on-active=10min /root/fw-reset.sh. На Debian и Ubuntu есть iptables-apply: утилита применяет файл правил, ждёт подтверждения и откатывает изменения сама, если подтверждения нет. Набор для nftables проверяется до загрузки командой nft -c -f ruleset.nft, ошибка в файле не тронет работающий набор.

Перед экспериментами убедитесь, что в цепочке есть разрешение для служебных соединений: iptables -C INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT. Без него сброс таблицы разорвёт уже открытые сессии. Сессию tmux или screen держите включённой: после случайного разрыва вы вернётесь в тот же контекст, а не в пустую консоль. Базовые правила доступа, sudo и SSH разобраны в руководстве по политике безопасности Linux-сервера.

В Windows отложенное действие оформляют задачей планировщика:

schtasks /create /tn 'fw-off' /tr 'netsh advfirewall set allprofiles state off' /sc once /st 12:30 /ru SYSTEM
schtasks /delete /tn 'fw-off' /f

Работы планируйте на окно низкой нагрузки: сканирование портов и включённое логирование заметны по нагрузке на сеть и диск.

Как убедиться, что файрвол запущен и активен

Начните со службы: если она остановлена, правила в ядре не применяются, и дальнейшая диагностика теряет смысл.

systemctl is-active ufw firewalld nftables
ufw status verbose
firewall-cmd --state
iptables -L -n -v
nft list ruleset

Вывод ufw status verbose показывает главное: строку Status: active и значение Default: deny (incoming). У firewalld команда --state отвечает running. У iptables -L -n -v важны счётчики pkts и bytes у каждого правила: если счётчик растёт во время вашего подключения, правило действительно обрабатывает трафик. Команда iptables -S печатает правила в том виде, в котором их принимает iptables-restore, и по ней удобно проверять порядок.

Типичная ловушка: iptables -L показывает пустой список, хотя защита работает. Уточните бэкенд командой iptables --version: пометка (nf_tables) означает трансляцию в nftables, и правила firewalld или nftables вы найдёте в выводе nft list ruleset. При пометке (legacy) наборы живут раздельно. Проверьте и модули ядра: lsmod | grep -E 'nf_tables|ip_tables'.

Windows Defender Firewall проверяется через PowerShell и netsh:

Get-Service MpsSvc | Select-Object Status, StartType
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
netsh advfirewall show allprofiles
Get-NetConnectionProfile

Get-NetFirewallProfile возвращает три профиля: Domain, Private, Public. Профиль Public со значением DefaultInboundAction Block и Enabled True означает, что входящие соединения режутся по умолчанию. Get-NetConnectionProfile показывает, какой профиль присвоен активному сетевому интерфейсу прямо сейчас: если адаптер попал в Public, правила, созданные для Private, не применяются. Сторонние EDR и антивирусы иногда отключают встроенный файрвол и перехватывают фильтрацию своими драйверами, тогда служба MpsSvc остановлена, а трафик всё равно фильтруется.

Тестирование портов: инструменты и команды

Выбор инструмента зависит от задачи. nmap даёт детальный отчёт и различает фильтрацию, telnet и nc отвечают за секунды по одному порту, Test-NetConnection закрывает ту же задачу в Windows. Сама логика одинакова на Windows и Linux, различаются только команды: сначала localhost, затем соседний хост, затем внешний сервис.

nmap: сканирование портов и интерпретация результатов

Установка: apt install nmap, dnf install nmap или winget install Insecure.Nmap. Базовое сканирование TCP:

nmap -sS -Pn -p 22,80,443 --reason 203.0.113.10
nmap -sT -Pn --top-ports 100 --open 10.0.0.5
nmap -sU -Pn -p 53,123,161 --reason 10.0.0.5

Ключ -sS выполняет SYN-сканирование и требует прав root, без них nmap переходит в режим -sT с полным TCP-соединением. Флаг -Pn отключает проверку доступности хоста и обязателен при политике DROP: без него сканер напишет Host seems down, хотя порты открыты, потому что ICMP-эхо не проходит. Ключ --reason объясняет вердикт.

PORT     STATE     SERVICE   REASON
22/tcp   open      ssh       syn-ack
80/tcp   closed    http      reset
443/tcp  filtered  https     no-response

Состояния читаются так. open: получен SYN-ACK, приложение отвечает. closed: пришёл RST, до порта добрались, слушателя нет. filtered: ответа нет или пришёл ICMP с запретом, пакет отброшен фильтром. Состояние open|filtered у UDP встречается чаще всего: протокол без подтверждений, и отсутствие ответа не доказывает ни открытость, ни блокировку. Причины filtered в выводе --reason выглядят как no-response, host-prohibited или admin-prohibited, и последние две указывают на политику REJECT. Подробная методика сканирования периметра собрана в материале про аудит сетевой инфраструктуры с помощью Nmap.

Сканируйте только свои системы и только с разрешения владельца. Сканер попадает в логи IDS и в бан-листы fail2ban, поэтому IP, с которого идёт проверка, добавьте в белый список заранее. Если внешней точки обзора нет, проще поднять отдельный сервер в другом дата-центре, чем строить догадки: VPS на Timeweb Cloud разворачивается за минуту, а скан из чужой сети сразу показывает реальную картину снаружи.

telnet и nc: простые проверки доступности порта

Быстрая проверка одного порта:

telnet 203.0.113.10 443 nc -zv -w 3 203.0.113.10 443 nc -zvu -w 3 203.0.113.10 53 timeout 3 bash -c '

telnet при успехе печатает Connected to 203.0.113.10 и ждёт ввода, при отказе возвращает Connection refused, при блокировке висит до таймаута. Клиент telnet в Windows по умолчанию не установлен, его включают компонентом Telnet Client. Netcat существует в нескольких реализациях: ncat и OpenBSD nc поддерживают -z (проверка без передачи данных) и -v, у busybox набор ключей урезан, сверяйтесь с nc -h. UDP-проверка через -u условна: успехом считается отсутствие ICMP port unreachable, а не подтверждение от приложения. Последняя строка примера работает в bash без установки пакетов и выручает на минимальных образах.

Практический вывод из этих команд один: RST (Connection refused) и молчание говорят о разном. Мгновенный отказ означает, что порт закрыт на хосте или правило отвечает reject. Тишина до таймаута, около 130 секунд при шести попытках SYN, означает drop: пакет ушёл и не вернулся. Это различие дальше помогает отделить файрвол от сбоя приложения.

В Windows те же проверки выполняются одной строкой:

Test-NetConnection -ComputerName 203.0.113.10 -Port 443 -InformationLevel Detailed
Test-Connection -TargetName 203.0.113.10 -TcpPort 443
netstat -ano | findstr :443

Test-NetConnection возвращает TcpTestSucceeded. Различать filtered и closed он не умеет: в обоих случаях будет False, а поле PingSucceeded отдельно показывает, проходит ли ICMP.

Внешние сервисы сканирования портов

Онлайн-сканеры подключаются к вашему адресу со своей стороны и показывают, что видит интернет: ping.eu, canyouseeme.org, portchecker.co. У check-host.net есть несколько точек по миру, что помогает поймать блокировку по географии или по диапазону провайдера.

Ограничения этих сервисов меняют выводы, и о них нужно знать заранее. Проверить можно только публичный адрес: сервер в приватной сети за NAT требует проброса порта на маршрутизаторе, иначе сканер увидит закрытый порт на роутере. Второй подводный камень - NAT loopback: запрос к своему внешнему IP из той же локальной сети часто не возвращается, и результат выглядит как блокировка, хотя порт открыт. Третий - CDN и обратный прокси: Cloudflare или балансировщик ответит на 443 независимо от состояния порта на бэкенде.

Три инструмента дают три картины: nmap с внешнего хоста показывает состояние фильтра, nc и telnet быстро отвечают по конкретному порту, онлайн-сервисы подтверждают доступность из интернета, а ss на сервере показывает состояние приложения. Расхождения между этими картинами и указывают на место потери трафика.

Чтение логов файрвола в Linux и Windows

Сканирование показывает факт блокировки, логи показывают правило, которое её выполнило. Без записи в журнале остаётся угадывать между хостом, облаком и приложением.

Логи iptables, ufw и firewalld

iptables сам по себе молчит. Пакет, попавший под DROP, не оставляет следа, пока вы не добавите цель LOG выше правила блокировки:

iptables -I INPUT 5 -m limit --limit 10/min --limit-burst 20 -j LOG --log-prefix 'IPT-DROP: ' --log-level 4
iptables -L INPUT -n -v --line-numbers
journalctl -k -f
dmesg -w

Позиция здесь решает всё: LOG должен стоять перед DROP, иначе правило не выполнится. Ограничитель -m limit защищает от потока записей при сканировании или атаке. Ядро отдаёт записи в journald, а на части дистрибутивов дублирует в /var/log/kern.log (Debian) или /var/log/messages (RHEL). Строка выглядит так:

Sep 17 12:04:11 web01 kernel: IPT-DROP: IN=eth0 OUT= SRC=198.51.100.23 DST=203.0.113.10 PROTO=TCP SPT=51234 DPT=3306 SYN URGP=0

Поля SRC, DPT и PROTO показывают, кто и куда стучался. Счётчики пакетов у правил часто заменяют логирование: iptables -L INPUT -n -v показывает, сколько пакетов отброшено, без записи на диск и без потери производительности.

ufw пишет в /var/log/ufw.log, детализация задаётся уровнем low, medium или high в /etc/ufw/ufw.conf либо командой ufw logging medium. Просмотр: tail -f /var/log/ufw.log, строки содержат блок [UFW BLOCK] с теми же полями.

firewalld отправляет отбросы в journald, а логирование включается отдельно:

firewall-cmd --set-log-denied=all
journalctl -u firewalld -f
firewall-cmd --runtime-to-permanent

Значение all покрывает все типы трафика, есть также unicast, broadcast и multicast. Записи об отклонении появляются с префиксом FINAL_REJECT и содержат имя цепочки. Логи большого сервера удобно фильтровать по адресу или порту: journalctl -k | grep 'DPT=3306'. Полный чек-лист по разбору правил и связанных сервисов есть в статье про аудит безопасности сети и проверку правил файрвола.

Логирование расходует ресурсы: при сканировании портов поток записей измеряется тысячами строк в секунду и забивает диск. Держите лимиты, настройте ротацию и выключайте лишнюю детализацию после решения задачи. Когда событий много, разбор ускоряет модель: сгруппируйте записи по SRC, выделите частые значения DPT и передайте сводку в агрегатор API нейросетей AiTunnel, который даёт доступ к GPT, Gemini и Claude по одному ключу.

Логи Windows Defender Firewall

В Windows два источника. Первый - журнал Security с событиями 5152 (отброшенный пакет) и 5157 (заблокированное соединение). По умолчанию подкатегории аудита выключены, их включают явно:

auditpol /set /subcategory:'Filtering Platform Packet Drop' /failure:enable
auditpol /set /subcategory:'Filtering Platform Connection' /failure:enable

Событие 5152 содержит адреса, порты, протокол и Filter Run-Time ID. Идентификатор не совпадает с именем правила, поэтому сопоставление делают через netsh wfp show filters и поиск по этому номеру в XML. Включайте такой аудит на время отладки: запись каждого пакета заметно нагружает систему.

Второй источник проще в работе, это текстовый лог pfirewall.log:

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging maxfilesize 8192
netsh advfirewall set allprofiles logging filename C:\Windows\System32\LogFiles\Firewall\pfirewall.log

По умолчанию файл лежит в C:\Windows\System32\LogFiles\Firewall\pfirewall.log, логирование выключено, а предельный размер равен 4096 КБ. Формат строки повторяет W3C: дата, время, действие (DROP или ALLOW), протокол, адреса и порты источника и назначения, размер, флаги TCP.

2026-09-17 12:04:11 DROP TCP 198.51.100.23 203.0.113.10 51234 3306 60 S 1234567890 0 64240 - - - - - - - RECEIVE

Чтобы понять, какое правило разрешает нужный порт, удобнее смотреть сам набор, а не лог:

Get-NetFirewallRule -Direction Inbound -Enabled True | Get-NetFirewallPortFilter
Get-NetFirewallRule -DisplayName 'Remote Desktop*' | Show-NetFirewallRule

Пара Get-NetFirewallRule и Get-NetFirewallPortFilter связывает правило с портом и протоколом, а Show-NetFirewallRule показывает ещё и адресные фильтры, которые чаще всего и мешают: правило включено, порт разрешён, но область RemoteAddress ограничена одной подсетью.

Как отличить блокировку файрвола от сбоя приложения

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

Проверка прослушивания портов

ss -tlnp
ss -tulnp
ss -tlnp 'sport = :80'
netstat -ano | findstr LISTENING | findstr :443
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

Ключи ss расшифровываются как t (TCP), u (UDP), l (listening), n (числовые адреса), p (процесс). Смотрите на столбец Local Address. Запись 0.0.0.0:80 означает приём на всех IPv4-адресах, [::]:80 на всех IPv6, 127.0.0.1:80 только на loopback. Третий случай объясняет большую часть жалоб: соединение снаружи не проходит, потому что приложение слушает только localhost, и файрвол здесь ни при чём. Лечится настройкой самого сервиса: listen_addresses в postgresql.conf, директива bind в redis.conf, параметр listen в nginx.conf.

Отдельно проверьте контейнеры. Docker публикует порты через DNAT в цепочке PREROUTING и собственные правила в FORWARD, поэтому правило -A INPUT -j DROP опубликованный порт не закроет. Блокировать такой трафик нужно в цепочке DOCKER-USER или на внешнем фильтре. Проверка порта внутри контейнера и на хосте даёт разные ответы, и это не ошибка.

Если процесса нет в выводе ss, проверьте, что он вообще запущен: systemctl status nginx, docker ps, Get-Process. Встречается и обратное: служба работает, но слушает порт, отличный от указанного в документации.

Анализ ответов: RST, таймаут, отказ в соединении

Симптом	Что означает
Мгновенный RST, Connection refused	Слушателя нет, либо правило с действием REJECT
Тишина до таймаута, SYN уходит без ответа	Пакет отброшен: DROP на хосте, в облаке или на маршрутизаторе
ICMP admin prohibited	Правило REJECT с запретом ICMP, часто на BSD и pfSense
HTTP 403 или 404	Пакет дошёл, отвечает приложение или обратный прокси
Малые пакеты проходят, крупные зависают	Проблема MTU, а не файрвол

Проверка через curl показывает тип сбоя в одной строке:

curl -v --connect-timeout 5 http://10.0.0.5:8080/
nc -zv -w 3 10.0.0.5 8080
tcpdump -ni eth0 port 8080

Ответ Connection refused относится к приложению или к reject-правилу. Operation timed out означает отброс пакетов. Если curl получил любой HTTP-код, соединение установлено и файрвол пропустил трафик, а дальше разбираться нужно в приложении: правах, конфигурации виртуального хоста, лимитах.

tcpdump закрывает вопрос окончательно. Запустите его одновременно на клиенте и на сервере. Возможны три картины: SYN уходит и ответа нет; SYN приходит, SYN-ACK не уходит; обмен идёт, но сессия рвётся. Первый случай указывает на промежуточное устройство, второй на фильтр или приложение на сервере, третий на приложение или MTU.

Не забывайте про блокировки внутри приложений и сервисов защиты. fail2ban добавляет собственные правила в iptables или nftables, и результат неотличим от ручной блокировки: проверяйте fail2ban-client status и fail2ban-client get sshd banned. Nginx и Apache закрывают доступ директивами deny, TCP wrappers работают через /etc/hosts.deny, облачный WAF фильтрует запросы до сервера. Логика deny all и связка с fail2ban разобраны в статье про файрвол для Linux-сервера.

Ещё одна причина недоступности порта без участия фильтров - переполнение очереди SYN. Проверьте ss -tn state syn-recv и netstat -s | grep -i listen: растущие счётчики переполнения указывают на приложение или параметры ядра, а не на правила.

Почему правило не срабатывает: порядок обработки и приоритеты

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

Порядок правил в iptables и nftables

В iptables пакет идёт по цепочке сверху вниз, и первое совпадение прекращает разбор. Пример из практики:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Порт 443 здесь недоступен: второе правило отбрасывает пакет до того, как разбор дойдёт до третьего. Лечится порядком, а не содержимым: iptables -I INPUT 3 -p tcp --dport 443 -j ACCEPT вставляет правило в нужную позицию, а -A всегда добавляет в конец. Посмотреть нумерацию и счётчики: iptables -L INPUT -n -v --line-numbers. Проверить наличие правила без правки набора: iptables -C INPUT -p tcp --dport 443 -j ACCEPT, код возврата 0 означает совпадение.

Вторая ошибка - цепочка. Трафик, адресованный самому хосту, обрабатывает INPUT, транзитный трафик и опубликованные порты Docker идут через FORWARD. Разрешающее правило в INPUT на них не влияет.

В nftables цепочки базового уровня выполняются в порядке приоритетов: raw (-300), mangle (-150), dstnat (-100), filter (0), srcnat (100). Вердикт drop, вынесенный цепочкой с меньшим значением priority, отмене не подлежит. Внутри цепочки правила также разбираются последовательно, а accept означает прекращение разбора этой цепочки, но не пропуск пакета мимо остальных. Посмотреть набор с номерами дескрипторов: nft -a list ruleset. Вставить правило в позицию позволяет nft add rule inet filter input position 3.

Ещё одна ловушка - смешение наборов. На современных дистрибутивах iptables работает через nftables, и рядом могут жить таблицы firewalld и таблицы, созданные вручную. Обе группы обрабатываются в одних и тех же хуках, поэтому отладка сводится к просмотру полного вывода nft list ruleset, а не только вывода iptables -L. Готовые примеры правил с пояснениями собраны в статье про сравнение iptables, nftables и ufw.

Приоритеты зон в firewalld и профилей Windows

firewalld привязывает сетевой интерфейс к зоне, и правила другой зоны на него не действуют. Начните с трёх команд:

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --query-port=443/tcp

Если интерфейс оказался в зоне drop или trusted, ожидаемый набор правил не применяется вовсе. Вторая частая ошибка - разница между runtime и permanent. Правило, добавленное с ключом --permanent, не работает до перечитывания конфигурации: firewall-cmd --reload. Обратная ситуация встречается так же часто: правило добавлено только в runtime, а после reload или перезапуска службы исчезает. Перенос runtime-настроек в постоянные выполняется командой firewall-cmd --runtime-to-permanent.

В Windows правила привязаны к профилям. Адаптер получает профиль Domain, Private или Public в зависимости от сети, и правило, созданное для Private, не действует, когда сеть опознана как Public. Проверьте Get-NetConnectionProfile и наличие нужного профиля в самом правиле: Get-NetFirewallRule -DisplayName 'HTTP*' | Select-Object Profile, Enabled, Action. Дальше работает приоритет: блокирующее правило перекрывает разрешающее, если совпадают условия. Порядок строк в оснастке wf.msc значения не имеет.

Остальные причины, по которым правило есть, а эффекта нет: несовпадение протокола (правило для TCP при проверке UDP), ограничение области RemoteAddress или LocalAddress, привязка к конкретной программе, требование шифрования соединения в свойствах правила, работа стороннего файрвола вместо встроенного.

Пошаговый алгоритм диагностики файрвола

Порядок действий идёт от состояния службы к правилам и логам. Так вы не потратите время на разбор цепочек, когда проблема в остановленном сервисе.

Проверьте, что файрвол запущен: systemctl is-active ufw firewalld nftables или Get-Service MpsSvc. На Windows отдельно уточните профиль активного интерфейса через Get-NetConnectionProfile.
Проверьте, что приложение слушает нужный порт: ss -tlnp | grep :443, netstat -ano | findstr :443. Смотрите на адрес привязки: 127.0.0.1 вместо 0.0.0.0 закрывает доступ извне без участия фильтра.
Просканируйте порт изнутри: nc -zv -w 3 127.0.0.1 443. Если ответа нет и здесь, проблема в приложении.
Просканируйте с соседнего хоста: nmap -sS -Pn -p 443 --reason или Test-NetConnection -Port 443. Состояние filtered указывает на фильтр между хостами.
Проверьте доступ из интернета через внешний сервис, если адрес публичный. Таймаут при открытом порте на хосте означает блокировку выше: security group, маршрутизатор, провайдер.
Посмотрите логи: journalctl -k | grep 'IPT-DROP', tail -f /var/log/ufw.log, firewall-cmd --set-log-denied=all, события 5152 и 5157 либо pfirewall.log в Windows.
Сверьте счётчики правил: iptables -L INPUT -n -v --line-numbers, nft -a list ruleset. Растущий счётчик показывает, какое правило обрабатывает ваш трафик.
Проверьте порядок и цепочку: разрешающее правило должно стоять выше блокирующего и в той цепочке, через которую идёт трафик (INPUT или FORWARD).
Проверьте зону или профиль: firewall-cmd --get-active-zones, Get-NetConnectionProfile. Убедитесь, что набор правил сохранён и переживёт reload.
Устраните причину минимальным изменением: добавьте одно правило, проверьте результат с трёх точек, затем фиксируйте конфигурацию.
Сохраните набор: netfilter-persistent save, iptables-save > /etc/iptables/rules.v4, nft list ruleset > /etc/nftables.conf, firewall-cmd --runtime-to-permanent, New-NetFirewallRule для Windows.
Снимите временные предохранители: atq и atrm для отложенного отката, удалите задачу планировщика, выключите подробное логирование.

Результат проверки фиксируйте сразу тремя отметками: вывод сканирования снаружи, строка лога с блокировкой и состояние правил после правки. Такой набор объясняет и вам, и коллегам, что изменилось, а при следующем инциденте сравнение занимает минуты. Если после всех шагов порт открыт снаружи при чистом host-based файрволе, вернитесь к внешнему периметру: security groups и NAT остаются вне сервера, и именно там чаще всего находится лишнее разрешение.