Система анализирует параметры HTTPS‑соединения и рассчитывает вероятность того, что запрос отправлен ботом. Если расчетное значение превышает заданный порог, пользователю предлагается дополнительная проверка перед установлением защищенного соединения; при низкой вероятности сессия открывается без дополнительных действий.
Вроде все так делают, не?
Это же буквально базовый алгоритм для антибот/антиддос софта в 2025 году. Смотрят на параметры, если что-то не нравится, показывают капчу ("дополнительная проверка").
Зачем это патентовать, интересно?
Что они собираются с этим патентом делать? Предъявлять Cloudflare или отечественным кибербез-компаниям?
В каких бинарных протоколах есть поле порядковый номер пакета разрядностью минимум 16 бит?
В TCP? Там есть 32-битный sequence number.
В каких бинарных протоколах есть порядковый номер передаваемого пакета?
Иногда в "односторонние" UDP-based протоколы добавляют порядковые номера, чтобы понимать сколько пакетов потерялось. В netflow/ipfix есть sequence number.
Существую ли бинарные протоколы реализованные аппаратно?
Какой-то очень сложный вопрос. Сейчас грань между "программно" и "аппаратно" немного размыта, но вообще сетевой стек (Ethernet, IP и даже TCP/UDP) парсится и модифицируется на многих бытовых сетевых карточках "аппаратно": https://en.wikipedia.org/wiki/TCP_offload_engine
Хотя это старая статья, сейчас даже мало кто говорит "tcp offload", обычно это называют "nic offloads".
Все вроде по-разному. Из того что я читал в открытом доступе или общался с инженерами - у них обычно есть разные продукты (или линейки продуктов) для разного.
Одни продукты анализируют netflow/ipfix/sFlow. Когда видят что-то подозрительное - то или срезают на роутерах (с помощью BGP blackhole/flowspec) или перенаправляют трафик на другие железки для "очистки". Таким способом срезают крупных ботов, которые наливают хорошо трафика и которых видно в семплированном xFlow.
Для "тонкой" очистки - да, как написали вверху, ставят nginx (или реже что-то другое) перед защищаемыми хостами в режиме реверс прокси и на нем уже пытаются бороться.
Есть опенсорные WAF, например https://github.com/bunkerity/bunkerweb - у него как раз nginx под капотом. Если интересно, можно посмотреть как там сделано
Теоретически это можно использовать как инструмент для обнаружения вредоносного и паразитного трафика.
Определять и отсекать ботов, сканеров и прочую малварь.
Но практически ботов часто пишут не дураки, они маскируются под обычный пользовательский трафик и все эти TLS fingerprints/JA4 и т.п. работают так себе.
И для nDPI нужны полные пакеты, то есть нужно снимать трафик с зеркала или стоять в разрыве. Такое могут себе позволить только не очень большие сети.
В более-менее крупных сетях максимум что можно анализировать постоянно - это семплированные кусочки пакетов из sFlow, а на таком эти *DPI не работают.
Более того, у подавляющего большинства операторов нет даже никаких "историй посещения сайтов". Операторов заставляют ставить отдельно коробку с СОРМ, а управляют этой коробкой и берут оттуда данные совершенно другие люди, не операторы.
Обычно вся статистика которая есть у оператора - это семплированный netflow/ipfix. В нем вообще ничего не видно кроме IP адресов, протоколов и портов. При семплировании 1:500 в эту статистику попадет каждый 500-й пакет, а у крупных операторов бывает sampling rate и 1:10000.
То есть "историю поиска" могут дать только поисковики. Ну да, можно увидеть ее в браузере искавшего, но это какой-то уже странный случай.
После этого момента типы-суммы исчезают из императивного программирования. В императивных языках конца XX века доминировало влияние Pascal и C. В Pascal не было типов-сумм, потому что Вирт считал их менее гибкими, чем не размеченные (untagged) объединения.
В C, возможно, нет типов-сумм, потому что его создатели заимствовали систему типов из языка PL/I от IBM
В C тоже можно сделать tagged unions "на коленке", но нужно следить вручную за тегами. В телекомах это вообще такая классика, используется в куче протоколов и есть даже специальный термин TLV (type-length-value / tag-length-value) https://en.wikipedia.org/wiki/Type–length–value
Линейное чтение больших файлов (большими кусками) - да, будет приблизительно одинаково. Если нужно возиться с одними и теми же данными в небольшой области - mmap-решение может быть проще и быстрее.
Но вообще кеширование есть в "обычных" fread/fwrite из libc, размер буфера можно потюнить, непонятно почему сравнивали только сисколы read/write с mmap().
memory maps в основном упрощают жизнь
Да, но с нюансами. read/write при ошибке чтения/записи возвращают эту ошибку, и обычно программист к этому готов. С mmap в таком же случае приложение может получить SIGBUS и упасть. Программист и пользователи обычно к этому не готовы.
Управлять памятью в случае с mmap тоже сложнее. C read/write вы выделяете буфер и с ним работаете, все более-менее предсказуемо. А если вы сделаете в виртуалке с 8Gb памяти mmap на файл 32Gb и начнете его читать в разных местах, то контролировать память становится довольно проблематично. Все будет делать ОС, и иногда довольно непредсказуемо.
Недавно на гитхабе начали переделывать и сломали статистику по трафику репозиториев. Изменили графики посещений и клонирования (в худшую сторону), перестали показывать сайты с которых перешли и популярный контент.
Referring sites and popular content are temporarily unavailable or may not display accurately. We're actively working to resolve the issue.
Не то чтобы это была какая-то суперважная фича, но иногда интересно было посмотреть.
Судя по
Мы попросим команды отложить разработку функций, чтобы сосредоточиться на переносе GitHub.
Насколько я понимаю, Гарда использует (если использует, конечно) поиск аномалий в сетевом трафике. Они же не могут показывать каждую аномалию человеку для валидации, это было бы странновато. Обычно на аномалии нужно очень быстро реагировать.
А вообще интересно, насколько это реально работает с сетевыми аномалиями, что можно детектировать (атаки? сбои оборудования?) и насколько хорошо это получается.
Нам нужно не только визуализировать, а еще и реагировать на сетевые аномалии, DoS/DDoS, причем чем быстрее, тем лучше. Мы используем скользящие средние для детекции аномалий.
И мы обычно на одной инсталляции показываем статистику по разным сетям или объектам мониторинга разным пользователям (т.е. делаем мультитенантность/мультиарендность).
Абсолютно ничего не имею против Акворадо, даже советую его использовать интересующимся пользователям на реддите, но нужно понимать, что он хранит все фловы. Для кого-то это плюс, для кого-то довольно бессмысленно - для того чтобы раз в неделю грубо посмотреть разбивку трафика по своим сетям, GeoIP или AS нужно иметь хорошее такое хранилище. Плюс он вместе с Кафкой не очень легкий:
Akvorado is performant enough to handle 100 000 flows per second with 64 GB of RAM and 24
Да простят меня Настоящие Хайлоадеры, но мы вместо Кафки используем просто файловую систему - нужная статистика складывается в файликах на диск и отдельным процессом экспортируется в PostgreSQL или ClickHouse.
Ну и предобрабатываем данные внутри коллектора. Наверное это тоже неправильно с точки зрения Настоящей Хайлоад Архитектуры, но позволяет обрабатывать до 700k fps на одном vCPU (когда много объектов мониторинга, то меньше, конечно).
Да, к фидбекам и вообще к комментариям "из интернета" нужно относиться с осторожностью.
Сейчас перепроизводство софта, почти всегда можно найти аналог. Если реальным пользователям что-то не нравится, они как правило молча (и без фидбека!) переходят на другой продукт. В интернете часто пишут вообще далекие от предметной области люди, причем с видом экспертов. А эксперты не пишут, им это не очень интересно. Какой-то странный феномен - личное (или даже оффлайновое) общение с реальными пользователями бывает полезнее и интереснее, чем сообщения от анонимных людей "из интернета".
Иногда вижу еще один вид негативных отзывов - от евангелистов ПРАВИЛЬНЫХ технологий. Программа/библиотека написана не на любимом языке программирования - у евангелиста моментально полыхает: "ха-ха, ну сразу же видно какой это глючный отстой, я пользуюсь штукой написанной на Правильном ЯП и всем советую!!1" (штука делает не то что нужно, но кого это смущает). Не используется любимая технология комментатора - "буэ, что за рукожоп это делал вообще, вот смотрите как нужно делать: <рассказ о продукте, который делает вообще другое>".
Очень странное ощущение, когда о тебе пишет нейросеть.
Да, скриншоты она почему-то не смогла.
Хотя, все эти визуализации выглядят более-менее одинаково. Обычно это time series и опционально отчеты за крупные периоды - столбчатые/круговые диаграммы потребителей трафика, генераторов, AS, гео-распределения и т.п.
Вроде почти у всех можно посмотреть и другие поля, типа распределения трафика по TCP-флагам, TTL, IP протоколам, TCP/UDP портам.
Можно заглянуть в каждый из проектов, там будут картинки. Или загуглить что-то вроде netflow reports и посмотреть картинки. Они у всех приблизительно одинаковые, там сложно придумать что-то оригинальное.
Про xenoeye недавно писал на хабре, там есть и скриншот графаны.
Основные отличия между netflow анализаторами как раз не в визуализации, а в другом - может ли анализатор реагировать на аномалии, как у него реализованы объекты мониторинга (если реализованы вообще), если ли возможность разным группам пользователей показывать разные отчеты и т.д.
На момент релиза tkvdb был одним из редких примеров реализации подобного решения на основе Radix.
Кхем. Radix trees тогда уж.
Key-Value на radix trees в памяти были и тогда, есть и сейчас. tkvdb был (и есть) редкий пример реализации с возможностью хранения деревьев на диске в виде append-only структуры и транзакциями (ну, условными).
Так действительно же диковатое заявление, не чувствуете? Хотя, может вы много с AI общаетесь. Про Оперу, кстати, хороший пример. "Компания Opera переходит на движок Chromium и бросает вызов Google" - нормально звучит?
Вроде все так делают, не?
Это же буквально базовый алгоритм для антибот/антиддос софта в 2025 году. Смотрят на параметры, если что-то не нравится, показывают капчу ("дополнительная проверка").
Зачем это патентовать, интересно?
Что они собираются с этим патентом делать? Предъявлять Cloudflare или отечественным кибербез-компаниям?
В смысле? Я бы наоборот считал что задача с подвохом.
Как именно этот список дан?
Если в текстовом виде, нужно ли проверять числа при парсинге?
Что это за числа, в каком они лежат диапазоне?
Сколько этих чисел может быть в списке, нужно ли готовиться к тому что машинные 64-битные переполнятся?
Нужно ли быстро считать эту сумму, может быть собеседующие - аутисты и хотят посмотреть как вы наваливаете SIMD-интринсиков вживую.
В общем, из такой "несложной" задачи можно сделать целый цикл статей на хабре, если захотеть.
В TCP? Там есть 32-битный sequence number.
Иногда в "односторонние" UDP-based протоколы добавляют порядковые номера, чтобы понимать сколько пакетов потерялось. В netflow/ipfix есть sequence number.
Какой-то очень сложный вопрос. Сейчас грань между "программно" и "аппаратно" немного размыта, но вообще сетевой стек (Ethernet, IP и даже TCP/UDP) парсится и модифицируется на многих бытовых сетевых карточках "аппаратно": https://en.wikipedia.org/wiki/TCP_offload_engine
Хотя это старая статья, сейчас даже мало кто говорит "tcp offload", обычно это называют "nic offloads".
Все вроде по-разному. Из того что я читал в открытом доступе или общался с инженерами - у них обычно есть разные продукты (или линейки продуктов) для разного.
Одни продукты анализируют netflow/ipfix/sFlow. Когда видят что-то подозрительное - то или срезают на роутерах (с помощью BGP blackhole/flowspec) или перенаправляют трафик на другие железки для "очистки". Таким способом срезают крупных ботов, которые наливают хорошо трафика и которых видно в семплированном xFlow.
Для "тонкой" очистки - да, как написали вверху, ставят nginx (или реже что-то другое) перед защищаемыми хостами в режиме реверс прокси и на нем уже пытаются бороться.
Есть опенсорные WAF, например https://github.com/bunkerity/bunkerweb - у него как раз nginx под капотом. Если интересно, можно посмотреть как там сделано
Теоретически это можно использовать как инструмент для обнаружения вредоносного и паразитного трафика.
Определять и отсекать ботов, сканеров и прочую малварь.
Но практически ботов часто пишут не дураки, они маскируются под обычный пользовательский трафик и все эти TLS fingerprints/JA4 и т.п. работают так себе.
И для nDPI нужны полные пакеты, то есть нужно снимать трафик с зеркала или стоять в разрыве. Такое могут себе позволить только не очень большие сети.
В более-менее крупных сетях максимум что можно анализировать постоянно - это семплированные кусочки пакетов из sFlow, а на таком эти *DPI не работают.
Более того, у подавляющего большинства операторов нет даже никаких "историй посещения сайтов". Операторов заставляют ставить отдельно коробку с СОРМ, а управляют этой коробкой и берут оттуда данные совершенно другие люди, не операторы.
Обычно вся статистика которая есть у оператора - это семплированный netflow/ipfix. В нем вообще ничего не видно кроме IP адресов, протоколов и портов. При семплировании 1:500 в эту статистику попадет каждый 500-й пакет, а у крупных операторов бывает sampling rate и 1:10000.
То есть "историю поиска" могут дать только поисковики. Ну да, можно увидеть ее в браузере искавшего, но это какой-то уже странный случай.
Не специалист по этому всему, но в Pascal же чуть ли не с рождения были variant records? Википедия считает что это и есть tagged unions https://en.wikipedia.org/wiki/Tagged_union#1970s_&_1980s
В C тоже можно сделать tagged unions "на коленке", но нужно следить вручную за тегами. В телекомах это вообще такая классика, используется в куче протоколов и есть даже специальный термин TLV (type-length-value / tag-length-value) https://en.wikipedia.org/wiki/Type–length–value
Линейное чтение больших файлов (большими кусками) - да, будет приблизительно одинаково. Если нужно возиться с одними и теми же данными в небольшой области - mmap-решение может быть проще и быстрее.
Но вообще кеширование есть в "обычных" fread/fwrite из libc, размер буфера можно потюнить, непонятно почему сравнивали только сисколы read/write с mmap().
Да, но с нюансами. read/write при ошибке чтения/записи возвращают эту ошибку, и обычно программист к этому готов. С mmap в таком же случае приложение может получить SIGBUS и упасть. Программист и пользователи обычно к этому не готовы.
Управлять памятью в случае с mmap тоже сложнее. C read/write вы выделяете буфер и с ним работаете, все более-менее предсказуемо. А если вы сделаете в виртуалке с 8Gb памяти mmap на файл 32Gb и начнете его читать в разных местах, то контролировать память становится довольно проблематично. Все будет делать ОС, и иногда довольно непредсказуемо.
Насколько я понимаю, получаем чей-то эмулятор ZX Spectrum, уже написанный. Робот просто заимствует код.
Сможет ли нейронка написать эмулятор для несуществующей архитектуры?
И вообще, сделать то, чего раньше не существовало?
Я видел со стороны несколько попыток заставить LLM написать нетривиальное, все провальные.
Недавно на гитхабе начали переделывать и сломали статистику по трафику репозиториев. Изменили графики посещений и клонирования (в худшую сторону), перестали показывать сайты с которых перешли и популярный контент.
Не то чтобы это была какая-то суперважная фича, но иногда интересно было посмотреть.
Судя по
можно и не дождаться, когда починят.
Насколько я понимаю, Гарда использует (если использует, конечно) поиск аномалий в сетевом трафике. Они же не могут показывать каждую аномалию человеку для валидации, это было бы странновато. Обычно на аномалии нужно очень быстро реагировать.
А вообще интересно, насколько это реально работает с сетевыми аномалиями, что можно детектировать (атаки? сбои оборудования?) и насколько хорошо это получается.
EDIT: не туда ткнул, это был ответ @mvasilev-ai
Да, аллокации/деаллокации на куче влияют на производительность.
У проекта DPDK есть гайд по написанию высокопроизводительного кода. Не для геймдева, конечно, а для обработки сетевого трафика (там требования к производительности и надежности бывают еще жестче): https://doc.dpdk.org/guides-25.07/prog_guide/writing_efficient_code.html
Это гайд для более "традиционных" Intel/ARM, причем многопроцессорных, но, мне кажется, его интересно почитать даже просто для информации.
Самодельную (но тоже опенсорсную) https://github.com/vmxdev/xenoeye/
Нам нужно не только визуализировать, а еще и реагировать на сетевые аномалии, DoS/DDoS, причем чем быстрее, тем лучше. Мы используем скользящие средние для детекции аномалий.
И мы обычно на одной инсталляции показываем статистику по разным сетям или объектам мониторинга разным пользователям (т.е. делаем мультитенантность/мультиарендность).
Недавно писал статью про наш Netflow/IPFIX/sFlow анализатор: https://habr.com/ru/articles/909132/
Абсолютно ничего не имею против Акворадо, даже советую его использовать интересующимся пользователям на реддите, но нужно понимать, что он хранит все фловы. Для кого-то это плюс, для кого-то довольно бессмысленно - для того чтобы раз в неделю грубо посмотреть разбивку трафика по своим сетям, GeoIP или AS нужно иметь хорошее такое хранилище. Плюс он вместе с Кафкой не очень легкий:
Да простят меня Настоящие Хайлоадеры, но мы вместо Кафки используем просто файловую систему - нужная статистика складывается в файликах на диск и отдельным процессом экспортируется в PostgreSQL или ClickHouse.
Ну и предобрабатываем данные внутри коллектора. Наверное это тоже неправильно с точки зрения Настоящей Хайлоад Архитектуры, но позволяет обрабатывать до 700k fps на одном vCPU (когда много объектов мониторинга, то меньше, конечно).
Одно неловкое движение и пальцы рубит винтом меча.
Можно будет узнавать владельцев таких мечей при рукопожатии. Очень удобно.
Да.
Нет. Когда процессоры Intel перешли на 32 бита, регистры общего назначения расширили до 32 бит. AX -> EAX, BX -> EBX и т.д.
BX не объединяли с AX для получения EAX.
Когда переходили на 64 бита, провернули приблизительно такой же трюк. EAX расширили до RAX, EBX до RBX и т.д.
Какое-то мучительное получилось копирование. Иногда такое делают без промежуточного регистра
push cspop dsИз .com файла можно выйти просто инструкцией ret. Вот объяснение как это работает https://devblogs.microsoft.com/oldnewthing/20200309-00/?p=103547
Да, к фидбекам и вообще к комментариям "из интернета" нужно относиться с осторожностью.
Сейчас перепроизводство софта, почти всегда можно найти аналог. Если реальным пользователям что-то не нравится, они как правило молча (и без фидбека!) переходят на другой продукт.
В интернете часто пишут вообще далекие от предметной области люди, причем с видом экспертов. А эксперты не пишут, им это не очень интересно.
Какой-то странный феномен - личное (или даже оффлайновое) общение с реальными пользователями бывает полезнее и интереснее, чем сообщения от анонимных людей "из интернета".
Иногда вижу еще один вид негативных отзывов - от евангелистов ПРАВИЛЬНЫХ технологий.
Программа/библиотека написана не на любимом языке программирования - у евангелиста моментально полыхает: "ха-ха, ну сразу же видно какой это глючный отстой, я пользуюсь штукой написанной на Правильном ЯП и всем советую!!1" (штука делает не то что нужно, но кого это смущает).
Не используется любимая технология комментатора - "буэ, что за рукожоп это делал вообще, вот смотрите как нужно делать: <рассказ о продукте, который делает вообще другое>".
Очень странное ощущение, когда о тебе пишет нейросеть.
Да, скриншоты она почему-то не смогла.
Хотя, все эти визуализации выглядят более-менее одинаково. Обычно это time series и опционально отчеты за крупные периоды - столбчатые/круговые диаграммы потребителей трафика, генераторов, AS, гео-распределения и т.п.
Вроде почти у всех можно посмотреть и другие поля, типа распределения трафика по TCP-флагам, TTL, IP протоколам, TCP/UDP портам.
Можно заглянуть в каждый из проектов, там будут картинки. Или загуглить что-то вроде netflow reports и посмотреть картинки. Они у всех приблизительно одинаковые, там сложно придумать что-то оригинальное.
Про xenoeye недавно писал на хабре, там есть и скриншот графаны.
https://habrastorage.org/r/w1560/getpro/habr/upload_files/419/b9d/ab3/419b9dab3d98780062b1e2e479da8697.png
Основные отличия между netflow анализаторами как раз не в визуализации, а в другом - может ли анализатор реагировать на аномалии, как у него реализованы объекты мониторинга (если реализованы вообще), если ли возможность разным группам пользователей показывать разные отчеты и т.д.
Кхем. Radix trees тогда уж.
Key-Value на radix trees в памяти были и тогда, есть и сейчас. tkvdb был (и есть) редкий пример реализации с возможностью хранения деревьев на диске в виде append-only структуры и транзакциями (ну, условными).
Так действительно же диковатое заявление, не чувствуете?
Хотя, может вы много с AI общаетесь.
Про Оперу, кстати, хороший пример.
"Компания Opera переходит на движок Chromium и бросает вызов Google" - нормально звучит?
Что за дичь я читаю.