3.3. Параметри правил Snort

Нагадаємо, що правило Snort складається із заголовка і параметрів, які і будуть детально розглянуті в цьому розділі.

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

Формат параметрів правила

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

alert tcp !$HOME_NET any -> $HOME _NET any (flags: SF; \

msg: "SYN-FIN scan"; )

В даному випадку параметри задані в рядку (flags: SF; \ msg: "SYN-FIN scan";). Кожний параметр включає ключове слово і (можливо) його значення. В даному прикладі для ключового слова “flags” встановлено значення SF, а для ключового слова “msg” - значення SYN-FIN scan. Для деяких параметрів як значення ключового слова повинні встановлюватися чисельні значення, для інших це повинні бути спеціальні коди. Між ключовим словом і його значенням встановлюється символ двокрапки (:), а параметри відділяються один від одного крапкою з комою (;). Крім того, крапка з комою повинна бути встановлена після останнього параметра. В іншому випадку буде видано повідомлення про помилку. Хоча значення більшості ключових слів вимагається встановлювати, але є і декілька виключень. Наприклад, не існує значень для ключового слова “nocase”, яке визначає, що при дослідженні вмісту корисних даних пакету не повинен враховуватися регістр символів.

Для Snort не має значення наявність декількох або повна відсутність пропусків між символами розділення (; і :), параметрами і значеннями. Наприклад, обидва наступні набори параметрів є рівнозначними.

(flags: SF; msg: "SYH-FIN scan"; )

(flags: SF; msg: "SYN-FIN scan"; )

Символ зворотної косої лінії (\) є символом продовження правила. Він встановлюється в кінці рядка незавершеного правила і дозволяє продовжити його написання в наступному рядку. Символ “решітки” (#) використовується для додавання коментарів в правила Snort.

Параметри правил

Тепер приступимо до розгляду найпопулярніших параметрів правил Snort, які дозволять продемонструвати всю потужність можливостей цієї системи. Опис всіх доступних параметрів правил Snort можна знайти на сайті www.snort.org, відкривши в посиланні Documentation розділ Snort Users Manual.

Параметр msg

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

Нижче приведені формат параметра, приклад правила і запис про зареєстроване попередження в результаті “спрацьовування” цього правила.

Формат:

msg: "<текст повідомлення>";

Приклад правила:

alert udp any any ->192.168.5.0/24 31337 \ (msg: "Back Orifice"; )

Приклад звіту:

[**] Back Orifice [**]

04/24-08:49:21.318567 192.168.143.15:60256 -> 192.168.5.16:31337 UDP TTL:41 TOS:0X0 ID:49951

Len:8

Це правило Snort викликає попередження (і реєстрацію) при отриманні з будь-якої IP-адреси і порту відправника пакету, призначеного хостам підмережі 192. 168. 5 на порт 31337. При цьому повинне видаватися повідомлення "Back Orifice".

Параметр logto

Параметр logto дозволяє задати ім'я файлу, в який записуватимуться звіти. Він використовується тільки для правил, для яких визначена дія попередження або реєстрації. Звичайно при “спрацьовуванні” таких правил інформація зберігається в каталозі за умовчанням (var/log/snort для UNIX-хостів, а для хостів під управлінням Windows - в підкаталозі log каталогу, в який була встановлена Snort) або в каталозі, вказаному після параметра командного рядка “-l” при запуску Snort. При цьому передбачається, що користувач не змінив вживану за умовчанням реєстрацію на збереження інформації в двійковому форматі (за допомогою параметра командного рядка “-b”) або на передачу даних демону системного журналу syslog (за допомогою параметра командного рядка “- s”) і повністю не відмінив реєстрацію (за допомогою параметра командного рядка “-N”).

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

Формат:

logto: "<ім’я_файла>";

В Snort не потрібно задавати повне ім'я файлу (з вказівкою шляху). Якщо буде вказаний шлях до файлу, то Snort видасть повідомлення про помилку. Ім'я файлу необхідно брати в лапки, інакше перед цим ім'ям може бути доданий пропуск.

Приклад правила:

alert udp any any -> 192.168.5.0/24 31335 \ (msg: "trinoo роrt"; logto: "DDoS"; )

Приклад звіту (при "спрацьовуванні" правила запис про цю подію на UNIX-хості заноситься у файл /var/log/snort/DDoS):

[**] trinoo роrt [**]

04/24-09:07:41.320938 192.168.143.15:56881 -> 192.168.5.16:31335 UDP TTL: 42 TOS:0x0 ID:4011

Len: 8

Параметр tcl

За допомогою параметра tcl можна перевірити значення поля ТТL отриманого пакету. Для використовування цього параметра існує безліч причин. Одним з них є пошук пакетів з невеликими значеннями поля TTL, що свідчить про використовування програми Traceroute віддаленим UNIX-хостом або програми Tracert віддаленим Windows-комп'ютером. Якщо при цьому використовується один з UDP-портів в діапазоні від 33000 до 34000, то швидше за все приміняється програма Traceroute. Windows-програма Tracert працює за допомогою ехо-запитів ICMP.

Наступне правило дозволяє знайти запити програми Traceroute до мережі 192. 168. 5 з вказаним портом відправника в діапазоні від 33000 до 34000 і значенням поля TTL, рівним 1.

Формат:

ttl: <число>;

Приклад правила:

alert udp any any ->192.168.5.0/24 33000:34000 \

(msg: "Unix traceroute"; ttl: 1; )

Приклад звіту:

[**] Unix traceroute [**]

04/24-09:29:37.971353 192.168.143.15:40920 -> 192.168.5.16:33437

UDP TTL: 1 TOS:0X0 ID:40923

Len: 18

Параметр id

Для Snort значення ідентифікатора в IP-заголовку використовується 16-бітове поле. Для кожної нової дейтаграмми встановлюється унікальний ідентифікатор, і його значення звичайно збільшується на 1 для кожного наступного пакету. При фрагментації це число називають ідентифікатором фрагмента, по якому виконується збірка одержуваної послідовності фрагментів. В наступному прикладі представлено правило, за допомогою якого можна виявити пакети з незвичайним значенням ідентифікатора, рівним 0. На жаль, ядро операційної системи Linux 2.4 встановлює значення 0 для ідентифікатора IP-дейтаграмм, коли в дейтаграммі також встановлений прапор DF (Don't Fragment - не фрагментувати). Пояснюють це тим, що якщо пакет не може бути фрагментований, то навіщо думати про ідентифікатор фрагмента.

Формат:

id: <число>

Приклад правила;

alert icmp any any -> 192.168.5.0/24 any \

(msg: "Suspect IP Identification #"; ID: 0; )

Приклад звіту:

[**] Suspect IP Identification # [**]

04/25-09:21:36.371005 192.168.143.15 -> 192.168.5.16

ICMP TTL:64 TOS:0X0 ID:00

Параметр dsize

Параметр dsize дозволяє Snort досліджувати розмір корисного навантаження пакету. Можна встановити перевірку по точному значенню або задати пошук пакетів з більшим або меншим за розміром корисним навантаженням. Це може стати в нагоді при створенні правила для блокування атак на переповнювання буфера. Ці атаки легко виявити, якщо організувати пошук пакетів, розмір корисних даних яких перевищує очікуване значення. Наступне правило призначено для виявлення IСМР-пакетів, корисне навантаження яких перевищує 1024 байт.

Формат:

dsize: [< | >] число

Приклад правила:

alert icmp any any ->192.168.5.0/24 any \

(msg: "Перевищення стандартної довжини ICMP-даних"; dsize: >1024; )

Приклад звіту:

[**] Перевищення стандартної довжини ICMP-даних [**] 04/24-11:24.110169 192.168.143.100 -> 192.168.5.16 ICMP TTL: 255 TOS: 0x0 ID: 5487 DF

ID: 7564 Seq: 0 ЕСHO

Параметр sequence

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

Формат:

seq: <число>

Приклад правила:

alert tcp any any -> any any \

msg: "Можливо, проводиться. DDoS-атака Shaft"; seq: 0x28374839; )

Приклад звіту:

[**] Можливо, проводиться DDoS-атака Shaft [**]

04/25-07:19:58.582562 192.168.143.100:35680 -> 192.168.143.15:23

TCP TTL: 255 TOS: 0x0 ID: 7705 DF

******S* Seq: 0x28374839 Acк: 0x0 Win: 0x2238

TCP Options => MSS: 1460

Параметр асknowledgement

За допомогою параметра асknowledgement можна перевірити значення номера підтвердження TCP-сегменту. Основним призначенням такої перевірки є виявлення спроб сканування, здійснюваних програмою nmap. Для виявлення активного хоста nmap відправляє TCP-пакет зі встановленим прапором АСК, а значення номера підтвердження в цьому пакеті рівно 0. В нормальному TCP-сеансі отримання пакету з таким номером підтвердження є досить рідкісним, оскільки це означає, що в попередньому отриманому TCP-сегменті значення порядкового номера досягло 232-1 (тільки тоді номер підтвердження обнуляється).

Формат:

аск: < число>;

Приклад правила:

alert tcp any any -> any any \

(msg: "nmap TCP ping", - flags: А; аск: 0; )

Приклад звіту:

[**] nmap TCP ping [**]

04/25-07:27:13.578488 192.168.143.15:63367 -> 192.168.143.16:80

TCP TTL:42 TOS:0x0 ID:26253

***A**** Seq: 0x16680003 Acк: 0x0 Win: 0xC00

Параметри itype і icode

Параметр itype використовується для вказівки типу ICMP-повідомлення. Поле “Тип” знаходиться в нульовому байті ICMP-пакету. Можливі значення цього поля і поля для зберігання коду ICMP-повідомлення, яке перевіряється за допомогою параметра icode, можна взнати за адресою www.iana.org/assignments/icmp-parameters. Частіше всього параметри itype і icode використовуються спільно. Код ICMP-повідомлення указується в першому байті ICMP-пакету. Багато ICMP-повідомлень відрізняються тільки кодом і мають один і той же тип. Наприклад, існує досить багато різних кодів для ICMP-повідомлень типу 3. Щоб виявити ICMP-повідомлення про недосяжність порту, потрібно створити правило Snort, згідно якому значення параметра itype дорівнювало б 3, і значення параметра icode теж би складало 3.

Формат:

itype: <число>; icode: < число>;

Приклад правила:

alert icmp 1.1.1.0/24 any -> 192.168.5.0/24 any \

(msg: "роrt unreachable"; itype: 3; icode: 3; )_;

Приклад звіту:

[**] роrt unreachable [**]

04/25-07:56:37.129338 1.1.1.16 -> 192.168.5.15

ICMP TTL: 255 TOS: 0xC0 ID: 33569

DESTINATION UNREACHABLE: PORT UNREACHABLE

Параметр flags

За допомогою параметра flags можна організувати різні перевірки встановлених в TCP-сегменті прапорів. Перерахуємо їх, починаючи наймолодшим прапором (справа наліво в байті TCP-прапорів):

F -встановлений прапор FIN;

S - встановлений прапор SIN;

R - встановлений прапор RESET;

Р - встановлений прапор PUSH;

А - встановлений прапор АСК;

U - встановлений прапор URG;

R - встановлений прапор RESET;

2 - встановлений ехо-біт ЕСN (раніше зарезервований біт);

1 -встановлений біт CWR (раніше зарезервований біт);

0 - не встановлено жодного прапора.

Крім того, для перевірки встановлених комбінацій прапорів допускається використовування трьох модифікаторів (+ * !). Наприклад, запис А+ означає, що в пакеті повинен бути встановлений прапор АСК. При цьому він може бути єдиним встановленим прапором або разом з ним можуть бути встановлені і інші прапори. Опис підходить і для пакетів із стандартною комбінацією прапорів PUSH (тобто нові дані відправляються одночасно з підтвердженням отримання минулої порції). Модифікатор “*” використовується для виявлення пакетів, в яких встановлений один або декілька прапорів із заданої комбінації. Наприклад, рядок SFP* визначає пошук пакетів зі встановленим хоча б одним з трьох прапорів SYK, FIN і PUSH, а також пакетів з будь-якою їх комбінацією. Останній модифікатор “!” дозволяє задати пошук пакетів, в яких не встановлений даний прапор. Параметр flags: !S, наприклад, дозволяє знайти всі пакети, в яких не встановлений прапор SYN.

Формат:

flags: <код_установлених_прапорів>

На мал. 14. 1 показано графічне представлення кодів Snort для прапорів TCP. Доступні модифікатори прапорів:

+ - всі пакети, в яких встановлений заданий прапор (або прапори) і будь-які інші прапори;

* - всі пакети, в яких встановлений один з вказаних прапорів;

! - всі пакети, в яких не встановлений вказаний прапор (прапори).

Приклад правила:

alert tcp any any -> any any (msg: "Сканування за допомогою null-пакетів"; /

flags: 0; )

Приклад звіту:

[**]Сканування за допомогою null-пакетів [**]

04/25-05:49:51.914748 192.168.143.15:54746 -> 192.168.143.16:21

TCP TTL: 51 TOS: 0x0 ID: 23446

******** Seg: 0x1CED3E2E Acк: 0x0 Win: 0x1000

TCR Options => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL EOL

В приведеному вище прикладі звіту міститься рядок з восьми символів зірочок (********). Snort замінює зірочки відповідними кодами для встановлених в пакеті прапорів (12UAPRSF), якщо отримання цього пакету викликало попередження. Оскільки в даному випадку проводилося сканування за допомогою null-пакету (в пакеті не встановлено ніяких прапорів), то всі зірочки залишилися на місці.

Параметр content

Один з найважливіших параметрів - content - часто використовують невірно. З його допомогою здійснюється перевірка вмісту корисних даних пакетів. Доступні різні способи задання значень для параметра content, і можна організувати перевірку по декількох таких значеннях. Проглядання вмісту корисних даних, вимагає значної витрати обчислювальних засобів, іншими словами, неправильне використовування параметра content може серйозно уповільнити роботу Snort. Хоча творці Snort максимально оптимізували алгоритм для проглядання корисних даних пакетів, але все одно ця операція виконується значно повільніше, ніж, наприклад, пошук заданих значень в полях заголовків Це пояснюється тим, що довжина поля заголовка складає максимум 4 байт, а розмір корисного навантаження звичайно набагато більше.

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

Рядок пошуку може бути заданий як текст, як шістнадцятеричне представлення двійкових даних або як комбінація тексту і шістнадцятеричних символів. Текстові рядки поміщаються в лапки і при пошуку враховується регістр символів (якщо не використаний параметр nocase). Шістнадцятеричний код відділяється за допомогою символів конвеєризації (|). За допомогою параметра content (або декількох подібних йому) для пошуку в пакеті можуть бути задані різні значення, при цьому для “спрацьовування” правила в пакеті повинні бути присутні всі задані значення. Значення, задані за допомогою декількох параметрів content, можуть знаходитися в підозрілому пакеті в будь-якій послідовності, незалежно від порядку параметрів content. Існує і інший параметр content-list, який дозволяє вважати правило таким, що “спрацювало” при знаходженні відповідності хоча б з одним із заданих параметрів content-list. Опис цього параметра і приклад його використовування можна знайти на сайті www.snort.org в розділі Snort Users Manual.

Формат:

content: <"value">;

content; <"value">_; content: <"value">;

Приклад правила:

alert udp $EXTERNAL_NET any -> $HOHE_NET 53 \

(msg: "Атака BIND спроба переповнювання буфера tsig"; \

content: "|00 FA 00 FF|"; content: "/bin/ah"; );

В цьому звіті знайдені в корисних даних шістнадцятеричні символи відображені зліва, а справа представлені відповідні їм ASCII-символи. Створене правило призначено для виявлення вхідного UDP-трафіку, відправленого на порт 53 одному з комп'ютерів мережі, що захищається. Зокрема, відстежується передача двох рядків: перша з них представлена в шістнадцятеричному форматі 00 FA 00 FF, а друга - в текстовому (рядок /bin/sh). Перевіряється присутність обох цих рядків в корисному навантаженні у будь-якому порядку. Це правило буде використано тільки після перевірки всієї решти параметрів для пакету, що поступив.

Деякі параметри правил використовуються тільки в якості модифікаторів для параметра content, іншими словами, при їх самостійному використовуванні без цього параметра буде видано повідомлення про помилку. Такими параметрами є: offset, depth, nocase і regex. Вони уточнюють характеристики пошуку тільки для вказаного безпосередньо перед ними параметра content який прапор.

Якщо досліджувати правила Snort, що поставляються спільно з самою системою, то можна помітити, що в дуже багатьох правилах окрім параметра content використовується параметр flags із значенням А+. Таким чином, для “спрацьовування” правила в пакеті повинен бути встановлений прапор АСК (і, можливо, інші прапори). Це може показатися неправильним, і багато хто може логічно заперечити: “А чому не використовувати параметр flags із значенням р+?”. Врешті-решт, система Snort повинна досліджувати вміст, коли в пакеті передаються байти корисного навантаження.

Все це так, і обробка пакетів стає більш ефективною, якщо правило з використанням параметра content застосовуватиметься тільки для тих пакетів, в яких передаються корисні дані. Але, як сказано в книзі Річарда Стівенса TCP/IP Illustrated, Volume 1, не дивлячись на те, що стеки TCP/IP багатьох BSD-систем встановлюють прапор PUSH для кожного пакету, в якому передаються дані, в інших операційних системах цей прапор встановлюється тільки тоді, коли користувач ініціює негайну відправку даних з витікаючого буфера. Це означає, що якщо одержувач встановлює невеликий розмір TCP-вікна, і відправник не звільняє весь свій вихідний буфер, то в пакетах, що відправляються, встановлюється тільки прапор АСК. Тому для параметра flags використовується значення А+. Не дивлячись на те що багато пакетів з прапором АСК не несуть корисного навантаження, вони також перевірятимуться.

Альтернативним варіантом перевірки наявності в пакеті корисних даних є використання параметра dzise >0. Це дозволяє знайти незвичайний трафік, наприклад, передачу даних в SYN-пакетах, в яких прапор АСК не встановлюється.

Як приклад відправки корисних даних в пакеті, в якому встановлений тільки прапор АСК, розглянемо два звіти про дії програми LaBrea версії 2. Ця програма дозволяє уповільнити атаку зловмисника за допомогою штучного заниження розміру вікна. В першому записі хост з програмою LaBrea (IP-адреса 10. 10. 10. 155) видає себе за Web-сервер і встановлює незвичайно мале значення розміру вікна, рівне 5. Хост порушника attacker.Net відправляє 5 байт корисних даних. Як видно, в передаваному пакеті встановлений тільки прапор АСК і немає прапора PUSH, оскільки розмір відправлених даних не дозволив повністю звільнити буфер хосту attacker.net.

10.10.10.155. www > attacker. net. 2045: S 998514038: 998514038(0) аск

=> 882335287 win 5

attacker. net. 2045 > 10.10.10.155. www: 1: 6(5) аск 1 win 8576 (DF)

Параметр offset

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

Формат:

offset: <число>;

Приклад правила:

alert tcp any any -> 192. 168. 5. 0/24 21 \ (msg: " Спроба анонімного доступу до ftp-серверу "; \ content: "anonymous"; offset: 5; )

Приклад звіту:

[**] Спроба анонімного доступу до ftp-серверу [**]

04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.5.16:21

TCP TTL: 64 TOS: 0x10 ID: 30124 DF

***AP*** Seq: 0x93EE0AB7 Acк: 0xB8352E61 Win: 0X7D78

TCP Options => NOP HOP TS_: 112024246 27551686

55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous..

Рядок “anonymous” знаходиться в шостому байті корисного навантаження, але оскільки при обчисленні зсуву рахунок починається з нуля, те значення зсуву 5 дозволяє знайти заданий рядок.

Параметр depth

Параметр depth є ще одним параметром, за допомогою якого можна обмежити розмір досліджуваних Snort корисних даних пакету. Він визначає кількість байтів, досліджуваних після заданого зсуву. Якщо зсув не заданий, воно вважається рівним 0. Цей параметр дозволяє значно підвищити ефективність роботи Snort при обробці пакетів з великими об'ємами корисних даних, для яких відома структура цих передаваних даних (в якій частині пакету знаходяться ті або інші дані).

Формат:

depth: < число>

Приклад правила:

alert udp ! $НОМЕ_NЕТ any -> $HOME_NET 5632 \

(msg: "PCAnywhere Startup"; content: "ST"; depth: 2; )

Приклад звіту:

[**] PCAnywhere Startup [**]

04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:5632

UDP TTL: 64 TOS: 0xl0 ID: 30124 DF

73 74 61 72 74 75 70 STARTUP

Пакет відповідатиме цьому правилу, якщо в його перших двох байтах (за умовчанням зсув рівен 0) корисного навантаження буде знайдений рядок "ST".

Параметр nocase

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

Формат:

nocase

Приклад правила:

alert tcp any any -у any 21 \

(msg: "FTP warez snooping"; content: "warez"; nocase; )

Приклад звіту:

[**] ftp warez snooping [**]

04/25-05:28:28.146374 192.168.143.15:3487 -> 192.168.143.16:21

TCP TTL: 64 TOS: 0xl0 ID: 30637 DF

***AP*** Seg: 0xE1977C8D Acк: 0x452F7F9 Win: 0x7D78

TCP Options => NOP NOP TS: 118248207 33775174

43 57 44 20 57 61 52 65 5A 0D 0A CWD WareZ..

Параметр regex

Параметр regex дозволяє в рядку символів, що задається для пошуку за допомогою параметра content, використовувати універсальні символи. Можливо використовування двох універсальних символів: знак “?” можна застосовувати для позначення одного будь-якого символу, а зірочка “*” дозволяє замінити будь-яку кількість символів.

За допомогою параметра regех можна виявити ознаки атак на переповнювання буфера. При успіху цієї атаки на хосту під управлінням UNIX зловмисник, швидше за все, схоче отримати доступ до командного інтерпретатора, наприклад інтерпретатору Bourne (файл /bin/sh), хоча існує багато інших командних інтерпретаторів, таких як командний інтерпретатор C (chs), Korn (ksh) і Bourne again (bash). Таким чином, за допомогою одного рядка і універсального символу можна знайти спроби доступу до всіх командних інтерпретаторів. До появи параметра regex єдиним способом перевірити спроби доступу до командних інтерпретаторів було створення окремих правил. Не забувайте, що параметр regex став повно функціональним тільки у версії Snort 2. 0.

Формат:

regex;

Приклад правила:

log tcp any any -> 192. 168. 5. 0/24 515/

(msg: "Спроба отримання доступу до командного інтерпретатора / за допомогою lpd"; content: "/bin/*sh"; regex; )

Приклад звіту:

[**Спроба отримання доступу до командного інтерпретатора за допомогою Ipd**]

03/23-07:41:11.282960 1.1.0.1:1892 -> 192.168.5.55:515

TCP TTL: 64 TOS: 0x0 ID: 63821 IPLen: 20 DgmLen: 60

***AP*** Seq: 0x32A77D55 Acк: 0x0 Win: 0x200 TcpLen: 20

2F 62 69 6E 2F 63 73 68 0A 00 00 00 00 00 00 00 /bin/csh...

00 00 00 00

Приведене вище правило дозволяє контролювати спроби доступу до командного інтерпретатора за допомогою пакетів, відправлених на порт 515 (порт Ipd). Уточнююче значення параметра regex (/bin/*. sh) для параметра content дозволяє виявити будь-які спроби доступу до командного інтерпретатора.

Параметр session

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

Для параметра існує два доступні ключові слова: printable і all. За допомогою ключового слова “printable” зберігаються друковані символи. Ключове слово “аll” дозволяє зареєструвати також і всі недруковані символи з їх шістнадцятеричними еквівалентами.

Будьте готові до того, що застосування параметра session може понизити продуктивність Snort, тому його краще використовувати для вже зареєстрованих даних: можна зберегти дані в двійковому форматі (файли TCPdump) і потім проглянути їх за допомогою Snort. Крім того, при застосуванні цього параметра повинні перевірятися дані, передаванні в обох напрямах (як показано в прикладі). І останнє: бажано додавати в командний рядок параметр “-d” для збереження даних на рівні додатків, в іншому випадку використання параметра session не має особливого сенсу.

За умовчанням звіти про сеанси зберігаються в каталозі log. Потім інформація розділяється по підкаталогах, назви яких аналогічні IP-адресам хостів, що ініціювали з'єднання. Формат імені файлу реєстрації сеансу - SESSION: sourceport-destport, де sourceport і destport - номери портів відправника і одержувача для даного сеансу відповідно.

Формат:

session: [printable/all]

Приклад правила:

log tcp any any <> 192.168.5.0/24 21 (session: printable; )

Якщо припустити, що IP-адресою хоста-відправника є 1. 2. 3. 4, а порт відправника 1025, то наступний звіт буде збережений в каталозі log в підкаталозі 1. 2. 3. 4 у файлі SESSION.

Приклад звіту:

220 linux2 FTP server (Version wu-2. 5. 0(l) Tue Sep 21 16: 48: 12 EDT 1999} ready.

USER jsmith

331 Password reguied for jsmith.

PASS snorty-the-plg

230 User jsmith logged in.

SYST

215 UNIX Type: L8

QUIT

221 - You have transferred 0 bytes in 0 files.

221 - Total traffic for this session was 239 bytes in 0 transfers.

221 - Thank уоu for using FTP service on linux2.

221 - Goodbye

Параметр resp

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

Для розриву TCP-з'єднань на сокет хоста-відправника, хоста-одержувача або сокети обох хостів може бути відправлений пакет зі встановленим прапором RESET. Якщо атака здійснюється за допомогою UDP-пакетів, то для розриву з'єднання посилаються різні ICMP-повідомлення (про недосяжність мережі, хосту, порту або комбінація цих ICMP-повідомлень).

Параметр resp не входить до складу автоматично встановлюваних. Щоб його використовувати, слід задати конфігурацію системи Snort за допомогою наступної команди:

. /configure -еnable-flexresp

Вона дозволяє додати необхідний програмний код для подальшої компіляції. Можливо, що до складу вашої версії UNIX не входить файл 1ibnet.h, який потрібен для виконання компіляції. Цей файл можна завантажити з сайту www.packetfactory.net.

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

Ще одна проблема полягає в узгодженні за часом. Часто обмін запитами і відповідями здійснюється практично миттєво, особливо запитами і відповідями служби DNS по протоколу UDP. Спроба відреагувати на отриманий шкідливий DNS-запит може виявитися даремною, оскільки за час реакції Snort відповідь вже може бути відправлена.

Формат:

resp <resp-параметр [, resp-параметр... ]>;

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

rst_snd - відправити TCP-пакет зі встановленим прапором RESET на сокет хоста-відправника;

rst_rcv - відправити TCP-пакет зі встановленим прапором RESET на сокет одержувача;

rst_all - відправити TCP-пакети зі встановленим прапором RESET на сокети хоста-відправника і одержувача;

icmp_net - повернути відправнику ICMP-повідомлення про недосяжність мережі (network unreachable);

icmp_host - повернути відправнику ICMP-повідомлення про недосяжність хосту (host unreachable);

icmp_port - повернути відправнику ICMP-повідомлення про недосяжність порту (роrt unreachable);

icmp_all - повернути відправнику всі три перерахованих вище ICMP-повідомлення.

Приклад правила:

alert tcp any any -> $HOME_NET 21 \

(msg: "Отримання файлу паролів FTP"; \

flags: A+; resp: rst_all; content: "passwd"; )

Приклад звіту про сеанс:

[rootiaverbo hping2-beta53]# ftp sparky

Connected to sparky.

220 sparky FTP server (SunOS 5. 7) ready.

Name (sparky: root): jsmith

331 Password required for jsmith.

Password:

230 User jsmith logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> cd /etc

250 CWD command successful.

ftp> get passwd

local: passwd remote: passwd

200 PORT command successful.

421 Service not available, remote server has closed connection

В попередньому правилі була задана у відповідь дія при спробі підключитися до FTP-серверу і отримати доступ до файлу паролів passwd. Snort намагається обірвати з'єднання на обох кінцях, оскільки була вибрана опція rst_all для параметра resp. Зверніть увагу на останній рядок FТР-сеансу. Зразу ж після того, як порушник ввів команду get passwd, з'єднання було розірвано. Але, на жаль, є вірогідність, що файл паролів був відправлений ще до розриву з'єднання.

Параметр tag

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

Формат:

tag: <тип> <кількість <показник> [напрям]

• Тип. Указує, пакети якого типу слід реєструвати.

  • Session - зберігати всі пакети, якими обмінюються учасники з'єднання;

  • host - зберігати тільки ті пакети, які поступають від хоста— відправника пакету, що викликав “спрацьовування” правила (необхідно використовувати модифікатор напрям).

• Кількість. Дозволяє визначити кількість одиниць, заданих за допомогою модифікатора показник.

• Показник. Визначає, в яких одиницях число вказано в модифікаторі кількість.

• расkets - зберегти <х> пакетів сеансу або відправлених з атакуючого хоста;

• seconds - зберегти пакети за <х> секунд після “спрацьовування” правила для даного сеансу або відправлених з атакуючого хосту;

• Напрям. Використовується тільки для типу host і указує, по якій IP-адресі (відправника або одержувача) слід вибирати реєстровані пакети.

  • scr - зберегти всі пакети з IP-адресою відправника, співпадаючою з IP-адресою відправника в пакеті, отримання якого привело до “спрацьовування” правила;

  • dst— зберегти всі пакети з IP-адресою одержувача, співпадаючою з IP-адресою одержувача в пакеті, отримання якого привело до “спрацьовування” правила.

Приклад правила:

alert tcp any any -> any 21 (msg: "FTP-доступ до файлу passwd"; flags: A+; \ content: "passwd"; tag: session, 10, расkets; )

Приклад звіту.

У файлі реєстрації попереджень збережені скорочені дані про потенційно небезпечне з'єднання через порт 21.

[**] FТР-доступ до файлу passwd [**]

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21

TCP TTL: 128 TOS: 0x0 ID: 50697 IpLen: 20 DgmLen: 58 DF

***AP*. * Seq: 0x17806739 Acк: 0xl21C07E5 Win: 0xlFD3 TcpLen: 20

Створюється каталог на ім'я 10.10.10.101 з файлом TCP:1454-21, в якому зберігаються звіти про всі операції, виконані під час сеансу з моменту спроби отримання файлу паролів (ще 10 подальших записів). Зверніть увагу на те, що, вказавши при запуску Snort в командному рядку параметр “-d”, можна зберегти всі корисні дані передаваних пакетів. Нижче приведений фрагмент такого звіту.

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21

TCP TTL: 128 TOS: 0x0 10: 50697 IpLen: 20 DgmLen: 58 DF

***AP*** Seq: 0x17806739 Acк: 0xl21C07E5 Win: 0xlFD3 TcpLen: 20

52 45 54 52 20 2F 65 74 63 2F 70 61 73 73 77 64 RETR /etc/passwd

0D 0A ..

*******************************************************************************************

03/21-20:31:05.610731 10.10.10.100:21 -> 10.10.10.101:1454

TCP TTL: 64 TOS: 0xl0 ID: 1752 IpLen: 20 DgmLen: 109 DF

***AP*** Seg: 0xl21C07E5 Acк: 0X1780674B Win:0x7D78 TcpLen: 20

31 35 30 20 4F 70 65 6E 69 6E 67 20 41 53 43 49 150 Opening ASCI

49 20 6D 6F 64 65 20 64 61 74 61 20 63 6F 6E 6E I node data conn

65 63 74 69 6F 6E 20 66 6F 72 20 2F 65 74 63 2F ection for /etc/

70 61 73 73 77 64 20 28 36 37 39 20 62 79 74 65 passwd (679 byte s)...

73 29 2E 0D 0A

*******************************************************************************************

< декілька пропущених записів>

*******************************************************************************************

03/21-20:31:08.924038 10.10.10.101:1454 -> 10.10.10.100:21

TCP TTL: 128 TOS: 0x0 ID: 52489 IpLen: 20 DgmLen: 58 DF

***AP*** Seq: 0x17806764 Acк: 0xl21C0860 Win: 0xlF58 TcpLen: 20

52 45 54 52 20 2F 65 74 63 2F 73 68 61 64 6F 77 RETR /etc/shadow

00 0A ..