Comments 42
Package parsing error. Require `rpm -qa` for rpm's or `dpkg-query -W -f='${Package} ${Version} ${Architecture} '` for deb systems.

Это через веб-интерфейс? Скиньте пожалуйста пример того, на чем упало мне в личку или на support@vulners.com. Мы оперативно поправим.
аналогично…
libtext-soundex-perl 3.4-1build3 i386

Даже из одной строчки вывод распарсить не может.
Привет! Сорри, ошибка была смешная — я не проверял на наличие пустых строк как элементов массива и упорно пытался их распарсить. Вроде Fixed.
На тех списках, которые вы мне кинули в почту, работает.
Спасибо за фидбек!
Scanned 2793 Packages and found 0 Security Bulletins

Заработало.
Только добавьте ещё проверку на наличие строки только с пробелом (табом) — тоже ошибка вылазит и приходится делать лишние движения — возвращаться назад и снова вставлять список.
Когда-нибудь. В данный момент мы изучаем, как это парсить и собирать.
Второй стадией уже сделаем такую же штуку для Win.
Передавать данные об актуальных уязвимостях третьим лицам, да еще и с адреса сервера (если белый IP) — вот этого хотелось бы избежать. Почему-то мне кажется, что платные сканеры уязвимостей имеют локальную БД с уязвимостями. Ну и во FreeBSD есть VuXML
У трех топовых Vulnerability Management вендоров есть облачные решения: Qualys Cloud Platform, Nessus Cloud, Rapid7 Nexpose Now. Причем у Qualys, лидера по объему рынка по версии Gartner-а, облачное решение является основным. У них есть и private cloud это экзотика для очень больших компаний. Это вопрос доверия VM-вендору. Если какая-то компания захочет иметь свой локальный Vulners, чтобы он хостился внутри компании и синхронизировал security content периодически, то думаю вполне реально договориться.
Как альтернативный вариант — можно подмешивать к запросам какие-то несуществующие пакеты, потом исключать их уязимости из результатов. Можно сделать проксирующий сервер, и все запросы пропускать только через него.
Возможно более безопасным был бы такой вариант — агент запрашивает по названию пакета, а ему возвращается список уязвимостей в версиях, который он фильтрует локально согласно версии пакета, и выводит актуальные уязвимости.
curl -s https://vulners.com/api/v3/search/id?id=RHSA-2015:1943 | grep OSVersion | uniq
            "OSVersion": "any",

Получаем «OSVersion»: «any» для всех пакетов, хотя тут видим, что этот RHSA-announce актуален только для RedHat версий 7.*.
Спасибо, работает.

Еще для RedHat находятся «лишние» уязвимости, из-за того парсятся бюллетени не только для «Red Hat Enterprise Linux Server», а и для всех остальных дистрибутивов заданной ветки (например Red Hat Gluster Storage Server).

Пример:

curl -s "https://vulners.com/api/v3/audit/rpm/?os=redhat&version=6.8&package=samba-winbind-clients-3.6.23-35.el6_8.x86_64" | grep bulletinID -m1
            "bulletinID": "RHSA-2016:0015",

В то время как RHSA-2016:0015 актуален только для Red Hat Gluster Storage Server.

Т.е. или нужно связать redhat только с «Red Hat Enterprise Linux Server» или добавить возможность указать более точно версию RedHat.
Спасибо, вижу. Но вот это кажется за 5 минут не поправлю.
Пошел копать содержимое.
Эээ… Постойте, то есть вы хотите сказать, что для deb/rpm-based дистрибутивов не существует штатного аналога portaudit (FreeBSD) / glsa-check (Gentoo)???
Нет, аналоги вполне есть: http://lzone.de/Automated+Linux+Package+Vulnerability+Scanning

Debian — debsecan
RHEL: yum list-security

