tcp_unknown — нераспознанный TCP

Приёмы для TCP-потоков, в которых DPI не смог определить прикладной протокол. Это уровень ниже, чем https: там транспорт уже опознан как TLS и имя хоста нередко видно в самом потоке, а здесь не известно ничего, кроме того, что это TCP. Общий метод классификации, наборы масок и DSL описаны на странице unknown_discovering, и всё, что сказано там, действует и здесь. На этой странице только то, что специфично для TCP.

• Поток отнесён к tcp_unknown. Обрати внимание, что здесь не опознан сам прикладной протокол, а не только сервис поверх него, — это более глубокая степень неизвестности, чем на странице https.
• На узле заметная доля tcp_unknown. Это повод разобраться, можно ли атрибуцировать узел какому-то сервису, потому что большой объём неопознанного трафика на одном адресе редко бывает случайным.
• Если на том же IP и том же серверном порту есть ещё и заметный объём https, начинать нужно не отсюда, а со страницы https. Там доступна SNI-«земля», и полученный по ней вывод затем переносится на tcp_unknown того же узла — это гораздо надёжнее, чем разбирать tcp_unknown изолированно.

Алгоритм на странице unknown_discovering строит «землю» из тех записей на изучаемом IP, где поле Host не пустое, и затем переносит полученный вывод на записи того же IP, где Host пуст. В tcp_unknown поля Host нет вообще: DPI не разобрал прикладной протокол, а значит и не извлёк оттуда имя. Поэтому шаг 2 общего алгоритма в исходном виде здесь неприменим, и «землю» приходится собирать из двух других источников — из соседних прикладных протоколов, живущих на том же серверном IP, и из данных DNS по этому IP.

Из этого следует важное практическое ограничение: метка, полученная на уровне tcp_unknown, по своей природе менее достоверна, чем метка, полученная по SNI. Указывай в выводе, что он сделан без «земли» по имени хоста, и на каких именно косвенных признаках держится.

• Потоки, в которых полезные данные не передавались, нельзя интерпретировать как профиль трафика. Keepalive, отвергнутые соединения, повторные попытки клиента и сканирование оставляют полноценную запись в netflow, но не говорят ничего о том, какой сервис работает на узле. Такие записи нужно отсеивать до того, как считается любая доля или строится любое распределение, иначе они разбавят картину и сдвинут её в сторону шума.
• Проверяй, виден ли в выгрузке handshake, то есть началась ли сессия у нас на глазах. Если SYN нет, а поток при этом длинный и объёмный, значит DPI подхватил уже установленное соединение: начало сессии прошло мимо точки съёма, а опознание протокола делается именно по началу. Отсутствие метки протокола в этом случае объясняется точкой съёма, а не природой трафика, и считать такой поток признаком нового неизвестного сервиса нельзя. Правильный ход — искать сессию, записанную в дамп целиком, от SYN, и разбирать её.
• Обращай внимание на асимметрию объёма входящего и исходящего трафика, и считай объём по каждому направлению отдельно, а не по сумме. Сильный перекос в сторону клиента означает, что узел раздаёт контент — это загрузка, стриминг, обновления. Близкие объёмы в обе стороны говорят скорее об интерактивном обмене, туннеле или синхронизации, где обе стороны отправляют сопоставимо много.
• Серверный порт выводи из направления потока так же, как это описано на шаге 2 общего алгоритма: если Host IP совпадает с Source IPv4, то серверный порт — это Source port, иначе Destination port. Прямой фильтр по Destination port отрежет примерно половину трафика, потому что в двунаправленном флоу серверный порт попадает то в источник, то в назначение.
• Нестандартный серверный порт — это гипотеза, а не вывод. Порт выбирает владелец сервиса, и совпадение с портом какого-то известного приложения ничего не доказывает, равно как и несовпадение ничего не опровергает.

Посмотри, какие прикладные протоколы присутствуют на том же серверном IP. На уровне tcp_unknown окружение — это основной источник признаков, а не вспомогательный, потому что других внутренних данных о потоке почти нет.

