Дані від постачальників подій (на схемі позначені абревіатурою ПС ), перехоплюючих HTTP-запити до веб-додатку та обігу веб-додатки до об'єктів оточення, потрапляють в підсистему попередньої обробки траси, де аналізуються і перетворюються до внутрішнього уявлення записи траси. Далі перетворена запис траси передається в підсистему виявлення аномалій, де відбувається аналіз і виявлення аномалій щодо профілів нормальної поведінки. Профілі нормальної поведінки завантажуються підсистемою виявлення з бази даних профілів нормальної поведінки (на схемі позначена абревіатурою БД ) в початковий момент часу і формують дерево профілів нормальної поведінки.
Малюнок 6.3.2 Схема функціонування модуля в режимі виявлення аномалій
6.4 Опис підсистем модуля
У даному підрозділі приводяться описи основних підсистем модуля виявлення вразливостей.
6.4.1 Консоль управління
Завданнями консолі управління є настройка, запуск і координація інших підсистем модуля.
При запуску консоль управління зчитує файл з настройками модуля. Далі налаштування передаються запускаються підсистемам.
6.4.2 Підсистема попередньої обробки траси
Завданням підсистеми попередньої обробки траси (далі - предобработчік траси ) є аналіз і перетворення записів траси до внутрішнього уявлення для подальшого аналізу підсистемами побудови профілю нормальної поведінки і виявлення аномалій.
Основними завданнями предобработчіка траси є:
аналіз значень POST-параметрів і їх заміна на типи;
підсумовування значень для однакових операцій у записі траси.
Як було сказано в ПІДРОЗДІЛИ 4.5, при порівнянні GET-параметрів зіставляються значення параметрів, а при порівнянні POST-параметрів - їх типи. Визначення типів POST-параметрів є безпосереднім завданням предобработчіка траси.
В якості типів використовуються символьні класи регулярних виразів стандарту POSIX [24]. Для визначення типу використовується відповідне регулярний вираз.
Як було відзначено в ПІДРОЗДІЛИ 6.2.2, в ряді випадків потрібно обробляти окремі GET-параметри як POST-параметри, і навпаки. Тобто - замінювати значення окремих GET-параметрів на їх типи і не замінювати значення окремих POST-параметрів на їх типи. Список таких винятків задається в окремому файлі, що представляє собою сукупність записів, що описують винятку.
Запис має наступну структуру:
запис відкривається ключовим словом WAProfile_ExclusionBegin ;
набір полів, що описують виняток;
запис закривається ключовим словом WAProfile_ExclusionEnd .
Запис складається з наступних полів:
WAProfile_ExclusionURL - поле містить URL-адреса веб-додатки, якому передається параметр;
WAProfile_ExclusionMethod - поле містить метод, яким передається параметр. Можливі значення:
WAProfile_ExclusionParam - ім'я переданого параметра;
WAProfile_ExclusionType - уточнення способу, яким повинен оброблятися даний параметр. Можливі значення:
use_value - параметр зберігає значення, при порівнянні наборів HTTP-параметрів відбувається порівняння значень даних параметрів;
use_type - замість значення параметра визначається і використовується його тип, при порівнянні наборів HTTP-параметрів відбувається порівняння типів даних параметрів;
use_custom_regexp - значення параметра перевіряється спеціальним регулярним виразом у форматі PCRE [24], яке вказується в окремому полі.
WAProfile_ExclusionRegexp - поле містить регулярний вираз у форматі PCRE [24]. Поле є необов'язковим. Регулярний вираз, задане в поле, використовується для перевірки значення параметра, якщо в якості значення поля WAProfile_ExclusionType задано use_custom_regexp .
Приклади записів: _ExclusionBegin_ExclusionURL: # center gt; 6.4.3 Підсистема побудови профілю нормальної поведінки
Завданням підсистеми побудови профілю нормальної поведінки є аналіз траси, отриманої в режимі навчання, і побудова на її основі профілів нормальної поведінки для веб-додатків, дані про запити до яких містяться у записах траси.
Підсистема активізується при запуску модуля в режимі побудови профі...
