Bloquear el almacenamiento USB sin dejar inutilizados teclados y ratones

febrero 20, 2026 • febrero 20, 2026 • Lectura: 24 min • Views: 0

¿Te fue útil?

Si alguna vez aplicaste una política de “desactivar USB” y viste cómo se llenó la cola de soporte, ya conoces la verdad:
los endpoints son caóticos, los usuarios son creativos y USB es la cucaracha de las interfaces. No puedes simplemente “apagarlos”
sin afectar teclados, ratones, lectores de tarjetas inteligentes, auriculares, estaciones de acoplamiento y el ocasional
monitor que se cree un concentrador USB con ganas de opinar.

El objetivo es más estrecho y realista: bloquear el almacenamiento USB (clase mass storage) dejando intactos los dispositivos
de interfaz humana (HID). Hazlo con evidencia, implementaciones por etapas y un plan para los casos raros—porque los casos raros
son donde viven las interrupciones.

Contra qué te estás defendiendo realmente

“Bloquear almacenamiento USB” se vende como una casilla de seguridad. No lo es. Es un control que reduce algunos riesgos concretos:

Exfiltración de datos al copiar archivos a medios extraíbles.
Introducción de malware vía flujos tipo autorun (menos comunes ahora) y ejecución impulsada por el usuario (aún común).
Ergonomías operativas peligrosas como que alguien clone la máquina equivocada o arranque desde una herramienta USB “útil”.
Postura regulatoria: demostrar que puedes restringir medios extraíbles cuando sea requerido.

No soluciona ataques tipo “BadUSB” donde un dispositivo se hace pasar por teclado. Bloquear la clase mass storage no detendrá
un HID malicioso. Si necesitas eso, entras en territorio de listas blancas de dispositivos, control de puertos o controles físicos.

Una política usable normalmente luce así:
bloquear mass storage por defecto, permitir excepciones aprobadas (IDs de dispositivo específicos, máquinas concretas, roles definidos),
y registrar todo para poder responder “¿qué pasó?” sin malabarismos interpretativos.

Hechos y breve historia para usar en reuniones

USB Mass Storage Class (MSC) estandarizó el comportamiento “la memoria USB se muestra como disco”; es el código de clase 08 en USB.
HID es el código de clase 03. Teclados y ratones suelen estar aquí. Bloquear la clase 08 no debería afectar la 03—a menos que tus herramientas sean toscas.
Windows temprano adoraba autorun, y la resaca de seguridad duró años. Windows moderno lo limitó bastante, pero los usuarios siguen haciendo doble clic.
Muchos “pendrives” son dispositivos compuestos: almacenamiento más emulación de CD-ROM más interfaces del fabricante. Por eso algunos controles los pasan por alto.
UASP (USB Attached SCSI Protocol) mejoró el rendimiento de SSD externos, pero también cambió qué controladores se vinculan—otra vía para que las políticas fallen accidentalmente.
Los teléfonos a menudo se presentan como MTP/PTP, no como almacenamiento masivo. Si tu política solo bloquea MSC, los usuarios aún pueden mover datos por protocolos de teléfono.
USB-C hizo el “puerto” ambiguo: el mismo conector puede llevar almacenamiento, red, vídeo y energía. Bloquear por puerto ahora es un instrumento tosco.
Linux históricamente vinculó almacenamiento USB mediante el módulo usb-storage. Bloquear ese módulo es efectivo, pero puede también romper flujos legítimos de arranque y comportamientos de docking.
Algunos teclados empresariales incluyen hubs USB. El teclado funciona, el hub se enuncia y de repente tu política “no USB” cree que encontró una nueva clase de dispositivo.

Principios de diseño: bloquear almacenamiento, no USB

Si recuerdas una cosa: no “desactives USB”. Desactiva la capacidad de montar o acceder al almacenamiento extraíble.
Son problemas diferentes con radios de impacto distintos.

1) Sé específico sobre qué significa “almacenamiento USB”

Apuntas a dispositivos que exponen interfaces de almacenamiento en bloque: código de clase 08, o controladores como
usb-storage en Linux y USBSTOR en Windows. Pero también vigila:

