itlxrd/dipl-edr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
dipl-edr/docs/diploma_practical_section.md
T
kilyabin 1a2a0dfbb7 feat: update docs to actual state
2026-05-29 17:36:21 +04:00

34 KiB
Raw Permalink Blame History

Практическая часть дипломной работы

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

3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

3.1 Общее описание разработанной системы

В рамках дипломной работы разработана система класса EDR (Endpoint Detection and Response) — системы обнаружения и реагирования на угрозы на конечных узлах сети. Система предназначена для мониторинга поведения процессов Linux-сервера в реальном времени, выявления аномальной активности методами машинного обучения и визуализации результатов в виде веб-панели управления (dashboard).

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

  • сбор поведенческих метрик всех запущенных процессов каждые 5 секунд;
  • мониторинг файловой системы в критических директориях /etc, /tmp, /var/log;
  • автоматическое обучение ансамбля из трёх ML-моделей (Isolation Forest, LOF, One-Class SVM) на нормальном поведении системы;
  • классификация процессов как аномальных/нормальных в режиме реального времени;
  • хранение всех событий в реляционной базе данных SQLite;
  • передача оповещений об аномалиях по протоколу WebSocket;
  • веб-интерфейс SOC-класса с отображением статистики, процессов, алертов и событий ФС.

3.2 Архитектура системы

Система построена по трёхзвенной клиент-серверной архитектуре и включает три основных компонента:

┌─────────────────────────────────────────────────────────────┐
│  Linux-хост (объект мониторинга)                            │
│                                                             │
│  ┌────────────┐  HTTP POST    ┌────────────┐               │
│  │  Агент     │ ────────────▶ │  Бэкенд    │               │
│  │  (Python)  │               │  (FastAPI) │               │
│  │            │               │            │               │
│  │ • psutil   │               │ • REST API │               │
│  │ • watchdog │               │ • SQLite   │               │
│  │ • ML-модель│               │ • WebSocket│               │
│  └────────────┘               └─────┬──────┘               │
│                                     │ WS                    │
│                               ┌─────▼──────┐               │
│                               │  Фронтенд  │               │
│                               │  (React)   │               │
│                               │  :3000     │               │
│                               └────────────┘               │
└─────────────────────────────────────────────────────────────┘

Компонент 1 — Агент мониторинга (agent/). Написан на языке Python 3.11. Запускается непосредственно на контролируемом хосте. Каждые 5 секунд собирает метрики всех запущенных процессов (PID, имя, загрузка CPU, объём RSS-памяти, количество открытых файлов, количество TCP-соединений), запускает ML-классификацию, затем отправляет результаты в бэкенд через HTTP POST. Параллельно запущен наблюдатель файловой системы (watchdog), отслеживающий создание, изменение и удаление файлов в указанных директориях.

Компонент 2 — Серверная часть (backend/). Реализована на фреймворке FastAPI (Python). Принимает батчи метрик, сохраняет их в SQLite через асинхронный драйвер aiosqlite. При обнаружении аномального процесса создаёт запись в таблице алертов и транслирует JSON-сообщение всем подключённым WebSocket-клиентам (панелям мониторинга).

Компонент 3 — Веб-панель управления (frontend/). Single-Page Application на стеке React 18 + TypeScript + Vite. Использует библиотеку shadcn/ui (Radix UI + Tailwind CSS) для интерфейсных компонентов, Recharts для графиков реального времени, TanStack Query для периодического опроса REST API каждые 5 секунд. WebSocket-соединение обеспечивает мгновенную доставку уведомлений об аномалиях.

3.3 Модуль машинного обучения

3.3.1 Проблема единственного классификатора и обоснование ансамблевого подхода

При обнаружении аномалий в поведении процессов каждый алгоритм машинного обучения обладает специфическими слабыми сторонами. Единственная модель даёт повышенное число ложных срабатываний (false positives) или пропускает определённые типы аномалий (false negatives) в зависимости от характера атаки и распределения данных.

В данной работе реализован ансамблевый детектор (voting ensemble), объединяющий три алгоритма обнаружения аномалий без учителя. Аномалией считается процесс, признанный подозрительным как минимум двумя из трёх моделей (правило большинства, majority voting). Такой подход снижает вероятность ложных срабатываний по сравнению с одиночным классификатором: случайный «выброс» от одного алгоритма не приводит к генерации алерта, если два других модели оценивают процесс как нормальный.

3.3.2 Алгоритмы ансамбля

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

