Как стать простым этичным хакером: основы и практика

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

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

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

Почему право и этика — это не формальность

Одинаковые технические действия могут быть:

законной проверкой безопасности

нарушением закона

Разница обычно не в инструменте, а в разрешении и рамках (scope).

Ключевые понятия

Авторизация — явное разрешение владельца системы на проверку.

Объём работ (scope) — список систем, методов и ограничений, которые разрешены.

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

Ущерб — не только взлом, но и простои, удаление/порча данных, утечки, финансовые потери.

> "Without authorization, scanning or probing a system for vulnerabilities may be illegal." OWASP Web Security Testing Guide

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

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

Чтобы ориентироваться, держите в голове три вопроса:

Чьё это? Кто владелец системы или данных.

Есть ли у меня письменное разрешение? И достаточно ли оно конкретное.

Что именно разрешено делать? Какие методы, какие временные окна, какие системы.

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

США: Computer Fraud and Abuse Act (CFAA) — Cornell Law School

Великобритания: Computer Misuse Act 1990 — legislation.gov.uk

ЕС: Directive (EU) 2022/2555 (NIS2) — EUR-Lex

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

Этика: что отличает этичного хакера

Этика — это правила поведения там, где один “лишний” шаг причиняет вред.

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

Разрешение прежде всего: никаких проверок “просто из интереса” на чужих ресурсах.

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

Минимизация данных: не собирать лишнее, не копировать базы “на всякий случай”.

Конфиденциальность: всё найденное — чувствительная информация.

Ответственное раскрытие: сообщать уязвимости так, чтобы помочь исправить, а не навредить.

Что такое ответственное раскрытие уязвимостей

Ответственное раскрытие (responsible disclosure) — это процесс, в котором вы:

Проверяете, что уязвимость реальна, в рамках разрешений.

Сообщаете владельцу безопасным каналом.

Даёте время на исправление.

Не публикуете детали до устранения (или до согласованного срока).

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

HackerOne Disclosure Guidelines

Документы и договорённости: минимум, который вас защищает

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

Что должно быть в разрешении (даже учебном)

Кто даёт разрешение и на какие системы.

Временные рамки (когда можно тестировать).

Разрешённые методы (например, можно сканирование портов, но нельзя DoS).

Запрещённые действия (например, нельзя трогать персональные данные).

Контакт для экстренной остановки.

Таблица: действия и типичный статус

| Действие | Без разрешения | С разрешением и в scope | |---|---:|---:| | Сканирование чужих IP/доменов | Обычно незаконно/рискованно | Допустимо при ограничениях | | Тестирование своего стенда | Законно | Законно | | Попытки подобрать пароли к чужим аккаунтам | Незаконно | Может быть допустимо только при явном разрешении и ограничениях | | Публикация эксплойта на найденную уязвимость “в проде” | Почти всегда вред и риск | Обычно запрещено, если не согласовано |

Безопасная лаборатория: где тренироваться без риска

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

Главные требования к лаборатории

Изоляция: лабораторные машины не должны случайно “светиться” в интернет.

Контролируемость: возможность откатиться (snapshots) после ошибок.

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

Безопасность хоста: ваш основной компьютер защищён, обновлён, с резервными копиями.

!Схема показывает, как изолировать атакующую и целевую ВМ от интернета и почему важны снапшоты

Сборка лаборатории: практичный и безопасный план

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

Что установить

Виртуализатор:

- VirtualBox

Образы/машины:

- Linux для работы (например, обычный Ubuntu) или специализированная среда - Уязвимые учебные приложения/машины

Учебные цели (targets), которые можно использовать легально

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

OWASP Juice Shop

Damn Vulnerable Web Application (DVWA)

Metasploitable 2

Важно: скачивайте только с официальных страниц/репозиториев и держите такие системы изолированными.

Настройка сети: безопасные варианты

Host-only: виртуальные машины видят друг друга и хост, но не выходят в интернет. Это базовый безопасный вариант.

NAT: даёт интернет виртуальной машине, но внешние устройства обычно не видят эту ВМ.

Bridged (мост): ВМ становится “как отдельный компьютер” в вашей домашней сети. Для уязвимых целей почти всегда не рекомендуется.

Рекомендуемая конфигурация

Создайте две виртуальные машины:

1. Рабочая (где вы изучаете инструменты) 2. Целевая (уязвимое приложение/машина)

Подключите обе к Host-only сети.

Отключите целевой ВМ доступ в интернет.