Lectores de tarjetas SD integrados en teclados/docks (a menudo USB MSC).
Envoltorios NVMe externos (MSC o UASP).
CD-ROM virtual en unidades “seguras”.
Almacenamiento Thunderbolt (no es la clase USB 08 en absoluto; superficie de control distinta).

2) Decide si necesitas “bloquear” o “lista blanca”

Bloquear MSC ampliamente es más sencillo y suele ser suficiente. Hacer lista blanca es más seguro pero caro de mantener.
En la práctica:

La mayoría de organizaciones: bloquean mass storage, permiten excepciones por ID de dispositivo para unidades cifradas aprobadas, y registran.
Endpoints de alto riesgo: lista blanca por VID:PID y serie; negar todo lo demás; usar estaciones de acoplamiento y teclados gestionados.

3) Piensa en capas: kernel/controlador + política + sistema de archivos

Bloqueo a nivel de controlador evita que el dispositivo funcione como almacenamiento. Bloqueo a nivel de política puede evitar
instalación o montaje. Controles a nivel de sistema de archivos (como restricciones de montaje) pueden reducir el daño aun cuando el dispositivo esté presente.

El apilamiento importa porque atacantes y accidentes no respetan tu capa favorita.

4) El registro es parte del control

Si tu única señal es “el usuario dice que el ratón dejó de funcionar”, operas por folclore.
Registra qué se bloqué, por qué y cómo coincidió con tu regla.

Idea parafraseada de Gene Kim: la ganancia en fiabilidad viene de bucles de retroalimentación rápidos y aprender del fallo, no de arreglos heroicos a posteriori.

Caja de herramientas Linux: módulos, udev, USBGuard

Linux te da múltiples palancas. Usa el instrumento menos tosco que aún mantenga la línea.

Opción A: Deshabilitar el módulo `usb-storage` (efectivo, tosco)

Esto impide que dispositivos MSC USB se vinculen al controlador de almacenamiento. Es simple y funciona bien en servidores y kioscos.
También puede sorprender en portátiles de desarrollo y bancos de soporte, donde la gente usa medios extraíbles legítimamente.

Tampoco es completo: UAS usa el controlador uas, y algunos dispositivos se vinculan de forma distinta. Necesitas bloquear ambos si vas en serio.

Opción B: reglas udev para desautorizarlos (quirúrgico, fácil de estropear)

udev puede hacer coincidir dispositivos y cambiar la autorización. La ventaja: puedes coincidir por código de clase, fabricante, producto e interfaz.
La desventaja: una coincidencia descuidada y desautorizarás el bus USB interno detrás del teclado de un portátil.

Opción C: USBGuard (motor de políticas, ideal para flotas)

USBGuard proporciona reglas de permitir/denegar, registro y un lenguaje de políticas que entiende atributos del dispositivo.
Encaja mejor con “bloquear almacenamiento pero permitir HID”, porque puedes permitir explícitamente HID y bloquear explícitamente mass storage,
y manejar excepciones de forma limpia.

Si gestionas una flota, elige USBGuard o una plataforma de gestión de endpoints que haga lo mismo.
Si estás endureciendo una sola máquina, la lista negra de módulos está bien.

Caja de herramientas Windows: GPO, registro, restricciones de instalación

Windows es donde la mayoría de organizaciones tropiezan, porque hay múltiples mecanismos superpuestos:

Servicio USBSTOR: deshabilitarlo bloquea la carga del controlador de almacenamiento USB.
Políticas de Acceso a Almacenamiento Extraíble: restringen acceso de lectura/escritura por clase.
Restricciones de instalación de dispositivos: evitan que clases o IDs específicos de dispositivo se instalen.

La respuesta corporativa limpia suele ser: GPO para bloquear almacenamiento USB, con un proceso de excepción para dispositivos cifrados aprobados.
Pero necesitas validar que no estás bloqueando lectores de tarjetas inteligentes, biometría o dispositivos compuestos usados para autenticación.

Nota sobre macOS: la verdad incómoda

macOS puede controlarse mediante perfiles MDM, herramientas de seguridad endpoint y en algunos casos restringiendo medios extraíbles.
Pero las especificaciones varían mucho según la versión del SO y la plataforma de gestión.

