Баланс между запис и блокиране в WAF

Информатек Дигитал » Ресурси » Баланс между запис и блокиране в WAF

Намирането на правилния баланс между регистриране и блокиране в WAF се превърна в едно от най-често срещаните главоболия за екипите по сигурност и операции. Защитната стена на уеб приложението може да спре много сериозни атаки, но ако е конфигурирана твърде агресивно, тя може да блокира легитимни покупки, достъп или API извиквания. Ако е конфигурирана твърде свободно, тя се оказва почти чисто декоративна. Ключът е внимателно да се регулира кога да се регистрира, кога да се брои, кога да се разрешава и кога да се блокира.

В тази статия ще разгледаме как да постигнем този баланс, използвайки съвременните възможности на WAF (списъци с разрешени, правила, базирани на честота, режими на обучение, SIEM интеграция, машинно обучение и др.), подкрепени от конкретни примери от AWS WAF, ModSecurity, облачни WAF и локални решения . Ще видите как да ограничите фалшивите положителни резултати, без да намалявате нивото на защита, как да организирате политиките по приложение и как да използвате регистрирането като съюзник, а не като постоянен, неуправляем източник на шум.

Какво е WAF и защо регистрацията е толкова важна?

Защитната стена на уеб приложението действа като интелигентен слой между потребителя и сървъра , анализирайки HTTP/HTTPS трафика в реално време. За разлика от традиционната мрежова защитна стена, която следи портове и IP адреси, WAF задълбочава: URL адреси, параметри, тела на заявките, заглавки, бисквитки, HTTP методи и други.

Неговата мисия е да открива и спира типични атаки от ниво 7 : SQL инжекция, XSS, LFI/RFI, атаки срещу контрол на достъпа, злоупотреба с API, агресивно извличане на данни чрез груба сила (brute force) и дори определени DDoS модели на ниво приложение. За да направи това, той разчита на набори от правила, сигнатури и политики за сигурност, които се актуализират постоянно.

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

• Разследване на инциденти: реконструирайте какво се е случило и как е направен опит за използване на уязвимост.
• Коригиране на правилатаоткриване на фалшиви положителни резултати чрез проверка кои легитимни заявки блокира WAF.
• Спазвайте разпоредбите: демонстриране на наличието на активни контроли (PCI DSS, GDPR, вътрешни одити и др.).
• Хранене на SIEMсъпоставяне на атаки към приложения със събития в мрежата, системата, идентичността и др.

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

Модели за сигурност в WAF: списъци с блокирани, списъци с разрешени и хибриден подход

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

WAF, базиран на блок-листи, следва негативен модел на сигурност. Основният му принцип е: „Позволявам всичко, освен това, което знам, че е злонамерено.“ Той работи, като използва сигнатури на известни атаки (SQL инжекция, XSS, бот модели и др.) и правила, които определят какво се счита за подозрително. По-лесно е да се внедри първоначално, но разчитането единствено на този модел рискува да позволи на нови вектори или варианти на атака да се промъкнат незабелязано.

WAF с разрешен списък работи по обратния начин: „блокира всичко, освен това, което е изрично разрешено“. Той се основава на модел на позитивна сигурност. Приема се само трафик, който отговаря на дефинираното легитимно поведение – маршрути, методи, параметри, формати, размери и т.н. Много по-сигурен е, но изисква значителна фина настройка и може да генерира фалшиви положителни резултати първоначално , ако не е правилно подготвен.

Поради предимствата и недостатъците на всеки подход, хибридният модел, комбиниращ списъци с разрешени и блокирани адреси, става все по-често срещан . В този сценарий се дефинират очакваните профили на трафика (например, какво представлява нормално влизане или заявка за плащане) и едновременно се прилагат подписи и евристики за откриване на типични злонамерени модели. За целите на регистрирането, този хибриден подход позволява:

• Маркирай как събитие с висок риск това, което нарушава списъка с разрешени предмети.
• Третирай като сигнали със среден/нисък приоритет общи модели на блок-листи.
• Използвайте режима „броене“, за да видите какво би нарушило правилото, преди да активирате блока.

WAF в мрежа, на хоста и в облака: въздействие върху регистрирането и заключването

Моделът на внедряване на WAF силно влияе върху начина, по който се обработва регистрирането и блокирането на трафика. Регистрирането на заявки на мрежово устройство не е същото като регистрирането им на агент в сървъра или в управлявана облачна услуга.

