osquery для инвентаризации и безопасности: запросы и задачи

Зачем osquery в инвентаризации и безопасности

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

Один антивирус обычно видит только часть картины. Он ловит известные угрозы, но не всегда объясняет, почему на компьютере появился новый автозапуск, откуда взялся лишний сервис или почему устройство перестало обновляться. А инвентаризация «по спискам» часто устаревает уже через неделю: кто-то поставил утилиту, подключил модем по USB, отключил службу обновлений, и это не попало в учет.

Сильная сторона osquery в том, что результаты легко превращаются в понятные ИТ-задачи. Полезнее всего не «все данные сразу», а отклонения:

• неизвестные или неучтенные устройства и ПО
• подозрительные точки автозапуска и закрепления
• подключения USB и съемных носителей не по правилам
• отставание по патчам и обновлениям
• критичные службы, которые остановлены или настроены странно

Простой пример: в школе или госорганизации видно, что на части ПК внезапно появился новый автозапуск и отключилась служба обновлений. Это не «инцидент в вакууме», а конкретный план: проверить источник установки, удалить лишнее, вернуть политики, обновить системы и закрыть повтор.

Важно помнить границы: osquery не «лечит» и не блокирует сам по себе. Он дает быстрый снимок реальности, чтобы вы могли принять решение и выполнить работу через свои инструменты управления и поддержки.

Как устроен osquery простыми словами

osquery - это агент, который превращает компьютер в набор таблиц, похожих на базы данных. Вы задаете SQL-запрос, а агент отвечает фактами: что запущено, что установлено, какие пользователи есть, какие устройства подключали.

Он подходит для рабочих станций, серверов, VDI и тестовых машин. Особенно удобно, когда парк разный: офисные ПК, серверы в стойках, виртуальные рабочие места. Источник данных один и тот же: сам хост.

Чаще всего используют «таблицы» про процессы и службы, пакеты и обновления, пользователей и группы, сетевые настройки, устройства (в том числе USB). Важно, что вы не «сканируете сеть», а спрашиваете каждый компьютер о его состоянии.

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

Чтобы старт был спокойным, заранее договоритесь о минимальном наборе проверок и о том, как хранить результаты. Практичный минимум на первые 2-3 недели:

• инвентаризация ОС и установленных пакетов
• аудит автозапуска и планировщика
• контроль подключений USB
• уровень патчей и даты последних обновлений
• состояние нескольких критичных служб (например, антивирус, журналирование)

Так вы получите пользу быстро и не утонете в данных уже на первой неделе.

Пошагово: как внедрить и запустить первые проверки

Начните не с запросов, а с целей. osquery можно использовать по-разному: собрать список активов, проверить соответствие политике, делать регулярные контрольные замеры или помогать в расследованиях. Если смешать все сразу, вы утонете в данных.

Дальше разложите парк на понятные группы устройств. Обычно хватает 3-6 групп: бухгалтерия, обычные офисные ПК, администраторы, ноутбуки, критичные серверы. Так проще задавать разные частоты проверок и быстрее понимать, где отклонения действительно важны.

Для старта сделайте пилот на небольшой группе и проверьте две вещи: нагрузку и качество данных. Например, возьмите 20-50 рабочих станций и пару серверов, запустите несколько простых запросов (ПО, автозапуск, USB, патчи) и посмотрите, нет ли пропусков, странных значений и скачков по CPU или диску.

Минимальный план пилота:

• сформулировать 3-5 проверок, которые дадут пользу за неделю
• определить группы устройств и ответственных владельцев
• запланировать частоту запусков (разово и по расписанию)
• решить, где хранить результаты и кто их разбирает
• сделать короткий отчет: что нашли, что исправляем, что уточняем

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

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

Инвентаризация: быстрые запросы, которые дают пользу

Начните с проверок, которые отвечают на простые вопросы: что это за компьютер, кто им управляет, что на нем стоит и что он открывает в сеть. Это дает видимость по парку и быстро показывает «не совпадает с нормой».

1) Базовые сведения об активе

Соберите минимум: имя хоста, ОС и версию, аптайм. Где возможно, добавьте серийный номер.

SELECT hostname, cpu_brand, physical_memory FROM system_info;
SELECT name, version, build, platform FROM os_version;
SELECT * FROM uptime;

Если в части устройств пусто поле серийного номера или «скачет» имя хоста, это уже задача: привести к стандарту учет и правила именования.

2) Пользователи и локальные админы

Слабое место инвентаризации - «тихие» локальные админы. Проверьте, кто есть на машине, и где это нетипично.

SELECT username, type, shell FROM users;
SELECT user, groupname FROM user_groups WHERE groupname IN ('Administrators','sudo');

