Если отойти от легенд и вернуться к практике, картина простая: вам нужно знать, где в вашей адресной зоне реально «дышат» порты и что именно за сервисы там отвечают. На роль «радара» берут Masscan — он шьёт миллионы SYN-зондов с предсказуемой скоростью и почти не тратит CPU. На роль «врача-диагноста» выходит Nmap — уверенно разговаривает с демонами, вытягивает версии, баннеры, поддерживаемые шифры и иногда угадывает ОС по поведению TCP/IP. Вместо борьбы школ инструментов мы выбираем связку: радар для первичного обнаружения, врач для точного диагноза. В этом тексте мы настроим оба так, чтобы они не мешали вашим пользователям, не триггерили лишние алерты у SOC и укладывались в бюджет по сети и вычислениям.

Зачем нужны два инструмента и почему попытки «одним Nmap’ом» — почти всегда компромисс

Masscan создан, чтобы быстро отвечать на один короткий вопрос: «на каких адресах и портах что-то открыто». Он использует свой TCP-стек, не полагаясь на стек ядра, из-за чего способен держать десятки тысяч пакетов в секунду даже на скромной виртуалке. Интересный факт: автор Masscan вдохновлялся подходом сканера ZMap, но сделал ставку на повторяемость и точный контроль скорости. Nmap, напротив, исторически про диагностику: глубокие пробы handshake, экспресс-скрипты NSE, аккуратная проверка версий, попытка распознать ОС сигнатурами. Когда вы пытаетесь «сделать всё Nmap’ом», неизбежно страдаете либо скорость, либо качество. Когда пытаетесь «всё Masscan’ом», страдает содержание: вы знаете, что порт 443 открыт, но не знаете, это старый Apache, новый Envoy или прокси, отвечающий H2-TLS. Два этапа решают это без героизма: Masscan находит, Nmap подтверждает и описывает.

Как определить зону ответственности и не получать абузы

Этика здесь важнее техники. Сканируйте только то, на что у вас есть право. Это не просто юридический щит, это и защита вашего времени: если зона согласована и задокументирована, меньше неожиданностей и меньше «ложной войны» с внутренним IDS. Начните с инвентаря диапазонов: собственные подсети, подсети аренды, сегменты в независимых ДЦ, публичные адреса балансировщиков, тестовые площадки. Отдельно пропишите исключения: старые принтеры, хрупкие IoT, биллинг и кассовые шлюзы — туда без согласования даже SYN-пакеты не шлём. Внутреннюю маршрутизацию и фаерволы стоит обсудить заранее с эксплуатацией: окно времени, лимиты PPS, набор портов и формат отчётов. Если такой регламент отсутствует, напишите короткий и понятный документ — он окупится уже на первом цикле.

Как выбрать площадку для скана и не сжечь бюджет

В независимом облаке мы можем переносить «скан-станцию» ближе к цели. Если сканить из того же ДЦ, общий трафик почти не выходит наружу, а латентность стабильная. Для больших поверхностей из разных регионов рационально поднять по малому узлу рядом с каждым крупным кластером и склеить отчёты. Ещё один экономический момент — CPU/IO. Masscan любит хорошие сетевые драйверы и честный vCPU без оверселла; Nmap любит кэш DNS, SSD для логов и умеренные лимиты ретраев. На практике одной бюджетной VPS на NVMe хватает, чтобы просканировать /16 по нескольким портам за ночь без неприятных сюрпризов. Если нужен экспресс-пролёт топ-портов по автономной системе, удобнее взять выделенный сервер с 10 Gb/s и запускать скан в ночное окно — в таком режиме вы платите за часы, а не за гигабайты в облачной чекушке.

Если хотите снять вопросы с сетевой частью, у нас есть VPS NVMe и «железо» с портами 10–40 Gb/s и гарантированными vCPU — можем развернуть готовую «скан-станцию» Masscan→Nmap и настроить окна, лимиты и отчёты под ваш регламент. Проверьте доступность локаций в ближайшем к вам регионе и попросите преднастройку «Inventory Scanner».

Подготовка окружения

На Linux всё проще всего: пакеты есть в репозиториях. Ставим Nmap стандартно и проверяем версию, затем добавляем Masscan. На Windows важнее правильно поставить Npcap, иначе сырые сокеты не заработают, а скорость будет «как по модему». Не забывайте про время — синхронизируйте часовой пояс и NTP, иначе у вас в отчётах начнётся хроника параллельной вселенной. Поднимая инстанс в облаке, сразу увеличьте лимит открытых файлов и упритесь в SSD для логов, а не в сетевую шару: «быстрые» сканы печально известны тем, что упираются не в сеть, а в запись JSON на медленный диск.

# Debian/Ubuntu
sudo apt update && sudo apt -y install nmap masscan jq
ulimit -n 1048576

Если рядом IDS, который не любит странные SYN на нестандартных скоростях, не ведите себя как киношный хакер. Начинайте с малого --rate, договоритесь о временном окне и сразу включите исключения: пара сотен «хрупких» адресов, которых лучше не будить, обойдётся дешевле, чем ночной звонок от дежурного администратора.

Masscan как радар: скорость под контролем

Masscan берёт на себя первый проход. Мы определяем диапазон, набор портов и целевую скорость. Ключевая мысль — скорость не самоцель. Нужна предсказуемость. Даже на 1 Gb/s приятно работать в диапазоне 3–10 тысяч пакетов в секунду, когда соседние сервисы не видят аномалии и не душат вас rate-limit’ами.