Включайте NAT временно только для обновлений рабочей ВМ.

Сделайте snapshot до начала практики и после каждого значимого этапа.

Безопасность данных и личная гигиена при обучении

Что нельзя делать даже “в лаборатории”

Использовать реальные чужие базы/утечки.

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

Пытаться “проверять” Wi‑Fi соседей, чужие камеры, роутеры.

Как не навредить себе

Используйте отдельные тестовые пароли и тестовые учётные записи.

Не храните “находки” в открытом виде (скриншоты с токенами, паролями).

Ведите заметки так, чтобы в них не было секретов (или храните их в защищённом хранилище).

Обновляйте хостовую ОС и виртуализатор.

Правило курса: когда вы можете действовать

Вы действуете только если одновременно выполняются условия:

система принадлежит вам или у вас есть явное разрешение владельца

вы понимаете и соблюдаете scope

вы работаете в безопасной лаборатории, если это обучение

Если хотя бы одно условие не выполнено — вы останавливаетесь и выбираете легальную альтернативу (учебные стенды, CTF с правилами, песочницы).

Что дальше по курсу

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

базовые понятия сетей и веба

модель угроз и типовые уязвимости

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

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

Основы сетей, ОС и командной строки

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

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

Минимальная карта понятий

Чтобы не тонуть в деталях, держите в голове три слоя:

Сеть отвечает за доставку данных от одного узла к другому.

ОС управляет процессами, файлами, пользователями и сетью на вашем компьютере.

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

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

Основы сетей

Узлы, адреса и уровни

Узел — устройство в сети: ваш компьютер, виртуальная машина, роутер, сервер.

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

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

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

IP нужен для движения между узлами на уровне маршрутизации.

MAC нужен для доставки внутри локальной сети.

TCP и UDP простыми словами

На транспортном уровне чаще всего встречаются два протокола:

TCP — надёжная доставка: устанавливается соединение, данные подтверждаются, порядок сохраняется.

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

Вы будете постоянно видеть это в виде записи IP:порт, например 192.168.56.10:22.

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

Порт — это логический “номер двери” внутри узла, который помогает понять, какой программе предназначены входящие данные.

Веб: 80 (HTTP), 443 (HTTPS)

SSH: 22

DNS: 53

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

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

Люди работают с именами вроде example.com, а сети доставляют по IP. DNS — система, которая отвечает на вопрос: “какой IP соответствует этому имени?”.

Клиент (ваша ОС) отправляет DNS-запрос.

Получает IP-адрес.

Далее подключается к этому IP по нужному порту.

Полезный справочник по DNS: Документация Cloudflare по DNS

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

Маршрутизация — выбор пути, по которому пакет пойдёт к цели.

Шлюз (gateway) — узел, через который вы выходите в другие сети (часто домашний роутер).

NAT — механизм, когда много устройств в локальной сети используют один внешний IP (обычно на роутере).

Для лаборатории из прошлой статьи это критично:

Host-only сеть в виртуализаторе помогает изолировать учебные машины.

NAT может дать интернет вашей “рабочей” ВМ для обновлений.

Что такое “сканирование” в безопасном смысле

В рамках курса важно понимать термин:

Сканирование портов — проверка, какие порты на узле “открыты” (то есть сервис слушает соединения).

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

Основы операционных систем (с упором на Linux)

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

Процесс — выполняемая программа.

Служба (service/daemon) — процесс, который работает в фоне и предоставляет функциональность (например, веб-сервер).

Для диагностики вы часто выясняете:

какой процесс слушает порт

от какого пользователя он запущен

где его конфигурация и логи

Пользователи, группы и принцип минимальных привилегий

Linux различает:

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

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

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

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

Файловая система и пути

/ — корень файловой системы.

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

/etc — конфигурация системы и многих служб.

/var/log — логи.

Различайте:

абсолютный путь: начинается с /, например /var/log/syslog

относительный путь: считается от текущей директории, например logs/app.log

Права доступа к файлам

Базовая модель:

r — чтение

w — запись

x — выполнение

Права задаются отдельно для:

владельца файла

группы

остальных

Это важно в практике: уязвимости часто связаны с тем, что конфиги, ключи или резервные копии доступны “не тем”.

Справочник по правам доступа: GNU Coreutils: chmod invocation

Командная строка: базовый набор, который нужен постоянно

Термины

Shell — программа, которая принимает команды (часто bash или zsh).

Терминал — приложение, в котором вы видите shell.

