Методы оценки защищенности корпоративных сетей

Методы оценки защищенности корпоративных сетей

Больше не работает модель «поставил фаервол и успокоился». Данные исследований Positive Technologies за 2024-2025 годы рисуют удручающую картину: 85% компаний до сих пор используют незащищенные протоколы передачи данных. Это как закрыть дверь на ключ, но оставить открытой форточку - злоумышленники лезут именно туда.

Активность вредоносного ПО фиксируется в каждой второй организации (46%), причем в 82% случаев это майнеры, которые жрут ресурсы инфраструктуры и палят железо. Но самое страшное не это. Самое страшное - устаревшие уязвимости вроде EternalBlue (CVE-2017-0144) до сих пор валят корпоративные домены, как это случилось при пентесте одной фармкомпании.

Анализ защищенности сетей это не галочка для регулятора. Это единственный способ понять, где твоя сеть уже дырявая, а где просто ждет своего часа.

Классификация уязвимостей: от OSI до OWASP

Сетевые протоколы уязвимы на каждом уровне модели OSI. На прикладном уровне (HTTP, SMTP, LDAP) перехватывают учетные данные - 69% компаний передают логины и пароли по HTTP, половина - по LDAP в открытом виде. Это не баги, это архитектурные дыры, заложенные еще в 90-е.

На транспортном уровне - TCP и UDP - классика: SYN-flood, сессионные атаки. Сетевой уровень (IP, ICMP) страдает от маршрутизационных атак и подделки ICMP-сообщений. Канальный уровень (ARP, MAC) - отравление ARP-кэша, перехват трафика в локальной сети.

Для веб-сервисов актуален OWASP Top 10 2025. Лидирует Broken Access Control - сломанное управление доступом, когда обычный пользователь может дернуть API-запрос и получить админские права. За ним следуют Security Misconfiguration (незакрытые порты, дефолтные пароли на phpMyAdmin) и Software Supply Chain Failures - зараженные библиотеки и компоненты.

Ключевой момент: уязвимости группируются не только по типу, но и по зоне доступности. Внешний периметр веб-морды, VPN-шлюзы, публичные API. Внутренняя сеть - контроллеры домена, файловые шары, серверы баз данных. DMZ - демилитаризованная зона, где живут веб-серверы и почтовики, доступные извне, но изолированные от ядра. Каждая зона требует своего подхода.

Уровень OSI Типовые протоколы Распространенные уязвимости Частота встречаемости Метод атаки
Прикладной (7) HTTP, LDAP, SMTP Перехват учетных данных 69% по HTTP Сниффинг, MITM
Транспортный (4) TCP, UDP SYN-flood, отказ в обслуживании Высокая Флуд, сессионные атаки
Сетевой (3) IP, ICMP Маршрутизационные атаки Средняя ICMP-редирект
Канальный (2) ARP, MAC Отравление ARP-кэша 54% компаний Перехват локального трафика

Внешний периметр: входные двери для хакера

Сканирование внешнего периметра первая линия обороны. Начинается с разведки: кто ты, какие у тебя IP-адреса (и IPv4, и IPv6, о котором многие забывают), субдомены, DNS-записи. Злоумышленники используют Amass, Subfinder, массово шарят по Certificate Transparency logs, находят забытые тестовые поддомены с админками.

Пример из практики: при тестировании фармацевтической компании нашли устаревшую CMS с известной дырой, через нее получили доступ к файловой системе, а там - phpMyAdmin без пароля. Дальше - создание админа CMS, заливка веб-шелла, получение удаленного доступа. Сервер оказался на CentOS с древним ядром, где один эксплойт повышения привилегий дал рута. А рут имел сетевой интерфейс во внутреннюю сеть. Game over.

Для внешнего анализа критически важно:

  • Проверять все публичные сервисы: веб-приложения, VPN, SSH-шлюзы, почтовые сервера, облачные хранилища.
  • Использовать актуальные базы уязвимостей, включая CISA KEV (Known Exploited Vulnerabilities) - список дыр, которые уже эксплуатируют прямо сейчас.
  • Не доверять автоматическим сканерам на 100%. Они дают много ложных срабатываний и пропускают логические баги. Ручная валидация критических находок обязательна.

Новая методика ФСТЭК (утверждена 25 ноября 2025) требует внешнего сканирования (С1) в обязательном порядке при аттестации информационных систем. Сроки жесткие: для интернет-доступных ресурсов уязвимости критического уровня нужно закрывать в течение трех календарных дней.

Внутренний периметр: ад с Legacy-системами

Внутренняя сеть часто защищена хуже внешнего периметра. Логика простая: «за фаерволом мы в безопасности». Но атакующий уже внутри - через фишинг, скомпрометированный VPN, веб-шелл на демилитаризованной зоне.

При внутреннем тестировании фармкомпании специалисты запустили Nmap и Metasploit и быстро нашли узлы с EternalBlue. Один из них оказался резервным контроллером домена на устаревшей Windows Server. Эксплуатация дала nt authority/system, дамп NTDS.dit со всеми хэшами пользователей, а Hashcat восстановил пароли за пару часов. Парольная политика была никакой.

Дополнительно через BloodHound нашли пароль админа домена в открытом виде в профиле учетки. Потом - уязвимость в IPMI, которая отдала хэш администратора системы виртуализации. Подобрали пароль, зашли на гипервизор, получили полный контроль над всеми виртуалками, включая базы 1С.

Внутренний анализ по методике ФСТЭК (С2) требует проверки:

  • Серверов (доменконтроллеры, терминальные фермы, СУБД, 1С, веб-серверы)
  • Сетевого оборудования (коммутаторы, маршрутизаторы, межсетевые экраны)
  • Средств защиты информации (антивирусы, DLP, SIEM)
  • Рабочих станций (допускается выборка 30% однотипных машин)

Типичные внутренние проблемы: необновленные ОС, слабые пароли, использование LLMNR и NetBIOS (54% компаний) - эти протоколы позволяют перехватывать Net-NTLMv2 хэши, использование программ удаленного доступа (85% компаний) - AnyDesk, TeamViewer, которые атакующие обожают за легитимность.

Незащищенные протоколы: трафик как открытая книга

Исследования PT Network Attack Discovery показывают: 69% компаний передают учетные данные по HTTP, 50% - по LDAP, 35% - по SMTP/POP3/IMAP без шифрования. Это катастрофа.

HTTP - логин:пароль в открытом виде. LDAP - то же самое, плюс вся иерархия домена. SMTP - вся корпоративная почта, включая вложения, доступна любому, кто получил доступ к сети (или поднял фейковую точку доступа в офисе).

Что делать? Переходить на HTTPS, SLDAP (LDAP over TLS), Kerberos, SFTP/SSH вместо FTP/telnet. Для почты - обязательный STARTTLS или полный переход на Exchange с шифрованием. ФСТЭК требует устранения уязвимостей высокого и критического уровней в первую очередь. Использование незащищенных протоколов классика высокого уровня.

Инструментарий и методология: чем сканировать и как не наделать глупостей

Автоматические сканеры - база. Сравнение эффективности четырех популярных инструментов (Nessus, Acunetix, OWASP ZAP, BeSECURE) на 67 веб-приложениях показало: OWASP ZAP лидирует по полноте обнаружения и стабильности результатов, а Nessus лучше находит критические и высокие уязвимости. Лучшая связка - использовать несколько сканеров параллельно, их результаты дополняют друг друга.

