Las dos primeras partes de esta serie cubrieron el ciclo de vida técnico de un paquete Debian: cómo mantenerlo al día sin sorpresas (parte I) y cómo moverlo de una versión mayor a la siguiente sin romper nada (parte II). Ese conocimiento es necesario, pero no es suficiente para explicar por qué hay servidores Debian corriendo veinte años sin una caída catastrófica mientras otros, administrados por gente igual de capaz técnicamente, terminan reconstruidos desde cero cada cuatro o cinco.

La diferencia no está, casi nunca, en un comando que unos conocen y otros no. Está en tres capas de disciplina que rara vez se enseñan juntas porque no son “comandos de Debian” en sentido estricto: saber qué está pasando en el sistema en todo momento (observabilidad), reducir de antemano lo que puede salir mal (hardening), y dejar un registro de por qué las cosas están como están (documentación operativa). Vamos por las tres.

Observabilidad: la diferencia entre “no hay errores” y “sé lo que está pasando”

Ya mencioné en las partes anteriores dos comandos puntuales —needrestart después de un upgrade, journalctl -p 3 -xb y debsums -c después de un salto de versión— como verificaciones de un momento específico. La observabilidad real es la versión continua de esa misma actitud: no esperar a que algo falle para mirar, sino tener visibilidad constante y de bajo esfuerzo del estado del sistema.

journalctl como hábito diario, no como herramienta de emergencia. La mayoría de los sysadmins solo abren journalctl cuando algo ya se rompió. La disciplina distinta es tratarlo como lectura de rutina: un journalctl --since today -p warning de treinta segundos por la mañana detecta patrones —un servicio que reintenta conexiones intermitentemente, un disco que empieza a reportar warnings de I/O— semanas antes de que se conviertan en una caída real.

Monitoreo de recursos con memoria histórica, no solo instantánea. Herramientas como vnstat (tráfico de red), sysstat/sar (CPU, memoria, I/O históricos) cuestan minutos de instalación y dan algo que top o htop nunca te van a dar: la capacidad de responder “¿esto es normal para este servidor o es nuevo desde el martes?” con datos, no con memoria humana. Un sysadmin sin históricos está, en la práctica, adivinando cada vez que algo se ve “raro”.

Logs de aplicación centralizados, aunque sea de forma modesta. No hace falta un stack de observabilidad enterprise para tener valor real. Algo tan simple como journald configurado con retención suficiente (SystemMaxUse= en /etc/systemd/journald.conf) más logrotate bien configurado para los logs de aplicación que viven fuera de journald (Nginx, aplicaciones propias) ya te da la capacidad de reconstruir qué pasó, cuándo, sin depender de que alguien se haya acordado de guardar una captura de pantalla del error.

El punto de fondo es este: la observabilidad no es un lujo de infraestructuras grandes. Es lo que te permite distinguir, con evidencia, entre “el servidor está bien” y “el servidor todavía no mostró que está mal” — que son dos cosas completamente distintas y que un sysadmin sin hábitos de observación confunde sistemáticamente.

Hardening: reducir de antemano lo que puede salir mal

Hardening en Debian no es una lista mágica de comandos exóticos. Es, en su mayor parte, sentido común aplicado con constancia — pero es justamente la constancia lo que falla en la práctica.

Superficie de ataque: instalá lo que usás, nada más. apt install --no-install-recommends como hábito reduce silenciosamente la cantidad de software (y por lo tanto de vulnerabilidades potenciales futuras) que termina en un servidor sin haber sido pedido explícitamente. Revisar periódicamente dpkg -l contra lo que efectivamente se usa, y desinstalar lo que no, es mantenimiento de superficie de ataque tan válido como cualquier firewall.

SSH como primera línea, tratado con el rigor que merece. Deshabilitar login de root por contraseña (PermitRootLogin prohibit-password o directamente no), autenticación por clave pública exclusivamente, y fail2ban configurado contra intentos de fuerza bruta no son medidas “avanzadas” — son la línea de base mínima esperable en cualquier servidor expuesto a Internet, y sorprende cuántas instalaciones reales todavía no las tienen.

unattended-upgrades para seguridad, revisado en la primera parte de esta serie, es en sí mismo la medida de hardening con mejor relación esfuerzo-beneficio que existe. La mayoría de los compromisos de servidores reales no explotan vulnerabilidades de día cero: explotan CVEs conocidas y parcheadas hace meses, en sistemas que nadie actualizó. Automatizar los parches de seguridad cierra esa ventana sin necesitar heroísmo diario.

AppArmor, ya integrado en Debian, subutilizado en la práctica. Debian viene con AppArmor habilitado por defecto para varios paquetes (nginx, mariadb, entre otros perfiles disponibles), pero muchos sysadmins ni siquiera saben que está corriendo, y menos aún lo extienden a sus propios servicios. aa-status te muestra qué perfiles están activos ahora mismo; escribir un perfil de confinamiento para una aplicación propia crítica es una tarde de trabajo que reduce de forma concreta el daño posible si esa aplicación específica es comprometida.

Documentación operativa: la parte que decide si el conocimiento sobrevive a la persona

Esta es, de las tres capas, la que menos se trata como parte del trabajo técnico y la que más determina si una infraestructura sobrevive un cambio de personal, una ausencia prolongada, o simplemente el olvido natural de por qué se tomó una decisión hace tres años.

En la primera parte mencioné el caso concreto de apt-mark hold: retener un paquete sin dejar registro del motivo es una bomba de tiempo organizacional tan real como el software sin actualizar. Ese mismo principio se aplica en escala mayor a cada decisión de infraestructura no obvia: por qué este servidor corre backports para un paquete puntual, por qué existe una excepción de firewall específica, por qué la configuración de Postfix tiene una directiva que no está en ningún tutorial estándar.

La forma más simple y más efectiva de sostener esto no es un wiki elaborado — es un archivo de texto plano versionado junto a la configuración (un NOTAS.md o DECISIONES.md en el mismo repositorio git que ya usás para tu configuración de Ansible o tus dotfiles de servidor), con entradas breves: fecha, qué se cambió, por qué, y quién lo decidió. La disciplina no es la herramienta —cualquier herramienta de texto sirve— es el hábito de escribir la entrada en el momento de tomar la decisión, no un mes después cuando ya no se recuerda el contexto completo.

El hilo que conecta las tres partes

Si hay una idea que atraviesa toda esta serie, es esta: administrar Debian bien no es saber ejecutar los comandos correctos en el momento correcto —aunque eso también hace falta, y las partes I y II de esta serie están dedicadas específicamente a eso—. Es sostener, día tras día, una cantidad de higiene que individualmente parece menor: revisar antes de confirmar, verificar después de ejecutar, retener con criterio y con registro, observar aunque nada esté fallando todavía, reducir la superficie de lo que puede salir mal, y dejar por escrito el porqué de cada decisión no obvia.

Ninguna de estas prácticas es, por separado, espectacular. Es exactamente su acumulación sostenida en el tiempo la que explica la diferencia entre un servidor Debian que llega a su vigésimo aniversario de servicio absorbiendo release tras release sin drama, y uno que —administrado por gente igual de inteligente, con las mismas herramientas disponibles— termina reconstruido desde cero cada pocos años, cada vez bajo la misma presión evitable.