Auditar dispositivos USB y bloquear los peligrosos (automatizable)

Modelo de amenaza: por qué USB es un riesgo en producción

USB no es “un puerto.” Es un bus con suministro de energía, hotplug, múltiples clases de dispositivos y una larga historia de
suposiciones del tipo “confía en el dispositivo, ¿qué más puedes hacer?”. Eso está bien en un portátil de desarrollo. Es irresponsable en un
servidor que contiene credenciales, datos de clientes o cualquier cosa que te avergüence explicar ante el comité de auditoría.

Los modos de falla operativos más comunes no requieren malware cinematográfico:

• Exfiltración de datos: se monta un almacenamiento masivo USB, alguien copia unos directorios y el día se arruina.
• Inyección de pulsaciones: un dispositivo se anuncia como teclado (HID) y teclea comandos más rápido de lo que parpadeas.
• Pivoteo de red: aparece un “Ethernet por USB” y crea una nueva interfaz de red con DHCP.
• Inestabilidad de servicios: un controlador se enlaza a un nuevo dispositivo serial USB y cambia rutas /dev o nombres de udev.
• Sorpresas en la cadena de suministro: dispositivos iguales a la vista con distintos IDs USB, firmware distinto y comportamiento distinto.

Tu trabajo no es “bloquear USB.” Tu trabajo es decidir qué puede hacer USB en esta clase de hosts y luego
aplicarlo con herramientas que no dependan de pensar en positivo.

Una cita para mantenerte honesto: «La esperanza no es una estrategia.» — James Cameron.

Hechos y contexto que cambian las decisiones

Unos puntos cortos y concretos que importan cuando diseñas política en vez de discutir en Slack:

1. El almacenamiento masivo USB existe desde hace décadas y se volvió ubicuo porque era muy sencillo: presentar un dispositivo de bloques y dejar que el SO lo monte.
2. HID (teclados/ratones) se considera “confiable por defecto” en la mayoría de entornos porque la usabilidad venció a la seguridad en la era PC temprana.
3. Los dispositivos USB compuestos son normales: un dispositivo físico puede exponer múltiples funciones (HID + almacenamiento + serial). Es genial para docks, y también para atacantes.
4. Los IDs de proveedor/producto no son autenticación: son identificadores y el firmware puede mentir. Son útiles para política, no para probar que algo es bueno.
5. Los adaptadores serial USB crearon todo un ecosistema de dependencia operativa (acceso a consola, UPS, control de PDU). Bloquear todo rompe trabajo real.
6. “BadUSB” obligó a la industria a admitir el problema del firmware: el firmware del dispositivo puede reprogramarse y presentar diferentes clases, incluso si parece una memoria USB.
7. Linux trata “apareció un nuevo dispositivo” como una tormenta de eventos: reglas udev, generadores systemd, networkd, automount de escritorio—muchos actores reaccionan.
8. Los servidores tienen dependencias USB silenciosas: watchdogs de hardware, dongles de licencia, KVMs y medios virtuales BMC aparecen como cosas tipo USB.
9. Los docks modernos USB-C son fábricas de funciones: almacenamiento, Ethernet, audio, vídeo, entrada—tu política debe ser explícita sobre lo que se acepta.

Si esos hechos te ponen incómodo, bien. Esa es la línea de base correcta.

Guía de diagnóstico rápido

Cuando algo relacionado con USB es “raro” (montajes misteriosos, nuevas interfaces, nombres de dispositivo inestables), no empieces con
teoría de política de seguridad. Comienza con una secuencia rápida de triage que reduzca el radio de impacto.

Primero: ¿qué evento acaba de ocurrir?

• Revisa el kernel/journal por eventos de hotplug y enlaces de controladores.
• Identifica la clase de dispositivo (almacenamiento/HID/red/serial).
• Confirma si el sistema montó o configuró algo automáticamente.

Segundo: ¿qué dispositivo es exactamente?

• Obtén los IDs de vendedor/producto, el número de serie (si existe) y la ruta física del puerto.
• Comprueba si es un dispositivo compuesto que expone múltiples interfaces.
• Mapea desde el dispositivo USB al nodo de dispositivo de bloques (si lo hay) y a los puntos de montaje del sistema de archivos.

Tercero: ¿qué plano de control tienes?

• Si ejecutas usbguard, revisa los registros de política y el estado del dispositivo.
• Si no, decide si bloquear vía módulo del kernel (usb-storage), reglas udev o bloqueo físico del puerto.
• Aplica un bloqueo temporal reversible, luego escribe la regla permanente con pruebas.

El cuello de botella suele ser no “USB”, sino tu observabilidad del USB. Arregla eso primero, luego aplica la política.

Fundamentos de auditoría: qué está conectado y qué es realmente

Auditar USB en Linux es construir una cadena de evidencia:
evento del kernel → ID USB → clase de interfaz → controlador → nodo de dispositivo → comportamiento del sistema.
Si no puedes dibujar esa cadena para un dispositivo, no lo controlas.

Además: no te fíes del “nombre” del dispositivo que muestran las herramientas de escritorio. En producción te importan identificadores estables
(ruta del puerto, número de serie, IDs de vendedor/producto) y qué controlador del kernel se enlazó al dispositivo.

Broma #1: Los dispositivos USB son como pasantes—algunos son brillantes, pero igual no deberías dejar que manejen la nómina sin supervisión.

Tareas prácticas (comandos, salidas, decisiones)

Estas son tareas reales que puedes ejecutar en un host Linux. Cada una incluye:
un comando, salida de ejemplo, qué significa la salida y la decisión que tomas a partir de ella.
Asume que eres root o tienes sudo donde se requiera.

Tarea 1: Listar todos los dispositivos USB (inventario grueso)

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

Qué significa: Los IDs Vendor:Product muestran la identidad del dispositivo según informa el firmware. Los root hubs son normales.

Decisión: Cualquier cosa que no sea un root hub debe justificarse. ¿SanDisk en un servidor? Eso es una conversación de política.

Tarea 2: Obtener detalles verbosos de un dispositivo sospechoso

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

Qué significa: Tienes un número de serie (fantástico para allowlist) y no declara una sola clase de dispositivo a nivel de dispositivo (común).

Decisión: Captura el número de serie y la ruta del puerto. Si permites almacenamiento, allowlistea solo seriales específicos.

Tarea 3: Vigilar eventos de hotplug USB en vivo (¿quién tocó la máquina?)

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)

Qué significa: Obtienes la ruta física del puerto (como 1-2) y eventos de interfaz (1-2:1.0).

Decisión: Usa la ruta del puerto para construir una política “este puerto del rack está permitido” cuando los seriales no sean fiables.

Tarea 4: Identificar el controlador que se enlazó a una interfaz USB

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

Qué significa: El controlador usb-storage está en uso, por lo que este dispositivo puede presentar almacenamiento en bloque.

Decisión: Si el host nunca debe aceptar almacenamiento extraíble, planea bloquear usb-storage globalmente o mediante usbguard/udev.

Tarea 5: Mapear almacenamiento USB a un nodo de bloque

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

Qué significa: TRAN=usb confirma el transporte. Ahora sabes qué dispositivo de bloque desmontar y limpiar si es necesario.

Decisión: Si ese montaje es inesperado, desmonta inmediatamente y luego bloquea la recurrencia. Inventaría qué se copió si es respuesta a incidentes.

Tarea 6: Ver mensajes recientes del kernel sobre USB y comportamiento de almacenamiento

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)

Qué significa: Esto confirma la secuencia de enumeración y el hecho de que el almacenamiento fue reconocido como disco SCSI.

Decisión: Si estás construyendo una pista de auditoría, guarda estos eventos con marcas de tiempo. Si previenes recurrencia, bloquea por clase/controlador.

Tarea 7: Inspeccionar atributos del dispositivo USB vía udev (para emparejamientos estables)

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

Qué significa: Estas propiedades son las que puedes emparejar en reglas udev. El serial es lo más fuerte aquí.

Decisión: Decide si aplicar por serial (preferido), vendor/product (aceptable para dispositivos conocidos y fijos) o ruta del puerto (último recurso).

Tarea 8: Buscar interfaces de red USB que no deberían existir

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

Qué significa: Las interfaces nombradas enx* suelen ser NICs USB (nombres derivados de MAC).

Decisión: Si el host no debe ganar conectividad de red vía USB, bloquea la clase de dispositivo o deniega explícitamente ese VID:PID con política.

Tarea 9: Identificar el origen de una NIC USB y sus IDs USB

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

Qué significa: Esta es una NIC Realtek USB impulsada por r8152, ubicada en la ruta de puerto 1-3.