3) Что установлено и что выглядит подозрительно

Снимите список пакетов с версиями (таблица зависит от ОС). Дальше сравнивайте не весь список, а отклонения.

SELECT name, version FROM programs ORDER BY name;

4) Базовые сетевые факты

Нужны интерфейсы и то, что слушает порты прямо сейчас, с привязкой к процессам.

SELECT interface, address, mask FROM interface_addresses;
SELECT pid, port, protocol, address FROM listening_ports;
SELECT pid, name, path FROM processes;

Чтобы отчеты не превратились в «простыню», заранее определите норму: допустимые ОС и минимальные версии, правила по локальным админам, базовый набор ПО для каждой роли и ожидаемые открытые порты. Дальше показывайте только различия: устройство - отклонение - риск - кому в работу.

Примеры запросов: автозапуск и закрепление в системе

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

Windows: Run-ключи, автозагрузка, планировщик

Начните с Run и RunOnce в реестре, а затем проверьте задания планировщика и ярлыки в папках автозагрузки.

-- Run / RunOnce
SELECT key, name, data
FROM registry
WHERE key IN (
  'HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run',
  'HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce',
  'HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run',
  'HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce'
);

-- Планировщик
SELECT name, path, action, enabled, state, last_run_time
FROM scheduled_tasks
WHERE enabled = 1;

-- Папки автозагрузки (пример: ищем файлы)
SELECT path, size, mtime
FROM file
WHERE path LIKE 'C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\%'
   OR path LIKE 'C:\\Users\\%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\%';

macOS и Linux: launchd, cron, systemd

На macOS полезно собрать launchd элементы, на Linux - cron и systemd units.

-- macOS: launchd
SELECT name, program, program_arguments, run_at_load, keep_alive, path
FROM launchd
WHERE run_at_load = 1 OR keep_alive = 1;

-- Linux: cron
SELECT username, command, path
FROM crontab;

-- Linux: systemd (включенные юниты)
SELECT name, description, fragment_path, unit_file_state
FROM systemd_units
WHERE unit_file_state = 'enabled';

Частые признаки, которые стоит разбирать в первую очередь: запуск из user-writable директорий (AppData, Downloads, /tmp, домашняя папка), временные папки, странные аргументы (base64, скрытые окна, цепочки через cmd/powershell/bash), «похожее на системное» имя при не системном пути.

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

Примеры запросов: USB и съемные носители

USB - частый канал утечек и заражений, но и обычный рабочий инструмент. Поэтому цель проверок не в том, чтобы «запретить все», а в том, чтобы видеть факты: что подключали, где, когда и кто за это отвечает.

Полезные запросы

Для быстрого снимка подключенных устройств (там, где это поддерживается) начните с таблицы usb_devices. Она показывает базовые признаки вроде VID, PID и (иногда) серийного номера.

SELECT
  vendor, vendor_id, model, model_id, serial,
  removable, uuid
FROM usb_devices;

История подключений зависит от ОС. Например, на macOS можно искать следы по usb_device_history и отфильтровать новые подключения за последние N дней.

SELECT
  vendor, model, serial, time
FROM usb_device_history
WHERE time > (strftime('%s','now') - 14*24*60*60)
ORDER BY time DESC;

На Windows часто проще опираться на артефакты в реестре. Идея такая: искать ключи USBSTOR и вытаскивать идентификаторы и метки времени.

SELECT
  key, name, data, mtime
FROM registry
WHERE key LIKE 'HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USBSTOR\\%'
ORDER BY mtime DESC;

Как превращать находки в задачи

Одна запись о новом USB-накопителе не равна инциденту, но это хороший повод создать понятную задачу. Полезно сразу сопоставлять хост с владельцем или подразделением по данным учетной системы (инвентаризация, CMDB, HR-справочник), чтобы не тратить время на «чей это ноутбук».

Обычно дальше все сводится к нескольким типам работ: подтвердить факт использования и контекст (какой ПК, какой пользователь, когда), запросить обоснование, если USB запрещен для группы, оформить исключение по конкретному устройству (по серийному номеру), усилить политику для выбранных групп (блокировка или «только чтение»), поставить регулярную проверку «новые USB за N дней» для критичных сегментов.

Примеры запросов: патчи и уровень обновлений

Патчи и обновления часто становятся «тихой» причиной инцидентов: уязвимость уже закрыта у большинства, а несколько машин остаются на старой сборке или без нужного KB. Здесь удобно начать с простого: версия ОС, номер сборки и признаки того, что обновления давно не ставились.

Базовый уровень: версия ОС и сборка

Сначала соберите то, что почти всегда доступно:

SELECT name, version, build, platform, arch
FROM os_version;