Operativamente: si tienes una flota mixta, no diseñes la política en torno a la plataforma que mejor conoces. Diseñala en torno a
resultados consistentes: “no montes medios extraíbles no gestionados”, “dispositivos aprobados permitidos” y “eventos registrados centralmente”.

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando intento bloquear almacenamiento USB sin dejar inutilizados teclados y ratones.
Cada tarea incluye: el comando, cómo luce una salida realista, qué significa y qué decisión tomar.

Tarea 1: Identificar qué considera el kernel USB vs no (Linux)

cr0x@server:~$ lsusb
Bus 002 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 002 Device 003: ID 0781:5567 SanDisk Corp. Cruzer Blade
Bus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. USB3.0 Card Reader

Significado: tienes un receptor Logitech (probablemente HID), una unidad SanDisk (almacenamiento) y un lector de tarjetas (almacenamiento).

Decisión: planea bloquear dispositivos de clase almacenamiento y considera si también quieres bloquear lectores integrados en docks.

Tarea 2: Verificar códigos de clase de interfaz USB (Linux)

cr0x@server:~$ lsusb -v -d 0781:5567 | egrep -i 'bInterfaceClass|bInterfaceSubClass|bInterfaceProtocol' | head
  bInterfaceClass         8 Mass Storage
  bInterfaceSubClass      6 SCSI
  bInterfaceProtocol     80 Bulk-Only

Significado: esto es MSC clásico (clase 8). Si bloqueas interfaces de clase 8, este dispositivo dejará de funcionar como almacenamiento.

Decisión: seguro bloquear a nivel de interfaz/clase, dejando la clase 3 (HID) intacta.

Tarea 3: Confirmar que teclados y ratones se enumeran como HID (Linux)

cr0x@server:~$ lsusb -v -d 046d:c534 | egrep -i 'bInterfaceClass|HID' | head
  bInterfaceClass         3 Human Interface Device
  iInterface              0

Significado: dispositivo de clase HID. Tu enfoque “bloquear clase 8” no debería tocarlo.

Decisión: permite explícitamente la clase HID en cualquier motor de permitir/denegar que despliegues (USBGuard), porque la claridad vence a la esperanza.

Tarea 4: Ver qué módulos del kernel están en juego (Linux)

cr0x@server:~$ lsmod | egrep 'usb_storage|uas|usbhid' | head
usbhid                 61440  0
usb_storage            73728  1 uas
uas                    28672  0

Significado: usbhid está cargado (bien), y existen tanto usb_storage como uas (vías de almacenamiento).

Decisión: si solo pones en lista negra usb_storage, los dispositivos UASP pueden seguir funcionando vía uas. Bloquea ambos para consistencia.

Tarea 5: Observar qué pasa al conectar una memoria USB (Linux)

cr0x@server:~$ sudo udevadm monitor --kernel --udev
KERNEL[2317.332122] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb)
UDEV  [2317.410923] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb)
KERNEL[2317.972114] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb)
UDEV  [2317.973881] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb)

Significado: estás viendo nodos de dispositivo e interfaz. La interfaz (…:1.0) es donde a menudo se hacen coincidencias por clase.

Decisión: construye reglas alrededor de atributos de interfaz, no solo VID:PID de dispositivo, cuando quieras “bloquear almacenamiento, permitir HID.”

Tarea 6: Inspeccionar atributos sysfs de un dispositivo específico (Linux)

cr0x@server:~$ usb_path=$(readlink -f /sys/bus/usb/devices/2-1)
cr0x@server:~$ echo "$usb_path"
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1
cr0x@server:~$ cat /sys/bus/usb/devices/2-1/idVendor; cat /sys/bus/usb/devices/2-1/idProduct
0781
5567

Significado: sysfs te da identificadores relativamente estables para escribir reglas udev o políticas USBGuard.

Decisión: usa VID:PID para listas blancas de excepciones; añade serie si necesitas control más estricto.

Tarea 7: Poner en lista negra módulos de almacenamiento (Linux)

cr0x@server:~$ sudo tee /etc/modprobe.d/usb-storage-block.conf >/dev/null <<'EOF'
blacklist usb_storage
blacklist uas
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.5.0-26-generic

