Архив рубрики: Scanvus

Размышляю о развитии Scanvus

Размышляю о развитии Scanvus

Размышляю о развитии Scanvus. Давненько не было обновлений проекта. Так-то понятно, что опекать конкретную инфру мне стало не нужно, поэтому приоритизирующий уязвимости Vulristics мне стал важнее, чем детектирующий их Scanvus. 🤷‍♂️ Однако проблема оценки качества детектирования уязвимостей никуда не делась, поэтому и необходимость в "прозрачном" (и желательно бесплатном 😏) сканере остаётся.

Подход к интерпретации OVAL-контента в рамках Vuldetta показал, что хоть это делать и можно, но местами довольно хлопотно (для уязвимостей ядра например).

Использовать для детектирования OpenSCAP было бы гораздо проще. В этом случае задачей Scanvus было бы зайти на хост, определить версию дистрибутива, найти инсталляцию OpenSCAP, скачать и загрузить на хост актуальный OVAL-контент, запустить утилиту OpenSCAP, забрать и отобразить отчёт сканирования.

Мне кажется, что такой "агентный" режим работы имеет смысл реализовать.

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta

Хочется немного поиграться с непосредственным детектом уязвимостей - проект Vuldetta. С 2021 года я работаю над открытым проектом сканера уязвимостей Scanvus для Linux хостов и docker-образов. И с ним всё отлично, кроме того, что он сам уязвимости не детектирует. 😅 Он собирает пакеты и версию дистриба, но для детектирования использует внешние коммерческие API-шки: Vulners Linux API или VulnsIO API. А оно стоит денег и это, естественно, снижает привлекательность утилиты. 🤷‍♂️

Можно ли сделать так, чтобы Scanvus работал без использования коммерческих API? Можно. И тут видятся 2 пути:

🔹 Первый путь - это добавить детектирование уязвимостей непосредственно в Scanvus. Мне это не очень нравится. Мне нравится концепция такого "безмозглого" нейтрального сканера, который может использовать различную внешнюю экспертизу в зависимости от потребностей.

🔹 Второй путь - это сделать некоторый аналог Vulners Linux API или VulnsIO API, который можно было бы развернуть локально в организации и использовать для детекта уязвимостей хотя бы для некоторых Linux дистрибутивов. Понимая, безусловно, что коммерческий сервис будет, скорее всего, поддерживать большее количество дистрибутивов и, возможно, будет даже лучше детектировать. Но от бесплатной свободной альтернативы хуже не будет.

Собственно второй путь и есть Vuldetta. Взять готовые формализованные правила детекта (после возни с OVAL-контентом для Debian я смотрю теперь в сторону OVAL-контента для Ubuntu), разобрать их во что-нибудь простое и удобное для работы (Bulletin|CVE_Number|Distribution_Version|Package_Name|Package_Version), сделать API-шку-сравнивалку версии на хосте с безопасными версиями из OVAL-контента.

Вроде выглядит как изян. А на выходе может получиться штука, которую как минимум можно будет использовать для валидации качества детектирования коммерческих сканеров уязвимостей, а как максимум возможно даже в проде где-то использовать. А так как лицензия будет MIT, то это даже можно будет встроить куда-нибудь как альтернативу жуткому фолсящему Trivy. 😅 И будет на чём тестовый контент для Vulremi генерить опять же. 🙂

Проекты, над которыми я сейчас размышляю

Проекты, над которыми я сейчас размышляю. Возможно кому-то тоже захочется поучаствовать.

1. CVE Mentions. Переводить аналитические отчёты с упоминанием CVE-идентификаторов в формализованный вид, использовать их для приоритизации уязвимостей в Vulristics.

2. Свой Vulnerability Feed. Анализировать все CVE/БДУ, детектировать тип уязвимости и уязвимый продукт, наличие эксплоита и факта эксплуатации вживую. Использовать фид в Vulristics.

3. Linux Patch Wednesday. Формировать ежемесячные обзоры по Linux-овым уязвимостям. Написать скрипт для формирования скоупов CVE с разбивкой по месяцам.