Мрежово базирана WAF обикновено се разполага като физическо или виртуално устройство в рамките на инфраструктурата, между интернет и приложения. Това е класическият подход, използван от производители като F5. Той предлага предимството на висока производителност и детайлен контрол , но конфигурацията и управлението могат да бъдат сложни. Регистрацията обикновено се изпраща към syslog или централен SIEM и е важно внимателно да се филтрира какво се запазва, за да се избегне претоварване на инструментите за съхранение и анализ, както и да се диагностицират проблеми в IP и DNS мрежи.

WAF-овете, базирани на хост, работят на същите сървъри (или контейнери), където се намира приложението, обикновено като модул или агент (например, ModSecurity, интегриран в Nginx или Apache; комбинирането му с Linux hardening чрез SELinux подобрява сигурността). Този модел позволява по-голям контекст на приложението и силно специфични правила за всяка услуга, за сметка на консумация на локални ресурси и изискване за по-разпределено управление на лог файлове. Логовете могат да се съхраняват в локални файлове и след това да се препращат или да се интегрират с централизирани услуги за логване.

Облачните WAF -ове (Cloudflare, Akamai, Imperva Cloud, AWS WAF и др.) се интегрират с балансьори на натоварването, CDN или виртуални мрежи. Доставчиците обикновено предлагат табла за управление и експортиране на лог файлове към S3, BigQuery, отдалечени системни логове или SIEM. Те обикновено са по-лесни за настройване, но трябва да адаптирате правилата си за логване към модела на доставчика: типове събития, периоди на съхранение, филтри за тежест и др.

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

Условия, правила и уеб ACL: как WAF решава дали да блокира, разреши или само да регистрира

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

Условията описват коя част от заявката се проверява: IP адрес на източника, специфични HTTP заглавки (Host, User-Agent, Accept, Content-Type…), параметри на заявката, тяло на заявката , бисквитки, HTTP метод, държава на произход и др. Например, в AWS WAF Classic можете да дефинирате IP условие с до 10 000 адреса или диапазона или условие за съвпадение на низове на част от URL адреса.

Правилата комбинират едно или повече условия и им присвояват намерение: да разрешат, да блокират или да броят. Когато едно правило има множество условия, те обикновено се оценяват с логическо И : всички условия трябва да бъдат изпълнени, за да се задейства правилото. Нормално правило без условия на практика не съответства на нищо и действието му никога не се задейства.

Много WAF-ове, включително AWS WAF, също имат правила, базирани на скорост . Тези правила броят заявките, пристигащи от IP адрес (или набор от IP адреси, които отговарят на определени условия) през времеви прозорец, например пет минути. Ако бъде превишен праг – например 1.000 заявки за пет минути – правилото влиза в сила: блокиране или просто броене. Това е много полезно за:

• контрол груба сила върху формуляри за вход.
• Ограничете агресивното изтърсване или грубите ботове.
• Смекчаване на определени видове DDoS атаки на ниво приложение.

Следващото ниво е уеб ACL (Access Control List) . Тук правилата са групирани и са дефинирани ред на оценяване и действие по подразбиране (ALLOW или BLOCK). Заявката преминава през правилата по ред; ако съвпада с едно от правилата, се прилага неговото действие и оценяването на останалите се спира. Ако не съвпада с никое правило, се прилага действието по подразбиране, дефинирано в ACL.

По отношение на балансирането между регистрирането и блокирането, ACL е мястото, където решавате дали искате системата да бъде разрешителна по подразбиране (РАЗРЕШАВА и блокиране само по определени правила) или силно рестриктивна (БЛОКИРА, освен в изключителни случаи). Освен това, много решения ви позволяват да задавате правила в режим „броене“ в ACL, така че те регистрират съвпадения, но не блокират трафика – идеално за фазата на настройка.

Бели списъци и намаляване на шума в лог файловете

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

Например, в AWS WAF можете да създавате правила за списък с разрешени адреси, така че ако заявка идва от конкретен IP адрес или диапазон или ако съответства на известен URL шаблон и HTTP метод, определени проверки на подписите да не се прилагат. Това помага за:

• Предотвратете вътрешни API, които използват „странни“ модели генерира постоянни фалшиви положителни резултати.
• Намалете латентността, въведена от задълбочената проверка в трафика, който вече считате за надежден.
• Намалете обема на ненужните записи в WAF лог файловете.

На платформи като ModSecurity, препоръчителният подход не е да се променят стандартни правила (напр. OWASP Core Rule Set), а по-скоро да се създават специфични изключения по идентификатор на правило за определени параметри, пътища или потребители. Това ви позволява да поддържате цялостна защита, без да създавате огромни уязвимости чрез деактивиране на цели правила в целия сайт.

