Классификация сетевого трафика по CIA-триаде: разбор pcap на границе инцидента

На третьей неделе дежурств в SOC я получил алерт: всплеск DNS-запросов к несуществующим поддоменам в 3 часа ночи. Открыл pcap в Wireshark — 4200 запросов за 12 минут к случайным поддоменам одного домена, интервал ровно 2.8 секунды. И вот тут повисает вопрос, от которого зависит всё дальнейшее: это нарушение конфиденциальности (данные утекают через DNS-туннель) или доступности (DNS-сервер скоро ляжет от нагрузки)? Ответ определяет — передаёшь ты тикет на L2 как инцидент или закрываешь как шум. Классификация сетевого трафика по CIA-триаде превращает «вижу что-то странное» в структурированный вердикт. Без неё ты гадаешь. С ней — принимаешь решение.

CIA-триада в кибербезопасности: что реально видно в сетевом трафике

CIA-триада — три свойства, которые защищает информационная безопасность: конфиденциальность (Confidentiality — данные видят только те, кому разрешено), целостность (Integrity — данные не изменены без ведома владельца) и доступность (Availability — система работает, когда нужна). Русскоязычные материалы обычно объясняют модель через абстракции: «шифрование обеспечивает конфиденциальность», «хеш-функции гарантируют целостность». SOC-аналитик работает не с абстракциями, а с пакетами — и каждое нарушение C, I или A выглядит в трафике по-своему.

Конфиденциальность в pcap — открытые пароли в HTTP Basic Auth, FTP-сессии с учётными данными в плейнтексте, DNS-запросы с закодированными фрагментами выгружаемых данных. Целостность — ARP-ответы с подменённым MAC-адресом, модифицированные DNS-ответы, перенаправляющие на фишинговый IP. Доступность — SYN-пакеты без ACK-ответа, прилетающие тысячами в секунду с разных адресов.

С такой привязкой каждый пакет перестаёт быть строкой из колонок Source/Destination/Protocol и становится индикатором конкретного нарушения. NIST Cybersecurity Framework (CSF v2.0), подкатегория DE.AE-01, прямо требует: базовая линия сетевых операций и ожидаемых потоков данных должна быть установлена и управляться. Без понимания CIA в контексте трафика эту базовую линию не построить.

Анализ pcap файлов: конфиденциальность под микроскопом Wireshark

Нарушение конфиденциальности данных в сетевом трафике — любая ситуация, когда чувствительная информация передаётся так, что её может перехватить третья сторона. В MITRE ATT&CK (открытая база тактик и техник атак; SOC-команды используют её для классификации действий злоумышленников, а T-коды вроде T1040 — идентификаторы конкретных техник) сюда попадают сразу несколько техник.

Открытые учётные данные и незашифрованные протоколы

Самый частый случай — учётные данные, летящие по сети открытым текстом. HTTP Basic Authentication, FTP, Telnet, SNMPv1/v2. По данным CyberDefenders, NTA (Network Traffic Analysis — мониторинг сетевого трафика для обнаружения аномалий) пассивно выявляет устройства с опасными незашифрованными протоколами: Telnet передаёт пароли и CLI-команды в плейнтексте, SNMPv1 на портах 161/162 раскрывает community strings вообще без защиты.

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

• http.authorization — HTTP-запросы с заголовком Authorization, где логин и пароль закодированы в Base64 (раскодируется за секунду — это не шифрование, а просто кодировка)
• ftp.request.command == "PASS" — FTP-пакеты с паролем в открытом виде
• telnet — весь Telnet-трафик, включая ввод учётных данных

Техника Network Sniffing (T1040, тактики Credential Access и Discovery) описывает именно этот вектор: злоумышленник перехватывает сетевой трафик для извлечения учётных данных. Если в pcap-дампе есть пакеты с открытыми паролями на продакшн-сервере — это подтверждённое нарушение конфиденциальности. Не «потенциальный риск», а факт.