Significado: has impedido que estos módulos se carguen en arranques futuros, y reconstruiste initramfs para que el arranque temprano lo respete.

Decisión: usa esto en servidores/kioscos donde realmente nunca quieras almacenamiento extraíble. En portátiles, prefiere motores de políticas y excepciones.

Tarea 8: Validar que el almacenamiento ya no se vincula después de un reinicio (Linux)

cr0x@server:~$ lsmod | egrep 'usb_storage|uas' || echo "no usb storage modules loaded"
no usb storage modules loaded

Significado: el kernel no ofrece la vía de almacenamiento habitual.

Decisión: procede solo si confirmaste que los flujos legítimos no necesitarán almacenamiento USB (o tienes un camino de recuperación fuera de banda).

Tarea 9: Desplegar USBGuard y generar una política base (Linux)

cr0x@server:~$ sudo apt-get install -y usbguard
Reading package lists... Done
Setting up usbguard (1:1.0.0-2) ...
cr0x@server:~$ sudo usbguard generate-policy
allow id 046d:c534 serial "" name "Unifying Receiver" hash "..."
block with-interface equals { 08:*:* }

Significado: la política base permite tu receptor existente y bloquea interfaces de clase 08 (almacenamiento masivo).

Decisión: revisa la política generada antes de hacerla cumplir. Las líneas base pueden “permitir” accidentalmente algo que no quieres, como un lector de tarjetas integrado en un dock.

Tarea 10: Activar la aplicación y confirmar el registro (Linux USBGuard)

cr0x@server:~$ sudo sed -i 's/^ImplicitPolicyTarget=.*/ImplicitPolicyTarget=block/' /etc/usbguard/usbguard-daemon.conf
cr0x@server:~$ sudo systemctl enable --now usbguard
cr0x@server:~$ sudo systemctl status usbguard --no-pager | head
● usbguard.service - USBGuard daemon
     Loaded: loaded (/lib/systemd/system/usbguard.service; enabled)
     Active: active (running)

Significado: el daemon está corriendo; la política implícita es block, así que dispositivos desconocidos son denegados salvo que una regla los permita.

Decisión: etapa la aplicación primero en modo “solo registro” si puedes (o comienza en un grupo canario). Los endpoints de producción odian las sorpresas.

Tarea 11: Probar que HID sigue funcionando mientras el almacenamiento está bloqueado (Linux)

cr0x@server:~$ sudo usbguard list-devices
1: allow id 046d:c534 name "Unifying Receiver" serial "" via-port "usb2" with-interface { 03:00:00 }
2: block id 0781:5567 name "Cruzer Blade" serial "..." via-port "usb2" with-interface { 08:06:80 }

Significado: HID (03) permitido; almacenamiento (08) bloqueado.

Decisión: esta es la captura de pantalla clave para tu solicitud de cambio. Demuestra “teclados/ratones OK, almacenamiento no.”

Tarea 12: Investigar por qué aún se montó un dispositivo de almacenamiento (Linux)

cr0x@server:~$ dmesg | tail -n 12
[ 4123.112233] usb 2-1: new SuperSpeed USB device number 7 using xhci_hcd
[ 4123.134455] scsi host6: uas
[ 4123.145678] scsi 6:0:0:0: Direct-Access     Samsung  Portable SSD T7  0    PQ: 0 ANSI: 6
[ 4123.156789] sd 6:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)

Significado: UAS adjunto. Si solo bloqueaste usb-storage, UAS aún podría funcionar. O tu política lo permite.

Decisión: asegúrate de que uas esté bloqueado (lista negra de módulos) o que tu política bloquee la clase de interfaz 08 independientemente del transporte.

