Linux sysmon что это

🔍 Sysmon – системный мониторинг Linux (как диспетчер задач Windows)

Одна из самых полезных программ в ОС Microsoft Windows – Диспетчер задач.

Это мощное приложение, которое показывает общую производительность системы Windows и использование ресурсов.

Конечно, для платформы Linux доступно очень много программ мониторинга системных ресурсов.

Но ни один из них не имеет внешнего вида диспетчера задач Windows 8/10.

Кроме того, большинству из них по-прежнему не хватает одной или двух функций.

Например, некоторые системные мониторинги не отображают данные об использовании жесткого диска и графического процессора на графиках.

К счастью, сегодня я наткнулся на системный диспетчер Linux под названием Sysmon.

Sysmon – это графический инструмент для мониторинга системы для Linux.

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

Он контролирует процессор, графический процессор, память, сеть и диски в режиме реального времени и отображает все детали в понятном и простом графическом интерфейсе.

Sysmon – бесплатное приложение с открытым исходным кодом, написанное на языке программирования Python.

Установка Sysmon на Linux

Sysmon зависит от двух пакетов python, а именно pyqtgraph и pyqt5.

Вы можете установить эти библиотеки с помощью Pip, как показано ниже.

Если у вас есть графический процессор Nvidia, вам необходимо установить nvidia-smi, чтобы отслеживать его использование.

После установки вышеупомянутых зависимостей, клонируйте репозиторий Sysmon с помощью команды:

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

Перейдите в каталог sysmon/src:

И запустите программу Sysmon с помощью следующей команды:

Sysmon – графический системный мониторинг для Linux

Интерфейс Sysmon по умолчанию выглядит так, как показано ниже.

Как видите, внешний вид sysmon напоминает диспетчер задач Windows.

Sysmon получает большую часть данных из каталога /proc в вашей системе Linux.

• сведения об использовании ЦП из /proc/cpuinfo и /proc/stat,
• Использование памяти из /proc/meminfo,
• Использование дисков из /proc/diskstats,
• Использование сети /proc/net/dev и iwconfig
• и обзор запущенных процессов с помощью команды ps aux.

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

Однако он не показывает нагрузку на HDD/SSD.

Sysmon – очень новый проект.

Он отлично работает на Ubuntu 20.04 LTS.

Надеюсь, что разработчик добавит еще больше функций в ближайшие дни.

Источник

Sysmon – A Graphical System Activity Monitor for Linux

Sysmon is a Linux activity monitoring tool similar to Windows task manager, was written in Python and released under GPL-3.0 License. This is a Graphical visualization tool that visualizes the following data.

By default distribution like Ubuntu comes with a system monitor tool, but the drawback with the default monitor tool is it does not display HDD, SSD, and GPU loads.

Sysmon adds all the features to a single place similar to the Windows Task Manager.

• CPU/GPU utilization and per-core clock speed.
• Memory and Swap utilization.
• Network utilization (Wlan and Ethernet). WLAN link bandwidth is constantly updated.
• SSD/HDD utilization.
• Overview of a running process.

In this article, you will learn how to install and use the Sysmon monitoring tool in Linux desktop systems.

Installing Sysmon Linux Monitor Tool

Since sysmon is written in python, you need to have a python package manager PIP setup in your machine. Sysmon depends on the following packages pyqtgraph, numpy, and pyqt5.

Install Sysmon Using PIP

When you install the sysmon using PIP dependencies are automatically installed.

If you have an Nvidia GPU, nvidia-smi has to be installed to monitor it.

Install Sysmon Using GitHub Repo

Alternatively, you can pull the repository from Github and install the package. But when following this method you have to make sure the dependent package (numpy, pyqtgraph, pyqt5) is installed separately.

You can check the list of installed packages from pip using the following commands.

List Pip Installed Packages

Now the dependency is satisfied and good to install sysmon by cloning the repo from GitHub.

The preferable method is to install packages using PIP, as PIP handles all the dependency and keeps the installation simple.

How to Use Sysmon in Linux

To launch sysmon, simply type sysmon at the terminal.

All the data points are grabbed from the /proc directory.

• CPU data are grabbed from /proc/cpuinfo and /proc/stat.
• Memory data are grabbed from /proc/meminfo.
• Disks data are grabbed from /proc/diskstats.
• Network data are grabbed from /proc/net/dev and iwconfig (Wlan).
• Processes data are grabbed from the ‘ps -aux’ command.

Sysmon Linux Process Monitor Sysmon Linux Network and Disk Monitor Sysmon Linux CPU and Memory Monitor

That’s it for this article. This tool is just a prototype and many more features like IOWait, Support for Intel and AMD GPU, Dark Mode, kill the process, sort, etc.. are in the pipeline to be added. Let’s wait and see how this tool is getting matured over a period of time.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

Sysmon для безопасника. Расширяем возможности аудита событий в Windows

Технические специалисты, которые, расследуя ИБ-инциденты или устраняя неполадки при траблшутинге, хоть раз пытались найти в логах операционных систем семейства Microsoft Windows реально важную для них информацию, знают, что в журналы аудита событий попадает далеко не все, что нужно. Можно ли исправить эту ситуацию без дополнительных финансовых вложений с использованием инструментов, гарантированно совместимых с Windows-средой? Разумеется, можно!

Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.

Сразу оговоримся, что за рамками настоящей статьи останутся вопросы осознанной чистки логов или «кривой» настройки политик аудита в домене (Audit Policy). Здесь мы поговорим только о том, как повысить информативность и расширить возможности функции аудита событий, используя утилиту System Monitor (Sysmon) в Windows-среде (от Windows 7 для клиентских узлов и от Windows Server 2008 R2 для серверов).

Sysmon

Утилиту можно загрузить с веб-сайта Microsoft Docs, из раздела Windows Sysinternals download. В составе Windows Sysinternals от Марка Руссиновича и Со есть еще много полезных утилит, так что найди время и «пощупай» их. Плюс загляни в подборку материалов на GitHub materials.
Но для данной статьи мы возьмем специальную готовую сборку с GitHub download, включающую файл конфигурации Sysmon Threat Intelligence Configuration от ION-STORM. Она ориентирована именно на выявление инцидентов ИБ и может выступить качественной основой для создания твоих собственных файлов конфигурации.

Утилиту можно установить точечно на каждое рабочее место либо с использованием групповых политик (Group Policy) в домене.

В данном файле конфигурации указываются в большинстве своем полные стандартные пути для ряда программного обеспечения:

Таким образом, в конкретной ИТ-инфраструктуре это может потребовать определенного тюнинга, так как, например, согласно корпоративной политике программы могут устанавливаться на диск D:\, а не на C:.

Инструментарий настолько гибкий, что можно задавать любые конструкции, нацеленные на то, чтобы отслеживать определенные действия или исключать их из твоего поля зрения.
После установки получишь новый журнал (Channel) Microsoft-Windows-Sysmon/Operational, в котором Sysmon выделяет 18 категорий задач (Task Category), среди них: Process Create, Network Connect, Driver Load, ProcessAccess, File Create.

Аудит сетевого взаимодействия

Перейдем к практическому применению Sysmon.

Представь сетевое взаимодействие между двумя узлами сети: узел А обращается к узлу Б, и это обращение не является легальным, то есть возникает подозрение на ИБ-инцидент. Искать следы данного сетевого взаимодействия в операционной системе будут в самый последний момент, а начнут именно с активного сетевого оборудования.
Что нам скажет межсетевой экран или маршрутизатор, если он контролирует это сетевое взаимодействие?

Видим только, кто IP_1 и куда IP_2.
По большому счету тут потребуются дополнительные усилия: придется в полуавтоматическом или ручном режиме анализировать узел А (IP_1), чтобы найти реальный источник сетевой активности.

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

Мы видим, кто, куда и, если очень повезет, то с помощью чего, то есть в данном случае PuTTY.
Но здесь нет ни места установки приложения, ни имени исполняемого файла, ни когда он был создан. В случае PuTTY это может показаться надуманными атрибутами, но если ты ищешь следы несанкционированных действий и/или вредоноса, то это уже важные вещи. Плюс вредонос может «представиться» легальным приложением и подтолкнуть тебя закрыть данный ИБ-инцидент как ложное срабатывание (false positive), приняв решение только на основании полученного из дампа сетевого трафика имени приложения.

Теперь посмотрим в канал Microsoft-Windows-Sysmon/Operational. В нем есть следующее событие:

Видим, кто, куда, с помощью чего, а также дополнительные параметры сетевого взаимодействия (протокол, порт). Теперь в этом же канале по значению поля ProcessGuid найдем событие категории Process Create, чтобы получить больше информации непосредственно об источнике данной сетевой активности:

Видим, что создан процесс, в том числе определено хеш-значение файла — прародителя данного процесса.

Теперь ты можешь по хешу проверить этот файл:

• по корпоративным «белым спискам» разрешенного программного обеспечения;
• на соответствие эталону на веб-сайте производителя данного программного обеспечения;
• в рейтингах сервиса Threat Intelligence;
• на ресурсах типа VirusTotal.

Стоит отметить, что на тех узлах сети, где есть ограничения на установку средств антивирусной защиты (терминалы диспетчеров, технологические АРМ и тому подобное), анализ хешей — в том числе автоматизированный, путем сопоставления данных от сервисов Threat Intelligence, например в системе класса Security Information and Event Management (SIEM), — может выступать вполне действенной компенсирующей мерой для борьбы с вредоносным программным обеспечением.

Развивая тематику отслеживания действий, связанных с файлами, нужно отметить, что по умолчанию указанный файл конфигурации позволяет отслеживать создание в операционной системе файлов, которые могут быть потенциальным источником ИБ-инцидентов, например цифровых сертификатов, исполняемых файлов, файлов библиотек, PowerShell-файлов, RDP-файлов, файлов MS Office с поддержкой макросов, а также файлов, создаваемых в определенных каталогах файловой системы:

Файлы или действия, которые ведут к изменению параметров реестра, также подлежат протоколированию. Например, ассоциация типа файла DOCM, который был впервые использован в операционной системе при создании файла Doc1.docm (см. пример выше), с приложением MS Word:

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

Централизация сбора и хранения событий

Чтобы обеспечить централизованный сбор и хранение событий из логов всех узлов сети, в том числе сократить злоумышленнику возможности очищать логи на атакуемом узле, практикуется консолидация данных на выделенном узле. На этом узле должна быть запущена служба Windows Event Collector. В итоге события будут отображаться в журнале Forwarded Events.
Нужно сделать следующие шаги на каждом рабочем месте либо с использованием групповых политик в домене:

1. Добавить пользователя, от имени которого будут собираться события «COLLECTOR», в локальную группу «Event log reader».
2. Выполнить от имени администратора (Run as) команду
   winrm quickconfig -quiet
3. Выполнить от имени администратора (Run as) команду
   wevtutil get-log Microsoft-Windows-Sysmon/Operational,
   Получить строку «channelAccess» DATA

1. Выполнить от имени администратора (Run as) команду
   wmic useraccount where name=’COLLECTOR’ get sid
   Получить UID_COLLECTOR
2. Выполнить от имени администратора (Run as) команду
   

wevtutil set-log Microsoft-Windows-Sysmon/Operational /ca: DATA(A;;0x1;;;UID_COLLECTOR)

Получить расширенные права доступа к каналу Microsoft-Windows-Sysmon/Operational для учетной записи COLLECTOR.

1. Добавить данный узел в специально созданную подписку (Subscription) для централизованного сбора и хранения событий на выделенном узле с запущенной службой Windows Event Collector.

Заключение

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

Напоминаем, что это полная версия статьи из журнала Хакер. Ее авторы — Александр Кузнецов и Алексей Федоров.

Источник