Алгоритм Принцип Сильная сторона
Isolation Forest (Liu et al., 2008) Случайные деревья изоляции Глобальные аномалии, O(n) скорость
Local Outlier Factor (Breunig et al., 2000) Локальная плотность соседей Локальные кластерные аномалии
One-Class SVM (Schölkopf et al., 1999) Гиперплоскость максимального зазора Нелинейные границы нормальности

Isolation Forest строит ансамбль из 100 случайных деревьев. Нормальные точки требуют большего числа разбиений для изоляции, аномальные — меньшего. Итоговый балл — нормированная средняя длина пути изоляции. Алгоритм эффективен для глобальных выбросов и работает с линейной сложностью O(n).

Local Outlier Factor (LOF) оценивает каждую точку относительно плотности её локального окружения из k=20 ближайших соседей. Если плотность точки значительно ниже плотности её соседей, точка является выбросом. LOF выявляет аномалии в локальных кластерах, которые IsolationForest может пропустить в многомодальных распределениях. Используется режим novelty=True для предсказания на новых данных.

One-Class SVM обучается провести гиперплоскость максимального зазора в пространстве признаков (ядро RBF), отделяющую нормальные данные от пространства аномалий. Нелинейная природа ядра позволяет захватывать сложные границы нормальности, недоступные линейным методам. Параметр nu=0.01 задаёт верхнюю оценку доли аномалий.

3.3.3 Схема голосования

Процесс → вектор признаков → RobustScaler (нормировка)
                                    │
               ┌────────────────────┼────────────────────┐
               ▼                    ▼                    ▼
        IsolationForest        LOF (novelty)        One-Class SVM
        (+1 норма/-1 ан.)   (+1 норма/-1 ан.)   (+1 норма/-1 ан.)
               │                    │                    │
               └────────────────────┴────────────────────┘
                                    │
                              сумма голосов
                            ≥ 2 «–1»  →  Аномалия
                            ≤ 1 «–1»  →  Норма

Формально, для вектора признаков x каждая модель m_i возвращает v_i \in \{-1, +1\}. Решение:

\text{is\_anomaly}(\mathbf{x}) = \left[\sum_{i=1}^{3} v_i \leq -1\right]

то есть аномалия фиксируется, если сумма голосов равна -1 (голосуют 2 из 3) или -3 (единогласно).

3.3.4 Вектор признаков

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

Признак Тип Описание
cpu_percent float Загрузка CPU процессом, %
memory_mb float Объём RSS-памяти, МБ
open_files int Количество открытых файловых дескрипторов
connections int Количество открытых TCP-соединений

Выбор признаков обоснован классическими индикаторами компрометации (IoC):

  • аномально высокое потребление CPU характерно для криптомайнеров и ransomware;
  • избыточное число соединений указывает на C2-коммуникации или сканирование сети;
  • большое число открытых файлов — признак шифровальщиков;
  • чрезмерное потребление памяти — характерно для эксплойтов heap overflow.

3.3.5 Предобработка: RobustScaler

One-Class SVM и LOF чувствительны к масштабу признаков, поэтому перед обучением применяется RobustScaler из scikit-learn. В отличие от StandardScaler, RobustScaler использует медиану и межквартильный размах (IQR) вместо среднего и дисперсии, что делает нормировку устойчивой к экстремальным выбросам в обучающих данных:

x' = \frac{x - \text{median}(X)}{\text{IQR}(X)}

Параметры масштабирования (медиана и IQR по каждому признаку) сохраняются вместе с моделями и применяются к каждому новому вектору при инференсе.

3.3.6 Обучающие данные

Система поддерживает два режима обучения:

Режим 1 (основной). Если в директории data/ находится файл UNSW_NB15_training-set.csv, все три модели обучаются на реальных данных набора UNSW-NB15. Датасет UNSW-NB15 (University of New South Wales, 2015) содержит 257 000 записей сетевого трафика, включая нормальную активность и 9 типов атак (Fuzzers, Analysis, Backdoors, DoS, Exploits, Generic, Reconnaissance, Shellcode, Worms). Из набора извлекаются первые четыре числовые колонки как приближение к вектору признаков.

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

  • CPU: 75% экспоненциальное распределение ≈ 0% (фоновые процессы), 20% Uniform[0.5, 15%] (лёгкие задачи), 5% Uniform[15, 60%] (тяжёлые процессы);
  • RAM: 50% — 0.5–50 МБ (мелкие демоны), 30% — 50–300 МБ, 12% — 300–800 МБ, 8% — 800–2000 МБ (браузеры, IDE);
  • Файлы: 70% — 0–20 дескрипторов, 30% — 20–80;
  • TCP-соединения: 70% — 0–2, 30% — 2–20.