Ключът е да се направят списъците с разрешени адреси хирургически , а не универсален подход. Много по-добре е да се изключи конкретна комбинация (правило X + параметър Y в URL адрес Z), отколкото да се деактивира правило X глобално. По този начин записването в логовете остава полезно и не се създават ненужни слепи зони.

Правила и ограничения на протокола: кога да се блокира, кога да се предупреждава

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

Някои много често срещани примери:

• Липсващ заглавен файл за приемане (Липсващ заглавен файл Accept): Това не е строго нарушение на RFC, но много заявки без този заглавен файл идват от автоматизирани инструменти или лошо написани скриптове. Това може да повлияе на персонализирани API или клиенти, които не го изпращат. В много среди, регистрирането и броенето са за предпочитане пред пълното блокиране.
• Липсващ заглавен файл на хостаСъгласно стандартите HTTP/1.1, заглавката Host е задължителна. WAF-овете също се нуждаят от нея, за да определят коя политика да приложат. Блокирането тук обикновено е разумно, но може да генерира фалшиви положителни резултати по време на тестване или поради неправилно конфигуриран вътрешен трафик; препоръчително е да наблюдавате лог файловете, преди да активирате строго блокиране.
• Липсващ заглавен файл на потребителския агентТова правило се опитва да ограничи елементарните ботове и неидентифицирания трафик. Проблемът е, че много легитимни API-та може да не изпращат потребителски агент. Най-разумният подход обикновено е да се регистрира и, ако се открие последователен и легитимен API, добавяне на техния IP адрес или модел към списък с разрешени.
• GET/HEAD валидиране с тяло на командатаВъпреки че RFC не забранява стриктно изпращането на тялото с GET или HEAD заявки, това не е обичайна практика и може да показва опити за избягване. В много случаи първата стъпка е да се регистрират всички тези заявки и, ако се установи, че са подозрителни аномалии, да се продължи с блокирането им.
• Липсва тип съдържание с тялотоАко има тяло на елемента, но няма тип съдържание (Content-Type), това е ясен индикатор за неправилно използване на протокола или опит за избягване на анализ. В тези случаи обикновено е разумно да се използва по-агресивен подход към блокиране, особено в среди с интернет връзка.

В допълнение към тези протоколни правила, често се срещат ограничения на аргументите , които предпазват от наводнения на ниво приложение и DoS атаки. Например:

• Максимален брой аргументи на заявка (по подразбиране 255 в някои WAF-ове).
• Максимална дължина на отделен аргумент (например 400 знака).
• Общ комбиниран размер на всички аргументи (например 64 000 байта).

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

Фалшиво положителни резултати: как да ги открием и да не умрем, опитвайки се

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

Откриването на фалшиви положителни резултати започва с внимателен преглед на лог файловете . Това включва проверка на това кои заявки се блокират, кое правило ги задейства и контекста, в който се появяват (URL адрес, параметри, потребител, произход и др.). Визуалните инструменти и табла за управление могат да помогнат за идентифициране на пикове в грешките 403 или необичайни модели.

Силно препоръчителен подход, както от доставчиците на облачни услуги, така и от общността на ModSecurity, е използването на режим на симулация или броене . В този режим правилата, които искате да тествате, регистрират всяко съвпадение, но не блокират. Това ви позволява да видите например колко легитимни заявки би блокирало ново SQLi правило, преди да се осмелите да го активирате в производствена среда.

Добра идея е също така да тествате правилата в тестова или предпроизводствена среда , която получава реален или симулиран трафик. Инструменти като OWASP ZAP или скриптове за повторно възпроизвеждане на трафик могат да ви помогнат да симулирате легитимни модели и известни атаки, за да тествате поведението на WAF.

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

Стратегии за коригиране на правилата и интелигентно използване на системния регистър

Управлението на фалшиво положителните резултати не се свежда до изключване на правилата, докато „всичко не заработи“, а до фина настройка на WAF с хирургическа прецизност . Тук влизат в действие добри практики като следните:

Първо, избягвайте глобалното деактивиране на правилата. За предпочитане е да създавате много специфични изключения : изключвайте идентификатора на правилото само за определен маршрут, за определени параметри или за вътрешен трафик. По този начин ще останете защитени в останалата част от приложението и ще поддържате полезни регистрационни файлове.

Второ, възползвайте се от режима на броене, преди да блокирате. Активирането на нови правила първоначално само в режим на регистриране ви позволява да измерите колко легитимни заявки биха били засегнати. Можете да допълните това с предупреждения в SIEM, за да откриете бързо дали дадено правило генерира необичаен обем съвпадения.

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

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

