Профессия: белый хакер (Ethical Hacker)

1. Роль белого хакера: задачи, этика и ответственность

Роль белого хакера: задачи, этика и ответственность

Белый хакер (ethical hacker) — это специалист по кибербезопасности, который легально и по согласованию ищет уязвимости в системах, чтобы помочь организации защититься до того, как этим воспользуются злоумышленники.

В этой статье вы разберёте:

чем белый хакер отличается от нарушителя

какие задачи он решает в компаниях

почему этика и юридические рамки — часть профессии

как выглядит ответственность за данные, инфраструктуру и результаты работы

Кто такой белый хакер и чем он отличается от других

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

В практике безопасности обычно выделяют:

White hat — действует с разрешения владельца системы и в оговорённых границах.

Black hat — действует без разрешения, преследуя вред или выгоду.

Gray hat — может находить проблемы без разрешения, но не обязательно с намерением причинить ущерб; такой подход всё равно может нарушать закон и этику.

Ключевая граница профессии белого хакера: явное разрешение и работа в рамках согласованного объёма.

Зачем бизнесу белые хакеры

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

Типичные цели:

снизить вероятность взлома и простоя

защитить данные клиентов и коммерческие секреты

выполнить требования регуляторов и договоров

повысить зрелость процессов разработки и эксплуатации

Основные задачи белого хакера

Ниже — основные направления работы. Термины даны сразу с простыми пояснениями.

Тестирование на проникновение (penetration testing, pentest) — проверка, можно ли реально взломать систему в рамках согласованного сценария и объёма.

Оценка уязвимостей (vulnerability assessment) — поиск и классификация слабых мест (обычно шире по охвату, но не всегда с глубоким подтверждением эксплуатацией).

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

Аудит веб-приложений и API — проверка логики, авторизации, обработки данных и типовых классов уязвимостей.

Аудит конфигураций — поиск опасных настроек в ОС, облаке, сетевом оборудовании, контейнерах.

Проверка безопасности кода (code review) — анализ исходников на ошибки безопасности и опасные шаблоны.

Сопровождение исправлений — помощь командам в понимании причины уязвимости и проверка, что исправление действительно закрывает проблему.

Полезные общедоступные ориентиры по методикам:

OWASP Web Security Testing Guide — практическое руководство по тестированию веб-безопасности.

NIST SP 800-115 Technical Guide to Information Security Testing and Assessment — базовое руководство по тестам и оценкам безопасности.

Как выглядит работа: жизненный цикл теста

Результат белого хакера — не «взлом ради взлома», а управляемая проверка с документированными выводами.

!Схема показывает этапы работ белого хакера от согласования до повторной проверки.

Ключевые этапы:

Согласование цели и объёма (scope)

Получение разрешения и правил работ

Проведение проверок в разрешённых границах

Отчёт с доказательствами и рекомендациями

Повторная проверка после исправлений (retest)

Важный документ на практике — ROE (Rules of Engagement), то есть правила проведения работ. Обычно в них фиксируют:

что именно можно тестировать (системы, домены, приложения)

что запрещено (например, атаки, вызывающие простой)

временные окна и контакт ответственных

как обращаться с данными и логами

как подтверждать уязвимости безопасно

Этика: принципы, без которых профессия невозможна

Этика белого хакера — это набор практических ограничений, которые защищают клиента, пользователей и самого специалиста.

Базовые принципы:

Согласие и прозрачность — работать только при явном разрешении и по правилам.

Минимизация вреда — выбирать методы, которые дают доказательства, но не ломают систему и не портят данные.

Конфиденциальность — не разглашать найденные уязвимости и не выносить данные за пределы согласованных условий.

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

Профессиональная осторожность — не использовать инструменты и техники, последствия которых вы не понимаете.

Этический стандарт в профессиональном сообществе часто формулируют так: делать систему безопаснее, а не демонстрировать власть над ней.

Юридическая ответственность: «разрешение» важнее техники

Одинаковые действия (например, сканирование портов или попытка подбора пароля) могут быть:

легальной проверкой — если есть письменное разрешение владельца и соблюдены границы

правонарушением — если разрешения нет или вы вышли за рамки объёма

Что важно помнить:

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

Выход за рамки scope — типичная причина юридических проблем даже при «белых» намерениях.

Работа с персональными данными требует повышенной осторожности: доступ, хранение, передача и удаление должны быть оговорены.

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

CERT/CC Vulnerability Disclosure — подходы к координированному раскрытию.

Ответственность за данные и инфраструктуру

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

Что обычно считается обязательным минимумом:

Безопасное обращение с артефактами: отчёты, дампы, скриншоты, токены доступа.

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

Контроль влияния на доступность: избегать действий, которые могут вызвать простой (например, агрессивные проверки без согласования).

Чёткая фиксация действий: чтобы можно было объяснить, что именно делалось и почему.

Что должно быть в хорошем отчёте белого хакера

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

Типичная структура:

Резюме для руководства: общая картина рисков простыми словами.

Методика и ограничения: что тестировали и что не тестировали.

Находки: описание уязвимости, затронутые компоненты, условия воспроизведения.

Доказательства: логи, скриншоты, безопасные примеры запросов.

Риск и приоритет исправления: почему это важно и что может случиться.

Рекомендации: конкретные шаги исправления и предотвращения повторения.

Приложения: детали окружения, версии, перечень проверок.

Важно: отчёт не должен превращаться в «список страшных слов». Его цель — помочь исправить проблему и снизить риск.

Границы допустимого: быстрый ориентир

| Ситуация | Допустимо для белого хакера | Недопустимо | |---|---|---| | Нет письменного разрешения | Ничего, кроме публично разрешённых программ (например, bug bounty) | Любые активные проверки чужой системы | | Есть разрешение, но ограниченный scope | Тестировать только перечисленные цели | Проверять соседние подсети, аккаунты, сервисы «заодно» | | Нашли доступ к чувствительным данным | Зафиксировать минимально необходимое доказательство и остановиться | Копировать базы «на всякий случай» | | Нужно доказать возможность атаки | Использовать безопасное подтверждение в рамках ROE | Выводить систему из строя без отдельного согласования |

Итог

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

В следующих материалах курса мы перейдём от роли и принципов к базовым техническим фундаментам: как устроены сети, веб-приложения и типовые механизмы защиты, которые вам предстоит проверять.

2. База: сети, TCP/IP, веб и основы криптографии

База: сети, TCP/IP, веб и основы криптографии

Белый хакер работает не с «магией взлома», а с предсказуемыми слоями технологий: сетью, протоколами, вебом и криптографией. Если в предыдущей статье мы закрепили этику, разрешение и границы (scope), то здесь вы получите технический фундамент, без которого невозможно ни корректно тестировать, ни грамотно описывать находки в отчёте.

Цель статьи — дать вам общий словарь и модель мышления: что где находится, как течёт трафик, где чаще всего возникают риски и какие «строительные блоки» безопасности используются в реальных системах.

Как мыслить слоями: от кабеля до приложения

Практически любую проверку удобнее раскладывать по уровням:

Канал и сеть: как пакеты вообще добираются до цели (IP, маршрутизация).

Транспорт: как приложения доставляют данные (TCP/UDP, порты).

Прикладной протокол: что именно передаётся (HTTP, DNS, SMTP и другие).

Безопасность поверх: шифрование и доверие (TLS, сертификаты, подписи).

Логика приложения: авторизация, права, бизнес-правила.

!Стек TCP/IP и примеры протоколов по уровням

Эта модель помогает не только учиться, но и соблюдать правила ROE: вы понимаете, на каком уровне вы действуете (например, «мы тестируем только веб-уровень и не трогаем сетевую инфраструктуру»).

Сети и IP: адреса, маршрутизация, NAT

IP-адрес и подсеть

IP-адрес — это адрес устройства в сети. В повседневной практике вы чаще увидите IPv4 (например, 203.0.113.10), но IPv6 тоже широко используется.

Чтобы понимать «где находится» узел, важны два понятия:

Подсеть — группа адресов, которые обычно доступны друг другу напрямую.

Маска/префикс — сколько бит адреса относятся к сети (например, /24).

Практический смысл для белого хакера:

один и тот же сервис может быть доступен снаружи по одному адресу, а внутри — по другому

в отчёте важно фиксировать, какой именно адрес/хост вы тестировали и откуда (внутренняя сеть, VPN, интернет)

Маршрутизация

