Cómo detectar eventos USB en Linux y crear acciones automáticas

Controlar qué pasa cuando alguien conecta un pendrive o cualquier periférico USB en una máquina Linux es clave para la seguridad y para la operativa del día a día. Detectar el evento y disparar automáticamente acciones como registrar, alertar o ejecutar scripts es sencillo si conoces las piezas correctas del sistema.

En esta guía práctica unimos tres pilares del ecosistema: udev para la detección y reacción en caliente, auditd para la auditoría de acciones y journald para la consulta y conservación de registros. Además, veremos utilidades como lsusb y lsblk para identificar dispositivos, y añadimos un apartado para entornos mixtos con Windows donde también puede interesar centralizar datos de USB. Todo explicado con ejemplos reales y recomendaciones de campo.

Detección de dispositivos: udev, uevents y sysfs

El gestor moderno de dispositivos en espacio de usuario es udev (en sistemas actuales, el servicio es systemd-udevd). Su cometido es procesar los eventos que el kernel emite cuando un dispositivo se añade, se retira o cambia de estado, generando nodos bajo /dev, asignando permisos y, si lo deseamos, ejecutando scripts.

Las reglas se cargan desde /lib/udev/rules.d y /run/udev/rules.d, pero donde tú debes escribir las tuyas es en /etc/udev/rules.d/. Los ficheros .rules de este directorio tienen prioridad, así que es el lugar ideal para personalizar el comportamiento ante eventos USB.

Para inspeccionar qué está sucediendo en vivo, usa el monitor de udev: verás en tiempo real los uevents del kernel y los eventos posteriores de udev, perfecto para depurar qué coincide y qué no.

$ sudo udevadm monitor

Cuando enchufas un dispositivo, el kernel expone atributos bajo /sys (sysfs). udev obtiene de ahí seriales, mayor/menor, tipo de bus y más para identificar unívocamente el hardware. Puedes consultar lo que udev sabe de un dispositivo con:

$ sudo udevadm info /dev/sdb

Si lo que quieres es simplemente averiguar el nombre de bloque asignado (por ejemplo, para una memoria USB), te servirá lsblk, que combina datos de sysfs y la base de udev. Así localizas /dev/sdb1 o similar de forma rápida:

$ lsblk

Ejecutar scripts al conectar y retirar un USB

Una receta clásica consiste en lanzar un script al detectar el evento ADD y otro cuando se produce REMOVE. Crearemos dos scripts sencillos que escriben en un log:

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

Ahora define la regla de udev en /etc/udev/rules.d/80-usb-actions.rules para disparar estos scripts solo ante dispositivos de tipo USB a nivel de dispositivo (no interfaces):

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

En estas líneas, SUBSYSTEM, ACTION y ENV{…} son los campos de coincidencia, y RUN+= define el comando a ejecutar. Dos operadores clave que verás en reglas:

• ==: compara igualdad en un campo (por ejemplo, acción o subsistema).
• +=: añade un valor a una lista (se usa para acumular comandos en RUN).

Carga los cambios sin reiniciar con un simple reload del gestor de udev y prueba conectando/desconectando una unidad USB para verificar que el fichero de log se va actualizando.

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

Consejo operativo: evita ejecutar tareas largas directamente desde RUN. Si necesitas un proceso pesado, llama a un script que a su vez delegue en un servicio systemd o encolado; así no bloqueas el procesamiento del evento.

Auditoría de acciones con auditd

Más allá de reaccionar al evento de hardware, puede interesarte auditar qué hacen los usuarios tras conectar un USB: comandos ejecutados, accesos a ficheros, cambios de permisos, etc. Ahí entra auditd, el servicio de auditoría del kernel en Linux.

Instálalo desde los repositorios de tu distribución e inspecciona su configuración principal en /etc/audit/auditd.conf. Algunos parámetros relevantes que conviene ajustar:

• log_file: ruta del registro, por defecto /var/log/audit/audit.log.
• flush y freq: controlan la frecuencia de volcado a disco de las trazas en memoria.
• max_log_file: tamaño máximo (MB) del fichero de auditoría.
• max_log_file_action: qué hacer al alcanzar el máximo. Opciones típicas: ignore, syslog, suspend, rotate, keep_logs.
• num_logs: cuántos ficheros mantener cuando usas rotate.
• space_left: umbral de espacio libre (MB) en el sistema de archivos del log a partir del cual se ejecuta space_left_action.
• space_left_action: reacción ante poco espacio. Soporta ignore, syslog, rotate, email (usa la cuenta en action_mail_acct), exec /ruta/script, suspend, halt.
• disk_full_action: análogo a space_left_action cuando el disco está lleno.

La potencia real de auditd está en las reglas. Colócalas en /etc/audit/rules.d/ con extensión .rules. Por ejemplo, para registrar cada ejecución de comando realizada por un usuario concreto:

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

Aquí indicamos: always,exit para auditar siempre al finalizar la llamada, execve como syscall objetivo, filtramos por euid del usuario y etiquetamos con -k para buscar luego con facilidad. Recuerda reiniciar o recargar el servicio tras añadir reglas.

Para consultar sin pelearte con ficheros binarios, usa ausearch y filtra por etiqueta, usuario, fecha u otros campos. Así podrás comprobar que acciones como borrar ficheros quedan registradas y asociadas al UID correcto.

$ sudo ausearch -k acciones_usuario

Con una combinación inteligente de udev (disparo) y auditd (trazabilidad), obtienes una visión completa: quién conectó algo, qué ocurrió después y con qué comandos.

Ver, filtrar y conservar registros con journald

En sistemas con systemd, el subsistema de registro central es journald. Almacena logs en formato binario indexado y ofrece journalctl para consultar, filtrar y gestionar espacio en disco de los registros del sistema.

Algunas consultas útiles del día a día: filtrar por prioridad, acotar por rango temporal, seguir en tiempo real o centrarse en una unidad de systemd (service) concreta.

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

Para gestionar el tamaño del journal, comprueba uso y aplica políticas de limpieza. Es habitual limitar por tamaño total para evitar crecer sin control:

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

La configuración reside en /etc/systemd/journald.conf. Opciones interesantes incluyen:

• Storage=auto: elige automáticamente cómo y dónde guardar.
• MaxFileSec=1month: define retención temporal por fichero.
• RateLimitBurst=1000: limita ráfagas de eventos para evitar tormentas de log.
• ForwardToSyslog=yes: reenvía a syslog si lo necesitas para integraciones heredadas.

Entre auditd y journald te llevas lo mejor de cada casa: auditoría detallada y consulta flexible con filtros potentes y control del almacenamiento.

Identificar y entender tus dispositivos: lsusb, lsusb -tv y lsblk

Para inventariar qué hay colgado del bus USB, lsusb es el clásico. Te lista buses, dispositivos y su ID vendedor:producto, algo imprescindible para escribir reglas udev específicas.

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

Si quieres ver la topología en formato árbol, añade -t y para detalle extra, -v. Así distingues hub raíz, controladores y puertos, y qué driver maneja cada interfaz.

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

Para dispositivos de bloque, lsblk muestra discos, particiones y puntos de montaje. Campos como RM (removible) o RO (solo lectura) te orientan sobre la naturaleza del dispositivo.

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

En combinación con udevadm info, obtendrás seriales y propiedades con las que construir reglas persistentes. Por ejemplo, anclar un disco USB concreto a un nombre de enlace simbólico en /dev basado en su número de serie.

Centralización y entornos mixtos (Windows incluido)

En empresas, conviene centralizar eventos USB para visibilidad y cumplimiento. Dos alternativas ágiles son herramientas de gestión de endpoints o una solución SIEM para correlación y alertado.

• Endpoint Management (Microsoft Endpoint Manager, ManageEngine, Ivanti): políticas, inventario y reportes de dispositivos USB conectados.
• SIEM (Splunk, Elastic Stack): ingesta de eventos, dashboards y alertas en tiempo real ante conexiones sospechosas.

Si necesitas algo a medida en Windows, puedes recoger la info de discos USB con PowerShell y enviarla por HTTP a un servidor que almacene los registros. Este ejemplo detecta unidades USB y publica en una API:

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

