Читаю дамп Wireshark на собеседовании вместо пересказа модели OSI: что реально спрашивают на джуна в сетевую безопасность

За два года я провёл больше 40 технических интервью на позицию джуна в SOC (Security Operations Center — центр мониторинга и реагирования на инциденты ИБ). Ровно три кандидата из этих сорока смогли внятно объяснить, что видят в pcap-файле (файл с записью сетевого трафика, формат .pcap/.pcapng), когда я открывал его на экране. Остальные начинали перечислять семь уровней OSI — и зависали на вопросе: «А на каком из этих уровней работает пакет, подсвеченный красным?» Разрыв между заученной теорией и умением читать реальный сетевой трафик — главная причина, по которой кандидаты не проходят техническое интервью на позиции в сетевой безопасности.

Почему на собеседовании сетевого инженера ИБ дают дамп вместо учебника

Формат вопросов на собеседовании по кибербезопасности за последние пару лет заметно сдвинулся. Раньше просили перечислить уровни модели OSI (Open Systems Interconnection — семиуровневая модель, описывающая, как сетевые устройства обмениваются данными), назвать отличия TCP от UDP и объяснить работу ARP (Address Resolution Protocol — протокол, который связывает IP-адрес устройства с его MAC-адресом в локальной сети). Это по-прежнему спрашивают, но как разогрев. Основная проверка теперь практическая.

Причина простая: SOC-аналитик каждый день работает с трафиком. Разбирает алерты из IDS/IPS (система обнаружения и предотвращения вторжений), смотрит дампы в Wireshark, ищет аномалии. Кандидат, который знает определения, но не отличит нормальный TCP-хендшейк (трёхстороннее рукопожатие: SYN → SYN-ACK → ACK) от SYN-флуда в живом трафике — не готов к первому рабочему дню. По данным Verizon DBIR 2025, 68% подтверждённых утечек данных связаны с человеческим фактором. Нужны люди, которые видят аномалию в потоке данных, а не пересказывают параграф учебника.

Что конкретно оценивают, когда открывают Wireshark на интервью:

• Ориентация в дампе — способность быстро понять масштаб: сколько хостов, какие протоколы, где основной объём трафика
• Знание фильтров — не наизусть, но базовых: по IP, протоколу, флагам TCP
• Вывод из данных — не просто «вижу много SYN-пакетов», а «это похоже на SYN-флуд с адреса X, потому что хендшейки не завершены»
• Умение объяснить находку — SOC-аналитик пишет отчёты. Если не можешь связно описать, что нашёл, ценность анализа стремится к нулю

Практические задачи на собеседовании по сетям: три типовых кейса

Три задачи, которые встречаются на собеседованиях джуна ИБ чаще всего. Не абстрактные «расскажите про TCP», а конкретные сценарии с разбором: что увидишь в дампе, какой фильтр применить, какой ответ ждёт интервьюер и какой заваливает.

Разбор TCP-хендшейка на собеседовании: SYN-флуд в дампе

Интервьюер открывает pcap-файл. «Этот дамп сняли с веб-сервера, который перестал отвечать клиентам. Что произошло?»

Что видно в Wireshark: экран забит пакетами с TCP-флагом SYN (первый шаг хендшейка). SYN-ACK (ответы сервера) — единичные или ноль. ACK (третий шаг, подтверждение от клиента) отсутствует. Адреса источников все разные (часто рандомные), адрес назначения один. Порт назначения — 80 или 443.

Хороший ответ: «Вижу массовую отправку SYN-пакетов на порт 80 сервера 10.0.0.5 с десятков различных IP. Соединения не завершаются — SYN-ACK единичны. Это SYN-флуд: атакующий исчерпывает таблицу полуоткрытых соединений сервера. Тип атаки — DDoS (Distributed Denial of Service — распределённая атака на отказ в обслуживании). Для фильтрации я бы применил tcp.flags.syn == 1 && tcp.flags.ack == 0, чтобы выделить входящие SYN без ответа.»

