Выбрать язык


Выбрать язык | Show only


Русский | English


суббота, 24 апреля 2021 г.

Внедрение WAF. Взгляд архитектора

Еще 8 лет назад я изучил различные варианты внедрения WAF в инфраструктуру компании для защиты ее веб-ресурсов. Ни вендор, ни интегратор тогда не смогли мне толком ответить, каким образом правильнее интегрировать WAF под мои требования, только твердили "vendor-recommended design". В итоге пришлось делать все самому, причем на тот момент выбранный вариант шел вразрез с рекомендованным дизайном вендора (только через пару лет вендор изменил свой дизайн на тот, что выбрал я). Иногда я рассказываю на внешних или внутренних конференциях, как правильно выбрать архитектуру, отвечаю на возникающие вопросы, чтобы мой опыт пригодился и другим. Несколько дней назад я понял, что тема актуальна и до сих пор, поэтому решил написать эту статью. 

Составлю эту статью в основном из скриншотов слайдов презентаций, с которой выступал на разных конференциях.

Вряд ли для кого-то это будет новостью, но дам вводное определение WAF своими словами:


Иногда можно услышать споры о том, что лучше использовать: WAF, IDS или IPS. Ключевое отличие последних - в многопротокольности (что логично), а WAF - в глубине и вариативности анализа веб-протоколов. Недавно обратили мое внимание на то, что WAF не используется на выходе из сети в Интернет. Абсолютная правда, хотя я никогда не акцентировал на этом внимание, ибо см. слайд с определением: WAF защищает конкретные ресурсы на входе из Интернет (и/или от рабочих станций, если в организации принят подход Zero Trust), и его невозможно использовать как прокси-сервер явного либо неявного типа при серфинге Интернета. В то же время, NGFW и IPS свои функции выполнят в направлении любого сетевого сегмента.


Нельзя сказать, что WAF необходимо использовать для всех ресурсов, потому что это может быть финансово нецелесообразно, но для некоторых (почти всех) он необходим:



Зачем необходимо использовать WAF, думаю, знают все, но, тем не менее, не ответить на этот вопрос я не мог, ибо обоснование бюджета зачастую требует более веских аргументов, чем экспертиза сотрудника:


Зачем еще нужен WAF организациям, обрабатывающим данные платежных карт, ответит PCI DSS. Привожу выдержку из актуальной на тот момент версии 3.2 (поиск в более актуальных версиях оставлю вам в качестве тренировки):


Список OWASP Top10 на момент составления презентации был таким. Сверка с актуальной версией - тоже на усмотрение читателя:


На этом краткий экскурс на тему "зачем нужен WAF" окончен, но вопрос ценообразования этого решения тоже немаловажен:




Пропускная способность в мегабитах защищаемых ресурсов замеряется с помощью MRTG/Cacti:



Количество новых TLS-handshake в секунду наиболее точно мне удалось посчитать, используя показатели установки новых TCP-сессий на firewall:



Количество одновременных соединений, которые должен уметь держать WAF, можно приблизительно рассчитать по такой формуле:




Рассмотрим возможные варианты архитектуры внедряемого решения:



Приведу для примера упрощенную схему для небольших организаций и территориально-распределенную - для крупных. Далее все варианты буду рассматривать на территориально-распределенной.




Начнем с самого простого варианта, который не влияет на сервис, но и толком не защищает, только алармит:



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



Краткие преимущества и недостатки описаны. Не указана проблема с расшифровкой HTTPS при использовании DH:



Следующий вариант архитектуры - программный модуль, устанавливаемый на веб-сервер:



Действий тоже немного, если сервер один. Главное - не навредить:



То, что модуль устанавливается на сервер, имеет как плюсы, так и минусы:



Следующий вариант - reverse proxy. Один из наиболее распространенных вариантов, по этой схеме работает преобладающее количество облачных сервисов WAF.



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



Приведу пример, описывающий территориально-распределенную схему и произведенные изменения. Можно использовать как примитивный checklist.



Reverse proxy имеет свои плюсы и минусы:



Следующий вариант - router. Довольно редкий случай для WAF в моей практике, но рассмотреть стоит, хотя бы для общего развития. 
Вариант, когда в каждый DMZ-сегмент ставим по экземпляру WAF:




И вариант, когда оба DMZ-сегмента защищаем одним WAF-router'ом:



Какие необходимо внести изменения:


И плюсы-минусы архитектуры:



Следующий вариант архитектуры - прозрачный режим bridge (если не выполняем терминацию трафика и скрытое проксирование) либо transparent reverse proxy (если делаем MITM с проксированием). По сути, с точки зрения сети это очень умный и очень дорогой кабель:



Кабель кабелем, а кое-какие изменения нужны:





У режима bridge есть свои плюсы-минусы:




У transparent reverse proxy - свои:




На что еще стоит обратить внимание при работе с WAF (некоторые пункты дублируются):





На этом краткое описание топологических вариантов внедрения WAF можно закончить. 
Надеюсь, материал был полезен.

Комментариев нет:

Отправить комментарий