Маршрутизаторы выбирают путь, по которому пакеты идут к цели. Ошибки в маршрутизации и фильтрации (например, слишком широкие сетевые доступы между сегментами) часто приводят к тому, что компрометация одного узла «расползается» дальше.

NAT и «внешний» адрес

NAT (Network Address Translation) — механизм, когда множество внутренних адресов «прячутся» за одним внешним. Это типично для офисов и облачных сетей.

Важный вывод:

видимый в логах IP пользователя и реальная внутренняя машина могут быть разными

иногда тест «снаружи» и тест «изнутри» показывают разные поверхности атаки

Транспорт: TCP, UDP и порты

Порты и сокеты

Порт — это числовой идентификатор сервиса на хосте. Связка IP:порт часто называют конечной точкой.

Примеры распространённых портов:

| Протокол/сервис | Типичный порт | Зачем важно белому хакеру | |---|---:|---| | HTTP | 80 | часто есть редирект на HTTPS, иногда остаются забытые панели | | HTTPS (HTTP поверх TLS) | 443 | основная поверхность веб-тестов | | SSH | 22 | удалённое администрирование, риски ключей/доступов | | DNS | 53 | влияет на резолвинг, может участвовать в атаках на инфраструктуру |

TCP

TCP — транспортный протокол с установлением соединения и гарантией доставки (в нормальных условиях). Он подходит для веба, почты, SSH.

Ключевые свойства TCP, которые полезно понимать:

соединение (есть состояние, стороны «договариваются»)

надёжность (потерянные данные переотправляются)

упорядочивание (данные приходят в правильной последовательности)

UDP

UDP — «безсоединительный» протокол: легче и быстрее, но без встроенной гарантии доставки. Используется там, где важна скорость или поверх него построена своя логика (например, DNS, VoIP, некоторые VPN).

Практический смысл:

проблемы с UDP часто выглядят как «иногда работает, иногда нет»

не все сетевые средства мониторинга одинаково хорошо интерпретируют UDP, это влияет на расследования инцидентов

DNS: как имя превращается в IP

DNS (Domain Name System) отвечает на вопрос: какому IP соответствует доменное имя.

Почему DNS важен в безопасности:

через DNS пользователи и сервисы находят инфраструктуру

ошибки в DNS могут уводить трафик «не туда»

многие проверки начинаются с понимания, какие поддомены существуют и куда они указывают

Базовые элементы DNS, которые стоит знать:

A/AAAA — запись на IPv4/IPv6

CNAME — алиас на другое имя

MX — куда доставлять почту домена

TXT — текстовые записи (часто используются для проверок владения доменом и почтовых политик)

Полезная справка:

Документация MDN по DNS

Веб: HTTP как протокол и веб-приложение как система

HTTP-запрос и ответ

HTTP — прикладной протокол «запрос → ответ».

Что есть в запросе:

метод (например, GET, POST)

путь (например, /api/users)

заголовки (например, Host, Cookie, Authorization)

тело (например, JSON в POST)

Что есть в ответе:

код статуса (например, 200, 401, 403, 500)

заголовки (например, Set-Cookie, Content-Type)

тело ответа (HTML/JSON/файл)

!Как устроен обмен HTTP-запросом и ответом

Справка по HTTP:

MDN: Обзор HTTP

Методы и типичные коды статуса

Самый частый минимум для веб-проверок:

| Категория | Примеры | Смысл | |---|---|---| | Методы | GET, POST, PUT, DELETE | чтение, создание, обновление, удаление данных | | Коды успеха | 200, 201, 204 | запрос обработан | | Переадресация | 301, 302 | перевод на другой URL | | Ошибки доступа | 401, 403 | не аутентифицирован / доступ запрещён | | Ошибки сервера | 500, 502, 503 | проблема на стороне сервиса/инфраструктуры |

Cookie, сессии и токены

Веб по своей природе статeless: каждый запрос сам по себе. Чтобы «помнить пользователя», применяют механизмы состояния.

Основные варианты:

Сессия на сервере + cookie с идентификатором сессии

Токены (например, токен в заголовке Authorization)

Важные свойства cookie, которые часто имеют отношение к безопасности:

HttpOnly — защищает от чтения cookie через JavaScript

Secure — отправка cookie только по HTTPS

SameSite — снижает риск некоторых межсайтовых атак

Справка:

MDN: Set-Cookie

Аутентификация и авторизация

Эти понятия часто путают, но в отчётах их нужно разделять.

Аутентификация — кто ты? (проверка личности: пароль, 2FA, сертификат, SSO)

Авторизация — что тебе можно? (проверка прав на действие/ресурс)

Типовая находка в веб-проверках — проблемы именно авторизации: пользователь вошёл, но может делать то, что не должен (например, доступ к чужим данным через API).

API и форматы данных

Современные системы часто состоят из фронтенда и API. Самый распространённый формат — JSON.

Практический смысл для тестирования:

часто уязвимость находится не в «красивой» веб-странице, а в API-методе

важно видеть, какие поля реально принимает сервер и как он проверяет права

Хорошая база по типовым классам веб-рисков:

OWASP Top 10

HTTPS и TLS: шифрование канала и доверие

Что такое TLS

TLS (Transport Layer Security) — протокол, который обеспечивает:

шифрование трафика (конфиденциальность)

контроль целостности (защита от незаметной подмены)

аутентификацию сервера через сертификат (обычно)

В вебе вы видите это как HTTPS: по сути, HTTP «внутри» TLS.

Сертификаты и цепочки доверия

Сертификат связывает доменное имя (например, example.com) с публичным ключом и подтверждается центром сертификации.

Что важно белому хакеру на практике:

сертификат должен соответствовать домену

сертификат должен быть действительным по срокам и цепочке доверия

неверные настройки TLS могут приводить к рискам даже при наличии HTTPS

!Цепочка доверия сертификатов в TLS

Справка:

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3

Основы криптографии: что защищает данные и почему это работает

Криптография в прикладной безопасности — это не «сложная математика ради математики», а набор инструментов для четырёх задач:

конфиденциальность (чтобы не прочитали)

целостность (чтобы незаметно не изменили)

аутентичность (чтобы знать источник)

неотказуемость (чтобы сложнее было отрицать авторство)

Симметричное шифрование

Симметричное шифрование использует один общий секретный ключ для шифрования и расшифрования.

плюс: быстро

минус: нужно безопасно передать/хранить общий ключ

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

Асимметричная криптография

Асимметричная криптография использует пару ключей:

публичный ключ — можно распространять

приватный ключ — должен оставаться в секрете

Применения:

обмен ключами (чтобы договориться о секрете)

цифровые подписи

Хэш-функции

Хэш-функция преобразует данные произвольной длины в строку фиксированной длины (хэш). Важно, что:

небольшое изменение входа сильно меняет хэш

трудно подобрать другой вход с тем же хэшем (устойчивость к коллизиям и подмене)

Хэши применяют для:

контроля целостности

хранения паролей в виде хэшей (но правильно — с солью и медленными алгоритмами)

Справка по рекомендациям хранения паролей (как ориентир для понимания «как должно быть»):

NIST SP 800-63B: Digital Identity Guidelines

Цифровые подписи

Цифровая подпись позволяет доказать, что:

сообщение подписал владелец приватного ключа

сообщение не менялось после подписания

Это основа доверия в сертификатах TLS и многих механизмах обновлений ПО.

Почему длина ключа важна

Очень упрощённо, если ключ имеет бит, то число возможных ключей равно .

— количество бит в ключе

— сколько разных значений может принимать ключ

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

Типичные ошибки, которые встречаются на практике

Эти примеры важны не как «инструкции атаки», а как карта того, что стоит уметь распознавать и объяснять.

Сеть и доступы

Веб-логика

Крипто-настройки

Ниже — частые причины инцидентов на каждом уровне:

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

Слабая авторизация: пользователь может запрашивать данные, которые ему не принадлежат.

Неправильная работа с сессиями: сессия не инвалидируется при выходе, cookie без Secure.

Небезопасное хранение секретов: ключи и токены в репозитории или логах.

Устаревшие TLS-настройки: слабые протоколы/шифры, неверная конфигурация.

Неверное хранение паролей: быстрые хэши без соли или, хуже, хранение в открытом виде.

Как это связывается с работой белого хакера

Техническая база нужна, чтобы соблюдать три профессиональных требования из первой статьи:

Работа в scope: вы понимаете, какие уровни и компоненты реально затрагиваете.

Минимизация вреда: вы выбираете безопасные способы подтверждения (например, доказать доступ без копирования лишних данных).

