Еволюция на Web Application Firewall: от мрежови екрани до облачни защитни системи с машинно обучение

В нашето предишно съдържание за облачната тематика ние разказвахме, как да защитим ИТ ресурсите в публично облако и защо традиционните антивируси не са напълно подходящи за тези цели. В този пост ще продължим темата за облачната сигурност и ще говорим за еволюцията на WAF и какво е по-добре да изберем: хардуер, софтуер или облак. 

Какво е WAF

Над 75% от хакерските атаки са насочени към уязвимости на уеб приложения и сайты: такива атаки обикновено остават незабелязани от ИТ инфраструктурата и ИТ службите. Уязвимостите на уеб приложенията крият рискове от компрометиране и измама на акаунти и лични данни на потребители, пароли, номера на кредитни карти. Освен това, уязвимостите в уебсайта служат като точка на вход за злоумишленици в корпоративната мрежа.

Web Application Firewall (WAF) е защитен екран, който блокира атаки на уеб приложения: SQL инжекции, междусайтово скриптиране, дистанционно изпълнение на код, брутфорс и заобикаляне на удостоверяване (auth bypass). Включително атаки, използващи zero-day уязвимости. Приложния защитен екран осигурява защита, като извършва мониторинг на съдържание на уеб страници, включително HTML, DHTML и CSS, и филтрира потенциално злонамерени заявки по HTTP/HTTPS.

Какви бяха първите решения?

Първите опити за създаване на Web Application Firewall бяха направени още в началото на 90-те години. Известно е за минимум трима инженери, работили в тази област. Първият е професорът по компютърни науки Джин Спафорд от Университета Пердью. Той описва архитектурата на приложния защитен екран с прокси и през 1991 г. я публикува в книгата „Сигурност на UNIX на практика“.

Вторият и третият бяха специалистите по ИБ Уилям Чесвик и Маркус Ранум от Bell Labs. Те разработиха един от първите прототипи на приложни защитни екрани. Разпространението му бе извършено от компанията DEC — продуктът бе пуснат под името SEAL (Secure External Access Link).

Но SEAL не представляваше пълноценно WAF решение. Той бе класически мрежови защитен екран с разширена функционалност — възможността да блокира атаки на FTP и RSH. Поради тази причина първото WAF решение днес се счита за продукта на компания Perfecto Technologies (по-късно Sanctum). През 1999 година тя представи системата AppShield. По това време Perfecto Technologies разработваха решения за информационна сигурност за електронната търговия, а целевата аудитория на новия им продукт бяха онлайн магазините. AppShield можеше да анализира HTTP заявки и блокираше атаки на базата на динамични политики за информационна безопасност.

Приблизително по същото време с AppShield (през 2002 година) се появи и първият WAF с отворен код. Това беше ModSecurity. Той бе създаден с цел популяризиране на WAF технологиите и все още се поддържа от ИТ общността (ето неговия репозиторий на GitHub). ModSecurity блокира атаки срещу приложения, основавайки се на стандартен набор от регулярни изрази (сигнатури) — инструменти за проверка на заявки по шаблон — OWASP Core Rule Set.

В крайна сметка разработчиците успяха да постигнат целта си — на пазара започнаха да се появяват нови WAF решения, включително и изградени на база ModSecurity.

Три поколения — вече история

Прието е да се открояват три поколения WAF системи, еволюирали с развитието на технологиите.

Първо поколение. Работи с регулярни изрази (или граматики). Към него принадлежи ModSecurity. Доставчикът на системата изследва типовете атаки срещу приложения и формулира шаблони, които описват легитимни и потенциално злонамерени заявки. WAF сравнява с тези списъци и решава какво да прави в конкретната ситуация — да блокира трафика или не.

Пример за откритие на база регулярни изрази е споменатият вече проект Core Rule Set с отворен код. Друг пример е Naxsi, който също е с отворен код. Системите с регулярни изрази имат редица недостатъци, включително, когато му се наложи да открие нова уязвимост, администраторът трябва да създаде допълнителни правила ръчно. В случая с мащабна ИТ инфраструктура, правилата може да са няколко хиляди. Управлението на такова количество регулярни изрази е доста сложно, да не говорим, че тяхната проверка може да намали производителността на мрежата.

