Universal forwarder что это

Splunk – Установка агентов для сбора логов Windows и Linux

Нам часто задают вопросы о том, как загрузить различные данные в Splunk. Одними из самых распространенных источников, представляющих интерес, оказались логи Windows и Linux, которые позволяют отслеживать неполадки операционных систем и управлять ими. Загружая данные в Splunk, Вы можете анализировать работу всех систем в одном месте, даже когда у Вас десятки или сотни различных источников.

В данной статье мы пошагово объясним Вам, как загрузить данные из Windows и Linux в Splunk, для последующей обработки и анализа.

Настройка базовой инфраструктуры

Для того, чтобы начать собирать данные нам необходимы следующие элементы системы:

Для того, чтобы загружать логи в Splunk, необходимо сначала предварительно настроить индексер, для этого потребуется:

В первую очередь, вам понадобится Splunk на машине, которая является нашим индексером. Если у вас нет установленного Splunk, то прочитать подробнее, как и на какие системы можно поставить его вы можете прочитать тут.

Это приложение необходимо для того, упростить управление источниками данных, когда этих источников много или доступ к ним для внесения изменений затруднителен. Также приложение позволит вам не совершать потенциально ошибочные изменения конфигурации на многих хостах, ограничивая изменением только на одном месте.

Создаем приложение: Apps — Manage Apps — Add New

После создания приложения, необходимо сформировать конфигурационный файл оutputs.conf (Подробнее об том файле Вы можете прочитать на официальном сайте Splunk)

В текстовом редакторе введите следующий текст, заменив indexer_hostname_or_ip_address именем хоста или IP-адресом индексера и получающим портом, установленным на предыдущем шаге:

Сохраните как outputs.conf и добавьте в папку \etc\apps\sendtoindexer\local (Папку local необходимо создать).

На этом этапе мы заканчиваем предварительную настройки индексера и переходим к установке агентов на машины Windows и Linux.

WINDOWS

Универсальным инструментом для загрузки логов является специальный агент – Splunk Universal Forwarder. Universal Forwarder представляет собой версию Splunk Enterprise с существенно ограниченным функционалом, единственной задачей которого является сбор данных с хоста и отправка их.

Скачать его можно по этой ссылке.

На картинке выше видно, что Universal Forwarder можно установить как на Windows, так и на Linux, Solaris и другие операционные системы.

1. Устанавливаем Universal Forwarder

В качестве Deployment Server указываем IP-адрес или название Splunk индексера, где мы создали приложение «Send to indexer». Порт по умолчанию: 8089. Раздел Receiving Indexer оставим пустым, так как эти функции выполнит «Send to indexer».

2. Следующий шагом нам необходимо вернуться к Splunk и определить класс сервера для приложения «Send to indexer».

Класс сервера что-то похожее на правило, в котором мы указываем какие приложения мы будем распределять между какими целевыми машинами-клиентами. Критериями для формирования разных классов сервера могут стать тип машины, ОС, географическая область или тип приложения, причем классы могут пересекаться между собой. (Более подробно можно прочитать на официальном сайте)

Settings — Forwarder Management — edit action — add new classes.

3. После сохранения вам будет предложено добавить приложения, которые мы будем рассылать и целевые системы, так называемые клиенты, которым мы будем их рассылать.

Добавляем «Send to indexer» в раздел приложений.

4. Затем добавляем клиента. Клиентом будет наша машина с Windows, на которую мы установили Universal Forwarder. Если Universal Forwarder был установлен правильно, то машина должна появиться в списке клиентов, подключенных к Deployment Server. Заносим ее в Include (whitelist).

5. Проверить правильно ли все работает можно, посмотрев на содержимое индекса _internal. После добавления «Send to indexer» в класс сервера Universal Forwarder начинает отправлять свои внутренние логи туда. Также в этом индексе далее мы можем следить за тем, правильно ли работают наши агенты.

6. Далее скачиваем специальный Add-on с сайта SplunkBase, который позволяет собирать данные о работе Windows.