На Windows одной этой строки часто достаточно, чтобы увидеть «выпавшие» устройства: одинаковая версия, но разные build, или устаревшая ветка.

Windows и Linux: признаки установленных обновлений

На Windows можно фиксировать список установленных обновлений, если таблица есть в вашей сборке osquery:

SELECT hotfix_id, installed_on, caption
FROM patches
ORDER BY installed_on DESC;

Для Linux чаще полезнее смотреть версии пакетов и сравнивать с вашей минимально допустимой версией:

SELECT name, version, source, install_time
FROM packages
WHERE name IN ('openssl','sudo','openssh-server')
ORDER BY name;

Отдельно хорошо работает эвристика «не обновлялись X дней». Если install_time заполняется, можно искать машины, где ключевые пакеты не менялись слишком давно:

SELECT name, version, datetime(install_time, 'unixepoch') AS installed
FROM packages
WHERE name IN ('openssl','sudo')
  AND install_time < (strftime('%s','now') - 60*60*24*90);

Результаты лучше переводить в действия: запланировать окно обслуживания для групп с устаревшей сборкой или отсутствующим KB, согласовать тестирование обновлений на пилотной группе (особенно для критичных систем), завести исключения с датой пересмотра, зафиксировать минимальные версии как правило и проверять их регулярно.

Примеры запросов: критичные службы и их состояние

Критичные службы - это те, без которых вы быстро теряете контроль: аутентификация, защита, резервное копирование, сбор журналов. Список у каждой организации свой. Часто туда попадают доменные службы и DNS, агент EDR/антивирус, агент резервного копирования, SIEM-агент, служба удаленного управления (если вы ее используете).

Задача простая: проверить, что служба запущена, что тип запуска не изменен на Manual/Disabled и что путь к бинарнику выглядит ожидаемо.

-- Windows: статус и автозапуск по выбранным службам
SELECT name, display_name, status, start_type, pid, user_account, path
FROM services
WHERE name IN ('WinDefend','W32Time','Dnscache');

-- Windows: подозрительная смена пути (не из System32, Program Files и т.п.)
SELECT name, status, start_type, path
FROM services
WHERE start_type != 'DISABLED'
  AND path NOT LIKE 'C:\\Windows\\System32%'
  AND path NOT LIKE 'C:\\Program Files%'
  AND path NOT LIKE '"C:\\Program Files%';

-- Linux: важные systemd юниты (пример)
SELECT name, load_state, active_state, sub_state, fragment_path
FROM systemd_units
WHERE name IN ('sshd.service','rsyslog.service');

Если хотите добавить проверку целостности на уровне фактов, фиксируйте путь и аргументы запуска, а на Windows дополнительно проверяйте подпись исполняемого файла.

-- Windows: проверка подписи файла службы (если таблица доступна)
SELECT s.name, s.path, a.subject_name, a.issuer_name, a.result
FROM services s
LEFT JOIN authenticode a ON a.path = TRIM(s.path, '"')
WHERE s.name IN ('WinDefend');

Дальше отделите риск от рутины. Если служба отключена или переведена в Manual, это обычно отдельный инцидент. Если изменился путь к бинарнику или подпись невалидна, это повод для расследования.

Как превращать результаты osquery в ИТ-задачи

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

Удобно разделять находки по смыслу:

• инцидент: явный риск или след атаки (например, неизвестный автозапуск на критичном сервере)
• отклонение от стандарта: настроено не по базовой политике
• техдолг: старые версии, просроченные патчи, забытые исключения
• запрос на уточнение: данных мало, нужно подтвердить у владельца системы

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

• что найдено: конкретная строка/значение (служба, путь, устройство, KB, версия)
• где найдено: список хостов или группа
• почему важно: риск злоупотребления или влияние на бизнес (простои, утечки, требования регулятора)
• что сделать: точное действие
• критерий «исправлено»: как проверить повторным запросом и какой результат считать нормой

Приоритизацию проще всего считать по четырем факторам: критичность системы, массовость (1 хост или 300), вероятность злоупотребления (USB, автозапуск), требования регулятора. Минимальные SLA можно держать простыми: срочно (до часа) для инцидентов, быстро (до суток) для массовых отклонений, планово (в ближайший спринт или окно) для техдолга.

Назначайте владельца по природе работы: ИБ разбирает инциденты и правила, Windows- и Linux-админы чинят конфигурацию и патчи, сервис-деск делает первичный контакт с пользователем (например, кто и зачем подключал USB-накопитель).

Частые ошибки и ловушки при использовании osquery

