Как обнаружить события USB в Linux и создать автоматические действия

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

В этом практическом руководстве мы объединяем три столпа экосистемы: udev для обнаружения и реагирования в режиме реального времени, auditd для аудита действий и journald для запроса и сохранения журналов. Мы также рассмотрим такие утилиты, как lsusb и lsblk, для идентификации устройств, и включим раздел для смешанных сред с Windows, где централизация данных USB может быть полезна. Все объяснено на реальных примерах и с практическими рекомендациями.

Обнаружение устройств: udev, uevents и sysfs

Современный менеджер устройств пользовательского пространства — это udev (в современных системах это служба systemd-udevd ). Его назначение — обрабатывать события, генерируемые ядром при добавлении, удалении или изменении состояния устройства, создавать узлы в каталоге /dev , назначать права доступа и, при необходимости, выполнять скрипты.

Правила загружаются из каталогов /lib/udev/rules.d и /run/udev/rules.d , но вам следует написать свои собственные в /etc/udev/rules.d/ . Файлы .rules в этом каталоге имеют приоритет , поэтому это идеальное место для настройки поведения для событий USB.

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

$ sudo udevadm monitor

При подключении устройства ядро ​​предоставляет доступ к атрибутам в каталоге /sys (sysfs). udev получает оттуда серийные номера, основной/дополнительный IP-адрес, тип шины и другую информацию для уникальной идентификации оборудования. Вы можете проверить, что udev знает об устройстве, с помощью команды:

$ sudo udevadm info /dev/sdb

Если вам просто нужно найти присвоенное имя блока (например, для USB-накопителя), достаточно команды `lsblk` , поскольку она объединяет данные из sysfs и базы данных udev. Это позволяет быстро найти `/dev/sdb1` или что-то подобное .

$ lsblk

Запускать скрипты при подключении и извлечении USB

Классический подход предполагает запуск одного скрипта при обнаружении события ADD , а другого — при возникновении события REMOVE . Мы создадим два простых скрипта , которые будут записывать данные в лог:

$ sudo sh -c 'cat >/bin/device_added.sh <<"EOF"'
#!/bin/bash
echo "Dispositivo USB agregado en fecha: $(date)" >>/tmp/scripts.log
EOF
$ sudo sh -c 'cat >/bin/device_removed.sh <<"EOF"'
#!/bin/bash
echo "Dispositivo USB eliminado en fecha: $(date)" >>/tmp/scripts.log
EOF
$ sudo chmod +x /bin/device_added.sh /bin/device_removed.sh

Теперь определите правило udev в файле /etc/udev/rules.d/80-usb-actions.rules , чтобы запускать эти скрипты только для USB-устройств на уровне устройства (а не интерфейсов):

SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", RUN+="/bin/device_added.sh"
SUBSYSTEM=="usb", ACTION=="remove", ENV{DEVTYPE}=="usb_device", RUN+="/bin/device_removed.sh"

В этих строках SUBSYSTEM, ACTION и ENV{…} — это поля соответствия, а RUN+= определяет команду для выполнения. В правилах вы увидите два ключевых оператора :

• ==: сравнивает равенство в области (например, действие или подсистема).
• +=: добавляет значение в список (используется для накопления) команды в режиме RUN).

Загрузите изменения без перезапуска, просто перезагрузив менеджер udev , и проверьте, подключая/отключая USB-накопитель, чтобы убедиться, что файл журнала обновляется.

$ sudo udevadm control --reload
$ ls -l /tmp/scripts.log
$ cat /tmp/scripts.log

Полезный совет: Избегайте запуска длительных задач непосредственно из команды RUN . Если вам нужен ресурсоемкий процесс, вызовите скрипт, который делегирует выполнение задач службе systemd или службе очереди; таким образом, вы не будете блокировать обработку событий.

Аудит акций с помощью auditd

Помимо простого реагирования на аппаратные события, вас может заинтересовать аудит действий пользователей после подключения USB-устройства: выполняемые команды, доступ к файлам, изменения прав доступа и т. д. Именно здесь на помощь приходит auditd , служба аудита ядра Linux.

Установите его из репозиториев вашего дистрибутива и изучите его основную конфигурацию в файле /etc/audit/auditd.conf . Некоторые важные параметры , которые следует изменить:

• журнальный файл: путь к журналу, по умолчанию /var/log/audit/audit.log.
• промывать y частота: управление частотой сброса трассировок из памяти на диск.
• max_log_file: максимальный размер (МБ) файла аудита.
• max_log_file_action: что делать, когда вы достигли максимума. Типичные варианты: игнорировать, системный журнал, приостановить, вращать, keep_logs.
• num_logs: сколько файлов хранить при использовании вращать.
• пробел_левый: Порог свободного места (МБ) в файловой системе журнала, из которой следует запускать пробел_левое_действие.
• пробел_левое_действие: реакция на ограниченное пространство. Поддерживает игнорировать, системный журнал, вращать, e-mail (используйте учетную запись в action_mail_acct), exec /path/script, приостановить, стой.
• disk_full_action: аналогично пробел_левое_действие когда диск заполнен.