7. Устанавливаем приложение на Splunk-Indexer ( Apps — Manage Apps — Install app from file)
По умолчанию оно устанавливается в каталог . \Splunk\etc\apps\Splunk_TA_windows, но нам необходимо скопировать его в папку deployment-apps, чтобы это приложение было доступно для deployment server, чтобы потом мы могли отправить его на другие машины также, как и «Send to indexer». (Важно: в папке apps оно также должно остаться, чтобы на индексере сформировались нужные нам индексы для данных).

8. Затем необходимо сделать преднастройку приложения.
Переходим в каталог . \Splunk\etc\deployment-apps\Splunk_TA_windows
Создаем в нем под-каталог «local» (Важно: Вносить изменения в конфигурационные файлы необходимо всегда в каталоге local).

Включим индексацию требуемых данных. Для этого в файле inputs.conf из каталога local через текстовый редактор делаем некоторые изменения. Заменим значения disabled=1 на disabled=0 в необходимых блоках файла. Давайте добавим логи системы по Application, Security, System.

9. Далее, на Splunk-indexer, добавляем к приложению созданный ранее сервер-класс. (Settings — Forwarder Management — Apps — Splunk_TA_Windows – «+» — Windows Forwarder)

10. Перезагрузим deployment server, это можно сделать через командную строку из каталога … /splunk/bin:

Проверям, загружаются ли данные. (Settings – Indexes ) Они должны попадать в индекс wineventlog. Как видно на нашем рисунке последние данные, которые были загружены на данный момент имеют временную метку 3 минуты назад.

LINUX

Одним из инструментов, позволяющих повысить уровень безопасности в Linux, является подсистема аудита auditd. C её помощью можно получить подробную информацию обо всех системных событиях. Именно данные, генерируемые этой системой мы будем индексировать в Splunk.

(Код будет представлен для Linux CentOS)

1. Проверим, если ли на машине предустановленная система аудита, если нет установим ее.

Добавим новое правило, которое мы будем отслеживать.

Проверить его наличие можно с помощью функции.

Логи, генерируемые auditd попадают в файл:

2. Далее, установим Universal Forwarder. Найти дистрибутив можно по ссылке.

3. Далее на создадим нового пользователя, который будет отвечать за работу со splunk.

4. Дадим разрешения пользовалелю, которого мы только что создали и запустим UniversalForwarder от его имени.

5. Проведем настройку форвардера и укажем Deployment Server, также как в части с Windows, это IP-адрес или имя Splunk-indexer/

6. Можно проверить, работает ли форвардер, следующим образом:

7. Далее переходим в Splunk-indexer и устанавливаем на него специальный Add-on, позволяющий передавать логи с Linux. Скачать дистрибутив можно по ссылке.

8. После установки, находим папку с приложением по следующему адресу ../splunk/etc/apps/Splunk_TA_nix. Копируем папку Splunk_TA_nix из apps в deployment-apps. Чтобы это приложение появилось как доступное для deployment server.

В файл …/ deployment-apps/Splunk_TA_nix/ local/ input.conf через текстовый редактор вносим изменения, которые покажут данные из каких папок мы хотим собирать. В нашем случае это /var/log/audit.