Decisión: Para servidores, predetermina denegar NICs USB a menos que tengas un caso de uso documentado (kiosk/edge excepcionados).

Tarea 10: Detectar la presencia de dispositivos de interfaz humana (HID) USB

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

Qué significa: La clase de interfaz 08 es almacenamiento masivo, 03 es HID. Es una forma rápida de detectar tipos sin parsear lsusb.

Decisión: Si un servidor de repente tiene HID, trátalo como sospechoso a menos que sea un KVM conocido o un dongle de consola.

Tarea 11: Deshabilitar temporalmente el almacenamiento masivo USB (contención rápida)

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

Qué significa: Quitar el módulo impide que nuevos dispositivos de almacenamiento USB se enlacen. Los dispositivos ya montados pueden permanecer hasta desmontarlos.

Decisión: Úsalo como freno de emergencia durante respuesta a incidentes. Para permanencia, usa una denylist de modprobe y/o política usbguard.

Tarea 12: Impedir de forma permanente que se cargue usb-storage (línea base para servidores)

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

Qué significa: El blacklist reduce cargas accidentales; install ... /bin/false es el “no” firme. Actualizar initramfs asegura que el arranque temprano lo respete.

Decisión: Haz esto en hosts donde el almacenamiento USB nunca se requiere. No lo hagas a ciegas en hosts que dependen de medios virtuales BMC para recuperación.

Tarea 13: Auditar el comportamiento de automount (el cómplice silencioso)

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)

Qué significa: En servidores, udisks2 suele ser innecesario y puede facilitar flujos de trabajo de automount (especialmente en entornos tipo escritorio).

Decisión: Para imágenes de servidor, deshabilita lo que no necesitas. Si necesitas udisks2 (raro), compensa con política USB más estricta.

Tarea 14: Instalar y habilitar usbguard (motor de política)

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.

Qué significa: usbguard puede aplicar política allow/deny por dispositivo, incluyendo clase e interfaz.

Decisión: Usa usbguard cuando necesites control fino (p. ej., permitir un UPS HID pero negar almacenamiento). Si solo necesitas “no almacenamiento USB”, los controles del kernel pueden ser más simples.

Tarea 15: Generar una política baseline con 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 "..."

Qué significa: usbguard ve lo que está conectado y emite reglas. Puede incluir hubs/controladores; eso es normal.

Decisión: Revisa antes de desplegar. Si la baseline se generó durante un incidente, acabas de consagrar el dispositivo del atacante como “permitido”. Genera desde un estado conocido y limpio.

