Обнаружение атак грубой силы с помощью Splunk

1. Определение грубой силы
2. Требования Splunk
3. Источники данных
4. Пример формата журнала веб-приложения (CA SiteMinder)
5. Случаи применения
6. Процент увеличения грубой силы
7. Потенциально скомпрометированные счета грубой силы

В этом гостевом блоге Навид Краббе (старший консультант по оперативной разведке с Splunk Partner) Function1 ) исследует использование Splunk для обнаружения атак грубой силы. Являясь лидером в области оперативного интеллекта и промежуточного программного обеспечения, Function1 не только разработал базовую архитектуру для некоторых из крупнейших в мире развертываний Splunk, но и помог разработать стандарт управления корпоративным классом и передачи данных.

Одной из самых давних и наиболее распространенных проблем для групп информационной безопасности и веб-разработки является атака методом перебора . Хотя эта форма атаки существует уже много лет, она остается одним из самых популярных и широко используемых методов взлома паролей. С точки зрения воздействия атаки методом перебора являются очень серьезной угрозой, способной повлиять на миллионы аккаунтов. Если эти атаки не будут своевременно обнаружены и устранены, они могут привести к краже интеллектуальной собственности и личной информации, значительным финансовым потерям и необратимому ущербу репутации бизнеса.

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

Определение грубой силы

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

Требования Splunk

Единственное истинное требование - наличие необходимых данных (и правильное их анализ) в развертывании Splunk Enterprise. Эти варианты использования могут быть построены с использованием стандартного Splunk SPL и представлены в виде панелей мониторинга или сохранены в виде запланированных поисков, которые вызывают оповещения. Если ваша организация использует Splunk Enterprise Security, эти варианты использования будут отлично работать как поиск корреляции, который запускает заметные события.

Источники данных

Это, конечно, будет зависеть от конкретных целей использования вашей организации и используемых технологий и приложений. В общем, журналы веб-приложений - хорошее место для начала. В частности, эти журналы должны включать все события, связанные с аутентификацией, для вашего веб-сайта / веб-приложений. Как минимум, они должны содержать метку времени, исходный IP-адрес, учетную запись пользователя, тип события аутентификации и результат. Кроме того, наличие канала (веб-или мобильного) и информации об устройстве (cookie или идентификатор оборудования) может предоставить дополнительную информацию для отчетности.

Пример формата журнала веб-приложения (CA SiteMinder)

[categoryid] [AuthType] [причина] [имя хоста] [метка времени] [имя агента] [sessionid] [идентификатор пользователя, ou1, ou2, dc1, dc2] [имя домена] [имя_режима] [имя_режима] [номер_режима] [ресурс] [действие] [authdirname] [authdirserver] [authdirnamespace] [TransactionID] [statusmsg] [имя_домена] [impersonatorname] [impersonatordirname] [ObjName] [objoid] [fielddesc]

[Auth] [AuthReject] [] [host.abcd.org] [11 / Apr / 2017: 09: 47: 31 -0400] [signonagent] [asdf] [uid = abcd-efgh-1234-5678, ou = клиенты , ou = people, dc = abcd, dc = org] [99-88a-77b-66c] [abcd] [00-11z-22x-33y] [12.345.67.89] [/ abcd /] [GET] [abcd Войти Каталог] [ldap1.abcd.org:9800] [LDAP:] [] [] [ABCD] [] [] [] [] []

Случаи применения

Обнаружен брутфорс IP

Этот вариант использования предназначен для обнаружения исходных IP-адресов, которые превышают высокий порог отклоненных и / или недействительных имен входа.