Самая частая проблема - начать с десятков проверок сразу. Данных становится много, отчеты растут, а понятных действий нет. Гораздо практичнее выбрать 5-10 вопросов, которые реально влияют на риск и трудозатраты: автозапуск, USB, патчи, критичные службы.

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

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

Как не утонуть в данных

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

Почему задачи не двигаются

Даже хорошие находки умирают без владельца. osquery показал, что на части рабочих станций разрешены новые USB-устройства, и пара ПК имеет неожиданные элементы автозапуска. Если не назначить ответственного (ИТ-операции, ИБ, владелец сервиса) и не договориться о сроках, результат останется в таблице.

Рабочая дисциплина выглядит так:

• ограничить стартовый набор запросов и критерии «красного» события
• привести хосты и группы к одному стандарту, убрать дубли
• вести список исключений с причиной и сроком пересмотра
• хранить историю и смотреть изменения, а не только «срез»
• сразу привязывать находку к исполнителю и следующему шагу

Короткий чеклист: что проверить перед запуском в прод

Перед тем как включать osquery на всех компьютерах, договоритесь о правилах: какие данные вы собираете, кто их смотрит и что делать с находками. Иначе даже полезные сигналы быстро превратятся в шум.

Минимальный набор, который обычно дает быстрый эффект:

• Определите группы устройств и владельцев: хотя бы «ноутбуки сотрудников», «серверы», «киоски/общие ПК». Для каждой группы зафиксируйте базу: ОС, роль, подразделение или ответственный.
• Подготовьте 5 обязательных контролей и проверьте, что они работают на вашей ОС: автозапуск, USB и съемные носители, уровень патчей/обновлений, состояние критичных служб, список локальных администраторов.
• Задайте пороги, чтобы находки были однозначными: «появилось новое за 7 дней», «не обновлялось 30 дней», «служба остановлена», «пользователь добавлен в админы». Порог должен быть одинаковым для всей группы устройств.
• Подготовьте шаблон ИТ-задачи и правило приоритета (например, сервер + критичная служба = высокий).
• Проверьте качество на пилоте: результаты на 10-20 устройствах должны повторяться в проде по той же логике.

Практичный тест перед «боевым» запуском: возьмите одну находку (например, новый элемент автозапуска на ноутбуке) и проведите ее путь до закрытой задачи. Если на этом пути есть спорные места, лучше поправить процесс заранее.

Пример реальной ситуации: от находки до плана работ

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

Сначала берут только компьютеры бухгалтерии и терминальные серверы, и только последние 14 дней. Дальше запускают три короткие проверки: какие USB-устройства подключались, что появилось в автозапуске, и какие защитные службы отключены.

Примеры запросов, которые часто дают первые зацепки:

-- USB: что сейчас подключено (полезно для точки "здесь и сейчас")
SELECT * FROM usb_devices;

-- Автозапуск: новые/подозрительные элементы
SELECT name, path, source FROM startup_items;

-- Службы: что остановлено из важного
SELECT name, status, start_type FROM services
WHERE status != 'RUNNING';

-- Патчи (для Windows): что установлено и когда
SELECT hotfix_id, installed_on FROM patches;

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

Чтобы не повторять один и тот же разбор каждый месяц, закрепляют практику: добавляют постоянные проверки (USB, автозапуск, статус служб, уровень патчей), задают простые пороги и договариваются, кто и как быстро реагирует.

Следующие шаги: как закрепить практику и не утонуть в данных

Чтобы osquery реально помогал, не гонитесь за сотнями проверок. Начните с небольшого набора запросов, которые дают понятные действия: автозапуск, USB, патчи, критичные службы. На каждый тип находки заранее назначьте владельца: кто исправляет и кто подтверждает закрытие.

Рабочий стартовый подход:

• Выберите 10-15 запросов и зафиксируйте, что считается отклонением.
• Назначьте ответственных по категориям (рабочие станции, серверы, ИТ, ИБ) и сроки реакции.
• Запустите пилот на одной группе (например, 50 ПК в одном подразделении) и посчитайте: сколько находок, сколько закрыли за неделю, что оказалось шумом.
• Уберите лишнее и добавьте то, что часто всплывает в пилоте.

Отчеты делайте максимально короткими: показывайте только отклонения и статус. В идеале каждая строка отчета превращается в задачу с полями: устройство, находка, риск, владелец, дедлайн, подтверждение.

Если вы строите такую практику в большой инфраструктуре, заранее продумайте, как результаты будут попадать в процессы поддержки и управления изменениями. В проектах, где нужна и поставка оборудования, и системная интеграция, это часто закрывают одним контуром: например, GSE.kz как производитель и системный интегратор может помочь спланировать внедрение, подобрать инфраструктуру (включая рабочие станции и серверы) и организовать поддержку 24/7.