Tarea 16: Imponer deny por defecto y permitir solo dispositivos conocidos (config 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

Qué significa: La política por defecto bloquea dispositivos a menos que haya reglas que los permitan. El archivo de reglas se convierte en la allowlist.

Decisión: Denegar por defecto es la única configuración que escala. Luego permite explícitamente lo que necesites—idealmente por serial, interfaz y puerto cuando sea práctico.

Tarea 17: Observar las decisiones de usbguard en tiempo real

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

Qué significa: El dispositivo apareció y fue bloqueado. La interfaz 08:06:50 es almacenamiento masivo (SCSI transparente, Bulk-Only o similar).

Decisión: Si el bloqueo es esperado, ya está. Si rompiste un flujo legítimo, crea una regla allow estrecha, no una excepción amplia.

Tarea 18: Crear una regla allow de usbguard para un serial e interfaz específicos

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

Qué significa: Este ejemplo permite una interfaz HID tipo UPS (no almacenamiento). El triple de interfaz importa: evita sorpresas de “mismo dispositivo que también expone almacenamiento”.

Decisión: Siempre incluye with-interface salvo que permitas un hub/controlador. Estrechar es mejor que intentar ser demasiado listo.

Tarea 19: Bloquear un VID:PID específico via udev (quirúrgico, pero limitado)

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

Qué significa: Establecer authorized=0 le dice al kernel que desautorice el dispositivo. Esto puede funcionar bien, pero el comportamiento varía según tipo de dispositivo y temporización.

Decisión: Usa udev como herramienta táctica. Para política a nivel de flota con auditoría, prefiere usbguard.

Tarea 20: Confirmar que el dispositivo de bloque ha desaparecido y que los montajes están limpios

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

Qué significa: No quedan montajes y no quedan discos con transporte USB.

Decisión: Declara contención solo después de que ambas cosas sean verdaderas. Bloquear sin desmontar es la forma de tener incidentes medio arreglados.

Estrategias de bloqueo: contundente, precisa y apta para flotas

Estrategia A: Deshabilitar almacenamiento masivo USB a nivel de módulo del kernel

Este es el gran martillo. Es maravillosamente efectivo para “servidores que nunca aceptan memorias USB”.
También es indiscriminado: bloquea todo el almacenamiento USB, incluyendo flujos legítimos de recuperación que usan medios virtuales.

Cuándo usarlo:

• Servidores de propósito general en un datacenter controlado donde la recuperación presencial usa otros mecanismos.
• Entornos impulsados por cumplimiento donde el almacenamiento removible está prohibido categóricamente.

Cuándo no usarlo:

• Despliegues remotos/edge donde la recuperación en campo depende de medios USB.
• Sistemas que dependen del almacenamiento USB como componente diseñado (algunos appliances lo hacen).

Estrategia B: usbguard deny por defecto + allowlist

Este es el enfoque maduro: política explícita, registro y un camino manejable para excepciones.
usbguard puede permitir un UPS HID específico mientras niega almacenamiento y rechaza interfaces desconocidas en el mismo dispositivo.

Si operas una flota, usbguard también te da un artefacto de política que puedes revisar como código.
Eso no es un lujo. Es como sobrevives a auditorías sin mentir.

Estrategia C: bloqueo basado en udev (rápido y local)

Las reglas udev pueden desautorizar dispositivos o prevenir ciertos comportamientos. Son útiles para denegaciones focalizadas y para sistemas
donde no puedes introducir un nuevo daemon. El trade-off es la complejidad y casos límite: la temporización importa, los atributos varían
y lo depurarás en el peor momento.

Estrategia D: atacar la superficie de automount

Incluso si se detecta un dispositivo de almacenamiento USB, no tiene que montarse. Para servidores no de escritorio, quitar agentes de automount
es buena higiene. No detendrá la inyección HID ni las NICs USB, pero reduce la clase de incidentes “ups, se montó”.

Estrategia E: controles físicos y de firmware (la parte que todos olvidan)

Si puedes deshabilitar puertos USB externos en BIOS/UEFI, hazlo en sistemas que nunca los necesiten.
Si puedes bloquear puertos físicamente, hazlo en máquinas en espacios semi-públicos.
La política por software es necesaria; no siempre es suficiente.

Broma #2: El único puerto USB verdaderamente seguro es el que está lleno de epoxi—pero Facilities se pone raro con eso.

Tres microhistorias corporativas desde el terreno

1) Incidente causado por una suposición errónea: “Es solo un teclado”

Una empresa mediana operaba un conjunto de jump hosts Linux que los ingenieros usaban para acceso a producción. Los hosts estaban muy cerrados:
sin compiladores, sudo estricto, MFA para SSH. El equipo se sentía seguro, lo cual suele ser el primer síntoma.

Durante una ventana de mantenimiento, un contratista necesitó acceso a consola porque un jump host tenía problemas de red. Alguien enchufó
un “teclado de repuesto” de un cajón. La suposición era simple: los teclados son dispositivos inertes; no pueden hacer mucho aparte de teclear.

El teclado no era inerte. Se enumeró como dispositivo HID e inyectó una secuencia corta de comandos en la consola.
Nada cinematográfico—solo un one-liner curl-to-shell que sacó un script desde un host interno y lo ejecutó.
El script añadió un usuario con claves SSH y se fue. Fue rápido, silencioso y no necesitó escalado porque la sesión de consola ya tenía privilegios para depurar.

El postmortem fue doloroso porque los “controles de seguridad” eran todos centrados en la red. USB no estaba en el modelo de amenazas.
El equipo terminó implementando política USB deny por defecto en esos hosts: permitir solo el VID:PID conocido del KVM y bloquear todo lo demás.
También aprendieron a dejar de guardar periféricos misteriosos en los cajones. El inventario no es glamuroso, pero el hardware sorpresa es como te comprometen.

Lo más embarazoso: no había firmas de malware que encontrar, ni cadenas de exploits elegantes. Solo la suposición de que “HID es seguro.”
No lo era.

2) Optimización que salió mal: “Permitamos todos los hubs y docks”

