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

Дата: 23.04.2021. Автор: Андрей Дугин. Категории: Блоги экспертов по информационной безопасности
Внедрение WAF. Взгляд архитектора

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

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

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

data-original-height=847

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

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

data-original-height=859

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

data-original-height=853

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

data-original-height=861

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

data-original-height=851


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

data-original-height=863
Пропускная способность в мегабитах защищаемых ресурсов замеряется с помощью MRTG/Cacti:
data-original-height=863
Количество новых TLS-handshake в секунду наиболее точно мне удалось посчитать, используя показатели установки новых TCP-сессий на firewall:
data-original-height=865
Количество одновременных соединений, которые должен уметь держать WAF, можно приблизительно рассчитать по такой формуле:

data-original-height=849
Рассмотрим возможные варианты архитектуры внедряемого решения:

data-original-height=843

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

data-original-height=861

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

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

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

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

data-original-height=865
Действий тоже немного, если сервер один. Главное — не навредить:

data-original-height=867
То, что модуль устанавливается на сервер, имеет как плюсы, так и минусы:

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

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

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

data-original-height=871
Reverse proxy имеет свои плюсы и минусы:
data-original-height=867
Следующий вариант — router. Довольно редкий случай для WAF в моей практике, но рассмотреть стоит, хотя бы для общего развития. 
Вариант, когда в каждый DMZ-сегмент ставим по экземпляру WAF:
data-original-height=867
И вариант, когда оба DMZ-сегмента защищаем одним WAF-router'ом:
data-original-height=865

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

data-original-height=869

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

data-original-height=851
Следующий вариант архитектуры — прозрачный режим bridge (если не выполняем терминацию трафика и скрытое проксирование) либо transparent reverse proxy (если делаем MITM с проксированием). По сути, с точки зрения сети это очень умный и очень дорогой кабель:
data-original-height=863
Кабель кабелем, а кое-какие изменения нужны:
data-original-height=847
У режима bridge есть свои плюсы-минусы:
data-original-height=853
У transparent reverse proxy — свои:
data-original-height=853
На что еще стоит обратить внимание при работе с WAF (некоторые пункты дублируются):
data-original-height=871

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

Источник — Блог Андрея Дугина «Практическая информационная безопасность и защита информации».

Андрей Дугин

Об авторе Андрей Дугин

Блог "Практическая информационная безопасность и защита информации" Андрея Дугина
Читать все записи автора Андрей Дугин

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *