Серверная комната ночью с тремя мониторами, отображающими топологию сети и код уязвимости CVE-2024-3400. Стойка с межсетевым экраном светится янтарными индикаторами в сине-зелёном полумраке.


На последнем external-engagement для финтех-компании первые 40 минут разведки через Shodan дали 14 экспонированных management-интерфейсов edge-устройств. Три - Palo Alto GlobalProtect с PAN-OS без актуальных патчей, два - Ivanti Connect Secure с открытым admin-порталом, четыре - cPanel на нестандартных портах. Ни один из этих интерфейсов не должен был торчать наружу. За полтора дня - pre-auth RCE на двух устройствах и полный доступ к management plane файрвола без единой учётной записи. Тестирование на проникновение инфраструктуры периметра сегодня сводится к одному вопросу: какие edge-устройства экспонированы и насколько оперативно на них ставят патчи. Ниже - конкретные техники пентеста периметра сети для трёх наиболее часто встречающихся классов устройств.

Эксплуатация периметровых устройств: место в kill chain и выбор вектора​

При внешнем пентесте edge-устройства - первая точка контакта. В терминах MITRE ATT&CK работаем на стыке Initial Access и Credential Access: эксплуатация уязвимостей сетевого оборудования (Exploit Public-Facing Application) и перебор учётных данных - Brute Force (T1110, Credential Access). Если эксплуатация удалась, следующий шаг - Remote Services (T1021, Lateral Movement): через скомпрометированный VPN-шлюз или файрвол атакующий попадает во внутреннюю сеть.

Принципиальное отличие от пентеста веб-приложений: периметровые устройства крутятся на проприетарных ОС (PAN-OS, Ivanti OS) с ограниченным набором инструментов post-exploitation. Нет привычного PowerShell - приходится работать с тем, что есть на устройстве. Иногда это busybox и больше ничего.

Выбор вектора зависит от результатов разведки. Decision tree из практики:

УсловиеВекторИнструментКонтекст
GlobalProtect portal на 443/tcpCVE в PAN-OS (path traversal, command injection)Nuclei + кастомный шаблонВнешний пентест, непатченные версии
Ivanti Connect Secure на 443/tcpPre-auth RCE цепочка (auth bypass + injection)curl + Burp Suite ProВнешний пентест, legacy и непатченные
cPanel на 2083/2087Auth bypass, CSRF, brute force WHMNuclei + Burp SuiteВнешний пентест, shared hosting
Management UI на нестандартном портуDefault credentials, config dumpnmap NSE + hydraВнешний пентест, legacy-конфигурация
Неизвестный сервисFingerprinting, CVE lookupnmap + searchsploitBlack box, любой контекст

Уровень шума у разных векторов отличается кардинально. Brute force через Hydra - тысячи записей в auth.log. Эксплуатация CVE через один HTTP-запрос - один GET/POST, который теряется в потоке легитимного трафика. Угадайте, что выбирает атакующий.

Приоритизация целей при пентесте межсетевого экрана и VPN-шлюзов:

УстройствоВероятность RCEСложность эксплуатацииУровень шумаЦенность для атакующего
Palo Alto PAN-OSСредняя (при наличии CVE)СредняяНизкий (single request)Критическая (internal routing)
Ivanti Connect SecureВысокая (частые CVE)Средне-высокая (цепочка)Низкий-среднийКритическая (VPN → internal)
cPanel/WHMНизкая (auto-update)Низкая (brute force, XSS)Высокий (при brute force)Средняя (hosting, не corp)

Требования к окружению​

Перед практическими шагами - минимальный стек для проверки файрвола на уязвимости и атак на edge-устройства:

ПараметрМинимумРекомендуется
ОСKali Linux 2024.x+ / Parrot OS 6.xKali на выделенном VPS
RAM4 ГБ8 ГБ
CPU2 ядра4 ядра
Диск30 ГБ50 ГБ
СетьСтатический внешний IP, VPSОтдельный VPS на каждый engagement
API-ключиShodan (free)Shodan membership + Censys API

Рабочая машина - вне корпоративной сети заказчика. Если сканировать с внутреннего IP, firewall rules для внутреннего трафика могут отличаться - результаты будут нерепрезентативны. Проверено: на одном проекте внутренний скан показал «всё чисто», а с внешнего VPS нашлось шесть management-интерфейсов.

Сравнение инструментов для пентеста периметра сети:

ИнструментЗадачаПреимуществоОграничениеКогда не использовать
nmap 7.94+ (активно поддерживается)Fingerprinting, port scanГибкость, NSE-скриптыМедленный на /16 диапазонахПассивная разведка
Nuclei (ProjectDiscovery, активно поддерживается)CVE matching, mass checkСкорость, обновляемые шаблоныТолько сигнатурная проверкаЛогические баги
Burp Suite ProManual web testingГлубина анализаТолько ручная работаМассовое сканирование
Metasploit Framework (Rapid7, nightly builds)Exploit verificationГотовые модулиВысокий шум в логахStealth-операции
Shodan/CensysПассивная разведкаНулевой шумДанные могут быть устаревшимиАктуальный fingerprint

Разведка периметровых устройств: от Shodan до fingerprinting​

Reconnaissance - самая тихая и самая информативная фаза при пентесте периметра сети. Для атак на edge-устройства нужен точный fingerprint: вендор, продукт, версия. От этого зависит весь дальнейший план.

Пассивная разведка через Shodan и Censys​

Shodan и Censys индексируют баннеры сервисов на публичных IP-адресах. Для поиска конкретных устройств:
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Nuclei для массовой проверки CVE сетевого оборудования​

После fingerprinting - массовая проверка на известные уязвимости:
Bash:
nuclei -l targets.txt \
  -t nuclei-templates/http/technologies/paloalto/ \
  -t nuclei-templates/http/technologies/ivanti/ \
  -t nuclei-templates/http/cves/ \
  -severity critical,high -o results.txt
Nuclei проверяет наличие CVE по характерным паттернам ответа: специфические заголовки, коды ошибок, версии в HTML. На выходе - список хостов с подтверждёнными уязвимостями для фазы эксплуатации.

Ограничение, о котором стоит помнить: Nuclei работает по сигнатурам. Если вендор изменил формат ответа в новой версии - шаблон не сработает. Кастомные шаблоны под конкретный engagement - не роскошь, а необходимость. На одном проекте стандартный шаблон для Ivanti молчал, а ручной запрос к /dana-na/ вернул версию, уязвимую к CVE-2023-46805.

Уязвимости Palo Alto PAN-OS: атаки на GlobalProtect и management plane​

Palo Alto - один из самых распространённых файрволов на enterprise-периметре. Attack surface при внешнем пентесте: GlobalProtect portal/gateway (443/tcp), management web UI (443 или кастомный порт), SSH management (22/tcp).

Вектор атаки: CVE в GlobalProtect​

CVE-2024-3400 (CVSS 10.0 Critical, CISA KEV с 12.04.2024, активно используется в ransomware-кампаниях) - показательный пример того, что ищут при пентесте PAN-OS: arbitrary file creation через path traversal в значении SESSID cookie. Контролируемое имя файла создаётся в /var/log/pan/, после чего cron-задача device telemetry парсит имена файлов через shell - command injection с правами root, без аутентификации. Условие эксплуатации: включённый GlobalProtect gateway или portal. Изначально Palo Alto указывал device telemetry как обязательное условие (механизм исторически связан с telemetry-pipeline), но позже advisory обновили: telemetry не требуется для успешной атаки - достаточно включённого GlobalProtect gateway или portal. Cloud NGFW, Panorama и Prisma Access не затронуты.

[Применимо: внешний пентест, on-prem PAN-OS с включённым GlobalProtect gateway, непатченные версии PAN-OS 10.x/11.x]

Типичный workflow при обнаружении уязвимого GlobalProtect:
  1. Fingerprint версии PAN-OS через SSL-сертификат и HTTP-заголовки
  2. Проверка наличия CVE через Nuclei или ручной запрос к специфичному endpoint
  3. Верификация эксплуатабельности - отправка безопасного payload (DNS-callback через curl или Burp Collaborator) для подтверждения RCE без деструктивных действий
  4. Документирование PoC с timestamps для отчёта
