Аудит USB-пристроїв та блокування небажаних (скриптово)

Модель загроз: чому USB — ризик для продуктивних систем

USB — це не просто «порт». Це шина з постачанням живлення, гарячим підключенням, множиною класів пристроїв і довгою історією
припущень «довіряй пристрою, бо що ще залишається робити?». Це нормально для робочого ноутбука. Це ризиковано для сервера,
який зберігає облікові дані, дані клієнтів або щось, за що буде соромно звітувати перед аудиторським комітетом.

Найпоширеніші операційні відмови не потребують кіберкінематичної шкідливості:

• Екфільтрація даних: масове USB-сховище монтується, хтось копіює кілька директорій — день зіпсовано.
• Ін’єкція натискання клавіш: пристрій заявляє, що він клавіатура (HID), і вводить команди швидше, ніж людина моргне.
• Поворот у мережу: «USB Ethernet» з’являється та створює новий мережевий інтерфейс із DHCP.
• Нестабільність сервісів: драйвер підключається до нового USB-серійного пристрою і змінює /dev-шляхи або імена udev.
• Сюрпризи ланцюга постачання: пристрій однаково виглядає, але має інші USB ID, іншу прошивку, іншу поведінку.

Ваше завдання не в тому, щоб «заблокувати USB». Ваше завдання — вирішити, що USB може робити на цьому класі хостів,
а потім застосувати інструменти, які не покладаються на надії.

Один вислів, щоб залишатися чесним із собою: «Надія — це не стратегія.» — James Cameron.

Факти та контекст, які впливають на рішення

Кілька коротких, конкретних пунктів, які мають значення, коли ви проектуєте політику замість суперечок у Slack:

1. USB Mass Storage існує десятиліттями і став універсальним, бо був простим: показати блочний пристрій, дати ОС змонтувати.
2. HID (клавіатури/мишки) «довіряють за замовчуванням» у більшості середовищ, бо зручність перемогла безпеку на ранніх ПК.
3. Композитні USB-пристрої — нормальна річ: один фізичний пристрій може показувати кілька функцій (HID + сховище + серійний). Це зручно для док-станцій, але й для атакувальників теж.
4. Vendor/Product ID — це не автентифікація: це ідентифікатори, і прошивка може брехати. Вони корисні для політики, але не є доказом безпеки.
5. USB-серійні адаптери створили екосистему залежностей (консольний доступ, UPS, керування PDU). Блокувати все — означає зламати реальні робочі процеси.
6. «BadUSB» змусив індустрію визнати проблему прошивки: прошивка пристрою може перепрошитись і пред’являти інші класи, навіть якщо виглядає як флешка.
7. Linux трактує «поява нового пристрою» як шторм подій: udev-правила, systemd-генератори, networkd, десктопні автомонтери — багато учасників реагують.
8. Сервери мають приховані залежності від USB: апаратні watchdog, ліцензійні донгли, KVM, віртуальні носії BMC виглядають як USB‑подібні речі.
9. Сучасні док-станції USB-C — фабрики функцій: сховище, Ethernet, аудіо, дисплей, ввод — ваша політика має бути явною щодо того, що допустимо.

Якщо ці факти змушують вас відчувати дискомфорт — добре. Це правильна відправна точка.

Плейбук швидкої діагностики

Коли щось, пов’язане з USB, поводиться «дивно» (таємничні монтування, нові інтерфейси, нестабільні імена пристроїв), не починайте з теоретичної політики.
Почніть з короткої тріаж-послідовності, яка звузить зону ураження.

Перше: яка подія тільки що сталася?

• Перевірте kernel/journal на події hotplug і прив’язки драйверів.
• Визначте клас пристрою (storage/HID/network/serial).
• Підтвердіть, чи авто-монтувалось або авто-конфігурувалось щось.

Друге: що це за пристрій, точно?

• Отримайте vendor/product IDs, серійний номер (якщо є) і фізичний шлях порту.
• Перевірте, чи це композитний пристрій із кількома інтерфейсами.
• Змоделюйте зв’язок від USB-пристрою до блочного device node (якщо є) і до файлових систем.

Третє: який у вас контрольний пласт?

• Якщо ви використовуєте usbguard, перевірте логи політик і стан пристрою.
• Якщо ні — вирішіть, чи блокувати через модуль ядра (mass storage), udev-правила або фізичне блокування портів.
• Застосуйте тимчасовий зупинний захід, який можна відкотити, потім запишіть постійне правило з тестуванням.

Вузьке місце зазвичай не в «USB». Воно в вашій спостережливості за USB. Виправте це спочатку, потім застосовуйте політику.