Провальный ответ: «Тут много пакетов… Наверное, какая-то атака.» Без указания на конкретный механизм интервьюер не понимает, видит ли кандидат разницу между TCP-флагами.

Зачем это злоумышленнику: SYN-флуд — способ вывести веб-сервис из строя. Цель — вымогательство (заплати или сайт лежит) или отвлечение внимания, пока идёт проникновение через другой вектор. По данным IBM X-Force 2025, атаки с использованием действительных учётных данных выросли на 71%. DDoS нередко служит дымовой завесой для кражи данных.

DNS-аномалии в трафике: что ищет интервьюер

«Дамп — 10 минут трафика с рабочей станции сотрудника. Безопасники подозревают утечку данных. Покажи, где.»

На что смотреть: фильтр dns. Ключевой маркер — DNS-запросы с необычно длинными именами: 40–60+ символов вида aGVsbG8gd29ybGQ.exfil.attacker.com. Это DNS-туннелирование (DNS tunneling) — техника передачи данных через DNS-запросы, когда полезная нагрузка кодируется в base64 или hex и помещается в субдомен. Второй маркер — аномально большое количество запросов к одному домену за короткий период. Нормальная рабочая станция генерирует десятки DNS-запросов в минуту; сотни запросов за ту же минуту — красный флаг.

Хороший ответ: «Вижу нетипичные DNS-запросы: длинные субдомены к домену evil.com, похожие на base64-закодированные данные. Это DNS-туннель — данные передаются через DNS, обходя стандартные средства контроля, потому что DNS-трафик обычно не блокируется на файрволе. Для подтверждения проверю Statistics → DNS в Wireshark и посмотрю, идут ли ответы с TXT-записями — они часто используются как обратный канал.»

Зачем это злоумышленнику: DNS-туннель нужен для скрытного вывода данных (exfiltration). Большинство файрволов пропускают DNS без глубокой инспекции. DNS-мониторинг — одна из ключевых задач SOC, и интервьюер проверяет, знаешь ли ты об этом.

HTTP-сессия: восстанавливаем картину утечки

«Восстанови содержимое HTTP-сессии из этого дампа.»

Последовательность: фильтр http.request — видны HTTP-запросы. Находишь POST-запрос к подозрительному URL (например, /upload на внешний IP). Правая кнопка мыши → Follow → TCP Stream — Wireshark восстановит полную сессию: заголовки, тело запроса, ответ сервера.

Что ищет интервьюер: замечаешь ли ты подозрительные детали в заголовках. Content-Type: multipart/form-data в POST на внешний адрес — возможная загрузка файла наружу. Cookie с токеном авторизации, переданный по HTTP (не HTTPS) — утечка учётных данных.

Нюанс с TLS, на котором горят многие. Если трафик идёт по HTTPS, содержимое зашифровано. В Wireshark ты увидишь только TLS-хендшейк: Client Hello → Server Hello → обмен сертификатами. Содержимое недоступно. Кандидат, который честно говорит: «Здесь TLS, вижу SNI (Server Name Indication — поле в TLS Client Hello, где указано доменное имя сервера) и могу определить, к какому домену идёт подключение, но содержимое без ключа шифрования не прочитать» — получает плюс. Кандидат, который делает вид, что читает зашифрованный поток — сразу минус.

Вопросы по TCP/IP на собесе: хорошие и провальные ответы

Теоретические вопросы на собеседовании джуна ИБ по сетям никуда не делись, но формат стал конкретнее. Спрашивают привязку к практике, а не определения.

Типичная ловушка: «Назовите два подуровня канального уровня.» Ответ: LLC (Logical Link Control) и MAC (Media Access Control). Вопрос не критичный, но если ответишь — интервьюер увидит, что подготовка вышла за пределы первой страницы Google.