Качественный отчёт: вы можете точно описать уязвимость языком протоколов и механизмов (HTTP-заголовки, коды статуса, свойства cookie, модель доверия TLS).

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

3. Операционные системы и администрирование для пентеста

Операционные системы и администрирование для пентеста

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

Эта статья продолжает две предыдущие темы курса:

из статьи про роль белого хакера вы берёте границы (scope), ROE, минимизацию вреда и ответственность за данные

из статьи про сети и веб — понимание, как трафик и протоколы доходят до ОС и приложений

Здесь вы построите базу по Linux и Windows именно с точки зрения пентеста: что проверять, как корректно собирать факты и как формулировать находки в отчёте.

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

Администрирование для пентеста — это не «умение настроить сервер ради настройки», а способность:

быстро ориентироваться в незнакомой системе

собирать доказательства так, чтобы не ломать среду

понимать, какие настройки являются риском и почему

говорить с администраторами и разработчиками на одном языке

Типовые ситуации, где админские знания критичны:

уточнить что реально доступно по сети на уровне хоста (слушающие порты, firewall)

подтвердить проблему минимально достаточным способом (например, показать доступ к конфигурации, не копируя лишние данные)

объяснить риск через модель прав (пользователь, группа, ACL, привилегии)

найти первопричину уязвимости в сервисе (служба, конфиг, переменные окружения, зависимости)

!Карта областей ОС, которые чаще всего проверяет пентестер

Лаборатория и рабочая дисциплина

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

Виртуализация и снимки

Практически стандарт:

виртуальная машина с Linux (например, Ubuntu)

виртуальная машина с Windows

снимки состояния (snapshots), чтобы откатываться после экспериментов

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

Справка:

Документация VirtualBox

Аккуратность при сборе артефактов

Даже в лаборатории привыкайте к правилам, которые обязательны в реальном проекте:

фиксировать дату/время и контекст (откуда вы подключены, какой хост, какая учётка)

сохранять только нужные доказательства (скриншот, небольшой фрагмент конфига, строка лога)

не хранить секреты в открытом виде (токены, приватные ключи)

Linux для пентеста: структура, права, процессы, сеть

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

Файловая система и стандартные каталоги

Linux организован как единое дерево каталогов. Несколько директорий встречаются постоянно:

/etc — конфигурация системы и сервисов

/var/log — журналы (логи)

/home — домашние каталоги пользователей

/tmp — временные файлы (часто источник рисков из-за неверных прав)

/usr/bin и /bin — исполняемые файлы (утилиты)

Что это даёт в пентесте:

вы быстрее находите конфиги сервисов и места, где могут утекать секреты

вы понимаете, где искать следы событий (а значит, можете аккуратно подтвердить факт проблемы)

Справка:

Filesystem Hierarchy Standard

Пользователи, группы и права доступа

В Linux доступ обычно определяется связкой:

владелец файла (user)

группа (group)

права r (read), w (write), x (execute)

Команды, которые используют администраторы и пентестеры для ориентирования:

id — кто вы и в каких группах

ls -l — права и владельцы файлов

getent passwd и getent group — источники пользователей и групп

Важные понятия:

root — суперпользователь (максимальные права)

sudo — механизм, который разрешает конкретным пользователям выполнять команды с повышенными правами

Почему это важно для безопасности:

избыточные права групп и широкие правила sudo превращают локальную ошибку в полную компрометацию

неверные права на конфиги могут раскрыть пароли, ключи, токены

Справка:

Страница руководства sudo

Процессы и службы

Большая часть «входных точек» — это службы (демоны), которые слушают сеть или обрабатывают данные.

Полезный минимум:

ps — список процессов

systemctl — управление службами в системах с systemd

journalctl — просмотр журналов systemd

Что смотреть в рамках пентеста:

какие службы запущены и нужны ли они

под каким пользователем работает сервис (слишком привилегированный сервис — частый риск)

где конфигурация и логи конкретной службы

Справка:

Документация systemd

Сеть на хосте: интерфейсы, порты, firewall

Из предыдущей статьи вы знаете уровни TCP/IP. Здесь — как это проявляется на конкретной машине.

Практические вопросы:

какие интерфейсы есть у хоста и какие IP на них назначены

какие порты слушаются локально

какие правила фильтрации применяются на самом хосте

Утилиты, которые часто используют:

ip addr и ip route — адреса и маршруты

ss -tulpen — слушающие TCP/UDP порты и процессы

Для фильтрации трафика в Linux часто встречаются:

nftables

iptables (встречается в старых конфигурациях)

Справка:

Документация iproute2

Документация nftables

Логи и аудит

Логи — это одновременно источник доказательств и зона ответственности: нельзя «просто так» копировать всё.

Где часто искать события:

/var/log/auth.log (в некоторых дистрибутивах) — аутентификация

/var/log/secure (в некоторых дистрибутивах) — аутентификация

journalctl — события systemd

Рекомендация по стилю работы:

фиксируйте точечные строки и временные окна

в отчёте указывайте, почему этот фрагмент важен и как он подтверждает находку

Windows для пентеста: учётные записи, службы, сеть, журналы

Windows часто встречается в корпоративной инфраструктуре: рабочие станции, серверы приложений, Active Directory-окружения. Даже если ваш scope ограничен веб-приложением, оно может работать на Windows-сервере.

Учётные записи и модель прав

Ключевые термины:

Security Identifier (SID) — уникальный идентификатор сущности безопасности

ACL (Access Control List) — список правил доступа к объекту

UAC — механизм, который снижает риск случайных действий с админ-правами

Что важно понимать:

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

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

Справка:

Microsoft Learn: Access Control Lists (ACLs)

Microsoft Learn: User Account Control

PowerShell как стандартная консоль администрирования

PowerShell — основной язык автоматизации в Windows. В пентесте он полезен не «для атак», а для корректного сбора фактов.

Что важно концептуально:

PowerShell работает с объектами, а не только со строками

многие админские действия и инвентаризация проще и точнее делаются через PowerShell

Справка:

Microsoft Learn: PowerShell documentation

Службы, автозапуск и планировщик

Типовые места, которые администраторы используют для запуска компонентов:

службы Windows

задания планировщика

автозагрузка

С точки зрения безопасности важно:

под какой учётной записью выполняется служба

где лежит исполняемый файл и кто может его изменять

какие права нужны сервису на самом деле (принцип наименьших привилегий)

Справка:

Microsoft Learn: Windows Service Applications

Сеть и firewall

На Windows-хосте часто проверяют:

какие порты слушаются

какие правила Windows Defender Firewall применяются

Справка:

Microsoft Learn: Windows Defender Firewall

Журналы событий (Event Logs)

Windows централизует много событий в журналах.

Пентестеру это помогает:

подтверждать факты входов, ошибок служб, проблем с политиками

объяснять влияние уязвимости через наблюдаемые события

Справка:

Microsoft Learn: Windows Event Log

Обновления и управление ПО как часть безопасности

Множество реальных рисков — это не «сложные 0-day», а сочетание:

устаревшего ПО

небезопасной конфигурации

отсутствия контроля изменений

На уровне ОС это проявляется так:

нет регулярных обновлений безопасности

неконтролируемо установлены пакеты и зависимости

конфиги менялись вручную без фиксации

Важно в отчётах:

разделять факт (версия/настройка) и риск (к чему это приводит)

предлагать исправления, которые реалистично внедрить (например, окно обновлений, тестовый контур, регламент)

SSH и удалённое администрирование: базовая гигиена

SSH — один из самых частых каналов администрирования Linux и сетевых устройств.

Что считается хорошей практикой:

ключи вместо паролей там, где это возможно

защита приватных ключей и корректные права на них

ограничение доступа по сети (jump host, VPN, фильтрация)

отключение небезопасных и устаревших настроек

Справка:

OpenSSH Manual Pages

Как оформлять находки по ОС: что писать в отчёте

Чтобы связать техническую часть с этикой и ответственностью из первой статьи, используйте структуру, которая минимизирует «шум» и помогает исправить проблему.

Минимальный шаблон находки (пример логики)

что обнаружено (настройка, служба, права, версия)

где обнаружено (хост, роль, компонент)

почему это риск (сценарий воздействия)

доказательство (минимально достаточное)

рекомендация (конкретная настройка или процесс)

Типовые классы проблем на уровне ОС

избыточные права (файлы/папки/службы)

секреты в конфигурациях и логах

сервисы работают с ненужными привилегиями

открытые порты и «забытые» админские интерфейсы

