Вышла утилита RKN Block Checker для диагностики блокировок

Вышла утилита RKN Block Checker для диагностики блокировок

Вышла утилита RKN Block Checker для диагностики блокировок

Разработчик Дмитрий Виноградов представил утилиту RKN Block Checker с открытым исходным кодом. Она помогает понять, почему конкретный сайт не открывается: это обычная сетевая проблема или блокировка на стороне провайдера / регуляторной инфраструктуры.

Проект написан на Python и опубликован под лицензией MIT. Утилита работает из командной строки и проверяет соединение по цепочке DNS → TCP → TLS → HTTP.

Идея простая: не просто выдать вердикт, что сайт недоступен, а показать, на каком именно уровне всё сломалось. Например, если системный DNS не даёт нормальный ответ, а Cloudflare DoH возвращает корректный адрес, это может указывать на DNS-подмену. Если TCP-соединение на 443-й порт сбрасывается, речь может идти о блокировке на уровне IP.

Если TCP проходит, но соединение рвётся на TLS-рукопожатии с SNI, это уже похоже на работу DPI / ТСПУ. А если сайт открывается, но вместо страницы приходит заглушка провайдера или код 451, утилита фиксирует и такой сценарий.

 

Автор отдельно подчёркивает, что смысл RKN Block Checker не в том, чтобы заменить браузер. Браузер и так сообщает, что сайт не открылся. Здесь задача другая — разложить проблему по слоям и дать пользователю более понятную картину, где именно произошёл сбой и на что это похоже.

Утилита сравнивает ответы системного DNS и DNS over HTTPS через Cloudflare, проверяет обычное TCP-подключение, запускает TLS-handshake с SNI целевого домена и затем делает HTTP-запрос. Вердикт выставляется по первому уровню, на котором возникла ошибка.

 

У проекта есть и ограничения. Пока поддерживается только IPv4. Списки целей жёстко заданы в коде и включают около 20 сайтов на категорию, поэтому инструмент не поймает все частные случаи. Кроме того, это разовая проверка без повторов и долгосрочного мониторинга, хотя JSON-вывод можно использовать в cron для регулярных запусков.

Linux-руткит для разработчиков: Quasar крадёт ключи и токены

Исследователи из Trend Micro обнаружили ранее неизвестный Linux-вредонос Quasar Linux (QLNX). По словам экспертов, зловред нацелен на системы разработчиков и DevOps-среды, а также сочетает в себе функции руткита, бэкдора и способен перехватывать учётные данные.

Главная опасность QLNX в том, что он бьёт не просто по отдельным рабочим станциям, а по окружениям, где живут ключи, токены и доступы к инфраструктуре разработки.

Операторов интересуют npm, PyPI, GitHub, AWS, Docker и Kubernetes, что может открыть прямой путь к атакам на цепочки поставок софта.

По данным Trend Micro, после попадания в систему QLNX старается закрепиться максимально незаметно. Он работает в памяти, удаляет исходный бинарный файл с диска, чистит логи, подменяет имена процессов и убирает следы из переменных окружения, которые могли бы помочь при расследовании.

 

Для устойчивости имплант использует сразу несколько механизмов закрепления: LD_PRELOAD, systemd, crontab, init.d-скрипты, XDG autostart и внедрение в .bashrc. Если один способ не сработает или процесс завершат, у вредоносной программы остаются другие варианты вернуться.

Отдельно исследователи выделяют руткит-составляющую QLNX. Она работает на двух уровнях: через userland LD_PRELOAD и через eBPF-компонент на уровне ядра. Это позволяет скрывать процессы, файлы, сетевые порты и другие следы активности. Причём часть компонентов QLNX динамически компилирует прямо на заражённой машине с помощью gcc.

 

Функциональность у вредоноса внушительная. Он может открывать удалённую оболочку, управлять файлами и процессами, перехватывать учётные данные, собирать SSH-ключи, данные браузеров, облачные и developer-конфиги, содержимое /etc/shadow и буфера обмена. Есть также кейлоггер, снятие скриншотов, мониторинг файловой системы, SOCKS-прокси, TCP-туннелирование, сканирование портов и инструменты для перемещения по сети через SSH.

Trend Micro пока не раскрывает данные о конкретных атаках и не связывает QLNX с определённой группировкой. Масштаб распространения тоже остаётся неясным. На момент публикации зловред детектировали только четыре защитных продукты, поэтому риск незаметного присутствия в инфраструктуре выглядит вполне реальным.

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