Основи аудиту: що підключено і що це насправді

Аудит USB на Linux — це побудова ланцюга доказів:
подія ядра → USB ID → клас інтерфейсу → драйвер → device node → поведінка системи.
Якщо ви не можете намалювати цей ланцюг для пристрою, ви ним не керуєте.

Також: не покладайтеся на «назву» пристрою, яку показують десктопні інструменти. У продакшені важливі стабільні ідентифікатори
(шлях порту, серійник, vendor/product IDs) і який драйвер прив’язався.

Жарт №1: USB-пристрої як стажери — деякі геніальні, але все одно не варто довіряти їм запуск зарплатні без нагляду.

Практичні завдання (команди, виводи, рішення)

Це реальні завдання, які можна виконати на Linux-хості. Кожне містить:
команду, приклад виводу, що означає вивід і яке рішення з нього випливає.
Припустимо, ви root або маєте sudo там, де потрібно.

Завдання 1: Перелік усіх USB-пристроїв (грубе інвентарування)

cr0x@server:~$ lsusb
Bus 002 Device 003: ID 0781:5581 SanDisk Corp. Ultra
Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Що це означає: Vendor:Product IDs показують ідентичність пристрою, як її звітує прошивка. Root hub-и нормальні.

Рішення: Будь-що, що не є root hub, повинно мати обґрунтування. SanDisk-сховище на сервері? Це привід для політичної розмови.

Завдання 2: Отримати детальну інформацію про підозрілий пристрій

cr0x@server:~$ lsusb -d 0781:5581 -v | sed -n '1,80p'
Bus 002 Device 003: ID 0781:5581 SanDisk Corp. Ultra
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5581 Ultra
  iManufacturer           1 SanDisk
  iProduct                2 Ultra
  iSerial                 3 4C530001230101234567
  bNumConfigurations      1

Що це означає: Є серійний номер (добре для allowlist), і на рівні пристрою не заявлено один клас (звично).

Рішення: Збережіть серійний номер і шлях порту. Якщо ви дозволяєте сховище взагалі, дозволяйте лише конкретні серійники.

Завдання 3: Слідкувати в реальному часі за подіями hotplug USB (хто торкався машини?)

cr0x@server:~$ sudo udevadm monitor --udev --kernel
monitor will print the received events for:
KERNEL - the kernel uevent
UDEV - the udev event

KERNEL[24812.531129] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
UDEV  [24812.612204] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
KERNEL[24812.713001] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0 (usb)
UDEV  [24812.714983] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0 (usb)

Що це означає: Ви отримуєте фізичний шлях порту (наприклад 1-2) і події інтерфейсу (1-2:1.0).

Рішення: Використайте шлях порту, щоб побудувати політику «цей порт у стійці дозволено», коли серійники ненадійні.

Завдання 4: Визначити драйвер, який прив’язався до USB-інтерфейсу

cr0x@server:~$ readlink -f /sys/bus/usb/devices/1-2:1.0/driver
/sys/bus/usb/drivers/usb-storage

Що це означає: Застосовується драйвер usb-storage, тому цей пристрій може презентувати блочне сховище.

Рішення: Якщо хост ніколи не має приймати знімне сховище, плануйте блокувати usb-storage глобально або через usbguard/udev.

Завдання 5: Змоделювати USB-сховище на блочний device node

cr0x@server:~$ lsblk -o NAME,TYPE,TRAN,SIZE,MODEL,SERIAL,MOUNTPOINT
NAME   TYPE TRAN  SIZE MODEL            SERIAL               MOUNTPOINT
sda    disk sata  1.8T INTEL SSDSC2BX   BTTV1234001
└─sda1 part       1.8T                                  /
sdb    disk usb  14.9G Ultra            4C530001230101234567
└─sdb1 part usb  14.9G                                  /media/usb

Що це означає: TRAN=usb підтверджує транспорт. Тепер ви знаєте, який блочний пристрій відмонтувати і витерти за потреби.

Рішення: Якщо цей монтування несподіване — відмонтуйте негайно, потім заблокуйте повторення. Під час IR інвентаризуйте те, що скопіювали.

Завдання 6: Переглянути нещодавні повідомлення ядра про USB і поведінку сховища

cr0x@server:~$ sudo journalctl -k -n 80 | egrep -i 'usb|scsi|uas|storage|hid'
Feb 05 10:41:12 server kernel: usb 1-2: new SuperSpeed USB device number 5 using xhci_hcd
Feb 05 10:41:12 server kernel: usb 1-2: New USB device found, idVendor=0781, idProduct=5581
Feb 05 10:41:12 server kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
Feb 05 10:41:12 server kernel: scsi host6: usb-storage 1-2:1.0
Feb 05 10:41:13 server kernel: scsi 6:0:0:0: Direct-Access     SanDisk  Ultra            1.00 PQ: 0 ANSI: 6
Feb 05 10:41:13 server kernel: sd 6:0:0:0: [sdb] 31260672 512-byte logical blocks: (16.0 GB/14.9 GiB)

