2.2. Препроцесори

Препроцесори були введені у версії Snort1.5, вони дозволяють розширити функціональність Snort, з їх допомогою користувачі і програмісти можуть досить просто додавати модульні плагіни в Snort. Код препроцесора запускається перед тим, як механізм виявлення буде викликаний, але після того, як розшифрується пакет. Пакет може бути модифікований або проаналізований через цей механізм.

Препроцесори завантажуються і настроюються з використанням ключового слова “preprocessor”. Формат директиви препроцесора у файлі правил Snort представляється у вигляді:

preprocessor <ім’я>: <опції>

preprocessor minfrag: 128

Приклад 2.3: Формат директиви препроцесора

2.2.1. Детектор роrtscan

Препроцесор роrtscan розробив Patrick Mulen. Що робить препроцесор роrtscan:

• реєструє запуск і закінчення сканування портів від єдиного початкового ip в стандартному засобі реєстрації;

• якщо файл реєстрації визначений, реєструє ip місця призначення і скануючі порти так само добре, як і вид сканування.

Сканування портів – це спроба tcp з'єднання з більш ніж “p” портами за “t” секунд або udp пакети, відправлені на більш ніж “p” портів за “t” секунд. Порти можуть розповсюджуватися через будь-яке число ip адрес призначення, і можуть всі бути одним портом, якщо розповсюджуються через численні ip. Ця версія проводить одиночний -> одиночний і одиночний -> безліч сканувань портів. Наступний повний випуск проводитиме розподілене сканування портів (численне -> одиночне або численне -> численне). Сканування також визначено як єдиний невидимий пакет сканування, як, наприклад null, fin, syn-fin, xmas, і т.п., це значить що для виявлення сканування в стандартному розповсюдженні Snort потрібен розкоментувати (прибрати знак коментарю) секцію для пакетів невидимого сканування. З модулем сканування портів ці попередження повинні з'являтися тільки один раз за сканування, що переважно, ніж один раз для кожного пакету. Якщо використовувати зовнішню особливість реєстрації то можна буде правити в реєстраційному файлі.

Аргументами до цього модуля є:

• мережа, для контролю мережі/cidr блоку, щоб знаходити сканування;

• число доступних портів, в періоді виявлення;

• тривалість періоду виявлення в секундах, щоб обчислити для чого приймається поріг доступу до порту;

• директорія реєстрацій/ім’я директорії/ім’я файлу для виведення попереджень. Попередження також записуються в стандартний файл попереджень.

Формат

роrtscan: <перевіряєма мережа> <число портів> <період виявлення> <шлях до файлу>

preprocessor роrtscan: 192.168.1.0/24 5 7 C:\Snort\log\portscan.log

Приклад 2.4: Конфігурація препроцесора роrtscan

2.2.2. Portscan ignorehosts

Ще один модуль від Patrick Mulen, який модифікує дії системи виявлення роrtscan. Якщо встановлені сервери, які прагнуть уникнути детектор роrtscan (як, наприклад ntp, nfs, і сервери dns), слід вказати роrtscan ігнорувати tcp syn і udp роrtscans певних хостів. Аргументи до цього модуля - це список ips/cidr блоків, які будуть проігноровані.

Формат

роrtscan-ignorehosts: <список хостів>

preprocessor роrtscan-ignorehosts: 192.168.1.5/32 192.168.3.0/24

Приклад 2.5: Конфігурація модуля роrtscan ignorehosts

2.2.3. Frag2

Frag2, введений в Snort 1.8, і є новим препроцесором ip дефрагментації. Frag2 розроблений для заміни defrag препроцесора. Цей дефрагментатор розроблений для ефективного використовування пам'яті і використовує той же режим управління пам'яттю підпрограми, який знаходяться у використовуванні в інших частинах Snort.

В frag2 можна настроїти використовування пам'яті і опції часу очікування фрагмента. Без зміни аргументів frag2 використовує ліміт пам'яті 4194304 байт (4mb) за умовчанням і період часу очікування 60 секунд. Період часу очікування використовується, щоб визначити довжину часу за яку незібраний фрагмент повинен відкидатися.

В Snort 1.8.7, були додані окремі елементи настройки, щоб допомогти відстежити використовування устаткування для ухилення як, наприклад fragroute.

Формат

preprocessor frag2: [memcap <xxx>], [timeout <xx>] [min_ttl <xx>] \

[detect_state_problems] [ttl_limit <xx>]

timeout <секунди>: кількість часу, щоб утримувати недіючий потік у встановленій таблиці, скинені сеанси, які автоматично підніматимуться знову, якщо спостерігається більше активності, значення за умовчанням - це 30 секунд;

memcap <байти>: число байт, щоб встановити місткість пам'яті, якщо цей ліміт є перевищеним frag2 агресивно підрізатиме недіючі перебирачі, значенням за умовчанням є 4mb;

detect_state_problems: включає попередження для подій, як наприклад перекриваючі фрагменти;

min_ttl: встановлює мінімальний ttl який приймає frag2;

ttl_limit: встановлює значення дельти, яке викличе попередження ухилення. (початковий ttl фрагмента +/- ліміт ttl).

preprocessor frag2: memcap 16777216, timeout 30

Приклад 2.6: Конфігурація препроцесора frag2

2.2.4. Stream4

Модуль stream4 забезпечує перебирання потоку tcp і можливість аналізу. Можливість перебору тривалого потоку дозволяє Snort ігнорувати “stateless” атаки, як, наприклад створення “stick” і “snot”. Stream4 також дає здатність кваліфікованим користувачам відстежити більш ніж 256 одночасних tcp потоки. Stream4 повинен уміти масштабувати, щоб обробити 32,768 одночасних зв'язків tcp в типовій конфігурації.

Stream4 містить два модулі, що конфігуруються: препроцесор stream4 і пов'язаний з ним плагін перебирач stream4. Настроюванні елементи “stream4_reassemble” описані в списку нижче.

Формат stream4

preprocessor stream4: [noinspect], [keepstats], [timeout <seconds>] \

[memcap <bytes>], [detect_scans], [detect_state_problems] \

[disable_evasion_alerts] [ttl_limit <count>]

noinspect: відключити інспекцію;