После получения RCE на файрволе: доступ к конфигурации (routing table, VPN-пулы, internal subnets), возможность дампа учётных данных из GlobalProtect auth, проброс трафика во внутреннюю сеть. Полная цепочка от интернета до internal LAN через одно устройство. Один запрос - и ты внутри.

Ограничения и реальность​

Встретить непропатченный CVE-2024-3400 на production-файрволе крупной компании в 2026 году маловероятно - патч давно вышел. Но management-интерфейсы PAN-OS на нестандартных портах, доступные из интернета, - встречаются регулярно. Тут работает вектор с default credentials и brute force (T1110). Дефолтный admin/admin - редкость, но слабые пароли типа PaloAlto123! - обычное дело. На трёх из пяти engagement'ов с Palo Alto в прошлом году пароль подбирался за первые 500 попыток.

DISA выпустила Palo Alto Networks NDM STIG - набор требований к безопасной конфигурации. Среди ключевых: запрет доступа к management plane из untrusted зон, обязательный HTTPS с валидным сертификатом, ограничение попыток аутентификации. На пентесте проверяю соответствие STIG baseline - каждое отклонение = потенциальный вектор.

Если файрвол прикрыт WAF (CloudFlare, Akamai перед GlobalProtect) - часть exploit'ов блокируется на уровне WAF-правил. Но path traversal в теле POST-запроса WAF пропускает чаще, чем аналогичный паттерн в URL. WAF смотрит на URL, а payload лежит в body - классика.

Ivanti Connect Secure: уязвимости VPN-шлюзов на периметре​

Ivanti Connect Secure (бывший Pulse Connect Secure) - SSL VPN, который за последние годы стал рекордсменом по количеству критических CVE на периметре. Ivanti EPMM (Endpoint Manager Mobile) - смежный продукт с собственной историей дыр. Оба продукта объединяет неприятный паттерн: критические CVE появляются быстрее, чем организации успевают патчить.

Pre-auth RCE цепочки​

Ivanti Connect Secure неоднократно подвергался атакам через цепочки: auth bypass + command injection = pre-auth RCE. Типичный сценарий: первая уязвимость - authentication bypass через path traversal в web-компоненте (CVE-2023-46805), вторая - command injection в API-endpoint, требующая прав администратора (CVE-2024-21887, CVSS 9.1, PR:H), которые достигаются через первый bypass. Две уязвимости по отдельности - неприятность. Вместе - катастрофа.

[Применимо: внешний пентест, black box, непропатченные версии Ivanti Connect Secure]

Workflow при эксплуатации:
  1. Определение версии через HTTP-заголовки или URL-паттерны - /dana-na/auth/url_default/welcome.cgi возвращает подсказки о версии в HTML
  2. CVE-matching через Nuclei с шаблонами по Ivanti
  3. Ручная верификация через Burp Suite: crafted запрос к уязвимому endpoint
  4. Подтверждение RCE через out-of-band callback (DNS или HTTP)

Разница между лабой и продакшном​

В лабораторных условиях эксплуатация Ivanti проходит чисто: уязвимая версия, exploit, shell. В production три фактора меняют картину.

Ivanti Integrity Checker Tool (ICT) - утилита проверки целостности файловой системы. Если blue team запускает её регулярно, любые модификации обнаруживаются. Но ICT сама имела уязвимости, позволявшие обойти проверку. Ирония: инструмент верификации целостности сам не проходит верификацию. Вопрос - какая версия ICT стоит на конкретном устройстве.

Балансировка и кеширование - если перед VPN стоит L7 балансировщик, он может модифицировать запросы и ломать exploit-цепочку. На одном engagement Ivanti за F5 BIG-IP не поддавался эксплуатации из-за перезаписи Content-Length заголовка. Пришлось менять подход.

Forensic artifacts - при эксплуатации Ivanti на устройстве остаются следы в /data/runtime/logs/. Если SOC мониторит эти логи через syslog forwarding - компрометация обнаруживается быстро. Если не мониторит (а так бывает часто) - нет.

