Servidores en la nube
Gestión de Firewall y Seguridad del Servidor en la Nube
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Gestión de Firewall y Seguridad de Cloud Server
Cada Cloud Server de KapsuleHost incluye un firewall administrado que deniega el tráfico entrante de forma predeterminada, además de protección contra ataques de fuerza bruta, un firewall de aplicación web y parches de seguridad automáticos, todo controlado desde una sola página en KPanel.
Los valores predeterminados se eligen para que un servidor nuevo sea seguro antes de que hayas tocado nada. Lo que añadas es normalmente solo los puertos que necesita tu propia aplicación. Esta guía recorre toda la página de Gestión del servidor, porque el firewall es una sección de ella y las otras secciones son lo que te evita necesitar el firewall en primer lugar.
Abrir la página de gestión
- Inicia sesión en KPanel.
- Haz clic en Cloud Servers en la barra lateral izquierda, luego haz clic en tu servidor.
- Haz clic en Management en los botones de acción en la parte superior de la página.
La dirección directa es /cloud-servers/<server-id>/management. La página se describe a sí misma como "Firewall, parches del sistema operativo, fail2ban y ModSecurity. Los cambios se aplican por SSH en segundos."
Si un banner dice "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately" [Aplicación en vivo no disponible. Los cambios se guardarán en la próxima ejecución de aprovisionamiento pero no tendrán efecto inmediato], el panel no puede alcanzar el servidor en este momento. Tus configuraciones siguen guardadas, solo que aún no se aplican. Comprueba que el servidor esté ejecutándose y sea accesible.
La política de firewall predeterminada
La sección Firewall (UFW) establece la política en una línea: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below." [Denegación predeterminada de entrada. SSH (22) siempre está abierto. Los puertos de stack de aplicación se abren automáticamente. Añade reglas personalizadas debajo].
En la práctica esto significa:
- Nada puede alcanzar tu servidor desde internet a menos que una regla lo permita.
- El puerto 22 siempre está abierto, por lo que un cambio de firewall nunca puede bloquearte el acceso a la máquina.
- Los puertos que necesita tu stack de aplicación, como 80 y 443 para una aplicación web, se abren para ti.
- El tráfico saliente del servidor no está restringido.
Sin reglas personalizadas, la sección muestra "No custom rules. Defaults: SSH + app-stack ports." [Sin reglas personalizadas. Valores predeterminados: SSH + puertos de stack de aplicación]. Este es un estado saludable, no una configuración faltante.
Añadir una regla personalizada
Añade una regla cuando ejecutas algo en un puerto que la política predeterminada no cubre: una aplicación Node en 3000, una base de datos a la que necesitas acceder directamente en 5432, un servidor de juegos o medios en un puerto UDP.
- Abre la sección Firewall (UFW).
- Escribe el número de Puerto en el primer campo. Los valores válidos son 1 a 65535.
- Elige TCP o UDP.
- Elige Allow [Permitir] o Deny [Denegar].
- Haz clic en Add [Añadir].
La regla aparece en la lista con un badge ALLOW [PERMITIR] o DENY [DENEGAR] y el puerto y protocolo, por ejemplo 3000/tcp. Se envía al servidor a través de la conexión de gestión en segundos.
Para eliminar una regla, haz clic en la X al final de su fila. Eliminar una regla Allow cierra ese puerto de inmediato.
Exponer un puerto de base de datos a toda internet es una de las formas más comunes en que un servidor se ve comprometido. Antes de permitir 3306, 5432, 6379 o 27017, pregúntate si lo que se conecta podría alcanzar la base de datos a través de la interfaz loopback del servidor o una red privada en su lugar. Si realmente debe ser accesible desde el exterior, asegúrate de que el servicio en sí requiera autenticación y cifrado fuertes.
Añade la regla primero, luego inicia el servicio. Un servicio que se inicia detrás de un puerto cerrado se ve roto exactamente de la misma manera que un servicio que no se inició, y puedes desperdiciar mucho tiempo depurando la capa equivocada.
App Stacks
La sección App stack le dice a la plataforma qué tipo de aplicación ejecuta este servidor, para que el preset de endurecimiento pueda ajustarse a él. La instalación de una aplicación a través del panel lo establece automáticamente.
Los stacks reconocidos son WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web [Web genérico] y No app stack [Sin stack de aplicación]. La sección se explica a sí misma como: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this." [El preset de endurecimiento se ajusta a tu aplicación. Instalar una aplicación desde el marketplace la configura automáticamente].
El stack afecta a qué puertos se abren automáticamente y cómo se ajustan las otras protecciones, más visiblemente en fail2ban.
fail2ban
fail2ban observa los intentos de autenticación y bloquea las direcciones que siguen fallando. Está activado de forma predeterminada y la página lo describe como: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too." [Bloquea direcciones IP que atacan por fuerza bruta SSH. Para sitios WordPress, también añade protección wp-login.php].
Déjalo activado. Es la protección individual más económica de la página, no cuesta nada en rendimiento, y convierte un ruido de fondo constante de intentos de adivinación de contraseñas en nada. En un stack WordPress o WooCommerce también protege el formulario de inicio de sesión, que es donde la mayoría de los ataques contra WordPress realmente aterrizan.
ModSecurity, el firewall de aplicación web
ModSecurity inspecciona las solicitudes HTTP según el conjunto de reglas principales OWASP e identifica las que parecen ataques. En un servidor KapsuleHost comienza en modo solo detección: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned." [Conjunto de reglas principales OWASP en modo solo detección de forma predeterminada. Registra tráfico sospechoso sin bloquear; cambia a modo activo en tu servidor una vez ajustado].
El modo solo detección es el punto de partida correcto. El conjunto de reglas principales es exhaustivo, y en una aplicación real algunas solicitudes legítimas coincidirán con una regla. Ejecútalo en modo solo detección durante un tiempo, lee los registros, averigua qué reglas activa tu propio tráfico, y solo entonces cambia a bloqueo dentro del servidor.
Activar el bloqueo sin ajuste previo puede romper tu propio sitio. Los envíos de formularios con texto enriquecido, cargas de archivos y clientes API con cargas útiles inusuales son las bajas habituales. Comprueba tus registros antes de cambiar.
Auto-parches del sistema operativo
Los parches de seguridad se aplican automáticamente. La sección explica la red de seguridad: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot." [Actualizaciones de seguridad aplicadas automáticamente. Protegidas por snapshots: se toma una snapshot del servidor antes de cada ejecución, con reversión automática si el servidor se vuelve inaccesible después de reiniciar].
Dos configuraciones se encuentran bajo el conmutador:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). [Permitir reinicio automático cuando una actualización de kernel lo necesite (solo durante horas silenciosas a continuación).] Los parches de kernel solo tienen efecto después de un reinicio. Si desactivas esto, los parches de kernel se instalan pero no se activan hasta que reinicies tú mismo.
- Quiet window (UTC) [Ventana silenciosa (UTC)], una hora de inicio y finalización. Los reinicios solo ocurren dentro de ella. Establécela en las horas más silenciosas para tu audiencia, y recuerda que el campo está en UTC, no en tu hora local.
Deja los auto-parches activados. La inmensa mayoría de los servidores comprometidos ejecutan software con un parche que se publicó semanas antes. Una snapshot anterior al parche con reversión automática significa que la objeción habitual, que una actualización podría romper algo, ya está manejada.
Historial de parches y ejecutar un parche ahora
La sección Patch history [Historial de parches] enumera cada ejecución con un estado de RUNNING [EN EJECUCIÓN], SUCCESS [ÉXITO], ROLLED_BACK [REVERTIDO], FAILED [FALLÓ] o SKIPPED [OMITIDO], el número de paquetes actualizados, si el servidor se reinició, y la hora en que se inició.
Para parchear inmediatamente en lugar de esperar al cronograma, haz clic en Run patch now [Ejecutar parche ahora]. La confirmación dice: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it." [Se crea una snapshot primero. El servidor se mantiene en línea excepto por un breve reinicio si una actualización de kernel lo necesita].
Una entrada ROLLED_BACK significa que la red de seguridad hizo su trabajo: el servidor no volvió en línea limpiamente después de un reinicio, por lo que se restauró la snapshot anterior al parche. Ver Cloud Server Snapshots para cómo funcionan esas snapshots.
Una línea de base sensata
Para la mayoría de los servidores, esta es toda la configuración de seguridad:
| Configuración | Recomendado |
|---|---|
| Firewall | Activado, reglas predeterminadas, más solo los puertos que tu aplicación necesita |
| fail2ban | Activado |
| ModSecurity | Activado, solo detección hasta que hayas leído los registros |
| Auto-parches del sistema operativo | Activado, con reinicios permitidos en una ventana silenciosa |
| Autenticación SSH | Claves, no contraseñas |
La última fila no está en esta página pero importa más que el resto junto. Ver Connecting to Your Cloud Server With SSH.
Solución de problemas
"Could not load management config." [No se pudo cargar la configuración de gestión]. El panel no pudo leer la configuración para este servidor. Recarga y comprueba que el servidor existe y está aprovisionado.
"Port must be 1-65535." [El puerto debe ser 1-65535]. El campo de puerto toma un número entero en ese rango. Los rangos y nombres de servicio no se aceptan aquí.
Mi regla se guardó pero nada cambió. Busca el banner "Live apply unavailable" [Aplicación en vivo no disponible]. Si se muestra, el cambio está almacenado pero aún no se ha enviado al servidor.
Puedo alcanzar mi servicio desde una red pero no desde otra. Eso es normalmente tu propio firewall saliente, no el del servidor. Prueba desde una conexión diferente antes de cambiar reglas aquí.
Una ejecución de parche muestra FAILED [FALLÓ]. Lee el mensaje de error en la fila. Un disco lleno es la causa más común. Libera espacio y haz clic en Run patch now [Ejecutar parche ahora].
El tráfico legítimo comenzó a ser bloqueado. Si cambiaste ModSecurity a modo bloqueo, devuélvelo a solo detección, lee los registros e identifica la regla antes de intentar de nuevo.
Si una regla de firewall se niega a aplicarse, o estás bloqueado de un servicio que has permitido, envía un correo electrónico a support@kapsulehost.com con el nombre del servidor, el puerto y lo que esperas alcanzar.