В input.conf есть раздел [monitor:///var/log], в котором необходимо изменить disabled=1 на disabled=0 (Важно: убедитесь, что необходимая папка есть в whitelist, если ее нет, но нужно ее добавить)

9. Далее проверим, увидел ли Deployment server нового клиента, нашу машину Linux. (Settings — Forwarder Management – Clients).

Если ее нет, то необходимо проверить название (Host name) машины, если он совпадает с названием машины индексера, то необходимо его изменить, иначе возникает ошибка.

10. Затем создаем новый сервер класс, относящийся к Linux.
Settings — Forwarder Management – Server Classes — New Server Class

11. Добавляем в этот класс приложения «Send to indexer» и «Splunk_TA_nix», а в качестве клиента добавляет машину Linux.

Обратите внимание, что файлы не будут загружаться, если у Universal Forwarder (у юзера, под которым мы используем Universal Forwarder) нет доступа к папкам, которые необходимо мониторить. Так что необходимо учесть этот момент и разрешить доступ.

12. В конце необходимо перезагрузить deployment server, это можно сделать через командную строку из каталога … /splunk/bin :

После проведения выше описанных операций, Вы получите логи Linux, которые будут загружены в индекс OS.

Заключение

Таким образом, мы показали вам, как загрузить ваши логи из Windows и Linux в Splunk для дальнейшего анализа и обработки. Надеемся, что эта информация будет полезна для Вас.

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

Источник

Splunk Universal Forwarder в докере как сборщик системных логов

Splunk является одним из нескольких наиболее узнаваемых коммерческих продуктов для сбора и анализа логов. Даже сейчас, когда продажи в России больше не производятся, это не повод не писать инструкции/how-to по этому продукту.

Задача: собирать системные логи с docker нод в Splunk не меняя конфигурацию хост-машины

Начать хотелось бы с официального подхода, который выглядит странноватым при использовании докера.
Ссылка на Docker hub
Что же мы имеем:

2. Стартуем контейнер с нужными параметрами

3. Заходим в контейнер

Далее нас просят пройти по известному адресу в документацию.

И конфигурировать контейнер после его запуска:

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

Отлично. В образе даже нет артефакта. То есть, каждый раз при запуске будет тратиться время, чтобы выкачать архив с бинарниками, распаковать и настроить.
А как же docker-way и всё такое?

Нет, спасибо. Мы пойдём другим путём. Что, если все эти операции мы выполним на этапе сборки? Тогда поехали!

Чтобы долго не тянуть, покажу сразу итоговый образ:

И так, что же содержится в

При первом старте, Splunk просит задать ему логин/пароль, НО эти данные используются только для выполнения административных команд этой конкретной инсталляции, то есть, внутри контейнера. В нашем случае же, мы просто хотим запустить контейнер, чтобы всё работало и логи лились рекой. Конечно, это хардкод, но других способов я не нашёл.

Дальше по сценарию выполняется

splunkclouduf.spl — Это файл креды для Splunk Universal Forwarder, которые можно загрузить из веб интерфейса.

Это обычный архив, который можно распаковать. Внутри — сертификаты и пароль для подключения к нашему SplunkCloud и outputs.conf со списком наших input инстансов. Этот файл будет актуален до тех пор, пока вы не переустановите свою инсталляцию Splunk или не добавите input нод, если инсталляция on-premise. Поэтому ничего страшного нет в том, чтобы добавить его внутрь контейнера.

И последнее — restart. Да, для применения изменений, нужно его рестартануть.

В наш inputs.conf добавляем логи, которые мы хотим отправлять в Splunk. Необязательно добавлять этот файл в образ, если вы, к примеру, раскидываете конфиги через puppet. Главное лишь в том, чтобы Forwarder видел конфиги, при старте демона, иначе будет нужен ./splunk restart.

А что за docker stats скрипты? На гитхабе есть старое решение от outcoldman, скрипты взяты оттуда и доработаны для работы с актуальными версиями Docker (ce-17.*) и Splunk (7.*).

С полученными данными можно строить такие

Исходный код дэшей лежит в репе, указанной в конце статьи. Обратите внимание, что там присутствует 2 select поля: 1 — выбор индекса (ищутся по маске), выбор хоста/контейнера. Маску индекса скорее всего вам придётся обновить, в зависимости от имён, которые вы используете.

В завершение, хочу обратить внимание на функцию start() в

Также стоит отметить момент, что по какой-то причине на Splunk не влияет наличие docker параметра hostname. Он всё равно будет упорото слать логи с id своего контейнера в поле host. Как решение, можно монтировать /etc/hostname с хост-машины и при старте делать замену, аналогичную именам индексов.

Да, возможно, решение не идеальное и уж точно не универсальное для всех, так как присутствует много «хардкода». Но на основе него каждый может собрать свой образ и положить его в свой приватный артифактори, если, так уж случилось, вам необходим Splunk Forwarder именно в докере.

Источник

Загрузка данных в Splunk: Universal Forwarder vs Heavy Forwarder. В чем разница?

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

Корректная загрузка данных — это самый проблемный вопрос в любой системе по работе с данными. Передача данных может осуществляться различными способами, но самый распространенный из них это использование форвардеров.

У Splunk форвардера есть ряд преимуществ:

Всего существует 2 вида форвардеров:

Universal Forwarder

Universal Forwarder имеет ряд преимуществ перед использованием Heavy Forwarder. И поэтому зачастую рекомендуется использовать именно его, если нет конкретных предпосылок использования Heavy Forwarder, о которых мы расскажем далее.

Наиболее заметным преимуществом является то, что Universal Forwarder использует значительно меньше аппаратных ресурсов, чем другие программные продукты Splunk. Он меньше нагружает CPU, использует меньше памяти и занимает меньше места на диске. Он также более масштабируемый, чем другие продукты Splunk, поскольку можно установить более тысячи экземпляров, которые не будут сильно влиять на производительность сети и хостов.

Еще преимуществом является его доступность для установки на многих различных платформах. Его можно установить не только на Windows, Linux и Mac OS, как Splunk Enterprise, но и на Solaris, FreeBSD и AIX.

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

Для достижения более высокой производительности Universal Forwarder имеет несколько ограничений:

Heavy Forwarder

Хотя Universal Forwarder является предпочтительным способом пересылки данных, но вам может потребоваться Heavy Forwarder, если необходимо проанализировать или внести изменения в данные, прежде чем пересылать их, или вам нужно будет контролировать, куда данные идут, основываясь на их содержании.

Одним из ключевых преимуществ Heavy Forwarder является то, что он может фильтровать нежелательные события, даже в неструктурированных данных, что позволит сократить объем индексации, а от этого зависит размер лицензии.

Правда, следует отметить, что использование Heavy Forwarder увеличивает сетевой трафик, использование ЦП и памяти. Это связано с тем, что Heavy Forwarder отправляет проанализированные данные по сети не просто сырыми событиями, а со всеми полями, которые выделяются во время индексации и дополнительными метаданными.

Чтобы сравнить показатели работы Heavy и Universal Forwarder, было проведено испытание.
В тестовом файле было 367 463 625 событий.

Итоги эксперимента

При использовании Universal Forwarder:

Рекомендации

Используйте Heavy Forwarder, только когда:

Если вы все еще не пробовали Splunk, то самое время начать, бесплатная версия до 500Мб в сутки доступна всем желающим. А если у вас есть вопросы или проблемы со Splunk — вы можете задать их нам, а мы поможем.

Источник

Что такое Splunk и с чем его едят

Я думаю, большинство так или иначе слышало о Splunk, тем не менее несколько вводных слов я тут напишу. Если коротко, то данный зверь помогает консолидировать логи со всех точек в единую базу.

Допустим, на сервере номер X есть демон, который мониторит N лог файлов и по SSL-каналу пересылает все изменения на сервер Splunk. Там все это консолидируется (ведь есть еще X – 1 серверов), индексируется, фильтруется и уже «бородатый админ», залогинившийся в милый зеленый интерфейс, делает выборку интересных ему событий быстро и без напряга. Есть как бесплатная лицензия (ограничения по объему: 500 метров в день), так и навороченная Enterprise. Ну а поддержка ОС просто великолепна: не только банальные Windows/Linux, но и OS X, и FreeBSD, а кроме того, и такие монстры, как HP-UX и AIX!

Хакер #181. Вся власть роботам!

Разумеется, это очень полезный инструмент, который поможет отследить кучу информации: от температуры блейдов до нагрузки на CPU или нехватки места на виртуальном диске того или иного сервера. Понятно, что настройка источников логов и прочего — это вопрос отдельный и требует понимания задач и интересов тех, кто будет все это собирать, то есть нас с вами!

Splunk as SIEM

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

Вот для таких навороченных систем есть своя ниша, свой рынок и даже свое название — SIEM (Security information and event management). Если обобщить, то SIEM — это такой класс систем для управления и анализа событий и инцидентов безопасности. Это механизм сбора логов и выявления в них событий, относящихся к безопасности. Splunk это умеет, но этого недостаточно, нужно еще управлять инцидентами, например через что-то типа JIRA. То есть Splunk + фильтры Splunk’a + JIRA = SIEM. Да, разумеется, у SIEM есть и иные свойства (комплайнс, корреляция и так далее), но это все детали, которые я тут не умещу.

Кстати, Splunk поддерживает «встраиваемые» приложения (ну типа как плагины на XML + HTML + JavaScript). Конкретно для реализации SIEM-фич есть Splunk App for Enterprise Security, но поставить это можно только на платную/энтерпрайз версию Splunk. Ну и добавим возможность реал-тайм мониторинга с нотификацией ответственных лиц в случае чего! В большой и разветвленной сети без этого точно никуда.

В принципе, можно собрать такую систему и самому (читай: бесплатно), используя Splunk только в роли агрегатора, но тогда придется поработать ручками. Если ты меня спросишь про бесплатный SIEM с «все включено», то я порекомендую OSSIM (в нем есть еще много других вкусностей, но он требует прямых рук и понимания предмета). Но это тема отдельная, которая частично поднималась в статье «Под прессом IT-рисков: обзор Open Source систем управления уязвимостями» за октябрь 2009. Есть и другие представители опенсорса, но все же на рынке больше популярны проприетарные изделия, такие как HP ArcSight (если у тебя денег полно) или SolarWinds Log & Event Manager… в любом случае, каждый выбирает по своим потребностям и возможностям.

Splunk App for Enterprise Security рассказывает о подозрительных User-Agent

Уже много было сказано про плюсы, но вернемся все же к нашей теме — безопасности. Мониторя различные лог-файлы и собирая с них данные, сортируя и упорядочивая, мы легко и в автоматическом режиме можем обнаружить атаки и прочие неприятные вещи. Причем мы думаем теперь только о том, что и как мы собираем, а анализировать можно уже потом и автоматически. И возвращаясь к теме сложности слежения за ситуацией в публичных облаках и облаках вообще: Splunk — идеальное решение, ведь он позволит «объединить» лог-файлы одного логического приложения, которое раскинуто на различных нодах облака, связав все события по временным меткам. Ну и конечно же, Splunk может собирать логи с различных источников — OSSEC, Snort, AppArmor/SELinux или логов аутентификации от SSH, что позволит собирать именно логи, связанные с событиями безопасности.

Начало

Что ж, скачать и установить Splunk довольно легко. Даже если появятся вопросы, как поставить форвардер и настроить его или как открыть сислог-сбор, это все RTFM-стайл вопросы, на которые жалко тратить бумаги, но тут я лишь посоветую уделить внимание менеджменту индексов. Индексирование собираемых данных — важный момент, ведь именно от этого будет зависеть скорость поиска, группирование и даже ограничение доступа различным клиентам. Грубо говоря, можно разным проектам или ролям раздать разные индексы. Скажем, логи с енд-поинтов клиентов (антивирусы, события на рабочках) — это один индекс, а ЕРП-сервис — другой. Фактически это будут разные физические базы данных. Более подробно о конфигурации и развертывании Splunk можно узнать на сайте вендора.

Что будем логировать?

Если наша задача — найти факт проникновения или хотя бы попытку проникновения, то нужно четко определить источники информации, которые нам помогут прямо или косвенно сообщить об этом. Это могут быть логи IDS, логи апача и даже mod_sec или OSSEC, журналы аудита и так далее. Разные лог-файлы имеют разный формат, если ты хочешь сортировать, рисовать графики, выделять нужную информацию — все это возможно сделать в менеджере приложений, правда, придется немного попотеть (в Splunk встроен свой Wizard, но скорее там набор темплейтов XML/HTML). По умолчанию же ты увидишь набор строк, которые сортируются по временным меткам, поэтому очень важно, чтобы в лог-файле были явные временные метки, иначе спланк будет разделять ивенты по своему усмотрению — по отрезку времени мониторинга, за которое было добавлена некая информация. Это плохо: если несколько ивентов были добавлены одновременно, спланк их посчитает за один ивент. После этого уже можно искать события…

Визард скуден и беден, но в целом накидать дашборд можно, так как все графики — встроенные функции поискового языка

Что теперь?

Имея уже солидную базу ивентов, можно смотреть, что было плохо. Для этого можно воспользоваться поиском или состряпать дашборд, ну или скачать готовое приложение (напомню, что для Splunk имеется целая куча бесплатных приложений — для Snort, ModSecurity, OSSEC, логов антивируса и прочего).

В качестве демонстрации мощи Splunk и гибкости языка запросов давай разберем один жизненный пример. Итак, у нас есть некоторый облачный веб-сервис, у него есть доменное имя и какие-то там функциональные скрипты. Если на этот сервис приходит запрос, то в зависимости от IP источника запрос направляется в нужный региональный дата-центр (Европа, Азия, Америка…). Пришедший запрос далее пробрасывается раунд-робином на конкретный виртуальный сервак с Apache. Второй запрос уже попадет в тот же региональный дата-центр, но на другой виртуальный сервак (из-за раунд-робин балансировки), а если клиент поменяет вдруг IP, то следующий запрос пойдет уже в другой дата-центр.

Предположим, что есть «злая» последовательность запросов, которая реализует некую брутфорс-атаку. С учетом архитектуры, в локальных логах Апача будут только отдельные звенья атакующей цепи, однако в Splunk все эти запросы выстроятся в одну цепочку, и таким образом будет обнаружена аномалия на количество запросов к одному логическому ресурсу в единицу времени. Ну вот, к примеру, как это будет выглядеть в строке поиска/фильтра:

В результате будут найдены все обращения к /service/auth логического ресурса web-service, причем нас интересуют только запросы методом POST. Следующая часть запроса сгруппирует запросы в блоки с периодом в одну минуту, после чего уже следующая часть отсортирует их по времени, в итоге каждый «блок по минуте» будет содержать статистку по количеству событий с данным URL. Ну а последняя часть условия сообщает, что нас интересуют только те минуты, где было более 60 таких событий. Заменив в этой части stats count by url time на stats count by srcip _time, получим то же самое, но уже с сортировкой по IP-адресам, то есть узнаем, с какого IP адреса было больше всего запросов в минуту. Конечно, это лишь один пример того, что «язык» запросов в Splunk очень гибкий и позволяет искать информацию и получать аналитику по самым разным вопросам. Аналогично можно «заменить» логику ModSecurity и искать паттерны SQLi в логах, так как Splunk поддерживает и regexp (по-моему, это уже стрельба из пушки по воробьям, но иногда и такое может быть полезно). Важно понимать, что собираемая в логах информация позволяет вести более адекватный поиск. Формат логов и ваши кастомные приложения в спланке могут оказаться намного полезнее бездумного логирования всего подряд с последующим анализом инцидентов — когда петух уже клюнет и нам надо будет узнать, как нас сломали и что делали злые дяди, вместо того чтобы вовремя определить их активность.

To be continued.

В заключение отмечу еще раз, что Splunk очень мощный инструмент, но основа его мощи — это люди, которые смогут им правильно воспользоваться. Просто даже внедрение и поддержка Splunk требует ресурсов. Конечно, очерк получился очень общим, почти рекламным: я не описывал недостатки, которые тоже имеются, например ограничения по объему трафика в 500 Мб в бесплатной лицензии, жуткий визард приложений, а многие бесплатные приложения написаны словно новичками из ВиндовсМаркета — все как-то недоделано, неполно и «лучше написать самому». В следующий же раз я покажу практическое решение одной задачи, в том числе при помощи именно данного инструмента. Всем Splunk, пацаны!

Алексей Синцов

Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE

Источник