Функциональный состав задач

В данном разделе представлено подробное описание каждой задачи сканирования, используемой в системе. Для каждой задачи указаны входящие в неё скрипты и их назначение, а также ASCII-схема, иллюстрирующая последовательность этапов сканирования. Эта информация поможет понять, как работает сканер на каждом этапе и какой функционал реализует каждая из задач.

Маппинг сети

Описание:
Задача NETWORK_MAPPING предназначена для быстрого обзора сети и выявления активных узлов. Сканер выполняет проверку доступности заданных адресов или диапазона адресов, определяя, какие из них отвечают. Результатом является список "живых" хостов, используемый для дальнейшего, более глубокого анализа.

Скрипты:

• alive_check – проверяет доступность хоста. Посылает ICMP Echo-запросы (ping) или аналогичные сетевые запросы к целевому адресу и ожидает ответа. Если от хоста получен отклик, скрипт помечает его как активный (alive) и доступный для последующего сканирования.

Процесс сканирования (ASCII):

NETWORK_MAPPING: [alive_check] -> [Список активных узлов]

На схеме выше скрипт alive_check опрашивает указанные узлы; на выходе получается перечень хостов, ответивших на запрос.

Поиск хостов

Описание:
Задача HOST_DISCOVERY ориентирована на обнаружение хостов и основных сервисов в сети. После проверки доступности узла, сканер выполняет поиск открытых портов и определяет, какие сервисы работают на обнаруженных портах. Эта задача дает первоначальное представление о том, какие устройства доступны и какие сетевые сервисы они предоставляют.

Скрипты:

• alive_check – определяет, отвечает ли целевой хост (аналогично использованию в NETWORK_MAPPING). Только активные хосты проходят к следующим этапам.
• port_search – сканирует порты активного хоста. Проверяет набор портов (или весь диапазон) на открытость, пытаясь установить подключение. Результатом является список открытых портов на хосте.
• fingerprinting – выполняет первичную идентификацию сервисов на найденных портах. Этот скрипт собирает баннеры и базовую информацию (например, тип службы: HTTP-сервер, FTP, SSH и т.д.) для каждого открытого порта.
• fingerprinting_deep – проводит углубленную идентификацию сервисов и ОС. Использует дополнительные запросы и эвристики для определения точных версий сервисов, операционной системы и других характеристик узла. Этот скрипт может отправлять специальные пакеты/запросы (например, аналог расширенного режима Nmap) для более точного определения сервисов.

Процесс сканирования (ASCII):

HOST_DISCOVERY: [alive_check] -> [port_search] -> [fingerprinting] -> [fingerprinting_deep] -> [Информация о хосте]

Схема показывает, что для каждого узла сначала проверяется доступность (alive_check), затем ищутся открытые порты (port_search), после чего выполняется базовая (fingerprinting) и расширенная (fingerprinting_deep) идентификация сервисов.

WEB поиск

Описание:
Задача WEB_DISCOVERY нацелена на обнаружение веб-сервисов на целевом узле. Она включает этапы проверки доступности, разрешения DNS-имени (если нужно), поиска открытых портов и определение наличия веб-сервисов. В результате выполняется идентификация веб-приложений и сервисов, включая возможное обнаружение известных конфигураций через шаблоны.

Скрипты:

• alive_check – проверяет, доступен ли целевой хост (как описано ранее).
• dns_resolver – выполняет DNS-разрешение имен. Если в качестве цели указан доменное имя, этот скрипт получает соответствующий IP-адрес. Также может обрабатывать сложные случаи, например, несколько A-записей или поддомены, связанные с целью.
• port_search – сканирует порты целевого хоста. Особое внимание уделяется стандартным веб-портам (80, 443 и др.), но могут проверяться и нестандартные порты на наличие сервисов.
• http_find – определяет, какие из открытых портов отвечают как веб-сервер. Скрипт отправляет HTTP-запросы (например, HEAD или GET) на обнаруженные порты, чтобы проверить наличие HTTP/HTTPS сервисов. Результатом является список портов, где обнаружен веб-сервис.
• fingerprinting – выполняет идентификацию сервисов на открытых портах (для веб-портов — определяет тип веб-сервера, например Apache, Nginx и т.д.).
• fingerprinting_deep – углубленная идентификация. Для веб-сервисов может определять версию веб-сервера, ОС, технологии (например, версии PHP, ASP.NET и др.) с помощью дополнительных запросов и анализа ответов.
• yaml_detection – проводит обнаружение известных служб или уязвимостей на основе шаблонов (возможно, описанных в YAML-файлах). Этот скрипт сравнивает собранную информацию о сервисах с библиотекой сигнатур/шаблонов, определяя, не соответствует ли сервис какому-либо известному приложению или конфигурации. В контексте WEB_DISCOVERY он может выявлять типовые веб-приложения или настройки по сигнатурам.

Процесс сканирования (ASCII):

WEB_DISCOVERY:
[alive_check] -> [dns_resolver] -> [port_search] -> [http_find] -> [fingerprinting] -> [fingerprinting_deep] -> [yaml_detection] -> [Отчет о веб-сервисах]

На схеме видно, что после выявления активного узла и разрешения DNS (dns_resolver), сканер ищет открытые порты (port_search), проверяет наличие веб-сервисов (http_find), идентифицирует их (fingerprinting и fingerprinting_deep), а затем сопоставляет результаты с известными шаблонами (yaml_detection).

Поиск web-уязвимостей

Описание:
Задача WEB_VULN_SCAN предназначена для полномасштабного сканирования веб-приложений на уязвимости. Она сочетает в себе обнаружение веб-сервисов, сбор информации о них, аудит SSL/TLS и активное тестирование безопасности веб-приложения. Данный режим включает все этапы, необходимые для выявления известных уязвимостей веб-серверов и веб-приложений, а также для оценки актуальности используемых компонентов.

Скрипты:

• alive_check – проверяет доступность целевого узла.
• dns_resolver – разрешает доменные имена в IP (если применимо).
• port_search – находит открытые порты, где могут работать веб-сервисы.
• http_find – выявляет, какие из открытых портов являются веб-сервисами (HTTP/HTTPS).
• fingerprinting – базовая идентификация веб-сервера и окружения (тип сервера, ОС и пр.).
• fingerprinting_deep – расширенная идентификация версий веб-сервера, CMS, фреймворков. Например, может определить версию Apache/Nginx, движок сайта (WordPress, Joomla и т.д.) с помощью специфических запросов и анализа содержимого страниц.
• https_parser – анализирует параметры HTTPS-соединения. Извлекает информацию о SSL/TLS сертификате (выдан для какого домена, кем подписан, срок действия) и параметры шифрования. Этот скрипт помогает собрать данные перед последующим аудитом безопасности протокола.
• ssl_audit – выполняет аудит SSL/TLS. Проверяет набор поддерживаемых версий протоколов (SSLv2/SSLv3/TLSv1.x), шифров и алгоритмов. Выявляет небезопасные настройки: например, использование устаревших протоколов, уязвимых шифров, отсутствие поддержки PFS, уязвимость Heartbleed и пр.
• web_detect – обнаруживает веб-приложения и их компоненты. Скрипт сканирует содержимое веб-сайта (страницы, заголовки, cookies) на признаки известных веб-платформ или технологий (например, определяет CMS, используемые библиотеки JavaScript, версии платформы). Это необходимо для нацеливания последующего аудита.
• web_audit – активный аудит безопасности веб-приложения. На этом этапе сканер выполняет тесты на уязвимости: SQL-инъекции, XSS, раскрытие информации, неправильные настройки и т.д. Скрипт автоматически отправляет специально сформированные запросы и анализирует ответы, чтобы выявить уязвимое поведение. Также сюда могут входить проверки на известные уязвимости в обнаруженных CMS или компонентах.
• yaml_detection – дополнительно выполняет поиск уязвимостей и конфигураций по шаблонам (YAML). В рамках WEB_VULN_SCAN этот скрипт может использовать базу известных проблем (описанных в YAML-файлах) для быстрого выявления типичных уязвимостей или проверок, специфичных для данной веб-технологии.
• cpe_eol – проверяет идентифицированные продукты на предмет окончания срока поддержки. На основе данных о версиях (CPE – Common Platform Enumeration) определяет, не является ли веб-сервер или платформа устаревшей и не поддерживаемой производителем. Устаревшие продукты часто содержат неисправленные уязвимости, поэтому важно их выявить.
• yaml_http – выполняет проверки безопасности HTTP на основе YAML-шаблонов. Это может включать тесты конфигураций веб-сервера (например, заголовки безопасности, директивы) и известные уязвимости, для которых имеются готовые шаблоны HTTP-запросов/ответов в базе знаний.
• check_cpe – анализирует известные уязвимости по идентификаторам CPE. Сопоставляет версии обнаруженных компонентов с базой данных уязвимостей (например, CVE) через их CPE-идентификаторы. Таким образом, скрипт выявляет, какие известные уязвимости присущи обнаруженным версиям ПО на веб-сервере или веб-приложении.