Що це означає: Це підтверджує послідовність енамерції та факт, що сховище розпізнане як SCSI-диск.

Рішення: Якщо ви будуєте аудиторський слід — збережіть ці події з мітками часу. Якщо запобігаєте повторенню — блокуйте за класом/драйвером.

Завдання 7: Перевірити атрибути USB-пристрою через udev (для стабільного матчінгу)

cr0x@server:~$ udevadm info -q property -n /dev/sdb | egrep 'ID_VENDOR_ID|ID_MODEL_ID|ID_SERIAL_SHORT|ID_BUS|ID_USB_DRIVER'
ID_BUS=usb
ID_VENDOR_ID=0781
ID_MODEL_ID=5581
ID_SERIAL_SHORT=4C530001230101234567
ID_USB_DRIVER=usb-storage

Що це означає: Ці властивості придатні для матчінгу в udev-правилах. Серійник тут найсильніший.

Рішення: Вирішіть, чи застосовувати політику по серійному номеру (бажано), по vendor/product (прийнятно для відомих фіксованих пристроїв) або по шляху порту (останній варіант).

Завдання 8: Перевірити наявність USB-мережевих інтерфейсів, яких не повинно бути

cr0x@server:~$ ip -br link | egrep 'enx|usb|wl|ww'
enx00e04c680001    UP             02:11:22:33:44:55

Що це означає: Інтерфейси з іменем enx* часто є USB NIC (іменування за MAC).

Рішення: Якщо хост не має отримувати мережеве з’єднання через USB, блокуйте клас пристроїв або явно забороніть той VID:PID у політиці.

Завдання 9: Визначити походження USB NIC і його USB IDs

cr0x@server:~$ udevadm info -q all -n /sys/class/net/enx00e04c680001 | egrep 'ID_VENDOR_ID|ID_MODEL_ID|DEVPATH|ID_NET_DRIVER' | head
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/net/enx00e04c680001
E: ID_VENDOR_ID=0bda
E: ID_MODEL_ID=8153
E: ID_NET_DRIVER=r8152

Що це означає: Це Realtek USB NIC під драйвером r8152, розташований на шляху порту 1-3.

Рішення: Для серверів за замовчуванням забороняйте USB NIC, якщо немає задокументованого випадку використання (кіоски/edge-пристрої — виняток).

Завдання 10: Виявити наявність USB Human Interface Devices (HID)

