Короткий ответ

Проверка периметра — регулярный свой скан всех белых адресов организации с хоста вне LAN/VPN (LTE, облачный jump ваш), сверка с матрицей и конфигом FW. Только свои IP. Не -iL список клиентов. Не сканируйте /24 провайдера. Не stop nftables «чтобы увидеть listen». Результат: отчёт open/filtered vs Excel/git, тикеты на лишнее, дата next scan.

Матрица: документировать порты. Лишнее: закрыть.

Плейсхолдер WAN: 203.0.113.10. Реальные адреса — из договора и DNS, не из этой статьи как чужие.

Симптомы и как отличить

Нет артефакта nmap за квартал. Проверяли Test-NetConnection из офиса — это не периметр. Shodan показывает 3389, вы не знали второй белый. IDS орёт на ваш же сканер без suppress — процесс не описан.

Отличие от pentest: здесь инвентарь экспозиции, не эксплуатация. Без эксплойтов, без CVE-охоты, без чужих сетей.

Возможные причины

  1. Скан не с улицы (hairpin, split tunnel).
  2. Неполный список белых (IPv6, второй WAN, облако).
  3. CDN origin скрыт, hostname вводит в заблуждение.
  4. UPnP/временный DNAT.
  5. Firewall на пути сканера (сам оператор) даёт ложный filtered.

Диагностика

1. Реестр целей

  • Все IPv4/IPv6 из актов провайдера
  • EIP/облако
  • A/AAAA критичных имён (сайт, vpn, mx)
  • Не PTR-соседи

Запишите: «сканируем только этот список».

2. Откуда сканируете

LTE или VPS вне 10.0.10.0/24 и вне VPN. Зафиксируйте src IP сканера — потом suppress в IDS (шум IDS).

3. Окно и нагрузка

Начните с короткого списка портов, -p- по одному IP в согласованное окно. Не flood (это не DDoS на себя без нужды).

4. Снимок FW до скана

sudo nft list ruleset > /root/pre-perim-$(date +%F).nft
/export file=pre-perim

Не меняйте правила «на время проверки» в policy accept.

Решение

Шаг 1. Короткий TCP-профиль

nmap -Pn -sS --reason -p 21,22,23,25,53,80,110,139,143,389,443,445,465,587,993,995,1433,1723,3306,3389,5432,5900,8291,8530,8531 \
  203.0.113.10 -oA /tmp/perim-$(date +%F)-short

Только свои цели в командной строке.

Шаг 2. UDP точечно

sudo nmap -Pn -sU -p 53,123,161,500,4500,51820,1900 203.0.113.10 -oA /tmp/perim-$(date +%F)-udp

53/123/161 open с WAN — отдельные finding (рекурсия, NTP amplification, SNMP).

Шаг 3. Полный TCP своего одного IP

nmap -Pn -sS -p- --min-rate 200 203.0.113.10 -oA /tmp/perim-$(date +%F)-full

min-rate не срывайте канал филиала. Один IP.

Шаг 4. Сверка

Таблица: порт, nmap state, есть ли в матрице, NAT dest, owner. Любой open вне матрицы — тикет close. open в матрице — обновить last_verified.

Шаг 5. Идентификация сервиса осторожно

-sV на своих open допустим в окне. Не NSE exploit. Баннер для заявки.

Шаг 6. IPv6

Повторите по AAAA своего узла. Часто IPv4 закрыли, AAAA нет в матрице.

Шаг 7. Конфиг vs скан

Если nmap filtered, а в filter accept — смотрите апстрим. Если open, а в конфиге drop — другой хост/NAT/облако.

/ip firewall nat print where chain=dstnat
sudo nft list table ip nat

Шаг 8. Типичные finding и куда

OpenСтатья
3389/445проброс
8291/22 adminадминка
лишниелишние порты
куча всегоany-any + ревизия

Не чините «отключением FW». Чините правило/NAT/listen.

Регламент квартального прохода с артефактами

Календарь: ответственный, список целей из договора (IPv4+IPv6), src IP сканера, окно для -p-. Артефакты: -oA nmap, sha256, diff vs матрица, тикеты на open вне матрицы. Suppress IDS на src сканера заранее, чтобы не устроить себе же шум.

Метод: только свои адреса, LTE/VPS вне VPN. Короткий TCP → точечный UDP → полный TCP одного IP. Не masscan соседнего /24. После закрытия finding — повторный скан того же порта. Change с новым DNAT не закрывается без строки матрицы и короткого nmap. Если 443/VPN отвалились во время скана — это ваш rate limit, смягчите бюджет, не отменяйте проверку периметра.

Как проверить, что проблема устранена

Процедура считается рабочей, когда:

  1. Отчёт в тикете: список IP, src сканера, файлы nmap, diff матрицы.
  2. Нет open вне матрицы или на каждый есть в работе ticket.
  3. Повтор после закрытия — чисто.
  4. IDS не сдох от шума (suppress src).
  5. Firewall остался enabled.
  6. Следующая дата в календаре (квартал / после каждого изменения WAN).

Легитим 443/VPN после скана живы — вы не уронили прод лимитом; если уронили — смягчите rate, не отменяйте скан навсегда.

Не подменяйте периметр сканом из Zabbix внутри LAN. Внутренний TCP-check 443 на VIP полезен как доступность, но не доказывает закрытый 3389 с улицы. Держите оба: внутреннюю канарейку сервиса и внешний nmap своих IP. Отчёт для руководства: число белых, число open, число вне матрицы, дата. Без эксплуатации и без CVE. Если open вне матрицы не закрыли за SLA — это уже не «проверка», а открытый finding в регистре рисков.

Если не помогло

  • Провайдер NAT (CGNAT): ваш «белый» не тот, что в договоре.
  • Anycast/CDN: скан hostname ≠ origin. Сканируйте origin из реестра.
  • Load balancer режет ICMP/SYN иначе с разных сетей — два src сканера.
  • Юридически диапазон не ваш — остановитесь.
  • Команда сканировала 10.0.10.0/24 — это не внешний периметр.

Профилактика

  • Календарь + ответственный.
  • Автоскан своих IP с jump в облаке организации, отчёт на syslog/SIEM.
  • Реестр белых = CMDB.
  • Change WAN без скана не закрывается.
  • Запрет UPnP, запрет DNAT 3389.

FAQ

Можно ли masscan на свой /29?

Осторожно с pps. Для маленького списка nmap достаточно. Не целитесь в соседние адреса /29 если они не ваши.

Shodan вместо своего скана?

Дополнение, не замена. Задержка индекса, не все порты. Свой nmap контролируете.

Нужен ли UDP -p-?

Обычно нет: шумно и медленно. Точечные 53/123/161/500/4500/51820/1194.

Скан сломал IDS/IPS

Переведите ложные SID, whitelist src сканера, не stop IPS навсегда.

Разрешение провайдера?

Вы сканируете свой хост. Не их инфраструктуру. Не делайте traceroute-flood. При сомнении — письменное у владельца IP (вы).