На практике: старые CVE в Ivanti Connect Secure встречаются на периметре у организаций с медленным patch-циклом - госсектор, промышленность. Каждая волна уязвимостей сопровождается mass-exploitation кампаниями, что подстёгивает даже медленные организации патчить быстрее. Но окно между disclosure и patch - от нескольких дней до нескольких недель - остаётся. И в этом окне работают все: от APT до script kiddies.

Проверка cPanel на уязвимости: атаки на веб-панель управления​

cPanel - не файрвол в привычном смысле, но это management-интерфейс, который часто торчит наружу на периметре хостинговых компаний. Веб-интерфейсы на портах 2083 (cPanel user), 2087 (WHM admin), 2095/2096 (webmail) - обширная attack surface с десятками endpoint'ов.

Attack surface и типичные векторы​

cPanel работает на Linux (CentOS/AlmaLinux/CloudLinux), management daemon cpsrvd обрабатывает запросы ко всем портам. Основные векторы при внешнем пентесте:

Brute force WHM - порт 2087 с WHM Login. cPanel предоставляет cPHulk Brute Force Protection, но он не всегда включён по умолчанию. Проверяю первым делом: активирован ли cPHulk, какой порог блокировки, есть ли whitelist. cPHulk обходится ротацией IP через прокси-пул, но это резко увеличивает шум в логах. Компромисс: 10-15 попыток с одного IP, пауза, следующий IP.

XSS и CSRF - cPanel как огромное веб-приложение с сотнями endpoint'ов исторически уязвимо к stored XSS и CSRF. Через CSRF на WHM можно создать аккаунт с root-привилегиями, если администратор перейдёт по ссылке. Анализирую в Burp Suite: все формы, API-вызовы, проверку CSRF-токенов.

API-endpoint'ы без аутентификации - cPanel предоставляет UAPI и legacy API2. Misconfiguration в настройках API tokens может открыть endpoint'ы для неаутентифицированных запросов. Проверяю через curl обращения к типовым API-путям без авторизации.

Webmail как точка входа - Roundcube или Horde на портах 2095/2096. Credential stuffing на webmail даёт доступ к почте, оттуда - к password reset для других сервисов на том же хостинге. Цепочка неочевидная, но работает.

Ограничения​

[Применимо: внешний пентест, shared hosting, cPanel/WHM актуальных версий]

cPanel активно патчит критические уязвимости через auto-update. Большинство production-серверов получают обновления автоматически в течение 24-48 часов. Эксплуатация известных CVE в cPanel - скорее исключение. Основной результат пентеста - misconfiguration: слабые пароли, открытые API, устаревшие модули.

Против cPanel не работает подход «CVE → exploit → shell». Тут больше ручной работы: анализ логики аутентификации, проверка access controls между аккаунтами shared hosting, поиск privilege escalation от обычного пользователя до reseller или root. По сути, полноценный web application pentest - но для панели управления хостингом.

Как SOC детектирует разведку и эксплуатацию edge-устройств​

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

Sigma-правила для brute force на периметре

Перебор учётных данных (T1110) - самый шумный вектор. В репозитории SigmaHQ - 40 правил для детекции brute force. Для edge-устройств релевантны правила на уровне authentication logs: Palo Alto PAN-OS пишет события аутентификации в syslog, где Sigma-правило отловит серию auth failed за короткий интервал. Концептуальный пример:
YAML:
title: Multiple Failed Auth on Edge Device
logsource:
  category: authentication
  product: paloalto
detection:
  selection:
    outcome: failure
  condition: selection | count(src_ip) by dst_ip > 10
  timeframe: 5m
level: high
tags:
  - attack.credential_access
  - attack.t1110
Это пример для демонстрации концепции - на практике его нужно адаптировать под конкретный формат syslog и SIEM. Но логика понятна: больше 10 фейлов с одного IP за 5 минут - алерт.

D3FEND: аномальная детекция​

MITRE D3FEND описывает защитные техники, сопоставленные с ATT&CK. Для T1110 (Brute Force) релевантны:
  • Protocol Metadata Anomaly Detection (D3-PMAD) - обнаружение аномалий в метаданных: нетипичный User-Agent в запросах к GlobalProtect, необычная частота обращений к auth endpoint
  • User Geolocation Logon Pattern Analysis (D3-UGLPA) - если пентестер работает с VPS в Нидерландах, а легитимные админы логинятся из Москвы, geo-anomaly сработает сразу
  • Credential Compromise Scope Analysis (D3-CCSA) - анализ масштаба компрометации учётных данных