Con un servidor mínimo en Python Flask, guardas esos eventos de manera sencilla. Aquí un esqueleto funcional que recibe el JSON y lo vuelca a un fichero:

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

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

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

Para que el script de PowerShell corra al iniciar, usa el Programador de tareas con el disparador al inicio del sistema o sesión, y marca Ejecutar con los privilegios más altos; o crea un .bat en la carpeta de Inicio:

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

Visor de eventos de Windows para USB

Windows registra datos muy útiles bajo Microsoft > Windows > DriverFrameworks-UserMode > Operational en el Visor de eventos. Activa ese registro operativo y verás eventos 2003 (conexión) y 2102 (desconexión), incluyendo tipo de dispositivo (por ejemplo, almacenamiento), fabricante/modelo y número de serie.

Ten en cuenta que si alteras el esquema del pendrive (por ejemplo, lo conviertes a GPT o creas particiones), los identificadores pueden cambiar. Puedes corroborar la correspondencia con el Administrador de dispositivos (propiedad de rutas de instancia o relaciones de eliminación). Para agilizar la revisión, crea una vista personalizada filtrando por los IDs 2003 y 2102.

Casos prácticos, diferencias de hardware y checks útiles

En máquinas de escritorio con bus PCI puedes verificar hardware mediante lspci. Si quieres asegurarte de la GPU detectada por el sistema sin abrir la caja, bastará con:

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

En placas ARM como Raspberry Pi no encontrarás ese comando en muchos modelos, porque no hay bus PCIe expuesto de la misma forma. Es una diferencia de arquitectura: ahí carece de sentido listar PCI.

Si vas a probar parámetros del módulo del kernel (por ejemplo, bluetooth) y no puedes descargarlo con modprobe -r, revisa si está en uso por dependencias o servicios, o si la funcionalidad viene integrada en el kernel (no como módulo). Estas comprobaciones ayudan:

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

Para verificar la situación de vulnerabilidades como Meltdown en kernels recientes, el kernel expone un estado legible en /sys. Una lectura rápida te dirá si estás mitigado o vulnerable:

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

En routers Linux con un único dispositivo de bloque, cuando conectas un disco USB normalmente aparecerá como /dev/sda (y sus particiones /dev/sda1, etc.). Confirma con lsblk, y en caso de duda cruza información con lsusb y udevadm info para identificar el nuevo añadido.

Buenas prácticas para reglas y logging

Cuando diseñes tus reglas de udev, filtra de forma precisa para evitar falsos positivos. Combina SUBSYSTEM, ACTION y ENV{DEVTYPE} y, si es necesario, atributos como idVendor o idProduct para reaccionar solo ante el hardware relevante.

Mantén los scripts que lanza udev lo más ligeros posible. Si necesitas trabajo pesado (cifrado, copias, análisis), deriva a un servicio systemd con Type=simple/oneshot e invócalo desde el script, para no bloquear la cola de eventos.

En auditd, define reglas con etiquetas (-k) que te permitan buscar fácil con ausearch. Y configura rotación y acciones ante poco espacio (por ejemplo, rotate + num_logs o un exec a un script de limpieza) para no llevarte sorpresas.

Con journald, ajusta retención y límites de ráfaga en journald.conf para equilibrar persistencia y uso de disco. Si trabajas con SIEM, activa ForwardToSyslog o usa journalbeat/systemd input en Logstash/Fluentd según tu stack.

Por último, en entornos regulados, considera centralizar los eventos USB (Linux y Windows) en un repositorio único. Desde ahí podrás construir alertas y auditorías más completas, cumpliendo políticas de seguridad y simplificando investigaciones.

Con todo lo anterior dispones de un flujo sólido: udev detecta y ejecuta lo que haga falta en caliente, auditd registra con granularidad lo que hacen los usuarios y journald conserva y facilita la consulta. Remata integrando identificación con lsusb/lsblk y, si trabajas en entornos mixtos, añade la capa de centralización y los eventos del Visor de Windows para una cobertura total de punta a punta.