Автоматизация, машинно обучение и адаптивни правила в WAF

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

Първо, интеграцията със SIEM ви позволява да изграждате правила за корелация и автоматизирани отговори : например, ако набор от IP адреси многократно задейства правила за инжектиране или XSS, можете да генерирате автоматично действие, за да добавите тези IP адреси към временен списък с блокирани адреси или да засилите нивото на проверка.

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

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

И накрая, непрекъснатото автоматизирано тестване (използвайки инструменти като OWASP ZAP, персонализирани скриптове или CI/CD конвейери) ви позволява да проверите дали промените в WAF не нарушават критична функционалност или не оставят очевидни уязвимости. Интегрирането на тези тестове в цикъла на внедряване прави сигурността естествена част от процеса на разработка, а не корекция в последния момент.

Дизайн на политики за всяко приложение и черни списъци за всяка услуга

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

Илюстративен пример е HTTP/S балансьор на натоварването, действащ като обратен прокси за множество сайтове (напр. www.company1.com и www.company2.com) зад един виртуален IP адрес. В този сценарий WAF може да бъде конфигуриран да оценява заглавката на хоста и IP адреса на източника веднага щом заявката пристигне, дори преди да достигне модула за балансиране на натоварването.

Логиката би била нещо подобно: WAF проверява дали комбинацията от SERVER_NAME (Host) и IP адрес на клиента съвпада със специфичен за сайта черен списък. Ако IP адресът е посочен като блокиран за www.company2.com, но не и за www.company1.com, отговор 403 Forbidden се изпраща само в първия случай. „Чистият“ трафик след това се предава на модула за балансиране на натоварването, който решава кой бекенд обслужва заявката.

Това позволява поддържането например на специфични за домейна черни списъци , вместо един глобален списък за цялата точка за достъп. На ниво регистриране всяко отхвърляне се записва в системния лог с подробности като идентификатора на правилото, съответстващото условие, URL адреса, хоста и IP адреса на клиента, което улеснява последващия анализ и разширяването или отстраняването на грешки в тези списъци.

Поуката от историята е, че колкото по-сегментирани са вашите политики (по приложение, по среда, по тип потребител), толкова по-фин баланс можете да постигнете между регистрирането и блокирането: можете да бъдете много стриктни на административните портали и малко по-гъвкави на информационните уебсайтове, например, винаги с доказателства в регистрационните файлове защо е взето всяко решение.

Отвъд класическия WAF: WAAP и API защита

Пейзажът от заплахи не е спрял. Днес много приложения са базирани на облак, използват микросървисни архитектури и предоставят достъп до публични и частни API , което ги прави основни цели за атакуващите. Традиционните WAF-ове са се развили в по-широки платформи, известни като WAAP (Web Application and API Protection - Защита на уеб приложения и API) или WAAS (Web Application & API Security - Сигурност на уеб приложения и API).

Тези решения не само автоматично откриват уеб приложения, но и идентифицират крайни точки на API , приемат спецификации като OpenAPI или Swagger и използват тази дефиниция, за да проверят съответствието на заявките: очаквани типове данни, разрешени параметри, ограничения на размера и др. В зависимост от крайната точка (например такава, която обработва силно чувствителни данни), може да се приложи много по-високо ниво на контрол и блокиране.

На ниво регистриране, WAAP е склонен да генерира богати на контекст събития : коя точно крайна точка на API е била атакувана, коя операция (GET, POST, PUT…), кой потребител или токен е бил замесен, коя част от спецификацията е била нарушена и т.н. Това позволява по-прецизни решения за блокиране, вместо да се разчита единствено на общи модели на полезен товар.

Освен това, много WAAP инструменти включват специфична за приложенията и API DoS защита, филтриране на геолокацията, управление на IP репутацията, откриване на ботове и извличане на данни, както и опции за персонализиране на нивата на предупреждения за всяка услуга. Отново става въпрос за гъвкавост да решите къде искате по-стабилен подход и къде искате да дадете приоритет на безпроблемната работа , без да жертвате солидна база данни с регистрационни файлове за разследване на инциденти.

Взети заедно, добре настроената WAF – независимо дали е класическа, базирана на WAAP или интегрирана в облачна екосистема – се превръща в съществен компонент на съвременната защита на приложенията и API, способна да комбинира детайлно регистриране, интелигентно блокиране и непрекъсната адаптация към променящия се пейзаж на заплахите.