Tarea 13: Windows: Comprobar si USBSTOR está deshabilitado (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\USBSTOR' -Name Start"
Start : 4
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR

Significado: Start=4 está deshabilitado. (Valores comunes: 3=manual, 4=deshabilitado.)

Decisión: si tu intención es bloquear almacenamiento USB ampliamente, este es un control fuerte. Si necesitas excepciones, requerirás un enfoque más matizado.

Tarea 14: Windows: Verificar política de acceso a almacenamiento extraíble (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices' -ErrorAction SilentlyContinue"

Significado: normalmente ninguna salida significa que la clave de política no está establecida en esta máquina (o se gestiona en otro lado).

Decisión: si el entorno depende de GPO, confirma con gpresult y la política central en lugar de editar el registro a mano.

Tarea 15: Windows: Ver qué clase de dispositivo es algo (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object { $_.FriendlyName -match 'USB' } | Select-Object -First 8 Status,Class,FriendlyName"
OK  HIDClass  USB Input Device
OK  DiskDrive Samsung Portable SSD T7 USB Device
OK  USB       USB Composite Device
OK  HIDClass  HID-compliant mouse

Significado: puedes distinguir HIDClass de DiskDrive. Los dispositivos compuestos aparecen por separado.

Decisión: si ves entradas DiskDrive que no esperabas, tu control no está funcionando o las excepciones son demasiado amplias.

Tarea 16: Windows: Confirmar políticas aplicadas (gpresult)

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects' -Context 0,8"
Applied Group Policy Objects
-----------------------------
    Workstation Baseline
    Removable Media Restrictions

Significado: has verificado los objetos de política aplicados. Esto importa al resolver “funciona en mi máquina”.

Decisión: si el GPO esperado no aparece, deja de culpar a los controladores y corrige el direccionamiento de la política primero.

Guía de diagnóstico rápido

Cuando alguien informa “el almacenamiento USB está bloqueado” o “mi teclado murió” justo después de un cambio, necesitas una vía rápida a la verdad.
Aquí está el orden que ahorra tiempo.

Primero: ¿es un problema de almacenamiento o de dispositivo de entrada?

Linux: ejecuta lsusb y verifica códigos de clase con lsusb -v para el dispositivo en cuestión.
Windows: Get-PnpDevice filtrando por clase HIDClass vs DiskDrive.

Si es HID y está roto, tu política es demasiado amplia o bloqueaste un hub padre. Trátalo como una interrupción.

Segundo: ¿se vinculó el dispositivo a un controlador?

Linux: revisa dmesg por usb-storage o uas, y revisa lsmod.
Windows: revisa el estado del servicio USBSTOR y el estado del dispositivo en PnP.

Si el controlador nunca se vinculó, tu bloqueo está funcionando (o es demasiado agresivo). Si se vinculó, te falta una vía (UAS, comportamiento compuesto, Thunderbolt).

Tercero: ¿es problema de la política o de la aplicación?

Linux: estado y lista de dispositivos de USBGuard; reglas udev y estado de autorización en sysfs.
Windows: gpresult y las claves de registro de política.

Si las políticas no están aplicadas, no depures dispositivos. Arregla el direccionamiento. Si las políticas están aplicadas pero son inefectivas, probablemente bloqueaste la clase equivocada o perdiste un controlador alterno.

Tres microhistorias corporativas desde el campo

1) Incidente causado por una suposición errónea: “los dispositivos HID no se afectan”

Una empresa mediana desplegó un cambio para “bloquear almacenamiento USB” en escritorios Linux usados por su equipo de soporte al cliente.
El ingeniero que escribió la regla udev coincidió en la palabra “USB” en un filtro de subsistema y luego desautorizó todo el nodo de dispositivo.
La suposición fue que el almacenamiento es “un dispositivo”, así que bloqueó el dispositivo.

Lo que no vieron: muchos escritorios usaban teclados baratos con hubs USB incorporados. El teclado se anunciaba como HID,
pero el hub se anunciaba como un dispositivo separado. La regla udev se disparó en el hub, lo desautorizó y dejó fuera de servicio al teclado.
El ratón, enchufado al teclado, también dejó de funcionar.

Se acumularon llamadas de soporte. La remediación remota fue posible en algunos sistemas, pero un grupo de endpoints no pudo controlarse porque
necesitabas teclado/ratón para iniciar sesión, y las herramientas remotas requerían aprobación interactiva. La solución fue ir físicamente
a escritorios con un teclado cableado de confianza conectado directamente al portátil/dock.

El postmortem fue aburrido y correcto: hacer coincidir solo la clase de interfaz 08, probar con dispositivos compuestos y mantener un mecanismo de reversión que no requiera entrada local.
Además, no publiques una regla que no hayas probado contra al menos un modelo de docking y un “teclado de oficina aleatorio”.

2) Optimización que se volvó en contra: “listas negras de módulos en todas partes”

Otra organización quiso una victoria rápida, así que pusieron en lista negra usb_storage en todos los hosts Linux usando su sistema de gestión de configuración.
Funcionó. También rompió su flujo de trabajo on-call de una manera que no apareció en las pruebas.

Su proceso de recuperación de servidores dependía de arrancar una imagen conocida desde una memoria USB para ciertos problemas bare-metal.
No todos los servidores tenían medios virtuales operativos, y no todos los incidentes ocurrieron en un datacenter con consola perfecta.
La lista negra no solo bloqueó copias casuales; eliminó una herramienta de recuperación.

En el siguiente incidente real, un ingeniero on-call llegó con su medio de recuperación USB y descubrió que el host no lo veía.
Perdieron tiempo, luego más tiempo explicando a seguridad por qué la “solución simple” tuvo consecuencias operativas. La ironía es que
el equipo de seguridad no estaba contento, pero la interrupción fue real.

Pivotaron a un enfoque por niveles: lista negra en kioscos y escritorios de centros de llamadas, USBGuard permitir/denegar en portátiles de desarrolladores,
y excepciones “romper el cristal” para un pequeño conjunto de máquinas de soporte. Mismo objetivo de seguridad, menos autodaño.

3) Práctica aburrida pero correcta que salvó el día: “canario y registros”