Тогда вопрос — зачем ваш сайт?
Ну вот мне нужно находить уязвимости в установленных джумлах, вордпрессах и их плагинах, о которых менеджеры пакетов не знают совсем. Правда, представленный агент о них тоже не знает, а методы нахождения версии у всех этих ЦМС и форумов сильно разнятся (про плагины вообще молчу), но задача в целом решаемая
Хороший вопрос. Действительно, есть различные утилиты для проверки уязвимостей для различных платформ. Vulnerability Management решение в общем случае позволяет отслеживать уязвимости единообразным способом для многих платформ, при этом обращение к репозиториям в момент проверки не требуется. Такое решение предоставляет подробную информацию о том, что за уязвимость была найдена, как её можно проэксплуатировать и запатчить и т.д. При работе с утилитами есть свои тонкости, например 'yum list-security' работает в RHEL, но не работает в CentOS. Если в компании зоопарк решений небольшой и не критично ставить все обновления без обязательного тестирования, безусловно можно обойтись и без сканера уязвимостей.
Вот вы что-то вроде ответили, а вроде бы и нет. Если что, я не вижу ничего плохого в том что есть причина не использовать центос.
Когда будет Suse (SLES)? Планируете ли парсить конфиги Cisco, Huawei, Palo Alto?
SUSE формально готова и лежит в базе, но мы ее не тестировали.
Если есть желание помочь — напишите нам письмо :) Так мы включим SUSE очень быстро.

Планируете ли парсить конфиги Cisco, Huawei, Palo Alto? --> Это прям сканер получится.
Увы, пока не знаю. Это фриварный sideproject для нашей команды, а не работа.
Будет время, успеем — напишем. Но пока парсер конфигов даже в планах не стоит.
С рандомной сортировкой не очень удобно изучать уязвимости.
https://vulners.com/search?query=type:%20nginx
Почему бы по дефолту не сделать сортировку, как у всех, по дате?
Хотя это вопрос скорее не про аудит, а про поиск.
Там дефолтная сортировка «по лучшести». То есть по весу «насколько найденный элемент соответствует условиям поиска».
Согласен, это спорное состояние «по умолчанию». Но мы опирались на то, как работает Гугл/Яндекс.
Мы не правы? Поменять-то 5 минут. Но как правильно, мы пока не знаем.
Но как правильно, мы пока не знаем

Предоставить выбор пользователю.

И да, хотелось бы в списке ОС увидеть OpenSuSE и SLES/SLED.
Для SLES/SLED вроде все данные есть.
Если вы можете помочь их потестить — пожалуйста, напишите нам.
Что бы запуститься надо не много, только протестировать.

проверьте алгоритм сравнения для deb


USN-3028-1
libnspr4 2:4.10.10-0ubuntu0.14.04.1 amd64


>>> import apt_pkg
>>> apt_pkg.init_system()
>>> apt_pkg.version_compare("2:4.10.10-0ubuntu0.14.04.1", "2:4.12-0ubuntu0.14.04.1")
-2
Исправлено:
https://vulners.com/api/v3/audit/deb/?os=ubuntu&version=14&package=libnspr4%202:4.10.10-0ubuntu0.14.04.1%20amd64
Очень веселая бага — в поисковом запросе в elasticsearch, который должен был выдавать кандидатов для анализа, мы использовали конструкцию вида OSVersion:«14*». Кто же знал, что символ wildcard нельзя использовать при поиске с фразой в кавычках )
Теперь и мы об этом знаем. Спасибо за находку. Если вы в мск, то можем подарить вам кружку vulners, уж очень сочная ошибка была

а зачем вы используете wildcard для версий Ubuntu? Таким образом покрываете non-LTS версии?

wildcard используется только на предварительной выборке уязвимостей из базы. Дальше используется точное совпадение.
Мы на всякий случай проверяем потом еще и неточное. Вендор не всегда указывает все правильно.
Благодарим вас за сервис! Воспользовались в связи с увеличенной атакой на проекты.
Only those users with full accounts are able to leave comments. Log in, please.