Предыстория: Являясь мировым лидером в сфере импорта и экспорта, компания Vandalay Industries стала мишенью многих злоумышленников, пытавшихся подорвать их онлайн-бизнес. Недавно Vandaly подвергся DDOS-атакам на свои веб-серверы.
В результате DDOS-атаки не только были отключены веб-серверы, но и скорость загрузки и выгрузки также значительно пострадала. Ваша сетевая команда предоставила результаты измерения скорости сети примерно во время последней DDOS-атаки.
Файл теста скорости
Снимок экрана загруженного файла server_speedtest.csv в Splunk:
eval создайте поле с именем «коэффициент», которое показывает соотношение между скоростями загрузки и выгрузки. Подсказка: Формат создания коэффициента: | eval new_field_name = 'fieldA' / 'fieldB'
Запрос, используемый в Splunk для генерации соотношения между скоростями загрузки и выгрузки - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
По этому запросу мы можем увидеть соотношение загрузок и выгрузок.
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioПодсказка: для команды table используйте следующий формат: | поле таблицыA полеB полеC
Запрос, используемый в Splunk для генерации соотношения между скоростями загрузки и выгрузки - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
На приведенном выше снимке экрана мы можем видеть общую хронологию событий, когда происходили загрузки и выгрузки.
На приведенном выше снимке экрана мы можем видеть время, в течение которого происходили загрузки и выгрузки, а также исходный IP-адрес, который выполнял это действие.
На приведенном выше снимке экрана мы можем видеть визуальное представление этих событий загрузки и выгрузки в формате столбчатого графика. Время отображается внизу, и это делает наши данные более читабельными.
Основываясь на результатах приведенных выше запросов, мы видим, что скорость загрузки и выгрузки резко упала примерно в 14:30 23 февраля. Мы можем видеть это на скриншоте ниже:
Мы видим, что в 14:30 загрузка упала до 7,87. Это резкое снижение по сравнению с предыдущим событием в 109,16 мегабит. Тогда справедливо предположить, что примерно в это время началась атака.
На скриншоте выше видно, что количество загруженных мегабит увеличилось с 17,56 до 65,34, что является резким увеличением. Поэтому можно с уверенностью предположить, что это примерно тот момент, когда система начала восстанавливаться и возвращаться к нормальному потоку сетевого трафика.
На скриншоте выше видно, что количество загруженных мегабит подскочило до 123,91 с 78,34 примерно в 23:30 23 февраля. Можно с уверенностью предположить, что это примерно то время, когда поток сетевого трафика стабилизировался и вернулся к нормальному состоянию.
Отправьте снимок экрана вашего отчета и ответ на вопросы выше.
Справочная информация: Из-за частоты атак ваш менеджер должен быть уверен, что конфиденциальные данные клиентов на их серверах не уязвимы. Поскольку Вандалей использует сканеры уязвимостей Nessus, вы проанализировали последние 24 часа сканирования, чтобы увидеть, есть ли какие-либо критические уязвимости.
Для получения дополнительной информации о Nessus прочитайте следующую ссылку: https://www.tenable.com/products/nessus
Результаты сканирования Nessus
Скриншот результатов сканирования nessus, загруженных в Splunk:
10.11.36.23 . Используйте dest_ip="10.11.36.23" в запросе.
Стоит отметить, что эти журналы ищут 5 типов уровней серьезности, как показано ниже:
Мы хотим отфильтровать любые уязвимости, уровень серьезности которых имеет «критическое» значение. Мы можем использовать severity="crtiical" в нашем запросе.
Весь запрос имеет source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
На снимке экрана ниже показан весь запрос, который отображает количество критических уязвимостей на сервере базы данных клиента из этого файла журнала:
Всего было обнаружено 49 критических уязвимостей, когда IP-адрес назначения был 10.11.36.23 (который является сервером базы данных).
[email protected] .Создайте оповещение, нажав «Сохранить как», а затем «Оповещение» после того, как мы сгенерируем результаты по приведенному выше запросу:
Введите данные, чтобы генерировать оповещения всякий раз, когда Nessus обнаруживает уязвимость на сервере базы данных. Введите имя, описание и любую другую соответствующую информацию:
Введите данные электронной почты, чтобы отправить созданное оповещение на адрес — [email protected] и введите данные сообщения, которое будет отправлено по электронной почте:
Продолжайте вводить сведения о предупреждении, а затем нажмите «Сохранить»:
После сохранения мы сможем увидеть предупреждение и отредактировать его, если захотим:
Отправьте снимок экрана отчета и снимок экрана, подтверждающий создание оповещения.
Предыстория: сервер Vandalay также подвергается атакам грубой силы на учетную запись администратора. Руководство хотело бы, чтобы вы установили мониторинг, чтобы уведомлять команду SOC, если атака методом перебора произойдет снова.
Логины администратора
Снимок экрана загруженного файла «Administrator_logs.csv» в Splunk:
Подсказки:
Найдите поле имени, чтобы найти неудачные попытки входа.
Отметим, атака длилась несколько часов.
Поскольку мы хотим найти любые признаки грубой атаки, мы хотим детализировать журналы, в которых учетные записи не смогли войти в систему. Если мы перейдем к полю «имя», мы сможем увидеть значения, которые оно содержит в журналах. В этом случае мы видим счетчик 1004 «Не удалось войти в учетную запись». Это хороший индикатор того, что произошла атака методом грубой силы. Смотрите скриншот:
Теперь, если мы добавим это в наш поиск, мы сможем увидеть общее количество событий, когда это произошло. Затем мы сможем увидеть, когда произошло большинство этих событий, что является хорошим индикатором того, когда это произошло. Смотрите скриншот:
Как мы видим, наблюдается довольно большой всплеск количества событий, когда «Не удалось войти в учетную запись» около 9 утра 21 февраля. Мы видим, что из общего числа произошедших 1004 событий в 9 утра было 124 таких события, аналогичные числа появились в последующие часы. Таким образом, я считаю, что атака началась примерно в это время – в 9:00 утра 21 февраля 2020 года.
Из хронологии этих событий мы можем видеть, что 124 — это настоящий скачок. За часы, предшествующие этому событию, наибольшее количество неудачных входов в систему составило около 23. Мы можем считать это нормальным поведением. Смотрите скриншот:
Имея это в виду и принимая во внимание, что на момент атаки методом перебора было около 124-135 попыток входа в систему, я бы рассматривал базовый показатель примерно в 40 неудачных входов в час. Я бы определил диапазоны неудачных входов в час следующим образом:
[email protected] если оно будет активировано.Чтобы создать оповещение для этого типа событий, я выполнил следующие шаги:
Нажмите «Сохранить как», а затем «Оповещение»:
Заполните подробную информацию о оповещении, в том числе о том, когда его активировать (все, что превышает 25 попыток в час):
Введите детали действия. В этом случае мы отправим электронное письмо на [email protected] :
Сохраните оповещение, и мы сможем просмотреть его:
Теперь мы успешно создали оповещение, которое сработает, когда произойдет более 25 событий, когда учетная запись не может войти в систему.
Отправьте ответы на вопросы о времени перебора, базовом уровне и пороге. Кроме того, предоставьте снимок экрана в качестве доказательства создания оповещения.