keepstats: запис підсумкової інформації сеансу в <папку реєстрацій>\session.log;

timeout <секунди>: кількість часу для утримання неактивного потоку у встановленій таблиці, сеанси, які є скиненими автоматично підніматимуться знову, якщо помічено більше активності, значення за умовчанням - це 30 секунд;

memcap <байти>: число байт, щоб встановити місткість пам'яті, якщо цей ліміт є перевищеним stream4 агресивно підрізатиме неактивні сеанси, значенням за умовчанням є 8mb;

detect_scans: включає попередження для подій роrtscan;

detect_state_problems: включає попередження для виявлення подій потоку, як наприклад пакети ухилень rst, дані в syn пакеті, і порядкові номери за межами вікна;

disable_evasion_alerts: вимикає попередження для подій, як наприклад перекриття tcp;

ttl_limit: встановлює значення дельти.

Формат stream4_reassemble

preprocessor stream4_reassemble: [clientonly], [serveronly],\

[noalerts] [роrts <portlist>]

clientonly: забезпечить перебірку тільки для клієнтської сторони зв'язку;

serveronly: забезпечить перебірку тільки для серверної сторони зв'язку;

noalerts: не попереджає про події, які можуть бути атаками “вставки” або “ухилення”;

роrts <список портів>: список портів розділених пропусками для виконання перебірки, “all“ забезпечує перебірку для всіх портів, значення за умовчанням забезпечує перебірку для портів 21, 23, 25, 53, 80, 110, 111, 143 і 513.

Примітка Установка директив stream4 і stream4_reassemble без аргументів в snort.conf файлі примусить їх працювати в їх типовій конфігурації, зображеній в таблиці 2.2 і таблиці 2.3.

Stream4 вводить новий ключ командного рядка: “-z”. При tcp трафіку якщо ключ “-z” є встановленим, Snort попереджатиме тільки про потоки, які були встановлені після трьох рукостискань (handshake) або потоків, де спостерігалася кооперативна двонаправлена активність (тобто де деякий трафік йшов по одному шляху і де що інше ніж “rst” або “fin” повернулося назад до творця). З включеним “-z” ключем Snort повністю ігнорує tcp-основані атаки “stick/snot”.

Таблиця 2.2: Значення за умовчанням stream4

Опція	За умовчанням
час очікування сеансу	30 секунд
місткість пам'яті сеансу	8388608 байт
перевірка	активна
статистика потоку	неактивна
попередження про проблеми	неактивна
роrtscan попередження	неактивна

Таблиця 2.3: Значення stream4_reassemble за умовчанням

Опції	За умовчанням
перебір клієнта	активна
перебір серверу	неактивна
перебір портів	21, 23, 25, 53, 80, 143, 110, 111, 513, 1433
перебір попереджень	активна

2.2.5. Flow

Модуль вистежування flow потрібен для об'єднання механізму зберігаючого стану Snort в єдиному місці. Як і в Snort 2.1.0, виконується тільки детектор роrtscan, але в довгостроковій перспективі багато з підсистем Snort мігрує і стануть flow плагінами. З введенням flow, це ефективно замінить застарілий препроцесор.

Ipv4 потік унікальний, коли ip протокол (ip_proto), початковий ip (sip), початковий порт (sport), ip місця призначення (dip), і порт місця призначення (dport) є тими ж. dport і sport складають “0”, якщо тільки протокол tcp або udp.

Формат

preprocessor flow: [memcap <bytes>], [rows <count>] \

[stats_interval <seconds>] [hash <1|2>]

Таблиця 2.4: Настроюванні елементи flow

memcap	число байт для розподілу
rows	число рядів для потоку хеш-таблиці
stats_interval	проміжок (секунди) для виведення статистики, установка “0” відключить висновок
hash	для використовування хеш методу

Приклад конфігурації

preprocessor flow: stats_interval 0 hash 2

2.2.6 Flow-роrtscan

Цей модуль розроблений для виявлень роrtscans, заснованих на створенні потоку в flow препроцесорі. Метою є виявлення однієї -> багатьох хостів і одного -> багатьох сканувань портів.

Flow препроцесор як роrtscan визначник узятий з досвіду “spp_conversation/portscan2” створеним Jason Larsen і Jed Haile і “ipaudit” розробленим Jon Rifkin.

Ця підсистема стала дещо складніша, ніж передбачалося, але вона відмінно справляється з роботою пом'якшення помилкових позитивів від пристроїв, як, наприклад “squid-проксі”. Нова розробка також більш послідовна у використовуванні пам'яті порівняно з portscan1 або portscan2. Препроцесор також ігнорує одиночні syn повені порту, оскільки вони є роботами, не роrtscan.

Вимоги до пам'яті узяті від архітектури portscan2, хоча в flow-роrtscan перебуває трохи менше інформації для збереження. Нова архітектура діє по принципу кільцевого буфера. Коли сканер не був активним тривалий час, препроцесор тільки проводить відновлення, коли немає більше пам'яті для використовування.

Всі з попередніх методів для виявлення роrtscan в Snort засуджувалися і будуть виключені в найближчому майбутньому.

Flow препроцесор повинен бути доступний спершу для того, щоб flow-роrtscan функціонував належним чином.

Основними компонентами flow-роrtscan є:

1. scoreboards (табло)

Табло містить інформацію щодо шкали часу для єдиної ip адреси. Є два табло: одне для передавачів (вузли, які активні у вашій мережі) і один для сканерів (вузли, які звернулися до заздалегідь невідомого порту у вашій server-watch-net);

2. uniqueness tracker (винятковий мисливець)

Винятковий мисливець використовується, щоб визначити, чи повинно з'єднання вважатися як нове для конкретного ip. Він перевіряє чи зв'язок відповідає новому виду з'єднання для початкового ip за допомогою ігнорування початкового порту. Будь-яка зміна в sip, dip, ip_proto, і dport указує на новий унікальний зв'язок і буде оброблена надалі для таблиці статистики і оцінювання серверу. Це зберігає речі подібно web сторінці з 15 зображеннями від швидкого збільшення очок з великою кількістю доступів до одного і того ж серверу;

3. server statistics tracker (мисливець статистики серверу)

