Основная концепция, связанная с использованием приложения osquery, – это «табличная абстракция» многих аспектов операционной системы, таких как процессы, пользователи и т. д.
Данные хранятся в таблицах, и их можно запрашивать с использованием синтаксиса SQL, непосредственно через оболочку osqueryi, или с помощью демона osqueryd.
В этом уроке мы увидим, как установить приложение, как выполнить базовые запросы и как использовать FIM (мониторинг целостности файлов) как части вашей работы по администрированию системы Linux.
В этом руководстве вы узнаете:
- Как установить osquery
- Как составить список доступных таблиц
- Как выполнять запросы из оболочки osqueryi
- Как использовать демон osqueryd для контроля целостности файла
Установка
У нас есть два основных варианта установки osquery: первый заключается в загрузке соответствующего пакета для нашей системы с официального сайта;
Второй, обычно предпочтительный, заключается в добавлении репозитория osquery к нашим источникам программного обеспечения.
Здесь мы кратко рассмотрим оба варианта.
Установка через пакет
С официального сайта osquery можно загрузить подписанные пакеты deb и rpm или более общие tarballs.
Первым делом мы выбираем версию, которую хотим установить, затем скачиваем пакет.
Совет: выберите последнюю доступную версию (4.1.2 на момент написания).
Как только пакет загружен, мы можем установить его с помощью нашего менеджера пакетов.
Например, чтобы установить программное обеспечение в системе Fedora (при условии, что пакет находится в нашем текущем рабочем каталоге), мы должны выполнить:
$ sudo dnf install ./osquery-4.1.2-1.linux.x86_64.rpm
Использование репозитория
В качестве альтернативы мы можем добавить репозиторий rpm или deb в нашем дистрибутиве.
Если мы используем дистрибутив на основе rpm, мы можем выполнить следующие команды для выполнения этой задачи:
$ curl -L https://pkg.osquery.io/rpm/GPG | sudo tee
/etc/pki/rpm-gpg/RPM-GPG-KEY-osquery
$ sudo yum-config-manager --add-repo https://pkg.osquery.io/rpm/osquery-s3-rpm.repo
$ sudo yum-config-manager --enable osquery-s3-rpm-repo
$ sudo yum install osquery
С помощью вышеприведенных команд linux мы добавляем gpg ключ, используемый для подписи пакетов в нашей системе, затем добавляем репозиторий.
Наконец, мы устанавливаем пакет osquery.
Обратите внимание, что yum в последних версиях Fedora и CentOS / RHEL является просто символической ссылкой на dnf, поэтому, когда мы вызываем первое, вместо него используется последнее.
Если вместо этого мы используем дистрибутив на основе Debian, мы можем добавить репозиторий deb к нашим программным источникам, выполнив:
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B
$ sudo add-apt-repository 'deb [arch=amd64] https://pkg.osquery.io/deb deb main'
$ sudo apt-get update
$ sudo apt-get install osquery
Основное использование
Osquery позволяет нам отслеживать различные аспекты операционной системы, использующей «табличную абстракцию», используя синтаксис SQL, аналогичный синтаксису, используемому в базах данных sqlite.
Запросы выполняются в таблицах, которые абстрагируют различные аспекты операционной системы, такие как процессы и службы.
Мы можем выполнять запросы напрямую с помощью интерактивной оболочки osqueryi или планировать их с помощью демона osqueryd.
Вот пример запроса для перечисления всех доступных таблиц (полный список таблиц с описанием также можно найти в Интернете):
$ osqueryi
osquery> .tables
=> acpi_tables
=> apt_sources
=> arp_cache
=> atom_packages
=> augeas
=> authorized_keys
=> block_devices
=> carbon_black_info
=> carves
=> chrome_extensions
=> cpu_time
=> cpuid
=> crontab
=> curl
=> curl_certificate
=> deb_packages
=> device_file
=> device_hash
=> device_partitions
=> disk_encryption
=> dns_resolvers
=> docker_container_labels
=> docker_container_mounts
=> docker_container_networks
=> docker_container_ports
=> docker_container_processes
=> docker_container_stats
=> docker_containers
=> docker_image_labels
=> docker_images
=> docker_info
=> docker_network_labels
=> docker_networks
=> docker_version
=> docker_volume_labels
=> docker_volumes
=> ec2_instance_metadata
=> ec2_instance_tags
=> elf_dynamic
=> elf_info
=> elf_sections
=> elf_segments
=> elf_symbols
=> etc_hosts
=> etc_protocols
=> etc_services
=> file
=> file_events
=> firefox_addons
=> groups
=> hardware_events
=> hash
=> intel_me_info
=> interface_addresses
=> interface_details
=> interface_ipv6
=> iptables
=> kernel_info
=> kernel_integrity
=> kernel_modules
=> known_hosts
=> last
=> listening_ports
=> lldp_neighbors
=> load_average
=> logged_in_users
=> magic
=> md_devices
=> md_drives
=> md_personalities
=> memory_array_mapped_addresses
=> memory_arrays
=> memory_device_mapped_addresses
=> memory_devices
=> memory_error_info
=> memory_info
=> memory_map
=> mounts
=> msr
=> npm_packages
=> oem_strings
=> opera_extensions
=> os_version
=> osquery_events
=> osquery_extensions
=> osquery_flags
=> osquery_info
=> osquery_packs
=> osquery_registry
=> osquery_schedule
=> pci_devices
=> platform_info
=> portage_keywords
=> portage_packages
=> portage_use
=> process_envs
=> process_events
=> process_file_events
=> process_memory_map
=> process_namespaces
=> process_open_files
=> process_open_sockets
=> processes
=> prometheus_metrics
=> python_packages
=> routes
=> rpm_package_files
=> rpm_packages
=> selinux_events
=> shadow
=> shared_memory
=> shell_history
=> smart_drive_info
=> smbios_tables
=> socket_events
=> ssh_configs
=> sudoers
=> suid_bin
=> syslog_events
=> system_controls
=> system_info
=> time
=> ulimit_info
=> uptime
=> usb_devices
=> user_events
=> user_groups
=> user_ssh_keys
=> users
=> yara
=> yara_events
=> yum_sources
Запустив команду osqueryi, мы входим в интерактивную оболочку; исходя из этого, мы можем отправлять наши запросы и инструкции.
Вот еще один пример запроса, на этот раз список всех запущенных процессов pid и name.
Запрос выполняется к таблице process (выходные данные запроса для удобства урезаны):
osquery> SELECT pid, name FROM processes;
+-------+------------------------------------+
| pid | name |
+-------+------------------------------------+
| 1 | systemd |
| 10 | rcu_sched |
| 10333 | kworker/u16:5-events_unbound |
| 10336 | kworker/2:0-events |
| 11 | migration/0 |
| 11002 | kworker/u16:1-kcryptd/253:0 |
| 11165 | kworker/1:1-events |
| 11200 | kworker/1:3-events |
| 11227 | bash |
| 11368 | osqueryi |
| 11381 | kworker/0:0-events |
| 11395 | Web Content |
| 11437 | kworker/0:2-events |
| 11461 | kworker/3:2-events_power_efficient |
| 11508 | kworker/2:2 |
| 11509 | kworker/0:1-events |
| 11510 | kworker/u16:2-kcryptd/253:0 |
| 11530 | bash |
[...] |
+-------+------------------------------------+
Можно даже выполнять запросы к объединенным таблицам с помощью оператора JOIN, как мы это делаем в реляционных базах данных.
В приведенном ниже примере мы выполняем запрос к таблице process , объединенной с users через столбец uid:
osquery> SELECT processes.pid, processes.name, users.username FROM processes JOIN
users ON processes.uid = users.uid;
+-------+-------------------------------+------------------+
| pid | name | username |
+-------+-------------------------------+------------------+
| 1 | systemd | root |
| 10 | rcu_sched | root |
| 11 | migration/0 | root |
| 11227 | bash | egdoc |
| 11368 | osqueryi | egdoc |
| 13 | cpuhp/0 | root |
| 14 | cpuhp/1 | root |
| 143 | kintegrityd | root |
| 144 | kblockd | root |
| 145 | blkcg_punt_bio | root |
| 146 | tpm_dev_wq | root |
| 147 | ata_sff | root |
[...]
| 9130 | Web Content | egdoc |
| 9298 | Web Content | egdoc |
| 9463 | gvfsd-metadata | egdoc |
| 9497 | gvfsd-network | egdoc |
| 9518 | gvfsd-dnssd | egdoc |
+-------+-------------------------------+------------------+
Мониторинг целостности файлов (FIM)
До сих пор мы использовали osquery через интерактивную оболочку: osqueryi.
Чтобы использовать FIM (Мониторинг целостности файлов), мы хотим вместо этого использовать демон osqueryd.
Через файл конфигурации мы предоставляем список файлов, которые мы хотим отслеживать.
Такие события, как изменения атрибутов с участием указанных файлов и каталогов, записываются в таблицу file_events.
Демон запускает запрос к этой таблице через заданный интервал времени и уведомляет в журналах, когда обнаруживаются новые записи.
Давайте посмотрим пример конфигурации.
Настройка конфигурации
Основной файл конфигурации для osquery – /etc/osquery/osquery.conf.
Файл не существует по умолчанию, поэтому мы должны его создать.
Конфигурация предоставляется в формате Json.
Предположим, мы хотим отслеживать все файлы и каталоги в /etc;
Вот как мы можем настроить приложение:
{
"options": {
"disable_events": "false"
},
"schedule": {
"file_events": {
"query": "SELECT * FROM file_events;",
"interval": 300
}
},
"file_paths": {
"etc": [
"/etc/%%"
],
},
}
Давайте проанализируем конфигурацию, показанную выше.
Прежде всего, в разделе параметров мы устанавливаем disable_events на «false», чтобы включить файловые события.
После этого мы создали раздел schedule: внутри этого раздела мы можем описывать и создавать различные именованные запланированные запросы.
В нашем случае мы создали запрос, который выбирает все столбцы из таблицы file_events, который должен выполняться каждые 300 секунд (5 минут).
После планирования запроса мы создали раздел file_paths, в котором мы указали файлы для мониторинга.
В этом разделе каждый ключ представляет собой имя набора файлов, которые нужно отслеживать (категория в жаргоне osquery).
В этом случае ключ «etc» ссылается на список только с одной записью, /etc/%%.
Что означает символ%?
При указании путей к файлам мы можем использовать стандартные (*) или символы SQL (%).
Если указан один подстановочный знак, он выбирает все файлы и каталоги, существующие на указанном уровне.
Если указан двойной подстановочный знак, он рекурсивно выбирает все файлы и папки.
Например, выражение /etc/% соответствует всем файлам и папкам на один уровень в /etc, в то время как /etc/%% рекурсивно соответствует всем файлам и папкам в /etc.
При необходимости мы также можем исключить определенные файлы из указанного нами пути, используя раздел exclude_paths в файле конфигурации.
В разделе мы можем ссылаться только на категории, определенные в разделе file_paths .
Мы предоставляем список файлов для исключения:
"exclude_paths": {
"etc": [
"/etc/aliases"
]
}
В качестве примера мы исключили файл /etc/aliases из этого списка.
Вот как выглядит наша окончательная конфигурация:
{
"options": {
"disable_events": "false"
},
"schedule": {
"file_events": {
"query": "SELECT * FROM file_events;",
"interval": 20
}
},
"file_paths": {
"etc": [
"/etc/%%"
]
},
"exclude_paths": {
"etc": [
"/etc/aliases"
]
}
}
Запуск демона
С нашей новой конфигурацией мы можем запустить демон osqueryd:
$ sudo systemctl start osqueryd
$ sudo systemctl enable osqueyd
$ sudo chmod 600 /etc/fstab
{
"name":"file_events",
"hostIdentifier":"fingolfin",
"calendarTime":"Mon Dec 30 19:57:31 2019 UTC",
"unixTime":1577735851,
"epoch":0,
"counter":0,
"logNumericsAsNumbers":false,
"columns": {
"action":"ATTRIBUTES_MODIFIED",
"atime":"1577735683",
"category":"etc",
"ctime":"1577735841",
"gid":"0",
"hashed":"0",
"inode":"262147",
"md5":"",
"mode":"0600",
"mtime":"1577371335",
"sha1":"",
"sha256":"",
"size":"742",
"target_path":"/etc/fstab",
"time":"1577735841",
"transaction_id":"0",
"uid":"0"
},
"action":"added"
}
В логах мы ясно видим, что действие ATTRIBUTES_MODIFIED (строка 10) произошло по пути target_path “/etc/fstab” (строка 23), который является частью категории “etc” (строка 12).
Важно отметить, что если мы запросим таблицу file_events из оболочки osqueryi, мы не увидим строк, так как демон osqueryd и osqueryi не взаимодействуют.