5 типовых ошибок пентестера: две из них мы совершили сами
Пентест часто оценивают по числу обнаруженных уязвимостей. Однако настоящий результат проверки измеряется иначе: что останется после завершения работ. Продолжит ли функционировать инфраструктура, не окажутся ли данные за пределами согласованного контура, не пострадают ли системы и компании, которые вообще не участвовали в проекте?
Ниже - пять распространённых ошибок специалистов по тестированию на проникновение. Некоторые из них я наблюдал со стороны, о других слышал от коллег. Две ошибки принадлежат нашей команде: одна привела к остановке сервера, вторая - к регистрации домена, который регистрировать не следовало.
1. Выход за пределы согласованного скоупа
Скоуп - это перечень систем, доменов, IP-адресов и приложений, которые заказчик разрешил проверять. Всё, что не входит в этот список, считается запрещённым для тестирования, даже если объект находится рядом, связан с целью или выглядит как очевидная часть инфраструктуры.
На практике границы часто размываются:
- во время разведки обнаруживается поддомен, отсутствующий в договоре;
- целевой домен размещён на shared-хостинге вместе с чужими сайтами;
- приложение работает в облаке, принадлежащем провайдеру;
- часть периметра обслуживает подрядчик заказчика;
- за время проекта меняются IP-адреса или архитектура сети.
Проблема в том, что за пределами утверждённого периметра специалист перестаёт действовать в рамках разрешения. Формально его действия могут выглядеть как обычное несанкционированное вмешательство. В российской практике подобные ситуации могут рассматриваться в контексте статей 272 и 274.1 УК РФ, особенно если затронута критическая информационная инфраструктура.
Отдельного универсального правового режима, который автоматически защищал бы пентестеров от компьютерных статей, по-прежнему нет. Поэтому главным инструментом защиты остаётся корректно оформленное разрешение.
Скоуп необходимо фиксировать письменно, с датой, списком адресов и описанием допустимых действий. Любое расширение оформляется так же. Сообщения вроде "давайте заодно проверим ещё этот сервер" недостаточно, если они не подтверждены уполномоченным представителем заказчика и не внесены в рабочую документацию.
Перед началом работ полезно проверить владельцев адресов, автономные системы, наличие shared-хостинга и принадлежность оборудования. В инструментах следует использовать allow-list, а не полагаться на память оператора. Ошибка, когда вместо одного адреса сканеру передают целую подсеть, остаётся одной из самых распространённых.
Особенно опасен азарт: найденная уязвимость вызывает желание "проверить ещё немного". Именно так специалисты незаметно переходят границу проекта. Профессионализм проявляется не только в способности обнаружить дыру, но и в умении вовремя остановиться.
2. Непреднамеренно вывести сервер из строя
Однажды мы получили bind-shell на сервере заказчика и установили Meterpreter, чтобы упростить дальнейшую работу. До определённого момента всё проходило штатно. Проблемы начались при попытке поднять SOCKS-прокси: сетевые интерфейсы на машине перешли в нерабочее состояние, и сервер перестал отвечать.
Мы сразу сообщили об инциденте заказчику, не стали пытаться скрыть последствия или ждать, пока отказ обнаружат самостоятельно. Примерно через десять минут сервис восстановился, и в этот раз всё ограничилось предупреждением. Но последствия вполне могли оказаться серьёзнее.
Пентестер не всегда знает, какую роль играет исследуемый сервер. Это может быть забытый легаси-компонент, самописное приложение без резервной копии или устройство, которое не перезагружали несколько лет. Внешне незначительная машина способна обслуживать критически важный бизнес-процесс.
Здесь проблема не в конкретном инструменте. Ошибка заключается в том, что цена эксперимента не была оценена заранее. Перед выполнением команды нужно понимать, обратимо ли действие, может ли оно изменить сетевую конфигурацию, повлиять на производительность или потребовать перезапуска.
В договоре стоит заранее перечислить запрещённые воздействия: отказ в обслуживании, агрессивный брутфорс, способный заблокировать учётные записи, массовое изменение данных, тестирование в рабочее время и другие потенциально разрушительные действия. У команды должны быть контакты ответственных лиц, включая канал экстренной связи вне рабочего времени.
Все действия следует журналировать с точными временными метками. Это нужно не только для отчёта, но и для расследования спорных ситуаций. Если инцидент произошёл, заказчика необходимо уведомить сразу: скрытая авария быстро превращается из технической проблемы в кризис доверия.
3. Унести больше данных, чем необходимо
Дамп базы данных, скачанный "для подтверждения" уязвимости, перестаёт быть безопасным доказательством сразу после выгрузки. С этого момента у команды появляются реальные персональные, коммерческие или технические данные, хранение которых требует отдельного контроля.
К чувствительной информации относятся не только пароли и логины. Опасность могут представлять сведения о клиентах, платежах, сотрудниках, внутренних адресах, конфигурации систем, непропатченных уязвимостях и структуре сети.
Правильный подход - собирать минимально достаточное количество данных. Для подтверждения доступа обычно достаточно нескольких обезличенных записей, хеша, фрагмента таблицы или скриншота без лишних полей. Полные базы следует выгружать только при прямом письменном разрешении и наличии понятного плана хранения, передачи и уничтожения.
Рабочие материалы нужно шифровать, ограничивать к ним доступ и удалять после завершения обязательного периода хранения. Нельзя переносить результаты проверки на личные ноутбуки, незащищённые облачные диски или внешние накопители без контроля.
4. Причинить ущерб третьей стороне
Инфраструктура заказчика нередко пересекается с системами других организаций. Это характерно для облаков, дата-центров, CDN, shared-хостинга, сервисов мониторинга и подрядных платформ.
Даже если специалист начал с разрешённого домена, автоматическое сканирование может затронуть соседние виртуальные хосты или общие сетевые компоненты. Ошибка в такой ситуации может привести к блокировке чужого сервиса, утечке данных или претензиям от компании, которая не заключала договор на тестирование.
До начала активных работ важно выяснить:
- кому принадлежат IP-адреса и оборудование;
- используется ли общий хостинг;
- есть ли промежуточные сервисы и прокси;
- какие системы обслуживаются подрядчиками;
- может ли запрос уйти в инфраструктуру провайдера.
При сомнениях проверку следует остановить и запросить уточнение. Лучше потерять несколько часов на согласование, чем получить инцидент у сторонней организации.
Если случайное воздействие произошло, необходимо сохранить логи, зафиксировать время и немедленно уведомить заказчика. Самостоятельные попытки "замести следы" или исправить чужую систему обычно только ухудшают ситуацию.
5. Превратить тестирование сотрудников в наказание
Социальная инженерия требует особенно аккуратного подхода. Проверка устойчивости персонала не должна превращаться в унижение, психологическое давление или поиск виноватых.
До начала кампании нужно определить, кого разрешено включать в тест, какие сценарии допустимы и где проходит граница. Не стоит имитировать тяжёлые чрезвычайные ситуации, угрожать увольнением, использовать реальные персональные обстоятельства или добиваться передачи настоящих секретов.
Безопаснее применять контролируемые сценарии: учебные страницы без сбора реальных паролей, тестовые маркеры, ограниченные рассылки и заранее согласованный механизм остановки. Руководители должны понимать цели проверки, но это не означает, что сотрудников следует публично раскрывать или выставлять некомпетентными.
Итогом должна быть не таблица с "процентом доверчивых работников", а план улучшений: обучение, настройка MFA, почтовые фильтры, процедуры сообщения о подозрительных письмах и повторная проверка через некоторое время.
Чек-лист перед стартом
Перед началом пентеста полезно проверить несколько базовых пунктов:
1. Утверждён ли скоуп и есть ли дата документа?
2. Перечислены ли исключения и запрещённые методы?
3. Понятно ли, кто владеет каждым адресом и сервисом?
4. Есть ли аварийный контакт заказчика?
5. Согласованы ли часы активных работ?
6. Определён ли порядок уведомления об инциденте?
7. Настроено ли журналирование действий?
8. Понятно ли, какие данные можно сохранять?
9. Есть ли процедура безопасного удаления материалов?
10. Назначен ли ответственный за финальное согласование отчёта?
Хороший пентест - это не соревнование по количеству найденных дыр. Его ценность определяется тем, насколько полезными окажутся результаты и насколько безопасно команда проведёт работу. Сильный специалист умеет не только получить доступ, но и остановиться перед опасным действием, сохранить контроль над периметром, минимизировать объём данных и честно сообщить о проблеме.
В конечном счёте заказчику нужна не эффектная демонстрация взлома, а более защищённая инфраструктура, понятный план исправлений и уверенность в том, что после завершения проверки не появятся новые инциденты.