Архив метки: Ubuntu

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

1 комментарий

Хочется немного поиграться с непосредственным детектом уязвимостей - проект 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 генерить опять же. 🙂

Платные обновления безопасности для актуальных версий Ubuntu

Добавить комментарий

Платные обновления безопасности для актуальных версий Ubuntu

Платные обновления безопасности для актуальных версий Ubuntu. Рекомендации в бюллетенях Ubuntu поставить ESM (Expanded Security Maintenance) версий пакетов доступные с платной подпиской это дело обычное. Как правило, это касается End of Life (EOL) версий Ubuntu. С 30 апреля EOL будут все версии ниже Ubuntu 18.04 (Bionic Beaver) включительно. Всё честно. Обновитесь на новую версию дистриба, будут вам безопасные версии пакетов, не можете - платите.

С появлением подписки Ubuntu Pro стало интереснее. Вот 2 USN бюллетеня с ESM пакетами для Ubuntu 20.04 (EOL Apr 2030):

USN-5273-1: RPM Package Manager vulnerabilities
USN-5160-1: Midnight Commander vulnerability

Пишут, что эти обновления доп. фича и без Ubuntu Pro их бы вообще не было - радуйтесь. По факту это значит, уязвимость в пакете из репозитория есть (тот же Scanvus продетектит), версия дистриба актуальная, исправить уязвимость без платной подписки нельзя. А Canonical подписки компаниям из РФ не продает. 🤷‍♂️

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

4 комментария

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂

1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)

Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году

1 комментарий

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

Что сканировать?

1) Оценка "стабильности" IT-вендоров похоже оказалась не особо востребованной и в итоге свелась к переходу на отечественное. Тут и позиция регуляторов направляет, и нежелание зарубежных вендоров подставляться лишний раз под вторичные санкции. Пока выглядит так, что новые IT и ИБ решения будут в основном российские (пусть даже они будут функционально хуже).
2) С другой стороны массового выпиливания продуктов Microsoft пока не наблюдается. MS пока не нагнетают. Позиция регуляторов достаточно умеренная и сводится к требованию контроля обновлений. Видима зависимость настолько велика, что требовать чего-то другого не реалистично.
3) Массового отказа от мейнстримных Linux дистрибутивов тоже не наблюдается. Пока не было громких кейсов с активным участием западных вендоров Linux дистрибутивов. Миграция c Ubuntu/Debian/CentOS Stream/Alma/Rocky на российские дистрибы связана с техническими сложностями и значительными финансовыми затратами. В целом, в ширнармассах пока не ощущается понимание зачем это нужно (за исключением случаев когда это прямое указание регулятора).

Чем сканировать?

Какого-то значимого изменения ландшафта на рынке VM-решений пока не видится.
1) Кто-то продолжает использовать западные решения с помощью разного рода ухищрений.
2) Кто-то активнее переходит на продукты традиционных отечественных VM вендоров (Positive Technologies, Алтэкс-Софт, Эшелон, Газинформсервис).
3) Есть некоторая активность от нового игрока Vulns.io.
4) Есть развитие у периметровых сервисов Metascan и ScanFactory.
5) Интересно развитие VM как доп. функциональности у Kaspersky: если все равно антивирус заменять, удобно получить в результате и агент детектирующий уязвимости. Win-win в духе Microsoft Defender for Endpoint. Выглядит как перспективная тема для агентного сканирования.
6) Достаточно много больших российских компаний приняли решение пилить свои VM решения, т.к. доступные коммерческие дороги и/или чем-то не устраивают. Есть вероятность появления таких решений на рынке.

Собственно вот и обещанный пост про OpenSCAP

Добавить комментарий

Собственно вот и обещанный пост про OpenSCAP. Демонстрирую как можно просканить хост на уязвимости с помощью OpenSCAP и бесплатного официального OVAL контента для Ubuntu. Также пробую разнести сбор данных и их анализ с помощью System Characteristics. Не без багов, но работает. Можно ли будет генерить файлы System Characteristics самостоятельно без утилиты oscap, только по собранным пакетам и версии ОС? Так чтобы на основе OpenSCAP сделать бесплатную API-шку совместимую со Scanvus? 🤓 Хе-хе, посмотрим. Но пока выглядит как достаточно перспективная задумка. Следите за обновлениями, ну и если кто хочет поучаствовать в благом деле, пишите в личку (@leonov_av).