Параметр 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)