Для T1021 (Remote Services): Network Traffic Signature Analysis (D3-NTSA) и Client-server Payload Profiling (D3-CSPP) - анализ payload'ов в сетевом трафике, детекция нетипичных SSH-сессий или VPN-туннелей от скомпрометированного устройства.

Что SOC обычно пропускает​

А вот тут начинается самое интересное. Одиночный HTTP-запрос, эксплуатирующий pre-auth RCE (path traversal в GlobalProtect или injection в Ivanti CGI), практически не детектируется стандартными средствами. Он выглядит как легитимный GET/POST к VPN-порталу. IDS типа Suricata может поймать известную сигнатуру, но exploit с минимальной модификацией (обфускация пути, изменение encoding) обходит сигнатуры.

Детекция на уровне самого устройства эффективнее: Palo Alto пишет events в threat log, Ivanti - в системные логи. Но если SOC не настроил forwarding этих логов в SIEM - слепая зона. По опыту: на ряде engagement'ов логи edge-устройств не попадают в централизованный мониторинг. Устройство скомпрометировано, а SOC узнаёт об этом через неделю из отчёта пентестера. Неловко получается.

Чеклист: проверка файрвола на уязвимости по шагам​

Итоговый чеклист для внешнего пентеста периметровых устройств - формат для включения в отчёт:
  1. OSINT-разведка - Shodan/Censys по IP-диапазону заказчика. Зафиксировать management-интерфейсы, версии, сертификаты
  2. Активное сканирование - nmap с -sV -sC по расширенному списку портов (443, 4443, 8443, 10443, 2083, 2087, 22). Результаты в -oA формате
  3. Fingerprinting - определить вендор и версию по HTTP-заголовкам, SSL-сертификатам, HTML login-страниц
  4. CVE matching - Nuclei с шаблонами critical,high. Параллельно ручной поиск в NVD и Exploit-DB по версиям
  5. Проверка аутентификации - тест на default credentials по вендору, оценка устойчивости к brute force (lockout, rate limiting, captcha)
  6. Эксплуатация CVE - только после согласования scope. Верификация через OOB-callback, не через деструктивные payload'ы
  7. Configuration audit - соответствие DISA STIG (Palo Alto NDM), доступность management plane из untrusted зон, TLS-конфигурация
  8. Lateral movement assessment - при доступе к устройству: оценка возможности проникновения через routing/VPN/NAT конфигурации
  9. Документирование - timestamps, скриншоты, полные команды. PoC без деструктива. Рекомендации по NIST SP 800-53 (AC-1, IA-1, CM-1)
  10. Ретест - через 30-60 дней после передачи отчёта: верификация устранённых уязвимостей
Три года назад пентест периметра сводился к «сканируем nmap, ищем открытые порты, пробуем default пароли». Сейчас attack surface edge-устройств - полноценные веб-приложения с API, микросервисами и интеграциями. Подход должен быть соответствующим: не только сканер уязвимостей, а полноценный web application pentest для каждого management-интерфейса на периметре.

Главная проблема - не отсутствие патчей. Патчи ставят. Проблема в том, что management-интерфейсы оказываются доступны из интернета «временно» и остаются там навсегда. На каждом втором engagement нахожу web UI файрвола, который «открыли для удалённой настройки подрядчиком» и забыли закрыть. DISA STIG, best practices Palo Alto, рекомендации Ivanti - все говорят одно: management plane не должен быть доступен из untrusted зон. Но между документом и реальной конфигурацией - пропасть, и именно в этой пропасти работает пентестер.

Через год-два edge-устройства станут сложнее: больше API-интеграций с облаком, больше OAuth-потоков, больше attack surface. Кто до сих пор проверяет периметр только автоматическим сканером - уже сейчас пропускает значительную часть реальных векторов. Management plane файрвола требует того же подхода, что и тестирование сложного веб-приложения. Попробуйте прогнать свой периметр через Shodan-запросы из раздела про разведку - результат может удивить.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab