Комментарии 8
ESNI уже переименовали в ECH. И поскорее бы его уже приняли, что ли…
Хорошая тема для поиска IOC-ов в корпоративной сети, но идея с ведением списка «хороших» хэшей для веб-серверов мне кажется труднореализуемой — во-первых, веб-серверов в интернетах много, они появляются и исчезают. Во-вторых, настройки tls у них еще и меняться могут.
Почему это круто:
Пакет приветствия клиента — это первый пакет в любом TLS-соединении. Это позволяет принимать решение о последующих мерах в начале сеанса до того, как потребуется подмена протокола или эмуляция.
Можно захватывать пакеты приветствия клиента TLS с высокой степенью точности по всем портам с абсолютно нулевым требованием для захвата обоих направлений потока. Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов, все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.
Пакеты приветствия клиента возникают достаточно редко, поэтому дополнительная обработка хэшей не повлечет значительных затрат.
Я не понял эти пункты.
решение о последующих мерах в начале сеанса до того, как потребуется подмена протокола или эмуляция— последующие меры чего? Когда подмена и какого протокола (или эмуляция) может потребоваться? Почему нельзя подменить протокол или эмулировать что-то в последствии?
Дальше — совсем не понял.
с высокой степенью точности по всем портам
Что за «точность» подразумевается в захвате трафика? Разве можно его захватывать «не точно»?
с абсолютно нулевым требованием для захвата обоих направлений потока
Т.е. захватывается односторонний трафик «только от клиента к серверу» (под описание трафик «от сервера к клиенту» тоже подходит)? Почему так? Это не совсем «нулевое требование», нужно явным образом запретить принимать одно из направлений, потому что по умолчанию дампятся оба направления.
Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов
Почему в среде с ассиметричной маршрутизацией будет отбрасывание пакетов? Какое дело датчикам до симметрии, это же датчики в работающей среде, а не «только что установленный FW, который не может поддержать statefull-сессию из-за того, что часть трафика мимо него прошла».
все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.
А как приветствие клиента можно спрятать на нестандартном порту? Можно чуть подробнее, пожалуйста?
Датчики с небольшими ресурсами могут собирать пакеты, которые им шлёт клиент, в среде с ассиметричной маршрутизацией, независимо от порта с которого клиент прислал пакет. Так, правильно? У вас именно так написано. Значит ли, что в среде с симметричной маршрутизацией сбор пакетов уже будет зависеть от порта с которого они пришли? Я честно не понимаю что вы имели в виду и как это у вас работает в теории хотя бы.
Пакеты приветствия клиента возникают достаточно редко, поэтому дополнительная обработка хэшей не повлечет значительных затрат.
Вы уже говорили про недостаток ресурсов в предыдущем пункте. Скорее всего это повторение.
— Далее, пример:
Порядок полей следующий
TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats
771,49196-49162-49195-52393-49161-49200-49172-49199-52392-49171-159-57-56-107-158-52394-51-50-103-22-19-157-53-61-156-47-60-10,0-23-65281-10-11-13-28,29-23-24-25,0
TLSVersion=0301=769 — у вас 771
Далее идут 36 CypherSuites (вы их же назвали Ciphers — или куда-то в другое место надо смотреть? Стрелочкой на сьюты показываете), первое со значением 00ff, у вас же 28 значений и нигде нет, как и 00a и далее.
Затем, семь значений Extensions — откуда они получены? На картинке их нет ни по количеству ни по значениям.
Далее у вас EllipticCurves — четыре значения. Откуда они берутся? На картинке этого нет.
EllipticCurvePointFormats — почему значение взято из поля «uncompressed», а не с его родного, где 1?
Дальше не читал, так как бестолку — если с основами не разобрался, дальше ничего будет непонятно.
Похоже, что я единственный кто вашу статью читал. Я сначала думал, что «просто я — тупой», но никто из тех, кому я показал и спросил «а как», мне не смог рассказать, что вы имели ввиду и почему именно так. =) Потрудитесь объяснить, пожалуйста.
— последующие меры чего? Когда подмена и какого протокола (или эмуляция) может потребоваться? Почему нельзя подменить протокол или эмулировать что-то в последствии?
Тут мы имели в виду, что можно осуществлять проактивную реакцию. Например, убирать SSL, заворачивать трафик на определённый прокси, закидывать хост, с которого идёт подозрительная активность, в VLAN, эмулирующий корпоративную сеть, и делать прочие забавные штуки, чтобы потом разобраться, что это была за активность.
Подмена протокола – убрать TLS (да, написали криво).
В последствии всё можно сделать, но не до конца эффективно. Мы встречали малварь, которая запоминала SSL-сертификат сервера, и если был другой, то самоудалялась. С эмуляцией могут быть такие же вещи (на практике не видели, но всё может быть).
Что за «точность» подразумевается в захвате трафика? Разве можно его захватывать «не точно»?
Тут мы имели в виду, что нам всё равно, на каком порту поднято TLS-соединение. TLS-рукопожатие легко детектится на любом порту.
Т.е. захватывается односторонний трафик «только от клиента к серверу» (под описание трафик «от сервера к клиенту» тоже подходит)? Почему так? Это не совсем «нулевое требование», нужно явным образом запретить принимать одно из направлений, потому что по умолчанию дампятся оба направления.
Тут не совсем понятно. Задачи при базовом фингерпринтинге — захватить начало TLS-рукопожатия. Нам не нужно производить глубокий анализ следующих пакетов (как это делают DPI-системы). Про нулевые требования, это мы лихо сказали конечно.
Почему в среде с ассиметричной маршрутизацией будет отбрасывание пакетов? Какое дело датчикам до симметрии, это же датчики в работающей среде, а не «только что установленный FW, который не может поддержать statefull-сессию из-за того, что часть трафика мимо него прошла».
Фраза про отброс пакетов относится к “с ограничениями ресурсов”, и опять повторю, что наша цель — захватить начало TLS-соединения, а дальше при фингерпринтинге нам всё равно, что происходит в сети — идут ли отбросы пакетов, перестроение маршрутов и т.д. Мы свои данные получили (опять сошлюсь на DPI-системы, которые в таких условиях и с частичной информацией работать не будут).
А как приветствие клиента можно спрятать на нестандартном порту? Можно чуть подробнее, пожалуйста?
Именно, что никак!
Датчики с небольшими ресурсами могут собирать пакеты, которые им шлёт клиент, в среде с ассиметричной маршрутизацией, независимо от порта с которого клиент прислал пакет. Так, правильно? У вас именно так написано. Значит ли, что в среде с симметричной маршрутизацией сбор пакетов уже будет зависеть от порта с которого они пришли? Я честно не понимаю что вы имели в виду и как это у вас работает в теории хотя бы.
Клиент — это роутер, датчик — это приёмник трафика по span-порту или аналогу.
Суть — TLS handshake легко получать из зеркалируемого трафика, и его анализ не ресурсозатратен.
Про пример — вы правы. Картинка не имеет никакого отношения к дальнейшим шагам (тут наш косяк, категорически не правы, не вычитали). Для глубокого понимания рекомендую читать оригинальную статью авторов JA3.
В реальной работе мы считаем хэши JA3/JA3S, используя Zeek. Всё теоретическое описание в статье дано для общего понимания. Извиняемся, что ввели в заблуждение.
В последствии всё можно сделать, но не до конца эффективно. Мы встречали малварь, которая запоминала SSL-сертификат сервера, и если был другой, то самоудалялась. С эмуляцией могут быть такие же вещи (на практике не видели, но всё может быть).
Понял. Это не круто, потому что равносильно «круто, если прилетят агрессивные инопланетяне-слоны с хвостами-патчкордами, чувствительными к хендшейкам TLS, мы тогда их смогли бы быстро находить и отправлять им в хвост, изгнав с Земли». Не имеет практической ценности.
Тут мы имели в виду, что нам всё равно, на каком порту поднято TLS-соединение. TLS-рукопожатие легко детектится на любом порту.
Задачи при базовом фингерпринтинге — захватить начало TLS-рукопожатия. Нам не нужно производить глубокий анализ следующих пакетов (как это делают DPI-системы). Про нулевые требования, это мы лихо сказали конечно.
Так любой NGFW точно так же работает, ему не нужно захватывать все остальные пакеты, чтобы понять что перед ним сейчас. Что мешает, в любом TCP-фрейме, который пришёл смотреть сразу в пейлоад и если первый байт равен 16, а следующие два попадают под паттерн версии (например 0301) — определять это как хендшейк и не смотреть на порты в принципе? Ничего. Я не совсем понимаю — чего нового вы предлагаете.
Фраза про отброс пакетов относится к “с ограничениями ресурсов”, и опять повторю, что наша цель — захватить начало TLS-соединения, а дальше при фингерпринтинге нам всё равно, что происходит в сети — идут ли отбросы пакетов, перестроение маршрутов и т.д. Мы свои данные получили (опять сошлюсь на DPI-системы, которые в таких условиях и с частичной информацией работать не будут).
А зачем тогда упоминать про «сети с ассиметричной маршрутизацией», если они не важны?
Именно, что никак!
Вы пишите " независимо от того, были ли они скрыты из-за работы на нестандартных портах."
Если «никак», то какой смысл несёт эта фраза?
Если сенсор — это приёмник SPAN трафика, то каким образом фраза
Круто детектить хендшейки, потому что можно захватывать пакеты приветствия клиента TLS с высокой степенью точности по всем портам с абсолютно нулевым требованием для захвата обоих направлений потока. Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов, все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.
относится к хендшейкам? Круто SPAN использовать — это понятно. Если детектить не SPAN'ом, а чем-то другим, то эта фраза у вас сохранит свою актуальность? Если «да», то зачем вы про SPAN рассказывали в объяснении, если фраза не про него? Если «нет», то это уже не круто, т.к. к теме не имеет отношения.
Третье утверждение содержится во втором, которое «не круто»
Получается три «не круто» из трёх. ;)
Спасибо за разъяснения. Того кто писал не ругайте, а то всю охоту писать отобьёте. Хоть и каша, но если бы технарь хотел писать статьи и понятно излагать свои мысли — пошёл бы на журналиста учиться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование TLS fingerprinting для выявления угроз