Если вы хотите разрабатывать свои nasl-плагины для OpenVAS, вам может быть интересно, как импортировать их в сканер. Вот мне тоже стало интересно.
Прежде всего, я решил скопировать один из существующих сценариев nasl. Я выбрал скрипт, который успешно обнаружил уязвимость на целевом узле. Таким образом, в случае ошибки импорта я бы точно знал, что это не из-за синтаксических ошибок в скрипте, а, например, из-за того, что у плагина нет подписи.
Я просканировал хост с CentOS, выбрал и скопировал файл сценария, изменил идентификатор сценария (oid) и название скрипта, восстановил базу данных. Затем я обновил целевой хост.
Как вы можете видеть, новый скрипт присутствует в результатах сканирования. Всё довольно просто.
Лично я считаю, что качество базы знаний является наиболее важной характеристикой Vulnerability Management (VM) продуктов. Возможно потому, что я сам довольно продолжительное время занимался разработкой security content-а для сканеров уязвимостей и это уже профессиональная деформация. =) Теперь, когда я сканеры в основном эксплуатирую, мне хотелось бы поделиться своими наблюдениями о качестве контента, который в них используется. В настоящее время на глобальном VM-рынке представлены десятки решений, которые имеют очень разные базы знаний и следовательно очень разные способности по обнаружению уязвимостей. Очень странно, что эта тема не обсуждается практически вообще. Такое ощущение, что качество сканирование никого не волнует. Рекомендую посмотреть на эту тем пост “Tenable doesn’t want to be Tenable anymore” и особенно комментарий к нему от HD Moore (основатель Metasploit и ex-CRO Rapid7).
Что VM-вендоры обычно рассказывают про базу знаний своего продукта? В лучшем случае количество реализованных проверок: 40000-80000 и примерный лист поддерживаемых систем. Чаще говорят, что умеют вообще всё. Но если все вендоры говорят, что умеют всё и не хотят соревноваться в качестве детекта с конкурентами, чем тогда остается очаровывать клиентов? Дашбордами, отчетами, SIEMоподобной функциональностью. По мне это всё, конечно, важно и круто, но все же не настолько важно как основная функциональность, за которую сканер уязвимостей и покупают. Чтобы показать, что разница в базах знаний действительно есть, я сделал простенькое сравнение Nessus и OpenVAS.
Почему я называю это сравнение быстрым и простеньким? Я не определяю структуру баз знаний для продуктов и не сопоставляю один NASL-плагин другому. Вполне вероятно, что я так и сделаю чуть позже. Вместо этого я смотрю только на CVE-ссылки. Если два сканера могут детектить одни и те же уязвимости у них и ссылки в плагинах будут на те же CVE проставлены, так ведь? На самом деле видим значительную разницу между продуктами и более половины из существующих CVE-шек нельзя обнаружить даже используя оба сканера.
Все CVEs: 80196
Ссылки на CVE в OpenVAS: 29240
Ссылки на CVE в Nessus: 35032
Пересечение OpenVAS и Nessus: 3787;25453;9579