1. index = web_idx sourcetype = web_st (AuthType = "AuthInvalid" ИЛИ AuthType = "AuthReject" ИЛИ AuthType = "AuthAccept ИЛИ AuthType =" AuthChallenge "ИЛИ AuthType =" Lockout ") 2. | Статистика считается как счетчик итоговых подсчетов (eval ( == "AuthInvalid")) в качестве значения invalid_count (eval (AuthType == "AuthReject")) в качестве значения reject_count (eval (AuthType == "AuthAccept")) в качестве счетчика accept_count (eval (AuthType == "AuthChallenge")) в качестве count_count count (eval (AuthType == «Lockout»)) как lockout_count по client_ip 3. | eval invalid_thresh = 4. | eval reject_thresh = 5. | где invalid_count> invalid_thresh ИЛИ reject_count> reject_thresh 6. | evalcent_denied = round (((reject_count + попытки_count) / total_count) * 100, 2) 7. | сортировка 0 - итого_счет процентов_день 8. | переименуйте client_ip как «IP-адрес клиента», total_count как «Total Count», invalid_count как «Попытки неверного имени пользователя», reject_count как «Попытки действительного имени пользователя / неверного пароля», accept_count как «Успешные входы в систему», account_count как «Количество вызовов», lockout_count как «Заблокированные попытки», процент_отклонено как «Процент отклонен»

Процент увеличения грубой силы

В этом сценарии использования обнаруживаются большие проценты увеличения в различных статистических данных о грубой силе за разные периоды времени (последние 30 минут по сравнению с 30-минутным периодом 6 часов назад).

1. index = web_idx sourcetype = web_st (AuthType = "AuthInvalid" ИЛИ AuthType = "AuthReject" ИЛИ AuthType = "Блокировка") самое раннее = -30m @ m самое последнее = @ m 2. | статистика считается как счетчик total_fail_count (eval (AuthType == "AuthInvalid")) как счетчик invalid_count (eval (AuthType == "AuthReject")) как счетчик reject_count (eval (AuthType == «Lockout»)) как самая ранняя блокировка_счета (_time) как самое раннее_ время самое позднее (_time) как самое последнее_ время 3. | convert timeformat = "% Y-% m-% d% T" ctime (earliest_time) AS earliest_time 4. | convert timeformat = "% Y-% m-% d% T" ctime (latest_time) AS latest_time 5. | приложения 6. [индекс поиска = web_idx sourcetype = web_st (AuthType = "AuthInvalid" ИЛИ AuthType = "AuthReject" ИЛИ AuthType = "Lockout") самое раннее = -390 м @ м последний = -360 м @ m 7. | статистика учитывается как 6h_total_fail_count count (eval (AuthType == "AuthInvalid")) как 6h_invalid_count count (eval (AuthType == "AuthReject")) как 6h_reject_count count (eval (AuthType == «Lockout_lock as_houtout»)) самое раннее (_time) как 6h_earliest_time самое позднее (_time) как 6h_latest_time 8. | время преобразования = "% Y-% m-% d% T" ctime (6h_earliest_time) AS 6h_earliest_time 9. | время преобразования = "% Y-% m-% d% T" ctime (6h_latest_time) AS 6h_latest_time] 10. | eval pct_total_fail_increase = round (((total_fail_count - 6h_total_fail_count) / 6h_total_fail_count) * 100,0) 11. | eval pct_invalid_attempt_increase = round (((invalid_attempt_count - 6h_invalid_attempt_count) / 6h_invalid_attempt_count) * 100,0) 12. | eval pct_lockout_increase = round (((lockout_count - 6h_lockout_count) / 6h_lockout_count) * 100,0) 13. | eval pct_reject_increase = round (((reject_count - 6h_reject_count) / 6h_reject_count) * 100,0) 14. | Таблица: eval total_fail_thresh = 16. | eval perc_inc_thresh = 17. | где (total_fail_count> total_fail_thresh) И ((pct_total_fail_increase> perc_inc_thresh) ИЛИ (pct_invalid_attempt_increase> perc_inc_thresh) ИЛИ (pct_lockout_increase> perc_inc_thresh))

Потенциально скомпрометированные счета грубой силы

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

1. index = web_idx sourcetype = web_st (AuthType = "AuthReject" ИЛИ AuthType = "Блокировка" ИЛИ AuthType = "AuthAccept") 2. | Статистика учитывается как счетчик total_count (eval (AuthType == "Lockout")) как счетчик lockout_count (eval (AuthType == "AuthReject")) как счетчик reject_count (eval (AuthType == "AuthAccept")) в виде accept_count dc (client_ip) как count_ips по идентификатору пользователя 3. | eval total_denied = lockout_count + reject_count 4. | eval denied_thresh = 5. | поиск accept_count> 0 AND total_denied> denied_thresh 6. | evalcent_denied = round ((total_denied / total_count) * 100, 2) 7. | Таблица идентификаторов пользователей. сортировка 0 - процент_данных

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

Удачи!
Навид Краббе
Старший консультант, Оперативная разведка
Function1
@ Function1Corp

Похожие

Комментарии