cr0x@server:~$ grep -H . /sys/bus/usb/devices/*/bInterfaceClass 2>/dev/null | head
/sys/bus/usb/devices/1-2:1.0/bInterfaceClass:08
/sys/bus/usb/devices/1-4:1.0/bInterfaceClass:03

Що це означає: Клас інтерфейсу 08 — масове сховище, 03 — HID. Це швидкий спосіб побачити типи пристроїв без парсингу lsusb.

Рішення: Якщо сервер раптово має HID — розглядайте це як підозріле, якщо тільки це не відомий KVM чи консольний донгл.

Завдання 11: Тимчасово відключити USB mass storage (швидке стримування)

cr0x@server:~$ sudo modprobe -r usb_storage
cr0x@server:~$ lsmod | grep -E '^usb_storage\b' || echo "usb_storage unloaded"
usb_storage unloaded

Що це означає: Видалення модуля зупиняє прив’язку нових USB-сховищ. Існуючі змонтовані пристрої можуть залишатися до відмонтування.

Рішення: Використовуйте як аварійний гальмо під час IR. Для постійності застосуйте denylist модулів і/або політику usbguard.

Завдання 12: Постійно заборонити завантаження usb-storage (базова політика для серверів)

cr0x@server:~$ printf "blacklist usb_storage\ninstall usb_storage /bin/false\n" | sudo tee /etc/modprobe.d/usb-storage.conf
blacklist usb_storage
install usb_storage /bin/false
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64

Що це означає: Чорний список зменшує випадкові завантаження; install ... /bin/false — це твердий «ні». Оновлення initramfs забезпечує дотримання на ранньому етапі завантаження.

Рішення: Робіть це на хостах, де USB-сховище ніколи не потрібне. Не робіть це бездумно на хостах, що залежать від virtual media BMC для відновлення.

Завдання 13: Аудит авто-монтування (мовчазний співучасник)

cr0x@server:~$ systemctl is-enabled udisks2.service 2>/dev/null || true
enabled
cr0x@server:~$ systemctl status udisks2.service --no-pager | sed -n '1,8p'
● udisks2.service - Disk Manager
     Loaded: loaded (/lib/systemd/system/udisks2.service; enabled; preset: enabled)
     Active: active (running)

Що це означає: На серверах udisks2 зазвичай непотрібний і може сприяти автомонтувальним робочим процесам (особливо в десктопних середовищах).

Рішення: Для серверних образів відключіть те, що не потрібно. Якщо udisks2 потрібен (рідко), компенсуйте суворішою USB-політикою.

Завдання 14: Встановити та увімкнути usbguard (движок політик)

cr0x@server:~$ sudo apt-get update
cr0x@server:~$ sudo apt-get install -y usbguard
cr0x@server:~$ sudo systemctl enable --now usbguard.service
Created symlink /etc/systemd/system/multi-user.target.wants/usbguard.service → /lib/systemd/system/usbguard.service.

Що це означає: usbguard може застосовувати allow/deny політику для кожного пристрою, включаючи класи інтерфейсів.

Рішення: Використовуйте usbguard, коли потрібен тонко налаштований контроль (наприклад, дозволити UPS HID, але заборонити сховище). Якщо потрібно лише «жодного USB-сховища», керування модулем ядра простіше.

Завдання 15: Згенерувати базовий allowlist політик з usbguard

cr0x@server:~$ sudo usbguard generate-policy
allow id 1d6b:0002 serial "" name "xHCI Host Controller" hash "..."
allow id 046d:c534 serial "" name "Unifying Receiver" with-interface 03:01:02 hash "..."
allow id 0bda:8153 serial "" name "RTL8153 Gigabit Ethernet Adapter" with-interface ff:ff:ff hash "..."

Що це означає: usbguard бачить поточні підключення і генерує правила. Може включати хаби/контролери; це нормально.

Рішення: Перегляньте перед розгортанням. Якщо baseline згенеровано під час інциденту, ви щойно зробили правило для пристрою атакуючого. Генеруйте з відомо чистого стану.

Завдання 16: Застосувати default-deny і дозволяти лише відомі пристрої (конфіг usbguard)

cr0x@server:~$ sudo sed -i 's/^ImplicitPolicyTarget=.*/ImplicitPolicyTarget=block/' /etc/usbguard/usbguard-daemon.conf
cr0x@server:~$ sudo install -m 0600 /dev/null /etc/usbguard/rules.conf
cr0x@server:~$ sudo bash -lc 'usbguard generate-policy > /etc/usbguard/rules.conf'
cr0x@server:~$ sudo systemctl restart usbguard.service

Що це означає: Політика за замовчуванням блокує пристрої, якщо правила їх не дозволяють. Файл правил стає allowlist-ом.

Рішення: Default-deny — єдиний налаштування, що масштабується. Потім явно дозволяйте потрібне — бажано за серійником, інтерфейсом і портом де можливо.

Завдання 17: Спостерігати рішення usbguard в реальному часі

cr0x@server:~$ sudo usbguard watch
device-present id 0781:5581 serial "4C530001230101234567" name "Ultra" hash "..." via-port "1-2" with-interface 08:06:50
device-policy id 0781:5581 serial "4C530001230101234567" target block

Що це означає: Пристрій з’явився і був заблокований. Інтерфейс 08:06:50 — масове сховище (SCSI transparent, Bulk-Only або подібне).

Рішення: Якщо блокування очікуване — все гаразд. Якщо ви порушили легітимний робочий процес — створіть вузьке allow-правило, а не широке виняток.

Завдання 18: Створити allow-правило usbguard для конкретного серійного номера і інтерфейсу

cr0x@server:~$ sudo bash -lc 'printf "%s\n" \
"allow id 051d:0002 serial \"\" name \"American Power Conversion\" with-interface 03:00:00" \
>> /etc/usbguard/rules.conf'
cr0x@server:~$ sudo systemctl reload usbguard.service || sudo systemctl restart usbguard.service

Що це означає: Цей приклад дозволяє UPS-подібний HID-інтерфейс (не сховище). Тройка інтерфейсу важлива: запобігає сюрпризам, коли той самий пристрій також має сховище.

Рішення: Завжди додавайте with-interface, якщо ви не дозволяєте хаб/контролер. Вузькі правила краще за «розумні» широкі.

Завдання 19: Заблокувати конкретний VID:PID через udev (сургична, але обмежена міра)