Ещё одна частая связка: «TCP vs UDP — приведи пример, где разница важна для безопасности.» Сильный кандидат не остановится на «TCP для веба, UDP для видео», а добавит: «SYN-flood эксплуатирует именно механизм TCP-хендшейка. А amplification-атаки через DNS или NTP возможны потому, что UDP не проверяет адрес отправителя — можно подставить IP жертвы в поле source, и ответ улетит ей.»

Фильтры Wireshark для анализа pcap файла на собеседовании

На собеседовании не ждут знания всех display-фильтров Wireshark наизусть. Но базовый набор должен быть на автомате.

tcp.flags.syn == 1 && tcp.flags.ack == 0   # SYN без ACK: сканирование или флуд
tcp.analysis.retransmission                 # повторные передачи: проблемы в сети
dns.qry.name contains "evil"               # поиск по имени в DNS-запросах
http.request.method == "POST"               # POST-запросы: возможная утечка
ip.addr == 10.0.0.5                         # весь трафик конкретного хоста
tcp.stream eq 7                             # конкретная TCP-сессия целиком
tls.handshake.type == 1                     # TLS Client Hello: SNI и домен

Зачем каждый из них: tcp.analysis.retransmission — не всякая аномалия означает атаку, иногда это просто плохой канал, и нужно уметь это определять. dns.qry.name — для поиска обращений к подозрительным доменам. http.request.method == "POST" — для обнаружения выгрузки данных наружу. tls.handshake.type == 1 — чтобы узнать, к каким доменам идут зашифрованные подключения, даже не видя содержимого.

Capture filter и display filter — не одно и то же, и путаница между ними на собеседовании сразу выдаёт кандидата, который не открывал Wireshark руками. Capture filter (формат BPF: tcp port 80) задаётся до начала захвата и ограничивает, какие пакеты попадут в файл. Display filter (tcp.port == 80) работает после захвата и фильтрует отображение. Синтаксис разный.

Помимо фильтров, на собеседовании часто просят описать работу с меню Statistics:

• Conversations — список всех пар IP-адресов и объём трафика между ними. Находишь, кто с кем общается больше всего
• Protocol Hierarchy — какие протоколы присутствуют и в каком соотношении. Аномально высокая доля DNS или ICMP — повод копать глубже
• Endpoints — все адреса в дампе. Внешний IP, которого не должно быть в корпоративном сегменте, сразу бросается в глаза

Анализ pcap файла: делай раз, делай два, делай три

Интервьюер вручил pcap-файл и сказал: «Расскажи, что тут.» Вот алгоритм, который работает на любом дампе. Wireshark установлен (версия 3.x или 4.x; на Linux — sudo apt install wireshark, на Windows — скачать с wireshark.org).

Шаг 1 — Protocol Hierarchy и первичная ориентация

Открываешь файл. Первое действие — не листать пакеты вниз. Идёшь в Statistics → Protocol Hierarchy.

Что ожидать: таблица с процентным распределением протоколов. 95% TCP и 5% UDP — стандартная картина для веб-трафика. 60% DNS при общем объёме 10 000 пакетов — аномалия: DNS не должен занимать такую долю. Большой объём ICMP — возможно, ping-sweep или traceroute.

Далее Statistics → Conversations → вкладка IPv4. Здесь видно, кто с кем общается и сколько данных передал. Пара адресов с аномально большим объёмом — первый кандидат на детальный разбор.

Результат этого шага — ты должен суметь сказать интервьюеру: «В дампе N пакетов за M минут, основной трафик между хостами A и B по протоколу X. DNS-запросов аномально много для такого окна — это первое, что буду разбирать.»

Шаг 2 — фильтрация аномалий

На основе Protocol Hierarchy применяешь display-фильтры. Нашёл подозрительную пару адресов — ip.addr == X.X.X.X. Много DNS — фильтр dns, проверяешь query names на длинные субдомены. Есть HTTP — http.request, ищешь POST-запросы на внешние адреса.