Също така, регулярните изрази имат доста висок процент на фалшиви срабатывания. Известният лингвист Ноам Чомски предложи класификация на граматиките, в която ги разделя на четири условни нива на сложност. Според тази класификация, с регулярни изрази могат да се опишат само правила на защитни стени, които не допускат отклонения от шаблона. Това означава, че злонамерените потребители могат лесно да "мамят" WAF от първо поколение. Един от методите за справяне с това е да се добавят в заявките към приложенията специални символи, които не засягат логиката на вредоносните данни, но нарушават сигнатурното правило.

Второ поколение. За да се преодолеят проблемите, свързани с производителността и точността на WAF, бяха разработени защитни стени от второ поколение. В тях се появиха парсери, които отговарят за откриването на строго определени типове атаки (на HTML, JS и т.н.). Тези парсери работят със специални токени, описващи заявките (например, variable, string, unknown, number). Потенциално вредоносните последователности токени се изнасят в отделен списък, с който WAF-системата регулярно се сверява. За първи път този подход беше демонстриран на конференцията Black Hat 2012 под формата на C/C++ библиотеки libinjection, която позволява откриването на SQL инжекции.

В сравнение с WAF от първо поколение, специализираните парсери могат да работят по-бързо. Въпреки това, те не решиха трудностите, свързани с ръчната настройка на системата при появата на нови вредоносни атаки.

Трето поколение. Еволюцията в логиката на откритие на третото поколение се състои в прилагането на методи за машинно обучение, позволяващи максимално приближаване на граматиката на откритие до реалната граматика на SQL/HTML/JS защитаваните системи. Тази логика на откритие е в състояние да адаптира машината на Тюринг за обхващане на рекурсивно изброими граматики. Освен това, преди задачата за създаване на адаптивна машина на Тюринг беше неразрешима, докато не бяха публикувани първите изследвания на невронни машини на Тюринг.

Машинното обучение предлага уникална възможност за адаптиране на всяка граматика, за да покрие всеки тип атака, без да е необходимо ръчно да се създават списъци със сигнатури, както беше необходимо при откритията от първо поколение, и без да се разработват нови токенизатори/парсери за нови типове атаки, като Memcached, Redis, Cassandra, SSRF, каквито изискваше методологията от второ поколение.

Обединявайки трите поколения логика за откритие, можем да начертаем нова диаграма, на която червеният контур представя третото поколение откritие (фиг. 3). Към това поколение принадлежи едно от решенията, които реализираме в облака съвместно с „Онсек“, разработчика на платформата за адаптивна защита на уеб приложения и API Валарм.

Сега в логиката за откритие се използва обратна връзка от приложението за самонастройка. В рамките на машинното обучение този цикъл на обратна връзка се нарича „подпомагане“. Обикновено има един или повече типа такова подпомагане:

• Анализ на поведението на отговора на приложението (пассивно)
• Сканиране/фаззинг (активно)
• Файлове с отчети/процедури за прихващане/капани (пост фактум)
• Ръчно (определя се от супервайзора)

В резултат на това логиката за откритие от трето поколение също решава важен проблем с точността. Сега е възможно не само да се избегнат фалшиви срабатывания и фалшиви отрицания, но и да се открият валидни истински отрицателни резултати, като откритие на използването на SQL команден елемент в контролния панел, зареждане на шаблони на уеб страници, AJAX заявки, свързани с JavaScript грешки и други.

По-нататък ще разгледаме технологичните възможности на различните варианти за реализация на WAF.

Хардуер, софтуер или облак – какво да изберем?

Един от вариантите за реализиране на защитни стени за приложения е „хардверно“ решение. Тези системи представляват специализирани изчислителни устройства, които компанията инсталира локално в своя дата център. Но в този случай трябва да се закупи собствено оборудване и да се платят пари на интегратори за неговата настройка и отстраняване на проблеми (ако компанията няма собствен ИТ отдел). В същото време всичкото оборудване остарява и излиза от употреба, поради което клиентите са принудени да заложат бюджет за обновяване на хардуера.

Друг вариант за инсталиране на WAF е софтуерна реализация. Решението се инсталира като добавка за определен софтуер (например, ModSecurity се настройва върху Apache) и работи на един и същ сървър с него. Обикновено, подобни решения могат да бъдат инсталирани както на физически сървъри, така и в облака. Недостатъкът им е ограничената скалируемост и поддръжка от страна на доставчика.

Третият вариант е настройка на WAF от облака. Такива решения се предоставят от облачни доставчици като услуга по абонамент. Компаниите не трябва да купуват и настройват специализирано оборудване, тези задачи са в ръцете на доставчика на услугата. Важно е да се отбележи, че съвременният облачен WAF не изисква миграция на ресурсите на платформата на доставчика. Сайтът може да бъде инсталиран навсякъде, дори на място.