3.3.7 Параметры ансамбля

# IsolationForest
IsolationForest(
    n_estimators=100,   # число деревьев изоляции
    contamination=0.01, # ожидаемая доля аномалий 1%
    random_state=42,    # воспроизводимость
    n_jobs=-1,          # параллельное обучение
)

# Local Outlier Factor
LocalOutlierFactor(
    n_neighbors=20,     # размер локального окружения
    contamination=0.01,
    novelty=True,       # инференс на новых данных
    n_jobs=-1,
)

# One-Class SVM
OneClassSVM(
    kernel="rbf",       # гауссово ядро
    nu=0.01,            # верхняя оценка доли аномалий
    gamma="scale",      # автоматически от дисперсии признаков
)

Параметр contamination=0.01 (1%) выбран для минимизации ложных срабатываний на рабочей станции с десятками доверенных фоновых процессов.

3.3.8 Список доверенных процессов

Для известных «тяжёлых» десктопных приложений (браузеры, Electron-приложения, IDE, медиаплееры) ML-классификация пропускается — они заносятся в TRUSTED_PROCESSES. Это предотвращает генерацию ложных алертов для firefox, VS Code, Telegram и других приложений, нормально потребляющих сотни мегабайт RAM. Пороговые алерты бэкенда (CPU > 80%, RAM > 3 ГБ) для доверенных процессов по-прежнему работают.

3.3.9 Сохранение ансамбля

После обучения все три модели и параметры RobustScaler сериализуются в единый файл data/model.pkl через joblib:

joblib.dump({
    "iforest": self.iforest,
    "lof":     self.lof,
    "ocsvm":   self.ocsvm,
    "scaler":  scaler,
}, MODEL_PATH)

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

3.4 Агент мониторинга

3.4.1 Сбор метрик процессов

Сбор осуществляется через библиотеку psutil — кроссплатформенную обёртку над системными вызовами Linux (/proc filesystem). Для каждого процесса в системе итерируется объект psutil.Process и извлекаются следующие атрибуты:

psutil.process_iter([
    'pid',           # идентификатор процесса
    'name',          # имя исполняемого файла
    'cpu_percent',   # загрузка CPU, %
    'memory_info',   # RSS/VMS в байтах
    'open_files',    # список открытых файловых дескрипторов
    'connections',   # список TCP/UDP соединений
])

Особенности реализации:

  • первый вызов cpu_percent() всегда возвращает 0.0 (psutil требует временной дельты), поэтому при старте агента выполняется прогревочный вызов с паузой 1 сек;
  • процессы, к которым нет доступа (PermissionError), пропускаются без исключения;
  • зомби-процессы обрабатываются отдельно.

3.4.2 Мониторинг файловой системы

Для отслеживания изменений в файловой системе используется библиотека watchdog, основанная на Linux inotify API. Наблюдатели запускаются рекурсивно для трёх директорий:

  • /etc — системные конфигурационные файлы (изменение может свидетельствовать о persistence-атаке);
  • /tmp — временные файлы (типичное место для дропа malware-полезной нагрузки);
  • /var/log — системные журналы (попытки очистки следов атаки).

Каждое событие (create/modify/delete) помещается в потокобезопасный буфер с ограничением в 500 записей. При отправке батча метрик буфер опустошается.

3.4.3 Протокол взаимодействия с бэкендом

Каждые 5 секунд агент формирует и отправляет JSON-батч:

{
  "timestamp": "2025-05-28T14:30:00.000Z",
  "processes": [
    {
      "pid": 1234,
      "name": "nginx",
      "cpu_percent": 2.1,
      "memory_mb": 45.3,
      "open_files": 22,
      "connections": 8,
      "is_anomaly": false
    }
  ],
  "system": {
    "cpu_percent": 12.5,
    "ram_percent": 34.2,
    "network_connections": 47
  },
  "file_events": [
    {
      "path": "/tmp/suspicious.sh",
      "event_type": "create",
      "timestamp": "2025-05-28T14:29:58.000Z"
    }
  ]
}

При недоступности бэкенда агент продолжает работу, логируя предупреждение, без аварийного завершения.

3.5 Серверная часть (бэкенд)

3.5.1 Технологический стек

