Еще 8 лет назад я изучил различные варианты внедрения WAF в инфраструктуру компании для защиты ее веб-ресурсов. Ни вендор, ни интегратор тогда не смогли мне толком ответить, каким образом правильнее интегрировать WAF под мои требования, только твердили "vendor-recommended design". В итоге пришлось делать все самому, причем на тот момент выбранный вариант шел вразрез с рекомендованным дизайном вендора (только через пару лет вендор изменил свой дизайн на тот, что выбрал я). Иногда я рассказываю на внешних или внутренних конференциях, как правильно выбрать архитектуру, отвечаю на возникающие вопросы, чтобы мой опыт пригодился и другим. Несколько дней назад я понял, что тема актуальна и до сих пор, поэтому решил написать эту статью.
Составлю эту статью в основном из скриншотов слайдов презентаций, с которой выступал на разных конференциях.
Вряд ли для кого-то это будет новостью, но дам вводное определение WAF своими словами:
Иногда можно услышать споры о том, что лучше использовать: WAF, IDS или IPS. name='more'> Ключевое отличие последних - в многопротокольности (что логично), а 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 можно закончить.
