Хабрахабр

Всё дело в комбинации: история системы безопасности одного сайта

Один из заказчиков, очень крупный интернет-магазин, как-то попросил нас обеспечить защиту веб-приложения от веб-атак. Учитывая масштабы ресурса, мы начали поиск нужного подхода. В результате решили применить комбинацию позитивной и негативной модели безопасности, реализовав её с помощью файрвола для веб-приложений (в данном случае в качестве WAF использовался продукт F5 ASM, но в целом подход универсальный для большинства WAF). Многие компании не любят пользоваться позитивной моделью, поскольку очень опасаются (и зачастую справедливо), что для части пользователей ресурс может оказаться недоступным и продажи снизятся, да ещё и придётся потратить массу времени на настройку политик. Однако без этого защита веб-ресурса не будет полноценной.

Что такое позитивная и негативная модель?

Негативная модель безопасности, наверное, самое простое, что может быть в WAF-е. С точки зрения логики работы, конечно же. Сама настройка может быть весьма нетривиальной. Описать негативную модель можно принципом «что не запрещено — то разрешено». Обычно это набор политик безопасности и сигнатур, которые содержат описание известных атак. Полагаться исключительно на такой подход по понятным причинам нельзя: всегда будет целая куча атак, под которые не написаны политики или сигнатуры. Однако и пренебрегать такой моделью тоже не стоит, т.к. она является первым рубежом обороны, особенно когда у вас еще нет готовой позитивной модели или она находится в процессе построения.

Работает эта модель по принципу: «что не разрешено — то запрещено». Позитивная модель безопасности описывает структуру веб-ресурса со всеми возможными ограничениями. В основу позитивной модели безопасности ложатся URL, параметры и методы. Отклонения от этой модели должны блокироваться. Создать такую модель для крупного сайта – задача не из легких. Причем позитивную модель можно настроить очень жестко, например, для каждого URL описать, какие методы можно для нее использовать, какие параметры, описать допустимые значения этих параметров, с каких URL можно на нее переходить. Также следует учитывать, что гарантировать абсолютную корректность построенной модели вам не сможет никто. А если сайт еще и меняется каждую неделю-две, поддерживать выстраданную и вылизанную модель в актуальном состоянии непросто. Отсюда делаем вывод, что позитивная модель – это, конечно, хорошо и безопасно, но с доступностью ресурса могут возникнуть проблемы. А это значит, что абсолютно нормальные пользовательские запросы вполне могут быть заблокированы. Следовательно, для крупных и быстро меняющихся придется ее ослаблять в угоду доступности. Жестко определенная позитивная модель жизнеспособна только для небольших нечасто меняющихся ресурсов. Но об этом чуть позже.

А вот если комбинировать оба решения, уже можно получить приемлемый уровень как безопасности, так и доступности ресурса. В итоге мы получаем, что использование только одной из этих моделей имеет существенные недостатки: для негативной модели это невысокий уровень безопасности, для позитивной – возможные проблемы с доступностью веб-ресурса.

Разработка системы защиты

Вот как выглядит недельное среднестатистическое распределение по видам атак на интернет-магазин заказчика (на основе срабатывания негативной модели):

Начали с негативной. Как вы, наверное, уже поняли, мы решили не отступать от классического подхода к защите веб-приложения и создать гибрид позитивной и негативной модели. Сигнатуры могут быть как системонезависимыми, так и предназначенными под определенный тип системы (IIS, Apache, MySQL, MSSQL и т.п.). В F5 ASM большой набор сигнатур, доступных из коробки – достаточно выбрать подходящие группы из списка. Например, если у вас IIS на Windows, нет особого смысла назначать сигнатуры группы Linux, если только вы не хотите избавиться от всех мусорных запросов, идущих в сторону веб-сервера, даже если они и не могут никак навредить. Назначать все сигнатуры подряд нецелесообразно – это только повысит нагрузку на WAF и может привести к появлению дополнительных ложных срабатываний.

Например, мы столкнулись с ситуацией, когда разработчики включили в название нескольких URL слово «shell» (в контексте «бампер» или «чехол»). Сигнатуры — относительно точный метод, однако иллюзий можете не испытывать: избежать ложных срабатываний всё равно не получится. Обработав ложные срабатывания, настроив исключения для одних случаев или отключив сигнатуру в принципе – для других, мы получили базу для защиты сайта. Для таких случаев, естественно, придется настраивать исключения. Пренебрегать такой защитой мы, конечно же, не стали. Чуть не забыл: помимо сигнатур, WAF’ы могут валидировать веб-запросы на соответствие RFC, что позволяет заблокировать всякий мусор и некорректно сформированные HTTP-запросы.

На сайте больше 10 тыс. А вот чтобы найти подход к позитивной модели безопасности, нам пришлось изрядно попотеть. Самой первой и самой безумной мыслью было построить полноценную позитивную модель с полным перечнем URL, однако мы довольно быстро поняли нецелесообразность такого подхода. разнообразных URL. А до того, как мы это поняли, мы успели попробовать получить этот список автоматически.

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