отсутствует аудит и централизованный сбор логов

устаревшие компоненты без регламента обновлений

Итог

ОС и администрирование — это фундамент, который связывает «как работает сеть и веб» с реальным устройством машин, где запускаются сервисы. Если вы понимаете структуру Linux и Windows, модель прав, службы, сеть на хосте и журналы, вы:

быстрее определяете поверхность атаки в рамках scope

аккуратнее подтверждаете риски без лишнего доступа к данным

пишете отчёты, которые администраторы могут внедрить в практику

В следующих темах курса этот базис станет опорой для практики: инвентаризация поверхности, тестирование веба и API, анализ конфигураций и корректное подтверждение уязвимостей.

4. Методология пентеста: разведка, сканирование, эксплуатация

Методология пентеста: разведка, сканирование, эксплуатация

Пентест — это управляемая проверка безопасности, а не набор случайных «попыток взлома». Методология нужна, чтобы:

работать в рамках разрешения и scope (из первой статьи)

понимать, что именно вы проверяете на уровне сети, веба и криптографии (из второй статьи)

собирать факты и подтверждения аккуратно, опираясь на устройство Linux и Windows (из третьей статьи)

В этой статье вы разберёте три центральных этапа практического пентеста:

разведка: что можно узнать о цели до активных действий и с минимальным воздействием

сканирование и перечисление (enumeration): какие сервисы и функции реально доступны и как они настроены

эксплуатация (exploitation): как корректно подтвердить уязвимость с минимальным риском и максимальной доказательностью

> Методология — это способ превратить проверку в воспроизводимый процесс: с понятными границами, артефактами и результатом в виде отчёта.

Где методология «встраивается» в жизненный цикл работ

В первой статье вы уже видели жизненный цикл: согласование → правила → тест → отчёт → повторная проверка. Методология пентеста — это «начинка» этапа тестирования, которая помогает отвечать на вопросы:

что мы делаем сейчас и зачем

какие данные собираем

как подтвердим риск так, чтобы не навредить

что попадёт в отчёт как доказательство

Ориентиры по общим подходам:

NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

OWASP Web Security Testing Guide (WSTG)

PTES: Penetration Testing Execution Standard

!Схема показывает, как разведка, сканирование и эксплуатация связываются с подготовкой, отчётом и повторной проверкой

Подготовка как обязательное условие разведки и сканирования

Хотя в названии статьи подготовка не указана, на практике без неё первые три этапа превращаются в риск.

Что обычно фиксируют до начала активных действий:

scope: домены, IP-диапазоны, приложения, аккаунты, среда (prod/stage)

ограничения по воздействию: запрет на DoS, ограничения на подбор паролей, «тихие часы»

контакты и эскалация: кому писать при неожиданном эффекте

обращение с данными: что можно сохранять в доказательства, как хранить, когда удалять

В терминах из первой статьи это оформляется как ROE (Rules of Engagement).

Разведка: собрать максимум фактов с минимумом воздействия

Разведка (reconnaissance) — этап, на котором вы строите карту цели: какие активы существуют, как они связаны, какие технологии используются и где могут быть точки входа.

Разведку полезно делить на два типа.

Пассивная разведка

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

Что обычно ищут:

домены и поддомены организации

публичные IP и автономные системы, связанные с инфраструктурой

технологии и внешние зависимости (например, CDN, почтовые провайдеры)

публичные утечки конфигураций и секретов (в том числе случайные)

Почему это важно:

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

снижаете риск «попасть не туда» и выйти за scope

заранее отмечаете «красные зоны» (например, критичные системы, которые нельзя трогать нагрузкой)

Активная разведка

Активная разведка — взаимодействие с целевой инфраструктурой, но ещё не «глубокое» перечисление: вы аккуратно проверяете доступность и базовые признаки.

Примеры активной разведки как категории действий:

проверка доступности хоста и базовой сетевой связности

аккуратная проверка ответа веб-сервиса (заголовки, редиректы, базовые страницы)

проверка DNS-резолвинга и соответствия доменов ожиданиям

На этом этапе особенно важно:

соблюдать лимиты ROE

фиксировать источник наблюдения (откуда вы проверяли: интернет, VPN, внутренняя сеть)

Сканирование и перечисление: превратить «адреса» в понятные сервисы

Термины, которые нужно различать:

сканирование (scanning) — выяснить, какие сетевые порты/сервисы доступны

перечисление (enumeration) — получить детали о сервисе: версия, конфигурация, эндпоинты, роли, права

Именно на перечислении чаще всего рождаются качественные находки: не просто «порт открыт», а почему это риск.

Что считать результатом сканирования

Результат сканирования — это не «лог инструмента», а структурированная картина:

хост

порт и протокол

предполагаемый сервис

подтверждение (баннер, рукопожатие протокола, наблюдаемый ответ)

комментарий о доступности (откуда виден сервис)

Это напрямую связано со второй статьёй про TCP/IP:

порт — это то, куда приходит TCP/UDP-трафик

протокол — это то, как сервис «разговаривает» (HTTP, SSH, DNS)

Перечисление веба и API

Для веба и API перечисление обычно означает:

понять структуру приложения (разделы, роли, области авторизации)

обнаружить ключевые URL и API-эндпоинты

изучить параметры, форматы данных (например, JSON), заголовки, cookie

построить модель аутентификации и авторизации (из второй статьи)

Важно: перечисление — это не «брутфорс всего подряд», а управляемое исследование поведения приложения.

Полезные ориентиры для веб-проверок:

OWASP Testing Guide: Testing for Authentication

OWASP Testing Guide: Testing for Authorization

Перечисление на уровне ОС и сервисов

Здесь включается база из статьи про администрирование:

на Linux вы часто подтверждаете факты через понимание конфигов в /etc, логов в /var/log, служб через systemctl и журналов через journalctl

на Windows важны модель прав (ACL), службы, планировщик и Event Logs

Даже если пентест «вебовый», уязвимости нередко связаны с тем, как сервис запущен и настроен.

Как не превратить сканирование в инцидент

Сканирование может создавать нагрузку и тревоги у мониторинга. Практические правила дисциплины:

подстраивать скорость и параллелизм под ROE

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

заранее согласовать «что считать допустимым шумом»

вести журнал действий: время, цель, тип активности

Анализ уязвимостей: мост между перечислением и эксплуатацией

Частая ошибка новичков: пытаться «эксплуатировать» сразу, не сформулировав гипотезу.

Анализ уязвимостей — это этап, где вы сопоставляете факты с типовыми классами проблем и решаете:

что здесь может быть уязвимостью

как её подтвердить безопасно

какие доказательства будут достаточны для отчёта

Источники для классификации и общения с командами:

OWASP Top 10

MITRE ATT&CK

Важно понимать различие:

уязвимость — техническая или логическая слабость

риск — возможный ущерб с учётом контекста (данные, доступы, сценарии)

Эксплуатация должна подтверждать риск, а не «факт, что что-то странное происходит».

Эксплуатация: подтвердить уязвимость минимально достаточным способом

Эксплуатация (exploitation) — это проверка, что уязвимость можно использовать на практике. В пентесте цель эксплуатации обычно такая:

доказать возможность воздействия

не нарушить доступность

не собрать лишние данные

оставить воспроизводимый след для отчёта

Что такое PoC и чем он отличается от «полноценной атаки»

PoC (Proof of Concept) — доказательство осуществимости. В хорошем пентесте PoC:

минимален

воспроизводим

не требует «лишних» прав

не делает необратимых изменений

Например, для проблем авторизации в API часто достаточно:

показать запрос к ресурсу, который должен быть запрещён

зафиксировать код ответа и фрагмент данных, не выгружая всё

Принцип минимального воздействия

Практическая формулировка принципа из первой статьи:

если можно доказать риск без записи на диск — не записывайте

если можно доказать доступ к данным одним примером — не скачивайте наборы

если можно подтвердить выполнение действия в тестовой сущности — не трогайте реальные объекты

В отчёте это важно отражать явно: как именно вы минимизировали вред.

Контроль изменений и следов

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

Поэтому до начала эксплуатации полезно согласовать:

можно ли создавать тестовые сущности

как выполнять очистку (cleanup)

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

Если очистка запрещена ROE, это тоже фиксируют: чтобы клиент понимал, где останутся артефакты.

Артефакты по этапам: что сохранять для отчёта

Хорошая методология заранее определяет, какие артефакты вы собираете и как они попадут в отчёт.

