Клиент LSUS USB Control

Назначение компонента¶

LSUS USB Control — сервис контроля USB-накопителей и CD/DVD на рабочей станции Linux. Для администратора это инструмент учёта и ограничения доступа к сменным носителям: сервис получает решения с сервера, применяет локальные правила и даёт в интерфейсе LSUS видимость того, что происходит с устройствами на хосте.

Компонент работает вместе с lsus-client и обычно использует тот же серверный контур.

Где используется¶

USB Control устанавливают на рабочие станции Linux, где требуется:

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

Если в организации нет сценария контроля USB, этот компонент можно не разворачивать.

Что делает USB Control на станции¶

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

Для администратора важно, что это не только сервис инвентаризации, но и точка фактического принудительного применения политики на хосте.

Как компонент связан с сервером¶

USB Control использует те же базовые параметры доступа, что и клиент LSUS:

URL сервера;
TLS-настройки;
токен API.

По умолчанию эти параметры берутся из конфигурации lsus-client, но при необходимости могут быть переопределены в собственной конфигурации USB Control.

Ключевые серверные вызовы нужны для трёх задач:

передача событий о подключении устройств;
получение разрешений;
отправка регистраций устройств.

Инвентаризация USB-устройств¶

lsus-usb-control не только блокирует и разрешает носители, но и регулярно отправляет на сервер полный снимок всех USB-устройств хоста.

Компонент раз в несколько минут (примерно раз в 10 минут) формирует полный снимок всего, что сейчас подключено к USB-шине, и отправляет его через:

POST /api/v1/clients/usb/inventory

Как формируется снимок¶

Снимок строится напрямую из sysfs — без вызова внешних утилит. Источник: /sys/bus/usb/devices. Для каждого обнаруженного устройства собираются:

Поле	Описание
`vendor_id` / `product_id`	VID:PID в hex (например, `12d1:1506`)
`manufacturer`	Производитель (раскодированный из дескриптора)
`model`	Название продукта/модели
`device_class`	Класс: Mass Storage / HID / Printer / Hub / Communications / …
`serial_number`	Серийный номер, если устройство его отдаёт

infoСнимок vs блокировка

Инвентаризация — это учёт, а не контроль доступа. В снимок попадают все подключённые USB-устройства, даже если доступ к сменным носителям не ограничен политикой. Таким образом администратор видит реальную картину подключённой периферии независимо от того, работают ли в организации правила блокировки.

Где это видно на сервере¶

На сервере снимок сохраняется в модели HostUsbInventory с привязкой к конкретному хосту.
Отображается в Хосты → Инвентаризация → USB (см. Хосты → Подвкладка «Инвентаризация»).
Доступен через API: GET /api/v1/admin/hosts/<id>/inventory/hardware (включает USB) и GET /api/v1/admin/hosts/<id>/inventory/usb.
Для внешних систем — через публичный Inventory API v2, endpoint GET /api/v2/inventory/hosts/{id}/usb.

lightbulbСнимок всегда свежий

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

Что администратор обычно настраивает¶

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

запущен ли lsus-client;
зарегистрирован ли хост на Master или Site;
доступен ли токен API;
стартует ли сервис lsus-usb-control;
создаются ли правила udev;
видны ли события устройства в серверном интерфейсе.

Если хост ещё не зарегистрирован и токена нет, USB Control обычно не сможет перейти к нормальной работе.

Поведение для пользователя¶

пользователь получает уведомления о том, разрешено устройство или заблокировано;
часть сообщений может дублироваться через трей LSUS Client;
решение о доступе к устройству принимается не пользователем локально, а политикой сервера.

Это важно для первой линии поддержки: многие пользовательские обращения про «флешка не открывается» на самом деле являются штатным поведением USB Control.

Локальное применение правил¶

Компонент использует udev и создаёт правила в /etc/udev/rules.d. В зависимости от ответа сервера он либо:

выдаёт доступ пользователю;
либо запрещает монтирование устройства.

Практическое следствие: при расследовании проблем с USB нужно проверять не только интерфейс Master, но и фактические локальные правила на рабочей станции.

Конфигурация и журналы¶

Путь	Назначение
`/etc/lsus-usb-control/lsus-usb-control.conf`	Основная конфигурация сервиса
`/var/log/lsus-usb-control.log`	Журнал работы

В конфигурации администратора в первую очередь интересуют:

параметры опроса сервера;
каталог правил;
префиксы файлов правил;
группа и режим для разрешённых устройств;
параметры уведомлений и логирования.

Признаки исправной работы¶

USB Control можно считать работоспособным, если:

сервис запущен;
хост зарегистрирован в LSUS;
при подключении носителя в журнале появляется событие;
на сервер передаётся информация о носителе;
разрешённое устройство получает доступ, а запрещённое блокируется;
администратор видит соответствующие события в интерфейсе Master или Site.

Типовые проблемы¶

Диагностику нужно начинать с USB Control, если:

носители не блокируются или блокируются неожиданно;
на сервере не появляются события по USB;
сервис не может получить разрешения;
после установки компонента не создаются правила udev;
пользователь получает уведомления, но сервер не отражает реальное состояние.

На практике проверяют по порядку:

зарегистрирован ли хост и работает ли lsus-client;
доступен ли токен API;
запущен ли lsus-usb-control.service;
есть ли записи в /var/log/lsus-usb-control.log;
применились ли правила в /etc/udev/rules.d;
видны ли события в интерфейсе LSUS.

Если хост не зарегистрирован и токен не выдан, сначала запускают клиент LSUS, затем перезапускают USB Control.

Сервис и зависимости¶

сервис: lsus-usb-control.service;
зависимости Python: python3-pyudev, python3-requests и зависимости пакета.

Что важно для сопровождения¶

сопровождать USB Control отдельно от клиента нельзя: сначала должен быть исправен контур lsus-client;
после изменения серверной политики по USB нужно проверять реальное поведение носителя на тестовой станции;
при разборе инцидентов ориентироваться сразу на три точки: журнал сервиса, локальные udev-правила и события в Master или Site.