Интересный технический факт: у Masscan отдельный TCP-стек, поэтому ядро системы может отсылать «лишние» RST на ответы «чужих» соединений. В продакшене это лечится кратковременным подавлением исходящих RST на время скана и аккуратным откатом после. Это не нарушение протокола, а способ не позволять ядру «чинить» то, что для Masscan нормально.

Формат вывода выбирайте JSON — он читаемый, а jq безотказен для вытягивания списка целей. На больших объёмах пригодится деление задачи на «шарды» — то же пространство адресов можно порезать на три-пять параллельных проходов с фиксированными seed’ами, чтобы не было дыр. Если адресов много, но портов мало, выгоднее «порт-центричный» подход: массово пройтись по 443/80/22 и лишь потом добивать экзотику на уменьшившемся списке IP.

# первый проход по двум портам с умеренной скоростью
sudo masscan 203.0.113.0/24 -p80,443 --rate 5000 -oJ web.json

Nmap как диагност: меньше ретраев

Второй проход должен быть экономным. Вы берёте IP, где радар услышал что-то живое, и передаёте их Nmap’у уже с перечнем портов. В этом месте выигрывают «умные» параметры: отключённый обратный DNS, нормальный шаблон времени, безопасные скрипты по умолчанию, а версии сервисов включены. Если вы любите аккуратность — делайте два круга: сначала «веб» (80/443/8080/8443), потом «управление» (22/3389/5900/5432 и т. д.). Это не только дружелюбнее к сервисам, но и укорачивает ревью результатов.

# извлекаем IP и порты из JSON первого прохода
jq -r '.[].ip' web.json | sort -u > hosts.txt
ports=$(jq -r '.[].ports[].port' web.json | sort -n | uniq | paste -sd, -)

# диагностический проход
nmap -iL hosts.txt -p "$ports" -sS -sV -sC --open -T4 -n -oA web_diag

Отчёты стоит хранить в трёх форматах одновременно: человекочитаемый, XML для машин, grepable для быстрых фильтров. В CI удобно складывать их в артефакты с датой и суффиксом локации: так вы спустя месяц сможете честно ответить, что именно поменялось.

Как не устроить себе «ложную войну» с защитой

Самые болезненные истории — про «Host seems down» и бесконечные UDP-сканы. Оба сценария решаются здравым смыслом. Если узел не отвечает на ICMP и пинг-пробы, не упирайтесь лбом, явно укажите -Pn или используйте TCP/UDP-пробы определённых портов. UDP как класс — медленный и требовательный к ретраям; здесь разумно брать топ-несколько портов и ограничивать время на хост. Если Nmap занят «героическим» number-of-retries, не стесняйтесь уменьшать повторы и поднимать минимальную скорость проб. В большом периметре важна не «идеальная» точность, а повторяемость и тренды.

Что делать с баннерами и «вредными» NSE-скриптами

Баннеры — полезная вещь для инвентаря, но не пытайтесь перепрыгнуть через голову и запускать весь набор скриптов уязвимостей. Держите себя в руках: дефолтные безопасные скрипты покрывают базовые кейсы, а точечные сценарии вроде проверки SSL-профиля, баннеров SSH и заголовков HTTP можно включать отдельной командой на небольших выборках. Кстати, быстро оценить жизненность веб-поверхности помогает комбо из -sV и запроса заголовков, это даёт на вход командам SRE и разработчикам понятные идентификаторы версий.

Как объяснить бизнесу экономику инвентаря и почему «скан в облаке» бывает дорогим

Трафик — это деньги. В гиперскейлерах вы платите за «выход» из зоны часто больше, чем стоит вся виртуалка за месяц. В независимом облаке и на «железе» картина иная: вы платите за узел и канал, а внутренние переброски в пределах площадки не превращаются в счёт с шестью нулями. Когда мы говорим «Masscan ночью, Nmap утром», мы фактически выносим основную сетевую нагрузку в дешёвое окно и сокращаем проброс трафика через границы. Если ваша зона широкая, имеет смысл сделать две-три «скан-станции» по географии, а не одну «в центре». Так вы выиграете в латентности, окажете меньше давления на транзиты и снизите вероятность ложных алертов на магистралях.

Если нужна быстрая экономичная обвязка, мы развернём для вас минимальный стек — однотонный VPS близко к целям, предустановленный Masscan/Nmap, сохранение отчётов на локальный NVMe и экспорт в ваш SIEM. Запросите миграцию стенда бесплатно и проверьте доступность локаций — обычно это часы, а не недели.

Отчёты важны не сами по себе, а как материал для диффа. Храните XML-выгрузки в каталоге с датой, локацией и автором запуска. Пишите рядом короткий README на две-три строки: окно, лимиты, список исключений, версии инструментов. Старайтесь, чтобы один и тот же пайплайн запускался одной командой, а не «у Вани — так, у Маши — иначе». Когда артефакты лежат рядом и структурно, вы сможете однажды показать руководителю график: «в январе открытых 443 было 612, к апрелю — 489, а RDP в Интернет в принципе исчез». Сколько адресов покрыто, какой PPS считаете безопасным, какой процент «стабильно открытых» портов на вашей поверхности. Публиковать сырые отчёты нельзя — в них много лишнего. Но сводные графики и методика вполне годятся для блог-поста. Это и репутация инженеров, и вклад в культуру «independent cloud», где мы все стараемся быть хорошими соседями по маршрутизатору.

Проверьте доступность локаций HSTQ для вашей зоны и закажите VPS с предустановленным пайплайном Masscan→Nmap. Настроим окна, исключения, отчёты и алерты.