Масштаб проблемы виден на крупных инцидентах. Компрометация LinkedIn — 164 миллиона учётных записей: email и пароли. Утечка данных START — 7.4 миллиона записей с email, геолокациями и паролями. Каждая такая утечка начинается с того, что данные оказываются доступны не тому, кому предназначены. Перехват незашифрованного трафика — один из простейших способов это сделать.

DNS-туннелирование и скрытая эксфильтрация данных

DNS-туннелирование — техника, при которой атакующий кодирует данные в DNS-запросах к подконтрольному домену. Зачем? DNS-трафик почти никогда не блокируют файрволом, и он редко попадает под пристальное внимание. Идеальный скрытый канал. В MITRE ATT&CK это DNS (T1071.004, тактика Command and Control) и Exfiltration Over C2 Channel (T1041, тактика Exfiltration).

Как это выглядит в pcap: хост отправляет DNS-запросы к поддоменам вида aGVsbG8gd29ybGQ.evil-domain.com. Строка перед первой точкой — данные в Base64. Нормальный DNS-запрос содержит поддомен длиной 4–15 символов (mail.google.com). Туннельный — 50–60 случайных на вид символов.

Фильтр dns.qry.name.len > 50 покажет DNS-запросы с подозрительно длинными именами. Дополнительный маркер — периодичность: запросы с фиксированным интервалом 2–3 секунды характерны для автоматического канала, а не для человека за клавиатурой. Именно такой паттерн я увидел в том ночном алерте: фиксированный интервал + длинные поддомены + неизвестный домен = эксфильтрация, нарушение C.

Ещё один вариант утечки — Exfiltration Over Unencrypted Non-C2 Protocol (T1048.003): данные уходят через легитимные протоколы (FTP, HTTP) на внешний сервер. В трафике это аномально большой объём исходящих данных на нетипичный IP-адрес. Фильтр: ip.dst != 10.0.0.0/8 && frame.len > 1000 — большие пакеты на внешние адреса, дальше ручной анализ содержимого.

Целостность в трафике: анализ сетевых атак Wireshark

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

Классический пример — ARP-спуфинг. ARP (Address Resolution Protocol) связывает IP-адреса с MAC-адресами в локальной сети. Атакующий рассылает поддельные ARP-ответы, убеждая хосты, что его MAC-адрес принадлежит шлюзу. Весь трафик идёт через атакующего — он может читать и модифицировать данные на лету. Это man-in-the-middle в чистом виде.

В Wireshark ARP-спуфинг обнаруживается через фильтр arp.opcode == 2 (все ARP-ответы). Если два разных IP-адреса резолвятся в один MAC — аномалия. Обращай внимание на Gratuitous ARP — незапрошенные ARP-ответы, которые хост рассылает без запроса. Wireshark умеет автоматически подсвечивать дублирующиеся маппинги через Expert Info (Analyze → Expert Information): записи с severity Warning и пометкой «Duplicate IP address» указывают на возможную подмену.

Другой вектор — подмена DNS-ответов. Атакующий перехватывает DNS-запрос и отвечает быстрее легитимного сервера, подставляя IP фишинговой страницы. В pcap это выглядит как два DNS-ответа на один Transaction ID от разных IP: первый (поддельный) приходит на миллисекунды раньше второго (настоящего). Фильтр dns.flags.response == 1 покажет все DNS-ответы, дальше — ручной анализ дублей.

OWASP A08:2021 (Software and Data Integrity Failures) описывает аналогичный принцип на уровне приложений: код и инфраструктура не защищены от нарушений целостности. В сетевом контексте это значит — если источник и неизменность данных в транзите не верифицируются, целостность под угрозой.

Доступность: выявление DoS-паттернов при мониторинге сетевого трафика

Нарушение доступности — система перестаёт обслуживать легитимных пользователей. В трафике это обычно самый заметный тип аномалии: объём пакетов резко растёт, и не заметить его сложно. Сложно — правильно классифицировать.

