Технологии и API полностью идентичные.
Отличается дашбордами, кнопкой «починить» и быстрой интеграцией в систему, если вы используете Zabbix как систему мониторинга.
Когда запрос идет без конкретизации полей, то работает механика обычного полнотекстового поиска.
А вот с affectedSoftware можно пользоваться уже точными сравнениями.
Хоть и не очень удобный, но правильный путь это посмотреть на все коллекции. Потом выбрать один элемент из нее, к примеру на Nginx.
Дальше там есть малозаметная но полезная кнопка «JSON source»:
Соответственно, «operator» подразумевает оператор сравнения, который надо применить между целевой версией софта и указанной в advisory. Если оператор выдал True, значит уязвимость присутствует.
Для поиска по конкретным полям в запросах надо применять разделитель "."
То есть, если мы хотим искать по name из примера, то affectedSoftware.name:«запрос»
Можно еще немножко расширить функционал и добавить к учету рейтинга факт использования уязвимой версии ПО.
Если использовать запрос на Vulners вот так:
Поисковый запрос:
affectedSoftware.name:"nginx" AND affectedSoftware.version:"1.11.0"
Чуть сложнее. Исходник вот тут — https://www.seebug.org/vuldb/ssvid-92405
Там оригинальный контент часто на китайском, поэтому парсер сходит с ума :(
legalhackers.com пока не парсятся, увы.
Смысл vulners в том, что бы структурировать в машиночитаемый вид то, что изначально таким не было.
Вот например патч уязвимости: https://vulners.com/centos/CESA-2016:2850
Вот так он выглядел до сборки:
Да. Целевые тренинги по веб-безопасности и безопасной разработке, выполненные дополнительно еще в контексте используемых нами технологий. Плюс внутренние CTF, «неделя безопасности QIWI» и тому подобное.
Для SLES/SLED вроде все данные есть.
Если вы можете помочь их потестить — пожалуйста, напишите нам.
Что бы запуститься надо не много, только протестировать.
Там дефолтная сортировка «по лучшести». То есть по весу «насколько найденный элемент соответствует условиям поиска».
Согласен, это спорное состояние «по умолчанию». Но мы опирались на то, как работает Гугл/Яндекс.
Мы не правы? Поменять-то 5 минут. Но как правильно, мы пока не знаем.
SUSE формально готова и лежит в базе, но мы ее не тестировали.
Если есть желание помочь — напишите нам письмо :) Так мы включим SUSE очень быстро.
Планируете ли парсить конфиги Cisco, Huawei, Palo Alto? --> Это прям сканер получится.
Увы, пока не знаю. Это фриварный sideproject для нашей команды, а не работа.
Будет время, успеем — напишем. Но пока парсер конфигов даже в планах не стоит.
Отличается дашбордами, кнопкой «починить» и быстрой интеграцией в систему, если вы используете Zabbix как систему мониторинга.
Fixed.
Поправлю при обновлении.
Там есть ссылки на образцы потенциальной малвари, плюс немножко анализов и IoC.
Были бы внятные пожелания :)
Альтернативный сканер на Python. Но он глупый, может просто отсканировать и показать уязвимости.
В уязвимости ничего про минорные версии не написано))
А вот с affectedSoftware можно пользоваться уже точными сравнениями.
Хоть и не очень удобный, но правильный путь это посмотреть на все коллекции. Потом выбрать один элемент из нее, к примеру на Nginx.
Дальше там есть малозаметная но полезная кнопка «JSON source»:
И посмотреть как выглядит разметка для автоматизации сканирования:
"affectedSoftware": [
{
"operator": "le",
"version": "1.9.9",
"name": "nginx"
}
],
Соответственно, «operator» подразумевает оператор сравнения, который надо применить между целевой версией софта и указанной в advisory. Если оператор выдал True, значит уязвимость присутствует.
Для поиска по конкретным полям в запросах надо применять разделитель "."
То есть, если мы хотим искать по name из примера, то affectedSoftware.name:«запрос»
Если использовать запрос на Vulners вот так:
Поисковый запрос:
affectedSoftware.name:"nginx" AND affectedSoftware.version:"1.11.0"
Делаем запрос API
То получаем выхлоп с уязвимостью. Можно использовать параметр «total»: 1 как метрику.
Не на все софты это сработает подобным образом, но на многие.
Вот еще пример для Apache:
(affectedSoftware.name:*apache*) AND (affectedSoftware.version:"2.4.18")
P.S.
Мануал по query лежит вот тут.
Там оригинальный контент часто на китайском, поэтому парсер сходит с ума :(
legalhackers.com пока не парсятся, увы.
Смысл vulners в том, что бы структурировать в машиночитаемый вид то, что изначально таким не было.
Вот например патч уязвимости: https://vulners.com/centos/CESA-2016:2850
Вот так он выглядел до сборки:
http://lists.centos.org/pipermail/centos-announce/2016-December/022169.html
http://lists.centos.org/pipermail/centos-announce/2016-December/022170.html
http://lists.centos.org/pipermail/centos-cr-announce/2016-December/003714.html
А вот так он выглядит в JSON: https://vulners.com/api/v3/search/id/?id=CESA-2016:2850
Если вы можете помочь их потестить — пожалуйста, напишите нам.
Что бы запуститься надо не много, только протестировать.
Согласен, это спорное состояние «по умолчанию». Но мы опирались на то, как работает Гугл/Яндекс.
Мы не правы? Поменять-то 5 минут. Но как правильно, мы пока не знаем.
Если есть желание помочь — напишите нам письмо :) Так мы включим SUSE очень быстро.
Планируете ли парсить конфиги Cisco, Huawei, Palo Alto? --> Это прям сканер получится.
Увы, пока не знаю. Это фриварный sideproject для нашей команды, а не работа.
Будет время, успеем — напишем. Но пока парсер конфигов даже в планах не стоит.