Процесс сканирования (ASCII):

WEB_VULN_SCAN:
[alive_check] -> [dns_resolver] -> [port_search] -> [http_find] -> [fingerprinting] -> [fingerprinting_deep]
v
[https_parser] -> [ssl_audit] -> [web_detect] -> [web_audit] -> [yaml_detection] -> [cpe_eol] -> [yaml_http] -> [check_cpe]

Диаграмма разбита на два блока для удобства чтения: первый блок – обнаружение хоста и веб-сервисов, второй блок – детальный аудит HTTPS и веб-приложения. Все этапы выполняются последовательно: от проверки доступности до поиска уязвимостей по базам CPE.

Поиск уязвимостей приложений

Описание:
Задача APP_VULN_SCAN фокусируется на поиске уязвимостей в сетевых приложениях (не только веб). Это общесетевое сканирование уязвимостей: после обнаружения активного узла и его сервисов, система пытается выявить слабые места, такие как уязвимые версии ПО, недостаточные обновления или слабые учетные данные. Данная задача полезна для выявления уязвимостей на уровнях сервисов (баз данных, FTP, SSH, и т.п.) и операционной системы.

Скрипты:

• alive_check – проверяет, что узел активен и отвечает.
• port_search – находит открытые порты на узле, тем самым выявляя работающие сервисы.
• fingerprinting – определяет типы сервисов на открытых портах (например, БД, SSH, SMTP и т.д.).
• fingerprinting_deep – уточняет версии обнаруженных сервисов и ОС, используя расширенные методы опроса.
• cred_check – проверяет уязвимости, связанные с учетными данными. Пытается использовать известные пары логин/пароль по умолчанию или слабые пароли для обнаруженных сервисов (например, попытка входа с учетными данными по умолчанию на FTP, SSH, база данных). Успешная аутентификация свидетельствует о критической проблеме безопасности.
• inventory – собирает инвентаризационные сведения. Формирует детальную информацию о хосте: перечень сервисов, версии ПО, обнаруженное оборудование. Эта информация сохраняется для учета IT-активов и дальнейшего анализа.
• cpe_eol – проверяет, не достигли ли обнаруженные продукты конца жизненного цикла. Помечает сервисы, версии которых больше не поддерживаются производителем.
• check_cpe – сопоставляет CPE обнаруженных сервисов с базой известных уязвимостей. Выявляет CVE, связанные с версиями ПО, установленными на узле, чтобы определить, какие уязвимости присутствуют.

Процесс сканирования (ASCII):

APP_VULN_SCAN: [alive_check] -> [port_search] -> [fingerprinting] -> [fingerprinting_deep] -> [cred_check] -> [inventory] -> [cpe_eol] -> [check_cpe]

Схема показывает линейную последовательность: от обнаружения узла и сервисов до проверки учетных данных и выявления известных уязвимостей через базу CPE.

Аудит хостов

Описание:
Задача HOST_AUDIT выполняет комплексный аудит безопасности хоста. Она включает сетевое сканирование, проверку конфигураций, учетных данных и соответствие передовым практикам безопасности. Цель – выявить уязвимости на уровне операционной системы и сервисов, проверить наличие необходимых обновлений, а также обнаружить признаки принадлежности узла к домену (например, контроллеры домена).

Скрипты:

• alive_check – убеждается, что хост доступен.
• port_search – находит открытые порты и активные сервисы.
• fingerprinting – определяет типы сервисов и ОС (базовая идентификация).
• fingerprinting_deep – подробно идентифицирует версии сервисов и ОС (расширенная идентификация).
• cred_check – проверяет уязвимые учетные записи. Например, пытается подключиться по SSH/SMB/WinRM с заданными или стандартными учетными данными, если такие доступны, чтобы выявить слабые пароли или открытые доступы.
• inventory – собирает полную информацию об оборудовании и ПО хоста, сохраняя данные об установленной ОС, запущенных службах, их версиях и пр.
• check_update – проверяет актуальность обновлений на хосте. Если доступны учетные данные или открыты сервисы, позволяющие узнать версию ОС и патчей, скрипт сопоставляет информацию о системе с последними обновлениями. Цель – определить, есть ли отсутствующие патчи безопасности или обновления.
• detect_dc – определяет, является ли данный узел контроллером домена (Domain Controller) или членом домена. Для этого скрипт ищет признаки: открытые специфичные порты (LDAP, Kerberos), имя хоста, принадлежность к доменному адресу, возможность выполнения LDAP-запросов и т.д.
• audit – выполняет общий аудит уязвимостей на хосте. На основе собранной информации скрипт проверяет конфигурации и версии сервисов на известные уязвимости или неправильные настройки. Например, проверяет наличие уязвимых версий протоколов, опасных настроек (открытые общие ресурсы, анонимные сессии SMB, и т.п.), а также соответствие рекомендациям по безопасности.
• cpe_eol – отмечает компоненты, достигшие конца поддержки (EOL), аналогично использованию в предыдущих задачах.

