Привет! Меня зовут Лев Палей, и я собаку съел на всяких сравнениях, технико-экономических обоснованиях и всей этой истории с выбором каких-либо решений. Теперь я работаю по другую сторону сделки. Поэтому, после некоторого времени, проведенного в компании-производителе, решил рассказать о тяготах выбора WAF, как историю из тех времен, когда сам был заказчиком и с учетом всякого нового, что начал понимать теперь. Раньше я не мог много об этом рассказывать (не было времени), а сейчас готов поделиться своим двусторонним опытом. Если перед вами стоит задача ........ велком под кат за подробностями.
Часть 1. Про мировые практики, защиту Web и прочую историю или где сейчас WAF?
Почему, зачем и что происходит?
В принципе, современную организацию сложно представить без использования в своей деятельности технологий, связанных с микросервисами, API и веб-приложениями. Драйверов для этого несколько: цифровизация деятельности, интеграция между сервисами, увеличение количества веб-инструментов, применяемых как в операционной деятельности, так и для продаж, развитие технологий удаленного доступа. Мало кто сейчас вспомнит, когда последний раз вызывал такси через диспетчерскую, времена, когда не было онлайн-магазинов или была необходимость стоять в театральные кассы за билетами. И это только то, что на поверхности. Постепенно все физические процессы перекочевывают в витринное, онлайн исполнение. Как снаружи, так и внутри любой инфраструктуры компании есть процессы сильно увязанные с целями и сутью бизнеса. Так, что при их остановке и сама компания на какое-то время может остановиться или замедлиться. Можно выделить несколько категорий таких ресурсов: мобильные приложения, веб-ресурсы, партнерские порталы, корпоративные порталы, системы Service Desk.
Новые возможности – это и новые риски, особенно с точки зрения информационной безопасности, ведь все эти ресурсы становятся неотъемлемой частью ИТ-инфраструктуры организации. Компрометация веб-ресурса может стать точкой входа злоумышленников в периметр организации, равно как и проникнув в ИТ-инфраструктуру организации можно получить доступ до опубликованным приложениям. И для разных компаний риск такого нарушения оценивается тоже по-разному (это как 7-й этаж, который как 6-й, но на этаж повыше).Поэтому прежде всего при атаке злоумышленнику будут больше всего интересны веб - и мобильные приложения, опубликованные наружу, а еще те уязвимости, которые могут нанести максимальный ущерб, при минимальных трудозатратах.
Сейчас миром правит концепция IaC (Infrastructure as Code) – суть которой в том, что основой всего становятся приложения, а всю что их поддерживает и сопровождает строится для большей функциональности, динамичности и устойчивости. Вспомните когда вы ходили на маркетплейс через браузер? Если он правда хороший, то он точно есть в виде приложения! То же самое происходит и с инфраструктурой – самые используемые функции принимают вид приложений. Логично, что и для тех, кто вас атакует будут больше всего интересный уязвимости компонент, лежащих в основе такой инфраструктуры – уязвимости в микросервисах и API.
Для защиты веб-приложений на рынке существует отдельный класс решений – WAF (web-application firewall). Этот класс решений позволяет предотвратить атаки на приложения на прикладном уровне. Для WAF условно выделяют три поколения, история которых длится уже более 20 лет:
Работа WAF первого поколения строилась на регулярных выражениях, на основе которых формировались паттерны, с которыми СЗИ сверяло анализируемый трафик. Этот подход имел несколько минусов: при появлении атак нового типа, регулярные выражения писались вручную, также имелся довольно высокий уровень ложных срабатываний и относительно легкий способ обхода этой защиты.
В WAF второго поколения появились парсеры, работающие со специальными токенами, описывающими запросы и отвечающие за выявление определенных видов атак. Использование этих парсеров снизило количество ложных срабатываний, ускорило работу системы, однако не решило проблемы, связанные с ручной настройкой системы при появлении новых видов атак.
Нынешнее, третье поколение, отличается появлением машинного обучения, что позволило автоматизировать реагирование на атаки без создания сигнатур вручную.
Немного цифр: в соответствии с экспертным анализом Anti-malware.ru, объем рынка безопасности приложений, в который входят и средства защиты веб-приложений, в российском сегменте в 2020 году составлял 6,2%, в то время как в 2022 г., в соответствии с анализом Центра стратегических разработок, доля этого рынка выросла до 9,3%. Подтвержденные данные по 2023 г. Пока отсутствуют, однако многие компании активно занимаются обеспечением информационной безопасности своих продающих инструментов, поэтому прогноз относительно рынка защиты веб-приложений самый оптимистичный.
Принцип работы WAF
Web Application Firewall по принципу работы аналогичен классическим межсетевым экранам, однако в отличии от них работает только на уровне L7. Для реализации своих функций и защиты веб-приложений, WAF устанавливается «в разрыв» между внешними ресурсами и защищаемым веб-приложением и анализирует HTTP/S трафик, проходящий через него. С одной стороны, остальные протоколы остаются без внимания со стороны СЗИ, однако большое количество способов обмена данными поверх HTTP весьма велико, а для детального разбора запросов во всем этом потоке, нужна немного другая логика, чем сигнатурный анализ зашитый в современных UTM\NGFW .
Подобная схема работы называется «обратный прокси-сервер», т.к. по принципу противоположна работе классических прокси-серверов. В процессе работы WAF анализирует HTTP-сообщения, основной частью которых являются POST и GET запросы, используемые для обмена данными. Отдельная задача - защита API, для этого в нужно уметь правильно работать со множеством используемых протоколов, как пример RESTful или GraphQL, форматов данных JSON или XML и токенов аутентификации.
WAF отслеживают и фильтруют трафик API, применяя правила и политики безопасности для предотвращения несанкционированного доступа, утечки данных или злоупотребления конечными точками API. Обнаруживая и блокируя вредоносные запросы, WAF помогают поддерживать целостность, конфиденциальность и доступность API и данных, которые они обрабатывают.
Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. https://t.me/WMXWAS
Комментарии (8)
isstoryteller Автор
07.12.2023 11:54Здесь пока первая часть статьи. Частично согласен и про Legacy и про микросервисы, только в разном контексте: если WAF для закрытия проблем, которые быстро не поправить - то первый вариант, если для включения в CI\CD на этапе тестов, для большей наблюдаемости - второй.
andrettv
07.12.2023 11:54Интересно посмотреть на перспективы WAF в контексте API. Задача WAF - противостоять инъекциям, но если не получается составить белый список разрешённых значений, то эта задача практически невыполнима: пытливые умы так или иначе найдут способ обойти чёрный. И если бичом WAF для web-приложений были ложноположительные срабатывания (Волки! Волки!), то для API им стали ложноотрицательные (что ещё хуже). При этом в OWASP Top 10 API Security этого года инъекции уже не вошли…
shai_hulud
Не получил ответ на вопрос "зачем вообще это все нужно".
Вот есть у меня web-приложение на GO, или даже много приложений на GO в кубере, балансировщик на HAProxy, наружу торчит 80 порт, запросы строго по спецификации. SQL-injection и другие OWASP TOP-10 отсутствуют.
Для чего мне могут понадобится обычный firewall и WAF?
Megakazbek
Непонятно, каким образом вы смогли гарантировать, что вам будут приходить только "запросы строго по спецификации" строго от добропорядочных клиентов, что у вас нет OWASP Top 10, что у вас нет и никогда не появится уязвимостей в серверной ОС, в фреймворке, в HAProxy и т.п.
shai_hulud
Приходить будут любые, обрабатываться только те которые есть в спецификации т.к. для других нет кода :)
В имозрительном примере их просто не сделали. В реальных проектах они поправлены, и проверены командой QA которые специализируются на это, не рокет саинс.
Они есть, будут итд. Но пока открыт только 80 порт уязвимость может быть в сетевом стеке ОС (шанс 0%, иначе всё уже было взломано по кругу), в HAProxy (шанс поменьше, но аналогично, тысячи сайтов уже были бы взломаны) и мой фреймворк и мой код. Тут я могу проверить и быть увереным в результате.
А вот еще один продукт в цепочке типа WAF это штука которая как миннимум бесполезна, а скорее сама содержит ошибки и уязвимости. Проверить ее нельзя. Чет исходников для предложенной системы не нашел.
Shaman_RSHU
Те, кто использовал log2shell в своих зависимостях (или даже не знал, что они есть в транзитивных записимостях) тоже думали, что защищены, но.. :)
Adgh
Есть с десяток веб-приложений, в числе которых легаси. Следить за ними полноценно просто дорого, дешевле взять WAF и отсечь разом море потенциальных CVE
shai_hulud
В статьях про WAF не пишут, что это для legacy и Web-приложений класса "Решето" (привет. Confluence). Даже тут написано про микросервисы и современную цифровизацию.