Привет, Хаброжители! Приложение, запущенное в облаке, обладает множеством преимуществ, но в то же время подвержено особенным угрозам. Задача DevOps-команд — оценивать эти риски и усиливать защиту системы от них. Книга основана на уникальном опыте автора и предлагает важнейшие стратегические решения для защиты веб-приложений от атак, предотвращения попыток вторжения. Вы увидите, как обеспечить надежность при автоматизированном тестировании, непрерывной поставке и ключевых DevOps-процессах. Научитесь выявлять, оценивать и устранять уязвимости, существующие в вашем приложении. Автор поможет ориентироваться в облачных конфигурациях, а также применять популярные средства автоматизации. Требуется знание Linux и владение стандартными практиками DevOps, такими как CI, CD и модульное тестирование. Отрывок. Глава 8. Анализ журналов для выявления вторжений и атак
В этой главе:
- Изучение компонентов уровня анализа в конвейере журналирования.
- Выявление вторжений и атак с помощью строковых сигнатур, статистики и исторических данных.
- Управление способами оптимального уведомления пользователей.
Из главы 7 вы узнали, как составить конвейер журналирования, который собирает, передает, анализирует и хранит журналы из всей инфраструктуры, а также предоставляет доступ к ним. Многоуровневый конвейер создает гибкую инфраструктуру, в которой журналы из различных источников используются для наблюдения за активностью сервисов организации. В главе 7 был представлен обзор функциональностей, обеспечиваемых всеми уровнями конвейера. В этой главе мы сосредоточимся на третьем уровне — уровне анализа — и погрузимся в техники и примеры кода, связанные с обнаружением вторжений и атак на сервисы.
Конвейер журналирования, используемый в Mozilla во время написания книги, подобен показанному в главе 7. Конвейер используется для наблюдения за состоянием клиентов Firefox (что называется телеметрией), работающих в естественной среде, обработки журналов приложений и сервисов, а также выявления необычной активности. Логический центр конвейера находится на уровне анализа, составленного из множества небольших программ, которые постоянно ищут что-то необычное. Эти небольшие программы не настолько продвинутые, чтобы иметь дело с вводом и выводом событий журналов, поэтому они передают эту задачу выделенному центру обработки данных — программе Hindsight (http://mng.bz/m4gg), предназначенной для выполнения работы анализирующих плагинов на потоках данных.
В этой главе мы будем использовать Hindsight для чтения различных типов журналов и написания оригинальных плагинов для их анализа.
ПРИМЕЧАНИЕ
Примеры журналов и плагинов для этой главы расположены в securing-devops.com/ch08/logging-pipeline. Нужно скопировать этот репозиторий на свою локальную машину и получить Docker-контейнер Hindsight для того, чтобы запускать примеры.
Начнем с описания того, как скомпонованы различные части уровня анализа: Hindsight расположена посередине, а уровни сбора и хранения — по обеим ее сторонам. Затем поговорим о трех различных подходах к выявлению вторжений и атак. Для самого простого из них используются строковые сигнатуры, которые содержат сведения об известных атаках, чтобы отправлять уведомления. Далее сравним статистические модели и подход с подписями, а также узнаем, как эти два подхода дополняют друг друга. И наконец, взглянем на способы применения исторических данных пользовательской активности для того, чтобы выявлять подозрительные области среди соединений.
Последний раздел главы посвящен отправке уведомлений. Вряд ли вы захотите каждый день получать от уровня анализа тысячи уведомлений, которые будут создавать много шума, вместо того чтобы приносить пользу. Если этого не изменить, получатели станут расценивать уведомления как спам и проигнорируют их. В завершающем разделе этой главы мы рассмотрим наилучшие приемы организации отправки уведомлений, а также обсудим способы точной и действенной передачи уведомлений администраторам и конечным пользователям.
8.2. Выявление атак с помощью строковых сигнатур
Когда вы работаете с журналами, вы работаете со строками. А это значит, что самым простым способом выявления признаков недобросовестной активности будет сравнение журналов со списком известных вредоносных строк. Это может показаться простым, но именно этим годами занималась индустрия поставщиков в сфере безопасности. Межсетевые экраны веб-приложений (WAF), так популярные в середине 2000-х, по сути, были хранилищем регулярных выражений, соответствие которым проверялось в каждом запросе, отправляемом в веб-приложение.
Не полагайтесь на регулярные выражения
Некогда я работал на банк, в котором широко пользовались этим типом средств защиты. Команда, обеспечивающая безопасность, отвечала за поддержку WAF, которые защищали различные онлайн-сервисы, включая торговый сервис для клиентов. Каждый веб-запрос, передаваемый этому сервису, проходил через сотни регулярных выражений перед тем, как попасть на сервер приложения. Однажды разработчик из команды сервиса онлайн-торговли решил взглянуть на эти регулярные выражения. Я не в курсе, что подвигло инженера начать читать содержание файла, заполненного в основном слешами, символами доллара, звездочками, плюсами, квадратными и круглыми скобками, но он за это взялся. И где-то на 418-й строке в сложном регулярном выражении он нашел подозрительную комбинацию «.+». Два невинных символа, которые позволяли абсолютно всему безболезненно проходить дальше: это регулярное выражение аналогично значению «разрешить всё».
Наша гордость — межсетевой экран веб-приложения за несколько тысяч евро, поддерживаемый целой командой, выполнял сотни проверок соответствия регулярным выражениям, влияя на производительность и усложняя проектирование и без того сложной системы, и все для того, чтобы беспрепятственно все пропускать. Конечно, мы вскоре исправили проблему, но моя вера в применение регулярных выражений для обеспечения безопасности с того времени так и не воспряла. Если хотите реализовать этот тип системы защиты в своей организации, учтите всю его сложность, чтобы подобного с вами не случилось.
При правильном использовании регулярные выражения могут стать мощным инструментом, но их невероятно сложно писать, поддерживать со временем — еще сложнее, а их масштабная реализация стоит дорого. Взгляните на регулярное выражение ((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>). Вы не догадаетесь, для чего оно используется, поэтому я вам скажу: с его помощью можно искать инъекции в строках HTTP-запросов, выявляя наличие открывающих и закрывающих символов неравенства < > и их содержимого. Этот тип строк HTTP-запроса вы будете получать от атакующего, который пытается внедрить вредоносный код JavaScript в ваше приложение, чтобы в итоге получилась атака межсайтового выполнения сценариев, о которой мы говорили в главе 3.
Это регулярное выражение можно использовать для выявления подозрительных запросов, которые содержат попытки инъекции. В листинге 8.7 показан пример анализатора, который реализует это, проверяя наличие в каждом из переданных журналов доступа NGINX соответствий регулярному выражению. Регулярное выражение хранится в локальной переменной xss, ее значение сравнивается с каждым значением Fields[request] с помощью функции rex.match().
Если обнаружены соответствия, то с помощью функции add_to_payload() отправляется уведомление, которое плагин вывода может получить и передать в место назначения.
Листинг 8.7. Плагин, который обнаруживает сообщения журналов, содержащих признаки атаки в строке запроса
Пример вывода этого плагина показан в листинге 8.8. Там генерируются несколько уведомлений по образцам журналов, часть из которых оказались ложноположительными. Отчасти так произошло потому, что образцы журналов были искусственно созданы с помощью сканера уязвимостей ZAP, а также потому, что строкам запроса не свойственно содержать теги HTML. В частности, у этого регулярного выражения не будет слишком высокого показателя нахождения ложноположительных соответствий.
Листинг 8.8. Примеры уведомлений, сгенерированных плагином XSS-анализа
Это всего лишь одно регулярное выражение для одного специфического типа атак. Чтобы такой подход приносил пользу, нужно найти нечто большее, чем регулярные выражения. Вы могли бы для начала собирать подписи от различных источников и по мере нахождения все большего количества подозрительных признаков в журналах постепенно увеличивать объем своей базы данных.
В листинге 8.9 показана модифицированная версия XSS-анализатора, которая ищет различные признаки атак (http://mng.bz/62h8). Этот скрипт показывает, как можно использовать таблицы Lua для хранения списка признаков и циклически использовать его для анализа входящих событий. В этом примере кода таблица suspicious_terms представляет собой простой ряд строк, который для поиска вместо регулярных выражений применяет подстроки, что работает намного быстрее. В таблице suspicious_terms используется формат «ключ — значение» для хранения меток вместе с выражением, чтобы иметь возможность напоминать о том, что данное выражение должно найти.
Листинг 8.9. Поиск признаков атак с помощью строк и выражений
Вы можете запустить этот анализатор с помощью тестовых настроек, описанных в начале главы. Запустите Docker-контейнер с монтированными каталогами, и вывод анализатора будет записан в output/payload/analysis.suspicious_signatures.alerts.txt. Плагин отправит тысячи уведомлений, что ожидаемо, так как эти журналы формируются сканером уязвимостей ZAP. Такой подход можно считать успешным, но у него есть недостатки, о которых вам стоит поразмышлять.
- Регулярные выражения сложно писать, а читать еще сложнее. Вы будете делать ошибки, которые нелегко исследовать и которые потребуют часов болезненной отладки. В этом анализаторе лишь четыре регулярных выражения, но читать эту часть кода уже тяжело. Насколько бы мощным и привлекательным инструментом ни были регулярные выражения, я бы не рекомендовал работать с ними постоянно.
- При таком подходе генерируется слишком много уведомлений. Веб-приложения, открытые для Интернета, получают много необычного трафика, вредоносного и не очень. Генерирование уведомлений для каждого необычного признака сведет с ума любую команду по безопасности в течение нескольких недель, даже если показатель ложноположительных результатов будет низким. Аномальный трафик — это естественное явление для сервисов, работающих в Интернете.
Вы могли бы исправить обе эти проблемы, применив математический подход и сделав эту совершенную систему выявления аномалий чуть менее совершенной. В следующем разделе мы рассмотрим, как использовать статистические методы для отправки уведомлений при преодолении некоего порога в качестве способа уменьшения шума со стороны логики обнаружения аномалий.
Об авторе
На момент написания книги Джульен Вехен управляет командой системы безопасности операций в Firefox, Mozilla. Он отвечает за формирование, реализацию и эксплуатацию стратегии защиты веб-сервисов, с которыми миллионы пользователей Firefox взаимодействуют ежедневно. Джульен сконцентрировался на защите сервисов в сети в начале 2000-х годов. Он начинал работать системным администратором в Linux, а в 2007 году получил диплом магистра по информационной безопасности.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — DevOps
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