cr0x@server:~$ cat | sudo tee /etc/udev/rules.d/90-usb-block-sandisk.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0781", ATTR{idProduct}=="5581", ATTR{authorized}="0"
cr0x@server:~$ sudo udevadm control --reload-rules
cr0x@server:~$ sudo udevadm trigger --subsystem-match=usb

Що це означає: Встановлення authorized=0 каже ядру деавторизувати пристрій. Це працює, але поведінка залежить від типу пристрою і таймінгу.

Рішення: Використовуйте udev як тактичний інструмент. Для політики флоту з аудитом краще usbguard.

Завдання 20: Підтвердити, що блочний пристрій зник і монтування чисте

cr0x@server:~$ mount | grep -E '/media/usb|/run/media' || echo "no removable mounts"
no removable mounts
cr0x@server:~$ lsblk -o NAME,TRAN,SIZE,MOUNTPOINT | egrep 'usb|^sdb' || echo "no usb block devices"
no usb block devices

Що це означає: Немає залишкових монтувань і немає USB-транспортних дисків.

Рішення: Оголошуйте утримання лише після того, як обидва стануть істинними. Блокування без відмонтування — шлях до напіввиправлених інцидентів.

Стратегії блокування: грубі, точні та дружні до флоту

Стратегія A: Відключити USB mass storage на рівні модуля ядра

Це великий молоток. Надзвичайно ефективний для «сервери ніколи не приймають флешки».
Він також недискримінаційний: блокує усе USB-сховище, включно з легітимними процедурами відновлення через virtual media.

Коли використовувати:

• Загально-призначені сервери у контрольованому датацентрі, де відновлення руками використовує інші механізми.
• Середовища з вимогами відповідності, де знімні носії категорично заборонені.

Коли не використовувати:

• Віддалені/edge розгортання, де польове відновлення залежить від USB-носіїв.
• Системи, що розраховані на USB-пристосоване сховище як проектну складову (деякі appliances).

Стратегія B: usbguard default-deny + allowlist

Це дорослий підхід: явні політики, логування і керований шлях до винятків.
usbguard може дозволити конкретний UPS HID-пристрій і одночасно заборонити сховище та невідомі інтерфейси на тому ж пристрої.

Якщо ви керуєте флотом, usbguard також дає артефакт політики, який можна переглядати як код.
Це не «приємна річ». Це те, як ви переживете аудити, не брехавши.

Стратегія C: блокування на основі udev (швидко і локально)

udev-правила можуть деавторизувати пристрої або заборонити певну поведінку. Вони корисні для прицільних заборон і для систем,
де не можна додати новий демон. Плата — складність і крайові випадки: таймінги важливі, атрибути різняться,
і ви будете дебажити у найгірший момент.

Стратегія D: атакувати площину автомонтування

Навіть якщо USB-сховище виявлено, воно не обов’язково має монтуватися. Для серверів видалення агента автомонтування —
хороша гігієна. Це не зупинить ін’єкцію натискань клавіш або USB NIC, але зменшить клас інцидентів «ой, воно змонтувалося».

Стратегія E: фізичні та прошивкові контролі (те, що всі забувають)

Якщо можна відключити зовнішні USB-порти в BIOS/UEFI — зробіть це на системах, які їх ніколи не потребують.
Якщо можна замкнути порти фізично — зробіть це на коробках у напівпублічних просторах.
Програмна політика потрібна; часто її недостатньо.

Жарт №2: Єдиний по-справжньому захищений USB-порт — той, що залитий епоксидом, — але Facilities дивно до цього ставляться.

Три корпоративні міні-історії з практики

1) Інцидент через хибне припущення: «Це ж просто клавіатура»

Середня компанія мала набір Linux jump hosts, якими інженери користувалися для доступу до продуктивних систем. Хости були закриті:
без компіляторів, суворий sudo, MFA для SSH. Команда почувалася впевнено, що зазвичай перша ознака проблеми.

Під час вікна обслуговування підряднику потрібен був консольний доступ, бо один jump host мав проблеми з мережею. Хтось підключив
«запасну клавіатуру» з шухляди. Припущення було простим: клавіатури — інертні; вони лише вводять текст.

Клавіатура не була інертною. Вона енамурувалася як HID і вкинула коротку послідовність команд у консоль.
Нічого кіношного — просто curl-to-shell однорядок, який завантажив скрипт з внутрішнього хоста і запустив його.
Скрипт додав користувача з SSH-ключами і пішов. Це було швидко, тихо і не потребувало підвищення привілеїв, бо консольна сесія вже була привілейованою для налагодження.