Una gran empresa hizo el despliegue como nadie quiere porque parece lento: anillo canario, luego piloto,
luego despliegue amplio. También habilitaron registro detallado desde el motor de políticas a su plataforma de logs central con un conjunto de campos estándar:
ID de dispositivo, clases de interfaz, acción tomada, regla aplicada.

Durante el piloto, un dock de auriculares específico empezó a fallar. No de forma intermitente—consistente. El soporte tenía un síntoma claro:
“Dock de audio USB no reconocido.” Los datos de logs mostraron que el dock exponía un lector de tarjetas (clase MSC 08) además de audio.
La política estaba denegando el dispositivo compuesto entero, no solo la interfaz de almacenamiento. Esa es una sutileza de política, no un problema del usuario.

Como estaba en piloto y los logs eran buenos, hicieron una excepción dirigida: permitir ese dispositivo, pero denegar su interfaz de almacenamiento,
y aplicar “no montar” a nivel del SO para medios extraíbles. El dock funcionó, el almacenamiento no, y el negocio no sintió el cambio.

Nadie escribió un correo heroico. Nadie recibió un trofeo. El despliegue tuvo éxito en silencio—que es el único tipo de éxito en el que debe confiar operaciones.

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

1) Síntoma: teclado y ratón dejan de funcionar después de “bloquear almacenamiento USB”

Causa raíz: bloqueaste un hub ascendente o desautorizaste todo el nodo USB en lugar de la interfaz de almacenamiento.

Solución: coincidir y bloquear solo la clase de interfaz 08. Si usas USBGuard, permite explícitamente interfaces HID; evita por defecto “bloquear todo USB” en endpoints.

2) Síntoma: pendrives USB aún funcionan en algunas máquinas

Causa raíz: política no aplicada (alcance GPO, deriva en gestión de configuración), o vía UAS no bloqueada (uas aún cargado).

Solución: verifica la aplicación de la política (gpresult en Windows; estado/ configuración del servicio en Linux), y bloquea tanto usb_storage como uas o bloquea la clase 08 en la capa de política.

3) Síntoma: transferencia de archivos desde el teléfono sigue funcionando tras bloquear almacenamiento USB

Causa raíz: los teléfonos usan MTP/PTP, no la clase mass storage 08.

Solución: decide si tu requisito incluye MTP/PTP. Si sí, restringe esos protocolos vía políticas endpoint/MDM y controles de prevención de pérdida de datos.

4) Síntoma: una estación de acoplamiento deja de funcionar (red, pantalla, audio) al bloquear almacenamiento

Causa raíz: dispositivo compuesto tratado como “una sola cosa”, y la denegación afecta al dispositivo entero; o el motor de políticas deniega el dock porque incluye un lector MSC.