Команда — имя программы + аргументы.

Пример:

Здесь ls — команда, -la — параметры, /var/log — аргумент (путь).

Навигация и работа с файлами

Минимальные команды:

pwd — показать текущую директорию

ls — список файлов

cd — перейти в директорию

mkdir — создать директорию

cp — копировать

mv — переместить/переименовать

rm — удалить

Команды просмотра содержимого:

cat — вывести файл целиком

less — просмотр постранично

head — первые строки

tail — последние строки

Поиск и фильтрация: то, что ускоряет работу в разы

grep — найти строки по шаблону

find — найти файлы по условиям

wc — посчитать строки/слова/байты

sort — сортировка строк

uniq — удаление повторов (обычно после сортировки)

Особенно важны конвейеры.

Конвейеры и перенаправление

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

| передаёт вывод одной команды на ввод другой

> перезаписывает файл выводом команды

>> добавляет вывод команды в конец файла

Пример безопасного анализа логов (в своей системе или лаборатории):

Смысл:

cat читает файл

grep оставляет строки со словом Failed

wc -l считает количество строк

Сеть из командной строки (безопасные примеры)

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

| Задача | Команда | Безопасный пример (локально/в лабе) | |---|---|---| | Проверить интерфейсы и IP | ip a | ip a | | Посмотреть маршруты | ip r | ip r | | Проверить доступность узла | ping | ping -c 1 127.0.0.1 | | Посмотреть активные соединения и слушающие порты | ss | ss -tulpen | | DNS-запрос | dig | dig example.com | | HTTP-запрос и диагностика ответа | curl | curl -I http://127.0.0.1 |

Документация по curl: curl documentation

Замечания:

127.0.0.1 — это локальный хост, обращения к нему не выходят в сеть.

Для целевых машин используйте IP из вашей Host-only сети (например, 192.168.56.0/24, если вы так настроили VirtualBox).

Привилегии: когда нужен sudo

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

Но в обучении держите правило:

сначала пробуйте команду без sudo

добавляйте sudo, только если понимаете, почему без него нельзя

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

Справочник по sudo: sudo manual

Как это связывается с этичным хакингом

Этичный хакер почти всегда делает три вещи:

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

собирает факты (логи, конфиги, ответы сервисов)

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

Именно поэтому сети, ОС и командная строка — фундамент: без них инструменты будут выглядеть как “магия”, а отчёты — как набор случайных терминов.

Мини-чеклист для вашей лаборатории перед практикой

Убедитесь, что уязвимая целевая ВМ в изолированной сети (Host-only).

Проверьте IP-адреса обеих ВМ командой ip a.

Проверьте связность между ВМ (например, ping по IP в Host-only сети).

Сделайте snapshot перед экспериментами.

Что дальше

Следующие темы курса обычно опираются на этот материал так:

разбор веба и HTTP через curl, DNS и порты

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

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

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

Разведка и моделирование угроз: как искать поверхность атаки

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

Право, этика и лаборатория: действуем только с разрешением и в рамках scope, а учимся в изолированной среде.

Сети, ОС и командная строка: понимаем IP, порты, DNS, процессы и умеем собирать факты командами.

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

Разведка (reconnaissance) — сбор информации о системе, чтобы понять, что вообще можно проверять.

Моделирование угроз (threat modeling) — способ заранее прикинуть, что может пойти не так, где наиболее вероятны ошибки и какой ущерб они принесут.

Поверхность атаки (attack surface) — все точки, через которые система может быть атакована: сетевые сервисы, веб-страницы, учётные записи, интеграции, настройки, человеческие процессы.

Ключевая мысль: разведка даёт карту фактов, моделирование угроз превращает карту в план проверки.

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

Безопасные рамки разведки

Разведка бывает пассивной и активной.

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

Активная разведка — запросы к системе и её сервисам (например, проверка портов, запросы HTTP, идентификация версий).

Важно связать это с правилами из первой статьи.

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

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

Мини-правило перед любым шагом

Перед запуском команды задайте себе три вопроса.

Это точно в scope?

Это точно моя лаборатория или есть разрешение?

Эта команда может создать нагрузку или изменить данные?

Если ответ на третий вопрос да, ищите более безопасную альтернативу или настройте ограничения.

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

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

Инвентарь обычно отвечает на вопросы.

Какие узлы существуют (IP, имена)?

Какие порты открыты?

Какие сервисы и версии работают?

Какие страницы, API-методы и функции доступны?