| Этап | Типовые артефакты | Зачем это нужно в отчёте | Риски при неаккуратности | |---|---|---|---| | Разведка | список активов, домены, зависимости | доказать полноту охвата и соответствие scope | случайно включить «чужие» активы вне scope | | Сканирование | карта портов и сервисов | показать поверхность атаки и входные точки | перегрузить сервис, зашуметь мониторинг | | Перечисление | версии, конфиги, эндпоинты, роли | связать уязвимость с конкретной точкой | собрать лишние чувствительные данные | | Эксплуатация | PoC, точечные логи/скриншоты | подтвердить реальную эксплуатацию | повредить данные, нарушить доступность |

Частые ошибки на каждом этапе и как их избегать

Разведка

путать активы компании и сторонние сервисы

собирать данные без фиксации источника и времени

начинать активные проверки до уточнения scope

Сканирование и перечисление

делать вывод «уязвимо», имея только открытый порт

не подтверждать, какой процесс/служба стоит за портом

не учитывать, что «видимость» сервиса зависит от точки доступа (интернет против внутренней сети)

Эксплуатация

«доказывать» риск разрушительным способом

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

не описывать условия воспроизведения (что делает PoC бесполезным)

Как связать методологию с качеством отчёта

Из первой статьи: отчёт — главный продукт. Методология делает отчёт сильнее, потому что:

разведка объясняет, почему вы вообще пришли к этой точке проверки

сканирование показывает, какая поверхность атаки доступна

перечисление даёт точные технические детали (HTTP, TLS, версии, права)

эксплуатация даёт доказательство риска с минимальным воздействием

Минимально полезный стиль формулировки находки:

что обнаружено

где обнаружено

как воспроизвести

почему это риск

доказательство (минимально достаточное)

рекомендация и приоритет

Итог

Методология пентеста — это дисциплина, которая связывает ваши знания о сети, вебе, криптографии и ОС в управляемый процесс.

разведка строит карту активов и снижает риск выхода за scope

сканирование и перечисление превращают «адреса» в понятные сервисы, конфигурации и функции

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

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

5. Веб-уязвимости и OWASP Top 10: поиск и подтверждение

Веб-уязвимости и OWASP Top 10: поиск и подтверждение

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

Эта статья опирается на предыдущие темы курса:

из материала про роль белого хакера вы берёте scope, ROE, минимизацию вреда и правила работы с данными

из базы по сетям и вебу — понимание HTTP, cookie, сессий, TLS, аутентификации и авторизации

из администрирования — понимание, где живут конфиги, логи и секреты и как они связаны с вебом

из методологии пентеста — дисциплину: разведка → перечисление → анализ → безопасное подтверждение (PoC)

Ключевой ориентир в веб-безопасности — OWASP Top 10: список самых критичных категорий рисков для веб-приложений.

OWASP Top 10

OWASP Web Security Testing Guide

Что считать веб-уязвимостью

Веб-уязвимость — это слабость в приложении, API или их конфигурации, которая позволяет нарушить одно из свойств безопасности:

конфиденциальность (получить доступ к данным)

целостность (изменить данные или логику)

доступность (нарушить работу)

подотчётность (скрыть следы, исказить аудит)

Важно различать:

уязвимость: техническая/логическая слабость

эксплуатация: подтверждение, что слабость реально используется в сценарии

риск: вероятность и ущерб с учётом контекста (какие данные, какие роли, какой периметр)

Как выглядит поверхность атаки веб-приложения

Веб-приложение — это не только «страницы». Обычно это набор компонентов:

Клиент (браузер или мобильное приложение)

Фронтенд (часто статический)

API (REST/GraphQL и другие)

Сервисы аутентификации (SSO, OAuth2/OIDC)

Базы данных и очереди

Хранилища файлов

Интеграции со сторонними провайдерами

!Упрощённая карта компонентов веб-приложения и типовых зон риска

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

Инструменты наблюдения: как видеть то, что делает веб

Чтобы тестировать веб, вам нужно видеть сырые запросы и ответы.

Минимальный набор для учебной практики и легальной работы в рамках ROE:

перехватывающий прокси для просмотра и повторения запросов

браузер и DevTools (Network)

curl для воспроизводимых запросов

Пример воспроизводимого запроса через curl (безопасный, без «атакующих» полезных нагрузок):

В отчёте ценится именно воспроизводимость: конкретный URL, метод, заголовки, код ответа, и минимально необходимый фрагмент результата.

Как подтверждать веб-уязвимости безопасно

Принцип минимально достаточного PoC

PoC (proof of concept) в вебе — это демонстрация, что проблема реально влияет на безопасность, но без лишнего воздействия.

Безопасные правила PoC, которые обычно проходят даже на продуктиве при корректном ROE:

предпочитайте чтение минимального фрагмента данных вместо выгрузки массивов

используйте тестовые аккаунты и тестовые объекты, если они выделены

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

избегайте действий, которые могут повлиять на доступность (нагрузка, массовые запросы)

Что должно быть в доказательствах

Обычно достаточно:

полная строка запроса (метод, путь, ключевые заголовки)

код ответа

один-два примера значимых полей (с маскированием чувствительных данных)

описание условий: какая роль, какая сессия/токен

Типовой шаблон находки для веба

Что: описание проблемы и её класса

Где: URL/эндпоинт, параметр, роль/аккаунт, окружение

Как воспроизвести: шаги без разрушительных действий

Почему это риск: сценарий воздействия

Доказательства: запрос/ответ, скриншот, лог

Рекомендации: конкретные меры

OWASP Top 10 как карта проверок

OWASP Top 10 (редакция 2021) — это категории рисков, которые чаще всего приводят к серьёзным инцидентам. Ниже — краткая «памятка пентестера»: что искать, как подтверждать аккуратно и что обычно рекомендовать.

Источник категорий:

OWASP Top 10:2021

A01: Broken Access Control

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

Типовые признаки:

изменение идентификатора ресурса в URL или JSON меняет доступный объект

разница между 401 и 403 используется неправильно (например, вместо запрета сервер отдаёт данные)

API полагается на проверки во фронтенде, а сервер не проверяет права

Безопасное подтверждение:

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

запросите один чужой объект и зафиксируйте минимальный фрагмент ответа

в идеале подтверждайте на тестовых данных

Что обычно рекомендовать:

серверная проверка прав на каждый объект и действие

принцип «deny by default»

централизованная модель авторизации и единые проверки для всех эндпоинтов

Ориентир по тестированию:

OWASP WSTG: Authorization Testing

A02: Cryptographic Failures

Криптографические сбои — это не «сломанная математика», а ошибки применения: данные передаются или хранятся без нужной защиты.

Типовые признаки:

чувствительные данные уходят по HTTP вместо HTTPS

слабые настройки TLS или неверная конфигурация сертификатов

хранение чувствительных данных в логах или в ответах API без необходимости

Безопасное подтверждение:

фиксируйте, по какому протоколу доступен ресурс (HTTP/HTTPS)

анализируйте заголовки и политику cookie (Secure, HttpOnly, SameSite) без попыток перехвата чужого трафика

Что обычно рекомендовать:

включить HTTPS везде, настроить HSTS при необходимости

безопасные атрибуты cookie

минимизация чувствительных данных в ответах и логах

A03: Injection

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

Важно: в реальном проекте проверка инъекций должна быть согласована, потому что агрессивные тесты могут повлиять на доступность или целостность.

Типовые признаки:

ошибки сервера, связанные с парсингом выражений

различное поведение при «неожиданных» типах данных

отсутствие параметризации запросов и строгой валидации

Безопасное подтверждение:

делайте акцент на доказательстве влияния, а не на «извлечении данных»

фиксируйте воспроизводимый факт некорректной обработки ввода (например, предсказуемая ошибка) без массового перебора

Что обычно рекомендовать:

параметризованные запросы

строгая валидация типов, схемы для JSON

минимальные привилегии учётной записи базы данных

A04: Insecure Design

Небезопасный дизайн — проблема уровня архитектуры и требований. Формально код может быть «без багов», но логика допускает опасный сценарий.

Примеры (как класс):

нет ограничения на критичные операции (например, подтверждение важных действий)

отсутствуют лимиты и контроль злоупотреблений

критичная бизнес-логика реализована только на клиенте

Безопасное подтверждение:

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

показывайте, почему защитный контроль должен быть на сервере

Что обычно рекомендовать:

threat modeling для ключевых функций

безопасные требования к бизнес-процессам

явные проверки на сервере и аудит критичных действий

Ориентир:

OWASP Application Security Verification Standard

