Auditamos nuestro propio servidor. Esto encontramos (y por qué te lo contamos)
Un equipo cuidadoso debería poder pasar su propia auditoría de seguridad sin sorpresas. La nuestra encontró tres hallazgos críticos. Aquí están — sin maquillaje — y la lección de por qué auditarse a uno mismo cada cierto tiempo no es paranoia, es disciplina.
Hace unas semanas, en ServerStack Solutions hicimos una auditoría de seguridad a nuestra propia infraestructura. La que sostiene este sitio, los servicios de nuestros clientes y nuestras herramientas internas. La que dirige el equipo que se dedica precisamente a configurar servidores seguros.
Encontramos tres cosas críticas que arreglar.
Te lo contamos no porque sea cómodo, sino porque es la mejor lección que podemos compartir: un equipo cuidadoso también acumula deuda de seguridad. La diferencia entre un servidor seguro y uno expuesto no es la pericia del equipo en un momento puntual — es la disciplina de revisar lo que ya estaba hecho.
Hallazgo 1: un puerto que no debía estar abierto
Uno de nuestros sitios tenía la aplicación corriendo en su contenedor (Docker), expuesta al puerto 3001 con escucha en 0.0.0.0. En lenguaje simple: cualquier persona en internet con la dirección IP del servidor podía acceder a la aplicación directamente, sin pasar por nuestro filtro de Cloudflare (sin certificado HTTPS, sin protección contra ataques, sin nada).
¿Cómo había llegado ahí? Por la naturaleza de Docker: cuando configuras un servicio sin especificar a qué interfaz tiene que escuchar, el default es "todas". Es práctico para desarrollo, peligroso en producción.
Fix: una línea en la configuración de Docker para que el puerto solo escuche al servidor mismo, no a internet. La aplicación sigue funcionando — todo el tráfico real pasa por Cloudflare como debe — pero ya no se puede tocar por el camino corto.
Lección: revisa qué puertos están expuestos al mundo, no solo los que tú abriste. A veces las herramientas exponen cosas por su cuenta.
Hallazgo 2: un archivo de credenciales legible por más procesos de los que debería
Encontramos un archivo .env —el que guarda las contraseñas de la base de datos, los secretos de la aplicación, llaves de servicios externos— con permisos de "todos pueden leer". En sistemas Linux esto se ve como 664, donde 4 significa "lectura para cualquier proceso del sistema".
En la práctica esto no es una catástrofe inmediata: el archivo solo lo puede leer alguien que ya esté dentro del servidor. Pero el día que un proceso se vea comprometido (un bug en una librería, una vulnerabilidad recién publicada), esa elevación de privilegios se vuelve trivial: el atacante encuentra las contraseñas servidas.
Fix: cambiar permisos a 600, que significa "solo el dueño del archivo puede leerlo". Cinco segundos de trabajo. Pero en una emergencia es la diferencia entre "se llevaron datos públicos" y "tienen acceso a todo".
Lección: los secretos en disco deben ser ilegibles por defecto. No "luego lo aprieto". Hoy.
Hallazgo 3: 7 semanas sin un backup nuevo
Aquí está el peor. Tres bases de datos de producción no se respaldaban automáticamente. Existía un script viejo, había existido alguna vez una intención, pero el sistema actual no estaba copiando nada desde hacía siete semanas.
Si en ese momento hubiera fallado el disco, hubiéramos perdido siete semanas de datos. Y nadie se había dado cuenta, porque nadie estaba revisando que el backup ocurriera.
Fix: un script de respaldo automático corriendo a las 2 de la mañana, escribiendo a S3 con retención de 30 días. Y, sobre todo, una alerta que avisa si un backup falla.
Lección: lo crítico es la alerta, no el script. Un script que falla en silencio es peor que no tener script, porque te da una falsa sensación de seguridad.
Por qué pasó esto en un equipo que se dedica a esto
Porque la infraestructura crece de a poco y los problemas se acumulan en silencio. Un día montas un servicio nuevo y le abres un puerto. Otro día renombras una variable de entorno. Otro día cambias el motor de base de datos y olvidas migrar el script de backup. Cada decisión por separado tiene sentido. El conjunto es lo que se desalinea.
El antídoto no es "ser más cuidadosos". Es auditar periódicamente, con una lista mecánica de qué revisar, sin asumir que "esto ya estaba bien".
La lista que usamos para auditar (y que tú también puedes usar)
Una auditoría no necesita ser un proyecto de tres meses. Estos siete puntos te dan el 80% del valor:
- Puertos abiertos al mundo: ¿cuáles son y por qué? ¿Hay alguno que ya no debería estar?
- Permisos de archivos sensibles:
.env, claves privadas, certificados. ¿Quién puede leerlos? - Backups: ¿corren? ¿se prueban? ¿hay alerta cuando fallan?
- Acceso administrativo: ¿quién puede entrar al servidor? ¿siguen ahí los ex-empleados?
- Versiones de software: ¿cuándo fue el último parche? ¿hay vulnerabilidades públicas sin aplicar?
- Logs de seguridad: ¿alguien los lee? ¿hay alertas automáticas?
- IPs baneadas y patrones de ataque: ¿qué intentaron contra ti la última semana?
Si no tienes respuesta clara para alguna, ahí está tu próximo trabajo.
La verdadera moraleja
La diferencia entre un servidor seguro y uno expuesto no es estática. Un servidor que era seguro hace seis meses puede haber acumulado tres pequeños descuidos que, juntos, lo vuelven vulnerable hoy. La seguridad no es un estado, es un hábito.
Por eso en cada servidor que administramos hacemos auditorías periódicas con esta misma lista. No porque desconfiemos del trabajo previo — porque confiamos en que el trabajo previo, sin revisión, se desactualiza.
En ServerStack Solutions
Si tienes un servidor en producción y quieres saber qué le falta sin pagar por una auditoría costosa, ofrecemos una primera revisión rápida sin compromiso. En 30 a 60 minutos identificamos los hallazgos críticos en tu infraestructura y te decimos qué tan urgente es cada uno.
Solicita la evaluación inicial. No te vamos a asustar para vender — te vamos a decir exactamente lo que encontremos, igual que aquí te contamos lo nuestro.
Relacionado: Caso real: servidor blindado sin puertos expuestos · Plan de recuperación cuando el servidor cae · IAM y menor privilegio.
Preguntas frecuentes
¿Cada cuánto debería auditarse un servidor?
Para PyMEs, una revisión completa cada 3 a 6 meses suele ser razonable. Una revisión rápida (los 7 puntos del post) puede hacerse cada mes. La regla práctica: cada vez que sumas un servicio nuevo o cambias algo importante, audita poco después.
¿Es necesario contratar a una empresa o puedo auditarme yo?
Puedes hacer la mayoría de las revisiones tú mismo si tienes conocimiento técnico — los 7 puntos del post son un buen comienzo. Lo que aporta una empresa externa es lo que tú no ves precisamente porque eres tú quien lo construyó. La autoauditoría descubre el 80%; el ojo externo encuentra el 20% que más cuesta detectar.
¿Por qué publican sus propios hallazgos? ¿No los hace ver mal?
Lo contrario. Cualquier empresa con infraestructura activa va a encontrar cosas para arreglar. Las que dicen "no encontramos nada" o no auditan, o no quieren contar. Mostrar lo que encontramos y cómo lo arreglamos es la mejor demostración de cómo trabajamos. Esa transparencia es exactamente lo que recomendamos a nuestros clientes que exijan a sus proveedores.