Бэкенд реализован на фреймворке FastAPI — современном асинхронном фреймворке для построения API на Python, основанном на стандарте ASGI. Ключевые преимущества:

  • автоматическая генерация OpenAPI-документации (доступна по адресу /docs);
  • встроенная валидация данных через Pydantic v2;
  • нативная поддержка async/await;
  • встроенная поддержка WebSocket.

База данных — SQLite через асинхронный драйвер aiosqlite. Выбор SQLite обусловлен простотой развёртывания (файловая база, не требует отдельного сервера) и достаточной производительностью для хранения метрик одного хоста.

3.5.2 Схема базы данных

-- Метрики процессов
CREATE TABLE metrics (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp   TEXT    NOT NULL,
    pid         INTEGER,
    name        TEXT,
    cpu_percent REAL,
    memory_mb   REAL,
    open_files  INTEGER,
    connections INTEGER,
    is_anomaly  INTEGER DEFAULT 0   -- 0=normal, 1=anomaly
);

-- Алерты безопасности
CREATE TABLE alerts (
    id           INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp    TEXT NOT NULL,
    pid          INTEGER,
    process_name TEXT,
    reason       TEXT,              -- человекочитаемое описание аномалии
    severity     TEXT               -- low | medium | high
);

-- События файловой системы
CREATE TABLE file_events (
    id         INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp  TEXT NOT NULL,
    path       TEXT,
    event_type TEXT                 -- create | modify | delete
);

3.5.3 REST API

Метод Эндпоинт Описание
GET /api/stats Агрегированная статистика для дашборда
GET /api/metrics?limit=200 Последние метрики процессов
GET /api/alerts?limit=50 Последние алерты безопасности
GET /api/file-events?limit=100 Последние события ФС
POST /api/metrics Приём батча от агента

3.5.4 WebSocket

Эндпоинт /ws реализует паттерн publish-subscribe. При поступлении батча с аномальными процессами бэкенд транслирует каждому подключённому клиенту (dashboard) JSON-сообщение:

{
  "type": "alert",
  "pid": 4567,
  "process_name": "python3",
  "reason": "Anomalous behaviour: CPU 95.2%, MEM 3200 MB",
  "severity": "high",
  "timestamp": "2025-05-28T14:30:05.000Z"
}

Уровень серьёзности (severity) определяется эвристически:

  • high: CPU > 80% или RAM > 2 ГБ;
  • medium: CPU > 50% или RAM > 1 ГБ;
  • low: статистический выброс без пороговых нарушений.

3.6 Веб-интерфейс

3.6.1 Технологический стек

Веб-интерфейс разработан в виде Single-Page Application (SPA) на следующем стеке:

Технология Версия Назначение
React 18.3 UI-фреймворк с декларативным рендерингом
TypeScript 5.4 Статическая типизация JavaScript
Vite 5.3 Сборщик с мгновенным HMR
Tailwind CSS 3.4 Utility-first CSS-фреймворк
Radix UI 1.x Headless UI-примитивы (доступность)
Recharts 2.12 Графики на основе D3.js
TanStack Query 5.x Серверный state-менеджмент с кешированием