После фильтрации ты видишь конкретные пакеты, формирующие паттерн. SYN без SYN-ACK. DNS-запросы к одному домену с base64-строками в субдоменах. POST-запросы с файлами на внешний IP.

На каждую находку — правый клик → Follow → TCP Stream (или UDP Stream), чтобы увидеть содержимое диалога целиком. Wireshark подсвечивает клиентские данные одним цветом, серверные — другим. Сразу видно, кто что отправил.

Шаг 3 — формулировка выводов для интервьюера

Этот шаг отделяет кандидата с оффером от того, кто «потыкал в Wireshark». Интервьюер ждёт структурированный ответ:

1. Что произошло — тип атаки или инцидента (SYN-флуд, DNS-туннелирование, утечка данных через HTTP)
2. Какие хосты затронуты — конкретные IP-адреса из дампа
3. На основании чего сделан вывод — применённые фильтры, номера пакетов, наблюдаемый паттерн
4. Что делать дальше — заблокировать IP на файрволе, изолировать хост, проверить другие машины в сегменте

Пример: «Обнаружен DNS-туннель: хост 192.168.1.15 отправляет DNS-запросы к домену c2server.evil с base64-данными в субдоменах. За 10 минут — 847 запросов типа A при норме 20–30. Рекомендация: изолировать хост, заблокировать домен на DNS-резолвере, запустить антивирусное сканирование.»

Что заваливает кандидатов: пять ошибок при разборе дампа wireshark на собеседовании

За 40+ интервью я собрал устойчивый список промахов. Одни и те же ошибки, раз за разом.

Ошибка 1 — сразу листать пакеты. Кандидат открывает файл и начинает скроллить сверху вниз. В дампе на 50 000 пакетов это бессмысленно. Первый шаг — Statistics → Protocol Hierarchy, не скроллинг. Интервьюер видит: человек не знает инструмент.

Ошибка 2 — описывать симптомы, а не механизм. «Вижу много пакетов, наверное атака» — это симптом. «SYN-пакеты без завершения хендшейка с 200+ различных IP за 30 секунд — SYN-флуд» — это механизм. Разница между этими ответами — разница между отказом и оффером.

Ошибка 3 — путать capture и display filter. Capture filter (tcp port 80, синтаксис BPF) работает до захвата, display filter (tcp.port == 80, синтаксис Wireshark) — после. Путаница выдаёт: кандидат читал документацию по диагонали и не запускал Wireshark сам.

Ошибка 4 — игнорировать контекст. Интервьюер говорит «дамп с рабочей станции бухгалтера», а в трафике видно Nmap-сканирование — серия SYN на последовательные порты. Это техника Network Service Discovery, T1046 в MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1046 — идентификаторы конкретных техник). T1046 относится к тактике Discovery, то есть к этапу разведки. С машины бухгалтера — инцидент. С машины пентестера — рабочий процесс. Контекст меняет всё.

Ошибка 5 — фантазировать вместо «не знаю». В дампе протокол, который не узнаёшь? Скажи: «Вижу трафик по порту 5222, предполагаю XMPP, но нужно проверить.» Это лучше, чем уверенно назвать неправильный протокол. Интервьюер проверяет способ мышления, а не энциклопедическую память.

Модель OSI на собеседовании: как отвечать через практику

Вопрос про модель OSI никуда не уйдёт. Но ответить через призму Wireshark — ценнее, чем отбарабанить список.

Слабый ответ: «Физический, канальный, сетевой, транспортный, сеансовый, представления, прикладной.» Это можно найти за 10 секунд в Google. Интервьюер не узнал ничего нового о кандидате.