Otra organización estandarizó docks USB-C para sus laptops de guardia. La intención era buena: menos adaptadores, swaps de estación más fáciles,
menos tiempo buscando el dongle correcto. Escribieron una política usbguard que permitía ampliamente vendors de docks y sus hubs.

La política parecía ordenada: permitir estos vendor IDs, permitir estos hubs, permitir esta función Ethernet. Incluso pasó un piloto. Luego llegó la realidad.
Los docks no son dispositivos estables y de una sola función. Las actualizaciones de firmware cambiaron los IDs reportados. Unidades de reemplazo vinieron de distintas líneas de fabricación.
La política empezó a bloquear docks legítimos y a permitir algunas interfaces sorprendentes.

El fallo fue sutil: un dock permitido expuso una interfaz de almacenamiento usada para “instalación de drivers” en Windows.
En Linux apareció como un pequeño disco de solo lectura. Nada se montó automáticamente en la imagen endurecida del laptop, pero los desarrolladores, fieles a su naturaleza,
lo montaron “para ver qué era”. El disco contenía scripts y binarios. Alguien ejecutó uno. No era malware, solo una herramienta de troubleshooting del vendor,
pero cambió ajustes de red del sistema y rompió el enrutamiento VPN.

El incidente no fue una brecha. Fue peor de otra manera: dejó fuera la conectividad de guardia durante un incidente de producción.
El equipo revisó la política para permitir Ethernet y funciones de display del dock pero negar explícitamente las interfaces de almacenamiento, incluso en dispositivos “permitidos”.
La lección: optimizar ampliando la confianza es optimizar para que tarde o temprano te facture por su propia comodidad.

3) Práctica aburrida pero correcta que salvó el día: “Inventario USB como código”

Una firma de servicios financieros gestionaba una flota mixta: servidores en datacenters, dispositivos edge en sucursales y kioscos.
Tenían una regla simple y aburrida: cada clase de host tenía una política USB documentada, versionada en la gestión de configuración.
No una página wiki. Archivos de política reales.

En un dispositivo edge, un operador informó que “una memoria USB dejó de funcionar.” Esa frase siempre es sospechosa:
o la bloqueaste intencionadamente (y está funcionando como se diseñó), o bloqueaste sin querer un dispositivo legítimo (y rompiste algo).

Revisaron logs de usbguard y vieron un nuevo dispositivo: mismo vendor y product que el módem “aprobado”, pero con distinto serial y una interfaz extra.
La política baseline permitía la clase de interfaz del módem y requería coincidencia de serial. Así que el nuevo dispositivo fue bloqueado por defecto.
La queja del operador fue la campana de alarma, no el problema.

Resultó que el módem había sido reemplazado por un tercero con una unidad más barata que reportaba IDs similares pero exponía una interfaz de almacenamiento.
La interfaz de almacenamiento contenía una herramienta de autorun para Windows. A la firma no le importaba autorun de Windows; les importaba la existencia de
una interfaz de almacenamiento inesperada en un dispositivo de camino de red. Rechazaron el hardware, actualizaron requisitos al proveedor y siguieron.

Lo que salvó la situación no fue un producto de seguridad mágico. Fue la práctica aburrida de: inventario baseline, allowlist explícita y logs que hicieron la decisión obvia.
Cuando puedes responder “¿qué cambió?” en minutos, duermes mejor.

Errores comunes (síntomas → causa raíz → solución)

Error 1: “Bloqueamos almacenamiento USB, pero a veces los discos siguen apareciendo.”

Síntomas: Algunas memorias USB se montan; otras no. El comportamiento varía según actualización del kernel o dispositivo.

Causa raíz: Bloqueaste usb_storage pero el dispositivo usa uas (USB Attached SCSI) u otra ruta, o tu initramfs aún carga módulos temprano.

Solución: Revisa módulos cargados tanto usb_storage como uas; actualiza initramfs; considera bloqueo basado en clases de usbguard para interfaces de almacenamiento.

Error 2: “Hicimos allowlist por vendor ID, ahora los atacantes nos suplantan.”

Síntomas: La política dice “permitir vendor X” y te sientes seguro. No deberías.

Causa raíz: VID:PID no es autenticación. El firmware puede presentar IDs. Además, dispositivos legítimos pueden cambiar IDs entre revisiones.