Дизайн выполнен в стиле SOC-dashboard (Security Operations Center): тёмный фон (#0a0a0f), акцентные цвета cyan (#00ff9d) и blue (#00d4ff), монospace-шрифт JetBrains Mono, декоративные сетка и эффект CRT-строк.

3.6.2 Структура интерфейса

Интерфейс разделён на четыре функциональных раздела, доступных через вкладки:

Вкладка Overview (Обзор):

  • Пять карточек-счётчиков: всего процессов, аномалий за сутки, алертов за сутки, средняя загрузка CPU, средний объём RAM.
  • График реального времени (Recharts LineChart): две линии — загрузка CPU% и RAM% системы за последние 60 точек измерений. Обновляется каждые 5 секунд через TanStack Query polling.

Вкладка Processes (Процессы):

  • Таблица всех текущих процессов с колонками: PID, Имя, CPU%, RAM MB, TCP-соединения, Открытые файлы, Статус.
  • Отображается последний снимок (snapshot) для каждого уникального PID.
  • Сортировка по убыванию CPU%.
  • Аномальные строки выделены красной левой рамкой и красным фоном.
  • Статус-бейджи: зелёный «Normal» / красный «Anomaly».

Вкладка Alerts (Алерты):

  • Таблица алертов: время, PID, имя процесса, описание аномалии, уровень серьёзности (цветные бейджи: синий/жёлтый/красный).
  • Индикатор состояния WebSocket-соединения (зелёная/красная точка).
  • Новые алерты появляются вверху таблицы.

Вкладка File Events (События ФС):

  • Таблица событий файловой системы: время, путь, тип события (create/modify/delete) с цветными бейджами.

Toast-уведомления: При получении алерта по WebSocket в правом нижнем углу появляется всплывающее уведомление с именем процесса, описанием аномалии и цветовой индикацией серьёзности. Исчезает через 5 секунд или по нажатию.

3.6.3 Архитектура обмена данными

TanStack Query                 WebSocket
(polling 5s)                   (push)
    │                              │
    ▼                              ▼
api.metrics()              WS.onmessage()
api.alerts()               → _emitToast()
api.stats()                → queryClient.invalidate()
api.fileEvents()
    │
    ▼
React state → re-render

TanStack Query кеширует ответы API и автоматически перезапрашивает данные каждые 5 секунд (staleTime: 4000ms). При поступлении WebSocket-алерта принудительно инвалидируется кеш /api/alerts и /api/stats, что вызывает немедленный повторный запрос без ожидания следующего интервала.

3.7 Результаты тестирования

3.7.1 Тест: CPU-аномалия

Условие: на тестовом хосте (Ubuntu 22.04, 4 ядра, 8 ГБ RAM) запущен стресс-тест:

stress-ng --cpu 4 --timeout 30s

Результат:

  • через 5–10 секунд процесс stress-ng-cpu появился в таблице Processes с отметкой «Anomaly»;
  • в таблице Alerts появилась запись severity=high с описанием «CPU 98.4%»;
  • в правом нижнем углу отобразилось toast-уведомление;
  • после завершения стресс-теста процесс вернул статус Normal.

Время реакции: 5–10 секунд (один цикл сбора метрик).

3.7.2 Тест: Memory-аномалия

Условие: Python-скрипт выделяет 3 ГБ памяти:

x = bytearray(3 * 1024 * 1024 * 1024)
import time; time.sleep(60)

Результат: алерт severity=high с описанием «MEM 3072 MB», время реакции — 5 с.

3.7.3 Тест: Filesystem-событие

Условие: создание файла в /tmp:

echo "malware" > /tmp/evil.sh
chmod +x /tmp/evil.sh

Результат: событие create с путём /tmp/evil.sh появилось во вкладке File Events в течение 1 секунды (inotify работает в реальном времени).

3.8 Выводы по практической части

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

  1. Разработана трёхзвенная система EDR, включающая агент мониторинга, серверную часть и веб-интерфейс.

  2. Реализован ансамблевый модуль машинного обучения, объединяющий три алгоритма обнаружения аномалий без учителя: Isolation Forest, Local Outlier Factor и One-Class SVM. Применение правила большинства голосов (2 из 3) снижает количество ложных срабатываний по сравнению с единственным классификатором и повышает устойчивость к различным типам аномалий.

  3. Обеспечена интеграция с датасетом UNSW-NB15 для обучения на реальных данных сетевых атак; реализован резервный режим на синтетических данных с реалистичным распределением поведения Linux-процессов.

  4. Реализован механизм оповещений в режиме реального времени через WebSocket, обеспечивающий время реакции не более одного цикла сбора метрик (5 секунд).

  5. Разработан веб-интерфейс профессионального уровня с поддержкой динамических графиков, цветовой индикацией угроз и push-уведомлениями.

  6. Система успешно выявляет следующие типы аномалий: аномально высокую нагрузку на CPU (криптомайнеры, brute-force), чрезмерное потребление памяти (эксплойты, утечки), избыточное число сетевых соединений (C2-коммуникации, DDoS), подозрительную активность в файловой системе.

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

Компонент Технология Версия Лицензия
Агент Python 3.11 PSF
Агент psutil ≥5.9 BSD-3
Агент watchdog ≥3.0 Apache-2.0
Агент scikit-learn (IF + LOF + OC-SVM) ≥1.3 BSD-3
Агент joblib ≥1.3 BSD-3
Бэкенд FastAPI ≥0.111 MIT
Бэкенд aiosqlite ≥0.20 MIT
Бэкенд uvicorn ≥0.29 BSD-3
Фронтенд React 18.3 MIT
Фронтенд TypeScript 5.4 Apache-2.0
Фронтенд Vite 5.3 MIT
Фронтенд Tailwind CSS 3.4 MIT
Фронтенд Recharts 2.12 MIT
Фронтенд TanStack Query 5.x MIT
Фронтенд Radix UI 1.x MIT
Контейнеризация Docker Compose 3.9 Apache-2.0

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

Reference in New Issue View Git Blame Copy Permalink