Где границы доверия (что доступно изнутри, что снаружи)?

Какие роли и уровни доступа существуют?

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

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

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

Шаг 1. Опишите систему словами

Минимальный шаблон описания.

Что это за система (веб-приложение, API, сервер)?

Для кого она (пользователи, админы)?

Где она работает (одна ВМ, несколько контейнеров, облако)?

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

Шаг 2. Определите активы

Актив — то, что имеет ценность и что вы защищаете.

Примеры активов.

Учётные записи пользователей.

Секреты: пароли, токены, ключи API.

Данные: профили, заказы, файлы, резервные копии.

Доступность сервиса: чтобы сайт не падал.

Практический приоритет: сначала защищают то, что даёт максимальный ущерб при компрометации.

Шаг 3. Найдите входные точки

Входная точка — место, где данные или команды попадают в систему.

Типичные входные точки.

Открытые сетевые порты.

Веб-страницы, формы, загрузка файлов.

API-эндпоинты.

Панели администрирования.

SSH-доступ.

Интеграции: вебхуки, очереди, БД, внешние сервисы.

Шаг 4. Отметьте границы доверия

Граница доверия — место, где меняется уровень контроля.

Интернет → веб-сервер.

Веб-сервер → база данных.

Обычный пользователь → админ.

Ваш браузер → API.

!Пример, где искать границы доверия и потоки данных

Шаг 5. Сформулируйте угрозы простыми предложениями

Угроза — это не название уязвимости, а сценарий.

Примеры формулировок.

"Пользователь может увидеть чужие заказы, подменив идентификатор".

"Злоумышленник может подобрать пароль к админке".

"Сервис может упасть из-за слишком тяжёлого запроса".

"Секретный ключ может утечь из конфигурации или логов".

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

Подмена личности.

Подмена данных.

Отказ от совершения действий.

Раскрытие информации.

Отказ в обслуживании.

Повышение привилегий.

Источник для чтения: Microsoft Learn: STRIDE threat model

Шаг 6. Приоритизируйте

Приоритизация нужна, чтобы не проверять всё подряд.

Простой подход.

Насколько легко это сделать?

Насколько большой ущерб?

Есть ли уже защитные меры (аутентификация, валидация, лимиты)?

Результат моделирования угроз — это список проверок: что тестировать первым и почему.

Дополнительный ориентир: OWASP: Threat Modeling

Практика разведки в лаборатории: от сети к приложению

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

Слой сети: кто с кем связан

Цель: понять адреса и маршрут в вашей лаборатории.

Примеры команд на рабочей ВМ.

Что вы фиксируете в заметках.

IP вашей рабочей ВМ.

IP целевой ВМ.

Подсеть (например, 192.168.56.0/24 в Host-only сетях VirtualBox).

Далее проверяете связность в лаборатории.

Если ping запрещён или выключен на цели, это не проблема: наличие или отсутствие ответов — тоже факт.

Слой портов: какие "двери" открыты

Цель: узнать, какие сервисы вообще доступны.

Самый безопасный старт.

Сначала посмотрите на своей машине, что слушает порты: это тренировка логики.

Далее, если вы в лаборатории или у вас есть разрешение, можно проверять порты на целевой ВМ.

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

Инструмент, который часто применяют для этой задачи: Nmap.

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

Как читать результат в терминах инвентаря.

Порт open → есть сервис, это входная точка.

Порт closed → сервис не слушает.

Порт filtered → что-то фильтрует трафик (например, firewall), это тоже часть поверхности атаки.

Слой сервисов: что именно работает на порту

Цель: определить тип сервиса и (осторожно) версии.

Для веба часто достаточно curl.

Что полезно фиксировать.

Код ответа (например, 200, 301, 401, 403).

Заголовки (например, Server, Set-Cookie, Content-Security-Policy).

Редиректы и базовый URL.

Важно: заголовок Server может быть скрыт или подменён. Это подсказка, а не истина.

Для SSH (если открыт 22) цель разведки не "войти", а понять, что сервис существует и как он настроен.

Никакого подбора паролей без отдельного разрешения и ограничений.

Слой приложения: страницы, функции, роли

Цель: собрать карту того, что пользователь может сделать.

Для учебных стендов (DVWA, Juice Shop) вы можете составить таблицу.

Страницы и разделы.

Какие параметры принимает страница (в URL, в формах).

Какие роли существуют (гость, пользователь, админ).

Где используются cookies и токены.