Використовується, щоб прослідити призначені потоки до “server-watchnet” і утримує “hitcounts” (число нападів) на число часу, за який конкретна служба була запитана з унікальними запитами з тих пір, як Snort була запущена. Цей “hitcount” (лічильник нападів) відстежується dip, dport, і protocol.

Якщо сервіс дуже популярний, з'єднання можуть ігноруватися для оцінювання за допомогою порівняння hitcount з “server-ignor-limit”. Якщо існує більше запитів до цього сервісу, ніж “server-ignore-limit”, то flow-роrtscan цілком проігнорує цей сервіс. Так само поступає “server-scanner-limit”, якщо запит до служби приймається, як очки сканера або як очки передавача.

Коли запит до сервісу не знаходиться в server-watchnet, це вважатиметься як очки передавача. Якщо не визначена server-watchnet (стежача мережа) всі попередження будуть попередженнями передавача.

Шлях виконання flow-роrtscan

1. flow-роrtscan одержує нове flow повідомлення від flow модуля.

2. винятковий мисливець визначає, якщо повідомлення - новий тип пошуку за допомогою перегляду змін в sip, dip, ip_proto, і dport. Якщо воно не унікальне, і tcp прапори нормальні, припиняє роботу.

3. якщо цей зв'язок призначається для ip в server-watchnet: протягом часу пізнання серверу збільшується hitcounts для популярності служби.

Інакше він одержує тільки збережений hitcount. Якщо hitcount більше, ніж server-ignore-ліміт, припиняє роботу. Якщо це значення менше ніж server-scanner-ліміт, позначає збільшені очки, як і очки сканера.

4. зв'язок позначений як передавач або як сканер (як в 3 пункті).

Є 4 шкали часу: 2 для ip сканера і 2 для ip передавача. Встановлена шкала часу знаходить “n” подій за “m” секунд. Це типовий вид роrtscan попереджень. Змінна шкала часу регулює “рахунок очка скидання” по кожній події після першої. Це регулює сторону вікна, в якому ми знаходимо події роrtscan за допомогою узяття

end = end + ((end - start) * sliding-scale-factor)

кожного разу, коли шкала має свій власний підсумок очок, який збільшений на новий потік. Кожний набір очок взаємодіє тільки з talker-fixed-score (встановлений рахунок передавача) і talker-sliding-score (ковзаючий рахунок передавача) або з scanner-fixed-score (встановлений рахунок сканера) і scanner-sliding-score (ковзаючий рахунок сканера).

5. оцінює рахунок щодо індивідуальних порогів передавача або сканера.

if (fixed_limit <= fixed_score)

generate_alert()

Формат

preprocessor flow-роrtscan: [scoreboard-memcap-talker <bytes>] \

[scoreboard-rows-talker <count>] \

[scoreboard-rows-scanner <count>] \

[scoreboard-memcap-scanner <bytes>] \

[scanner-fixed-threshold <integer>] \

[scanner-sliding-threshold <integer>] \

[scanner-fixed-window <integer>] \

[scanner-sliding-window <integer>] \

[scanner-sliding-scale-factor <float>] \

[talker-fixed-threshold <integer>] \

[talker-sliding-threshold <integer>] \

[talker-fixed-window <integer>] \

[talker-sliding-window <integer>] \

[talker-sliding-scale-factor <float>] \

[unique-memcap <bytes>] \

[unique-rows <integer>] \

[server-memcap <bytes>] \

[server-rows <integer>] \

[server-watchnet <ip list in snort notation>] \

[src-ignore-net <ip list in snort notation>] \

[dst-ignore-net <ip list in snort notation>] \

[tcp-реnalties <on|off>] \

[server-lerning-time <seconds>] \

[server-ignore-limit <hit count>] \

[server-scanner-limit <hit count>] \

[alert-mode <once|all>] \

[ounput-mode <msg|pktkludge>] \

[base-score <integer>] \

[dumpall <1>]

1. scoreboard-rows-talker (значення за умовчанням: 1000000). Число рядів, що використовуються для таблиці передавача.

2. scoreboard-rows-scanner (значення за умовчанням: 250000). Число рядів, що використовуються для таблиці сканера.

3. unique-rows (значення за умовчанням: 1000000). Скільки потрібно розподілити рядів для унікального мисливця.

4. server-rows (значення за умовчанням: 65536). Скільки потрібно розподілити рядів для вивчення серверу.

Загальна примітка про ряди: рахунок вищого ряду займе більше пам'яті із загального об'єму для специфічної підсистеми. У виводі Snort це представляється як “загублені байти” і також виводиться відсоток знайдених втрат. Рахунок вищого ряду забезпечує велику хеш-таблицю, щоб мінімізувати колізії і має більш швидкий загальний час обробки за рахунок пам'яті. Хеш-таблиці безпосередньо використовують псевдовипадкову тверду “salt”, яка зібрана під час ініціалізації.

5. scoreboard-memcap-talker (значення за умовчанням: 25165824). Число байт для використовування в таблиці передавача.

6. scoreboard-memcap-scanner (значення за умовчанням: 6291456). Число байт для використовування в таблиці сканера.

7. unique-memcap (значення за умовчанням: 25165824). Скільки байт потрібно розподілити для унікального мисливця. Чим більше відводиться пам'яті, тим менше виявиться з'єднань із зайнятим сервером на популярному сервісі.

8. server-memcap (значення за умовчанням: 2097152). Скільки байт потрібно розподілити для вивчення серверу.

9. scanner-fixed-threshold (значення за умовчанням: 15). Число очок, які сканер повинен накопичити в діапазоні scanner-fixed-window (встановлене вікно сканера). “0” використовується для відключення цього виду попередження.

10. talker-fixed-threshold (значення за умовчанням: 15). Число очок, які повинен накопичити сканер в діапазоні часу talker-fixed-window (встановлене вікно передавача). “0” використовується для відключення цього виду попередження.

11. scanner-sliding-threshold (значення за умовчанням: 40). Число очок, які повинен накопичити сканер в scanner-sliding-window (ковзаюче вікно сканера) діапазоні часу. Для відключення цього виду попередження встановлюється “0”.

12. talker-sliding-threshold (значення за умовчанням: 30). Число очок, які повинен накопичити сканер в діапазоні talker-sliding-window часу. Щоб відключити цей вид попередження встановлюється “0”.