Постмортем був болючим, бо «контролі безпеки» були орієнтовані на мережу. USB не входив до моделі загроз.
Команда врешті впровадила політику default-deny для USB на тих хостах: дозволено лише відомий VID:PID KVM і все інше заблоковано.
Також вони перестали тримати загадкові периферійні пристрої в шухлядах. Інвентар — не гламурно, але сюрпризне обладнання — шлях до проблем.

Найсоромніша частина: не було сигнатур шкідливості, жодного хитромудрого експлойту. Просто припущення, що «HID безпечний».
Воно таким не виявилося.

2) Оптимізація, яка повернулась боком: «Дозволимо всі хаби й доки»

Інша організація стандартизувала док-станції USB-C для робочих ноутбуків on-call. Намір був добрий: менше адаптерів, простіша заміна робочих місць,
менше часу на пошук потрібного донгла. Вони написали usbguard-політику, яка широко дозволяла відомих виробників доків і їхні хаби.

Політика виглядала чисто: дозволити ці vendor ID, дозволити ці хаби, дозволити цю Ethernet-функцію. Вона пройшла пілот.
Потім реальність нагадала про себе. Доки не стабільні — оновлення прошивки змінюють заявлені ID. Замінні одиниці приходять з інших партій.
Політика почала блокувати легітимні доки і дозволяти дивні інтерфейси.

Бумеранг був тонким: дозволений док відкрив інтерфейс масового сховища для «встановлення драйверів» на Windows.
На Linux він з’явився як невеликий лише для читання диск. Нічого не монтувалось автоматично на жорстко налаштованому образі, але розробники підключали його «щоб побачити».
Диск містив скрипти і бінарники. Хтось запустив один. Це не було шкідливістю, це був інструмент постачальника для налагодження,
але він змінив мережеві налаштування і зламав VPN-маршрутизацію.

Інцидент не був компрометацією. Він був гіршим у іншому сенсі: він вивів з ладу on-call зв’язок посеред виробничого інциденту.
Команда пересвідчилася: дозвіл Ethernet і дисплея дока — ок, але явно заборонити інтерфейси сховища навіть на «дозволених» пристроях.
Урок: оптимізація, що розширює довіру, рано чи пізно принесе вам рахунок за свою зручність.

3) Нудна, але правильна практика, що врятувала ситуацію: «Базовий USB-інвентар як код»

Фінансова фірма мала змішаний флот: сервери в датацентрі, edge-пристрої в відділеннях і кілька кіосків.
У них була проста, нудна правило: кожен клас хостів мав задокументовану USB-політику, версіоновану в системі управління конфігурацією.
Не в wiki. Реальні файли політик.

На edge-пристрої оператор повідомив, що «флешка перестала працювати». Така фраза завжди підозріла:
або ви навмисно її заблокували (і вона працює як задумано), або ви випадково заблокували легітимний пристрій (і ви щось поламали).

Вони перевірили логи usbguard і побачили новий пристрій: той самий vendor і product як «дозволений» USB-модем, але інший серійник і додатковий інтерфейс.
Базова політика дозволяла тільки відомий інтерфейс модему і вимагала матчу серійного номера. Тож новий пристрій був заблокований за замовчуванням.

Виявилось, що модем замінив сторонній підрядник дешевшою одиницею, яка звітувала подібні ID, але додавала інтерфейс сховища.
Інтерфейс містив autorun-утиліту для Windows. Фірма не переймалася Windows autorun; їх турбувала наявність несподіваного сховища на пристрої мережевого шляху.
Вони відхилили обладнання, оновили вимоги постачальника і продовжили.

Рятівником не був якийсь магічний продукт. Це була нудна практика: інвентаризація baseline, явний allowlist і логи, які робили рішення очевидним.
Коли ви можете відповісти «що змінилося?» за хвилини — ви спокійніше спите.

Поширені помилки (симптоми → корінь → виправлення)

Помилка 1: «Ми заблокували USB-сховище, але диски іноді все одно з’являються.»

Симптоми: Деякі флешки монтуються; інші — ні. Поведінка змінюється після оновлення ядра або залежить від пристрою.

Корінь: Ви заблокували usb_storage, але пристрій використовує uas (USB Attached SCSI) або інший шлях, або ваш initramfs все ще завантажує модулі на ранній стадії.

Виправлення: Перевірте завантажені модулі для usb_storage і uas; оновіть initramfs; розгляньте класове блокування сховища через usbguard.

Помилка 2: «Ми allowlisted по vendor ID, тепер атакувальники нас спуфлять.»

Симптоми: Політика каже «дозволити vendor X», і ви відчуваєте безпеку. Але не варто.

Корінь: VID:PID — це не автентифікація. Прошивка може пред’являти ID. Також легітимні пристрої можуть змінювати ID між ревізіями.

Виправлення: Віддавайте перевагу серійному номеру + обмеженню інтерфейсу. Якщо серійника немає — прив’язуйте політику до фізичного шляху на фіксованому обладнанні і застосовуйте default-deny.

Помилка 3: «usbguard заблокував наш UPS і коробка вимкнулася під час обслуговування.»

Симптоми: Події живлення не повідомляються; скрипти завершення роботи не спрацьовують; моніторинг втрачає зв’язок з UPS.

Корінь: UPS був USB HID-пристроєм, а ваша політика default-deny не дозволяла його або дозволила без потрібної деталізації інтерфейсу.

Виправлення: Додайте allow-правило для UPS з конкретним класом інтерфейсу. Тестуйте шляхом відключення/підключення в вікні технічного обслуговування і підтвердіть, що моніторинг бачить його.

Помилка 4: «Ми все заблокували і тепер віддалене відновлення неможливе.»

Симптоми: Ви не можете використовувати virtual media BMC; rescue ISO не підключається; віддалений персонал не може завантажити recovery media.

Корінь: Ви глобально заборонили USB-сховище, але ваше OOB-управління презентує virtual media як USB-сховище ОС.

Виправлення: Створіть виняток для класу хостів: дозволити USB-сховище лише для BMC virtual media (конкретний VID:PID/порт) або лише у режимі break-glass з контролем змін.

Помилка 5: «Ми написали udev-правило, але воно не спрацьовує.»

Симптоми: Підключаєте пристрій і нічого не відбувається; правило здається ігнорованим.

Корінь: Неправильний матчінг (SUBSYSTEM vs SUBSYSTEMS), атрибути відсутні для того вузла пристрою або конфлікт порядку виконання правил.

Виправлення: Використайте udevadm info -a -p проти шляху пристрою, щоб знайти правильні атрибути; перевірте імена файлу правила для порядку; моніторте з udevadm monitor.

Помилка 6: «Ми заблокували нові пристрої, але старі сесії продовжують працювати.»

Симптоми: Ви застосували політику, але вже підключений пристрій все ще функціонує.

Корінь: Застосування працює при підключенні; існуючі монтування/драйвери залишаються прив’язаними.

Виправлення: Відмонтуйте файлові системи, виведіть інтерфейси з роботи, і за потреби фізично відключіть/підключіть пристрій. Перевірте за допомогою lsblk і ip link.

Чеклісти / покроковий план

Чекліст A: Побудуйте USB-інвентар, який можна захищати

1. Запустіть lsusb на відомо чистому хості і збережіть вивід у вашому репозиторії конфігурацій або експорт CMDB.
   Пристрої в «нормальному» стані не повинні бути загадкою.
2. Для кожного пристрою, що не є root-hub: зафіксуйте VID:PID, серійник (якщо є), класи інтерфейсів і шлях порту (через udevadm monitor або sysfs).
3. Для USB-сховищ або NIC — змоделюйте до OS вузлів (lsblk, ip link) і задокументуйте, чи дозволено це для цього класу хостів.
4. Визначте класи хостів: сервери в датацентрі, jump hosts, робочі станції розробників, кіоски, edge-пристрої. Одна політика для всіх — лінива і помилкова.

Чекліст B: Виберіть шар примусового виконання (не переінженеруйте)

1. Якщо правило «жодного USB-сховища ніколи»: забороніть через модпровайд конфіг (і оновіть initramfs). Просто і сильно.
2. Якщо потрібні винятки (UPS, серійна консоль, конкретний док Ethernet): розгорніть usbguard і використовуйте default-deny allowlisting.
3. Якщо потрібен тактичний блок сьогодні: використайте udev-авторизаційні правила для конкретного VID:PID, поки ви будуєте правильну політику.
4. Якщо є автомонтування: видаліть/відключіть його на серверах. Не давайте USB-сховищу вільний шлях.

Чекліст C: План розгортання, що не зіпсує флот

1. Почніть в режимі спостереження: розгорніть usbguard, але логування рішень; не блокуйте, якщо ви не впевнені. Потім переключіться на блокування, коли матимете політику.
2. Пілотуйте на невеликій підмножині хостів по кожному класу, включаючи «дивні» хости (з UPS, серійними донглами, KVM).
3. Перевірте операційні робочі процеси: віддалене відновлення, консольний доступ, моніторинг UPS, OOB-управління.
4. Додайте процедуру break-glass: тимчасове обхідне правило з жорстким контролем змін і чітким відкатом.
5. Робіть USB-політику артефактом, що проходить CI‑рев’ю. Якщо її не можна перевірити — вона буде дрейфувати, поки не зламається.

