Andrey Dugin @blog: Внедрение 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 с проксированием). По сути, с точки зрения сети это очень умный и очень дорогой кабель: