ELK Отслеживание процессов Windows во всей сети

Что мы хотим получить? Мы хотим отслеживать какие программы (процессы) запускаются на windows-компьтерах нашего предприятия. На всех компьютерах, серверах и рабочих станциях. Мы хотим обнаруживать запуск неизвестных или опасных, на наш взгляд, процессов.
Как мы этого добьемся? Мы будем использовать стек ELK для сбора логов аудита всех машин с помощью агента winlogbeat. Мы включим аудит событий Windows таким образом, чтобы получить регистрацию событий запуска процессов в системе. Мы создадим в elasticsearch очень простой индекс win-proc-list, в котором будет храниться «профиль» нашей системы — категоризированный список известных нам процессов. Этот индекс мы будем обновлять вручную, с помощью двух простых скриптов на python: get_proc_list и set_proc_list. Мы сделаем dashboard на Kibana, где будет отображаться необходимая нам информация и можно будет фильтровать данные о запущенных процессах по категориям, хостам, на которых они запускались, и просматривать сырые логи с информацией о событиях запуска процессов.
Приступим …

Установка и настройка ELK

Об этом смотреть в документации на ELK. Дополнительно о конфигурации ELK для маленьких (200-300 хостов) компаний можно почитать в моей статье «Elastic для маленьких. Оптимизируем для небольшой компании».

Теперь надо раскатать на все хосты в нашей сети winlogbeat. Один из способов — использовать MS System Center Configuration Manager. Этот способ описан в моей статье Логи Windows на ELK, кстати этот способ может быть использован и для ручной установки.

Настройка аудита событий в Windows

Общие сведения об аудите безопасности смотрите здесь. Мы будем использовать расширенные политики аудита безопасности. Как минимум нам надо включить Аудит создания процессов. Я рекомендую использовать такой шаблон политик (извините, что не по-русски, это я писал для администратора англоязычного контроллера домена):

    Обязательная конфигурация аудита.
Устанавливать для всех серверов и рабочих станций групповой политикой, не перекрывать эту политику.
Для недоменных станций и серверов настроить в локальной политике безопасности (gpedit.msc) 

    Включение расширенной политики аудита

Computer Configuration -> Policies -> Windows Settings.

Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
выставить Enable

    Необходимые настройки

Account Logon - Audit Other Account Logon Events
Account Management - Все политики
Detailed Tracking - Audit Process Creation
Detailed Tracking - Audit Process Termination
Logon/Logoff - Audit Account Lockout
Logon/Logoff - Audit Logoff
Logon/Logoff - Audit Logon
Logon/Logoff - Audit Other Logon/Logoff Events
Logon/Logoff - Audit Special Logon
Policy Change - Audit Audit Policy Change
Policy Change - Audit Authentication Policy Change
Policy Change - Audit Authorization Policy Change
Policy Change - Audit Other Policy Change Events
System - Audit Security State Change
System - Audit Security System Extension
System - Audit System Integrity

Для перечисленных политик должен быть включен аудит успех/отказ. 
Для остальных политик в группе должно быть установлено состояние "ненастроено".

Подготовка реестра процессов в нашей сети

Нам понадобится вспомогательный индекс win-proc-list. Сначала мы создадим его шаблон и запишем в elastic. Готовый шаблон можно взять здесь. Я обычно складываю шаблоны в /etc/logstash. Теперь нам нужно отправить шаблон в elastic командой с консоли:

curl -XPUT 'http://localhost:9200/_template/win-proc-list' -d@/etc/logstash/win-proc-list-template.json