Но сканеры тупые. Они не проверят бизнес-логику, не увидят, что можно подменить ID заказа в API и посмотреть чужие данные. Поэтому после автоматизации - ручная валидация:

  1. Для каждой критической находки - воспроизвести атаку, сделать скриншоты, сохранить pcap-логи.
  2. Проверить, не сработала ли ложноположительная сработка (например, сканер нашел уязвимость в старой версии библиотеки, но она задетектирована и не используется).
  3. Оценить реальную эксплуатируемость с учетом контекста: сетевая сегментация, наличие IDS/IPS, права доступа.

Новая FedRAMP-методология RFC-0012 (внедряется в США, но задает тренды) отказывается от чистой CVSS-оценки в пользу контекстного приоритизирования. Учитываются: достижимость уязвимости из интернета, наличие эксплойта в открытом доступе, критичность актива для бизнеса. Уязвимость с CVSS 7.0, которая висит на изолированном тестовом сервере без важных данных, может быть менее приоритетной, чем CVSS 5.5 на публичном шлюзе с доступом к платежной информации.

Методика ФСТЭК требует оценки критичности по собственной шкале (утверждена 30 июня 2025). Уязвимости критического и высокого уровня - обязательны к устранению. Средние и низкие - экспертная оценка с решением: чинить или мониторить.

Практические шаги: от сканирования до закрытия

 Планирование и согласование. Определить scope: какие IP-адреса, подсети, сервисы проверяем. Согласовать окна тестирования (чтобы не положить production случайным эксплойтом). Для внешнего теста - подписать разрешение от руководства, иначе это уголовное дело за несанкционированный доступ.

  • Сбор информации. WHOIS, DNS-записи, Certificate Transparency logs, ASN-сети. Сканирование портов (Masscan, Naabu). Обнаружение активных хостов и сервисов.
  • Автоматизированное сканирование. Запуск сканеров уязвимостей с актуальными подписками. Обязательно - аутентифицированное сканирование (сканер логинится в систему и проверяет глубже). Сохранение конфигураций для воспроизводимости.
  • Ручная валидация и эксплуатация. Подтверждение критических уязвимостей. Попытка реального проникновения (пентест) или контролируемая эксплуатация (как в примере с EternalBlue). Сбор доказательной базы.
  • Отчетность и закрытие. Два отчета: для бизнеса (бизнес-влияние, сроки, риски) и для технических специалистов (CVE, CVSS v4.0, пути воспроизведения, рекомендации по фиксу). Повторное сканирование после исправлений.
  • Непрерывный процесс. Разовое сканирование - мусор. Уязвимости появляются каждый день. Нужны ежеквартальные сканирования, сканирования после изменений инфраструктуры, подключение к Threat Intelligence лентам (CISA KEV, vendor advisories).

Регуляторные требования: ФСТЭК, 117-й приказ и новая методика

25 ноября 2025 года ФСТЭК утвердила Методику анализа защищенности информационных систем. Документ обязателен при аттестации объектов информатизации, контроле уровня защищенности гостайны и оценке соответствия.

Ключевые положения:

  • Анализ уязвимостей делится на внешнее (С1) и внутреннее (С2) сканирование.
  • Проводить работы могут либо штатные специалисты заказчика с ТЗКИ, либо лицензиаты ФСТЭК.
  • Критичность - по методике ФСТЭК от 30 июня 2025.
  • Уязвимости критического и высокого уровня - устранять обязательно. Средние и низкие - по экспертной оценке.
  • Для однотипных АРМ можно проверять только 30% выборки.
  • Выходные документы: отчет, перечень уязвимостей с критичностью, рекомендации, результаты повторного анализа, итоговое заключение.

С 1 марта 2026 вступает в силу приказ №117: все государственные организации обязаны проводить контроль уровня защищенности минимум раз в три года или после инцидента. Отчет - во ФСТЭК.

Практический вывод: готовьтесь к жесткому регулированию. Если вы госорган или работаете с гостайной - выделяйте бюджет на регулярные пентесты и анализ защищенности. Если вы коммерческая компания - хотя бы добровольно следуйте этим стандартам, потому что атакующим плевать на ваш статус.