Pull to refresh
87.53
Rating
Pentestit
Информационная безопасность

Защита сайта от атак с использованием Nemesida WAF: от сигнатур до искусственного интеллекта

Pentestit corporate blog Information Security *


В статье будет рассмотрены практики защиты уязвимого веб-приложения — от сигнатурного метода до искусственного интеллекта с использованием Web Application Firewall (коммерческая и Opensource версии). В качестве коммерческого решения мы будем использовать Nemesida WAF, в качестве некоммерческого — NAXSI. Статья содержит общую и техническую информацию по работе WAF, а также сравнение методов обнаружения атак, разбор их особенностей и недостатков.

Детектирование атак


Первая и основная задача любого WAF — максимально точно определить атаку с минимальным количеством ложных срабатываний (false positive). В NAXSI заложен только сигнатурный механизм определения атак (поведенческий анализ находится в начальном состоянии, поэтому мы его считать не будем), в Nemesida WAF — три: сигнатурный, качественный поведенческий анализ и машинное обучение. Говоря о комплексном методе определения атак мы подразумеваем симбиоз этих трех методов. Почему три? Давайте разберемся.

Сигнатурный метод определения атак


Несмотря на стремительное развитие технологий, большая часть атак выявляется сигнатурным методом, и от того, насколько качественно пишутся сигнатуры, зависит точность работы всех методов, построенных на базе сигнатурного анализа (в том числе машинное обучение). Рассмотрим пример определения атаки на веб-приложение сигнатурным методом:

index.php?id=-1'+union+select+1,2,3,4,5+--+1

В данном случае сигнатурой атаки будет вхождение цепочки «union+select».

Пример атаки, которую пропустит NAXSI:

index.php?id=-1'+Union+Select+1,2,3,4,5+--+1

NAXSI пропустит такую атаку, поскольку при обработке запроса из-за ошибки в коде не учитывается первая буква «стоп слова», указанная в верхнем регистре, и запрос не подходит под сигнатуры «union» и «select».

NAXSI пропустит прямое обращение для получения версии СУБД:

id=version();+--+

Это касается и других служебных функций — «CURRENT_USER()», «DATABASE()», «ROW_COUNT()» и других. NAXSI не преобразует (не нормализует) «URLENCODED» данные или бинарные строки для сравнения с базой сигнатур, поэтому такие атаки тоже будут пропущены:

id=concat_ws%23%0a(0b00111010,database%0b(%0b),database%09(%09)
id=1 anD 0 unio%6e %23def%0a sELEc%74%23zxc%0a

И такие атаки тоже пропустит:

Пример 1: <iframe/onload='this[«src»]=«javas cript:al»+«ert``»';>
Пример 2: <img/src=q onerror='new Function`al\ert\`1\``'>

Стоит отметить, что сигнатуры NAXSI учитывают не все современные методы маскировки пейлода и требуют значительной доработки. А учитывая регулярные выражения по синтаксису MySQL команд есть немалая вероятность внести в белый список (при ложных срабатываниях) кучу «опасных вхождений», например:

MainRule "rx:select|union|update|delete|insert|table|from|ascii|hex|unhex|drop" "msg:sql keywords" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1000;

False Positive


Для того, чтобы свести количество ложных срабатываний к нулю, необходимо точно выставлять уровень угрозы для каждой сигнатуры (скоринг). Рассмотрим правило с неверным скорингом (на примере операторов «order» и «by»), приводящий к появлению ложных срабатываний:

The New World Order is a book written by H. G. Wells

Причина False Positive в примере выше — высокий скоринг вхождения операторов MySQL без учета применимости и зоны запроса.

А вот пример правила с верным скорингом (вхождение цепочки):
index.php?id=1+order+by+10+--+

Сигнатурный анализ: выводы


1. Для разработки сигнатур нужны высокие компетенции и понимание того, как работает злоумышленник. У нас такими знаниями обладают сотрудники отдела анализа защищенности.
2. Сигнатуры должны постоянно обновляться
3. Использование сигнатур без специализированной обработки (поведенческого анализа) приведет к ложным срабатываниям (False Positive).

Даже с точным и полным набором правил сигнатурный метод выявления атак имеет 2 основных недостатка, которые приведут или к появлению ложных срабатываний, или вовсе пропустят атаку:

  1. False positive в случае, если сигнатурный метод выявит вхождение операторов «union» и «select» в URI будет иметь высокий скоринг, что приведет к ошибочному блокированию запроса: /weareunion/sub/select_your_choice.php
  2. False negative в случае, если сигнатура или цепочка сигнатур атаки, имеет низкий скоринг, но позволяет получить «чувствительную» информацию: some.php?size=version%28%29%20;%20-

Чтобы устранить оба недостатка, потребуется расширенная модель определения атак — поведенческий анализ и машинное обучение.

Поведенческий анализ


Перейдем сразу к практике:

Запрос 1: index.php?id=1
Запрос 2: index.php?id=3-2
Запрос 3: index.php?id=-1
Запрос 4: index.php?id=1'
Запрос 5: index.php?id='1
Запрос 6: index.php?id=1 and sleep(5)


В этом примере мы видим попытку выявления SQL-инъекции путем манипуляции параметров, добавления символа кавычки и функции «sleep». Сами по себе эти разрозненные признаки не содержат явного вектора атаки, но их совокупность явно дает понять, что злоумышленник пытается «прощупать» веб-приложение. Математическая модель суммирует признаки поведения пользователя за период времени и на основании этого происходит блокировка, что позволяет не пропустить начало атаки, при этом запросы легитимных посетителей сайта не блокируются.

Искусственный интеллект


Машинное обучение (Machine Learning) — обширный подраздел искусственного интеллекта, изучающий методы построения алгоритмов, способных обучаться. Различают два типа обучения:

  • обучение по прецедентам, или индуктивное обучение, основанное на выявлении общих закономерностей по частным эмпирическим данным
  • дедуктивное обучение, предполагающее формализацию знаний экспертов и их перенос в компьютер в виде базы знаний. Дедуктивное обучение принято относить к области экспертных систем, поэтому термины машинное обучение и обучение по прецедентам можно считать синонимами.

Говоря простыми словами, мы используем весь накопленный опыт (как в области защиты веб-приложений, так и опыт тестирования на проникновения) для построения основы обучающейся модели, то есть используем дедуктивное обучение.

Дополнительный источник атак — лаборатории тестирования на проникновение


В 2013 году была запущена первая лаборатория тестирования на проникновение «Test lab», представляющая собой копию реальной корпоративной сети виртуальной компании, содержащая распространенные уязвимости и ошибки конфигурации. За 4 года разработки лабораторий их концепция не изменилась, изменились только ее размеры. Последние лаборатории представляют собой распределенные сети головного офиса и филиалов, а количество узлов увеличилось до 50 единиц (сервера, рабочие станции, сетевое оборудование etc). В отличие от CTF упор в «Test lab» сделан на реалистичность, а действия атакующих идентичны действиям внешнего нарушителя, что позволило собрать вокруг «Test lab» боле 18 000 участников.

Для нас лаборатории стали не только «just for fun», но и отличным полигоном для отладки и улучшения работы Nemesida WAF. Только представьте — 40-50 Мбит\с трафика «чистых» атак, которые нужно без задержек обработать и отфильтровать.

Nemesida WAF


Являясь компанией, предоставляющей услуги и решения в области практической ИБ — тестирование на проникновение, анализ защищенности и т.д., обладая качественной базой поиска уязвимостей (в 8 из 10 пентестов завершаются получением доступа к критичным данным), мы сделали Nemesida WAF — систему комплексного выявления атак на основе искусственного интеллекта, точно выявляющую и блокирующую атаки на веб-приложения с практически 0% ложных срабатываний.

Личный кабинет








Nemesida WAF предоставляется или в виде облачного сервиса (когда трафик до защищаемого приложения проходит через защищаемый модуль, расположенный в нашей инфраструктуре), или в виде Standalone-решения (когда WAF устанавливается в инфраструктуре клиента).
Tags:
Hubs:
Total votes 33: ↑31 and ↓2 +29
Views 8.5K
Comments Comments 6

Information

Founded
Location
Россия
Website
www.pentestit.ru
Employees
11–30 employees
Registered