об авторе
Юэ Лян, старший инженер по безопасности отдела информационной безопасности Ctrip. Присоединился к Ctrip в 2015 году, в основном отвечая за тестирование на проникновение, проверку безопасности и разработку продуктов безопасности.
1. Предпосылки
В истории развития обнаружения атак веб-приложений до сих пор это в основном механизм обнаружения черных списков, который опирается на правила.Будь то брандмауэр веб-приложения или идентификаторы и т. Д., Он в основном полагается на встроенную регулярность обнаружения. Engine для сопоставления пакетов. Хотя он может противостоять большинству атак, мы считаем, что у него есть следующие проблемы:
1. Поддержание базы правил затруднено, передача персонала затруднена, и даже по прошествии длительного времени автору оригинала трудно понять правила, написанные в начале. трудно изменить его онлайн.
2. Правила слишком широки, и их легко убить по ошибке, и слишком тонко, чтобы их можно было обойти.
Например, обычный оператор для обнаружения SQL-инъекций выглядит следующим образом:
Stringinj_str = "'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";
Нормальный комментарий «Рубашка, которую я купил в Selected, грязная», был убит.
3. Штатный движок серьезно влияет на производительность, особенно когда регулярных записей слишком много.Например, мы уже сталкивались с явлением серьезного накопления трафика, которое можно обнаружить в кафке.
Так как же решить вышеуказанные проблемы? Особенно в крупных интернет-компаниях, как быстро и точно идентифицировать запросы вредоносных атак среди массовых запросов, стало для нас сложной проблемой.
В последнее время большое внимание уделяется применению машинного обучения в информационной безопасности, мы считаем, что машинное обучение можно использовать везде в области информационной безопасности, где требуется обработка данных, анализ и прогнозирование. В этой статье будет представлена практика машинного обучения отдела информационной безопасности Ctrip в идентификации веб-атак.
Во-вторых, внедрение архитектуры системы обнаружения вредоносных атак.
Рисунок 1: Первая версия архитектуры системы обнаружения атак Ctrip nile
Прежде всего, давайте кратко представим первоначальную архитектуру системы обнаружения атак Ctrip nile.Как показано на рисунке 1 выше, прежде чем трафик попадет в механизм правил (здесь имеется в виду обычный механизм сопоставления), мы используем белый список, чтобы отфильтровать более 97% обычного трафика (мы думаем, например, http://ctrip.com/flight?Search?key=value, если в значении параметра значения нет английских знаков препинания и управляющих символов, это «нормальный трафик», а еще есть экспорт ip трафика Ctrip и т.д.).
Остальные 3% трафика проходят через обычный движок правил, если результат черный (злонамеренная атака), он будет отправлен в систему автоматической проверки уязвимостей hulk (о введении hulk см. https://zhuanlan .zhihu.com/p/28115732), например, вызовите sqlmap, чтобы воспроизвести трафик и повторно проверить, действительно ли злоумышленник может успешно атаковать.
В настоящее время мы улучшили систему nile до пятого издания.Архитектура показана на рисунке 2 ниже.Самое важное изменение заключается в том, что механизм машинного обучения spark добавлен перед механизмом правил.В настоящее время библиотека spark mllib используется для моделирование и прогнозирование. Если движок машинного обучения черный, он будет по-прежнему передаваться обычному движку правил для повторной проверки.
Рисунок 2: Последняя версия архитектуры системы обнаружения атак Ctrip nile
Это дает следующие преимущества:
1. Скорость обработки машинного обучения относительно высока, и оно может отфильтровывать большую часть трафика, а затем перебрасывать его в обычный движок. Решена проблема, из-за которой регулярная регуляризация приводила к серьезному накоплению кафки в прошлом (даже у 3% исходного трафика была такая проблема).
2. Вы можете сравнить результаты обычного движка и движка машинного обучения, чтобы проверить недостатки друг друга. Например, мы можем найти обычные ложные негативы или ложные срабатывания и вручную изменить или дополнить существующую обычную библиотеку. Если машинное обучение ложноположительно, белый трафик идентифицируется как черный, первое, о чем следует подумать, — это не чистый ли черный образец, а второе — проблема с выделением признаков.
3. Что делать, если машинное обучение занижает отчеты? Согласно процессу на рис. 2, мы понятия не имеем, что мы пропустили. Самая прямая идея состоит в том, чтобы сопоставить механизм машинного обучения и обычный механизм, чтобы проверить и заполнить пробелы, но это противоречит предпосылке нашего стремления к эффективности.
В последней версии мы добавили динамический черный список IP-адресов, сосредоточив внимание на IP-адресах с высоким риском, которые были поражены несколько раз в течение временного окна, и напрямую игнорируя белый список шторма. На практике мы позаимствовали эту часть черного ip-трафика для дополнения наших обучающих выборок (более 99% черного ip-трафика — трафик атак), нашли реферер, ua-инъекцию и т. д., и прочие логические атаки. обход порядка и т.д.
Некоторые люди могут спросить, в соответствии с приведенной выше структурой, если другая сторона атакует вас с новым POC атаки и атакует вас только один раз, разве это невозможно обнаружить? Во-первых, если в poc еще много специальной английской пунктуации и чувствительных слов, мы все равно можем это обнаружить, а в другом случае, если она действительно пропущена, что нам делать? новые регулярные выражения и добавляем их в логику обнаружения. Как показано на рисунке 2, мы добавили "механизм правил (новые правила)" для прямого обнаружения. После непрерывной пометки и плевка в журнал es можно использовать новый журнал атак как черный образец для обучения и так далее.
Сравнение эффектов до и после добавления машинного обучения: потребляемый трафик Kafka: 10 000/мин -> 4 миллиона+, объем обнаружения после внесения в белый список: 10 000/мин -> 100 000+.
Мы настроили пакет потребления каждую минуту, а из storm каждую минуту приходило 100 000+ данных, и на их обработку ушло всего около 10 секунд, поэтому, если мы укоротим окно пакета потребления, теоретически его можно улучшить на 5-6. раз Пропускная способность, как показано на Рисунке 3 ниже.
Рис. 3. Скорость обработки Storm в новой архитектуре
Давайте сначала посмотрим на результаты распознавания машинного обучения, как показано на рисунке 4 ниже:
Рис. 4. Ведение журнала машинного обучения
Тег rule_result является результатом регулярного распознавания, потому что мы не добавили регулярность атаки struts2 в то время, но по результатам журнала ES механизм машинного обучения все же обнаружил атаку.
После знакомства с архитектурой давайте вернемся к самому машинному обучению.Далее будет рассказано, как построить модель машинного обучения для обнаружения веб-атак. Вообще говоря, применение машинного обучения для решения практических задач делится на следующие четыре этапа:
-
Определите целевую проблему
-
Сбор данных и разработка функций
-
Обучите модель и оцените производительность модели
-
Онлайн-приложение и непрерывная оптимизация
Проблема определения целей
Основной целевой вопрос:
1. Задача двух категорий, предсказать, является ли трафик атакой или нормальным
2. Уровень ложных срабатываний должен быть менее 10% (здесь мы считаем, что ложные срабатывания более серьезны, чем ложные срабатывания, и ложные срабатывания также могут быть исправлены штатным движком второго слоя)
3. Скорость предсказания модели должна быть быстрой, например, алгоритм knn ближайших соседей с сортировкой нами исключен.
Когда машинное обучение применяется в области информационной безопасности, первая сложность заключается в отсутствии размеченных данных.Благодаря реальному производственному трафику с обычными метками в наших журналах ES, здесь мы решили использовать бинарную классификацию, основанную на обучении с учителем для моделирования . Цель контролируемого обучения состоит в том, чтобы учиться на множестве помеченных примеров, а затем делать прогнозы на основе новых данных. Конечно, некоторые люди предлагали неконтролируемые идеи, устанавливая нормальную модель трафика и идентифицируя те, которые не соответствуют модели, как вредоносные, например, используя кластерный анализ, который не будет обсуждаться далее в этой статье.
Ни одна модель машинного обучения не может решить все проблемы, мы можем учиться на опыте предшественников, например, байесовская подходит для распознавания спама, а HMM — для распознавания речи. Для сравнения конкретных алгоритмов см. https://s3-us-west-2.amazonaws.com/mlsurveys/54.pdf.
После уточнения целей, которых нам нужно достичь, давайте начнем рассматривать «сбор данных и проектирование функций», что, по нашему мнению, также является наиболее важным шагом для успеха или провала модели.
4. Сбор данных и разработка функций
Мы пишем скрипт, который берет черно-белые данные ES по дням и периодам времени и хранит их отдельно, плюс журнал тревог собственной разработки waf и POC, собранный онлайн.На этом этапе наше обучающее сырье готово. . Кроме того, особое внимание следует обратить на то, что фичи и модели мы извлекаем отдельно для get-запросов и post-запросов, а почему — пусть читатели думают сами.
В начале локального эксперимента я выбрал библиотеку python sklearn, а черно-белые данные обучающих выборок составляли 10w+ фрагментов данных соответственно, достигая сбалансированного соотношения 1:1. Когда проект был запущен, мы использовали для этого spark mllib. Для удобства ознакомления в этой статье будет представлен python+sklean.
Давайте поговорим о «конструировании функций». Мы считаем, что «конструирование признаков» является наиболее важной частью моделей машин. Это больше похоже на искусство, часто полагающееся на «интуицию» экспертов и профессиональный опыт в предметной области. Более того, некоторые люди высмеивают, что машинное обучение на самом деле является проектированием признаков. Можно ли доверять модели прогнозирования финалов НБА, созданной кем-то, кто никогда не смотрел НБА?
Из-за нехватки места здесь мы в основном представляем этапы «разработки функций», которые мы считаем более важными в проекте:
-
Уточнение характеристик:
Основные требования: какая полезная информация извлекается из обучающих данных и как эта информация должна быть организована?
Давайте посмотрим на разницу между оператором атаки и обычным оператором в журнале ES следующим образом:
Заявление об атаке: Flights.ctrip.com/Process/checkinseat/index?tpl_content=&name=test404.php&dir=index/../../../..¤t_dir= тпл
Обычный оператор: Flights.ctrip.com/Process/checkinseat/index?tpl_content=hello,world!
Очевидно, мы видим, что наиболее очевидной особенностью оператора атаки является то, что он содержит символы и знаки препинания, такие как eval, ../, в то время как в обычных операторах мы видим, что он содержит английские запятые, восклицательные знаки и т. д., поэтому мы можем перечислить количество оценок в качестве измерения функции. При фактической обработке мы игнорируем uri и берем только значение параметра value для извлечения признаков. Например, два приведенных выше утверждения Flight.ctrip.com/Process/checkinseat/index?tpl_content были нами проигнорированы.
дефget_evil_eval(url):
возвращениеlen(re.findall("(eval)", url, re.IGNORECASE))
Что нам делать, если нет никакой ценности, такой как атака с угадыванием чувствительного каталога? Наш подход заключается в том, чтобы рассматривать это отдельно, удалять недопустимые данные, такие как Flights.ctrip.com, и использовать весь uri для извлечения функций.
Предположим, мы указываем 5 функций, а именно script, eval, одинарную кавычку, двойную кавычку и количество левых круглых скобок, тогда приведенный выше оператор атаки будет преобразован в [0,1,0,0,2]
Наконец, мы получаем пятимерное предложение атаки, помеченное меткой = 1, и обычный трафик с меткой = 0 для различения. Таким образом, запрос преобразуется в матрицу 1*n, а m обучающих выборок представляют собой m*n входное моделирование.
Однако после запуска первой версии, несмотря на то, что скорость потребления очереди сообщений была значительно улучшена, а скорость распознавания в основном была в порядке, мы все же отказались от этого метода извлечения признаков регулярного сопоставления предложений. Вот причины:
1. Используя обычные правила для извлечения признаков таким образом, всегда будут отсутствовать ключевые слова, и вы попадете в замкнутый круг проверки и заполнения пропусков.
2. Трудно оптимизировать функции, например, добавление определенного параметра функции увеличит количество ложных срабатываний, а их удаление увеличит количество ложных отрицаний.
3. При прогнозировании по-прежнему необходимо пропускать предложение запроса через регуляризацию и преобразовывать его в цифровой векторный признак, что снижает эффективность работы движка.
Мы получили вдохновение от использования машинного обучения для двоичной классификации настроений После проверки данных 1 https://github.com/jeonglee/ML мы решили заменить обычный метод извлечения признаков и использовать tfidf для извлечения признаков.
Мы думаем, что бинарная классификация настроений и черно-белая классификация трафика имеют схожие проблемы. Первая состоит в том, чтобы дать такое предложение, как «Том, ты нехороший мальчик!», чтобы судить, положительное оно или нет, но есть и другие. не так много положительных комментариев в нашем предложении.Или отрицательные эмоциональные слова, больше английской пунктуации и некоторые подозреваемые слова с высоким риском, такие как select, тогда мы заменяем понятие, является ли английская пунктуация с высоким риском похожей на отрицательное эмоциональное слово, другие слова как и нейтральные слова, поэтому наша проблема становится бинарной классификацией «нейтральных предложений и злонамеренных предложений».
Вот краткое введение в tfidf Для получения более подробной информации, пожалуйста, обратитесь к https://en.wikipedia.org/wiki/Tfidf.
Например, у нас есть 1000 операторов запроса на получение, первый оператор имеет всего 10 слов, из которых 3 одинарных кавычки и 3 от. 10 из 1000 предложений содержат одинарные кавычки, 100 содержат из, и вычисление tfidf выглядит следующим образом (перед вычислением tfidf нам необходимо обработать знаки препинания и специальные символы в предложении, например преобразовать в строковый тип, конкретная ссылка 1 ):
Результат расчета: tfidf=0,587 одинарных кавычек > tfidf=0,3318 of from
Основная идея TFIDF заключается в следующем: если слово или фраза часто встречается в статье и редко встречается в других статьях, считается, что это слово или фраза обладает хорошей способностью различать категории и подходит для классификации. Это в основном то же самое, что и суждение нашего мозга.Значение tfidf одинарных кавычек больше по сравнению с ним, что более характерно для того, является ли предложение предложением нападения, чем для.
Демонстрация кода выглядит следующим образом:
Причина, по которой принимается причина Ngram_range = {1,3}, потому что мы хотим сохранить отношения заказа между словами до и после как часть функции, например, функцию измерения в предыдущем «Том, вы не очень хорошие Мальчик! "Это [не, хорошо], а затем рассчитать TFIDF этого« коллективного слова ». Конечно, вы можете принять функции на основе CHAR, а специфическое значение значения параметров требует экспериментов, чтобы доказать, какой из них лучший. Что касается удаления стоп-слов, как преобразовать пунктуацию и т. Д. Вы можете обратиться к https://github.com/jeonglee/ml/blob/master/spark/naivebayes/src/main/java/wordparser.java, который не будет повторяться здесь.
-
Пример очистки данных:
Хотя мы выяснили, как извлекать признаки, и с моделированием вроде все в порядке, мы задаем себе вопрос: каков охват обучающих данных и точны ли метки исходных обучающих данных? Если наши собственные обучающие выборки не являются чистыми, результаты не должны быть удовлетворительными. Давайте поговорим о работе, которую мы проделали при очистке образцов:
1. Оптимизировать существующую регулярность обнаружения: когда мы открыли white.txt и black.txt, мы наблюдали за ними невооруженным глазом и обнаружили много ошибочных классификаций, поэтому это показывает, что сам наш обычный движок нуждается в оптимизации.
2. Присоединитесь к черному списку динамических IP-адресов, соберите его журналы атак и добавьте черные образцы. После нашего наблюдения мы обнаружили, что на ip, который постоянно сканируется сканером, приходится более 99% черного трафика.
3. Что касается белой выборки, то в качестве данных белой выборки мы можем напрямую взять исходный трафик по периоду времени, потому что на долю белой выборки приходится более 99,99% зеркального трафика.
4. Пример дедупликации, дедуплицируется тот же оператор содержимого запроса.
5. Некоторые зашифрованные запросы исключены из выборки по названию параметра
6. Самостоятельно соберите черный тезаурус, поместите его в белые образцы, чтобы они соответствовали содержанию тезауруса, и найдите образцы с явно неправильными метками. Например, создайте черный тезаурус [base64_decode, onglcontext, img script, struts2....], а затем поместите его в белый образец, чтобы найти совпадающие предложения и удалить их. На самом деле этот метод можно применять во многих местах, например, робот службы поддержки в сфере туризма может использовать ключевые слова отеля для очистки данных в образце билета на поезд, мы также вдохновляемся этим.
Очистка функций составляет более 60% нашей рабочей нагрузки, и это также неизбежный непрерывный процесс оптимизации.Это ручная работа, и ее нельзя избежать.
Нормализация признаков: Поскольку здесь мы используем tfidf, нормализация здесь не используется, потому что частота слов tf имеет эффект нормализации, который предотвращает смещение в сторону длинных предложений. Здесь снова, если вы используете первую версию обычного извлечения признаков, вы должны использовать нормализацию признаков.Пожалуйста, обратитесь к http://blog.csdn.net/leiting_imecas/article/details/54986045 для конкретных причин и введения в нормализацию.
5. Обучите модель и оцените эффект модели
Первоначальная оценка модели обучения sklearn очень проста: здесь мы перекрестно обучаем, берем 50% данных для обучения и 50% данных для тестирования, чтобы увидеть, соответствует ли эффект ожиданиям.
Если результаты перекрестного обучения в настоящее время неудовлетворительны, обычно есть три причины, и обычно первая и вторая причины ниже приводят к отклонению от ожидаемых результатов, Мы считаем, что алгоритм просто вишенка на торте, и качество разработки функций и образцов является точным.Ключ к скорости.
1. Есть проблема с извлечением признаков, нет возможности это сделать, оно полностью основано на личном опыте в определенном диапазоне областей знаний.
2. Проблемы с обучающими выборками, много неправильных меток или выборки несбалансированные
3. Алгоритм и выбранные параметры обучения нуждаются в оптимизации
Первые два были введены. Давайте поговорим о том, как оптимизировать параметры. Здесь мы представляем использование GridSearchCV в sklearn. Основной принцип заключается в систематическом обходе различных комбинаций параметров и определении наилучших параметров эффекта посредством перекрестной проверки. Обратитесь к официальный пример использования http://scikit-learn.org/dev/modules/generated/sklearn.grid_search.GridSearchCV.html.
После того, как перекрестное обучение достигнет психологического ожидания, мы сохраним локальную модель, полученную в результате обучения, на жестком диске, чтобы ее можно было напрямую загрузить и использовать в следующий раз.
Демонстрационный код для обучения и онлайн-прогнозирования выглядит следующим образом: сначала мы сохраняем черно-белые образцы в файле trainData.csv под метками uri и label соответственно.
Рисунок 5: Формат хранения данных обучающей выборки csv
На этом этапе, если мы оцениваем нашу модель машинного обучения с данными проверки с известными метками, мы рекомендуем использовать матрицу путаницы в качестве критерия,
#expected — это значение метки, предсказание — результат предсказания модели.
print("Матрица путаницы:\n%s" % metrics.confusion_matrix(ожидаемый,прогнозируемый))
вывод:
Confusion matrix:
[[ 1 0]
[4226 65867]]
Примерно объясните результаты матрицы путаницы:
|
Истинная ситуация |
результат прогноза |
|
|
Положительный пример |
Контрпример |
|
|
Положительный пример |
TP, фактическое положительное прогнозируемое положительное |
FN, фактическое положительное прогнозируемое отрицательное |
|
Контрпример |
FP, фактическое отрицательное прогнозируемое положительное |
TN, фактический отрицательный Прогноз отрицательный |
Поскольку на этот раз в нашем проверочном наборе данных есть только 1 нормальный трафик, мы видим, что FN равен 0. Нас больше беспокоит ситуация, когда вредоносный трафик идентифицируется как обычный трафик (ложные срабатывания).Мы видим, что ложных срабатываний здесь 4226. Если вы хотите рассчитать процент ложных срабатываний, вы можете использовать следующие индикаторы
print("Отчет о классификации для классификатора %s: \n%s\n"% (модель, metrics.classification_report(ожидаемый, прогнозируемый)))
вывод:
Скорость отзыва: отзыв=TP/(TP+FN)
Точность: Точность=(TP+TN)/(TP+FP+TN+FN)
Скорость точности: Точность=TP/(TP+FP),
f1-оценка представляет собой гармоническое среднее отзыва и точности, и если предположить, что оба они одинаково важны, формула выглядит следующим образом:
f1-score=(2*Recall*Accuracy) / (Recall+Accuracy)
Очевидно, что наш показатель отзыва здесь равен 0,94, а это означает, что наш показатель ложноотрицательных результатов составляет 6%, что едва ли находится в пределах допустимого диапазона и нуждается в постоянной оптимизации.
6. Онлайн-приложение и постоянная оптимизация
Онлайн-приложение, которое предназначено для встраивания встроенной модели в нашу существующую структуру nile, и необходимо настроить механизм машинного обучения с одним ключом, а также обычный переключатель с одним ключом для некоторых часто пропускаемых отчетов, непосредственно Расширенный обычный механизм , конечно же, количество регуляров нужно ограничивать, иначе дело снова зайдет в тупик регулярного обнаружения. Позже нам нужно постоянно наблюдать за выводом, постоянно автоматически дополнять правила и автоматически обучать новые модели.
Ссылаясь на рамочные рамки NiLe, упомянутая выше, самая большая проблема, возникающая в настоящее время: как мы сталкиваемся с пропущенным трафиком атаки, и является ли эта часть риска приемлемой. Я еще не думал о хорошем решении.
В конечном счете, мы по-прежнему считаем, что извлечение признаков является фактором, который оказывает наибольшее влияние на точность модели.Разработка признаков — грязная работа, и время, затрачиваемое на нее, намного больше, чем на другие шаги.Это требует большего количества инженеров. и часто требует больших профессиональных знаний.Опыта и острой интуиции, плюс немного "вдохновения". Можно сказать, что даже если хорошие характеристики сочетаются с плохими алгоритмами или параметрами, все равно можно получить хорошие результаты. Потому что хорошая фича означает приближение к сути реальной проблемы. К тому же не хватает инженера, который усердно чистит данные.
7. Перспективы будущего
В настоящее время наши приложения информационной безопасности в машинном обучении все еще имеют следующие области, которые могут быть улучшены:
1. Суждение о нестандартных json и xml пакетах данных, т.к. содержимое этих данных длинное, много знаков препинания, а некоторые из них нестандартные структуры.Например, json структура не может быть плавно разобрана, в результате чего ошибки в результатах прогнозирования.
2. Добавление нескольких классификаций может идентифицировать различные типы веб-атак, чтобы лучше интегрироваться с hulk.
3. В других приложениях, таких как случайное обнаружение доменных имен, вредоносные комментарии UGC, распознавание порнографических изображений и т. д., мы также начали практиковать этот аспект один за другим.
4. Замените библиотеку spark mllib на библиотеку spark ml.
Последнее предложение заключает, что дорога только началась.
Рекомендуемое чтение: