← Proyectos
Observabilidad · Mínimo privilegio

Alertas en el móvil
sin abrir un solo puerto

El punto ciego: nadie avisaba de nada. Ni de un despliegue, ni de una firma rechazada, ni de un fallo de respaldo. La solución obvia —un bot con acceso al sistema— habría añadido superficie y privilegios. La construida no abre puertos y no puede elevarse.

Arquitectura
4LABSSERVER recolector con privilegios · 1/min estado fichero temporal solo lectura bot sin privilegios saliente mensajería API de bots móvil entrante ningún puerto abierto

Ninguna flecha apunta hacia dentro. El recolector es la única pieza con permisos y no habla con el exterior; el bot habla con el exterior y no tiene permisos. Separar esas dos capacidades es lo que hace que un fallo en el bot no sirva de nada a quien lo encuentre.

Las decisiones, y su porqué
01
El servidor pregunta; nadie llama al servidor
ProblemaPara que un bot reciba órdenes, lo habitual es exponer un endpoint público al que el servicio de mensajería envía cada mensaje. Eso significa abrir una puerta nueva a Internet.
AlternativasUn webhook público, protegido con una ruta secreta y una cabecera de verificación. Funciona, pero vuelve a publicar superficie justo después de haberla reducido.
DecisiónLong polling: es el servidor quien mantiene una conexión saliente preguntando si hay mensajes. Cero puertos abiertos, cero endpoints nuevos, nada que sondear desde fuera. Es el mismo principio que rige el pipeline de despliegue — la conexión siempre parte de dentro.
02
Identidad verificada y solo lectura
ProblemaCualquiera que descubra el nombre del bot puede escribirle. Y un bot que responde revela que existe algo detrás.
AlternativasUna contraseña por mensaje, o confiar en que nadie adivine el nombre.
DecisiónEl bot ignora en silencio todo mensaje que no proceda de la cuenta autorizada: ni responde, ni confirma su existencia. El identificador lo aporta la plataforma, no el remitente, así que no es falsificable. Y ningún comando ejecuta acciones: solo consultan. Un móvil se pierde; una llave del servidor en el bolsillo, no.
03
Contra la fatiga de alertas
ProblemaEl servidor acumula más de dos mil bloqueos automáticos y recibe cientos de sondeos al día. Notificar cada intento produciría cientos de mensajes diarios.
AlternativasAvisar de todo lo que ocurre, que es la reacción instintiva al montar un sistema de alertas.
DecisiónDos niveles. Al instante, solo lo que exige una decisión: una firma rechazada, un rollback, un fallo de respaldo. El ruido de fondo —escaneos, bloqueos rutinarios— se agrega en un informe diario. Un sistema de alertas que se ignora es peor que no tenerlo, porque da una sensación falsa de control.
04
Eliminar el privilegio, no restringirlo
ProblemaEl informe necesita datos que requieren permisos de administración: bloqueos del cortafuegos, estado de la red privada. El bot los obtenía elevando privilegios puntualmente.
AlternativasEndurecer el servicio manteniendo esa elevación: aislar el sistema de ficheros, limitar llamadas al sistema, restringir capacidades. Mitiga, pero la vía de escalada sigue ahí.
DecisiónInvertir la responsabilidad. Un recolector con permisos reúne todo el estado en un fichero temporal cada minuto —bloqueos, red privada, contenedores, registros— y el bot se limita a leerlo y darle formato. Deja de necesitar acceso al sistema, así que se le puede prohibir por completo. No se protege mejor: se deja de necesitar protección.
05
El agujero que la puntuación no veía
ProblemaCon el servicio ya endurecido, la herramienta de análisis lo calificaba de aceptable. Pero seguía ejecutándose bajo el usuario administrativo, que pertenece al grupo con acceso al motor de contenedores.
AlternativasConfiar en la calificación automática, que no contempla la pertenencia a grupos. Ninguna de las restricciones aplicadas cerraba esa vía: no hay elevación de privilegios que bloquear, solo un socket al que ese grupo puede escribir.
DecisiónUn usuario de sistema propio, sin shell, sin directorio personal y sin grupos suplementarios. Un fallo en el bot ya no conduce a ninguna parte, y no porque esté bloqueado: porque ese usuario nunca tuvo el acceso. Las métricas automáticas orientan, pero no sustituyen a razonar sobre quién puede hacer qué.
06
El coste que sí se asume
ProblemaLos informes viajan por la infraestructura de un tercero: direcciones de conexión, nombres de servicios, estado del sistema. La API de bots no cifra extremo a extremo.
AlternativasUn canal propio, consultando por la red privada sin intermediarios. Más coherente, bastante menos cómodo.
DecisiónSe asume conscientemente, y se documenta. La comodidad de consultar el estado desde cualquier sitio compensa aquí, a diferencia del acceso administrativo, donde sí se descartó depender de terceros. Como contrapartida, la cuenta de mensajería pasa a formar parte del perímetro y se protege con doble factor.
El resultado

Avisos inmediatos de lo que importa, informe diario de lo que no, y consulta del estado completo desde cualquier sitio — sin un solo puerto abierto y sin que el proceso expuesto tenga acceso al sistema. La medición de exposición cayó de 8.0 a 1.3 sobre 10, pero la mejora que cuenta no aparece en esa cifra: el proceso que recibe entrada externa ya no puede alcanzar el motor de contenedores, y con él la vía a privilegios totales.

BashsystemdTelegram Bot APIjqfail2banWireGuard
Connect → Automate → Augment → Deploy.
El privilegio más seguro es el que no hace falta pedir.