Привет! Меня зовут Кирилл, и в центре киберзащиты DataLine я развиваю сервис защиты веб-приложений (WAF): общаюсь со специалистами по ИБ и ИТ от клиента, выясняю их задачи, отвечаю за корректную работу сервиса. За неполный год настройки WAF я убедился: если у вас есть сайт, его будут атаковать. И не всегда так, как вы думаете.
Мы несколько раз дорабатывали решение: лучше изучали векторы атак и поведение атакующих, добавляли и настраивали новые средства защиты, улучшали регламенты взаимодействия с клиентом. Расскажу, как развивался наш сервис на базе FortiWeb и о чем нужно позаботиться, чтобы защитить свое веб-приложение.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/e94/951/f65/e94951f652efdc4e578b966279a8baef.png)
Для собственных сайтов мы в свое время выбрали FortiWeb от Fortinet, уже знали тонкости работы с ним. Перед глазами был опыт WAF-as-a-service в облаке у Fortinet.
На Западе для WAF распространена модель селф-сервиса. Клиенту отдают выделенный инстанс для самостоятельной настройки в нужном облаке (AWS, Azure и GCP), естественно, не в РФ. У такой модели есть свои трудности:
Справиться с этими тремя пунктами могут крупные компании с большим штатом. Мы же хотели учесть запросы бизнесов поменьше. Таким клиентам предложили сервис «под ключ» под управлением наших инженеров. Начали собирать его с вопросов архитектуры.
Сервис разместили в облаке, соответствующем PCI DSS. Этот сертификат важен для сайтов, которые работают с платежными данными: ритейлеров, поставщиков услуг, процессинговых компаний.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/9f6/fad/621/9f6fad621c7fe9909b98e2adbbb94520.png)
Сервис WAF тоже попал в скоуп PCI DSS.
Отдельно продумали отказоустойчивость сервиса. Для FortiWeb вендор предусмотрел несколько вариантов кластера. Мы протестировали разные способы синхронизации сессий и остановились на режиме Active Backup: одна виртуальная машина FortiWeb остается главной и скидывает часть трафика на вторую. В этом случае при падении ноды недоступность сервиса не превышает 10 секунд. Настроили расположение машин так, чтобы они всегда поднимались на разных хостах.
Затем решили вопрос с разделением клиентов в облаке. FortiWeb не поддерживает мультитенантность: мы не можем сегментировать WAF на домены, как сделали с нашим NGFW-as-a-Service на базе FortiGate. Остается разделение с помощью политик. Если отдадим такие политики на откуп клиентам, есть риск повлиять на соседей. Поэтому наши ответственные за сервис инженеры по ИБ сами заводят клиентские сайты за WAF и следят за настройками сервиса. А для клиентов предоставляем отдельный инструмент с отчетностью и статистикой.
Поэтому сам сервис не ограничился только WAF, мы добавили к нему:
Расскажу чуть подробнее про каждый компонент.
Для поиска уязвимостей в коде сайтов мы добавили Qualys – решение для сканирования и анализа безопасности веб-приложений. У нас уже был развернут отдельный сервис сканирования уязвимостей, оставалось настроить его совместную работу с WAF.
Первый раз запускаем сканер до заведения сайта за WAF и отправляем отчет разработчикам приложения. Только после этого закрываем на WAF уязвимости, которые нельзя устранить на уровне кода.
Дальше мы настраиваем ежемесячное сканирование с отправкой отчета клиенту. А на будущее тестируем схему, где отчет будет сразу загружаться сразу на FortiWeb.
FortiWeb хорошо защищает от атак прикладного уровня, например: если веб-приложение будут атаковать с помощью большого числа GET-запросов, поможет DoS-Protection на WAF. Но в дополнение к нему нужно отдельное решение для DDoS-атак уровнем ниже, например, SYN-flood. У некоторых клиентов есть свой анти-DDoS, который мы интегрируем с нашим сервисом WAF. Но это, скорее, частный случай.
Для остальных случаев в сервисе появился Qrator.Ingress – решение для защиты инфраструктуры от DDoS-атак. Оно защищает канал с L2 по L4, анализирует и очищает трафик.
Мы создали 10-гигабитные стыки с Qrator, чтобы отправлять на WAF уже очищенный трафик через защищенный канал. Схема сервиса стала выглядеть так:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/b87/206/02f/b8720602f076595857a854caad63bdc4.png)
Инфраструктура клиента может жить где угодно, на любом хостинге. После заведения сайта за WAF на этот хостинг отправляется только проверенный сервисом трафик. Вот упрощенная схема, как это работает:
Что в итоге? Когда пользователь запускает браузер и обращается к ресурсу, защищенному WAF, его трафик по DNS сначала направляется в центры очистки в Qrator. Дальше по защищенному каналу трафик идет на WAF. И только после проверки пользователь получает доступ к веб-серверу клиента. Вот весь путь:
![](https://habrastorage.org/r/w1560/webt/6i/bl/xa/6iblxauytgrvuzpdk0c2-rzsmpw.png)
Но если даже сайт заведен за WAF, это еще не значит, что он защищен. Нужно настроить Web Protection Profile – набор правил и настроек защиты для сайта. Это делается отдельно под каждого клиента.
Ситуация с атаками такова, что настроить профиль один раз и забыть про него нельзя. Поэтому мы анализируем ситуацию на каждом сайте и улучшаем защиту: добавляем новые механизмы безопасности, корректируем профиль, чтобы не было ложных срабатываний. Для первоначальной настройки используем информацию, которую получили от сканера уязвимостей Qualys.
Администрирование сервиса со стороны наших инженеров включает настройку политик и – при необходимости – блокировку атак вручную. За это отвечают специалисты по FortiWeb, которые понимают нюансы защиты веб-сайтов. Но в то же время наши инженеры не могут знать всю логику работы клиентского приложения. Если будем сразу блокировать любую подозрительную активность, можем случайно заблокировать легитимного пользователя. Так что мы работаем в связке со специалистами клиента и вырабатываем совместную стратегию отражения атак.
Среди клиентов есть компании без больших подразделений по ИТ и ИБ. Разработку приложений для них часто выполняют аутсорсеры, так что исправление уязвимостей в коде занимает некоторое время. На WAF же можно предложить обходные пути и быстро нейтрализовать возникшие атаки. На этот случай мы разработали регламенты и прописали, когда считать ситуацию критичной и сразу принимать меры, а когда – согласовывать блокировки с клиентом.
Отслеживать критичные ситуации нам помогает мониторинг в связке с ELK. В прошлый раз мы уже рассказывали, как это устроено технически. ELK позволяет нам управлять информацией о безопасности без добавления в сервис дорогостоящей системы SIEM (Security information and event management).
На мониторинге мы настраиваем оповещения для немедленного реагирования. Первая линия поддержки работает круглосуточно, после оповещения сразу оценивает ситуацию по регламенту и действует на своем уровне, либо передает инцидент инженерам по безопасности.
В результате у нас получилось комплексное решение для защиты веб-приложений. Помимо защиты с помощью WAF можем настроить балансировку веб-серверов, кеширование, редиректы и, таким образом, разгрузить основной сайт.
На будущее мы заложили запас для масштабирования. Для балансировки подключим FortiADC – контроллер для доставки приложений и распределения нагрузки в высокопроизводительных системах. Он поддерживает SSL-разгрузку серверов и увеличивает производительность веб-приложений.
Сервис тарифицируется на основе пропускной способности и подходит для не очень тяжелых сайтов. Если же у клиента гигабиты трафика, то предлагаем уже не облачный сервис, а приватное решение. Чтобы сервис был прозрачен для клиентов, планируем выводить данные по WAF в их личный кабинет.
Если интересно узнать подробности, с удовольствием отвечу на вопросы в комментариях. Или регистрируйтесь на семинар по WAF 26 ноября – будет возможность задать вопросы не только нам, но и техническим специалистам Qualys, Fortinet и Qrator.
Мы несколько раз дорабатывали решение: лучше изучали векторы атак и поведение атакующих, добавляли и настраивали новые средства защиты, улучшали регламенты взаимодействия с клиентом. Расскажу, как развивался наш сервис на базе FortiWeb и о чем нужно позаботиться, чтобы защитить свое веб-приложение.
![](https://habrastorage.org/getpro/habr/post_images/e94/951/f65/e94951f652efdc4e578b966279a8baef.png)
Предыстория сервиса
Для собственных сайтов мы в свое время выбрали FortiWeb от Fortinet, уже знали тонкости работы с ним. Перед глазами был опыт WAF-as-a-service в облаке у Fortinet.
На Западе для WAF распространена модель селф-сервиса. Клиенту отдают выделенный инстанс для самостоятельной настройки в нужном облаке (AWS, Azure и GCP), естественно, не в РФ. У такой модели есть свои трудности:
- Специалист по ИБ на стороне клиента должен глубоко понимать особенности защиты веб-приложений.
- Специалисту клиента нужно знать возможности и настройки конкретного WAF, чтобы создать профили защиты. По-хорошему, для работы с WAF нужен отдельный инженер, чтобы постоянно вносить изменения в настройки.
- Ему нужно все время взаимодействовать с разработчиками сайта и решать, какие уязвимости закрывать на WAF, какие исправлять в самом коде. Все же WAF – это компенсирующая мера, и некоторые проблемы лучше решить на уровне разработки.
Справиться с этими тремя пунктами могут крупные компании с большим штатом. Мы же хотели учесть запросы бизнесов поменьше. Таким клиентам предложили сервис «под ключ» под управлением наших инженеров. Начали собирать его с вопросов архитектуры.
Сервис разместили в облаке, соответствующем PCI DSS. Этот сертификат важен для сайтов, которые работают с платежными данными: ритейлеров, поставщиков услуг, процессинговых компаний.
![](https://habrastorage.org/getpro/habr/post_images/9f6/fad/621/9f6fad621c7fe9909b98e2adbbb94520.png)
Сервис WAF тоже попал в скоуп PCI DSS.
Отдельно продумали отказоустойчивость сервиса. Для FortiWeb вендор предусмотрел несколько вариантов кластера. Мы протестировали разные способы синхронизации сессий и остановились на режиме Active Backup: одна виртуальная машина FortiWeb остается главной и скидывает часть трафика на вторую. В этом случае при падении ноды недоступность сервиса не превышает 10 секунд. Настроили расположение машин так, чтобы они всегда поднимались на разных хостах.
Затем решили вопрос с разделением клиентов в облаке. FortiWeb не поддерживает мультитенантность: мы не можем сегментировать WAF на домены, как сделали с нашим NGFW-as-a-Service на базе FortiGate. Остается разделение с помощью политик. Если отдадим такие политики на откуп клиентам, есть риск повлиять на соседей. Поэтому наши ответственные за сервис инженеры по ИБ сами заводят клиентские сайты за WAF и следят за настройками сервиса. А для клиентов предоставляем отдельный инструмент с отчетностью и статистикой.
Поэтому сам сервис не ограничился только WAF, мы добавили к нему:
- сканер уязвимостей от Qualys,
- защиту от DDoS от Qrator,
- ELK для сбора статистики, визуализации и анализа данных.
Расскажу чуть подробнее про каждый компонент.
Сканируем сайты на уязвимости
Для поиска уязвимостей в коде сайтов мы добавили Qualys – решение для сканирования и анализа безопасности веб-приложений. У нас уже был развернут отдельный сервис сканирования уязвимостей, оставалось настроить его совместную работу с WAF.
Первый раз запускаем сканер до заведения сайта за WAF и отправляем отчет разработчикам приложения. Только после этого закрываем на WAF уязвимости, которые нельзя устранить на уровне кода.
Дальше мы настраиваем ежемесячное сканирование с отправкой отчета клиенту. А на будущее тестируем схему, где отчет будет сразу загружаться сразу на FortiWeb.
Разбираемся с очисткой трафика
FortiWeb хорошо защищает от атак прикладного уровня, например: если веб-приложение будут атаковать с помощью большого числа GET-запросов, поможет DoS-Protection на WAF. Но в дополнение к нему нужно отдельное решение для DDoS-атак уровнем ниже, например, SYN-flood. У некоторых клиентов есть свой анти-DDoS, который мы интегрируем с нашим сервисом WAF. Но это, скорее, частный случай.
Для остальных случаев в сервисе появился Qrator.Ingress – решение для защиты инфраструктуры от DDoS-атак. Оно защищает канал с L2 по L4, анализирует и очищает трафик.
Мы создали 10-гигабитные стыки с Qrator, чтобы отправлять на WAF уже очищенный трафик через защищенный канал. Схема сервиса стала выглядеть так:
![](https://habrastorage.org/getpro/habr/post_images/b87/206/02f/b8720602f076595857a854caad63bdc4.png)
Инфраструктура клиента может жить где угодно, на любом хостинге. После заведения сайта за WAF на этот хостинг отправляется только проверенный сервисом трафик. Вот упрощенная схема, как это работает:
- У нас есть «белая» подсеть, которую мы анонсируем в канал с Qrator.
- Мы выделяем клиенту 1 новый IP-адрес из этой подсети .
- На WAF создаем для сайта политики Server Policy и HTTP Content routing, добавляем туда доменные имена и указываем, куда их направлять.
- FortiWEB терминирует на себе TLS-соединения, так что подгружаем цепочку сертификатов на него.
- Затем просим клиента изменить DNS-запись сайта и для нужных доменных имен указать в ней IP-адрес из сети Qrator’а.
Что в итоге? Когда пользователь запускает браузер и обращается к ресурсу, защищенному WAF, его трафик по DNS сначала направляется в центры очистки в Qrator. Дальше по защищенному каналу трафик идет на WAF. И только после проверки пользователь получает доступ к веб-серверу клиента. Вот весь путь:
![](https://habrastorage.org/webt/6i/bl/xa/6iblxauytgrvuzpdk0c2-rzsmpw.png)
Но если даже сайт заведен за WAF, это еще не значит, что он защищен. Нужно настроить Web Protection Profile – набор правил и настроек защиты для сайта. Это делается отдельно под каждого клиента.
Ситуация с атаками такова, что настроить профиль один раз и забыть про него нельзя. Поэтому мы анализируем ситуацию на каждом сайте и улучшаем защиту: добавляем новые механизмы безопасности, корректируем профиль, чтобы не было ложных срабатываний. Для первоначальной настройки используем информацию, которую получили от сканера уязвимостей Qualys.
Работаем в команде: изучаем атаки с клиентом
Администрирование сервиса со стороны наших инженеров включает настройку политик и – при необходимости – блокировку атак вручную. За это отвечают специалисты по FortiWeb, которые понимают нюансы защиты веб-сайтов. Но в то же время наши инженеры не могут знать всю логику работы клиентского приложения. Если будем сразу блокировать любую подозрительную активность, можем случайно заблокировать легитимного пользователя. Так что мы работаем в связке со специалистами клиента и вырабатываем совместную стратегию отражения атак.
Среди клиентов есть компании без больших подразделений по ИТ и ИБ. Разработку приложений для них часто выполняют аутсорсеры, так что исправление уязвимостей в коде занимает некоторое время. На WAF же можно предложить обходные пути и быстро нейтрализовать возникшие атаки. На этот случай мы разработали регламенты и прописали, когда считать ситуацию критичной и сразу принимать меры, а когда – согласовывать блокировки с клиентом.
Отслеживать критичные ситуации нам помогает мониторинг в связке с ELK. В прошлый раз мы уже рассказывали, как это устроено технически. ELK позволяет нам управлять информацией о безопасности без добавления в сервис дорогостоящей системы SIEM (Security information and event management).
На мониторинге мы настраиваем оповещения для немедленного реагирования. Первая линия поддержки работает круглосуточно, после оповещения сразу оценивает ситуацию по регламенту и действует на своем уровне, либо передает инцидент инженерам по безопасности.
Что в итоге, и как это будет развиваться дальше
В результате у нас получилось комплексное решение для защиты веб-приложений. Помимо защиты с помощью WAF можем настроить балансировку веб-серверов, кеширование, редиректы и, таким образом, разгрузить основной сайт.
На будущее мы заложили запас для масштабирования. Для балансировки подключим FortiADC – контроллер для доставки приложений и распределения нагрузки в высокопроизводительных системах. Он поддерживает SSL-разгрузку серверов и увеличивает производительность веб-приложений.
Сервис тарифицируется на основе пропускной способности и подходит для не очень тяжелых сайтов. Если же у клиента гигабиты трафика, то предлагаем уже не облачный сервис, а приватное решение. Чтобы сервис был прозрачен для клиентов, планируем выводить данные по WAF в их личный кабинет.
Если интересно узнать подробности, с удовольствием отвечу на вопросы в комментариях. Или регистрируйтесь на семинар по WAF 26 ноября – будет возможность задать вопросы не только нам, но и техническим специалистам Qualys, Fortinet и Qrator.