Solución: permite el dock por ID y deniega solo la interfaz de almacenamiento si tu herramienta soporta reglas por interfaz; de lo contrario elige un modelo de dock sin lector integrado.

5) Síntoma: los usuarios aún pueden escribir en unidades USB pero no leer (o viceversa)

Causa raíz: política parcial (interruptores de lectura/escritura configurados de forma inconsistente) o opciones de montaje aplicadas solo a algunos puntos de montaje.

Solución: estandariza: o niegas el controlador por completo, o haces cumplir restricciones coherentes de lectura/escritura con política gestionada centralmente y prueba ambas direcciones.

6) Síntoma: “almacenamiento USB bloqueado” rompe flujos de arranque/recuperación

Causa raíz: bloqueaste almacenamiento a nivel de controlador en máquinas que necesitan medios USB para recuperación.

Solución: define hosts o roles con excepción “romper cristal”; documenta caminos de recuperación; considera tokens de permiso temporales en lugar de excepciones permanentes.

7) Síntoma: dispositivos cambian aleatoriamente entre permitido y bloqueado

Causa raíz: lista blanca sin números de serie; VID:PID coincide con múltiples lotes; cambios en la topología de hubs; actualizaciones de línea base de políticas hechas sin cuidado.

Solución: incluye la serie cuando sea posible; trata las actualizaciones de política como código; prueba en hardware representativo; registra coincidencias de reglas.

Broma #1: USB significa “Universal Serial Bus”, pero en producción a menudo significa “Usualmente Alguien lo Rompió”.

Listas de verificación / plan paso a paso

Paso 1: Decide el límite de la política (y escríbelo)

¿Bloquear la clase USB MSC 08 por defecto?
¿Permitir unidades cifradas aprobadas?
¿Qué hacer con lectores SD en docks?
¿Y con teléfonos (MTP/PTP), cámaras y adaptadores Ethernet USB?
¿Necesitas prevenir el arranque desde USB, o solo el montaje en el SO?

Si no puedes responder esto, no tienes una política; tienes una vibra.

Paso 2: Inventario del hardware real en tu entorno

Al menos un ejemplo de cada modelo de portátil.
Cada modelo de dock en circulación.
Al menos dos “teclados de oficina aleatorios” (en serio).
Lectores de tarjetas y dispositivos biométricos usados para inicio de sesión.

Recopila VID:PID y clases de interfaz. No adivines.

Paso 3: Elige tu mecanismo de aplicación por tipo de endpoint

Servidores/kioscos: lista negra de módulos Linux + restricciones de montaje en sistema de archivos; Windows USBSTOR deshabilitado si no se necesitan excepciones.
Portátiles de empleados: motor de políticas (USBGuard / herramienta endpoint), con excepciones en lista blanca y registro fuerte.
Workstations privilegiadas/administrativas: modo lista blanca; trata cualquier dispositivo nuevo como sospechoso hasta aprobado.

Paso 4: Construye excepciones deliberadamente

Prefiere listas blancas de modelos de unidades cifradas por VID:PID + número de serie.
Limita temporalmente las excepciones (p. ej., aprobaciones de corta duración) si tu herramienta lo soporta.
Requiere una razón de negocio y un responsable para cada excepción.

Paso 5: Despliegue canario (no negociable si te gusta dormir)

Comienza con endpoints de TI y seguridad. Pueden auto-recuperarse.
Luego un grupo piloto con setups de docking representativos.
Luego despliegue amplio.

Broma #2: La mejor ventana de cambio es “nunca”, pero la segunda mejor es “después de haber probado en el dock del CFO”.

Paso 6: Registro y alertas

Centraliza logs de “dispositivo bloqueado” y “dispositivo permitido por excepción”.
Alerta por bloqueos repetidos en una sola máquina (puede ser comportamiento de usuario o preparación de malware).
Rastrea los modelos de dispositivo más bloqueados; normalmente es un dock/lector de tarjetas que no conocías.

Paso 7: Runbook operativo y reversión