Инструменты уровня браузера (DevTools) здесь так же важны, как и командная строка.

Слой данных и конфигураций (внутри лаборатории)

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

Если вы администрируете стенд и это ваша лаборатория, вы можете посмотреть.

Где конфиги (/etc, файлы .env).

Где логи (/var/log).

Какие процессы запущены.

Команды-ориентиры.

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

Документирование: ваш главный "инструмент" разведки

Разведка ценна только тогда, когда она воспроизводима.

Что стоит фиксировать.

Дата и версия стенда.

IP, доменные имена, подсети.

Команды и их вывод (или краткое резюме).

Найденные входные точки.

Предположения и вопросы.

Простой шаблон заметки.

Цель: 192.168.56.10 (Host-only)

Открытые порты: 22/tcp, 80/tcp

Веб:

- / → 200 OK - /admin → 302 на /login - cookies: есть Set-Cookie

Гипотезы:

- проверить аутентификацию и роли - проверить, нет ли лишней информации в заголовках

Частые ошибки новичков

Делать активную разведку вне scope.

Сканировать "всё подряд" вместо целевых проверок.

Путать факт и интерпретацию: "порт 80" не означает "безопасно" или "небезопасно".

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

Игнорировать границы доверия и роли.

Итог

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

Разведка даёт инвентарь поверхности атаки.

Моделирование угроз превращает инвентарь в приоритетный план проверок.

Всё это делается в рамках этики и закона: только с разрешением и, для обучения, в изолированной лаборатории.

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

Сканирование и базовые уязвимости: веб, сервисы, конфигурации

В прошлых статьях мы заложили основу.

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

Вы понимаете базу: IP, порты, DNS, процессы, права доступа и команды.

Вы умеете делать разведку: собирать инвентарь поверхности атаки и превращать его в план.

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

Под “базовыми” здесь понимаются не “простые взломы”, а типовые проблемы:

лишние открытые сервисы

неверные настройки (misconfiguration)

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

слабая аутентификация

избыточная информация в ответах сервиса

> “Security misconfiguration is one of the most common issues.” OWASP Top 10:2021

Рамки безопасности перед сканированием

Сканирование и перечисление (enumeration) почти всегда относятся к активным действиям. Вне лаборатории это допустимо только при явном разрешении и в рамках scope.

Практическая политика курса для этой статьи.

Сканируем только свои ВМ и учебные стенды (DVWA, Juice Shop, Metasploitable) в Host-only сети.

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

Не делаем подбор паролей, если это не выделено отдельным разрешением и заданием.

Любое наблюдение превращаем в заметку: команда → результат → вывод → рекомендация.

!Схема показывает безопасный поток работы: лаборатория → сканирование → проверка → отчёт

Термины, которые нужны в этой теме

Сканирование портов — проверка, какие порты на цели отвечают как открытые.

Перечисление (enumeration) — уточнение, что именно работает на открытых портах.

Сервис — программа, которая слушает порт (например, веб-сервер, SSH).

Баннер (banner) — кусок информации, который сервис может “выдать” при подключении (иногда включает версию).

Конфигурационная ошибка (misconfiguration) — небезопасная настройка: лишние права, дефолтные учётки, debug-режим, открытые панели.

Методика: от “что открыто” к “что опасно”

В этичном подходе важно не “нажимать всё подряд”, а двигаться по ступеням.

Шаг 1: зафиксировать контекст цели

Убедитесь, что вы в правильной сети (Host-only) и знаете IP цели.

Зафиксируйте дату, версию стенда и IP в заметках.

Проверьте связность (если это уместно в лаборатории).

Примеры команд на атакующей ВМ.

Если ping не отвечает, это не “поломка”, а факт: ICMP мог быть запрещён.

Шаг 2: мягкое сканирование портов

Цель — получить список входных точек, а не “просканировать весь мир”.

Инструмент для лаборатории: Nmap.

Пример мягкого старта (малый набор портов).

Расшифровка параметров.

-sS — TCP SYN scan (часто используют как базовый).

-Pn — не полагаться на ping, сразу проверять порты.

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

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

Важно: определение версий — это попытка “поговорить” с сервисом. В реальных работах это может быть чувствительно, поэтому всегда сверяйтесь со scope.

Шаг 3: перечисление веба через HTTP

Если открыт 80 или 443, начинайте с безопасного осмотра ответа.

заголовки

коды ответа

редиректы

cookies

Команда для заголовков.

Что полезно выписать.

HTTP/1.1 200 OK или другой статус