SYN-флуд — классика. Атакующий отправляет тысячи TCP SYN-пакетов (запросы на установку соединения) без завершения тройного рукопожатия (SYN → SYN-ACK → ACK). Сервер тратит ресурсы на полуоткрытые соединения и перестаёт принимать новые. В MITRE ATT&CK это OS Exhaustion Flood (T1499.001, тактика Impact).

Wireshark-фильтр: tcp.flags.syn == 1 && tcp.flags.ack == 0 — показывает только SYN-пакеты без ACK. Если таких пакетов сотни в секунду с разных source IP на один destination — SYN-флуд. Чтобы оценить масштаб: Statistics → I/O Graphs с этим фильтром покажет всплеск на временной шкале.

Второй паттерн — DNS-амплификация. Атакующий отправляет DNS-запросы с подменённым source IP (IP жертвы) на открытые DNS-резолверы. Резолверы отвечают жертве объёмными ответами. Красота атаки (с точки зрения атакующего) — коэффициент усиления: запрос 60 байт, ответ 4000 байт. Со стороны жертвы в pcap это поток входящих DNS-ответов, которых никто не запрашивал. Фильтр dns.flags.response == 1 в сочетании с Statistics → Conversations покажет аномальный входящий DNS.

По данным CyberDefenders, WannaCry сканировал сети на наличие TCP-порта 445 (SMB) и эксплуатировал уязвимость SMBv1 для распространения. NTA выявил бы сканирование (Network Service Discovery, T1046, тактика Discovery) до начала шифрования файлов. Ransomware — пересечение доступности и целостности: шифрует данные (нарушение I) и делает системы неработоспособными (нарушение A). Это важный момент: одна атака может нарушать сразу несколько компонентов CIA.

Разбор pcap на инциденты: пошаговая классификация по CIA триаде

Теория — хорошо. Теперь — практика. Допустим, ты получил pcap после срабатывания IDS (Intrusion Detection System — система обнаружения вторжений, генерирующая алерты при подозрительной активности). Задача: классифицировать находки по CIA и решить — инцидент или шум.

Что нужно: Wireshark (входит в Kali Linux, доступен для Windows/macOS с wireshark.org). Pcap-файл от IDS, сетевого тапа или зеркалирования порта на коммутаторе.

Шаг 1 — первичная разведка трафика

Открой pcap в Wireshark. Первое — статистика протоколов: Statistics → Protocol Hierarchy. Отчёт покажет, какие протоколы присутствуют и какой процент трафика они занимают. HTTP 80% — нормально для веб-сервера. DNS 60% — повод разбираться.

Затем — Statistics → Conversations. Здесь видны пары хостов и объём переданных данных. Аномалия: внутренний хост передал 500 МБ на незнакомый внешний IP за ночь — потенциальная эксфильтрация (C-нарушение).

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

Шаг 2 — маркировка по компонентам CIA

Проходишь по ключевым фильтрам и фиксируешь находки:

# Конфиденциальность (C)
http.authorization            — открытые учётные данные
ftp.request.command == "PASS" — FTP-пароли
dns.qry.name.len > 50        — возможный DNS-туннель

# Целостность (I)
arp.opcode == 2               — ARP-ответы (ищем дубли MAC)

# Доступность (A)
tcp.flags.syn==1 && tcp.flags.ack==0  — SYN без ACK (флуд)

Каждый фильтр применяешь поочерёдно. Если возвращает результаты — записываешь: какие хосты, объём, временной диапазон. Wireshark позволяет помечать пакеты цветом через View → Coloring Rules — я назначаю красный для C-нарушений, жёлтый для I, синий для A. Визуально сразу видно, с чем имеешь дело.