A05: Security Misconfiguration

Ошибки конфигурации безопасности — когда система настроена так, что раскрывает лишнее или допускает опасные режимы.

Типовые признаки:

включены отладочные режимы и подробные сообщения об ошибках

открыты административные интерфейсы

небезопасные заголовки безопасности или их отсутствие

доступные каталоги, «листинг», тестовые страницы

Безопасное подтверждение:

собирайте доказательства через заголовки ответа и публично доступные страницы

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

Что обычно рекомендовать:

безопасные значения по умолчанию

отключение debug в проде

инвентаризация и закрытие админ-панелей, сегментация доступа

A06: Vulnerable and Outdated Components

Уязвимые и устаревшие компоненты — риск из-за библиотек, фреймворков и сервисов.

Типовые признаки:

версия компонента известна и имеет публичные уязвимости

нет процесса обновлений и контроля зависимостей

Безопасное подтверждение:

фиксируйте версии из корректных источников (баннер, /version, заголовки, файлы package-lock.json в публичных репозиториях)

избегайте «эксплойтов из интернета» в продуктиве без отдельного согласования

Что обычно рекомендовать:

SBOM и контроль зависимостей

регулярные обновления, окна обслуживания

автоматические проверки уязвимостей в CI/CD

A07: Identification and Authentication Failures

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

Типовые признаки:

слабые политики паролей и отсутствие защиты от перебора

ошибки в 2FA, восстановлении пароля

сессии не инвалидируются после выхода

токены живут слишком долго без ротации

Безопасное подтверждение:

тестируйте на выделенных тестовых аккаунтах

если ROE запрещает перебор, подтверждайте отсутствие защитных механизмов через наблюдаемые признаки (например, отсутствие задержки, отсутствующие сообщения о блокировке) без массированных попыток

Что обычно рекомендовать:

rate limiting и блокировки с учётом UX

корректная инвалидация сессий

MFA для критичных ролей

Ориентир:

OWASP WSTG: Authentication Testing

A08: Software and Data Integrity Failures

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

Типовые признаки:

обновления и пакеты подтягиваются без проверки целостности

интеграции доверяют данным без валидации и подписи там, где это нужно

Безопасное подтверждение:

фокусируйтесь на проверке процесса: откуда берутся артефакты, есть ли подписи, есть ли контроль источника

подтверждайте через конфигурацию и документацию, а не через попытки подмены

Что обычно рекомендовать:

подпись артефактов и проверка целостности

контроль цепочки поставки (supply chain)

ограничения на источники зависимостей

A09: Security Logging and Monitoring Failures

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

Типовые признаки:

критичные события (вход, смена пароля, изменение ролей) не логируются

логи не содержат нужного контекста (кто, что, откуда)

нет алертов на подозрительные действия

Безопасное подтверждение:

согласуйте с заказчиком способ проверки (например, тестовая попытка входа и проверка, что событие попало в журнал)

не собирайте и не выносите логи целиком; фиксируйте только факт наличия или отсутствия записи

Что обычно рекомендовать:

события безопасности как обязательные требования

централизованный сбор логов и ретеншн

алерты на критичные аномалии

A10: Server-Side Request Forgery

SSRF — когда сервер по запросу пользователя делает исходящий запрос к другому ресурсу, и это можно использовать для доступа к внутренним системам.

Типовые признаки:

приложение принимает URL и «ходит за данными» на стороне сервера

есть функции импорта по ссылке, webhook, предпросмотр URL

Безопасное подтверждение:

подтверждайте на специально выделенной тестовой внешней цели, которую контролирует заказчик, либо на стенде

фиксируйте факт исходящего запроса (по логам тестовой цели или безопасным маркерам), не выполняя сканирование внутренних адресов

Что обычно рекомендовать:

allowlist допустимых доменов

запрет внутренних адресов и метаданных облака

отдельные сетевые политики для исходящих запросов

Как превратить OWASP Top 10 в план проверки

Чтобы проверки были системными, удобно идти от модели приложения к категориям OWASP.

Практический порядок работ для веба и API:

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

Проверить контроль доступа на объектном уровне (A01) для каждого критичного действия.

Проверить управление сессией, cookie, вход и восстановление (A07).

Проверить типовые зоны инъекций и валидацию данных (A03).

Проверить конфигурацию и поверхность: заголовки, debug, админки (A05).

Проверить зависимые компоненты и процесс обновлений (A06).

Проверить, что критичные события логируются и мониторятся (A09).

Итог

OWASP Top 10 — это не «чеклист ради чеклиста», а язык, на котором удобно обсуждать риски с разработчиками, безопасниками и руководством.

Профессиональная веб-проверка белого хакера строится так:

вы работаете строго в рамках scope и ROE

вы видите и воспроизводите HTTP-трафик

вы подтверждаете уязвимости минимально достаточным PoC

вы формулируете находки как риск, с чёткими доказательствами и реалистичными рекомендациями

В следующих материалах курса этот фундамент будет расширяться практическими сценариями тестирования веба и API и подходами к оформлению сильного отчёта и ретеста исправлений.

6. Инструменты и практикум: Kali Linux, Burp Suite, Nmap, Metasploit

Инструменты и практикум: Kali Linux, Burp Suite, Nmap, Metasploit

Инструменты белого хакера нужны не для «магии», а для дисциплины: быстро собирать факты, воспроизводимо подтверждать риски, аккуратно сохранять доказательства и не выходить за рамки scope и ROE.

Эта статья связывает предыдущие темы курса:

из материала про роль белого хакера вы берёте разрешение, scope, ROE, конфиденциальность артефактов и принцип минимизации вреда

из базы по сетям и вебу — понимание TCP/IP, HTTP, TLS, cookie, сессий и различие аутентификации и авторизации

из статьи про ОС — базовую ориентировку в Linux/Windows, логах, службах и правах

из методологии — последовательность разведка → перечисление → анализ → безопасный PoC → отчёт

Здесь вы разберёте четыре «опорных» инструмента практики и то, как ими пользоваться профессионально:

Kali Linux как рабочая среда

Burp Suite для тестирования веба и API

Nmap для инвентаризации сервисов и поверхности атаки

Metasploit Framework для управляемого подтверждения некоторых классов уязвимостей в разрешённых условиях

> Важное правило: инструменты не делают работу легальной. Легальность определяют разрешение владельца системы, scope и ROE.

Как инструменты ложатся на методологию пентеста

!Карта, какие инструменты обычно применяются на разных этапах

Практический смысл:

Nmap помогает построить карту доступных сервисов (поверхность атаки) и входных точек

Burp Suite позволяет видеть реальный HTTP-трафик и проверять поведение сервера (особенно авторизацию и обработку входных данных)

Metasploit иногда используют для управляемого подтверждения уязвимости, но только если это разрешено ROE и есть план минимизации воздействия

Kali Linux помогает держать всё это в одном месте, воспроизводимо и с учётом артефактов

Рабочая среда: Kali Linux как «полевой набор»

Kali Linux — специализированный дистрибутив Linux для задач информационной безопасности, где собраны многие инструменты тестирования.

Официальные источники:

Kali Linux Documentation

Kali Linux Tools

Почему удобнее отдельная среда, а не «всё на рабочем ноутбуке»

Изоляция рисков: меньше шансов случайно смешать рабочие данные компании и артефакты пентеста

Воспроизводимость: одинаковые версии инструментов, предсказуемые зависимости

Контроль артефактов: проще хранить отчётные материалы и удалять их по завершении проекта

Дисциплина артефактов: структура проекта

Чтобы отчёт был сильным, а работа — аккуратной, полезно вести единый «проектный» каталог.

Пример структуры (названия условные):

00-scope — scope/ROE, контактные данные, ограничения

01-recon — карта активов и источники (что и откуда собрано)

02-scan-enum — результаты инвентаризации сервисов и точные точки входа

03-web — запросы/ответы, скриншоты, заметки по ролям и эндпоинтам

04-poc — минимальные доказательства (PoC) и условия воспроизведения

05-report — черновик отчёта, таблица находок, приоритеты, ретест

Ключевой принцип: храните только то, что нужно для воспроизведения и исправления. Секреты (токены, пароли, приватные ключи) не должны попадать в «артефакты по умолчанию».

Burp Suite: наблюдение и управление HTTP-трафиком

Burp Suite — набор инструментов для тестирования веб-приложений и API через перехват, анализ и повтор запросов.

Официальные источники:

PortSwigger Burp Suite Documentation

PortSwigger Web Security Academy

