Lo que no debe hacer
Módulo 10: Mantener la seguridad · Tiempo de lectura: 12 minutos
Objetivo de aprendizaje: Tras esta lección, usted reconocerá los errores que con más frecuencia llevan a un servidor hackeado o averiado, podrá explicar por qué son peligrosos y sabrá qué hacer en su lugar.
Conceptos clave: inicio de sesión de root con contraseña, contraseña débil o predeterminada, base de datos abierta, API de Docker en el puerto 2375, docker.sock en un contenedor, chmod 777, curl | bash, secretos en Git, panel de administración sin verificación en dos pasos, firewall desactivado "un momento", sin actualizaciones, sin copia de seguridad
¿Por qué una lección sobre errores?
La mayoría de los servidores no los hackea un atacante genial con una vulnerabilidad desconocida. Los hackean bots que recorren todo internet en busca de errores conocidos: una contraseña que se puede adivinar, una base de datos abierta, un programa al que le falta una actualización desde hace meses. Quien evita los errores de esta lección deja de interesar a esos bots. Esa es la mayor parte de la protección que puede conseguir.
Para cada error se explica por qué es peligroso y qué debe hacer en su lugar. Casi todo lo ha aprendido en lecciones anteriores; esta lección lo reúne de forma ordenada.
1. Inicio de sesión de root con contraseña
El problema. Todo servidor recibe intentos de inicio de sesión en root durante todo el día (lección 5.3). Si root puede iniciar sesión con contraseña, esa contraseña es lo único que separa a un bot del control total. Las contraseñas reutilizadas o demasiado cortas acaban adivinándose tarde o temprano, o ya figuran en una lista filtrada.
Haga esto. Inicie sesión solo con claves: PasswordAuthentication no y KbdInteractiveAuthentication no, root como mucho con una clave (PermitRootLogin prohibit-password) o directamente no (no), y trabaje a diario como usuario normal con sudo (lecciones 2.2 y 3.2). Compruebe desde fuera qué métodos de inicio de sesión ofrece su servidor (ejercicio Z2.2).
2. Una base de datos, caché o clúster de búsqueda abierto a internet
El problema. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch u OpenSearch (9200) y MongoDB (27017) están pensados para programas de confianza en una red de confianza. Si escuchan en 0.0.0.0 sin firewall, los escáneres los encuentran enseguida. Redis indica en su propia documentación que no debe exponerse a internet y que cualquiera con acceso puede borrar todo el conjunto de datos; mediante el comando CONFIG un atacante puede incluso escribir archivos en el servidor. Las bases de datos y los clústeres de búsqueda abiertos son desde hace años una causa conocida de grandes filtraciones de datos y de mensajes de "rescate" en lugar de sus datos.
Haga esto. Haga que estos servicios escuchen en 127.0.0.1 (lección 5.1), manténgalos detrás del firewall (lección 5.2) y, en Docker, no los publique o publíquelos solo en 127.0.0.1 (lección 9.3). Para acceder usted mismo desde su portátil: un túnel SSH (lección 2.3). Compruébelo desde fuera (ejercicio Z5.1).
3. La API de Docker abierta o docker.sock en un contenedor
El problema. Quien puede controlar el daemon de Docker es, en la práctica, root en el servidor: la documentación de Docker indica que solo los usuarios de confianza deben poder controlar el daemon y equipara el acceso al daemon con el acceso de root. Hay dos variantes de este error:
- El daemon escucha en un puerto TCP sin TLS (lo habitual es el 2375). Cualquiera que llegue a ese puerto puede iniciar contenedores con el disco de su servidor dentro.
- Un contenedor recibe
/var/run/docker.sockcomo volumen ("así puede gestionar contenedores por sí mismo"). Si ese contenedor es hackeado, se pierde todo el servidor.
El grupo docker también equivale a root (lección 9.2): incluya en él solo a administradores.
Haga esto. Deje que Docker funcione solo a través del socket local. La administración remota se hace por SSH (docker context con ssh://) o, si realmente tiene que ser por TCP, con TLS en el puerto 2376 y certificados de cliente. Monte docker.sock solo en un contenedor en el que confíe plenamente y que de verdad lo necesite, y preferiblemente solo en modo lectura a través de un proxy restrictivo.
4. chmod 777 para quitarse de encima un mensaje de error
El problema. Aparece "Permission denied" al subir un archivo, y un foro le dice: chmod -R 777 /var/www. A partir de ese momento, cualquier usuario y cualquier proceso del servidor puede escribir lo que quiera en su sitio web, también un plugin hackeado u otra cuenta. El código en el que puede escribir el servidor web puede sustituirse, a través de una vulnerabilidad, por una puerta trasera.
Haga esto. Averigüe quién necesita escribir y dónde (lección 3.1): normalmente solo el usuario del servidor web, en una única carpeta para subidas o caché. El código, con un propietario distinto del servidor web y permisos 644/755; las subidas, 750/640 o similar.
5. curl ... | bash y software de cualquier procedencia
El problema. Un script que usted ejecuta como root sin mirarlo puede hacer cualquier cosa: añadir repositorios y claves, sobrescribir archivos, abrir un servicio. Aunque la intención sea buena, después no sabe qué ha cambiado, y en la siguiente actualización de versión de la distribución algo se rompe (lección 4.3).
Haga esto. Descargue el script y léalo. Instale preferiblemente desde el repositorio de su distribución o desde la fuente oficial del fabricante, con su propia clave (Signed-By, lección 4.1). Anote qué instala y por qué.
6. Sin actualizaciones, o actualizaciones "más tarde"
El problema. Las vulnerabilidades se corrigen y después se explotan, a menudo en cuestión de días. Un servidor que pasa meses sin actualizaciones, o que funciona con una versión sin soporte, tiene una lista de puertas abiertas conocidas. apt no actualiza los contenedores.
Haga esto. Active las actualizaciones de seguridad automáticas (lección 4.2), fije un momento para los reinicios, anote en su agenda la fecha de fin de soporte de su versión (lección 4.3) y actualice los contenedores con regularidad (lección 9.4).
7. Sin copia de seguridad, o una copia que nunca se ha probado
El problema. Una instantánea en el mismo almacenamiento no es una copia de seguridad (lección 8.1). Una copia de seguridad guardada en el propio servidor desaparece con él en caso de hackeo o ransomware. Y una copia de seguridad que nunca se ha restaurado es una esperanza, no una certeza.
Haga esto. Copias de seguridad cifradas fuera del servidor (restic, lección 8.2), supervisión de que se ejecutan y, como mínimo cada trimestre, una prueba de restauración.
8. Paneles de administración abiertos a todo el mundo, sin verificación en dos pasos
El problema. Un panel de administración de una base de datos (como phpMyAdmin), de Docker (como Portainer), de su aplicación o de su gestor de contraseñas es un objetivo atractivo: una sola contraseña da acceso a todo. Las contraseñas predeterminadas como admin/admin y un registro que se queda abierto (Vaultwarden, lección 9.4) lo ponen aún más fácil.
Haga esto. No abra los paneles de administración a internet: acceda a ellos mediante un túnel SSH o solo desde una dirección fija. Si un panel tiene que ser público de todos modos: https, una contraseña fuerte y única de su gestor de contraseñas, verificación en dos pasos y el registro cerrado. Cambie siempre las contraseñas predeterminadas.
9. Secretos en Git o en su archivo compose
El problema. Una contraseña, clave de API o clave privada en un archivo que acaba en un repositorio Git permanece en el historial para siempre, aunque la elimine más tarde. Los bots rastrean los repositorios públicos en busca precisamente de este tipo de claves.
Haga esto. Guarde los secretos en un archivo aparte con permisos 600 (EnvironmentFile, lección 6.3; .env en Docker Compose, lección 9.3), incluido en .gitignore. Si aun así se ha filtrado un secreto: sustitúyalo de inmediato (una contraseña nueva, una clave nueva); limpiarlo en Git no basta.
10. Desactivar el firewall "un momento", todo como root y sin notas
El problema. "Desactivo el firewall un momento para probar" acaba olvidándose. "Lo hago un momento como root" se convierte en costumbre. Y un servidor del que nadie sabe qué ejecuta ni por qué no se puede administrar ni recuperar.
Haga esto. Pruebe con una regla temporal y estrecha (un puerto, una dirección de origen) y elimínela después. Trabaje como usuario normal con sudo. Mantenga un breve expediente del servidor: qué se ejecuta, qué puertos están abiertos, dónde están las copias de seguridad, cuándo termina el soporte de la versión (lección 10.4).
En la práctica
Todos estos errores pueden cometerse en cualquier VPS, tanto en WebOké como en otros proveedores: lo que ocurre dentro de su servidor lo administra usted. El proveedor sí puede desconectar un servidor de la red si envía spam o lanza ataques, porque eso afecta a otros clientes. Prevenir es, por tanto, importante también para su propia disponibilidad.
Resumen
- La mayoría de los hackeos aprovechan errores conocidos, no vulnerabilidades desconocidas.
- Inicio de sesión con claves y sin contraseña; bases de datos, cachés y la API de Docker nunca abiertas a internet; nada de
docker.socken contenedores en los que no confíe plenamente. - Nada de
chmod 777ni decurl | bash: sepa quién puede hacer qué y qué está instalando. - Actualizaciones automáticas, copias de seguridad fuera del servidor y probadas, paneles de administración detrás de un túnel o con verificación en dos pasos.
- Secretos fuera de Git y fuera de los archivos compose; lo que se ha filtrado se sustituye.
Cuestionario
Ejercicio
Ejercicio Z10.2: ¿Qué error es? El archivo de ejemplo casussen-z10-2.md contiene ocho casos breves de servidores con algún problema. Para cada caso, elija de qué error se trata según la lista de esta lección (de la A a la J) y cuál es el mejor primer paso. El programa compara sus respuestas con la clave fija y después muestra la explicación de cada caso.
Para saber más
- Proteger su VPS: los primeros cinco minutos
- Gestor de contraseñas y claves de acceso (passkeys): así organiza sus inicios de sesión de forma segura
- Documentación de Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
- Documentación de Docker, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
- Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/