Tener una reversión que no requiera entrada local de teclado/ratón (gestión remota, consola fuera de banda).
Mantener un procedimiento documentado de “permitir emergencia” con aprobaciones.
Entrenar al helpdesk en qué preguntar: modelo de dispositivo, dock, si el dispositivo es almacenamiento o HID.

Preguntas frecuentes

1) ¿Bloquear el almacenamiento USB detendrá ataques BadUSB?

No. BadUSB a menudo se presenta como teclado (HID). Bloquear la clase mass storage 08 no bloquea la clase HID 03.
Si necesitas mitigar eso, necesitas listas blancas de dispositivos, control de puertos o restricciones físicas.

2) ¿Por qué no simplemente desactivar todos los puertos USB?

Porque romperás la entrada básica, smartcards, docking y a veces la conectividad de red.
Además, los puertos USB-C son multipropósito; “desactivar el puerto” suele equivaler a “dejar inoperativo el puesto de trabajo del usuario”.

3) ¿Es suficiente poner en lista negra `usb-storage` en Linux?

A menudo sí, pero no siempre. Muchos dispositivos modernos usan UAS, que se vincula a uas.
Si tomas la ruta de lista negra de módulos, bloquea tanto usb_storage como uas, y valida con dispositivos reales.

4) Si bloqueamos almacenamiento USB, ¿pueden los usuarios seguir sacando datos?

Sí. Email, sincronización en la nube, capturas de pantalla, teléfonos vía MTP y adaptadores Ethernet USB existen.
Bloquear almacenamiento USB reduce un canal. No es una estrategia completa de prevención de pérdida de datos.

5) ¿Cómo permitimos solo unidades USB cifradas aprobadas?

Usa lista blanca por VID:PID más números de serie cuando sea posible, y mantén un flujo de excepciones.
En Linux, las políticas USBGuard son una vía práctica. En Windows, combina USBSTOR/restricciones de dispositivo con una herramienta endpoint que soporte control de dispositivo y auditoría.

6) ¿Y los lectores de tarjetas SD en portátiles y docks?

Muchos se anuncian como almacenamiento masivo USB. Si tu requisito es “sin medios extraíbles”, bloquéalos también.
Si tu requisito es “no unidades flash externas”, puede que necesites excepciones por dispositivo para no romper docks con lectores integrados.

7) ¿Podemos bloquear el montaje pero dejar que el dispositivo se enuncie?

Sí. Es un control más suave: el dispositivo aparece, pero el SO no lo montará ni permitirá acceso.
Puede reducir roturas, pero es más fácil de sortear si los usuarios tienen privilegios de administrador o si otros subsistemas pueden acceder a dispositivos brutos.

8) ¿Cómo probamos ante auditores que el almacenamiento USB está bloqueado?

Proporciona evidencia desde múltiples capas: configuración de políticas (GPO/USBGuard), verificación en endpoint (comandos que muestran controlador deshabilitado),
y logs que demuestren bloqueos con identificadores de dispositivo y marcas temporales.

9) ¿Cuál es la razón más común por la que fallan estos despliegues?

Tratar “almacenamiento USB” como una categoría de dispositivo en vez de una categoría de interfaz/controlador, y bloquear demasiado alto en la pila
(hubs, dispositivos compuestos o todo USB).

Próximos pasos que puedes hacer esta semana

Si quieres una política que bloquee almacenamiento USB y no se convierta en un generador semanal de incidentes, haz esto en orden:

Inventario: ejecuta comprobaciones de códigos de clase en tu mezcla real de hardware, especialmente docks y lectores integrados.
Elige la aplicación por endpoint: lista negra de módulos para sistemas de propósito fijo; motor de políticas para endpoints de usuario.
Bloquea rutas clásicas y modernas: en Linux, piensa en usb_storage y uas; en Windows, valida USBSTOR y políticas de almacenamiento extraíble.
Despliegue canario con registro: si no puedes ver qué estás bloqueando, solo estás adivinando en voz alta.
Planifica excepciones: unidades cifradas aprobadas y dispositivos compuestos requeridos obtienen reglas explícitas, no permisos a mano.

Lo más importante: no lances un control que no puedas revertir. Los cambios de seguridad que dejan fuera de servicio dispositivos de entrada son memorables por todas las razones equivocadas.