Что такое «перехватывающий прокси» простыми словами

Burp действует как промежуточная точка между браузером (или мобильным клиентом) и сервером:

клиент отправляет запрос в Burp

Burp показывает запрос в «сыром» виде

вы можете отправить его дальше без изменений или с правками

Это критично для задач из OWASP Top 10, потому что многие проблемы не видны «по экрану», но видны в HTTP:

контроль доступа (A01) часто проявляется в API-запросах

ошибки аутентификации (A07) часто видны в cookie/токенах и статус-кодах

misconfiguration (A05) часто видна в заголовках и ответах сервера

Основные модули Burp и как они используются в пентесте

| Модуль | Для чего нужен | Типовой результат для отчёта | |---|---|---| | Proxy | перехват и просмотр трафика | точный запрос/ответ, заголовки, cookie | | HTTP history | журнал всех запросов | доказательство маршрута воспроизведения | | Repeater | ручное повторение запросов | воспроизводимый PoC с минимальными изменениями | | Intruder | автоматизация повторяющихся проверок | используется только в рамках ROE (лимиты/скорость) | | Decoder | декодирование/кодирование данных | объяснение форматов токенов и параметров | | Comparer | сравнение ответов | демонстрация различий при смене роли/параметра |

Практика: безопасное подтверждение проблемы авторизации

Здесь важна идея, а не агрессивные проверки.

Типовой безопасный сценарий подтверждения:

Вы используете два тестовых пользователя с разными правами.

Находите запрос к ресурсу, который относится к объекту пользователя (например, «профиль», «заказ», «документ»).

В Repeater аккуратно меняете только идентификатор объекта на «чужой».

Фиксируете результат:

- код ответа - минимально необходимый фрагмент данных (с маскированием) - роль, под которой выполнен запрос

Такой подход соответствует принципу минимизации вреда: вы не выгружаете массивы данных и не делаете нагрузку.

Частые ошибки при работе с Burp

делать выводы по интерфейсу, а не по HTTP

не фиксировать роль/токен, под которым воспроизводится проблема

сохранять в доказательства «всё подряд» (особенно токены и персональные данные)

смешивать окружения (prod и stage) без явной маркировки

Nmap: инвентаризация сервисов и поверхности атаки

Nmap — инструмент для обнаружения доступных хостов и сервисов и для уточнения деталей (порты, протоколы, признаки версии).

Официальные источники:

Nmap Reference Guide

Nmap Book

Что Nmap даёт пентестеру как профессионалу

На практике Nmap помогает ответить на вопросы «перечисления» из методологии:

какие сервисы доступны в рамках scope

по каким протоколам и портам они доступны

какие «входные точки» реально видны из вашей точки доступа (интернет, VPN, внутренняя сеть)

Важно: результат Nmap — это не «лог ради лога», а карта поверхности атаки, пригодная для отчёта.

Как оформлять результаты инвентаризации

Удобно сразу переводить вывод инструмента в структурированный вид.

| Поле | Что фиксировать | Почему это важно | |---|---|---| | Цель | IP/домен из scope | доказательство соблюдения scope | | Контекст | откуда сканировали (интернет/VPN) | поверхность зависит от точки наблюдения | | Сервис | порт/протокол/предполагаемая служба | основа для дальнейшего анализа | | Признак | баннер/ответ протокола | объясняет, почему вы так классифицировали сервис | | Примечание | ограничения ROE, скорость, окна | показывает аккуратность и контроль воздействия |

ROE и «шум»: почему сканирование нужно согласовывать

Сканирование может:

создавать нагрузку на сетевые устройства и сервисы

вызывать срабатывания мониторинга и реагирование

выглядеть как атака, если не согласовано заранее

Поэтому профессиональный подход:

согласовать допустимый уровень активности (скорость, время, запреты)

вести журнал действий (время, цель, тип активности)

использовать только цели из scope

Типовые ошибки при работе с Nmap

включить «всё и сразу» на продуктивной среде без согласования

не фиксировать точку доступа (из-за чего выводы становятся неверными)

воспринимать «порт открыт» как «уязвимость» без анализа конфигурации и контекста

Metasploit Framework: управляемое подтверждение уязвимостей

Metasploit Framework — платформа, которая объединяет техники проверки и подтверждения уязвимостей в виде модулей.

Официальные источники:

Metasploit Documentation

Как правильно понимать Metasploit

Metasploit в работе белого хакера — это не «кнопка взлома», а инструмент, который может:

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

помочь воспроизводимо подтвердить риск

дать стандартизированные артефакты для отчёта

Но при этом Metasploit повышает риск воздействия на систему, поэтому:

применять только при явном разрешении в ROE

предпочитать безопасные методы подтверждения там, где это возможно (например, через конфиг, версию, поведение сервиса)

иметь план остановки и контакты эскалации

Базовые типы модулей (термины без «эксплуатационных деталей»)

Auxiliary: вспомогательные проверки (например, диагностика и проверка отдельных свойств сервиса)

Exploit: модуль, который пытается использовать уязвимость

Payload: действие после успешного использования уязвимости (что именно произойдёт)

Post: действия после подтверждения доступа (например, сбор сведений для отчёта)

Для отчёта важны не названия модулей, а итог:

что именно подтверждено

при каких условиях

как минимизировали вред

какие изменения могли быть внесены и как их убрать (если это разрешено)

Когда Metasploit уместен, а когда нет

| Ситуация | Уместно | Неуместно | |---|---|---| | Учебная лаборатория | да, для понимания механики подтверждения | нет ограничений, но всё равно нужна дисциплина | | Продуктив без отдельного разрешения | почти никогда | да, потому что риск воздействия высокий | | Есть стенд и чёткие ROE | иногда | если нет плана минимизации воздействия | | Можно подтвердить иначе | лучше подтвердить иначе | использовать «потому что быстрее» |

Практикум: безопасная лаборатория и отработка навыков

Цель практикума — научиться воспроизводимо собирать факты и подтверждать выводы, не затрагивая чужие системы.

Что выбрать в качестве учебной цели

Используйте только специально предназначенные для обучения приложения:

OWASP Juice Shop

Damn Vulnerable Web Application (DVWA)

Минимальный набор навыков, который стоит отработать на практике

В Kali настроить рабочее окружение и проектную структуру артефактов.

В Burp:

- включить перехват - научиться находить нужный запрос в истории - повторить запрос в Repeater и зафиксировать минимальный PoC

В Nmap:

- провести инвентаризацию сервисов учебной цели - составить таблицу «хост → сервис → точка входа»

В Metasploit:

- понять структуру модулей и требования ROE - научиться документировать подтверждение так, чтобы оно было безопасным и воспроизводимым

Что должно остаться по итогам практикума

Не «скриншоты всего», а компактный набор артефактов:

карта поверхности атаки (таблица сервисов)

1–2 воспроизводимых примера HTTP-запросов/ответов из Burp

краткие заметки: роль, условия, результат, риск

черновик формулировки находки по шаблону:

- что/где/как воспроизвести/почему риск/доказательство/рекомендация

Итог

Kali Linux, Burp Suite, Nmap и Metasploit полезны ровно настолько, насколько вы применяете их в дисциплине белого хакера:

в рамках разрешения, scope и ROE

с акцентом на воспроизводимость и минимизацию вреда

с артефактами, которые помогают исправить проблему, а не «произвести впечатление»

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

7. Отчётность, remediation и правовые аспекты (договоры, scope)

Отчётность, remediation и правовые аспекты (договоры, scope)

Пентест заканчивается не на этапе поиска уязвимостей. Профессиональный результат белого хакера — это управляемый цикл: согласовать границы, провести проверку, подготовить отчёт так, чтобы его можно было реализовать, помочь с исправлениями (remediation) и выполнить повторную проверку (retest).

Эта статья связывает предыдущие материалы курса:

из темы про роль белого хакера вы берёте разрешение, ROE, минимизацию вреда и ответственность за данные

из тем про сети/веб/ОС — умение формулировать факты языком протоколов, прав и конфигураций

из методологии пентеста — дисциплину разведка → перечисление → анализ → PoC

из OWASP Top 10 и инструментов — практический способ находить и воспроизводимо подтверждать проблемы

Дальше вы разберёте, как оформить результат так, чтобы он был:

юридически корректным (границы, договоры, доказательства разрешения)

технически точным (воспроизводимость, артефакты)

полезным для исправлений (приоритеты, рекомендации, ретест)

!Диаграмма жизненного цикла результатов пентеста и исправлений