На выходе — список находок с привязкой к C, I или A. Пример записи: «Хост 192.168.1.45 отправил 3200 DNS-запросов с длиной > 50 символов на домен x8f2k.net за 20 минут — классификация: C (возможная эксфильтрация через DNS-туннель)».

Шаг 3 — решение: инцидент или шум

Не каждая аномалия — инцидент. Ключевые факторы:

DNS-запросы к длинным поддоменам с фиксированным интервалом на неизвестный домен ночью — инцидент C-класса. Единичный SYN-пакет на закрытый порт — discovery-фаза, фиксируешь, но пока не эскалируешь.

Маппинг техник MITRE ATT&CK на конфиденциальность, целостность, доступность

Привязка техник из MITRE ATT&CK к компонентам CIA стандартизирует классификацию и упрощает коммуникацию с L2/L3. Когда ты пишешь в тикете «T1071.004, нарушение C» — старший аналитик сразу понимает, о чём речь, без пересказа. Маппинг для техник, которые чаще всего видны в сетевом трафике:

Network Service Discovery (T1046) — особый случай. Сканирование портов не нарушает C, I или A напрямую, но это reconnaissance-фаза перед атакой на любой компонент. В SOC такой трафик фиксируется с пониженным приоритетом эскалации. Не игнорируется — но и не поднимает тревогу уровня «всё бросай».

Граница инцидента безопасности: где проходит черта между шумом и атакой

Главный вопрос L1-аналитика (первая линия SOC, которая разгребает поток алертов) к тимлиду: «Это инцидент или ложное срабатывание?» Ответ строится на пересечении трёх факторов.

Подтверждённое нарушение CIA. Не «что-то странное», а конкретное: «учётные данные передаются открытым текстом» (C), «ARP-таблица содержит дублирующиеся маппинги для шлюза» (I), «SYN-пакетов 50 000 в минуту» (A). Если находка не классифицируется по C, I или A — это аномалия, но не инцидент.

Воздействие на актив. Незашифрованный Telnet к тестовому серверу без чувствительных данных — уязвимость, но не инцидент. Тот же Telnet к продакшн-серверу с клиентской базой — инцидент C-класса. Контекст определяет критичность.

Умысел или неосторожность. SYN-флуд с тысяч IP на один сервер — целенаправленная атака на доступность. Всплеск легитимного трафика из-за маркетинговой рассылки — не инцидент, хотя симптомы похожи. В pcap отличие видно по разнообразию source IP и заголовков: реальные пользователи генерируют разнообразный трафик, ботнет — однотипный.

OWASP A09:2021 (Security Logging and Monitoring Failures) напоминает: без адекватного мониторинга утечки невозможно обнаружить. Анализ pcap файлов с классификацией по CIA — один из базовых инструментов для закрытия этого разрыва. Не единственный (есть SIEM, NDR, EDR), но доступный каждому аналитику с установленным Wireshark.

По опыту разбора алертов, 70% времени SOC-аналитика первой линии уходит не на обнаружение аномалий, а на их классификацию: «что именно произошло» и «насколько это критично». CIA-триада — не академическая модель из учебника по CompTIA Security+. Это рабочий фреймворк, который превращает поток пакетов в структурированный отчёт, понятный тимлиду и заказчику.

Я до сих пор начинаю каждый разбор pcap с трёх фильтров — по одному на C, I и A. Все три чисты — закрываю алерт. Хотя бы один возвращает результаты — маркирую, копаю, эскалирую.

Одна вещь, которую не пишут в руководствах: граница инцидента — не техническая линия. Это решение аналитика, основанное на контексте. Два одинаковых pcap с одинаковыми SYN-пакетами могут быть инцидентом в одном случае и нормой в другом — зависит от того, какой актив стоит за IP-адресом. Научиться принимать это решение можно только разбирая дампы — реальные и учебные — пока классификация не станет автоматической. На IB Basics показывают, что делать в первый месяц после «хочу в ИБ», включая эту самую практику разбора алертов, с которой начинается работа в любом SOC.