• Наличие рядом распознанного трафика, уже отнесённого к какому-то сервису, — это подсказка, а не итог. На одном узле может жить несколько сервисов одновременно, а само распознавание может быть ошибочным, поэтому заканчивать анализ на этом этапе нельзя.
• Отсутствие рядом чего-либо распознанного тоже не является выводом. Имя хоста может быть видно в других потоках, но не отнесено ни к одному прикладному протоколу, и тогда узел выглядит пустым, хотя данные по нему есть.
• Отдельно проверь, есть ли на этом узле https и на каком порту он живёт. Если https и tcp_unknown сидят на одном и том же серверном порту, перенос вывода с https на tcp_unknown обоснован. Если порты разные, это, скорее всего, разные службы на одном адресе, и переносить вывод нельзя.

Выгрузка может оказаться агрегированной — например, распределение прикладных протоколов на узле или топ узлов по протоколу, без детализации до отдельных потоков. Работай с тем, что есть, а если агрегата для вывода не хватает, запрашивай сырой лог по конкретному узлу. Учитывай, что почти все признаки из раздела о транспортном уровне — handshake, асимметрия направлений, потоки без данных — по агрегату не проверяются вообще, для них сырой netflow обязателен.

Состав выгрузки меняется со временем, поэтому по одной выгрузке нельзя фиксировать перечень узлов как окончательный.

В tcp_unknown имени хоста в потоке нет, поэтому DNS остаётся единственным внутренним источником имени. Сопоставление ведётся по IP хоста и по близости во времени: ищем DNS-ответ, вернувший этот IP незадолго до начала потока.

• Связь между DNS-ответом и потоком не жёсткая, поэтому любое совпадение остаётся гипотезой, а не установленным фактом. Клиент мог получить адрес из кеша задолго до наблюдаемого окна, а один и тот же IP может отдаваться по многим разным именам.
• Часто по узлу в DNS нет вообще ничего, и это нормально. Пустой DNS не говорит ничего ни за, ни против какого-либо сервиса.

Владелец адресного блока, номер автономной системы, обратная зона DNS и публично заявленные диапазоны сервиса важны всегда. На уровне tcp_unknown их вес выше, чем на странице https, именно потому что внутренних признаков здесь меньше и опираться больше не на что.

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

Формулируй намерение, а не форму таблицы: какой срез нужен, за какой период и что в нём должно быть видно.

1. Узлы с наибольшим объёмом tcp_unknown за период.
2. Распределение прикладных протоколов на конкретном узле, обязательно с указанием портов.
3. Сырой netflow по узлу, в котором есть число пакетов и объём отдельно по каждому направлению, длительность потока и, если система их отдаёт, флаги TCP. Без этих полей ни один признак транспортного уровня с этой страницы проверить не получится.
4. Имена хостов, связанные с этим узлом, включая данные DNS.
5. Тот же самый срез за другой период времени, чтобы отделить устойчивую картину от особенностей одного окна.

• Отсутствие имени хоста может быть свойством выгрузки и выбранного периода, а не свойством сервиса. Прежде чем делать вывод из пустого поля, проверь, а бывает ли оно заполненным на этом узле в других окнах.
• Отсутствие SYN — это свойство точки съёма, а не свойство трафика. Не строй на нём выводов о протоколе или сервисе.
• Одно TCP-соединение может нести обращения к разным ресурсам, тем более при keep-alive и мультиплексировании. Поэтому весь объём потока не стоит целиком относить к одному сервису, даже когда имя хоста известно.
• Захват пакетов — крайняя мера. Он оправдан только тогда, когда одновременно выполняются два условия: есть явный повод разбирать именно этот узел и вывод без просмотра полезной нагрузки недостижим.

• unknown_discovering — общий метод, наборы, DSL
• https — уровень выше: TLS опознан, имя хоста может быть видно
• udp_unknown — то же самое для UDP