13. scanner-fixed-window (значення за умовчанням: 15). Скільки секунд слід чекати перед скиданням встановленого рахунку сканера.

14. talker-fixed-window (значення за умовчанням: 30). Скільки секунд потрібно чекати перед скиданням встановленого рахунку передавача.

15. scanner-sliding-window (значення за умовчанням: 20). Скільки секунд потрібно чекати перед скиданням відмітки сканера.

16. talker-sliding-window (значення за умовчанням: 30). Скільки секунд потрібно чекати перед скиданням відмітки передавача ковзання.

17. scanner-sliding-scale-factor (значення за умовчанням: 0.5). На скільки потрібно збільшувати ковзаюче вікно кожного разу, коли помічений новий ковзаючий вхід сканера. Його поточний розмір + (<показник шкали> * поточний розмір).

18. talker-sliding-scale-factor (значення за умовчанням: 0.5). На скільки потрібно збільшувати ковзаюче вікно кожного разу, коли помічений новий вхід, ковзаючий вхід передавача. Його поточний розмір + (<показник шкали > * поточний розмір).

19. src-ignore-net. Список ip в яких вказані ip джерела, які будуть проігноровані.

20. dst-ignore-net. Список ip де вказані ip місць призначення, які будуть проігноровані.

21. tcp-реnalties (значення за умовчанням: on). Якщо включено, коли входить новий tcp потік в набір виявлення роrtscan, перевіряє tcp прапори для нестандартних ініціаторів сеансу і призначає штрафні очки на дивні комбінації, як наприклад syn+fin

22. flag mapping

23. server-watchnet. Список машин (ip список), служби яких потрібно вивчити. Зайняті сервери повинні розміщуватися тут, щоб допомогти роrtscan-детектору дізнатися, які служби запитані в мережі.

Таблиця 2.5: Розподіл прапорів

syn або syn+ecn bits	base_score (за умовчанням 1 очко)
syn+fin+th_ack і що не будь інше	5 очок
syn+fin і що не будь інше окрім аск	3 очки
що не будь інше	2 очки

24. server-learning time (значення за умовчанням: 28800)

Скільки секунд потрібно утримувати збільшені hitcounts (рахунок нападів) послуг на ips в server-watchnet. Ця опція не виконує підтвердження, що сервіс з’єднаний коректно. Це можливо коли взнаєш що хтось переповнив таблицю з унікальними з'єднаннями вимушуючи щось стати сервісом без згоди. Звичайно передбачається, що вивчення відбувається в час, коли трафік “типовий”. Майбутні версії Snort дозволятимуть зберігати і змінюватимуть цей стан. Якщо це застереження типове у вашому оточенні, не встановлюйте watchnet-сервери і довіряйте тільки очкам передавача.

25. server-ignore-limit (значення за умовчанням: 500)

Скільки запитів порт на ip в server-watchnet повинен побачити перед тим, як вони будуть проігноровані в цілях сканувань портів.

26. server-scanner-limit (значення за умовчанням: 500)

Скільки запитів порт на ip в server-watchnet повинен побачити перед тим, як вони будуть оброблені передавачем, а не сканером. Це мінімальне число запитів, яке повинне бути поміченим протягом server-learning-time (час вивчення серверу) для обробки потоку з'єднання з передавачем, а не з'єднання з сканером.

27. alert-mode (значення за умовчанням: once)

Таблиця 2.6: Режими попереджень

once	попереджає коли вперше відбувається сканування входу. Ефективно зменшує безладдя, оскільки попередження про сканування в першому випадку указує попередженню подивитися на інші види подій
all	попереджає кожного разу, коли рахунок перевищує поріг

28. output-mode (значення за умовчанням: msg)

Таблиця 2.7: Режими виводу

msg	змінне текстове повідомлення, що містить рахунок
pktkludge	генерує фальшиві пакети і використовує вихідну реєструючу систему

29. скидає все, коли виходимо з Snort, скидає весь вміст таблиці серверу, таблицю виняткового мисливця, і дані табло. Це корисно, якщо був помічений дефект лежачий в основі алгоритмів, що використовуються, або якщо потрібно подивитися, що взнала Snort. “1” використовується для включення.

30. base-score (значення за умовчанням: 1) Рахунком за умовчанням є рахунок нового з'єднання. Це корисно тільки для відладки.

Приклад конфігурації

preprocessor flow-роrtscan: server-watchnet [10.0.0.0/8] \

unique-memcap 5000000 \

unique-rows 50000 \

tcp-реnalties on \

server-scanner-limit 50 \

alert-mode all \

output-mode msg \

server-learning-time 3600

2.2.7. Telnet decode

Препроцесор “telnet_decode” дозволяє Snort нормалізувати символи протоколу управління telnet від даних сеансу. В Snort 1.9.0 і вище, він приймає список портів для запуску як аргументи. Також в 1.9.0, препроцесор нормалізує безпосередньо в окремому буфері даних з пакету таким чином, що необроблені дані можуть реєструватися або перевірятимуться з модифікатором необробленого вмісту 3.5.3.

Запуск на портах 21, 23, 25, і 119 – це значення за умовчанням.

Формат

preprocessor telnet_decode: <порти>

2.2.8. Rpc decode

Препроцесор “rpc_decode” нормалізує безліч розбитих на шматки записів rpc в єдиному не розбитому на фрагменти записі. Це робиться за допомогою нормалізації пакету всередину буфера пакету. Якщо stream4 включений, то обробить тільки трафік з боку клієнта. Приймає за умовчанням запуск на портах 111 і 32771.

Таблиця 2.8: Настроюванні елементи rpc decoder

Опції	Мета
alert_fragments	попереджає про будь-який фрагментований запис
no_aleret_multiple_requests	не попереджає коли є численні записи в одному пакеті
no_alert_large_fragments	не попереджає якщо сума фрагментованих записів перевищує один пакет
no_alert_incomplete	не попереджає якщо запис єдиного фрагмента перевищує розмір пакету

Формат

preprocessor rpc_decode: <порти> [ alert_fragments ] \

[no_alert_multiple_requests] [no_alert_large_fragments] \

[no_alert_incomplete]

