что такое сканер уязвимостей
Использование сканера уязвимостей OpenVAS
Сканеры уязвимостей — это программные или аппаратные средства, служащие для осуществления диагностики и мониторинга сетевых компьютеров, позволяющее сканировать сети, компьютеры и приложения на предмет обнаружения возможных проблем в системе безопасности, оценивать и устранять уязвимости. (Википедия).
Известными коммерческими сканерами являются Nessus, GFI LANguard, XSpider.
В отличии от прочих, OpenVAS бесплатен, работает без каких либо ограничений и может пригодится как сетевым администраторам, так и специалистам ИБ для выявления актуальных проблем своей инфраструктуры. 
В основе работы OpenVAS-а лежит постоянно пополняемая коллекция NVT тестов безопасности (которых уже больше 30000), а также подключение к базе CVE, описывающей известные уязвимости. Исполнение NVT тестов позволяет выявить уязвимость, а CVE обеспечивает описание проблемы и способы её решения.
1. Выбор железа.
Тут все просто, если предстоит сканировать часто и большие диапазоны адресов, то чем мощнее железо, тем лучше. Можно увеличивать число параллельных потоков обработки сетевых адресов, да и само сканирование по каждому хосту будет проходить быстрее.
2. Установка.
Тут я выбираю наименее проблемный для меня способ установки из пакетов.
Заходим на адрес.
www.openvas.org/install-packages.html
Выбираем нужный дистрибутив и устанавливаем.
В моем случае это CentOS и репозитарий atomicorp. Скрипт сам скачает все зависимости, проведет первоначальное обновление базы уязвимостей и пропишет нужные настройки. В процессе попросит придумать логин и пароль для доступа в Openvas.
3. Использование.
Переходим по адресу localhost:9392 вводим логин и пароль и мы в консоли управления Greenbone Security Assistant.
Далее пример работы с Openvas для сканирования диапазона внутренней сети. Основные настройки заточены под оптимальную скорость проверки каждого хоста.
3.1 Выбираем конфигурацию сканирования.
Идем в раздел Configuration – Scan Configs.
Видим 4 стандартных политики и 1 пустую.
Политики делятся на 2 группы – fast и deep.
Принципиальное различие — в deep не учитывается работа каждого предыдущего скрипта проверки и сбор информации начинается заново.
По моим тестам, это существенно увеличило время сканирования каждого хоста, при отсутствии значимого результата. Поэтому поэтому для большей скорости выбираем политику Full and fast ultimate и клонируем ее нажав на значок овечки .
Теперь, для клона, нам доступны опции редактирования и нажав на значок гаечного ключа , заглянем внутрь.
Опций великое множество, несколько сотен, на скрине, только самое начало. Все опции сгруппированы по подразделам NVT тестов по различным типам операционных систем и сетевого оборудования, по настройкам различных подключаемых утилиты типа nmap, nikto и др.
Называем нашу новую политику Office_scan_config.
Обращаю внимание на следующие пункты.
safe_check–отключение позволит запускаться потенциально опасным NVT тестам, выполнение которых может вызвать падение тестируемого хоста. Использовать аккуратно.
optimize_test– переключатель который задает использовать fast или deep сканирование.
Далее спускаемся до пунктов PingHost и выставляем переключатели, как на скриншоте.
Это позволит сразу исключать пустые адреса и не тратить на них время сканера. Остальные пункты не трогаем.
Не забываем сохранить принятые изменения.
3.2 Прописываем учетную запись для проведения локальных проверок.
Если данный пункт сконфигурирован, то Openvas будет заходить на каждую машину, сканировать установленный софт, локальные настройки безопасности и выкидывать алерты, в случае обнаружения проблем.
Естественно это увеличит время сканирования.
Если не конфигурировать, Openvas ограничится удаленными проверками.
Идем в раздел Configuration –Credentials.
Создаем новую запись, нажав на значок звездочки .
Допустим у нас windows сеть в домене, есть пользователь sec_check, с правами локального администратора на нужных машинах, тогда это будет выглядеть так.
Сохраняем и идем дальше.
3.3 Устанавливаем цели сканирования.
Далее нам нужно забить диапазон адресов для сканирования и определится с набором портов, которые будет проверять Openvas.
Идем в раздел Configuration –Target. Создаем новую цель, нажав на значок звездочки. Задаем ей имя office.
Тут в принципе все понятно, в разделе SMB, мы подключили ранее созданного пользователя для проведения локальных проверок.
В разделе PortList, подключается нужный диапазон портов, в данном случае предлагаемый Nmap-ом набор популярных портов. Выбор в пользу такого диапазона, сделан опять же в пользу оптимизации, дабы не лопатить все 65 тысяч.
В разделе Hosts указываем диапазон ip.
3.4 Запуск!
Идем в раздел ScanManagement — Task. Создаем новую задачу, нажав на значок звездочки.
Последовательно выбираем ранее созданные конфигурации и нажимаем на кнопку CreateTask.
Стартуем.
Идем пить чай.В зависимости от насыщенности сети и мощности сервера, процесс может занять до нескольких часов.
По окончанию процесса мы можем нажать на значок лупы и просмотреть все найденные проблемы.
4. Обновления.
Периодически необходимо подкачивать актуальные сведения об уязвимостях и тесты их выявляющие.
Делается это либо из браузера в разделе Administration. (поочередно во всех 3-х разделах: nvt,scap,cert)
Либо из командной строки, последовательными командами.
Обладатели мощного железа, могут заглянуть в раздел Settings и выставить большее кол-во параллельных потоков.
Полезные приемы работы в Greenbone Security Assistant. можно найти тут
Сканирование на уязвимости и безопасная разработка. Часть 1
В рамках профессиональной деятельности разработчикам, пентестерам, безопасникам приходится сталкиваться с такими процессами, как Vulnerability Management (VM), (Secure) SDLC.
Под этими словосочетаниями скрываются различные наборы практик и используемых инструментов, которые переплетены между собой, хотя их потребители различаются.
Технический прогресс пока не дошёл до того, чтобы одним инструментом заменить человека для проведения анализа защищённости инфраструктуры и ПО.
Интересно понять, почему это так, и с какими проблемами приходится сталкиваться.
Процессы
Процесс Vulnerability Management («управление уязвимостями») предназначен для непрерывного мониторинга защищённости инфраструктуры и патч-менеджмента.
Процесс Secure SDLC («цикл безопасной разработки») предназначен для поддержки защищённости приложения в ходе разработки и эксплуатации.
Схожей частью этих процессов является процесс Vulnerability Assessment — оценки на уязвимости, сканирования на уязвимости.
Основное различие в сканировании в рамках VM и SDLC в том, что в первом случае целью является обнаружить известные уязвимости в стороннем ПО или в конфигурации. Например, устаревшую версию Windows или community-строку по умолчанию для SNMP.
Во втором же случае целью является обнаружить уязвимости не только в сторонних компонентах (зависимостях), но в первую очередь в коде нового продукта.
Это порождает различия в инструментах и подходах. На мой взгляд, задача поиска новых уязвимостей в приложении значительно интереснее, поскольку не сводится к фингерпринтингу версий, сбору баннеров, перебору паролей и т.д.
Для качественного автоматизированного сканирования уязвимостей приложений необходимы алгоритмы, учитывающие семантику приложения, его предназначение, специфичные угрозы.
Инфраструктурный же сканер зачастую можно заменить таймером, как выразился avleonov. Смысл в том, что чисто статистически вы можете считать вашу инфраструктуру уязвимой, если вы её не обновляли, скажем, месяц.
Инструменты
Сканирование, как и анализ защищённости, можно выполнять как чёрным ящиком, так и белым ящиком.
Black Box
При blackbox-сканировании инструмент должен уметь работать с сервисом через те же интерфейсы, через которые с ним работают пользователи.
Сканеры инфраструктуры (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose и т.д.) ищут открытые сетевые порты, собирают «баннеры», определяют версии установленного ПО и ищут в своей базе знаний информацию об уязвимостях в этих версиях. Также пытаются обнаружить ошибки конфигурации, такие как пароли по умолчанию или открытый доступ к данным, слабые шифры SSL и т.д.
Сканеры веб-приложений (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, и т.д.) тоже умеют определять известные компоненты и их версии (например, CMS, фреймворки, JS-библиотеки). Основные шаги сканера — это краулинг и фаззинг.
В ходе краулинга сканер собирает информацию о существующих интерфейсах приложения, HTTP-параметрах. В ходе фаззинга во все обнаруженные параметры подставляются мутированные или сгенерированные данные с целью спровоцировать ошибку и обнаружить уязвимость.
Такие сканеры приложений относятся к классам DAST и IAST — соответственно Dynamic и Interactive Application Security Testing.
White Box
При whitebox-сканировании различий больше.
В рамках процесса VM сканерам (Vulners, Incsecurity Couch, Vuls, Tenable Nessus и т.д.) зачастую дают доступ к системам, проводя аутентифицированный скан. Таким образом, сканер может выгрузить установленные версии пакетов и конфигурационные параметры прямо из системы, не угадывая их по баннерам сетевых сервисов.
Скан получается точнее и полнее.
Если же говорить о whitebox-сканировании (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs и т.д.) приложений, то речь обычно идёт о статическом анализе кода и использовании соответствуюбщих инструментов класса SAST — Static Application Security Testing.
Проблемы
Проблем со сканированием возникает множество! С большинством из них мне приходится сталкиваться лично в рамках предоставления сервиса по построению процессов сканирования и безопасной разработки, а также при проведении работ по анализу защищённости.
Выделю 3 основные группы проблем, которые подтверждаются и беседами с инженерами и руководителями служб ИБ в самых разных компаниях.
Проблемы сканирования веб-приложений
Проблемы сканирования исходного кода
Проблемы сканирования инфраструктуры
Подходы
Stay tuned and let’s disrupt the vulnerability scanning!
Сканеры безопасности: автоматическая классификация уязвимостей
Растущее количество угроз вынуждает разработчиков средств анализа защищенности постоянно усовершенствовать свои решения. Сейчас на рынке ИБ представлен широкий выбор сканеров безопасности от различных производителей, которые разнятся по своей эффективности. Это делает невозможным выпуск новых версий сканеров без конкурентного анализа подобных продуктов.
Компания Positive Technologies разработала собственную методологию конкурентного анализа для тестирования и сравнения сканеров по объективным критериям, таким как типы и количество найденных уязвимостей, полнота сканирования различных целей. Кроме того, была сформирована база данных конкурентного анализа (DBCA — Database of Competitive Analysis), в которой собраны уникальные уязвимости, найденные в процессе ручных проверок и автоматического сканирования синтетических целей, реальных сайтов, CMS, веб-приложений и прочих информационных систем сканерами безопасности (WebEngine – встроенный в PT AF и PT AI, Acunetix, AppScan и др.). DBCA используется для сравнения результатов сканирования новыми версиями сканеров Positive Technologies с результатами сторонних сканеров и отсеивания ложных срабатываний (false positive).
Однако наполнение DBCA требует месяцев ручного труда высококвалифицированных инженеров-тестировщиков. Процессы настройки окружений и сканирования занимают много времени, порой недели. Еще дольше происходит процесс валидации найденных уязвимостей. Так, над заполнением текущей базы работали три инженера отдела QA в течение года. В связи с этим возникла необходимость ускорения и автоматизации работ.
Решением стало использование математического аппарата нейронных сетей (НС) и нечетких измерительных шкал. Об этом мы подробно писали в предыдущей статье «Сканеры безопасности: автоматическая валидация уязвимостей с помощью нечетких множеств и нейронных сетей». Теоретические исследования вошли в основу практического эксперимента, поставленного инженерами Positive Technologies: Тимуром Гильмуллиным, Владимиром Софиным, Артемом Юшковским.
Была решена формальная задача по преобразованию DBCA в базу знаний, путем использования НС (в качестве решающего правила) и нечетких измерительных шкал (для лингвистической оценки результатов классификации в понятной человеку форме). Практически DBCA была дополнена правилами и механизмами отсеивания ложных срабатываний, заранее отсортированных по степени уверенности в их наличии, оцененных на нечеткой измерительной шкале. Это позволило ускорить работу инженеров-тестировщиков по анализу результатов сканирования и отсеиванию ложных срабатываний.
Ретроспектива, критерий приемки и основные результаты
После завершения работ по первичному заполнению DBCA уязвимостями, база содержала несколько десятков тысяч уязвимостей. Из них инженеры-тестировщики в течение года классифицировали лишь около половины. Результаты нашего анализа показали, что они выполняли до 70% лишних действий по отсеиванию ложных срабатываний от всего объема работ.
При регулярном проведении работ по конкурентному анализу использование автоматической системы для валидации уязвимостей дает огромный прирост производительности и повышает эффективность ручного труда — можно сократить до 70% объема требуемых работ! Кроме того, применение автоматической системы освободит инженеров для других приоритетных задач, что позволит увеличить число сканеров, участвующих в конкурентном анализе, и количество сканируемых CMS.
Со стороны тестирования были получены следующие критерии приемки и требования эффективности:
Функциональная схема классификации уязвимостей
Весь комплекс автоматизации процессов для классификации уязвимостей был описан функциональной IDEF0-схемой.
Рис. 1 Функциональная IDEF0-схема
На схеме отражены основные этапы классификации уязвимостей:
В качестве измерительных шкал для оценки свойств информационных систем была использована универсальная нечеткая измерительная шкала (рис. 2).
Рис. 2. Распределение уровней по нечеткой универсальной шкале
Нечеткая шкала (FuzzyScale) — это набор упорядоченных нечетких переменных, представленных в виде лингвистических переменных, описывающих некоторые свойства объекта:
Матрица кодирования свойств уязвимостей и формат ее хранения
Любой способ классификации уязвимостей предполагает кодирование, поэтому одним из важных этапов классификации уязвимостей было кодирование входных данных. В качестве основного элемента мы использовали матрицу кодирования свойств уязвимостей (Coding Matrix). Она применяется для преобразования уязвимостей, полученных из базы TFS в формате XML, в текстовый DAT-файл специального формата, подаваемого на вход нейросети программы FuzzyClassificator. После построения матрицы написать скрипты (support scripts) для кодирования при помощи матрицы не составляет никакого труда. Подробнее читайте в блоге (Кодирование входных данных).
Для более эффективного обучения нейросети требовалось подобрать оптимальную матрицу, которая описывает способ кодирования наиболее значимых свойств уязвимостей, подаваемых на входы нейросети. Матрица была реализована при помощи простого JSON-файла.
Автоматизация процесса классификации уязвимостей в TeamCity
Для удобства инженеров-тестировщиков весь процесс, представленный на функциональной схеме, был автоматизирован в системе интеграции TeamCity. Часть конфигурации, приведенная на рис. 3, иллюстрирует точку входа для реализации блоков 4, 5, 6 (7) функциональной схемы.
Рис. 3. Конфигурация в TeamCity, которая запускает процесс классификации уязвимостей
После завершения процесса анализа уязвимостей TeamCity выдает текстовые файлы с отчетами по классификации уязвимостей-кандидатов и статистику с оценкой качества обучения нейросети на эталонах.
Кроме того, до получения итоговых результатов можно оценивать качество обучения нейросети по ошибкам, которые она выдает на эталонных векторах. Процесс обучения проходит в удобном для инженера формате: вся необходимая информация выводится в конфигурации Training network (см. рис. 4) в реальном времени.
Рис. 4. Вывод промежуточных результатов по качеству обучения нейросетей
Параметры на рис. 4 отражают основные показатели обучения на эталонных векторах:
Примеры отчетов
Для удобства интерпретации результатов статистика во всех отчетах разбита на отдельные блоки, т. е. на выходе инженер-тестировщик получает понятный и подробный отчет. Под спойлером представлены пояснения по каждому блоку.
В заголовке отчета Overview:
• Neuronet — используемая сеть;
• Input file with encoded vectors — файл со входными данными для обучения или классификации (в зависимости от отчета);
• Network configuration — конфигурация нейронной сети;
• Report legend — описание нечетких уровней, использующихся для оценки принадлежности уязвимости к классам подтвержденных или неподтвержденных уязвимостей.
В таблице Main statistics:
• Total classificated vectors’ count — количество обработанных уязвимостей при классификации;
• Allocation table of sorted by levels vectors’ count — таблица распределения количества векторов уязвимостей по различным нечетким уровням.
В таблице Neural network quality statistics (for ethalon vectors only):
• False classificated vectors’ count — количество ошибочно классифицированных векторов уязвимостей при обучении на эталонах, согласно правилам подсчета статистики по качеству обучения нейросети (неполное совпадение засчитывается как верный результат);
• Allocation table of sorted by levels false classificated vectors — количество ошибок классификации сгруппированных по различным нечетким уровням.
• TFSID — ссылка на уязвимость в DBCA;
• Level Confirm — результат классификации уязвимости нейросетью, показывающий степень уверенности в том, что уязвимость подтверждается;
• Level Reject — результат классификации уязвимости нейросетью, показывающий степень уверенности в том, что уязвимость не подтверждается;
• Interpreting as — как интерпретировать результат композиции двух уровней (Level Confirm, Level Reject), четкий итоговый результат классификации:
Рис. 5. Пример отчета по классификации уязвимостей-эталонов, содержащий статистику по качеству обучения нейросети
На рис. 5 представлен пример отчета по классификации уязвимостей-эталонов. Данные, полученные нейросетью после обучения (блок Classification Result), сравниваются с эталоном и выдается результат — True или False (засчитать ответ как правильный или как ложный). По итогам классификации подсчитывается число ошибочно классифицированных уязвимостей при обучении на эталонах, согласно правилу подсчета статистики по качеству обучения нейросети. Это правило мы свели в табл. 1, где указали уровни, которые можно считать правильным результатом при классификации, исходя из практических соображений.
Табл. 1. Интерпретация ответов нейросети при обучении
В ходе исследования мы пришли к выводу, что требовать от нейросети стопроцентного совпадения уровней при классификации уязвимостей невозможно, так как некоторые уровни близки по значению друг к другу. К примеру, человек, получив в результате классификации Level Reject = High вместо Max, зачтет такую уязвимость как опровергнутую. Поэтому, если результат, выданный нейросетью, «близок» к истинному значению (High вместо Max и Low/Med вместо Min), то мы считаем его правильным при обучении True (weak), если значения полностью совпадают, то True (strong). Отметим, что правила для реальных уязвимостей строже, чем для ложных, так как выявление реальных уязвимостей является более приоритетной задачей. Все остальные варианты, не указанные в таблице, считаются ложным ответом (False).
Рис. 6. Пример отчета по классификации уязвимостей-кандидатов, содержащий значения нечетких уровней и их интерпретацию
Аналогично отчету по классификации уязвимостей-эталонов выглядит отчет с результатами классификации по кандидатам. Нейросеть выдает ответ, как интерпретировать нечеткие уровни Level Confirm и Level Reject по каждой уязвимости: Confirmed, Rejected или ERROR, согласно правилам однозначной интерпретации результатов нечеткой классификации уязвимостей (см. табл. 2).
Табл. 2. Правила однозначной интерпретации результатов нечеткой классификации уязвимостей
Использование правил позволяет дать четкий ответ в понятной человеку форме: уязвимость подтверждена, опровергнута или получен неоднозначный результат классификации — ошибка. В случае ошибки требуется ручная классификация. По аналогии с правилами табл. 1, уязвимости-кандидаты нужно считать отвергнутыми, если по результатам классификации нечеткий уровень Level Reject будет высоким (Max, High), а нечеткий уровень Level Confirm средним или низким (Med, Low, Min). Соответственно уязвимость будет подтверждена при противоположных результатах. Правила для подтвержденных уязвимостей также более строгие.
Результаты исследования
Работа с нейросетью включала в себя несколько этапов — обучение на эталонах и разбор уязвимостей в рабочем режиме на новых результатах сканирования.
Разбор уязвимостей в рабочем режиме состоял из двух этапов. Первый этап включал в себя ручной разбор данных сканирования и классификацию уязвимостей. На втором этапе разобранные уязвимости были предложены нейросети, которая ранее на них не обучалась, для анализа (одновременно и в качестве кандидатов для разбора уязвимостей, и в качестве эталонов).
В рабочем режиме, при классификации ранее неизвестных уязвимостей, нейросеть выдала следующие результаты: из 2998 проанализированных уязвимостей ошибочно классифицировала 595 (19.8%).
На данный момент удовлетворены все формальные требования со стороны отдела тестирования, и мы продолжаем работать над улучшением результатов классификации: оптимизируем параметры нейросети, отсеиваем «плохие» свойства из матрицы кодирования.
Полноценное использование всех преимуществ автоматической классификации уязвимостей при помощи нейросетей ожидается в начале 2016 года. Однако уже сейчас результаты разбора уязвимостей автоматически проставляются для уязвимостей в DBCA.
На рис. 7 приведен пример типичной записи об уязвимости из DBCA, для которой нейросеть сделала правильное предположение, что эту уязвимость, найденную сканером PT AI, нужно опровергнуть как ложное срабатывание. Об этом говорят значения полей: «Level Confirm: 5 – Min», «Level Reject: 1 — Max», «Notes: Interpreting as: Reject». Аналогичным образом проставляются результаты для всех остальных уязвимостей.
Рис. 7. Запись в DBCA с результатами нейросетевой классификации
Выражаю благодарность своим коллегам: QA-инженерам Positive Technologies Владимиру Софину и Артему Юшковскому за помощь в практической реализации некоторых инструментов и огромный вклад в проведение многочисленных экспериментов, а также доценту кафедры математического анализа, алгебры и геометрии, к. пед. н. Казанского (Приволжского) федерального университета Мансуру Гильмуллину за помощь в подготовке теоретической базы для исследований и экспериментов.
Автор: Тимур Гильмуллин, к. т. н., DevOps-инженер Positive Technologies.