Защо все повече компании се насочват към облачен WAF, ще обясним по-долу.

Какво може WAF в облака

От гледна точка на технологичните възможности:

• Доставчикът отговаря за актуализациите. WAF се предоставя по абонамент, затова за актуалността на обновленията и лицензите следи доставчикът на услугата. Актуализациите засягат не само софтуерното, но и хардуерното оборудване. Доставчикът обновява сървърния парк и се занимава с неговата поддръжка. Той също така отговаря за балансирането на натоварването и резервирането. Ако се случи отказ в работата на WAF сървъра, трафикът незабавно се пренасочва към друг сървър. Разумното разпределение на трафика позволява да се избегнат ситуации, когато защитната стена влиза в режим fail open — не се справя с натоварването и спира да филтрира заявките.
• Виртуален патчинг. Виртуалните пачове ограничават достъпа до компрометирани части на приложението до затварянето на уязвимостта от страна на разработчика. В резултат на това клиентът на облачния доставчик може спокойно да изчака официалните „пачове“, които доставчикът на софтуер ще публикува. Приоритет за доставчика на софтуер е да направи това максимално бързо. Например, в платформата „Валарм“ за виртуалното патчиране отговаря отделен софтуерен модул. Администраторът може да добавя персонализирани регулярни изрази за блокиране на злонамерени заявки. Системата позволява маркиране на определени заявки с флага „Конфиденциални данни“. Тогава параметрите им се маскират, а самите те не се предават извън работната зона на защитната стена.
• Вграден скенер за периметър и уязвимости. Това позволява самостоятелно да се определят мрежовите граници на ИТ-инфраструктурата, използвайки данни от DNS заявки и протокола WHOIS. След това WAF автоматично анализира работещите вътре в периметъра услуги и сервизи (извършва сканиране на портове). Защитната стена е в състояние да открива всички разпространени видове уязвимости — SQLi, XSS, XXE и др. — и да идентифицира грешки в конфигурацията на софтуера, например неразрешен достъп до репозитории в Git и BitBucket и анонимни запитвания към Elasticsearch, Redis, MongoDB.
• Атаките се наблюдават от ресурсите на облака. Обикновено облачните доставчици разполагат с големи обеми изчислителни мощности. Това позволява анализ на заплахите с висока точност и скорост. В облака се разгръща клъстер от филтриращи възли, чрез които преминава целият трафик. Тези възли блокират атаките на уеб приложения и изпращат статистика в Центъра за аналитика. Той използва алгоритми за машинно обучение, за да актуализира правилата за блокиране за всички защитени приложения. Реализацията на такава схема е показана на рис. 4. Подобни адаптирани правила за сигурност минимизират броя на фалшивите сработвания на защитната стена.

Сега малко за особеностите на облачните WAF от гледна точка на организационни моменти и управление:

• Преход към OpEx. В случай на облачни WAF разходите за внедряване ще бъдат нулеви, тъй като всичкото оборудване и лицензи са вече платени от доставчика, а плащането за услугата се извършва по абонамент.
• Различни тарифни планове. Потребителите на облачната услуга могат бързо да активират или деактивират допълнителни опции. Управлението на функциите се осъществява от единен контролен панел, който е също така защитен. Достъпът до него се осъществява през HTTPS, плюс наличието на механизъм за двуфакторна автентикация на базата на протокола TOTP (Алгоритъм за еднократни пароли с времеви обхват).
• Свързване по DNS. Можете сами да променяте DNS и да настройвате маршрутизацията в мрежата. За решаването на тези задачи не е необходимо да наемате и обучавате отделни специалисти. Обикновено техническата поддръжка на доставчика може да помогне с настройките.

WAF технологиите преминаха през еволюция от прости мрежови екрани с емпирични правила до сложни защитни системи с алгоритми за машинно обучение. В момента защитните стени на приложенията притежават широк спектър от функции, които бяха трудно реализируеми през 90-те години. В значителна степен появата на нови функционалности стана възможна благодарение на облачните технологии. WAF решенията и техните компоненти продължават да се развиват, както и другите области на информационната безопасност.

Текстът е подготвен от Александър Карпузиков, продуктов мениджър по развитие на облачния доставчик #CloudMTS.

Източник: habr.com