Server: (иногда показывает тип/версию)

Set-Cookie: (атрибуты безопасности)

Location: (куда редиректит)

Справочник по кодам статуса: MDN Web Docs: HTTP response status codes.

Шаг 4: перечисление локально на цели (если вы админ стенда)

В лаборатории вы часто контролируете целевую ВМ. Это полезно, потому что вы учитесь видеть связь “порт → процесс → конфиг → риск”.

На целевой ВМ.

Вы ищете.

какой процесс слушает порт

от какого пользователя он запущен

есть ли сервисы, которые не должны быть доступны

Типовые находки на уровне сервисов

Ниже — частые проблемы, которые обнаруживаются уже на этапе “порты и сервисы”.

Лишние открытые порты

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

Примеры.

открыта база данных (например, PostgreSQL) на интерфейсе, доступном из сети

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

Почему это риск.

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

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

Рекомендации.

закрыть порт firewall’ом

слушать сервис только на 127.0.0.1, если он нужен только локально

убрать сервис, если он не нужен

Устаревшие версии сервисов

Суть проблемы: сервис имеет известные уязвимости, потому что давно не обновлялся.

Что можно сделать этично на базовом уровне.

зафиксировать версию из nmap -sV или баннера

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

Важно: поиск конкретных эксплойтов и попытки эксплуатации в этом уроке не нужны. Здесь тренируем обнаружение и документирование.

“Слишком разговорчивые” баннеры

Суть проблемы: сервис сообщает лишнее.

точная версия веб-сервера

детали платформы

внутренние имена

Почему это риск.

упрощает подбор атак под конкретные версии

Рекомендация.

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

Базовые веб-уязвимости и слабые настройки

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

Отсутствие HTTPS там, где нужны учётные данные

Суть проблемы: логины/пароли или токены могут передаваться без шифрования.

Что вы проверяете.

есть ли https://

редиректит ли http:// на https://

Пример.

Если это учебный стенд, отсутствие HTTPS может быть нормой для лаборатории. В реальном мире это фиксируется как серьёзный риск.

Справочник: MDN Web Docs: HTTPS.

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

Суть проблемы: cookies аутентификации выданы без защитных флагов.

На что смотреть в Set-Cookie.

HttpOnly (уменьшает риск кражи cookie через XSS)

Secure (cookie отправляется только по HTTPS)

SameSite (уменьшает риск CSRF в типовых сценариях)

Справочник: MDN Web Docs: Set-Cookie.

Лишняя информация в ошибках

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

Почему это риск.

раскрывает внутреннее устройство

даёт подсказки для дальнейших атак

Как проверять аккуратно.

наблюдать ответы на “обычные” ошибочные запросы (например, несуществующая страница)

не пытаться ломать вводом агрессивных payload’ов в этом уроке

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

Суть проблемы: панель администратора доступна всем.

Что считается “базовой проверкой”.

обнаружить факт существования /admin, /manager, /dashboard

посмотреть коды ответов 200/401/403/302

Пример.

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

Дефолтные учётные данные

Суть проблемы: не изменены стандартные логины/пароли.

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

Этичный способ мышления.

сначала ищем документацию стенда

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

фиксируем факт и рекомендуем смену/запрет дефолтов

Базовые уязвимости конфигурации и “гигиены”

Значительная часть проблем безопасности — это не “хитрые баги”, а ошибки настройки.

Принцип “минимума наружу”

Практический ориентир.

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

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

Типовые ошибки.

.env файл доступен из веба

резервные копии лежат рядом с сайтом (например, backup.zip)

включён debug-режим

каталог логов доступен через веб

Слабые права доступа и секреты в файлах

В лаборатории вы можете увидеть проблемы прямо в файловой системе цели.

секреты лежат в открытых файлах

ключи доступны “всем”

конфиги читаются не тем пользователем

Команды-ориентиры.

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

Ненужные компоненты и демо-страницы

Суть проблемы: оставлены тестовые страницы, примеры, демо-конфиги.

Почему это риск.

они часто менее защищены

иногда содержат подсказки или даже секреты

Как превращать находки в отчёт

Проверка безопасности ценна не списком “страшных слов”, а связкой: факт → риск → рекомендация.

Удобный шаблон одной находки.

Факт: что вы наблюдали (порт, заголовок, файл, настройка).

Доказательство: команда и краткий результат.

Риск: что плохого может случиться.

Рекомендация: что сделать.

Контекст: где это обнаружено (лаборатория, стенд, версия).

Таблица: быстрый справочник “находка → почему важно → что делать”

| Находка | Почему это риск | Что обычно рекомендуют | |---|---|---| | Открыт лишний порт | Увеличивает поверхность атаки | Закрыть порт, ограничить интерфейс, удалить сервис | | Сервис с устаревшей версией | Возможны известные уязвимости | Обновить, включить процесс патч-менеджмента | | Баннеры и заголовки раскрывают версии | Помогает атакующему подобрать метод | Скрыть/минимизировать раскрытие информации | | Нет HTTPS для логина | Перехват учётных данных | Включить TLS, редирект на HTTPS | | Cookie без HttpOnly/Secure/SameSite | Повышает риски XSS/CSRF/перехвата | Настроить атрибуты cookies | | Админка доступна всем | Цель для атак на учётки | Ограничить доступ, усилить аутентификацию | | Дефолтные учётные данные | Компрометация “в один шаг” | Смена дефолтов, политика паролей | | Debug/stack trace в ошибках | Утечки деталей системы | Выключить debug в проде, настроить обработку ошибок |

Частые ошибки новичков при сканировании

Сканировать “всё” вместо узкого, контролируемого набора.

Путать обнаружение и эксплуатацию: находка версии — это ещё не “взлом”.

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

Делать выводы без подтверждения: заголовок Server может быть подменён.

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

Итог

В этом уроке вы научились главному практическому циклу этичного хакера на раннем этапе.

Сканирование выявляет входные точки.

Перечисление объясняет, что это за точки.

Базовые уязвимости часто лежат в конфигурации и “гигиене”.

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

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

Отчёт, устранение уязвимостей и рост навыков

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

Теперь важнейший шаг, который отличает “нашёл проблему” от реальной пользы: оформить понятный отчёт, помочь устранить уязвимость и подтвердить исправление. Именно так выглядит практическая работа этичного хакера: вы не просто фиксируете находки, вы помогаете сделать систему безопаснее.

!Диаграмма показывает полный цикл: от находки до подтверждённого исправления и роста процесса

Зачем нужен отчёт

Отчёт в безопасности решает сразу несколько задач:

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

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

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

защищает вас и заказчика: показывает, что вы действовали в рамках scope и не выходили за границы разрешённого

Важная установка: цель отчёта — исправление, а не демонстрация “как круто я умею”.

Принципы качественного отчёта

Отделяйте факты от интерпретаций

Факт: “cookie сессии выдан без HttpOnly”

Интерпретация: “это может повысить риск кражи cookie при наличии XSS”

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

Пишите так, чтобы вас поняли разные роли

Как минимум есть две аудитории:

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

не техническая (владелец продукта, менеджер): нужен риск, приоритет и влияние

Хороший отчёт содержит и то, и другое, но в разных блоках.

Минимизируйте вред и чувствительные данные

Даже в лаборатории привыкайте к профессиональной гигиене:

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

маскируйте секреты: AKIA...XXXX

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

Рекомендация: сверяйтесь с подходом OWASP к оформлению результатов тестирования: Руководство OWASP Web Security Testing Guide.

Структура отчёта: минимальный рабочий шаблон

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

Обложка и контекст

кто проводил проверку

дата и версия стенда/окружения

scope: какие IP/домены/приложения входили

ограничения: что было запрещено (например, DoS, подбор паролей)

Executive summary (краткое резюме)

Коротко и по делу:

сколько найдено проблем и каких уровней важности

какие 1–3 проблемы самые критичные

общий вывод: “исправить в первую очередь X, затем Y”

Метод и источники доказательств

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

чем подтверждались наблюдения: команды (nmap, curl), логи, конфиги (в лаборатории)

Реестр находок (таблица)

Таблица помогает быстро ориентироваться.

| ID | Находка | Компонент | Влияние | Вероятность | Приоритет | Статус | |---|---|---|---|---|---|---| | F-01 | Открыт лишний порт | Сервис/сеть | Среднее | Средняя | Высокий | Новая | | F-02 | Cookie без HttpOnly | Веб | Среднее | Высокая | Высокий | Новая |

Влияние — что случится при эксплуатации. Вероятность — насколько реально это провернуть в вашем контексте. Приоритет — итог: что чинить раньше.

Карточка каждой находки

Единый формат делает отчёт читаемым. Для каждой находки используйте блоки:

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

Затронутый компонент (IP/порт/URL/сервис)