Сильный ответ: «Модель OSI — семь уровней сетевого взаимодействия. На практике я чаще опираюсь на четырёхуровневую TCP/IP (канальный, сетевой, транспортный, прикладной) — она ближе к реальному стеку протоколов. Когда открываю пакет в Wireshark, вижу каждый уровень: Ethernet-кадр (L2) с MAC-адресами, IP-заголовок (L3) с адресами и TTL, TCP-заголовок (L4) с портами и флагами, прикладные данные (L7) — HTTP, DNS. Уровни L5-L6 (сеансовый и представления) в TCP/IP не реализованы отдельно — их функции берут на себя прикладной уровень и библиотеки типа TLS.»

Follow-up: «На каком уровне работает файрвол?» Ответ: зависит от типа. Пакетный фильтр — L3-L4 (IP-адреса и порты). Stateful — L4 (отслеживает состояния TCP-сессий). WAF (Web Application Firewall) — L7 (инспектирует HTTP-запросы). NGFW (Next-Generation Firewall) — L3-L7 одновременно. После такого ответа дополнительных вопросов по теме обычно не следует.

Подготовка к собеседованию network security: план на неделю

Собеседование через неделю — вот приоритеты от самого важного к менее срочному.

День 1–3: разбор дампов в Wireshark. Скачай публичные pcap-файлы с malware-traffic-analysis.net — бесплатный ресурс с дампами реальных инцидентов. Открой каждый и пройди три шага: Protocol Hierarchy → фильтрация → выводы. Повтори на 3–5 разных файлах. Цель — чтобы последовательность действий стала автоматической.

День 3–5: TCP/IP через живой трафик. Не зубри OSI по карточкам. Открой Wireshark, запусти ping google.com и посмотри пакеты: DNS-запрос (прикладной уровень), UDP-датаграмма (транспортный), IP-пакет (сетевой), Ethernet-кадр (канальный). Потом зайди на HTTP-сайт и проследи трёхстороннее рукопожатие TCP: SYN → SYN-ACK → ACK → HTTP GET. Увидеть это живьём — полезнее трёх глав учебника.

День 5–7: атаки в трафике. Разберись, как выглядят SYN-флуд, ARP-spoofing, DNS-туннелирование, сканирование портов. Для последнего в дампе видна серия SYN на последовательные порты одного хоста — фильтр tcp.flags.syn == 1 && tcp.flags.ack == 0 && ip.dst == адрес_цели.

Бонус: tcpdump. На собеседовании могут спросить про анализ трафика без GUI. Базовое: tcpdump -i eth0 -w capture.pcap записывает трафик в файл, tcpdump -r capture.pcap 'tcp port 80' фильтрует при чтении. SOC-аналитик использует tcpdump, когда подключается к серверу по SSH, где графического интерфейса нет — стандартная рабочая ситуация. Кандидат, который знает оба инструмента — Wireshark для глубокого анализа и tcpdump для быстрого захвата на сервере — выглядит заметно сильнее на собеседовании сетевого инженера ИБ.

Из тех 40 интервью оффер получили 11 человек. У девяти из них было одно общее: они не пытались пересказывать учебник. Открывали дамп и начинали работать — методично, без паники, с конкретными выводами. Ни один не знал все фильтры Wireshark наизусть. Зато каждый мог объяснить, зачем он применяет конкретный фильтр и что именно ищет.

Вот что я не встречал в обсуждениях подготовки к собеседованиям: большинство курсов по ИБ до сих пор тратят 80% времени на теорию и 20% на практику. В реальности на техническом интервью пропорция обратная — теорию проверяют за пять минут, остальные 30–40 минут это разбор дампов, кейсы и конкретные ситуации. Если вся подготовка — чтение определений, это подготовка к экзамену в институте, а не к рабочему собеседованию. Моя рекомендация: 70% времени на Wireshark и реальные дампы, 30% — на повторение теории. Если ищешь джуниор-роль и хочешь, чтобы эта пропорция была заложена с первого модуля — IB Basics даёт именно такой формат: практика с инструментами с первого дня, без семестра теории до первой консоли.