Да, чтобы элемент попал в позитивную модель, он должен встретиться не в одном веб-запросе, а также прийти с разных адресов. Но не всякий Machine Learning одинаково полезен. Также не забываем про URL и параметры с динамическими элементами. Но в итоге получается все равно довольно приличное количество мусора, который нужно чистить. У нас после автоматического обучения получилось как раз нечто такое, необслуживаемое. Их может быть очень много, и они могут сделать позитивную модель необслуживаемой. Усугублялось все тем, что ежедневно на веб-ресурс добавлялось/удалялось от нескольких десятков до сотни URL и система просто не успевала так быстро вносить изменения.

Перечень URL, полученных таким способом, мы загружали по API. Вторая попытка получить список URL автоматически заключалась в чтении sitemap.xml, который в свою очередь содержал ссылки на страницы с необходимым нам, как мы тогда думали, содержимым. Однако и этот список не оказался полным. Он был довольно велик.

Вместо этого решили прибегнуть к другому подходу — защите, основанной на параметрах, в которых передаются как пользовательские, так и какие-то внутренние данные. После проведенных экспериментов мы скрепя сердце решили отказаться от белого списка URL, чтобы не плодить кучу срабатываний политики в случае отсутствия URL в заданном списке. С учетом того, что от «белого списка» URL мы отказались, параметры решили защищать без привязки к конкретному URL. Наибольшее число атак осуществляется как раз через параметры. В используемом в данном проекте WAF’е такая возможность есть за счет использования концепции Global Parameters.

Обычно, правда, так мало кто делает. Проблема может возникнуть, если на разных URL есть параметры с одним и тем же именем, но содержащие разные типы данных. Но если столкнулись с подобной проблемой, придется определить эти параметры для каждого URL в отдельности и указать для них разные допустимые значения.

Так же мы исходили из того принципа, что через параметры, которые могут содержать исключительно число-буквенные значения без спецсимволов, атаковать крайне проблематично. В случае с интернет-магазином, который мы защищали, сработало скорее правило, чем исключение, и если на разных страницах встречались параметры с одинаковым именем, то они содержали данные одного типа. Таким образом, если появляется параметр, содержащий спецсимвол, мы добавляем его в список. И поэтому в список защищаемых параметров, поместили только те, которые содержат спецсимволы, все остальные описали как «*». Для всех остальных параметров действует ограничение: они должны содержать только число-буквенные значения.

Такую модель уже вполне можно обслуживать. В итоге получилось около 300—400 параметров. И совершенно зря. После того как эта модель стабилизировалась, и число ложных срабатываний снизилось до приемлемой величины, наступил следующий этап, который многие игнорируют в связи с натянутыми отношениями между подразделениями. Этот шаг может существенно повысить качество построенной модели. Крайне желательно согласовать полученную модель с разработчиками веб-приложения заказчика. Тратить время на ознакомление разработчиков с интерфейсом WAF’а мы не стали. В нашем случае со стороны заказчика работали довольно толковые специалисты, которые, несмотря на высокую занятость, пошли нам навстречу. Файл передается разработчикам, они ищут нужный параметр у себя в словарике и корректируют допустимые значения в случае необходимости. Вместо этого написали простенький скрипт на Python, который парсит политику WAF в формате XML и на выходе дает csv-файл с перечнем параметров и разрешенными для них спецсимволами.

Например, вводимые пользователями комментарии, особенно когда заказчик не хочет ограничивать пользователей. Одна из проблем позитивной модели безопасности заключается в том, что некоторые параметры сложно как-либо ограничить. Ну и конечно, такие параметры нужно дополнительно тщательно проверять на стороне самого web-сервера. В этом случае для защиты таких параметров придется пользоваться услугами негативной модели безопасности, проверяя пользовательский ввод на наличие известного вредоносного кода.

