Опубликовано: 12.10.2026 | Источник: SecurityLab (RSS)

• Основной поисковый запрос: анализ сетевого трафика в ВКР
• LSI-запросы: VPN-детекция, TLS-фингерпринтинг JA3/JA4, DPI, классификация трафика машинным обучением, модель угроз STRIDE, NetFlow/IPFIX, eBPF, WireGuard, разностная приватность, метрики классификатора
• Вопросы студентов: «Как измерить эффективность модели в дипломе?», «Обязательно ли писать код?», «Где брать датасет сетевого трафика?», «Как оформить ТЗ по ГОСТ 34.602-89?», «Чем обосновать выбор стека, если руководитель просит сравнение?»
• Ключевые сущности: ГОСТ 34.602-89, ISO/IEC 25010, Scapy, nDPI, CICIDS2017, WireGuard, STRIDE, OpenTelemetry

Анализ сетевого трафика в ВКР: от модели угроз до метрик классификатора

Федеральные ведомства годами советуют рядовому пользователю «просто включить VPN» — и именно этот совет стал поводом для разбора, опубликованного 27 марта 2026 года. Суть в том, что массовое использование коммерческих VPN-шлюзов не прячет человека, а наоборот, делает его заметнее: трафик туннеля отличается от обычного по размеру пакетов, таймингам, набору TLS-отпечатков, а сам факт обращения к VPN-сервису в корпоративной или провайдерской сети — это уже аномалия, которую видно на уровне DPI. Чем сильнее сжимается «нормальный» профиль пользователя, тем легче выделить тех, кто от него уклоняется.

Для выпускника ИТ-направления это не новость из мира паранойи, а готовая тема с измеримым результатом: нужно не рассуждать о слежке, а построить классификатор, который отличает VPN-трафик от обычного, оценить его точность и предложить архитектуру, где такая детекция применяется легально — в корпоративном мониторинге, а не в охоте на людей. Ниже — как развернуть эту историю в защищаемую ВКР, какие метрики предъявить комиссии и где чаще всего спотыкаются студенты.

Три темы ВКР, которые вырастают из этого кейса

Тема 1. Классификация VPN-трафика методами машинного обучения

Актуальность. Пока вендоры уверяют, что туннель скрывает содержимое, исследователи показывают: содержимое скрыто, а поведение — нет. Значит, задача «отличить туннель от обычного HTTPS» решается статистическими признаками и это ровно тот материал, который ложится в диплом по ИБ или прикладной информатике.

Цель: разработать и оценить модель бинарной классификации сетевых потоков «VPN / не VPN» на открытом датасете.

Задачи: собрать и очистить датасет потоков; выделить признаки (длины пакетов, межпакетные интервалы, энтропия полезной нагрузки, TLS-отпечаток); обучить и сравнить не менее трёх моделей (логистическая регрессия, случайный лес, градиентный бустинг); оценить качество по F1, precision, recall и ROC-AUC, оформить выводы.

Структура: Глава 1 — обзор методов DPI и классификации трафика, анализ статьи и смежных публикаций. Глава 2 — архитектура конвейера обработки, схема признакового пространства, обоснование выбора моделей. Глава 3 — эксперименты, метрики, оценка вычислительной стоимости инференса.

Тема 2. Система обнаружения аномалий в корпоративной сети на базе NetFlow и eBPF

Актуальность. Если VPN-туннель становится маркером, то корпоративный мониторинг обязан его видеть — но не ради слежки, а ради контроля теневых каналов утечки данных. Здесь статья превращается в обоснование функциональных требований.

Цель: спроектировать систему детекции аномального сетевого поведения с разделением на сбор телеметрии и аналитику.

Задачи: определить источники данных (NetFlow v9/IPFIX, eBPF-пробы); формализовать модель угроз по STRIDE; спроектировать хранилище потоков и правила корреляции; провести нагрузочное тестирование и замерить задержку обнаружения.

Структура: Глава 1 — модели угроз и нормативная база. Глава 2 — компонентная архитектура, диаграммы развёртывания, интеграция с SIEM. Глава 3 — сценарии тестирования, метрики RTO/RPO, расчёт затрат на внедрение.

Тема 3. Оценка устойчивости обфускации туннелей к анализу трафика

Актуальность. Прямое следствие статьи: чем «чище» классический WireGuard или OpenVPN, тем проще их найти. Значит, имеет смысл исследовать, насколько обфускация (маскировка под обычный HTTPS, шейпинг пакетов) снижает точность детектора.

Цель: количественно оценить, как приёмы обфускации влияют на вероятность обнаружения туннеля.

Задачи: собрать тестовый стенд с двумя-тремя вариантами туннелей; зафиксировать единый набор признаков; провести серию замеров до и после обфускации; построить сравнительную таблицу деградации метрик.

Структура: Глава 1 — теория трафик-анализа и разностной приватности. Глава 2 — проектирование стенда, изоляция экспериментов, воспроизводимость. Глава 3 — результаты, оценка погрешности, ограничения исследования.

Аналитическая глава: сравнение решений и обоснование стека

Первая глава ВКР — это место, где студент обычно пишет «рассмотрим популярные технологии» и получает замечание от рецензента. В нашем случае аналитика должна опираться на конкретную развилку из статьи: детектировать на уровне признаков или на уровне содержимого, и какой протокол туннеля при этом считать эталоном.

