Защитный модуль LKRG теперь совместим с ядрами Linux ветки 6.1

Защитный модуль LKRG теперь совместим с ядрами Linux ветки 6.1

Защитный модуль LKRG теперь совместим с ядрами Linux ветки 6.1

Анонсирован выпуск LKRG 1.0.0 — новой сборки защитника Linux от нарушения целостности ядра и попыток эксплуатации уязвимостей. Обновление для модуля с множеством существенных изменений доступно на сайте lkrg.org.

Напомним, код LKRG распространяется под лицензией GPLv2. В анонсе, разосланном по подписке Openwall, разработчики пишут, что семилетний проект с новым выпуском достиг возраста зрелости.

Они также отметили, что базовый код защитного модуля ядра стал компактнее, в него внесено множество изменений. Наиболее примечательны следующие:

  • обеспечена совместимость с новейшими ядрами основной ветви Linux (протестировано до 6.17-rc4, на котором будет работать Fedora 44, включительно);
  • в обеспечение поддержки ядер 6.13+ сняты хуки с функций override_creds() и revert_creds(); возникшее в результате ограничение детекта атак перезаписью указателя cred компенсировано добавлением проверок переопределения cred в других местах ядра;
  • снято отслеживание учеток, не проверяемых на подлинность (за счет этого код сокращен примерно на 1500 строк);
  • добавлена поддержка OverlayFS ovl_tmpfile, введенного в ядрах Linux 6.10 – 6.12 во избежание ложноположительных срабатываний;
  • для систем с архитектурой x86_64 реализована поддержка защиты Intel CET IBT и kCFI.

Участники проекта также пофиксили шесть новых багов, повысили быстродействие и стабильность работы ряда функций.

Пакеты Rocky Linux SIG/Security (в состав входит LKRG), используемые и с другими дистрибутивами корпоративного класса (AlmaLinux 8 и 9, RHEL 8/9 и проч.), уже обновлены и скоро будут выложены в паблик.

DPI видит даже сквозь шифрование, разработчики придумали ответ

«Но ведь трафик зашифрован!» — звучит убедительно, но современный DPI на такое только усмехнётся. Как рассказал пользователь Хабра dmitry__ilyin, классификатору необязательно читать пакеты: достаточно посмотреть на их размеры, направление, интервалы, TLS-рукопожатие и общий рисунок соединения.

OpenVPN, например, выдаёт себя характерным хендшейком, а WireGuard — фиксированными размерами некоторых служебных сообщений.

Даже протокол, притворяющийся обычным TLS, можно раскусить, если после красивого ClientHello он ведёт себя совсем не как браузер.

Команда автора разрабатывает туннельную инфраструктуру, устойчивую к DPI, и решила портить классификаторам жизнь сразу по нескольким направлениям. Клиент с помощью uTLS копирует ClientHello настоящих Chrome, Firefox, Edge и Safari, чередуя варианты между соединениями.

Транспорт работает поверх HTTP/2, а параллельно клиент отправляет реальные запросы к CDN, чтобы сделать общую сетевую активность менее однозначной.

Дополняет картину pacing — сглаживание всплесков передачи, которое мешает анализировать временной рисунок потока. А любители активного прощупывания серверов получают унылый и ни к чему не обязывающий код 404.

Магии, впрочем, не случилось. Дополнительная маскировка прибавляет примерно 40–80 мс задержки, а decoy-трафик заметно нагружает процессор клиента. Наблюдения проводились в сетях Ростелекома, Билайна, Мегафона, МТС, Теле2 и Дом.ру, но автор честно предупреждает: это полевые данные, а не лабораторный бенчмарк против конкретных DPI-систем.

Цель проекта — не сделать трафик невидимым, а лишить DPI простых и стабильных признаков. Часть разработки уже открыта — SDK, протокол обфускации и decoy-логику можно изучить на GitHub.

RSS: Новости на портале Anti-Malware.ru