2.2.9. Performance monitor

Цей препроцесор вимірює максимальну продуктивність Snort в реальному часі і теоретичну максимальну продуктивність. Кожного разу, коли цей препроцесор підключений він повинен мати включений режим виводу, або “консоль”, яка видає статистику у вікно консолі або в “файл” з певним ім'ям, в якому виводиться статистика. Статистика, яка оброблена - це статистика реального часу і статистика за умовчанням. Вона містить:

1. отримані пакети;

2. втрачені пакети;

3. % втрати пакетів;

4. отримані пакети;

5. кількість пакетів за секунду;

6. середнє число байт в пакеті;

7. mbits за секунду (лінія зв'язку);

8. mbits за секунду (відновлення) [це середнє mbits який Snort поміщає після відновлення пакетів];

9. mbits за секунду (підсумок);

10. відсоток зіставлення із зразком [середній відсоток отриманих даних, які Snort обробив в шаблоні відповідності];

11. використовування cpu (призначений для користувача час, час системи, час очікування);

12. попередження за секунду;

13. syn-пакети за секунду;

14. syn/ack пакети за секунду;

15. нові сеанси за секунду;

16. віддалені сеанси за секунду;

17. загальна сума сеансів;

18. max число сеансів протягом інтервалу часу;

19. скидання потоку за секунду;

20. помилки потоку за секунду;

21. час очікування потоку;

22. кількість завершених фрагментів за секунду;

23. кількість вставок фрагментів за секунду;

24. кількість видалень фрагментів за секунду;

25. кількість скидань фрагментів за секунду;

26. час очікування фрагмента;

27. помилки фрагментів.

Коли підключене ключове слово “flow”, статистика виводить дані про вид трафіку і дані протоколу розподілу, який бачить Snort. Ця настройка може видавати велику кількість виводу.

Ключове слово “events” запускає звіт про події. Так виводиться статистика щодо числа сигнатур, які відповідали зразковому набору виявлення збігів і числом тих збігів, які були перевірені з прапорами сигнатур. Ці події називають придатними і непридатними. Це показує користувачу, якщо є проблема із запущеним набором правил.

Ключове слово “max” активує теоретично максимальну продуктивність, яку Snort обчислює на основі швидкості процесора і поточної продуктивності. Це буде доцільно тільки для однопроцесорних машин, оскільки багато операційних систем не зберігають точну статистику ядра для багатопроцесорних систем.

Ключове слово “console” виводить статистику в консолі, це є значення за умовчанням.

Ключове слово “file” видає статистику у форматі з обмежуючою комою в певний файл. Не вся статистика виводиться в цей файл. Можна також використовувати “snort-файл”, який виводитиме в директорію реєстрації Snort.

Ключове слово “pktcnt” регулює число pkts для обробки перед перевіркою зразка часу. Таким чином, підвищується продуктивність, після того, як буде перевірений зразок часу зменшення продуктивності Snort. За умовчанням 10000.

Ключове слово “time” зображає число секунд між інтервалами.

Приклади

preprocessor реrfmonitor: time 30 events flow file stats.profile max \

console pktcnt 10000

preprocessor реrfmonitor: time 300 file з:\Snort\contrib\snortstat pktcnt 10000

2.2.10. Http inspect

Httpinspect є загальним декодером http для програм користувачів. Одержуючи буфер даних, httpinspect декодує буфер, знаходить http-поля, і нормалізує їх. Httpinspect працює як над запитами клієнта, так і над відповідями серверу.

Поточна версія httpinspect обробляє тільки stateless-дескриптори. Це значить, що httpinspect перевіряє http поля в пакеті використовуючи базисний пакет, і працюватиме не коректно, якщо пакети не будуть перебрані. Це добре працює, коли є інший модуль, обробляючий перебірку, але є обмеження в аналізі протоколу. Майбутні версії матимуть режим обробки “stateful”, який перехоплюватиме в перебірки різних модулях.

Httpinspect має дуже багату призначену для користувача конфігурацію. Користувачі можуть настроїти індивідуальні http-сервери з різноманітністю елементів настройки, які повинні дозволити користувачу емулювати будь-який вид web серверу. В межах httpinspect є дві області конфігурації, global і server.

Глобальна конфігурація

Глобальні настройки мають справу з настройками, які визначають глобальне функціонування httpinspect. Наступний приклад дає загальний глобальний конфігураційний формат:

Формат

preprocessor http_inspect: global \

iis_unicode_map <map_filename> \

codemap <integer> \

[detect_anomalous_servers] \

[proxy_alert]

Допускається наявність тільки однієї глобальної конфігурації, і буде видана помилка, якщо конфігурацій більш ніж одна.

Конфігурування

1. is_unicode_map <і’мя карти> [codemap <ціле>]

Це глобальний “iis_unicode_map” файл. “iis_unicode_map” є обов'язковим параметром конфігурації. Файл карти може знаходитися в тій же директорії що і “snort.conf” або визначений через повний шлях до файлу карти.

“iis_unicode_map” файл є картою “unicode codepoint”, яка указує “httpinspect” який код сторінки використовувати при декодуванні символів “unicode”. Для серверів США, “codemap” як за звичай є 1252.

За умовчанням використовується карта “unicode codepoint” від Microsoft, яка знаходиться в початковій директорії Snort “etc”. Вона називається “unicode.map” і повинна використовуватися, якщо ніяка інша карта “codepoint” не доступна. Разом з Snort поставляється інструмент для генерації інших карт “unicode”. (“ms_unicode_generator.c” в директорії “contrib.”)

ПРИМІТКА Пам'ятайте, що ця конфігурація для карти “global iis unicode”, індивідуальні сервери можуть послатися на їх власні карти “iis unicode”.

2. detect_anomalous_servers

Цей глобальний елемент настройки конфігурації дозволяє загальну інспекцію трафіку серверу http на не-http орієнтовані порти, і попереджає, якщо помічений http трафік. Цю настройку не слід включати, якщо немає конфігурації типового серверу, яка охоплює всі порти http серверів, до яких можуть звернутися користувачі. В майбутньому перевірка трафіку буде обмежена в конкретних мережах, оскільки це більш корисно, але зараз інспектується весь трафік мережі.

3. proxy_alert

Дозволяє використовувати глобальні попередження на уповноваженому http сервері. Настроїв сервери httpinspect і включивши “alow_proxy_use”, поступатимуть тільки попередження використовування проксі для веб користувачів, які не використовують настроєні проксі або використовують проксі сервер “rogue”.

Слід відмітити, що якщо не буде потрібна настройка використання веб проксі, то буде отримано багато проксі попереджень. Отже, слід використовувати цю особливість тільки з традиційними проксі оточеннями (проксі “blind firewall” не в рахунок).

Приклад глобальної конфігурації:

Preprocessor http_inspect: global iis_unicode_map unicode.map 1252

Конфігурація серверу

Є два види конфігурування серверу: за умовчанням і за ip адресою.

Default: ця конфігурація забезпечує настройки серверу за умовчанням для будь-якого серверу, який не є індивідуально конфігурованим. Більшість з web серверів найбільш ймовірно використовуватиме типову конфігурацію.

Приклад конфігурації за умовчанням

Preprocessor http_inspect_server: server default profile all роrts { 80 }

Конфігурація за ip адресами - цей формат дуже подібний формату “default” з однією лише різницею, що можуть бути конфігуровані специфічні ips.

Приклад ip конфігурації

preprocessor http_inspect_server: server 10.1.1.1 profile all роrts { 80 }

Елементи конфігурації серверу

Важливе зауваження: деякі елементи конфігурації мають аргумент “yes” або “no”. Цей аргумент визначає, незалежно від того чи хоче користувач, щоб елемент конфігурації генерував httpinspect-попередження чи ні. Аргумент “yes/no” не визначає незалежно елемент конфігурації як “on” або “off”, тільки застережливе призначення. Іншими словами незалежно від того, що встановлено (так чи ні), http нормалізація все ж таки відбуватиметься, і заснований на правилах http трафік все ж таки ініціюватиметься.

1. profile <all|apache|iis>

Користувачі можуть конфігурувати httpinspect за допомогою використовування заздалегідь визначених профілів http-серверу. Профілі дозволяють користувачу легко настроїти препроцесор для певного виду серверу, але не потрібні для відповідної дії. Є три профілі: all, араche, і iis.

1-1. all

Профіль “all” покликаний нормалізувати використовування uri з більшості загальнодоступних хитрощів. Слід попередити про більш серйозні форми ухилень. Це великий профіль для виявлення всіх видів атак, не дивлячись на сервер http. “profile all” встановлює наступні елементи настройки.

1-2. араche

Профіль “араche” використовується для араche web-серверів. Відрізняється від “is” профілю тільки відсутністю стандартного кодування “unicode utf-8” і не приймає зворотні слеші в ролі законних слешів, подібно iis. Apache також допускає табуляцію як пропуски. “Profile араche” встановлює наступні елементи конфігурації.

1-3. iis

“iis профіль” імітує iis сервер. Таким чином, використовується “iis unicode codemaps” для кожного серверу, “%u” кодування, “bare-byte” кодування, “double” декодування, зворотні слеші, і т.п. “iis” профіль встановлює наступні елементи конфігурації:

Профілі повинні бути визначені як початкові опції серверу і не можуть бути з'єднані з будь-якими іншими настройками окрім:

1. роrts

2. iis_unicode_map

3. alow_proxy_use

4. flow_depth

5. no_alerts

6. inspect_uri_only

7. oversize_dir_length ці опції повинні бути визначені після опції “profile”.

Таблиця 2.9: Опції профілю “all”

flow_depth	300
chunk encoding	попереджає про шматки більш ніж 500000 байт
iis_unicode_map	карта codepoint в глобальній конфігурації
ascii decoding	on, попередження вимкнене
looking for null bytes in url	on, попередження включено
multiple slash	on, попередження вимкнене
directory normalization	on, попередження вимкнене
араche whitespace	on
double decoding	on
%u decoding	on
bare byte decoding	on
iis unicode codepoints	попередження включено
iis backslash	on, попередження вимкнене
iis delimiter	on

Таблиця 2.10: Опції профілю “араche”

flow_depth	300
chunk encoding	попереджає про шматки більше 500000 байт
ascii decoding	on, попередження вимкнене
looking for null bytes in url	on, попередження включено
multiple slash	on, попередження вимкнене
directory normalization	on, попередження вимкнене
араche whitespace	on, попередження включено
utf_8 encoding	on, попередження вимкнене
non_strict url parsing	on

Таблиця 2.11: Опції профілю "iis"

flow_depth	300
iis_unicode_map	карта codepoint в глобальній конфігурації
ascii decoding	on, попередження вимкнене
multiple slash	on, попередження вимкнене
directiry normalization on, alert off	on, попередження включено
double decoding	on, попередження включено
%u decoding	on, попередження включено
bare byte decoding	on, попередження включено
iis unicode codepoints	on, попередження включено
iis backslash	on, попередження вимкнене
iis delimiter	on, попередження включено
араche whitespace	on, попередження включено

Приклад

Preprocessor http_inspect_server: server 1.1.1.1 profile all роrts { 80 3128 }

2. роrts { <port> [<port> <..>] }

Настроює, які порти декодувати на http сервері. Кодований трафік (ssl) не може бути декодований, так що додавання портів 443 дасть тільки позитиви помилкового кодування.

3. iis_unicode_map <і’мя карти> codemap <ціле>

Карта “iis unicode” генерується програмою “ms_unicode_generator.c”. Ця програма розташована в директорії “contrib.”. Запуск цієї програми генерує карту “unicode” для системи, на якій вона була запущена. Отже, для того, щоб отримати специфічне юникод відображення для “iis” web-серверу, потрібно запустити цю програму на тому сервері і використати карту “unicode” в цій конфігурації.

При використовуванні цієї опції, користувачу потрібно вказати файл, який містить карту “iis unicode”, а також вказати карту “unicode” для використання. Для серверів, це звичайно 1252. Але програма “ms_unicode_generator” повідомляє, яку “codemap” потрібно використовувати для серверу, це буде кодова сторінка ansi. Можна вибрати правильну кодову сторінку за допомогою проглядання доступних кодових сторінок, які виводить “ms_unicode_generator”.

4. flow_depth <ціле>

Визначає кількість корисного навантаження відповіді серверу для перевірки. Ця опція значно збільшує “ids” продуктивність, тому ігнорується велика частина мережного трафіку, для якого так чи інакше немає правил. Більшість з правил http-серверу, які є, створені для http-заголовка і декількох байт після нього, так що можна піймати попередження за допомогою визначення “flow_depth” в межах 150 - 300. Відстань може варіюватися.

5. ascii <yes|no>

Опція “ascii” декодування незалежно указує декодувати закодовані символи “ascii”, a.k.a %2f = / %2e = ., і т.п. Нормальним є використовування “ascii” кодування в urls, так що рекомендується не включати httpinspect-попередження для цього елемента настройки.

6. utf_8 <yes|no>

Опція “utf-8” декодування указує httpinspect декодувати стандартні “utf-8 unicode” послідовності, які знаходяться в “uri”. Цей елемент дотримується стандарту “unicode” і лише використовує “%” кодування. Apache використовує цей стандарт, так що для будь-яких серверів араche, переконайтеся в тому, що цей елемент настройки включений. Щодо попереджень, можна поцікавитися, коли є “utf-8” кодований “uri”, але він може виявитися помилковим, оскільки законні web-клієнти використовують цей вид кодування. Коли “utf_8” запущений, то “ascii” декодування також дістає можливість здійснювати правильне функціонування.

7. u_encode <yes|no>

Ця настройка емулює схему “iis %u” кодування. Схема “%u” кодування працює таким чином:

схема кодування запускається “%u” з вказівкою 4 символів, подібно “%uxxxx”. “xxxx” є шістнадцятеричним кодованим значенням, яке узгоджується з “iis unicode codepoint”. Це значення найімовірніше буде “ascii”. Символ “ascii” кодується подібно “%u002f = /”, “%u002e = .”, і т.п. Якщо не визначена “iis_unicode_map” перед або після цього елемента настройки, то використовується “codemap” за умовчанням.

Слід попереджати про “%u кодування”, тому що немає ніяких законних клієнтів, які використовують це кодування. Отже, найбільш ймовірно, що хто-небудь пробує сховатися.

8. bare_byte <yes|no>

Кодування “чистого байта” - це iis хитрість, яка використовує не-ascii символи в ролі правильних значень в декодуванні значень “utf-8”. Це не входить в стандарт http, оскільки всі не-ascii значення повинні кодуватися за допомогою “%”. Кодування “чистого байта” дозволяє користувачу емулювати “iis” сервер і коректно інтерпретувати кодування невідповідні стандартам.

Попередження по цьому декодуванні повинне бути включеним, тому що немає законних клієнтів, які використовують кодування “utf-8” з тих пір, як вона перестала відповідати стандартам.

9. base36 <yes|no>

Ця опція для декодування кодованих “base36” символів. Цей елемент настройки заснований на інформації з http://www.yk.rim.or.jp/~shikap/patch/spp\_http\_decode.patch

Якщо “%u” кодування доступно, ця настройка не працюватиме. Доведеться використовувати опцію “base36” з елементом “utf_8”. Не слід використовувати “%u” опцію, тому що “base36” не працюватиме. Коли “base36” встановлений, то “ascii” кодування відбуватиметься правильно.

10. iis_unicode <yes|no>

Опція “is_unicode” включає відображення “unicode codepoint”. Якщо не визначена опція “is_unicode_map” настроєна в конфігурації серверу, “iis_unicode” використовуватиме “codemap” за умовчанням. Опція “iis_unicode” оперує відображенням не-asci “codepoints”, які “iis” сервер приймає і декодує нормальним “utf-8” запитом.

Користувачі повинні попереджати про “iis_unicode” опцію, тому вона помічається в більшості випадків атак і спроб ухилення. Коли “iis_unicode” визначений в парі з “ascii” і “utf-8” декодуванням, то здійснюється правильне декодування. Для попереджень по “utf-8” декодуванню користувач повинен включити також “utf_8 yes”.

11. double_decode <yes|no>

Опція “double_decode” є ще однією “iis” специфікацій, і емулює “iis” функціональність. “iis” робить два проходи через “uri” запит, проводячи декодування в кожному з них. В першому проході виконуються наступні кодування: “utf-8 unicode”, “asci”, “чистий байт”, і “%u”. В другому проході виконуються наступні кодування: “ascii”, “чистий байт”, і “%u”. “utf-8” пропускається, тому що “%” кодований “utf-8” перекодований в “unicode” байт в першому проході, а потім в другій стадії декодується “utf-8”. Так чи інакше, це дійсно складно і додає тонни різних кодувань для одного символу. Коли “double_decode” дозволений, як і “ascii”, то відбувається правильне декодування.

12. non_rfc_char { <byte> [<byte ..>] }

Цей настроювальний елемент дозволяє користувачам одержувати попередження, якщо певні не-rfc символи використовуються в “uri” запиті. Наприклад, користувач не хоче бачити недійсні байти в uri-запиті і може генерувати попередження із цього приводу. Цей елемент потрібно дбайливо використовувати, оскільки його можна настроїти для сповіщення про все або щось подібне. Це гнучка настройка, так що слід бути обережним.

13. multi_slash <yes|no>

Ця настройка нормалізує численні слеші в ряд, подібно цьому: "foo/////////bar" отримати нормалізацію "foo/bar".

Якщо вимагається одержувати попередження, коли зустрічаються численні слеші, то слід встановити “та” в іншому випадку “ні”.

14. iis_backslash <yes|no>

Нормалізує зворотні слеші в слеші. Це ще одна “iis” емуляція. Отже uri-запит "/foo bar" нормалізується в "/foo/bar".

15. directory <yes|no>

Ця настройка нормалізує проглядання директорії і довідкової директорії.

Директорія:

/foo/fake\_dir/../bar

після нормалізації:

/foo/bar

Директорія:

/foo/./bar

після нормалізації:

/foo/bar

Для настройки попередження слід встановити “так”, в іншому випадку “ні”. Це попередження може видавати помилкові повідомлення, оскільки деякі веб-вузли стали звертатися до файлів, використовуючи проглядання директорії.

16. apache_whitespace <yes|no>

Цей елемент відповідає не-rfc стандарту таблиці для роздільника простору. Apache використовує його, так що якщо емулюючим web-сервером є араche потрібно настроїти цей елемент. Попередження по цій опції можуть бути цікавими, але можуть бути також схильні до помилкових значень.

17. iis_delimiter <yes|no>

Запускає специфічний “iis”, араche добре розуміє цей невідповідний стандартам роздільник. З тих пір, як ця опція стала загальною, її прийняли як стандарт з часу, коли найпопулярніші web-серверу стали її приймати. Але все ще можна отримати попередження з цією опцією.

18. chunk_length <не нульове позитивне ціле>

Ця настройка - детектор аномалій для ненормально великих розмірів фрагментів. Ця опція збирає араche використані кодовані фрагменти, і може також видавати попередження на використання http тунелю, який використовує кодування фрагмента.

19. no_pipeline_req

Ця опція вимикає конвеєр http декодування, і є розширенням продуктивності. За умовчанням запити конвеєра перевіряються на атаки, але коли ця настройка встановлена, запити конвеєра не декодуються і аналізуються за полями http протоколу. Перевірка проводиться тільки загальним зіставленням із зразком.

20. non_strict

Ця настройка активує нестрогий uri-аналіз для пошкодженого шляху, в якому сервери араche декодуватимуть “uri”. Цю настройку слід використовувати тільки на серверах, які прийматимуть “uris” подібно “get /index.html alsjdfk alsj lj aj la jsj s n”. Опція “non_strict” приймає “uri” між першим і другим пропуском, навіть якщо після другого пропуску немає правильного http ідентифікатора.

21. alow_proxy_use

Визначаючи це ключове слово, користувач допускає використовування проксі на цьому сервері. Це значить, що не генеруватимуться попередження, якщо глобальне ключове слово “proxy_alert” було використано. Якщо ключове слово “proxy_alert” є не встановленим, то ця настройка нічого не робитиме. Ключове слово “alow_proxy_use” - це тільки спосіб для заборони несанкціонованого використовування проксі для уповноваженого серверу.

22. no_alerts

Ця опція вимикає всі попередження, які генеруються модулем препроцесора httpinspect. Вона не впливає на http правила в наборі правил. Ніякий аргумент не визначений.

23. oversize_dir_length <не нульове позитивне ціле>

Ця настройка приймає позитивне ненульове ціле число як аргумент. Аргумент визначає “max” довжину символів для “url” директорії. Якщо “url” директорія більше цього розміру аргументу генеруватиметься попередження. Добрим значенням аргументу вважається 300 символів. Це повинно обмежити попередження атак “ids” ухилення, подібно “whisker-i 4”.

24. inspect_uri_only

Це оптимізація продуктивності. Коли включена, тільки “uri” частина http запитів буде перевірена на атаки. Оскільки це поле звичайно містить 90-95 % web атак, можна буде піймати більшість з них. Отже якщо потрібна додаткова продуктивність, то варто дозволити цю оптимізацію. Важливо відзначити, що якщо ця настройка використовується без будь-яких правил з “uri” вмістом, то перевірка не проводитиметься. Це стало очевидним з часу коли “uri” стало перевірятися тільки правилами з “uri” вмістом, і якщо їх немає в наявності, тоді перевірка не проводитиметься.

Наприклад, є в наявності наступний набір правил:

alert tcp any any -> any 80 ( msg:"content"; content: "foo"; )

перевіряємо наступний uri:

get /foo.htm http/1.0\r\n\Попередження не генеруватиметься, коли “inspect_uri_only” включений. Конфігурація “inspect_uri_only” виключає всі форми виявлень окрім перевірки “uri” вмісту.

25. webroot

Ця настройка генерує попередження, коли проходження директорії продивляється мимо кореневого каталогу web серверу. Це генерує набагато менші помилкові позитиви, ніж опції директорії, тому що не попереджає про проглядання директорії, що перебуває в межах структури каталогів web-серверу. Попереджає тільки, коли проглядання директорії проходить мимо кореневого каталогу web-серверу, який пов'язаний з певними web-атаками.

Приклади

Preprocessor http_inspect_server: server 10.1.1.1 \

роrts { 80 3128 8080 } \

flow_depth 0 \

ascii, no \

double_decode, yes \

non_rfc_char { 0x00 } \

chunk_length 500000 \

non_strict \

no_alerts

preprocessor http_inspect_server: server default \

роrts { 80 3128 } \

non_strict \

non_rfc_char { 0x00 } \

flow_depth 300 \

apache_whitespace yes \

directory no \

iis_backslash no \

u_encode yes \

ascii no \

chunk_length 500000 \

bare_byte yes \

double_decode yes \

iis_unicode yes \

iis_delimiter yes \

multi_slash no

preprocessor http_inspect_server: server default \

profile all \

роrts { 80 8080 }

2.3. Поріг події

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

Існує 3 види порогів:

1. ліміт (limit): попереджає про перші “m” події протягом інтервалу часу, потім ігнорує події для решти частини інтервалу часу.

2. поріг (threshold): попереджає “m” раз, коли бачимо цю подію протягом інтервалу часу.

3. обидва (both): попереджає один раз за інтервал часу після виявлення “m” випадків подій, потім ігнорує будь-які додаткові події протягом інтервалу часу.

Команди обмежень можуть включатися в правила, або можна використовувати команди автономного порогу, який посилається на генератор і “sid” до якого вони приймаються. Немає функціональної різниці між додаванням порогу до правила, або використанням окремої команди порогу, застосованої до того ж правила. Існує логічна різниця. Деякі правила мають сенс тільки з використанням порогу. Це повинно включити команду порогу в правилі. Наприклад, правило для виявлення багатьох спроб логіна пароля може вимагати більш ніж 5 спроб. Це можна зробити, використовуючи команду порогу “limit”. В цьому є значення, тому що характеристика порогу є становлячою частиною цього правила.

Для того, щоб правила порогів застосовувалися належним чином, ці правила повинні містити “sid”.

Тільки один поріг може застосовуватися до будь-якого даного генератора і пари “sid”. Якщо більш ніж один поріг застосований до генератора і пари “sid”, Snort закінчить роботу з помилкою в процесі читання конфігураційної інформації.