Внешний пентест. Как разобраться в том, что действительно находится на границе вашей ИТ-среды

У любой компании есть тот слой инфраструктуры, который смотрит наружу. Это сайты, отдельные модули приложений, интерфейсы для партнеров, каналы удаленного доступа, сервисы в облаке и другие системы, способные принимать запросы извне. Они могут быть простыми или сложными, но объединяет их одно: все они работают на открытых каналах связи, и именно через них внешний пользователь впервые соприкасается с вашей ИТ-средой.

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

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

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

Это исследование отвечает на совершенно конкретные вопросы:

1. Какие сервисы и функции отвечают извне;
2. Как они настроены и насколько адекватно реагируют на запросы;
3. Соответствуют ли конфигурации ожиданиям команды;
4. Какие элементы забыли отключить или перенести;
5. Что можно улучшить, чтобы внешний слой стал предсказуемым и управляемым.

Для технических специалистов это удобный способ сверить архитектуру с реальностью. Для руководителей — способ получить ясное представление, что фактически происходит в периметре компании.

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

Ниже основные практические поводы выполнять такую проверку.

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

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

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

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

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

Шаг 1. Согласование границ
Компания указывает, какие домены, адреса и внешние ресурсы включаются в проверку. Определяются часы, ограничения по нагрузке и особенности сервисов, к которым нужно относиться аккуратно. Цель — чтобы работа проходила предсказуемо и без риска для функционирования сервисов.

Шаг 2. Анализ открытых сведений
Инженер изучает то, что можно увидеть без обращения во внутреннюю сеть:

— поддомены, появившиеся автоматически;
— старые записи, оставшиеся после миграции;
— служебные интерфейсы, которые никто не закрыл;
— публичные объекты в облачных системах;
— информацию, которая раскрывается косвенно.

Этот шаг показывает, насколько фактический внешний слой совпадает с тем, который описан в документации.

Шаг 3. Обход доступных сервисов
После определения перечня сервисов начинается их практическое исследование. Проверяется:

— как сервисы отвечают;
— какие версии программного обеспечения используются;
— какие маршруты доступны;
— что приложение возвращает при корректных и некорректных запросах;
— какие параметры влияют на поведение.

Эта часть дает понимание, как сервис выглядит вживую, а не на схеме.

Шаг 4. Поиск ошибок в поведении и конфигурации
Оценивается логика работы сервисов:

— правильно ли обрабатываются запросы;
— работают ли ограничения доступа;
— есть ли маршруты, не предназначенные для публичного доступа;
— возвращают ли сервисы лишнюю техническую информацию;
— совпадает ли фактическая структура с ожидаемой.

Нередко на этом этапе обнаруживаются элементы, которые существовали долго, но никто уже не считал их частью периметра.

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

Шаг 6. Проверка наблюдаемости
Если в компании есть журналирование и мониторинг, важно понять:

— какие события фиксируются;
— отображаются ли обращения;
— корректно ли работают уведомления;
— хватает ли данных для анализа.

Иногда выясняется, что внешние обращения не попадают в журналы — это отдельная зона доработки.

Шаг 7. Итоговый отчет
В отчет попадает только полезная информация:

— найденные сервисы и их состояние;
— выявленные проблемы;
— подтверждение особенностей поведения;
— рекомендации по исправлению;
— приоритеты;
— обобщенное описание состояния периметра.

Документ можно использовать как рабочее руководство для технических команд.

Пентест не моделирует полномасштабную атаку, но помогает понять общую логику того, как исследуют внешний слой. Чаще всего все начинается с малого:

Поиск точки, которая отвечает
Любой активный сервис привлекает внимание. Неважно, это веб-интерфейс, API или вспомогательная служба.

Изучение его реакций
Достаточно отправить несколько вариантов запросов, чтобы понять, как сервис обрабатывает данные. Не всегда речь идет о чем-то сложном — часто важны мелкие детали.

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

Комбинация особенностей
Когда несколько мелких несовпадений складываются вместе, могут появляться новые варианты действий.

Оценка итогового воздействия
Пентест показывает, какой набор данных или функций доступен извне и каким образом к нему можно прийти.

Внешняя проверка обычно охватывает:

– сайты и публичные модули;
– интерфейсы для партнеров;
– точки удаленного доступа;
– облачные элементы;
– служебные участки, которые оказались открыты;
– параметры защищенного соединения;
– поведение приложений при нестандартных запросах.

Каждая из этих зон может давать свои особенности.

Перечень ниже формируется годами наблюдений и встречается во всех масштабах компаний.

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

Тестовые функции
Создаются во время разработки и остаются доступными.

Нестрогие настройки доступа
Некоторые запросы проходят без правильной проверки прав.

Устаревшие версии ПО
Часть инфраструктуры обновляется, часть остается позади.

Публичные объекты в облаке
Некоторые файлы или каталоги доступны всем.

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

Со временем на границе среды появляются особенности, которые сложно заметить без стороннего взгляда.

Накопление забытых элементов
Периметр обрастает сервисами, о которых давно не вспоминали.

Неполная картина поведения приложений
Без проверки трудно понять, как именно сервис реагирует на редкие типы запросов.

Сложности при релизах
Новые приложения могут неожиданно пересекаться с оставшимися старыми конфигурациями.

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

Пониженная наблюдаемость
События на границе могут не фиксироваться корректно.

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

Приведение конфигураций к архитектурной модели
Маршруты, доступы и параметры приводятся к согласованному виду.

Обновление устаревших компонентов
Сервисы получают актуальные версии.

Удаление лишних систем
Очищается внешний слой от элементов, которые больше не нужны.

Улучшение авторизации
Доступы настраиваются строгим и единообразным образом.

Настройка журналирования
События фиксируются более полно и понятно.

Руководству
Даёт ясную, не техническую, но точную картину того, что происходит наружу.

CISO
Позволяет сопоставить внутренние представления о рисках с реальным состоянием внешнего слоя.

Командам DevOps
Помогает увидеть, где фактическое окружение отличается от инфраструктурного кода.

Разработчикам
Показывает особенности работы приложений при обращении извне.

Сетевым инженерам
Даёт материалы для корректировки маршрутизации и правил доступа.

Группам мониторинга
Показывает, какие события фиксируются, а какие проходят мимо.

Автоматические средства показывают только точки, в которых найден известный дефект.

Они не анализируют:
— логику работы приложений;
— взаимосвязи сервисов;
— особенности, появившиеся после интеграций;
— ошибки настройки, которые нельзя определить без практических запросов;
— поведение системы в неожиданных ситуациях;
— качество журналирования.

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

Проводить такую проверку собственными силами сложно. Внутренние специалисты по привычке смотрят на систему изнутри. Многие элементы кажутся очевидными, и поэтому они легко ускользают от внимания.

Внешние инженеры исследуют периметр иначе. Они не знают внутренней структуры, не связаны ожиданиями, не опираются на прошлый опыт эксплуатации. Это дает возможность увидеть то, что внутри давно воспринимается как обычное состояние вещей.

АБП2Б проводит внешние пентесты в аккуратном и безопасном режиме. Мы объясняем результаты без лишней терминологии, формируем отчет, пригодный для использования в работе, и помогаем компаниям привести внешний слой инфраструктуры к управляемому виду.