Приклад. Preprocessor http_inspect_server: server 1.1.1.1 profile all роrts { 80 3128 }

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” символів. Цей елемент настройки заснований на інформації з https://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-атаками.