Условия и шаги воспроизведения (только в рамках разрешений)

Доказательства (команда и ключевой фрагмент результата)

Риск (понятным языком)

Рекомендации (коротко и применимо)

Примечания по проверке исправления (re-test)

Пример: как оформлять доказательства безопасно

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

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

Факт: сервер выдаёт cookie без HttpOnly.

Доказательство:

В отчёт вы переносите не весь вывод, а минимально нужную строку, например:

Риск: если в приложении появится XSS, cookie сессии проще украсть из JavaScript.

Рекомендации: включить HttpOnly для cookie сессии; при необходимости добавить Secure (для HTTPS) и корректный SameSite.

Re-test: повторить curl -I и убедиться, что Set-Cookie содержит нужные атрибуты.

Справочник по атрибутам cookie: MDN: Set-Cookie.

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

В индустрии часто используют CVSS, но на старте достаточно прозрачной логики, основанной на двух вопросах:

Влияние: что будет, если это случится? (утечка данных, захват аккаунтов, простой сервиса)

Вероятность: насколько легко это сделать в реальности? (доступность из сети, отсутствие защит, простота повторения)

Практическая шкала для курса:

Высокий приоритет: удалённый доступ/утечка чувствительных данных/компрометация аккаунтов и это сравнительно легко

Средний: влияние ограничено или нужна цепочка условий

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

Совет: всегда явно пишите, почему приоритет такой — одной-двумя фразами.

Устранение уязвимостей: стратегия “сначала уменьшаем поверхность атаки”

Большая часть базовых проблем из прошлой статьи лечится не “магией”, а дисциплиной конфигурации.

Уменьшение поверхности атаки

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

закрыть порты на firewall

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

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

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

Обновления и управление версиями

Если обнаружена устаревшая версия сервиса:

обновите пакет/контейнер/образ

зафиксируйте версию после обновления

убедитесь, что обновление не сломало функциональность

Важно: “обновить” — не равно “стало безопасно”, но это часто устраняет целый класс известных проблем.

Исправления веб-настроек

Типовые задачи:

включить HTTPS и редирект с HTTP (если это уместно для окружения)

настроить заголовки и cookie-атрибуты

отключить debug-режим и подробные ошибки

Справочник по статусам HTTP для чтения отчётов и ответов: MDN: HTTP response status codes.

Права доступа и секреты

Если находка связана с файлами и правами (в лаборатории):

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

ограничьте права на файлы конфигурации

исключите секреты из логов

Главная цель: секреты не должны быть доступны “всем” и не должны утекать через веб.

Проверка исправлений: re-test без самообмана

Исправление считается завершённым только после повторной проверки.

Минимальные правила re-test

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

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

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

Таблица “до/после” в отчёте

| Проверка | До | После | |---|---|---| | curl -I /login (cookie) | нет HttpOnly | HttpOnly присутствует | | nmap порт 3306 | open | closed или filtered |

Если проблема не ушла, это тоже результат: значит, либо исправление неполное, либо вы проверяете не тот компонент.

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

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

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

отделяйте обязательное от желательного

описывайте влияние на эксплуатацию: что может сломаться после закрытия порта или включения HTTPS

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

Рост навыков: как превращать каждую находку в прогресс

Ваше обучение ускорится, если вы будете превращать результаты в процесс.

Ведение базы знаний

Создайте у себя простой репозиторий заметок (локально) со структурой:

checklists/ (чеклисты проверок)

findings/ (примеры находок: факт → риск → рекомендация)

labs/ (как развёрнут стенд, какие версии, какие настройки)

Чеклист после каждой лабораторной сессии

какие факты я собрал (порты, сервисы, заголовки)

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

что я бы сделал иначе, чтобы было меньше шума и больше пользы

какие команды стоит добавить в личный “шпаргалочник”

Мини-метрика качества (без сложной математики)

Оцените свою работу по трём критериям:

воспроизводимость: другой человек сможет повторить шаги?

понятность: риск описан человеческим языком?

проверяемость исправления: есть ли чёткий re-test?

Если хотя бы один пункт “нет”, улучшайте именно его.

Частые ошибки новичков в отчётах и исправлениях

писать “страшно, критично”, не объясняя влияние и сценарий

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

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

не фиксировать scope и ограничения

не делать re-test и считать задачу закрытой

Итог

Полезный этичный хакинг — это цикл:

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

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

помогаете выбрать приоритет

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

превращаете опыт в чеклисты и рост навыков

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