Карта без единого пакета: разведка и сканирование
Разведка в сети начинается не с запуска сканера, а с вопроса: какие данные о сети уже существуют и кто их производит. Мониторинг, который в основной программе рассматривался как инструмент эксплуатации, с этой стороны оказывается источником утечки: зеркало порта, сохранённый захват, журнал подключений и таблица маршрутизации рассказывают о сети больше, чем любой активный запрос, и при этом не оставляют в ней ни одного нового пакета.
Тема 22 основной программы объясняла, как измерять сеть и находить неисправности. Здесь тот же инструментарий используется для построения карты: сначала из чужих данных, затем — из ответов самой сети. Второй этап неотделим от первого, потому что активная разведка проверяет гипотезы, а не заменяет их: сканер, запущенный вслепую, даёт список портов; сканер, запущенный по пассивной карте, даёт список ролей.
Изложение идёт от данных к пакету. Сначала — пассивные источники и то, что из них извлекается. Классическое описание стека и его протоколов дано в учебниках 12, поэтому здесь напоминаются только те свойства, которые становятся точкой атаки. Затем — активные методы локального сегмента: ARP, ICMP, traceroute, перечисление DNS и SNMP. После этого — устройство сканирования: почему разные типы сканов дают разный ответ и что этот ответ означает. Завершают тему обход фильтров и обнаружение.
Границы с соседями: атаки на канальном уровне — тема 02; подделка пакетов и атаки на TCP — тема 04. Здесь сеть только описывается, но не изменяется.
Тень базового курса: мониторинг как источник карты
В теме 22 сеть наблюдали, чтобы обнаружить неисправность: ping проверял доступность, traceroute показывал путь, NetFlow отвечал на вопрос «кто с кем говорил». Все эти инструменты предполагают, что наблюдатель находится внутри сети и имеет право смотреть.
Атакующий начинает с того же, но меняет цель: ему нужен не ответ «работает ли», а инвентарь — какие адреса заняты, какие службы слушают, какие узлы разговаривают друг с другом и какие из них видят больше остальных. Разница не в инструментах, а в вопросе. tcpdump, снятый на зеркале порта в течение часа, отвечает на этот вопрос точнее, чем сутки сканирования, потому что содержит не только «порт открыт», но и «этот порт каждый час опрашивает один и тот же внутренний адрес».
Отсюда первый принцип: пассивная разведка невидима по определению. Её нельзя обнаружить в сети, потому что она не порождает трафика; её можно обнаружить только по факту доступа к зеркалу, к журналам или к системе мониторинга. Второй принцип: пассивные данные быстро устаревают — DHCP выдаёт адреса, балансировщики меняют узлы, а VPN-туннели скрывают настоящую топологию. Поэтому карта строится в два прохода: пассивный черновик, затем активная проверка.
Пассивная разведка: данные, которые уже есть
Зеркало порта, TAP и сохранённый захват
Самый богатый источник — копия трафика. Она появляется тремя способами: зеркалирование порта на коммутаторе (SPAN), оптический или электрический TAP, встроенный в разрыв линка, и захват на самом узле. Первые два дают картину сегмента, третий — только трафик узла, но зато вместе с процессом, который его породил.
Захват сам по себе — сырой материал. Чтобы он стал картой, его нужно свести к парам «источник — назначение» и к множеству наблюдаемых служб. Методика такого сведения разобрана у Сэндерса 6; простейший разбор делает tshark:
tshark -r segment.pcap -q -z conv,ip
tshark -r segment.pcap -q -z endpoints,ip
tshark -r segment.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" \
-T fields -e ip.src -e ip.dst -e tcp.dstport | sort -u
Первая команда печатает матрицу разговоров с объёмом в каждом направлении, вторая — список конечных точек, третья — все попытки установить соединение. Третья полезна тем, что показывает не только состоявшиеся сессии, но и отказы: SYN без ответа означает фильтр, SYN с RST — закрытый порт, SYN с SYN-ACK — живую службу.
Пример вывода для учебного сегмента (адреса документационные):
tshark -r segment.pcap -q -z conv,tcp
================================================================================
TCP Conversations
Filter:<No Filter>
| <- | | -> |
| Frames Bytes | | Frames Bytes |
192.0.2.10:49152 <-> 192.0.2.20:80 14 1840 14 9210
192.0.2.10:49153 <-> 192.0.2.53:53 2 148 2 312
192.0.2.10:49154 <-> 198.51.100.7:443 31 22140 29 88110
Читается так: узел 192.0.2.10 — рабочая станция, которая ходит в веб, в DNS и наружу по TLS. Узел 192.0.2.20 — внутренний веб-сервер. Адрес 198.51.100.7 — внешний, и объём в его сторону втрое больше обратного, что для браузера нормально, а для неизвестного процесса — повод присмотреться.
Журналы Zeek и потоковая телеметрия
Zeek превращает пакеты в события: conn.log — соединения, dns.log — запросы, http.log — запросы и ответы, ssl.log — рукопожатия TLS, files.log — переданные файлы 7. Для разведки важны не отдельные строки, а поля, которых нет в pcap: длительность, число байтов в каждую сторону, состояние соединения, история.
zeek -r segment.pcap local
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service duration orig_bytes resp_bytes
192.0.2.10 192.0.2.20 80 tcp http 1.204 1840 9210
192.0.2.10 192.0.2.53 53 udp dns 0.031 148 312
192.0.2.10 198.51.100.7 443 tcp ssl 12.884 22140 88110
192.0.2.20 192.0.2.10 22 tcp ssh 0.442 2210 1480
Четвёртая строка — то, ради чего строится карта: внутренний веб-сервер сам инициирует SSH-сессию к рабочей станции. Это либо администрирование, либо обратное подключение; в обоих случаях направление соединения важнее порта.
NetFlow, IPFIX и sFlow дают ту же картину без содержимого, но зато за месяцы и по всей сети 8. Для разведки они ценны историей: какие пары «источник — назначение» устойчивы, какие появились впервые, какие исчезли. Базовая линия «кто с кем обычно говорит» — самый дешёвый детектор нового узла.
Внешние источники: DNS, Certificate Transparency, BGP, SNMP
Снаружи организация видна через свои имена и адреса. Обратная зона DNS перечисляет имена по адресам; записи SPF, DKIM и DMARC выдают почтовую инфраструктуру; Certificate Transparency показывает все сертификаты, выпущенные на домен, включая те, о которых забыли; RIPEStat и bgp.tools связывают префиксы с автономными системами и провайдерами; PeeringDB — с точками обмена 9.
SNMP остаётся отдельным подарком. MIB-II описывает интерфейсы, адреса, маршруты и таблицу соседей; при community-строке public всё это читается одной командой:
snmpwalk -v2c -c public 192.0.2.1 1.3.6.1.2.1.4.20.1.1
snmpwalk -v2c -c public 192.0.2.1 1.3.6.1.2.1.2.2.1.2
snmpwalk -v2c -c public 192.0.2.1 1.3.6.1.2.1.4.21.1.1
Первая команда — таблица адресов (ipAdEntAddr), вторая — имена интерфейсов (ifDescr), третья — таблица маршрутов (ipRouteDest). Вместе они дают адресный план и топологию без единого сканирующего пакета: запрос идёт по UDP/161, но это запрос к службе, а не перебор.
Активная разведка локального сегмента
ARP и ICMP: кто ответил
В локальном сегменте хост обязан ответить на ARP-запрос о своём адресе — это часть работы стека, а не служба, которую можно выключить 4. Поэтому перебор адресов через ARP даёт полный список занятых адресов быстрее и точнее, чем ICMP, который часто фильтруют.
for i in $(seq 1 254); do arping -c 1 -w 1 192.0.2.$i >/dev/null 2>&1 && echo "192.0.2.$i up"; done
arping шлёт ARP-запрос и ждёт ответа; -c 1 ограничивает попытку одним пакетом, -w 1 — одной секундой. Последовательный перебор 254 адресов занимает до четырёх минут; параллельный вариант на Python с scapy укладывается в секунды, но требует прав на raw-сокет.
ICMP даёт больше, чем факт доступности. Эхо-запрос возвращает TTL, по которому грубо оценивают число хопов, и размер ответа, по которому видно, режут ли крупные пакеты 3. Запросы timestamp и address mask в современных системах почти всегда отключены, но их ответы прямо выдают версию стека.
nmap -sn -PR 192.0.2.0/24
nmap -sn -PE 192.0.2.0/24
nmap -sn -PS22,80,443 -PA80 192.0.2.0/24
Первая команда — ARP-обнаружение (работает только в своём сегменте), вторая — ICMP echo, третья — TCP SYN в перечисленные порты и TCP ACK. Разница в результатах и есть карта фильтрации: хост, ответивший на ARP, но не на ICMP, существует и, скорее всего, фильтрует.
Traceroute, MTU и firewalk
traceroute использует TTL: каждый маршрутизатор уменьшает его на единицу и, получив ноль, отвечает ICMP Time Exceeded. Три варианта — UDP, ICMP и TCP — различаются тем, какой фильтр их пропускает. Если UDP-трассировка обрывается на третьем хопе, а TCP-трассировка доходит до цели, это не «сеть сломалась», а правило фильтрации, которое видно по разнице.
traceroute -n 203.0.113.10
traceroute -T -p 443 -n 203.0.113.10
tracepath -n 203.0.113.10
tracepath дополнительно сообщает MTU пути: он отправляет пакеты увеличивающегося размера и ловит ICMP «Fragmentation needed». Тот же механизм позволяет найти «чёрную дыру» PMTUD — звено, которое молча отбрасывает крупные пакеты с DF=1.
Firewalk использует TTL наоборот: пакет с TTL на единицу больше, чем расстояние до межсетевого экрана, доходит до него, но не до следующего узла. Если экран пропускает пакет, тот умирает за ним и ответа нет; если блокирует — экран отвечает ICMP Time Exceeded сам. По набору таких ответов восстанавливается правило фильтрации, не касаясь цели.
Перечисление DNS и SNMP
Зона DNS, отданная на передачу, — это готовая карта имён. Проверка занимает одну команду:
dig AXFR nsu.example @192.0.2.53
dig +short TXT _dmarc.nsu.example
dig +short NS example.com
Если передача закрыта, остаются словарный перебор и NSEC-walking: в зоне с DNSSEC отсутствующее имя возвращает NSEC-запись, которая указывает на следующее существующее имя, — и по цепочке таких ответов зона вычитывается целиком, без перебора.
SNMP-перебор community-строк — отдельная техника: onesixtyone и snmpwalk проверяют словарь строк вроде public, private, cisco. Успех даёт не только данные, но и путь к изменению конфигурации, если строка read-write.
Сканирование: как оно устроено
Типы сканов и что они говорят о фильтрации
Сканер не «проверяет порт» — он отправляет пакет с определёнными флагами и интерпретирует ответ или его отсутствие. Разные флаги обходят разные фильтры.
| Тип | Пакет | Открытый порт | Закрытый порт | Фильтр |
|---|---|---|---|---|
| TCP connect | полное рукопожатие | SYN-ACK, затем ACK | RST | таймаут |
| TCP SYN | SYN | SYN-ACK | RST | таймаут или ICMP |
| TCP FIN/NULL/XMAS | без SYN | нет ответа | RST | таймаут или ICMP |
| TCP ACK | ACK | RST | RST | таймаут |
| UDP | пустая датаграмма | ответ службы | ICMP port unreachable | таймаут |
Таблица объясняет, почему FIN-скан не работает против Windows: стек отвечает RST на любой пакет вне соединения, и открытые порты неотличимы от закрытых. SYN-скан, наоборот, универсален, потому что опирается на обязательный шаг рукопожатия.
ACK-скан не ищет открытые порты — он ищет фильтры. RST в ответ означает, что пакет дошёл до хоста; отсутствие ответа — что его съел межсетевой экран. Это основной инструмент картирования правил.
Определение версий и операционной системы
Определение версии — это не чтение баннера, а набор проб: nmap-service-probes содержит сотни запросов, каждый из которых вызывает характерный ответ. Проба для HTTP может отправить GET / HTTP/1.0 с необычным заголовком и сравнить ответ с сигнатурой; для SSH — прочитать строку идентификации; для TLS — попытаться выполнить рукопожатие с разными наборами шифров.
nmap -sV --version-intensity 5 -p 22,80,443 192.0.2.20
nmap -O --osscan-guess 192.0.2.20
nmap -sV -sC -oX scan.xml 192.0.2.0/24
Определение ОС опирается на отпечаток стека: начальное значение ISN, поведение IPID, набор TCP-опций и их порядок, размер окна, реакцию на неверные комбинации флагов 5. Отпечаток стабилен, пока стек не изменился; виртуализация и балансировщики его размывают, а подделка TTL и MSS сбивает.
Скорость: nmap, masscan, zmap
nmap хранит состояние по каждому хосту и потому точен, но медленен: миллион адресов для него — часы. masscan и zmap работают без состояния: они отправляют SYN с заданной скоростью и слушают ответы, а соответствие «ответ — цель» восстанавливают по номеру порта источника. Отсюда ограничение: один порт на адрес, иначе ответы не сопоставить.
masscan 192.0.2.0/24 -p0-65535 --rate 10000
zmap -p 443 -o results.csv 198.51.100.0/24
Скорость — главный демаскирующий фактор. Десять тысяч пакетов в секунду от одного адреса не похожи ни на что легитимное; именно скорость, а не типы пакетов, ловится большинством детекторов.
Обход фильтров и обнаружения
Фрагментация, decoys и исходный порт
Фрагментация делит заголовок и полезную нагрузку на части. Stateless-фильтр, который не собирает фрагменты, видит только первый фрагмент с TCP-заголовком и может пропустить пакет, если правило смотрит на порт, оказавшийся во втором фрагменте.
nmap -f -p 80,443 192.0.2.20
nmap --mtu 8 -p 80 192.0.2.20
nmap -D RND:10 -p 80 192.0.2.20
nmap -g 53 -p 80,443 192.0.2.20
-f режет на восемь байт, --mtu 8 задаёт размер явно; -D RND:10 добавляет десять случайных ложных источников, среди которых теряется настоящий; -g 53 подставляет исходный порт 53, потому что многие правила разрешают DNS-трафик безусловно.
Медленно и распределённо
Чем медленнее скан, тем меньше он похож на скан. -T0 и -T1 растягивают интервалы, --scan-delay задаёт паузу между пакетами, а распределение по нескольким источникам размывает корреляцию. Цена — время: полный перебор одного адреса при задержке в секунду занимает восемнадцать часов.
Обнаружение строится на том, что медленный скан всё равно оставляет след: множество SYN от одного адреса к разным портам за длительный период. Детектор, работающий по окну в минуту, его не увидит; детектор по суточному окну — увидит. Поэтому обход — это всегда вопрос того, какое окно агрегации использует защита.
Обнаружение и защита
| Приём | Признак | Контрмера |
|---|---|---|
| ARP-перебор | много ARP-запросов от одного MAC | arpwatch, port security, DAI |
| ICMP-перебор | эхо-запросы ко всем адресам подсети | rate limit ICMP, baseline |
| SYN-скан | SYN без завершения, рост conntrack | SYN cookies, лимит на источник, Suricata |
| Медленный скан | широкий набор портов за сутки | длинное окно агрегации, NetFlow |
| Фрагментация | крошечные фрагменты, перекрытие | сборка фрагментов на экране |
| Decoys | много источников с одинаковым TTL | корреляция по TTL и IPID |
| SNMP-перебор | много запросов community | смена строки, ACL, SNMPv3 |
| AXFR | запрос передачи зоны | разрешить передачу только второму серверу |
Правило Suricata на SYN-скан по числу портов (классификация приёмов разведки — в матрице ATT&CK 10):
alert tcp any any -> $HOME_NET any (msg:"SCAN possible SYN scan"; flags:S; \
threshold: type both, track by_src, count 30, seconds 60; \
classtype:attempted-recon; sid:1000001; rev:1;)
Правило срабатывает, когда один источник за минуту отправляет тридцать SYN в разные порты. Порог подбирается по базовой линии: в сети, где каждый клиент открывает десятки соединений в минуту, тридцать — норма, и правило нужно поднимать до сотен.
Итоги темы
Пассивная разведка даёт карту, которую невозможно обнаружить в сети, потому что она не создаёт трафика. Её источники — зеркало порта, pcap, Zeek, NetFlow, SNMP, DNS и внешние базы; её главный продукт — не список адресов, а список ролей и связей.
Активная разведка проверяет эту карту и стоит дороже: каждый пакет — след. Разные типы сканов отвечают на разные вопросы, и выбор типа определяется не удобством, а тем, какой фильтр стоит на пути. Определение версий и ОС — это сравнение с сигнатурами, а не магия; оно ошибается там, где стек изменён.
Обход фильтров — всегда компромисс между скрытностью и скоростью. Фрагментация, decoys и медленный темп снижают вероятность обнаружения, но не устраняют её: защита, которая агрегирует события за длинное окно, видит то, что пропускает защита с коротким.
Следующая тема спускается на уровень ниже — к кадрам Ethernet, где доверие к ARP, DHCP и STP оказывается ещё дешевле.
Литература
- Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
- Fall K. R., Stevens W. R. TCP/IP Illustrated. Volume 1: The Protocols. 2nd ed. — Addison-Wesley, 2011.
- Postel J. Internet Control Message Protocol. — RFC 792, IETF, 1981. https://www.rfc-editor.org/rfc/rfc792
- Plummer D. C. An Ethernet Address Resolution Protocol. — RFC 826, IETF, 1982. https://www.rfc-editor.org/rfc/rfc826
- Lyon G. Nmap Network Scanning. — Insecure.Com LLC, 2009.
- Sanders C. Practical Packet Analysis. 3rd ed. — No Starch Press, 2017.
- The Zeek Documentation. — https://docs.zeek.org/
- Claise B., Trammell B., Aitken P. Specification of the IP Flow Information Export (IPFIX) Protocol. — RFC 7011, IETF, 2013. https://www.rfc-editor.org/rfc/rfc7011
- Mockapetris P. Domain Names — Implementation and Specification. — RFC 1035, IETF, 1987. https://www.rfc-editor.org/rfc/rfc1035
- MITRE ATT&CK. Discovery. — https://attack.mitre.org/tactics/TA0007/