Процесс сканирования (ASCII):

HOST_AUDIT: [alive_check] -> [port_search] -> [fingerprinting] -> [fingerprinting_deep] -> [cred_check] -> [inventory] -> [check_update] -> [detect_dc] -> [audit] -> [cpe_eol]

На схеме показано, что после сбора базовой информации (alive_check до fingerprinting_deep), сканер проверяет учетные данные (cred_check), собирает данные в инвентаризацию (inventory), анализирует обновления (check_update), определяет принадлежность к домену (detect_dc) и проводит финальный аудит уязвимостей (audit).

Инвентацизация хостов

Описание:
Задача INVENTORY_HOST служит для детального сбора информации о хосте с целью инвентаризации. В ходе её выполнения сканер идентифицирует все активные сервисы, собирает сведения о сертификатах, проверяет учетные данные и фиксирует всё обнаруженное в базе данных инвентаризации. Эта задача не столько ищет уязвимости, сколько создает полный "паспорт" системы в актуальном состоянии.

Скрипты:

• alive_check – проверяет доступность узла.
• port_search – находит открытые порты.
• http_find – определяет, есть ли на открытых портах веб-сервисы, отправляя пробные HTTP-запросы.
• fingerprinting – базовая идентификация сервисов и системы.
• fingerprinting_deep – углубленная идентификация версий сервисов и ОС.
• https_parser – если найден HTTPS-сервис, извлекает данные сертификата (доменное имя, издатель, срок действия и т.д.).
• ssl_audit – анализирует настройки SSL/TLS (не столько с целью поиска уязвимостей, сколько для сбора данных о поддерживаемых протоколах и шифрах, что тоже часть инвентарной информации).
• web_detect – выявляет технологии веб-приложений (CMS, скриптовые языки, версии фреймворков) на обнаруженных веб-сайтах.
• yaml_detection – использует шаблоны для определения известных сервисов и конфигураций, помогая заполнить информацию о ПО на хосте. Например, может распознать, что определенный баннер соответствует конкретному продукту.
• cred_check – проверяет стандартные учетные данные на сервисах, фиксируя факт наличия слабозащищенных аккаунтов, что тоже может быть частью инвентаризации (учет небезопасных настроек).
• inventory – финальный сбор всех полученных сведений в единый отчет об оборудовании. Записывает информацию обо всех обнаруженных сервисах, их версиях, сертификатах, принадлежности к веб-приложениям, и т.д., чтобы учесть этот хост в общем реестре.

Процесс сканирования (ASCII):

INVENTORY_HOST: [alive_check] -> [port_search] -> [http_find] -> [fingerprinting] -> [fingerprinting_deep] -> [https_parser] -> [ssl_audit] -> [web_detect] -> [yaml_detection] -> [cred_check] -> [inventory]

На схеме изображена цепочка действий для инвентаризации хоста: после определения доступности и сервисов, сканер собирает подробные данные о каждом сервисе, включая SSL-сертификаты и веб-технологии, проверяет учетные записи, а затем все фиксирует.

DC аудит

Описание:
Задача DC_AUDIT специально предназначена для аудита контроллеров домена (Domain Controller) и проверки их безопасности. В её рамках система определяет, что целевой узел является контроллером домена, а затем проводит ряд проверок, связанных с типичными уязвимостями и конфигурациями Active Directory. Необходимо наличие соответствующих учетных данных или доступа, чтобы получить детальную информацию о настройках домена.

Скрипты:

• alive_check – проверяет, доступен ли контроллер домена в сети.
• cred_check – проверяет возможность подключения с заданными учетными данными. Для аудита контроллера домена, как правило, используются доменные учетные данные. Скрипт пытается установить соединение (например, через LDAP/SMB) с использованием предоставленных учетных записей, чтобы убедиться, что доступ разрешен.
• identification – собирает общую информацию о домене и контроллере. Определяет имя домена, роли контроллера, версию ОС контроллера домена, а также базовые настройки AD. Этот скрипт может выполнять LDAP-запросы для получения информации о доменной структуре.
• detect_dc – подтверждает, что узел действительно является контроллером домена. Проверяет специфичные признаки: открытые порты LDAP (389) и Global Catalog, наличие служб Active Directory. (В некоторых случаях detect_dc может выполняться до identification или совместно, но логика в том, чтобы точно классифицировать узел как DC.)
• dc_audit – выполняет специализированный аудит безопасности контроллера домена. Проверяются настройки, которые влияют на безопасность AD: разрешены ли анонимные запросы LDAP, настроены ли безопасные каналы, правильные ли параметры шифрования Kerberos, наличие уязвимостей типа Zerologon, проверка слабых конфигураций в политике паролей и др. Этот скрипт собирает информацию о критичных параметрах AD и сопоставляет их с лучшими практиками безопасности.

Процесс сканирования (ASCII):

DC_AUDIT: [alive_check] -> [cred_check] -> [identification] -> [detect_dc] -> [dc_audit]

На схеме видно, что сначала проверяется доступность контроллера и учетных данных, затем идентифицируется доменная роль, и после подтверждения типа узла (detect_dc) выполняется углубленный аудит параметров безопасности AD.

Полное сканирование

Описание:
Задача FULL_SCAN является наиболее всеобъемлющей – это полный скан, объединяющий проверки сети, хоста и веб-приложений. FULL_SCAN последовательно выполняет все этапы: от обнаружения узла и его сервисов до детального аудита всех найденных компонентов (включая веб-сайты). Данный режим дает максимальное покрытие, выявляя как сетевые, так и прикладные уязвимости, проблемы конфигурации, устаревшее ПО и другие риски безопасности.

Скрипты:

• alive_check – проверка, доступен ли узел.
• dns_resolver – разрешение DNS-имени (если цель задана как доменное имя).
• port_search – сканирование портов.
• http_find – обнаружение веб-сервисов на найденных портах.
• fingerprinting – базовая идентификация сервисов и ОС.
• fingerprinting_deep – расширенная идентификация версий сервисов и ОС.
• https_parser – извлечение информации о SSL-сертификатах на HTTPS-портах.
• ssl_audit – аудит SSL/TLS конфигурации.
• cred_check – проверка уязвимых учетных данных на сервисах.
• inventory – сбор инвентарной информации (список сервисов, версия ОС, оборудование).
• check_update – проверка актуальности обновлений ОС и приложений.
• detect_dc – определение роли узла (контроллер домена или нет).
• audit – общий аудит уязвимостей (на основе конфигураций, версий и известных проблем).
• web_detect – определение веб-технологий и платформ.
• web_audit – активное сканирование веб-приложения на уязвимости.
• yaml_detection – выявление сервисов/уязвимостей по шаблонам (YAML) для всех типов сервисов.
• cpe_eol – отметка компонентов, достигших конца поддержки, по всем обнаруженным CPE.
• yaml_http – проверки веб-сервера по YAML-шаблонам (конфигурации, типовые уязвимости).
• check_cpe – сопоставление всех обнаруженных CPE с базой известных уязвимостей (CVE).

Процесс сканирования (ASCII):

FULL_SCAN: [alive_check] -> [dns_resolver] -> [port_search] -> [http_find] -> [fingerprinting] -> [fingerprinting_deep] |
|______________ последовательное сканирование ________________|
v [https_parser] -> [ssl_audit] -> [cred_check] -> [inventory] -> [check_update] -> [detect_dc] -> [audit] v [web_detect] -> [web_audit] -> [yaml_detection] -> [cpe_eol] -> [yaml_http] -> [check_cpe]

На ASCII-схеме выше отражена комплексная последовательность FULL_SCAN. Сначала выполняются шаги сетевого сканирования (alive_check до fingerprinting_deep). Затем параллельно показаны два направления: одно – аудит хоста (https_parser, ssl_audit и далее по цепочке до audit), другое – аудит веб-приложения (web_detect, web_audit и далее). В реальности этапы выполняются последовательно, охватывая как сетевые сервисы, так и веб-компоненты. Финальные шаги (yaml_detection, cpe_eol, yaml_http, check_cpe) обрабатывают собранную информацию, выявляя шаблонные уязвимости и сопоставляя данные с известными проблемами.