Например, в поле ввода названия города пользователь пишет «{f,fhjdcr» вместо «Хабаровск». Еще одна особенность, с которой приходится сталкиваться, – ошибки ввода пользователя. он нарушает допустимые значения параметра, в котором могут быть только число-буквенные значения. В итоге его запрос должен быть заблокирован, т.к. Но не всех заказчиков может устраивать подобная реакция WAF, и в этом случае придется ослаблять позитивную модель в угоду функциональности. Казалось бы, ничего страшного: пользователь ошибся – пользователь поплатился.

Далее начинается довольно нудный процесс актуализации. В итоге мы получили комбинированную систему, сочетающую в себе обе модели. C каждым выходом патчей или релизов позитивная модель может меняться, новые ложные срабатывания могут возникнуть как у одной, так и у другой модели.

До этого момента WAF, конечно, работает, генерируя события безопасности, но не повышает безопасность веб-ресурса и никак не влияет на пользовательскую активность. Ну а после этого начинается самый ответственный этап — включение блокирующего режима.

Не хватало волевого решения, которое бы позволило двинуться дальше. В нашем случае в связи со сложностью согласований на стороне заказчика процесс включения блокирующего режима сильно затянулся. Поэтому мы в течение достаточно длительного промежутка времени просто актуализировали существующие модели.

Введение в эксплуатацию

Наконец, заказчик решился, но выдвинул ряд довольно жестких требований.Количество ложноположительных срабатываний должно быть минимальным, а доступность сайта – максимальной. Требование, конечно, отличное, но сложно реализуемое на практике. При этом каких-либо количественных метрик для выполнения этих требований нам не предоставили. В среднем число web-запросов в день находилось в диапазоне 100-150 млн.

раз в неделю, что дает цифру около 20 тыс. Как ранее было показано на рисунке, в среднем негативная модель срабатывала порядка 100-150 тыс. Большинство из этих срабатываний — действительно атаки, в подавляющем числе случаев автоматизированные. срабатываний в день. Сразу оговорюсь: все 20 тыс. Исходя из наших наблюдений, количество ложных срабатываний в процентном соотношении было в не больше 5%. Все запросы с адреса атакующего просматривать нет смысла, достаточно двух-трёх. запросов в день мы не просматривали, однако настоящие атаки достаточно легко отсеиваются при анализе IP-адресов атакующих.

срабатываний в день. Позитивная модель давала еще порядка 50 тыс. запросов приходилось анализировать. По большей части они дублировали алерты негативной модели, и такие срабатывания можно было легко выкинуть из анализа, однако около 20 тыс. В нашем случае WAF группировал срабатывания по спецсимволам, а дальше по параметрам, в которых этот спецсимвол встречался. И здесь уже много зависит от того, как WAF может группировать срабатывания, упрощая анализ. Если они были с большого диапазона IP, это признак того, что тревога могла быть ложной. Далее все более-менее просто: смотрим комбинацию, параметр – спецсимвол, для которого было наибольшее количество срабатываний. В большинстве случаев удается без посторонней помощи понять, атака это, ошибка ввода пользователи или недостаток позитивной модели. А дальше анализируем примеры запросов. После завершения анализа массовых срабатываний переходим к анализу единичных срабатываний. В случае спорных ситуаций не стоит брезговать общением с разработчиками (если, конечно, такая возможность имеется). По завершению анализа получаем от 5 до 10% ложных срабатываний, что в совокупности с ложными срабатываниями негативной модели дает до 6000 ложных срабатываний или 0,005% от общего количества запросов. Их, как правило, сложнее анализировать, особенно в самом начале, когда не знаешь специфики работы приложений. Важная ремарка: это совсем не означает, что работа 6000 пользователей будет парализована. Эта цифра уже не отпугивает – она в итоге и устроила заказчика. Просто при переходе на некоторую страницу или при вводе некоторых данных пользователь будет перенаправлен на страницу с ошибкой, после чего он сможет продолжить нормально взаимодействовать с web-ресурсом.

Решили вводить систему защиты в эксплуатацию поэтапно. Итого: цифры получены и они устраивают заказчика, однако не будет лишним перестраховаться, особенно, если на этом настаивает сам клиент. Трафик там вполне боевой, регионы периодически меняются и есть города/области-миллионники. Для тестового включения блокировки нам был любезно предоставлен макрорегион,, на котором заказчик тестирует свои новые релизы и патчи. А далее включаем блокировку, но тоже не сразу, а только для негативной модели. Копируем существующую политику и применяем ее к макрорегиону. После этого включаем блокировку на основе негативной модели для всего сайта, тоже смотрим неделю, меряем показатели. Тестируем в течение недели – количество ложных срабатываний не превысило расчетного значения. Может показаться, что все прошло подозрительно гладко, но не забываем, что этому предшествовал длительный этап актуализации моделей, который и позволил нам включить защиту достаточно безболезненно. Далее проделываем тот же фокус с позитивной моделью: сначала включаем блокировку для макрорегиона, неделю-две смотрим на результаты и включаем блокировку для всего сайта.

Можно выделить группу внутренних сотрудников, которые так же будут обращаться к ресурсу через WAF и включить блокирование только для этой группы пользователей. Что делать, если нет полноценной тестовой зоны (тестовый макрорегион в нашем случае)? Да, такое тестирование менее полноценное, но все же лучше, чем ничего.

Многие заказчики не готовы ждать достаточное время для формирования качественной позитивной модели, либо не желают/не имеют возможности ее актуализировать. По итогам можно признать, что WAF это либо небыстро, либо некачественно. Есть еще те, кто целиком и полностью полагаются на автоматическое построение позитивной модели, в итоге она получается далекой от идеала. В связи с этим они либо отказываются от позитивной модели, либо оставляют ее на произвол судьбы, не включая блокирование. К настройке WAF нужно подходить основательно. Оба таких подхода не способны обеспечить полноценной защиты. Затраченное время того стоит.

Андрей Черных, эксперт Центра информационной безопасности «Инфосистемы Джет»

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть