На последнем 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/tcp | CVE в PAN-OS (path traversal, command injection) | Nuclei + кастомный шаблон | Внешний пентест, непатченные версии |
| Ivanti Connect Secure на 443/tcp | Pre-auth RCE цепочка (auth bypass + injection) | curl + Burp Suite Pro | Внешний пентест, legacy и непатченные |
| cPanel на 2083/2087 | Auth bypass, CSRF, brute force WHM | Nuclei + Burp Suite | Внешний пентест, shared hosting |
| Management UI на нестандартном порту | Default credentials, config dump | nmap NSE + hydra | Внешний пентест, legacy-конфигурация |
| Неизвестный сервис | Fingerprinting, CVE lookup | nmap + searchsploit | Black 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.x | Kali на выделенном VPS |
| RAM | 4 ГБ | 8 ГБ |
| CPU | 2 ядра | 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 Pro | Manual 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 работает по сигнатурам. Если вендор изменил формат ответа в новой версии - шаблон не сработает. Кастомные шаблоны под конкретный 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:
- Fingerprint версии PAN-OS через SSL-сертификат и HTTP-заголовки
- Проверка наличия CVE через Nuclei или ручной запрос к специфичному endpoint
- Верификация эксплуатабельности - отправка безопасного payload (DNS-callback через
curlили Burp Collaborator) для подтверждения RCE без деструктивных действий - Документирование PoC с timestamps для отчёта
Ограничения и реальность
Встретить непропатченный 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 при эксплуатации:
- Определение версии через HTTP-заголовки или URL-паттерны -
/dana-na/auth/url_default/welcome.cgiвозвращает подсказки о версии в HTML - CVE-matching через Nuclei с шаблонами по Ivanti
- Ручная верификация через Burp Suite: crafted запрос к уязвимому endpoint
- Подтверждение 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 daemoncpsrvd обрабатывает запросы ко всем портам. Основные векторы при внешнем пентесте: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
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) - анализ масштаба компрометации учётных данных
Что 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 узнаёт об этом через неделю из отчёта пентестера. Неловко получается.
Чеклист: проверка файрвола на уязвимости по шагам
Итоговый чеклист для внешнего пентеста периметровых устройств - формат для включения в отчёт:- OSINT-разведка - Shodan/Censys по IP-диапазону заказчика. Зафиксировать management-интерфейсы, версии, сертификаты
- Активное сканирование - nmap с
-sV -sCпо расширенному списку портов (443, 4443, 8443, 10443, 2083, 2087, 22). Результаты в-oAформате - Fingerprinting - определить вендор и версию по HTTP-заголовкам, SSL-сертификатам, HTML login-страниц
- CVE matching - Nuclei с шаблонами
critical,high. Параллельно ручной поиск в NVD и Exploit-DB по версиям - Проверка аутентификации - тест на default credentials по вендору, оценка устойчивости к brute force (lockout, rate limiting, captcha)
- Эксплуатация CVE - только после согласования scope. Верификация через OOB-callback, не через деструктивные payload'ы
- Configuration audit - соответствие DISA STIG (Palo Alto NDM), доступность management plane из untrusted зон, TLS-конфигурация
- Lateral movement assessment - при доступе к устройству: оценка возможности проникновения через routing/VPN/NAT конфигурации
- Документирование - timestamps, скриншоты, полные команды. PoC без деструктива. Рекомендации по NIST SP 800-53 (AC-1, IA-1, CM-1)
- Ретест - через 30-60 дней после передачи отчёта: верификация устранённых уязвимостей
Главная проблема - не отсутствие патчей. Патчи ставят. Проблема в том, что management-интерфейсы оказываются доступны из интернета «временно» и остаются там навсегда. На каждом втором engagement нахожу web UI файрвола, который «открыли для удалённой настройки подрядчиком» и забыли закрыть. DISA STIG, best practices Palo Alto, рекомендации Ivanti - все говорят одно: management plane не должен быть доступен из untrusted зон. Но между документом и реальной конфигурацией - пропасть, и именно в этой пропасти работает пентестер.
Через год-два edge-устройства станут сложнее: больше API-интеграций с облаком, больше OAuth-потоков, больше attack surface. Кто до сих пор проверяет периметр только автоматическим сканером - уже сейчас пропускает значительную часть реальных векторов. Management plane файрвола требует того же подхода, что и тестирование сложного веб-приложения. Попробуйте прогнать свой периметр через Shodan-запросы из раздела про разведку - результат может удивить.