Hardening de Raspberry Pi industrial: reducir riesgo sin prometer de más

Una Raspberry Pi puede ejecutar adquisición, pasarelas o análisis de borde, pero instalar Linux en un armario no convierte el conjunto en un controlador industrial. El hardening reduce superficie de ataque y limita consecuencias; no corrige una fuente inadecuada, una envolvente mal dimensionada ni un diseño de red inseguro. Esta guía se concentra en el sistema operativo y exige probar cada cambio en un equipo de laboratorio representativo antes de desplegarlo.

1. Definir el modelo de amenazas

Anote activos, entradas y consecuencias antes de copiar comandos. Considere credenciales robadas, servicio vulnerable, equipo perdido, dispositivo de la misma VLAN comprometido, modificación no autorizada y corrupción tras pérdida de alimentación. Identifique además qué flujos necesita realmente la aplicación, quién administra el nodo y cuánto estado se puede perder.

El objetivo puede ser: solo una estación de salto abre SSH; la aplicación publica telemetría hacia destinos conocidos; ningún servicio de campo acepta tráfico desde la red corporativa; y una imagen conocida permite recuperar el nodo. Si un puerto, usuario o paquete no respalda ese objetivo, elimínelo. Revise el modelo cuando cambien conexiones, software o responsables.

2. Mantener una cadencia compatible con Raspberry Pi OS

Raspberry Pi recomienda apt update seguido de apt full-upgrade para mantener Raspberry Pi OS y desaconseja usar rpi-update como mantenimiento normal porque instala firmware de prepublicación. Debian también recomienda actualizaciones regulares por sus correcciones de seguridad. No traduzca esto en actualizaciones ciegas: defina una ventana, conserve la imagen anterior y ensaye primero con la misma rama de sistema operativo.

sudo apt update
apt list --upgradable
sudo apt full-upgrade
sudo reboot

Una cadencia mensual puede ser un punto de partida, con evaluación extraordinaria cuando se publique una vulnerabilidad aplicable. Registre fecha, paquetes, reinicio y comprobaciones. Antes de actualizar, confirme que la versión de Raspberry Pi OS sigue soportada; una versión sin soporte requiere migración planificada, no acumulación indefinida de excepciones.

3. Usar claves SSH y privilegio mínimo

Cree una cuenta nominal por administrador, instale su clave pública y pruebe una segunda sesión antes de cerrar la primera. Después deshabilite autenticación por contraseña y acceso directo de root en un archivo de /etc/ssh/sshd_config.d/. Valide antes de recargar:

PasswordAuthentication no
PermitRootLogin no
AllowUsers operador

sudo sshd -t && sudo systemctl reload ssh

La cuenta de la aplicación no necesita shell interactiva ni pertenecer a sudo. Conceda solo grupos de dispositivo imprescindibles y comandos administrativos específicos mediante sudoers, comprobado con visudo. Proteja las claves privadas fuera del nodo y tenga un procedimiento presencial para una configuración SSH defectuosa.

4. Filtrar y segmentar la red

La segmentación en el conmutador o firewall limita qué equipos pueden llegar al nodo; el firewall local contiene errores y movimientos laterales dentro del segmento. No son sustitutos. Documente una matriz de origen, destino, protocolo y puerto, y aplique denegación por defecto después de permitir conexiones establecidas, loopback, administración desde la estación de salto y flujos de aplicación explícitos.

Con nftables, cargue un archivo versionado mediante nft -c -f para comprobar sintaxis y nft -f para aplicarlo. Mantenga acceso de consola durante la prueba y confirme el resultado con nft list ruleset. No pegue una regla genérica: direcciones, IPv6, DHCP, DNS, NTP y protocolos industriales dependen del sitio.

5. Encerrar cada servicio con systemd