Сравнение методов удобно свести в таблицу и уже из неё выводить требования к проекту. Комиссия любит, когда выбор стека подтверждён критериями, а не вкусом автора.

Обоснование стека строится вокруг воспроизводимости: Python как язык экспериментов, Scapy или eBPF для съёма трафика, готовый анализатор потоков, хранилище временных рядов. Если в работе используется контейнеризация — это плюс, но только при условии, что в тексте объяснено, зачем именно Docker или Kubernetes в вашем сценарии, а не «потому что модно».

Проектная часть: архитектура конвейера и диаграммы

Вторая глава — это ответ на вопрос «что именно вы спроектировали». Разложите систему на четыре слоя и нарисуйте их явно.

• Сбор. Источники телеметрии: зеркалирование порта, агент на хосте, экспорт NetFlow. В тексте фиксируйте, какие данные не собираются — это снимает вопросы этического характера.
• Обогащение. Расчёт признаков: агрегаты по потоку, TLS-отпечатки, признаки периодичности. Здесь уместна диаграмма последовательности.
• Анализ. Модель или набор правил, порог срабатывания, обработка ложных срабатываний.
• Реагирование. Запись события, уведомление, интеграция с SIEM. Отдельно опишите хранение и срок жизни персональных данных.

Фрагмент расчёта признаков из потока удобно показать кодом — это демонстрирует, что проект не умозрительный:

import numpy as np

def flow_features(sizes, iats):
    """Признаки потока: размеры пакетов и межпакетные интервалы."""
    sizes = np.asarray(sizes, dtype=float)
    iats = np.asarray(iats, dtype=float)
    return {
        "pkt_count": len(sizes),
        "size_mean": sizes.mean(),
        "size_std": sizes.std(),
        "iat_mean": iats.mean() if len(iats) else 0.0,
        "iat_std": iats.std() if len(iats) else 0.0,
        "bytes_per_sec": sizes.sum() / max(iats.sum(), 1e-6),
    }

Не забудьте про документацию: техническое задание по ГОСТ 34.602-89, схема компонентов, схема развёртывания, спецификация интерфейсов. Если времени на всё не хватает, сокращайте объём, но не убирайте структуру — именно по ней комиссия проверяет системность мышления.

Тестирование и метрики: чем доказать работоспособность

Самая частая слабость дипломных проектов — раздел «тестирование», состоящий из одной фразы «система работает корректно». В нашем кейсе есть чем закрыть этот пробел.

Для качества модели используйте стандартный набор: матрица ошибок, precision, recall, F1, ROC-AUC, а также контроль на отложенной выборке и кросс-валидацию. Отдельно покажите цену ошибок — пропуск туннеля и ложное срабатывание стоят бизнесу по-разному, и это хороший повод ввести взвешенную метрику.

Для системы в целом добавьте нефункциональные характеристики по ISO/IEC 25010: производительность (задержка инференса на поток), надёжность (RTO и RPO при отказе узла аналитики), удобство сопровождения. Нагрузочное тестирование опишите сценариями: рост числа потоков в секунду, деградация при потере источника телеметрии, поведение при пиковой нагрузке.

Мониторинг самого решения — тоже часть работы. Метрики снимаются через OpenTelemetry, отображаются в дашборде, алерты настраиваются на отклонение доли аномалий от базовой линии. Это превращает диплом из «скрипта в блокноте» в эксплуатируемый сервис.

Чему вы научитесь на такой теме

• Формализовать модель угроз и выводить из неё функциональные требования, а не наоборот.
• Собирать и размечать датасет сетевого трафика, честно описывать его ограничения.
• Обосновывать выбор протокола, библиотеки и архитектурного решения через измеримые критерии.
• Оформлять техническую документацию по ГОСТ и строить UML-диаграммы, понятные без пояснений.
• Защищать результат цифрами: метрики модели, задержки, стоимость внедрения.

Вопросы, которые задают чаще всего

Нужно ли поднимать собственный стенд или хватит открытого датасета?

Для базового варианта хватит открытого набора потоков, но тогда обязательно опишите его ограничения. Сильный ход — небольшой собственный стенд на две-три виртуальные машины: он даёт свежие данные и позволяет показать методику сбора, что высоко ценится на защите.

Обязательно ли писать код, если специальность не профильная?

Нет, но нужен эквивалент: расчётная модель, формализованные правила корреляции, воспроизводимая методика оценки. Пустой раздел «реализация» без артефактов почти гарантирует снижение оценки. Если с кодом совсем тяжело, сузьте задачу до аналитической части с математическим аппаратом.

Как правильно оформить диаграммы, чтобы их приняли?

Единый нотации на всю работу: компоненты и развёртывание — UML, процессы — BPMN или IDEF0, но не смешивайте их в одном разделе. Каждая диаграмма должна иметь номер, подпись и хотя бы одну ссылку из текста, иначе она выглядит как декорация. И проверьте, что элементы на схеме совпадают с терминами в тексте, — расхождения замечают сразу.

Где брать данные для тестирования и допустимо ли использовать чужой трафик?

Только синтетический или публичный обезличенный трафик плюс записи с собственного стенда. Реальный трафик пользователей без согласия — прямой путь к вопросам этического и правового характера на защите. Если тема тянет на большее, добавьте подраздел о минимизации собираемых данных — это будет плюсом.

Источник: Хочешь защититься от слежки? Следуй советам ФБР — и тебя будут следить еще сильнее (опубликовано 2026-03-27)