Зачем белому хакеру «бумаги» и процесс

Технически одинаковые действия могут быть:

законной проверкой, если есть явное разрешение и соблюдён scope

нарушением, если разрешения нет или вы вышли за рамки

Поэтому профессиональная практика опирается на два уровня фиксации:

юридический и организационный (договоры, правила работ, ответственность, обработка данных)

технический и отчётный (как вы собирали факты, как подтвердили риск, какие действия выполняли)

Ориентиры по отраслевым подходам к тестированию и отчётности:

NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

OWASP Web Security Testing Guide

PTES Penetration Testing Execution Standard

Scope и ROE: как определить и удержать границы

Что такое scope

Scope — это перечень разрешённых целей и типов работ. Он отвечает на вопрос: что именно мы имеем право тестировать.

В scope обычно фиксируют:

активы: домены, поддомены, IP-адреса/диапазоны, приложения, API, мобильные приложения

окружения: прод/стенд/тест

учётные записи: какие роли и сколько тестовых пользователей выделено

допустимые виды активности: например, можно ли сканирование, можно ли проверка подбора паролей

исключения: что тестировать нельзя (например, платёжный контур, партнёрские сервисы)

Что такое ROE

ROE (Rules of Engagement) — правила проведения работ. Они отвечают на вопрос: как именно можно тестировать, чтобы не вызвать инцидент и соблюсти обязательства.

ROE обычно включает:

временные окна и «тихие часы»

лимиты по нагрузке и скорости (особенно для сканирования)

запреты: DoS, массовые рассылки, социальная инженерия, эксплуатация без отдельного согласования

контакты эскалации: кому звонить при непредвиденном эффекте

правила обращения с данными и артефактами (что можно сохранять, где хранить, когда удалять)

Как не выйти за scope на практике

Типовые причины выхода за рамки — не «плохие намерения», а организационные ошибки:

поддомен указывает на сторонний сервис (SaaS), который не принадлежит заказчику

инфраструктура меняется во время проекта (новые IP, миграции)

приложение использует внешние интеграции (платежи, SMS, почта), и тест случайно задевает третью сторону

Практический подход к контролю:

Перед активными действиями сверяйте цель с письменным scope.

Если обнаружили актив «рядом», но не уверены, что он в scope — фиксируйте как наблюдение и запрашивайте уточнение.

Для неоднозначных случаев используйте стоп-правило: при сомнении остановиться и согласовать.

Договорная рамка: какие документы встречаются и что в них важно

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

Ниже — типовой набор, который часто встречается в проектах.

| Документ/раздел | Что обычно фиксирует | Почему важно белому хакеру | |---|---|---| | NDA (соглашение о конфиденциальности) | что нельзя разглашать, срок, порядок передачи материалов | защищает заказчика и вас; определяет, как хранить артефакты | | MSA (рамочный договор) | общие условия, ответственность сторон, порядок оплаты | задаёт «правила игры» для серии работ | | SOW (техническое задание/объём работ) | конкретный scope, сроки, формат отчёта, ретест | главный источник прав на конкретные активы | | ROE | правила тестирования, ограничения, контакты, окна | снижает риск инцидента и споров «что вы делали» | | Раздел про данные (иногда DPA) | правила обработки данных, хранение, удаление | критично при доступе к персональным данным |

Важно: если вы не уверены, что формулировка в документах покрывает ваш метод проверки — это не «техническая мелочь», а причина остановиться и уточнить.

Артефакты и доказательства: что сохранять, а что нельзя

Вы уже видели принцип минимизации вреда. В отчётности он превращается в правило: хранить минимально достаточные доказательства.

Принципы безопасных артефактов

сохраняйте только то, что нужно для воспроизведения и исправления

маскируйте чувствительные данные (частичные значения, хэш, редактирование)

фиксируйте контекст: дата/время, роль пользователя, окружение, точка доступа (интернет/VPN)

отделяйте «доказательство проблемы» от «данных пользователей»

Примеры хороших доказательств

| Класс находки | Достаточное доказательство | Что обычно избыточно | |---|---|---| | Broken Access Control | один запрос/ответ, показывающий доступ к чужому объекту, с маскированием | выгрузка списка всех объектов или дамп базы | | Misconfiguration | заголовки ответа, скриншот открытой админ-страницы | автоматизированный перебор всех директорий без ROE | | Секреты в конфиге | одна строка/фрагмент с маскированием и путём файла | копирование всего файла/каталога |

Цепочка хранения (chain of custody) в прикладном смысле

Иногда результаты пентеста используют для внутреннего расследования. Тогда полезно уметь отвечать:

где лежали артефакты

кто имел доступ

менялись ли они

Практический минимум:

Хранить материалы проекта в отдельной структуре каталогов.

Ограничивать доступ (шифрование диска/архива, доступ по необходимости).

Вести журнал: что сохранено и почему.

Структура профессионального отчёта

Отчёт должен быть понятен сразу трём аудиториям:

руководству (что за риски и приоритеты)

владельцам систем/разработчикам (как исправить)

безопасности/аудиту (как проверяли и что подтверждено)

Шаблон одной находки

Чтобы отчёт был воспроизводимым, каждую находку удобно писать по единому шаблону:

Название и класс (например, Broken Access Control)

Затронутые активы (URL/эндпоинт/хост)

Условия (роль, окружение, точка доступа)

Шаги воспроизведения

Фактический результат и ожидаемый результат

Доказательство (запрос/ответ, скриншот, лог)

Риск (что может сделать атакующий и к чему это приведёт)

Рекомендации (конкретные действия, а не общие слова)

Статус (open/fixed/retest needed)

Приоритизация и понятие «критичности»

В отчётах важно не просто перечислить проблемы, а дать приоритет исправления.

Подходы к оценке

Самые распространённые практики:

внутренняя шкала компании (например, Critical/High/Medium/Low)

использование CVSS как единого языка метрик

Официальный источник по CVSS:

FIRST CVSS v3.1 Specification

Важно: CVSS — это про техническую оценку, а бизнес-приоритет может быть выше или ниже из-за контекста (какие данные, какой периметр, какие компенсирующие меры).

Практическая формула приоритета без «сложной математики»

Чтобы не спорить абстрактно, опирайтесь на три вопроса:

насколько легко эксплуатировать (нужна ли авторизация, сложные условия)

какое воздействие (данные, деньги, доступность)

насколько широко затронуто (один сервис или вся платформа)

Хорошая приоритизация в отчёте — это объяснение, а не только метка.

Remediation: как помочь исправить уязвимости

Remediation — процесс исправлений и снижения риска. Он обычно включает не только код, но и конфигурацию, инфраструктуру и процессы.

Коммуникация по исправлениям

Чтобы remediation не превратился в переписку без результата, заранее согласуйте:

SLA по критичным находкам (например, сроки реакции)

канал связи и формат вопросов

необходимость воркшопа/разбора отчёта

И полезная практика: отмечать в отчёте, какие находки блокируют ретест (например, если требуется доступ к стенду или новый билд).

Retest: повторная проверка исправлений

Retest подтверждает, что:

уязвимость действительно устранена

исправление не «маскирует симптом» (например, меняет сообщение об ошибке, но не закрывает доступ)

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

Как правильно описывать ретест

В отчёте по ретесту обычно достаточно:

ссылку на исходную находку (ID)

что изменилось (версия/дата релиза/конфиг)

те же шаги воспроизведения, что раньше

новый фактический результат

статус: fixed/partially fixed/not fixed

Важно: ретест — это не «повторить весь пентест», а проверка конкретных исправлений, если не согласовано иначе.

Правовые и этические риски в отчётности

Типовые опасные ситуации

хранение лишних данных: доказательства содержат персональные данные или секреты без необходимости

раскрытие уязвимостей не тем адресатам: отправка отчёта в открытые каналы, публикация без согласования

неясное разрешение: нет документа, который явно разрешает тест конкретного актива

выход за scope: «проверили соседний сервис, потому что он был рядом»

Как снизить риски

До старта работ убедиться, что scope покрывает активы и методы.

Согласовать формат доказательств (особенно при работе с персональными данными).

Использовать защищённые каналы передачи отчётов и артефактов.

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

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

CERT/CC Vulnerability Disclosure

Итог

Профессиональная работа белого хакера — это связка:

правильные границы (scope и ROE)

чистые артефакты (минимально достаточные доказательства)

сильный отчёт (воспроизводимость, приоритеты, рекомендации)

remediation и ретест (закрыть риск, а не просто «найти баг»)

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