Seguridad básica de un servidor: por dónde empezar

Quién llama a tu puerta (y por qué no es personal)

Enciende un servidor con una IP pública y, antes de que te dé tiempo a terminar de configurarlo, su registro de accesos ya mostrará decenas de intentos de entrada desde direcciones repartidas por medio mundo. No es un ataque dirigido contra ti: son robots que escanean rangos enteros de internet a todas horas, probando usuarios y contraseñas comunes, buscando servicios sin actualizar y puertas que alguien dejó abiertas por descuido.

Eso cambia cómo conviene plantear el problema. Nadie es demasiado pequeño para que lo escaneen —a escala de internet, «pequeño» no significa nada—, así que la meta no es esconderse, sino no ser la presa fácil. La mayoría de esos robots busca objetivo cómodo: en cuanto una máquina les da algo de trabajo, saltan a la siguiente dirección. Casi toda la seguridad básica se reduce a eso.

Capas, de fuera hacia dentro

La idea que sostiene todo lo demás es sencilla: no confíes en una sola barrera. Cada capa da por hecho que la anterior puede fallar y limita el daño si lo hace. A esto se le llama defensa en profundidad, y se entiende mejor mirándolo de fuera hacia dentro.

El orden importa. El cortafuegos filtra antes de que el tráfico toque nada; el acceso protege lo que el cortafuegos deja pasar; y solo cuando has recortado todo lo que no hace falta queda un servicio, uno, de cara al mundo. Debajo, como red por si algo se cuela, están las copias y la vigilancia. Ninguna capa es infalible por sí sola; apiladas, convierten un fallo en un susto en lugar de en un desastre.

El acceso: la puerta que más se aporrea

El acceso remoto por SSH es lo primero que sondean los robots, así que es lo primero que conviene blindar. Tres decisiones cubren casi todo:

• Entra con llave, no con contraseña. Una llave SSH es un par de archivos criptográficos: uno se queda en tu ordenador y otro en el servidor. Adivinar una contraseña de ocho caracteres es cuestión de tiempo para una máquina; adivinar una llave de este tipo, en la práctica, queda fuera de su alcance. Una vez configurada, puedes desactivar por completo la entrada por contraseña y la fuerza bruta contra el login deja de tener sentido.
• No entres como root. La cuenta de administrador total es la que todos los atacantes prueban por nombre. Desactiva su acceso directo y trabaja con un usuario normal que eleve privilegios solo cuando hace falta; así, aunque alguien logre entrar, no aterriza con las llaves de todo el reino.
• Deja solo los usuarios necesarios. Cada cuenta activa es una puerta más. Cuentas viejas de gente que ya no está, o creadas «para probar» y olvidadas, son un clásico de cualquier auditoría.

Con esto, el rumor de intentos de login no desaparece —seguirán llamando—, pero se queda en rumor inofensivo.

Abre lo justo: el firewall

Un servidor no debería tener abierto al mundo nada que el mundo no necesite. El principio es cerrar todo por defecto y abrir solo los puertos imprescindibles: normalmente el de la web y el del acceso remoto, poco más. Cada puerto abierto es una superficie que alguien puede sondear, así que la lista corta gana siempre.

El fallo típico no es olvidar el firewall, sino exponer sin querer un servicio interno. La base de datos es el ejemplo de manual: no tiene ninguna razón para escuchar en la dirección pública cuando solo la aplicación que corre en la misma máquina la usa. Atándola a la interfaz local (127.0.0.1) desaparece de fuera aunque el firewall tuviera un hueco. Herramientas de administración, paneles internos y puertos de depuración caen en el mismo saco: útiles de puertas adentro, un regalo si asoman a internet.

Ponte al día antes que ellos

Buena parte de los ataques no usa nada sofisticado: aprovecha fallos ya descubiertos y ya corregidos, contra máquinas que nunca aplicaron el parche. Cuando se publica un fallo de seguridad se publica también la receta para explotarlo, y los escáneres automáticos la incorporan en cuestión de días. La ventana entre «hay parche» y «le están dando caña a gran escala» es corta.

Mantenerse al día no es ponerlo todo en automático y mirar para otro lado. Merece la pena separar las actualizaciones de seguridad —esas conviene aplicarlas rápido y se pueden automatizar con cabeza— de los cambios de versión grandes, que piden probarse antes. Y un detalle que se olvida: algunas actualizaciones, las del núcleo del sistema sobre todo, solo surten efecto tras reiniciar. Un servidor parcheado que lleva meses sin reiniciarse puede estar arrastrando un agujero que cree tener tapado.

Frenar la fuerza bruta

Aunque hayas cerrado la entrada por contraseña, el resto de servicios sigue recibiendo intentos: paneles, correo, formularios. Aquí ayuda un guardián sencillo y muy rentable: un vigilante que lee los registros, cuenta los fallos y bloquea la IP que insiste. Diez contraseñas erróneas en un minuto desde la misma dirección no son un usuario despistado; son una máquina probando suerte, y se le cierra la puerta durante un rato.

Es de las medidas con mejor relación esfuerzo-resultado: se configura una vez y corta en seco los ataques por diccionario, que son la mayoría. El único cuidado real es no autobloquearte —conviene dejar tu propia dirección en una lista de excepciones— y ajustar el umbral para que un error de dedo genuino no acabe en veto.

Lo único que queda de cara al mundo: el servicio

Después de recortarlo todo, queda una cosa expuesta a propósito: la aplicación que da la cara. Por eso merece un cuidado aparte.

• Que no corra como root. Si un servicio con todos los privilegios tiene un fallo, quien lo explote hereda todos esos privilegios. Ejecutándolo con un usuario limitado, el mismo fallo se queda contenido en su rincón.
• Cifra el tráfico. TLS —el candado de https— evita que credenciales y datos viajen en claro por redes que no controlas. Hoy es gratis y automático; no ponerlo no tiene excusa.
• Los secretos, fuera del código. Contraseñas, claves de API y tokens no van en el repositorio ni en un archivo que se pueda servir por error. Un secreto que se cuela en el historial de un repositorio hay que darlo por quemado y rotarlo.
• Cuida las dependencias. El código que escribes tú es una fracción de lo que corre; el resto son librerías de terceros. Mantenerlas al día importa tanto como parchear el sistema.

Cuando algo salga mal igual: copias y vigilancia

La seguridad perfecta no existe, y actuar como si existiera es el error más caro de la lista. Las dos redes que te salvan cuando algo se cuela son las copias de seguridad y la vigilancia, y las dos tienen truco.

Una copia solo cuenta si cumple tres condiciones: vive fuera de la máquina (una copia en el mismo servidor, que se cifra o se borra con él, no sirve de nada), está automatizada para no depender de que alguien se acuerde y —la que casi todos se saltan— se ha probado a restaurar al menos una vez. Conviene un simulacro de recuperación cada cierto tiempo.

La vigilancia es la otra mitad, y no necesita un centro de operaciones: basta con recibir un aviso cuando algo se sale de lo normal —el disco casi lleno, un servicio caído, un pico de accesos raro, un proceso que no debería estar ahí—. Enterarte a los diez minutos en vez de a los diez días es la diferencia entre un contratiempo y salir en las noticias.