Ejecute la aplicación como usuario dedicado y deje que systemd gestione inicio y reinicio. Endurezca incrementalmente: NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict, ProtectHome=yes y ReadWritePaths= para directorios que deban cambiar. systemd-analyze security nombre.service ayuda a detectar exposición, pero su puntuación no demuestra que la aplicación funcione ni que la política sea suficiente.

Pruebe dispositivos, DNS, hora, credenciales TLS, archivos y reinicio después de cada restricción. Restart=on-failure puede recuperar un proceso terminado; no arregla datos inválidos ni una dependencia caída. Limite además los ciclos con StartLimitIntervalSec= y StartLimitBurst= para evitar bucles agresivos.

6. Tratar secretos como material revocable

No incluya contraseñas, claves privadas o tokens en la imagen, repositorio, unidad de systemd ni línea de comandos. Provisiónelos por dispositivo, limite permisos al usuario del servicio y separe identidad de desarrollo y operación. Un archivo EnvironmentFile= evita exponer valores en la unidad, pero no cifra el contenido: use el mecanismo de secretos disponible en su infraestructura, documente propietario, caducidad y rotación, y pruebe la revocación de un nodo perdido.

7. Elegir conscientemente entre escritura y OverlayFS

Raspberry Pi OS permite activar OverlayFS con:

sudo raspi-config nonint enable_overlayfs

La raíz queda protegida por una capa superior temporal: reduce escrituras persistentes y descarta cambios al reiniciar. Ese beneficio tiene coste. Actualizaciones, claves rotadas, configuración y registros locales también pueden desaparecer; el uso de RAM crece; y el procedimiento de mantenimiento debe desactivar o administrar la superposición. Clasifique cada ruta como inmutable, temporal o persistente. OverlayFS no reemplaza almacenamiento adecuado, apagado controlado, copia ni prueba de restauración.

8. Conservar señales útiles, no ruido infinito

Defina límites para journald y verifique uso con journalctl --disk-usage. Si la raíz es temporal, exporte eventos necesarios a un colector autenticado o reserve almacenamiento persistente con cuotas. Evite registrar secretos y sincronice la hora desde una fuente autorizada. Una alarma útil identifica nodo, servicio, versión y condición; una tormenta de mensajes puede llenar disco o esconder el primer fallo.

9. Configurar watchdog con una condición de salud real

El watchdog de hardware reinicia cuando deja de recibir pulsos; RuntimeWatchdogSec= permite que el gestor de sistema lo alimente. Para una aplicación compatible, WatchdogSec= exige notificaciones periódicas. Ninguno confirma por sí solo que la telemetría sea correcta. Pruebe proceso bloqueado, carga alta y dependencia inaccesible, y evite reinicios repetidos que borren evidencia o agraven una salida física insegura.

10. Preparar copia, reversión y simulacro

Guarde fuera del dispositivo configuración versionada, inventario, sumas de la imagen, datos persistentes y material de reprovisión; los secretos requieren copia protegida o emisión nueva. Antes de cambiar paquetes o políticas, capture el estado necesario y defina el criterio de reversión. Una copia no cuenta hasta restaurarla.

Ejecute periódicamente un simulacro: retire el medio en laboratorio, instale la imagen conocida, aplique configuración y credenciales nuevas, restaure datos, conecte a la red de prueba y valide puertos, servicios, registros, watchdog y flujo de aplicación. Mida el tiempo y corrija pasos manuales ambiguos. El resultado honesto es evidencia de recuperación bajo ese escenario, no una garantía sobre todos los fallos.

Validación mínima antes del despliegue

sudo sshd -t
sudo nft -c -f /etc/nftables.conf
sudo nft list ruleset
systemctl --failed
systemd-analyze security nombre.service
journalctl -u nombre.service --since today

Revise también usuarios y grupos, puertos escuchando, paquetes pendientes, persistencia tras reinicio y restauración desde la copia. Registre quién aprobó el resultado y repita las pruebas después de cualquier cambio relevante.

Fuentes primarias

Consultadas el 2026-07-24:

Hardening de Raspberry Pi industrial: una guía honesta