4. ОСОКА. Система оценки критичности уязвимости на основе CVSS v3 и методики оценки критичности ФСТЭК. Расписать метрики, формулу расчета, автоматическую генерацию базовых метрик из CVSS Base v2, v3, v4.

5. Scanvus OVAL. Добавить в Scanvus возможность детектирования уязвимостей с использованием OVAL-контента без доступа к внешним платным API.

6. Scanvus Docker. Добавить возможность детектировать уязвимости Docker images без запуска контейнера, только через анализ SBOM.

7. Telegram2WordPress. Написать обвязку, которая будет раскидывать посты из телеграмма в блог на WordPress. Для упрощения навигации, улучшения индексации и на случай если Телеграмм снова начнут блокировать.

Про сканер уязвимостей в Yandex Cloud

Про сканер уязвимостей в Yandex Cloud

Про сканер уязвимостей в Yandex Cloud. На днях были новости, что Yandex открыл доступ к своему сканеру уязвимостей. Из этих новостей было не очень понятно что за сканер, для чего сканер. Но я нашел первоисточник - блогопост на сайте Яндекс Клауда.

1. Речь о сканере для Docker-образов, интегрированный в сервис Yandex Container Registry. Это аналог Aqua Trivy, Clair, Falco, Docker scan. Ну и моего Scanvus-а. 🙂 И видимо имеется ввиду Сканер уязвимостей описанный в документации, поддерживающий Alpine, CentOS, Debian, Redhat, Ubuntu в качестве ОС, на которых могут быть собраны пользовательские Docker-образы.

2. В чем преимущество: "Чтобы использовать сканер уязвимостей Yandex Cloud, не требуется выделять дополнительную инфраструктуру, обслуживать её, заниматься разворачиванием и поддержкой продукта или глобально менять процесс выкладки кода. "

3. Описание сканера частично понятно, детект по пакетам: "по результатам сканирования образа пользователь получает отчёт об уязвимостях, обнаруженных в конкретных пакетах ОС, и о версиях этих пакетов с исправлениями, если такие имеются". А то, что понимается под "сканер уязвимостей с использованием статического анализа" - загадочно.

4. Уровни сканирования: реестра целиком и выбранных репозиториев. Сканирование отдельных образов и фильтрации по тегам пока нет, но обещают.

5. Сколько стоит: "Первые шесть первичных и шесть последующих сканирований бесплатны. Начиная с седьмого раза нужно будет платить: за каждое первичное — 13,2 рубля, а за последующее — 7,2 рубля."

Небольшое обновление Scanvus для сканирования Linux-хостов по SSH

Небольшое обновление Scanvus для сканирования Linux-хостов по SSH. Теперь Scanvus может аутентифицировать не только ключом

$ python3 scanvus.py --audit-service "vulners" --assessment-type "remote_ssh"  --host "192.168.56.105" --user-name "vmuser" --key-path "/home/alexander/.ssh/id_rsa.pub"

но и просто по паролю

$ python3 scanvus.py --audit-service "vulners" --assessment-type "remote_ssh"  --host "192.168.56.105" --user-name "vmuser" --password "vmuser"

Иногда так проще и быстрее.

Выпустил эпизод про поддержку двух API в Scanvus

Выпустил эпизод про поддержку двух API в Scanvus. Потестил сканирование локалхоста, удаленного хоста по SSH и Docker образа. Все работает, но при сравнении результатов есть серьезные расхождения. До конкретных причин я в этом эпизоде на докапывался. Однако это в очередной раз подтверждает, что обнаружение уязвимостей не такое просто дело, и хорошо, когда можно использовать несколько независимых механизмов обнаружения и сравнивать результаты. 😉

Отличные новости по моему опенсурсному проекту Scanvus!

Отличные новости по моему опенсурсному проекту Scanvus!

Отличные новости по моему опенсурсному проекту Scanvus! Теперь вы можете проводить проверки на уязвимости Linux хостов и докер-образов не только с помощью API от Vulners.com, но и с помощью аналогичного API от Vulns.io. Особенно приятно, что весь код для поддержки нового API коллеги из Vulns.io написали и законтрибьютили сами. Оставалось только потестить, что все работает. За это им огромное спасибо!