Чекліст D: Реагування на інцидент при знайденому чужому USB-пристрої

1. Збережіть логи: journalctl -k події навколо часу вставлення, плюс вивід usbguard watch якщо доступний.
2. Визначте, як воно енамурувалося: storage/HID/network/serial.
3. Контейнмент: відмонтуйте сховище, виведіть інтерфейси, розвантажте модулі якщо потрібно і фізично видаліть пристрій.
4. Оцінка: перевірте історію shell і sudo-логи на предмет ін’єкцій HID; перевірте зміни мережі якщо з’явився USB NIC.
5. Запобігання повторенню: напишіть явні deny-правила; потім складіть allowlist для потрібних пристроїв.

FAQ

1) Чи просто вимкнути всі USB-порти в BIOS/UEFI?

На серверах, які ніколи не потребують локального вводу і мають надійне OOB-управління — так. Це чисто.
Але багато середовищ все ще потребують USB для KVM, моніторингу UPS або break-glass відновлення. Не прикидайтеся, що цього немає.

2) Чи достатньо заблокувати usb_storage, щоб зупинити USB-диски?

Часто — так, але не завжди. Деякі пристрої прив’язуються через UAS, і раннє завантаження модулів може обійти пізню політику.
Перевіряйте через lsmod, логи ядра і підключення тестового пристрою після перезавантаження.

3) Чому не просто блокувати монтування і залишити пристрої?

Тому що сховище — не єдина загроза. HID може ін’єктувати команди, а USB NIC може створити нові мережеві шляхи.
«Жодного автомонту» — хороша гігієна; але це не повноцінна USB-безпекова політика.

4) Чи безпечно розгортати usbguard масштабно?

Так, якщо ставитися до нього як до політики фаєрвола: почати зі спостереження, згенерувати політику з відомо чистого стану,
і розгортати по класах хостів. Небезпека — в тому, щоб включити default-deny на коробці, яку ви не добре знаєте.

5) Який найнадійніший ідентифікатор для allowlist?

Серійні номери найкращі, коли вони існують і стабільні. Наступне по надійності — шлях порту на фіксованому обладнанні.
VID:PID корисні, але самі по собі недостатні.

6) Як поступати з USB-пристроями, що змінюють ID після оновлення прошивки?

Плануйте це: розглядайте оновлення прошивки як зміну, що може вплинути на політику.
Використовуйте обмеження інтерфейсів і, де можливо, дозволяйте за серійником, а не лише за VID:PID.
Майте стендову середу для спостереження нових ID перед виробничим розгортанням.

7) А як щодо «USB condom» (адаптерів для зарядки без даних)?

Вони можуть зменшити ризик у зарядно-орієнтованих сценаріях, головно на мобільних пристроях. На серверах це не стратегія.
Ваші контролі мають бути застосовні політикою і аудитуємими, а не залежати від того, що хтось використовує правильний адаптер у стресовій ситуації.

8) Чи можна блокувати лише нові USB-пристрої, але зберегти старі?

Так, концептуально: default-deny для нових пристроїв і allowlist для відомо добрих пристроїв.
Практично — тестуйте перезавантаження і реенаумерацію, бо «існуючий» часто стає «новим» після reboot.

9) Як аудитувати використання USB по флоту?

Збирайте lsusb, lsblk (USB-транспорт) і логи usbguard централізовано. Обробляйте вивід як дані інвентарю.
Ключ — консистентність: однакові команди, однаковий парсинг, заплановані запуски і алерти на дрейф.

Висновок: наступні кроки, які можна відправити в продакшн

USB — це проблема надійності, що носить шапку безпеки. Виправлення — не одна команда; це політика, яку ви можете пояснити, впровадити й аудіювати.
Почніть з вивчення того, що реально підключено, потім вирішіть, що кожен клас хостів має дозволяти, і застосуйте найпростішу прошарок, що відповідає вимогам.

1. Сьогодні: Запустіть завдання аудиту на одному репрезентативному хості для кожного класу. Збережіть базу.
2. Цього тижня: Вимкніть автомонтувальні сервіси на серверах і додайте кроки аварійного стримування в runbook інцидентів.
3. Цього місяця: Розгорніть usbguard де потрібні винятки; інакше блокуйте USB-сховище на рівні модуля ядра. Розгортайте з пілотами і контролем змін.
4. Постійно: Ставте USB-політику як політику фаєрвола — переглядайте, версіонуйте і тестуйте після змін обладнання/прошивки.

Мета — нудний USB. Нудний означає стабільний, захищений і приємно безподійний. Продакшн любить, коли нічого не відбувається.