Настоящая мощь auditd заключается в его правилах . Разместите их в файле /etc/audit/rules.d/ с расширением .rules. Например, чтобы регистрировать каждую команду, выполненную определенным пользователем:

-a always,exit -S execve -F euid=strsistemas -k acciones_usuario

Здесь мы указываем: `always,exit` для обязательного аудита в конце вызова, `execve` в качестве целевого системного вызова, фильтрацию по euid пользователя и тег `-k` для удобного поиска в дальнейшем. Не забудьте перезапустить или перезагрузить службу после добавления правил.

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

$ sudo ausearch -k acciones_usuario

Благодаря грамотному сочетанию udev (запуск триггеров) и auditd (отслеживание), вы получаете полную картину : кто что-то подключил, что произошло дальше и с помощью каких команд.

Просмотр, фильтрация и сохранение журналов с помощью journald

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

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

$ journalctl -p err
$ journalctl --since '2024-01-01' --until '2024-01-02'
$ journalctl -u systemd-udevd.service
$ journalctl -f

Для управления размером журнала проверьте его использование и примените политики очистки . Обычно ограничивают размер по общему объему, чтобы предотвратить неконтролируемый рост.

$ journalctl --disk-usage
$ sudo journalctl --vacuum-size=500M

Конфигурация находится в файле /etc/systemd/journald.conf . К числу интересных параметров относятся:

• Хранение=авто: Автоматически выбирает способ и место сохранения.
• MaxFileSec=1месяц: определяет временное хранение для каждого файла.
• RateLimitBurst=1000: Ограничивает всплески событий, чтобы избежать журнальных штормов.
• ForwardToSyslog=да: Пересылать в syslog при необходимости для устаревших интеграций.

Благодаря сочетанию auditd и journald вы получаете лучшее из обоих миров: подробный аудит и гибкие запросы с мощными фильтрами и контролем хранилища.

Определите и поймите свои устройства: lsusb, lsusb -tv и lsblk

Для инвентаризации подключенных к USB-шине устройств классическим инструментом является `lsusb` . Он выводит список шин, устройств и их идентификаторов поставщика и продукта (vendor:product ID ), что необходимо для написания специальных правил udev.

$ lsusb
Bus 004 Device 007: ID 0951:1642 Kingston Technology ...
...

Если вы хотите увидеть топологию в древовидном формате, добавьте параметр -t , а для большей детализации — -v . Таким образом, вы сможете различить корневой концентратор, контроллеры и порты , а также определить, какой драйвер обрабатывает каждый интерфейс.

$ lsusb -tv
/ : Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
...

Для блочных устройств команда lsblk отображает диски, разделы и точки монтирования. Такие поля, как RM (съемный) или RO (только для чтения), предоставляют информацию о типе устройства.

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk
└─sda1   8:1    0 924.1G  0 part /
sr0     11:0    1 1024M   0 rom

В сочетании с командой `udevadm info` вы получите серийные номера и свойства, которые можно использовать для создания постоянных правил . Например, вы можете привязать определенный USB-накопитель к символической ссылке в `/dev` на основе его серийного номера.

Централизация и смешанные среды (включая Windows)

В корпоративной среде централизация событий USB полезна для обеспечения прозрачности и соответствия нормативным требованиям. Двумя гибкими альтернативами являются инструменты управления конечными точками или решение SIEM для корреляции и оповещения.

• Управление конечной точкой (Microsoft Endpoint Manager, ManageEngine, Ivanti): политики, инвентаризация и отчеты о подключенных USB-устройствах.
• SIEM (Splunk, Elastic Stack): прием событий, панели мониторинга и оповещения в реальном времени против подозрительных связей.

Если вам требуется что-то нестандартное в Windows, вы можете собирать информацию с USB-накопителей с помощью PowerShell и отправлять её по HTTP на сервер , который хранит журналы. В этом примере происходит обнаружение USB-накопителей и публикация данных в API:

# Detectar dispositivos USB en Windows y enviar a un API
Get-WmiObject Win32_DiskDrive | Where-Object { $_.InterfaceType -eq 'USB' } |
ForEach-Object {
  [PSCustomObject]@{
    DeviceID = $_.DeviceID
    Model   = $_.Model
    Serial  = (Get-WmiObject Win32_PhysicalMedia | Where-Object { $_.Tag -eq $_.DeviceID }).SerialNumber
  }
} | ConvertTo-Json | Invoke-RestMethod -Uri 'http://servidorcentral/api/usblog' -Method Post

С помощью минимального сервера Flask на Python вы можете легко сохранять эти события. Вот рабочий шаблон, который получает JSON и записывает его в файл:

from flask import Flask, request, jsonify
app = Flask(__name__)

