Предлагаю читателям Хабрахабра перевод статьи «Выявление злоумышленников: что ваши журналы могут рассказать о защите вашего бизнеса» из официального блога Эластичный поиск .
В статье рассказывается о том, как можно использовать возможности Elasticsearch для анализа журналов веб-сервера с целью обнаружения подозрительной активности на сайте.
Давайте подумаем, что и когда нам делать в случае попыток взлома нашего сайта? Во-первых, чаще всего мы пытаемся устранить угрозу после того, как злоумышленники нашли уязвимость на сайте и воспользовались ею.
Во-вторых, зачастую единственным оперативным инструментом борьбы со злоумышленниками является блокировка IP-адресов, но это неэффективный инструмент, если мы не располагаем подробной информацией обо всех адресах, с которых сайт подвергается атаке.
Но насколько изменилась бы ситуация, если бы мы могли заранее получать подробную информацию обо всех IP-адресах и подсетях, проявляющих подозрительную активность, и специально их блокировать? Звучит здорово, не так ли? Мы можем легко сделать это с помощью Elasticsearch. Эта поисковая система имеет в своем арсенале замечательный плагин Нетриск , который берет на себя все хлопоты по анализу логов и с помощью диаграммы «Сэнки» (см.
картинку) показывает нам размер и концентрацию подозрительной активности в различных сегментах трафика.
Подготовка
Начнем с установки Netrisk. Для этого вам следует запустить следующую команду из домашнего каталога Elasticsearch (требуется версия 1.4.0 или новее):Отлично, плагин установлен.bin/plugin -install markharwood/netrisk
Но это не все.
Он ожидает, что мы предоставим ему индекс с правильно настроенным сопоставлением для поля, в котором будут храниться IP-адреса.
Подробности я объясню позже, а сейчас вам просто нужно создать индекс и заполнить его небольшим количеством тестовых данных, запустив следующий сценарий оболочки: $ES_HOME/plugins/netrisk/exampleData/indexAnonData.sh
Внимание! Этот скрипт создаст индекс «mylogs», и если индекс с таким именем у вас уже есть, он будет удален.
Если вы выполнили все инструкции выше, вы можете открыть страницу плагина: локальный хост :9200/_plugin/netrisk/
Запуск
Если посмотреть на данные, генерируемые скриптом, то может показаться, что этого недостаточно для серьезного анализа, ведь, по сути, единственное ценное, что у нас есть, — это статус HTTP-ответов от сервера.На самом деле этого достаточно, чтобы обнаружить подозрительное поведение.
Обычно веб-сервер генерирует ответы в диапазоне от 200 до 300, но в случае возникновения проблем он может присвоить ответу статус от 400 до 500. Например, это может произойти, когда кто-то пытается получить доступ к несуществующей странице.
Оказывается, мы уже можем получить список всех подозрительных обращений к серверу с помощью запроса: status:[400 TO 599]
Netrisk использует стандартный парсер запросов Lucene (такой же, как Kibana), поэтому вы можете дополнить запрос, обнаруживающий подозрительный трафик, дополнительными фильтрами через условие OR. Например, таким образом мы можем сообщить системе, что доступ к сайту без указания UserAgent также следует считать подозрительным.
Важно понимать, что запрос, составленный на этом этапе, не будет однозначно определять, что все записи в журнале, соответствующие ему, плохие.
Нет, мы просто делаем предположение о том, что может быть подозрительным, чтобы Elasticsearch впоследствии анализировал весь журнал на наличие высокой концентрации подозрительных обращений к серверу с определенных IP-адресов или подсетей.
Если мы запустим плагин, используя приведенный выше запрос, Netrisk покажет нам диаграмму Санки подозрительного трафика, ведущего на ваш сайт. Вот некоторая информация для чтения диаграммы: Толщина линии обозначает количество «плохих» запросов, но это не самое главное! Гораздо важнее цвет линии — он зависит от того, какие запросы преобладают: ярко-красный цвет означает, что почти все запросы плохие, а зеленый означает, что почти все запросы мы можем считать хорошими.
Если вы наведете курсор на линию, вы увидите действительные числа, лежащие в основе определения цвета.
На схеме показано, какие IP-адреса включены в каждую подсеть.
Эта информация может оказаться очень ценной для веб-мастера при определении того, откуда исходит вредоносный трафик: с конкретных IP-адресов или из подсети? При нажатии на определенный IP-адрес откроется веб-сайт проекта Honey Pot, где вы сможете прочитать комментарии других веб-мастеров относительно этого IP-адреса.
Вы наверняка заметили, что цвет линии может меняться с красного на зеленый слева направо.
Это связано с тем, что в левой части диаграммы каждый узел обычно представляет собой небольшую группу IP-адресов, запросы с которых были определены как подозрительные.
Следующие узлы на схеме представляют подсети, содержащие большое количество IP-адресов с различным поведением.
Однако некоторые подсети будут полностью красными.
Скорее всего, это означает, что вашим сайтом в этом регионе никто, кроме злоумышленников, не интересуется (например, если у вас русскоязычный сайт, и к вам идет красный трафик из Китая, то, скорее всего, это означает, что китайские хакеры хотят навредить вашему ресурсу).
Как это работает?
Немного о сопоставлении данных
Запросы, которые делает Netrisk, основаны на существующей статистике об IP-адресах и подсетях, хранящихся в индексе.Для такого рода анализа мы не можем просто индексировать каждый IP-адрес как строку, мы должны разделить его на токены, которые будут представлять сам IP-адрес и подсети, в которых он находится (например, такой IP-адрес, как 186.28.25.186, будет быть разделены на следующие токены: 186.28.25.186, 186.28.25, 186.28 и 186).
Это можно реализовать с помощью следующего правила сопоставления: Правило сопоставления curl -XPOST " http://localhost:9200/mylogs " -d '{
"settings": {
"analysis": {
"analyzer": {
"ip4_analyzer": {
"tokenizer": "ip4_hierarchy"
}
},
"tokenizer": {
"ip4_hierarchy": {
"type": "PathHierarchy",
"delimiter": ".
"
}
}
}
},
"mappings": {
"log": {
"properties": {
"remote_host": {
"type": "string",
"index": "not_analyzed",
"fields": {
"subs": {
"type": "string",
"index_analyzer": "ip4_analyzer",
"search_analyzer": "keyword"
}
}
}
}
}
}
}'
Такой подход дает нам возможность выполнять быстрый поиск одновременно на всех 4 уровнях иерархии каждого IP-адреса.
(это также относится к адресам IPv6)
То, что находится внутри?
Netrisk получает от вас запрос, определяющий, что именно следует считать «плохими попаданиями» (точнее, «потенциально плохими попаданиями»).Отфильтровав данные, Netrisk использует агрегацию значительный_термс, чтобы определить, с каких IP-адресов или подсетей чаще всего приходят подозрительные запросы.
Шаблон запроса выглядит следующим образом: curl -XGET " http://localhost:9200/anonlogs/_searchЭsearch_type=count " -d'{
"query": {
"query_string": {
"query": "status:[400 TO 599]"
}
},
"aggs": {
"sigIps": {
"significant_terms": {
"field": "remote_host.subs",
"size": 50,
"shard_size": 50000,
"gnd": {}
}
}
}
}'
Этот запрос выбирает 50 наиболее подозрительных IP-адресов и подсетей.
Есть несколько моментов, заслуживающих внимания: Чтобы получить корректные данные, нам нужно высокое значение shard_size. Это серьёзно нагрузит память и сеть, а также потребует дискового пространства для большого количества уникальных записей в индексе.
Если мы не проиндексируем IP-адреса полностью в поле Remote_host.subs, то это уменьшит нагрузку, но и уменьшит глубину получаемого результата.
ElasticSearch по умолчанию использует для эвристического анализа алгоритм JLH, но для рассматриваемой нами задачи гораздо лучше подходит алгоритм GND. Обычно при анализе нас интересуют редкие слова, например, нам важно определить, что слова «Носферату» и «Хельсинг» связаны с набором документов о фильме «Дракула», но нас это мало интересует. с чем ассоциируется обычное слово «он».
В задаче анализа IP-адресов мы можем пренебречь возможностями, которые дает нам алгоритм JLH, и использовать менее функциональный, но более быстрый GND. Этот одиночный запрос проведет массовый анализ и предоставит нам основную информацию о нарушителях в нашей системе, но желательно уточнить некоторую информацию, прежде чем принимать решение о блокировке IP-адресов.
Для этого мы можем использовать следующий запрос: Запрос {
"query": {
"terms": {
"remote_host.subs": [
"256.52",
"186.34.56"
]
}
},
"aggs": {
"ips": {
"filters": {
"filters": {
"256.52": {
"term": {
"remote_host.subs": "256.52"
}
},
"186.34.56": {
"term": {
"remote_host.subs": "186.34.56"
}
}
}
},
"aggs": {
"badTraffic": {
"filter": {
"query": {
"query_string": {
"query": "status:[400 TO 599]"
}
}
}
},
"uniqueIps": {
"cardinality": {
"field": "remote_host"
}
}
}
}
}
}
Для каждого указанного подозрительного IP или подсети мы получим массив со следующей информацией: Общее количество запросов (плохих и хороших);
Общее количество неверных запросов;
Общее количество уникальных IP-адресов в подсети;
Теперь, когда у нас есть диаграмма и подробная статистика по сомнительным IP-адресам, мы можем принять окончательное решение о блокировке.
Заключение
Отслеживание поведения таких объектов, как IP-адреса, путем анализа журналов веб-сервера — сложная вычислительная задача, но наши данные — это лишь верхушка айсберга.Вот еще несколько интересных примеров поведенческого анализа, которые вы можете реализовать самостоятельно: Сколько времени посетители проводят на моем сайте? Какие IP-адреса ведут себя как боты (не загружают CSS и JavaScript — только саму разметку страницы)? Какая страница сайта чаще всего является первой/последней при посещении сайта? Теги: #elasticsearch #информационная безопасность #Поисковые технологии
-
Точарские Языки
19 Oct, 24 -
Как Обратиться В Сервисный Центр
19 Oct, 24 -
Здравствуйте, Дорогие Друзья!
19 Oct, 24 -
Полная Визуализация Интернет-Аналитики
19 Oct, 24
