Apertura de la página de gestión
- Inicie sesión en KPanel.
- Haga clic en Servidores Cloud en la barra lateral izquierda y, a continuación, haga clic en su servidor.
- Haga clic en Gestión 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 "Cortafuegos, parches del SO, fail2ban y ModSecurity. Los cambios se aplican por SSH en cuestión de segundos."
Si un banner indica "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", el panel no puede alcanzar el servidor en este momento. Su configuración sigue guardada, solo que aún no se ha aplicado. Compruebe que el servidor se está ejecutando y es accesible.
La política de cortafuegos predeterminada
La sección Cortafuegos (UFW) expresa la política en una línea: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
En la práctica, esto significa:
- Nada puede alcanzar su servidor desde Internet a menos que una regla lo permita.
- El puerto 22 siempre está abierto, por lo que un cambio de cortafuegos nunca puede dejarle sin acceso a la máquina.
- Los puertos que necesita su pila de aplicaciones, como 80 y 443 para una aplicación web, se abren automáticamente.
- El tráfico saliente del servidor no está restringido.
Sin reglas personalizadas, la sección muestra "No custom rules. Defaults: SSH + app-stack ports." Este es un estado saludable, no una configuración faltante.
Adición de una regla personalizada
Agregue una regla cuando ejecute algo en un puerto que la política predeterminada no cubre: una aplicación Node en 3000, una base de datos a la que debe acceder directamente en 5432, un servidor de juegos o multimedia en un puerto UDP.
- Abra la sección Cortafuegos (UFW).
- Escriba el número de Puerto en el primer campo. Los valores válidos son del 1 al 65535.
- Elija TCP o UDP.
- Elija Permitir o Denegar.
- Haga clic en Agregar.
La regla aparece en la lista con un icono PERMITIR o 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 cuestión de segundos.
Para eliminar una regla, haga clic en la X al final de su fila. La eliminación de una regla de Permitir cierra ese puerto inmediatamente.
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úntese si lo que se conecta podría alcanzar la base de datos a través de la interfaz de bucle local del propio servidor o una red privada. Si realmente debe ser accesible desde el exterior, asegúrese de que el servicio en sí requiere autenticación fuerte y encriptación.
Agregue la regla primero, a continuación, inicie el servicio. Un servicio que se inicia detrás de un puerto cerrado parece roto exactamente de la misma manera que un servicio que no se pudo iniciar, y puede invertir mucho tiempo depurando la capa incorrecta.
Pilas de aplicaciones
La sección Pila de aplicaciones indica a la plataforma qué tipo de aplicación ejecuta este servidor, de modo que el ajuste preestablecido de endurecimiento pueda adaptarse. La instalación de una aplicación a través del panel lo establece automáticamente.
Las pilas reconocidas son WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web y No app stack. La sección se explica a sí misma: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
La pila afecta qué puertos se abren automáticamente y cómo se ajustan las otras protecciones, de forma más visible en fail2ban.
fail2ban
fail2ban vigila los intentos de autenticación y prohíbe direcciones que no dejan de fallar. 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."
Déjelo activado. Es la protección más económica en la página, no cuesta nada en rendimiento y convierte el ruido de fondo constante de intentos de adivinanza de contraseña en nada. En una pila de WordPress o WooCommerce también protege el formulario de inicio de sesión, que es donde realmente aterrizan la mayoría de los ataques contra WordPress.
ModSecurity, el cortafuegos de aplicación web
ModSecurity inspecciona las solicitudes HTTP con respecto al conjunto de reglas principales de 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."
Solo detección es el punto de partida correcto. El conjunto de reglas principal es exhaustivo y en una aplicación real algunas solicitudes legítimas coincidirán con una regla. Ejecútelo en modo solo detección durante un tiempo, lea los registros, descubra qué reglas activa su propio tráfico y solo entonces cambie al bloqueo dentro del servidor.
Activar el bloqueo sin ajustar primero puede romper su propio sitio. Los envíos de formulario con texto enriquecido, cargas de archivos y clientes API con cargas útiles inusuales son las víctimas habituales. Compruebe sus registros antes de cambiar.
Auto-parches del SO
Las actualizaciones 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."
Dos configuraciones se encuentran bajo el conmutador:
- Permitir reinicio automático cuando una actualización de kernel lo requiere (solo durante las horas silenciosas a continuación). Las actualizaciones del kernel solo surten efecto después de un reinicio. Si lo deja desactivado, los parches del kernel se instalan pero no están activos hasta que reinicie usted mismo.
- Ventana silenciosa (UTC), una hora de inicio y una de finalización. Los reinicios solo ocurren dentro de ella. Establézcala en las horas más silenciosas para su audiencia y recuerde que el campo está en UTC, no en su hora local.
Deje los auto-parches activados. La abrumadora mayoría de los servidores comprometidos ejecutan software con un parche que se publicó semanas antes. Una instantánea anterior al parche con reversión automática significa que la objeción habitual, que una actualización podría romper algo, ya se ha manejado.
Historial de parches y ejecución de un parche ahora
La sección Historial de parches enumera cada ejecución con un estado de RUNNING, SUCCESS, ROLLED_BACK, FAILED o SKIPPED, el número de paquetes actualizados, si el servidor se reinició y la hora en que comenzó.
Para parchar inmediatamente en lugar de esperar al cronograma, haga clic en Ejecutar parches ahora. La confirmación indica: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Una entrada ROLLED_BACK significa que la red de seguridad hizo su trabajo: el servidor no volvió en línea correctamente después de un reinicio, por lo que se restauró la instantánea anterior al parche. Consulte Instantáneas de servidor cloud para saber cómo funcionan esas instantáneas.
Una línea de base sensata
Para la mayoría de los servidores, esta es toda la configuración de seguridad:
| Configuración | Recomendado |
|---|---|
| Cortafuegos | Activado, reglas predeterminadas, más solo los puertos que necesita su aplicación |
| fail2ban | Activado |
| ModSecurity | Activado, solo detección hasta que haya leído los registros |
| Auto-parches del SO | 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 en conjunto. Consulte Conexión a su servidor cloud con SSH.
Solución de problemas
"Could not load management config." El panel no pudo leer la configuración de este servidor. Recargue y compruebe que el servidor existe y está aprovisionado.
"Port must be 1-65535." El campo de puerto toma un número entero en ese rango. No se aceptan rangos ni nombres de servicio aquí.
Mi regla se guardó pero nada cambió. Busque el banner "Live apply unavailable". Si se muestra, el cambio se almacena pero aún no se ha enviado al servidor.
Puedo alcanzar mi servicio desde una red pero no desde otra. Eso es generalmente su propio cortafuegos de salida, no el del servidor. Pruebe desde una conexión diferente antes de cambiar reglas aquí.
Una ejecución de parche muestra FAILED. Lea el mensaje de error en la fila. Un disco lleno es la causa más común. Libere espacio y haga clic en Ejecutar parches ahora.
El tráfico legítimo comenzó a ser bloqueado. Si cambió ModSecurity al modo de bloqueo, vuelva al modo solo detección, lea los registros e identifique la regla antes de intentarlo de nuevo.
Si una regla de cortafuegos se niega a aplicarse o está bloqueado en un servicio que ha permitido, envíe un correo electrónico a support@kapsulehost.com con el nombre del servidor, el puerto y lo que espera alcanzar.
Cada servidor KapsuleHost se envía con un cortafuegos administrado que deniega el tráfico entrante de forma predeterminada, más protección contra ataques de fuerza bruta, un cortafuegos de aplicación web y parches de seguridad automáticos, todo controlado desde una página en KPanel.
Los valores predeterminados se eligen para que un servidor nuevo sea seguro antes de que haya tocado nada. Lo que agrega además es generalmente solo los puertos que su propia aplicación necesita. Esta guía recorre toda la página de Gestión del servidor, porque el cortafuegos es una sección de ella y las otras secciones son lo que evita que necesite el cortafuegos en primer lugar.