Хабр Курсы для админов
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
работа конечно проделана потрясающая. но есть еще куда расти. три примера, когда ваша тула сфелит или скажет не то
1) debian с репой от вендора nginx. стоит условная версия 1.1, которая уже EOL, но CVE патчи дотягиваются командой дебиана. но версия стоит из репы и она протухла давно, откуда брать фиды CVE непонятно.
2) rhel based дистры, в которых нет софта вообще, часто подключают помойки типа remi/epel и тд. какая там политика патчинга никто не знает
3) ESM в убунте. да-да, даже в актуальной 26 некоторые пакеты избавляются от CVE только в ESM
Спасибо, все три примера в точку. Проект свежий и развивается.
1. Debian и nginx. Тут два разных случая.
1.1 Если nginx штатный, из Debian: ось пакетов сверяет версию с Debian Security Tracker, а он про бэкпорты знает, так что там всё честно.
Ось сервисов, наоборот, смотрит на upstream-версию из баннера и покажет CVE, которые Debian уже закрыл патчами. Будут ложные срабатывания, а EOL при этом окажется правдой. Сейчас эти оси не сводятся, и я сознательно предпочёл ложное срабатывание пропуску. Для дистрибутивного софта главная — ось пакетов.
1.2 Если nginx из репозитория nginx.org: трекер Debian про такой пакет ничего не знает. Версия 1.26 «старше» исправленной дебиановской 1.22, поэтому по пакетам выйдет тишина.
Спасает ось сервисов, если nginx заведён отдельной целью: версия вендорского пакета совпадает с upstream, а её покрывают advisories nginx.org, NVD и БДУ.
2. RHEL с EPEL и remi. OVAL от Red Hat, Alma и Oracle описывает только пакеты самого дистрибутива. Всё, что пришло из EPEL или remi, там просто не упоминается, и сейчас enodia покажет по таким пакетам «нет находок», хотя честнее было бы «неизвестно». Есть и обратный риск: если имя стороннего пакета совпало с дистрибутивным, его сверят с чужим фидом. Буду исправлять: введу отдельный статус «не покрыто фидом» и начну учитывать, из какого репозитория пришёл пакет (apt Origin, rpm vendor).
3. Ubuntu ESM. Проверил на OVAL для noble: ESM-исправления там есть, с версиями +esm. Хост без Pro enodia покажет уязвимым, и это правда: пакет действительно не пропатчен. Но она не предупредит, что исправление ставится только через Ubuntu Pro. Возможно добавлю такую пометку, либо опишу в доках.
Всё записал в roadmap, спасибо за конкретные сценарии.
ну я просто уже все это проходил, пока у нас нечто аналогичное делали. и сколько там еще скрывается - надо плотно сидеть и разибраться. или ллм натравить, пусть покажет дырки.
PS BDU зачастую трэшак несет - например отмечен CVE для пакета aarch64 only, а по факту общая для всех платформ.
BTW тоже поди по архитектурам не распилено в вашем продукте :)
Про БДУ согласен, там все очень неоднозначно. Поэтому оно все опционально подключается)
По архитектурам не распиливал. Так как изначально, тула делалась для покрытия мониторингом серверных аппов, с api и протоколами в первую очередь. Ну то есть всяких редисок. жир, гитлабов и тд.
Покрытие по софту на ОС через овалы и вендор-базы уже добавлялось значительно позже в качестве эксперимента и полезной потенциально фичи. Так что упора, мониторить именно пакеты не было.
Но в целом, есть куда развивать. Главное, в итоге не превратиться в Ccleaner с проверкой обновления софта и биоса. Но мысль проработать анализ установленного софта был, и на кросплатформе. Пока просто как идея.
aarch64 давно уже много серверных железок. например
продается в РФ вполне.
я имею ввиду, что если взять тот же esxi, который есть на арме, то его тула увидит ее по версиям.
но фильтр по cve можно будет доработать, чтобы условная cve воспроизводимая и на спецефичной архитектуре (на arm на том же) не попадала в x86 выборку, например. это да.
учту момент.
а так, если у платформы есть api, то могу с ним ознакомиться и постараться добавить пробу.
в общем, на гитхабе есть категория ишью с реквестаии, чтобы оно не потерялось)
Ложное срабатывание в любом случае лучше, чем пропущенная дыра в безопасности)
Проще собирать софт в Docker-образах с четкими тегами, тогда сканировать зависимости намного легче. А тащить левые репы в систему это всегда риск
и да, в целом история вполне коммерциализируема, нормальных решений сейчас на рынке или 0 или 1.
из дополнительно проверить в сценарии
"Отчёт нужно перегенерировать, а потом ещё и понять, что изменилось с прошлого раза. Поддерживать диффы руками больно."
даунгрейд - часто бывает откат у админов, прилетела новая версия, неочень, нужно откатиться.
и еще в копилку - нотификации владельцу сервера "у вас тут дыряво", с запоминанием CVSS, даты патчинга и когда уже поздно и надо писать объяснительную.
Крутая идея собрать инвентаризацию и сверку с календарем EOL в один бинарник)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зоопарк версий под контролем: как я создал enodia — инвентаризацию сервисов с EOL и CVE