Solución: Prefiere serial + restricciones de interfaz. Si no hay serial, ata la política a rutas de puerto físicas en hardware fijo y aplica deny por defecto.

Error 3: “usbguard bloqueó nuestra UPS y la máquina se apagó durante mantenimiento.”

Síntomas: No se reportan eventos de energía; hooks de apagado no se disparan; el monitoreo pierde contacto con la UPS.

Causa raíz: La UPS era un dispositivo HID USB y tu política deny por defecto no la permitió, o la permitiste sin el detalle de interfaz requerido.

Solución: Añade una regla allow para la UPS con clase de interfaz específica. Prueba desenchufando/reenchufando durante una ventana de mantenimiento y confirma que el monitoreo la vea.

Error 4: “Bloqueamos todo y ahora la recuperación remota es imposible.”

Síntomas: No puedes usar medios virtuales BMC; la ISO de rescate no se adjunta; las manos remotas no pueden arrancar medios de recuperación.

Causa raíz: Negaste globalmente almacenamiento USB, pero la gestión fuera de banda presenta medios virtuales USB al SO.

Solución: Crea una excepción por clase de host: permite almacenamiento USB solo para dispositivos de medios virtuales BMC (VID:PID/puerto específico) o solo en modo break-glass con control de cambios.

Error 5: “Escribimos una regla udev, pero no se dispara.”

Síntomas: Enchufas el dispositivo y no pasa nada; la regla parece ignorada.

Causa raíz: El emparejamiento está mal (SUBSYSTEM vs SUBSYSTEMS), los atributos no existen en ese nodo de dispositivo, o hay conflicto en el orden de reglas.

Solución: Usa udevadm info -a -p contra la ruta del dispositivo para encontrar atributos correctos; verifica el orden del nombre del archivo de regla; vigila con udevadm monitor.

Error 6: “Bloqueamos nuevos dispositivos, pero sesiones antiguas siguen funcionando.”

Síntomas: Aplicas política pero un dispositivo ya conectado sigue funcionando.

Causa raíz: El cumplimiento se aplica al conectar; los montajes/controladores existentes permanecen enlazados.

Solución: Desmonta sistemas de archivos, baja interfaces y desenchufa/reenchufa físicamente si es necesario. Valida con lsblk y ip link.

Listas de verificación / plan paso a paso

Lista A: Construir un inventario USB que puedas defender

1. Ejecuta lsusb en un host conocido y limpio y captura la salida en tu repositorio de configuración o exportación CMDB.
   Los dispositivos en estado “normal” no deberían ser un misterio.
2. Para cada dispositivo que no sea root hub, registra: VID:PID, serial (si existe), clases de interfaz y ruta de puerto (desde udevadm monitor o sysfs).
3. Para almacenamiento USB o NICs, mapea a nodos del SO (lsblk, ip link) y documenta si está permitido para esa clase de host.
4. Decide tus clases de host: servidores de datacenter, jump hosts, estaciones de trabajo de desarrollador, kioscos, appliances edge. La misma política para todos es pereza y está mal.

Lista B: Elige la capa de aplicación (no sobre-ingenierices)

1. Si la regla es “nada de almacenamiento USB nunca”: deniega vía configuración de modprobe (y actualiza initramfs). Simple y fuerte.
2. Si necesitas excepciones (UPS, consola serial, Ethernet de dock específica): despliega usbguard y usa deny por defecto con allowlist.
3. Si necesitas un bloqueo táctico hoy: usa reglas de autorización udev para VID:PID específicos mientras construyes la política correcta.
4. Si existe automount: quítalo/desactívalo en servidores. No le des pista de despegue al almacenamiento USB.

Lista C: Plan de despliegue que no dejará la flota inservible

1. Comienza en modo observación: despliega usbguard pero registra decisiones; no bloquees aún si no estás seguro. Luego cambia a bloqueo cuando tengas política.
2. Pilota en un conjunto pequeño de hosts por clase, incluyendo los raros (los que tienen UPS, dongles serial, KVMs).
3. Valida flujos operativos: recuperación remota, acceso a consola, monitoreo UPS, gestión fuera de banda.
4. Añade un procedimiento break-glass: una anulación temporal de política con control de cambios estricto y reversión clara.
5. Haz de la política USB un artefacto revisado por CI. Si no es revisable, derivará hasta fallar.

Lista D: Respuesta a incidentes cuando se encuentra un dispositivo USB rogue

1. Captura logs: eventos journalctl -k alrededor del tiempo de inserción, más la salida de usbguard watch si está disponible.
2. Identifica en qué se enumeró: almacenamiento/HID/red/serial.
3. Contén: desmonta almacenamiento, baja interfaces, descarga módulos si es necesario y quita físicamente el dispositivo.
4. Evalúa: revisa historial de shell y registros sudo por comandos inyectados si sospechas HID; revisa cambios de red si apareció una NIC USB.
5. Prevén recurrencia: escribe reglas deny explícitas; luego crea la allowlist para dispositivos requeridos.

Preguntas frecuentes

1) ¿Simplemente debería deshabilitar todos los puertos USB en BIOS/UEFI?

En servidores que nunca necesitan entrada local y tienen gestión fuera de banda fiable, sí. Es limpio.
Pero muchos entornos aún necesitan USB para KVMs, monitoreo UPS o recuperación break-glass. No finjas que no.

2) ¿Bloquear usb_storage basta para detener memorias USB?

A menudo, pero no siempre. Algunos dispositivos se enlazan vía UAS, y la carga temprana de módulos puede eludir políticas aplicadas tarde.
Verifica con lsmod, logs del kernel y probando con un dispositivo tras reiniciar.

3) ¿Por qué no solo bloquear montajes y dejar los dispositivos?

Porque el almacenamiento no es el único riesgo. HID puede inyectar comandos, y las NICs USB pueden crear nuevos caminos de red.
“No automount” es buena higiene; no es una política de seguridad USB completa.

4) ¿Es seguro desplegar usbguard ampliamente?

Sí, si lo tratas como política de firewall: empieza con observación, genera política desde un estado conocido y limpio,
y despliega por clase de host. La versión peligrosa es habilitar deny por defecto en una máquina que no entiendes del todo.

5) ¿Cuál es el identificador más fiable para allowlist?

Los números de serie son los mejores cuando existen y son estables. Lo siguiente mejor es la ruta del puerto en hardware fijo.
VID:PID es útil pero no suficiente por sí solo.

6) ¿Cómo manejo dispositivos USB que legítimamente cambian IDs tras actualizaciones de firmware?

Planifícalo: trata las actualizaciones de firmware como cualquier cambio que puede afectar la política.
Usa restricciones de interfaz y, cuando sea posible, permite por serial en vez de solo VID:PID.
Mantén un entorno de staging para observar nuevos IDs antes de rodarlos en producción.

7) ¿Qué pasa con los “USB condom” bloqueadores de datos?

Pueden reducir riesgo en escenarios de solo carga, mayormente en móviles. En servidores no son una estrategia.
Tus controles deben ser aplicables por política y auditables, no depender de que alguien use el adaptador correcto bajo presión.

8) ¿Puedo bloquear solo nuevos dispositivos y mantener los existentes funcionando?

Sí, conceptualmente: deny por defecto para dispositivos nuevos mientras allowlisteas los conocidos.
En la práctica, debes probar reinicios y reenumeración porque “existente” a menudo se convierte en “nuevo” tras un reinicio.

9) ¿Cómo audito uso de USB en una flota?

Centraliza lsusb, lsblk (transporte USB) y logs de usbguard. Trata la salida como datos de inventario.
La clave es la consistencia: mismos comandos, mismo parseo, ejecuciones programadas y alertas por desviación.

Conclusión: próximos pasos que puedes desplegar

USB es un problema de fiabilidad con puesta de seguridad. La solución no es un único comando; es una política que puedas explicar, implementar y auditar.
Empieza por aprender qué está realmente conectado, decide qué debe permitir cada clase de host y aplícalo con la capa más simple que cumpla el requisito.

1. Hoy: Ejecuta las tareas de auditoría en un host representativo por clase. Captura la baseline.
2. Esta semana: Deshabilita servicios de automount en servidores y añade pasos de contención de emergencia a tu runbook de incidentes.
3. Este mes: Despliega usbguard donde necesites excepciones; de lo contrario bloquea almacenamiento USB a nivel de módulo. Despliega con pilotos y control de cambios.
4. Continuo: Trata la política USB como política de firewall—revisada, versionada y probada tras cambios de hardware/firmware.

El objetivo es USB aburrido. Aburrido es estable, seguro y agradablemente poco noticioso. A producción le encanta lo poco noticioso.