@app.route('/api/usblog', methods=['POST'])
def log_usb_data():
    data = request.get_json()
    if not data:
        return jsonify({'error': 'No se enviaron datos'}), 400
    with open('usb_log.txt', 'a') as f:
        f.write(f"{data}\n")
    return jsonify({'message': 'Datos recibidos correctamente'}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Чтобы запустить сценарий PowerShell при загрузке системы, используйте планировщик задач , установив в качестве триггера запуск системы или сессии и выбрав флажок « Запустить с наивысшими привилегиями» ; или создайте файл .bat в папке «Автозагрузка»:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File 'C:\ruta\script.ps1'

Просмотр событий Windows для USB

В журнале событий Windows отображается очень полезная информация в разделе Microsoft > Windows > DriverFrameworks-UserMode > Operational . Включите это оперативное ведение журнала, и вы увидите события 2003 (подключение) и 2102 (отключение) , включая тип устройства (например, хранилище), производителя/модель и серийный номер.

Обратите внимание, что если вы измените схему разделов USB-накопителя (например, преобразуете его в GPT или создадите разделы), идентификаторы могут измениться . Вы можете проверить соответствие с помощью Диспетчера устройств (путь к экземпляру, права собственности или связи удаления). Чтобы ускорить процесс, создайте пользовательское представление с фильтрацией по идентификаторам 2003 и 2102.

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

На настольных компьютерах с шиной PCI проверку оборудования можно выполнить с помощью команды lspci . Если вы хотите подтвердить обнаруженную системой видеокарту без вскрытия корпуса , просто выполните следующие действия:

$ lspci | grep -i vga
$ lspci -v -s <bus:device.func>

На ARM-платах, таких как Raspberry Pi, вы не найдете эту команду на многих моделях, потому что там нет шины PCIe, доступной таким же образом . Это архитектурное различие: указывать PCI там бессмысленно.

Если вы тестируете параметры модуля ядра (например, Bluetooth ) и не можете выгрузить их с помощью `modprobe -r` , проверьте, используются ли они зависимостями или службами , или же эта функциональность интегрирована в ядро ​​(а не является модулем). В этом могут помочь следующие проверки:

$ lsmod | grep -E 'bluetooth|btusb'
$ sudo systemctl stop bluetooth.service
$ sudo modprobe -r btusb bluetooth

Для проверки наличия уязвимостей, подобных Meltdown , в последних версиях ядра, ядро ​​предоставляет доступное для чтения состояние в каталоге /sys . Быстрое ознакомление с ним покажет, защищена ли ваша система от уязвимостей или же она уязвима:

$ cat /sys/devices/system/cpu/vulnerabilities/meltdown

На маршрутизаторах Linux с одним блочным устройством при подключении USB-накопителя он обычно отображается как /dev/sda (и его разделы /dev/sda1 и т. д.) . Подтвердите это с помощью команды `lsblk` , а если сомневаетесь, сравните информацию с результатами команд `lsusb` и `udevadm info`, чтобы определить новое добавление.

Лучшие практики для правил и ведения журнала

При разработке правил udev используйте точную фильтрацию , чтобы избежать ложных срабатываний. Объедините SUBSYSTEM , ACTION и ENV{DEVTYPE} и, при необходимости, атрибуты, такие как idVendor или idProduct , чтобы реагировать только на соответствующее оборудование.

Старайтесь, чтобы скрипты, запускаемые udev, были как можно более легковесными . Если вам требуется выполнять ресурсоемкие задачи (шифрование, резервное копирование, анализ), перенаправляйте данные в службу systemd с параметром Type=simple/oneshot и вызывайте ее из скрипта, чтобы избежать блокировки очереди событий.

В auditd определите правила с тегами (-k) , которые позволят вам легко осуществлять поиск с помощью ausearch . И настройте ротацию и действия при нехватке места (например, rotate + num_logs или выполнить скрипт очистки), чтобы избежать неожиданностей.

При использовании journald настройте ограничения на время хранения и пиковую нагрузку в файле journald.conf, чтобы сбалансировать использование постоянного хранилища и дискового пространства. Если вы работаете с SIEM-системой, включите ForwardToSyslog или используйте ввод journalbeat / systemd в Logstash/Fluentd в зависимости от вашей системы.

Наконец, в регулируемых средах следует рассмотреть возможность централизации событий USB (Linux и Windows) в едином репозитории. Это позволит создавать более полные системы оповещений и аудита , соблюдать политики безопасности и упростит расследования.

Благодаря всему вышеперечисленному, у вас получается надежный рабочий процесс: udev обнаруживает и выполняет все необходимые действия на лету, auditd регистрирует активность пользователей с высокой степенью детализации, а journald сохраняет и упрощает запросы . Завершите процесс, интегрировав аутентификацию с lsusb/lsblk, а если вы работаете в смешанных средах, добавьте уровень централизации и события Windows Viewer для полного сквозного охвата.