Еще одна проблема. В стандартном индексе winlogbeat есть поле event_data.NewProcessName, но в него пишется полный путь к файлу с программой. Это не очень здорово для анализа, поскольку один и тот же по сути модуль может запускаться из разных путей (например из профиля пользователя). Нам нужно добавить поле event_data.NewProcessBareName, которое будет содержать «голое» имя файла. И еще надо добавить парочку полей: event_data.NewProcessSeverity и event_data.NewProcessSeverityComment. Последнее поле разумно сделать analyzed. В стандартном шаблоне для winlogbeat новые поля объявляются not_analyzed. Значит нужно внести правку в шаблон для этого поля. Это нужно сделать до перезапуска logstash. Правленный шаблон для elastic версии 2.х можно взять здесь или для версии 5.х. Или вставьте в свой шаблон в нужное место фрагмент для версии 2.х:

        "event_data": {
          "properties": {
            "NewProcessSeverityComment": {
              "ignore_above": 1024,
              "index": "analyzed",
              "type": "string"
            }
          }
        },

или для версии 5.х

        "event_data": {
          "properties": {
            "NewProcessSeverityComment": {
              "norms": false,
              "type": "text"
            }
          }
        },

Я держу шаблоны в каталоге /etc/logstash и во всех файлах конфигурации logstash написано перезагружать шаблон в elastic при запуске logstash.
Еще нам понадобится elasticsearch filter plugin for logstash, по указанной ссылке вы прочитаете, как его добавить.

Теперь нам нужно добавить необходимые поля к индексу winlogbeat-*. Мы это сделаем в фильтре Logstash. Можно взять мой готовый файл конфигурации для logstash. Но пока его лучше не включать в полном объеме. Пока у нас нет индекса с профилем процессов, нет надобности записывать в elastic «мусорные» значения полей. Пока нам нужен только этот фрагмент в секции filter:

    if [beat][hostname] {
        ruby {code => "event['beat']['hostname'] = event['beat']['hostname'].downcase;"}
    }
    if [type] == "wineventlog" {
        if [event_data][LogonType] {
            ruby { 
                code => "dict = {'0'=>'Системный', '1'=>'Неизвестный', '2'=>'Интерактивный', '3'=>'Сетевой', '4'=>'Пакетный', '5'=>'Как Сервис', '6'=>'Прокси', '7'=>'Снятие блокировки (локально)', '8'=>'Сетевой (открытый текст)', '9'=>'Новая учетная запись', '10'=>'Интерактивный (удаленно)', '11'=>'Интерактивный (из кэша)', '12'=>'Интерактивный (удаленно, из кэша)', '13'=>'Снятие блокировки (из кэша)'}; key = event['event_data']['LogonType']; event['event_data']['LogonType'] = dict[key];"
            }        
        }
        if [event_data][NewProcessName] {
            mutate {
                add_field => {
                    "[event_data][NewProcessBareName]" => "NewProcessBareName"
                }
            }
            ruby {
                code => "event['event_data']['NewProcessBareName'] = event['event_data']['NewProcessName'].split('\\')[-1];"            
            }                    
        }
    }

Пора перезапустить logstash.
Прекрасно. Стоит подождать недельку, пока elastic наберет серьезную базу событий аудита. После чего можно будет создать начальный профиль — список «обычных» процессов в нашей системе. Для этого мы будем использовать два консольных скрипта get_proc_list.py и set_proc_list.py. Первый скрипт пройдется по записям аудита и создаст файл с уникальными именами процессов вида: proc_name:Неизвестный:Авто. Этот файл можно открыть в текстовом редакторе и заменить Неизвестный на Обычный. Делайте это с некоторой осторожностью. Вдруг у вас там вирус затесался. Пометить его обычным процессом — плохая идея. После редактирования и сохранения файла, запускаем set_proc_list.py. Всё. Первый профиль записан.

Пополнение логов раскраской процессов

Сначала не забудем, что мы должны установить плагин elasticsearch для logstash. Если мы еще этого не делали, то идем в домашний каталог logstash, не забываем, что они разные для разных версий. У меня logstash 2.4. Её домашний каталог: /opt/logstash. У версий 5.x — /usr/share/logstash. Из домашнего каталога запускаем команду:

bin/logstash-plugin install logstash-filter-elasticsearch

Теперь можно установить окончательный файл конфигурации logstash, либо взяв мой, указанный в ссылке выше, либо поменяв в своем секцию filter вот так:

    if [beat][hostname] {
        ruby {code => "event['beat']['hostname'] = event['beat']['hostname'].downcase;"}
    }
    if [type] == "wineventlog" {
        if [event_data][LogonType] {
            ruby { 
                code => "dict = {'0'=>'Системный', '1'=>'Неизвестный', '2'=>'Интерактивный', '3'=>'Сетевой', '4'=>'Пакетный', '5'=>'Как Сервис', '6'=>'Прокси', '7'=>'Снятие блокировки (локально)', '8'=>'Сетевой (открытый текст)', '9'=>'Новая учетная запись', '10'=>'Интерактивный (удаленно)', '11'=>'Интерактивный (из кэша)', '12'=>'Интерактивный (удаленно, из кэша)', '13'=>'Снятие блокировки (из кэша)'}; key = event['event_data']['LogonType']; event['event_data']['LogonType'] = dict[key];"
            }        
        }
        if [event_data][NewProcessName] {
            mutate {
                add_field => {
                    "[event_data][NewProcessBareName]" => "NewProcessBareName"
                    "[event_data][NewProcessSeverity]" => "Неизвестный"
                    "[event_data][NewProcessSeverityComment]" => "Авто"
                }
            }
            ruby {
                code => "event['event_data']['NewProcessBareName'] = event['event_data']['NewProcessName'].split('\\')[-1];"            
            }
            elasticsearch {
                add_tag => ["%{[event_data][NewProcessBareName]}"]
                index => "win-proc-list"
                query => "proc_name:%{[event_data][NewProcessBareName]}"

                fields => [["severity","[event_data][NewProcessSeverity]"], ["comment","[event_data][NewProcessSeverityComment]"]]
            }

        }
    }

Перезапускаем logstash. Раскраска логов началась.
Периодически мы можем обновлять наш каталог процессов с помощью скриптов get_proc_list и set_proc_list.

Теперь в Кибану

Конечно, каждый сам под себя делает дашборды, но в качестве заготовки можно использовать мои элементы, которые лежат здесь.

И кое что о «клонах»

Есть еще такая проблема, как «подмена правильной программы», то есть запуск из другого расположения программы с таким же названием файла. Это может быть нормально, например, когда нужны разные версии, а может быть не нормально. В моем дашборде есть табличная визуализация winlog_процессы_полные_пути_по_хостам. Последняя колонка называется Клоны и показывает количество разных путей запуска одноименной программы на одном хосте. Можно отсортировать таблицу по убыванию значения в этой колонке (там стрелочку сортировки нажать надо, если вы забыли) и увидеть всех клонов во всей красе.

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

Реклама

ELK Отслеживание процессов Windows во всей сети: 11 комментариев

  1. Спасибо за содержательную статью. Сейчас как раз занимаюсь тетсирование ЕЛК стека в небольшом парке машин. Очень занятное решение с фильтром «доверенных программ» , как раз была идея писать что-то подобное. Нужно попробовать Ваш метод. Еще такой вопрос: Почему не использовали для этих целей Metricbeat ? Он же в реальном времени процессы показывает запущенные. Или много логов выходит ?

    Нравится

    • Я про него даже и не думал. Меня интересует история разных событий. Логично искать ее в журналах аудита. Но в части процессов, может и metricbeat подойдет. Просто не подумал об этом. А логов много не бывает 🙂

      Нравится

      • Я смотрю вы используете фильтры на стороне logstash.
        В чем преимущество по сравнению фильтров на стороне beats. (я имею ввиду event_id)
        Например в моем конфиге winlogbeat это выглядит так:
        ###############################################################
        winlogbeat.event_logs:
        — name: Application
        ignore_older: 168h
        #event_id: 4624, 4625, 4700-4800, -4735 #A whitelist and blacklist of event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735).
        event_id: 1022, 1033, 1034
        — name: Security
        ignore_older: 168h
        event_id: 1102, 1033-1034, 4624-4625, 4649, 4657, 4688-4689, 4697-4698, 4720, 4723-4724, 4735, 4738, 4800-4803, 4964
        — name: System
        ignore_older: 168h
        event_id: 104, 6009, 7000, 7022, 7035-7036, 7040, 7045
        level: info
        output:
        logstash:
        hosts: [«ip:port»]
        index: winlogbeat
        enabled: true
        timeout: 120
        ###############################################################
        То есть я взял список интересных для меня ивентов и добавил их в разные журналы. Что бы они фильтровались на стороне пользовательской машины.
        С одной стороны править на сервере удобней для массовости. С другой более тонкая настройка выходит.

        Нравится

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

    Нравится

    • Спасибо за ответ. А есть вариация white-list в конфигурации фильтра logstash. (Для моей цели проще выбрать список интересующих ивентов , чем убирать все «лишние»)

      Нравится

    • И еще вопрос по реальному использованию. Сейчас хочу внедрить ELK для 250 рабочих станций. Сбор winlogbeat и metricbeat (не на всех пк). Какая будет приблизительная нагрузка на сеть и обьем логов ? (Какой hdd поставить? Ибо ситуация с вашей похожа — бюджет сильно ограничен, и больше одного ПК для этих целей не дадут).
      Заранее благодарю за ответ! С ув. Дмитрий.

      Нравится

      • Нагрузки на сеть почти не будет. Логи будут умещаться в 2гига за сутки (оба индекса в совокупности). Объем диска — это вопрос дительности хранения логов. По возможности лучше использовать SSD. Можно завести два логических диска для индексов. Когда первый подходит к концу, ставить второй первым в списке, а первый бэкапировать и стирать с него индексы. Можно просто копировать содержимое на медленнный диск и монтировать его в файловую систему и указывать в конфиге в конце списка. Так можно будет свежие индексы держать в «оперативном доступе» на ssd а старые на медленном диске.
        Главное оперативной памяти дать побольше. С таким потоком нужно не меньше 8 гиг. 16 — совсем хорошо.

        Нравится

  3. «Объем диска — это вопрос дительности хранения логов. По возможности лучше использовать SSD. Можно завести два логических диска для индексов. Когда первый подходит к концу, ставить второй первым в списке, а первый бэкапировать и стирать с него индексы. Можно просто копировать содержимое на медленнный диск и монтировать его в файловую систему и указывать в конфиге в конце списка. Так можно будет свежие индексы держать в «оперативном доступе» на ssd а старые на медленном диске.»

    А можно по-подробнее о такой конфигурации? Или это на отдельную статью материал? Как допустим указать конфигурацию, что бы к примеру индексы за неделю (10-20-30 гиг ) были в быстром доступе на ssd, а остальное архивировалось на hdd (на 1-2ТБ). Как лучше разбивку делать на логические диски для бэкапа? Подключаете ли Вы для этого logrotare ? Или функционалом logstash реализовали? Пробовали ли функцию архивирования логов ? Сможет ли он читать логи в последствии из архивов ? (Ну вдруг понадобится поднять лог 3х месячной давности)

    Заранее благодарю за ответ. С ув. Дмитрий.

    Нравится

    • Да просто: допустим у вас есть ssd на 100 гиг и медленный терабайтник. Делаете на SSD два логических тома 1 и 2 по 50 гиг, монтируете их в две директории dir1, dir2, и в таком порядке перечисляете их в конфиге эластика. Терабайтник бъете на 20 дисков по 50 гиг. И никуда их не монтируете. Когда место в dir1 будет близиться к концу, поменяйте порядок директорий в конфиге, эластик начнет писать в dir2. Скопируйте содержимое dir1 на первый из медленных дисков, размонтируйте старый dir1 и смонтируйте новый, освободившийся кусок SSD смонтируйте как dir3 и впишите в конфиг в порядке dir2,dir3,dir1. Продолжайте в том же духе.
      Свежие индексы у вас всегда будут на быстрых SSD, а старые на медленных дисках.
      Недостаток в том, что вам придется перезапускать Эластик, а это не очень быстрая процедура, поскольку ему надо алокировать все шарды всех индексов, в том числе старых. Так что не понятно выиграете вы или проиграете. При действительно большом количестве индексов, скажем за год, Запуск может занимать минут 30. Здесь важен не объем, а количество. Вообще Эластик это система для непрерывной работы, когда он разрастается, его трудно остановить и запустить. Это все равно, что остановить Международную космическую станцию, а потом опять запулить ее на орбиту.
      Впрочем, возможно поддерживается смена директории для записи индексов «налету», без перезапуска всего Эластика. Это было бы разумно, я просто не интересовался, можно ли сменить этот параметр конфигурации налету,

      Нравится

  4. Введение
    Elastic Stack многофункциональное открытое программное обеспечение, позволяющее облегчить процесс анализа данных.
    Благодаря расширенному диапазону возможностей данный продукт превзошел по функциональности ELK стек (комбинация продуктов Elasticsearch, Logstash и Kibana), при этом предоставив постоянно расширяющиеся возможности, как разработчикам, так и обыкновенным пользователям.
    Далее будут рассмотрены аспекты продукта, позволяющие обобщить возможности, требования и особенные черты в отношении использования программы.
    Все начинается с сбора данных. Оба приложения Logstash и Beats служат этой цели, хотя и каждый точно настроен на соответствие различным целям и использованию. Данная настройка соответствует как требованиям легких ресурсов, так и для обеспечения с значительно расширенными параметрами.

    1.1 Beats
    Beats представляет собой легкий и быстрый ресурс, поставляющий и собирающий данные, качественно выполняющий одну заданную функцию.
    Например, так называемые «пэкетбиты» собирают и перемещают данные в пределах активности пакета интерфейса сети, в то время как «файлобиты» могут служить для отслеживания логов и перенаправления их для последующей обработки.
    Beats созданы быстрыми и компактными для легкого размещения на отдельных хостах для специфического использования. Существуют даже созданные пользователями биты, как, например, для мониторинга HTTP и состояния NGINX (рис.1).
    Написанные в Go и базирующиеся на совместной организации libbeat,

    Рис.1 Мониторинг HTTP
    Beats созданы для быстрого достижения результата. Даже окружение с весьма ограниченными ресурсами может быть оценено просто и без сверхзатрат.

    1.2 Logstash
    Logstash, также, приспособлена для сбора данных. Ее стратегическими целями являются централизация, обработка и складирование данных. Разработчики программы позиционируют ее как открытый источник, усваивающий обработанные данные со стороны сервера от многочисленных источников, одновременно из трансформирующий и в последствии способный перенаправить их в выбранное вами хранилище (например Elasticsearch).
    Полем деятельности для сбора данных Logstash являются бескрайние просторы плагинов из открытых источников, цель которых улучшать используемые данные. Например, подразумевая процесс сбора логов с вебсерверов как полезный процесс, парсинг данных пользователей посредством извлечения статистики трафика при помощи фильтра useragent filter, может быть дополнительной удобной выгодой.
    Или, например, используя плагин Твиттера, вы можете проанализировать настроения пользователей сети.
    Пользовательские плагины ни что иное как библиотеки Руби, предоставляющие пользователю возможность расширить функциональность и быстро создавать прототипы характерных функций. Производительности ресурса необходимо думать заранее, тем не менее, Logstash по умолчанию оборудована JRuby, что предоставляет огромные возможности для согласования и создания реальных потоков.

    1.3 Elasticsearch
    После того, как данные собраны и обработаны с целью улучшения для анализа, размещение их Elasticsearch открывает целую линейку возможностей.
    Elasticsearch явялется сердцем Elastic Stack. Это распределенный уверенный поиск и аналитика, которые предоставляет надежный движок, способный решить растущее число проблем пользователей. Как уже упоминалось выше, являясь сердцем Elastic Stack, Elasticsearch централизованно хранит ваши данные позволяя вам одинаково надежно мониторить ожидаемые и неожидаемые ситуации.
    Данный ресурс позволяет выполнять и комбинировать многие типы поиска – структурированный, неструктурированный, гео, метрический – в любом желаемом пользователем направлении.
    Отступив несколько назад, можно увидеть более масштабную картинку того, что вы хотите разглядеть. Одно дело, когда требуется найти 10 документов наилучшим образом соответствующих вашему запросу. Но как разобраться с миллиардом логов? Функция агрегации Elasticsearch позволяет пользователю рассмотреть на расстоянии изучаемые тренды и модели данных.
    Elasticsearch, по своей сути, это поисковая машина, которую можно использовать в бесчисленном множестве случаев, благодаря ее гибкости и простоты в использовании. Созданная на основе Apache Lucene, Elasticsearch нацелена на решение обеих операционных проблем (речь идет о масштабируемости и надежности). Также, в ее функционал входит решение в наиболее легком для пользователя воплощении, связанных с приложениями задач, таких как freetext поиск и автозаполнение.
    В операционном контексте эластичность Elasticsearch базируется на разделении индексов на составляющие, которые могут быть распределены по многочисленным хостам с целью сбалансировать производительности загрузки и ускорения. С учетом планирования, это означает, что наборы данных могут превосходить возможности, предоставляемые одной машиной.
    Ниже представлены некоторые примеры аналитики, которые может выполнить Elasticsearch:
    • Гео-поиск. Когда документы содержат встроенные метаданные, результаты поиска могут быть нанесены на карту, чтобы визуально представить взаимосвязь документов с реально существующими широтой и долготой (с координатами);
    • Графическое отображение. Недавно разработанные плагины добавили поиск по графическим элементам в Elasticsearch, которые могут дать ответы на интересующие вопросы, как например, взаимоотношения между данными в известном случае «Панамских документов» (рис.2);
    • Агрегирование. Создание ответов на такие вопросы как, какие страницы чаще всего возвращаются с ошибкой «500», что становится причиной формирования правильных запросов в областях логов.

    Рис.2 Анализ финансовых и юридических документов в деле о «панамских документах»

    В то время как вышеописанные возможности предоставляются посредством использования базового Elasticsearch, встраиванием их в дружественный пользователю интерфейс занимается следующий уровень стека.

    1.4 Kibana
    Kibana, по существу, является окном пользователя в Elastic Stack, позволяющим визуализировать пользовательские данные Elasticsearch и осуществлять навигацию Elastic Stack. Таким образом, пользователь может делать что угодно – от изучения постраничных сообщений в определенное время до понимания какое влияние дождливая погода оказывает на квартальную статистику пользователя.
    Данный продукт позволяет пользователю свободно выбирать в какой форме будут представлены данные и в контексте этого запоминать направления поиска. С помощью интерактивной визуализации он может начать с одного вопроса и увидит, куда это его выведет.
    Kibana это базирующийся на браузере инструмент визуализации внешнего интерфейса для Elasticsearch. Данный инструмент позволяет пользователю легко оперировать с агрегированными данными, в других случаях подобная обработка трудновыполнима, создавать логии, метрики и неструктурированные данные, которые ищут и широко используют люди.
    Дополнительные плагины могут быть использованы в определенных ситуациях, таких, как например, для данных временных рядов Timelion. Данный продукт соединяет воедино совершенно независимые источники данных в единый интерфейс, приводимый в работу посредством простого однолинейного языка выражений, совмещающим восстановленные данные, комбинации и трансформации временных рядов, и все это в форме визуализации.
    Создатели настаивают на том, что большая часть данных Kibana в пределах управляется при помощи дашбордов и визуализации, точно так же как управляются и другие индексы в Elasticsearch. Таблицы. Графики и другие инструменты визуализации находятся на вершине Elasticsearch API, которые могут быть легко изучены для более близкого анализа или применения в других системах.

    Нравится

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s