# Webship Servidor Web: Configuración Segura por Defecto
Un servidor web seguro no debería depender de que un operador recuerde una configuración más a las 2 a.m. Debería comenzar desde una línea base protectora, rechazar configuraciones inseguras y requerir elecciones deliberadas antes de exponer capacidades sensibles.
Ese es el modelo detrás de Webship. Su configuración predeterminada activa las defensas principales de solicitudes y respuestas, limita los recursos que un atacante puede consumir y deja deshabilitadas las superficies de control opcionales. Puedes ajustar esos valores predeterminados para una aplicación real, pero no tienes que descubrir cada protección antes de que llegue la primera solicitud.
Seguro por defecto no significa seguro sin contexto. Los certificados, la autorización de aplicaciones, la política de red, los secretos y la respuesta a incidentes siguen siendo responsabilidad del operador. El trabajo de Webship es hacer que el punto de partida seguro sea obvio y dificultar el debilitamiento accidental.
Las protecciones que comienzan habilitadas
Webship habilita seis capas en su configuración base:
| Capa | Comportamiento por defecto | Lo que reduce | | --- | --- | --- | | Protección de archivos dot | Niega segmentos de ruta estáticos que comienzan con un punto | Exposición accidental de archivos de entorno, metadatos del repositorio y configuración local | | Cortafuegos de aplicaciones web | Bloquea patrones de ataque conocidos | Inyección SQL, secuencias de comandos entre sitios (XSS), traversión, sondeos de rutas sensibles, inyección de comandos, contrabando de encabezados y codificaciones de solicitudes no compatibles | | Controles DDoS | Funciona en modo normal con estado de cliente limitado | Inundaciones de solicitudes, seguimiento no limitado y agotamiento de recursos evitable | | Desafío de bot | Utiliza una cookie de desafío firmada | Abuso automatizado de bajo costo y escaneo repetido | | Encabezados de seguridad de respuesta | Agrega una política restrictiva para el navegador | Confusión de MIME, encuadre, filtrado de referencias, capacidades peligrosas del navegador y carga amplia de contenido | | Escudo de API | Utiliza el modo de bloqueo y rechaza rutas desconocidas una vez que se define un contrato de API | Endpoints ocultos, métodos no intencionados, tipos de contenido inesperados y requisitos de autorización faltantes |
El WAF predeterminado también establece límites estrictos en lo que inspecciona: 32 KiB de encabezados de solicitud, una ruta de 2.048 bytes y un cuerpo de solicitud de 1 MiB. Estos son límites de seguridad, no interruptores de rendimiento arbitrarios. Si una aplicación necesita legítimamente solicitudes más grandes, aumente el límite relevante para esa aplicación y pruebe el resultado en lugar de deshabilitar la inspección de manera global.
La protección contra DDoS comienza en modo normal a 600 solicitudes por minuto con una tolerancia de ráfaga de 100 por clave de cliente. Su tabla de estado del cliente está limitada a 65,536 entradas. Estos valores son una referencia, no un modelo de tráfico universal: una API pública, un servicio de descargas y un panel de administración interno no deben compartir los mismos límites específicos de la aplicación.
Las protecciones del navegador son parte de la línea base
La política de encabezado de respuesta de Webship está habilitada incluso cuando una aplicación olvida agregar la suya. El valor predeterminado incluye:
- X-Content-Type-Options: nosniff;
- una política de denegación de frames;
- Política de remitente: sin remitente;
- Strict-Transport-Security durante un año, incluidos los subdominios;
- Política de seguridad de contenido limitada a contenido del mismo origen, con restricciones de enmarcado y de URI base;
- Política de permisos deshabilitando el acceso a geolocalización, micrófono y cámara.
Estos valores predeterminados son intencionalmente restrictivos. Revise HSTS antes de aplicarlo a un dominio con subdominios que no estén completamente preparados para HTTPS. Revise Content-Security-Policy antes de que una aplicación cargue scripts, estilos, fuentes, imágenes o conexiones desde otros orígenes. Un valor predeterminado seguro debería fallar visiblemente durante la implementación, no debilitarse silenciosamente en producción.
Las superficies opcionales permanecen cerradas
Webship no expone todas las funcionalidades solo porque el binario las contenga. El proxy inverso, WebTransport, los endpoints de observabilidad, TLS automático, la procedencia de respuestas y el endpoint de control de MCP están deshabilitados por defecto.
El punto de acceso MCP tiene un alcance de bucle invertido cuando está habilitado y requiere una configuración de seguridad explícita. Las métricas y estadísticas requieren que la instrumentación se habilite deliberadamente. La gestión automática de certificados requiere que el operador elija un directorio ACME, contactos, almacenamiento y la aceptación de los términos de servicio. Esto evita que las funciones operativas se conviertan en superficies de red inesperadas.
El oyente base también se enlaza a 127.0.0.1. Un operador debe seleccionar explícitamente una dirección pública. Esa única elección crea un punto de revisión útil para las reglas del cortafuegos, permisos de servicio, identidad TLS y topología de implementación.
El proxy inverso preserva el límite de confianza
Cuando se habilita el proxy inverso, la transmisión de TLS sigue siendo la predeterminada. Webship reenvía el tráfico cifrado sin hacerse cargo del texto plano de la aplicación ni de las claves de sesión activas. El origen sigue siendo responsable del TLS y del protocolo negociado.
Habilite la finalización de TLS solo cuando Webship deba inspeccionar solicitudes HTTP, enrutar por ruta, aplicar políticas de WAF y API, reescribir encabezados o almacenar en caché respuestas. La finalización no es inherentemente menos segura; mueve el límite de confianza. La decisión importante es qué máquina tiene permitido ver el texto sin cifrar y por qué.
El paso a través también tiene límites funcionales. La enrutación TCP se basa en el SNI de ClientHello porque la solicitud HTTP está encriptada. HTTP/3 el paso a través requiere que las rutas compartan un origen UDP. Si necesitas seguridad consciente del contenido en el borde, termina TLS allí y protege el salto del borde al origen por separado.
Una línea base de producción que puede revisar
El siguiente extracto hace explícitos los ajustes predeterminados importantes en lugar de depender de la omisión:
listen = "0.0.0.0:443"
deny_dotfiles = true
[tls]
unknown_sni = "reject"
[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 60
max_tracked_clients = 65536
[security]
enabled = true
rate_limit_max_entries = 65536
[security.waf]
enabled = true
mode = "block"
sqli = true
xss = true
traversal = true
sensitive_paths = true
header_abuse = true
max_header_bytes = 32768
max_path_bytes = 2048
max_body_bytes = 1048576
[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'; base-uri 'self'"
permissions_policy = "geolocation=(), microphone=(), camera=()"En un oyente multi-dominio, unknown_sni = "reject" evita que un nombre de host no reconocido reciba el certificado predeterminado del oyente. Los oyentes de TLS automático de Webship ya rechazan nombres desconocidos hasta que exista un certificado.
La validación es un control de seguridad
Webship valida la configuración antes de vincular los listeners. Los campos desconocidos, límites inválidos, identidades incompletas, listeners en conflicto y combinaciones de protocolos no compatibles provocan el fallo del inicio con un error específico. La misma validación se ejecuta antes de que se instale una configuración en vivo. Una recarga fallida mantiene la configuración actual activa.
La ruta de configuración autenticada MCP añade otra protección: rechaza los cambios en vivo que deshabilitarían un WAF activo, una capa DDoS, API Shield, desafío de bots, política de autenticación en el borde o una capa de encabezado de respuesta. Las comprobaciones de versión evitan que un administrador sobrescriba un snapshot de configuración más reciente. Las configuraciones vinculadas a procesos aún requieren un reinicio en lugar de fingir que un cambio parcial en vivo tuvo éxito.
Esta es una distinción útil. Los valores predeterminados seguros protegen una nueva implementación. La validación transaccional y las actualizaciones protegidas protegen una en funcionamiento.
Qué operadores aún necesitan decidir
Antes de exponer Webship a Internet:
- Configure una identidad TLS confiable y proteja la clave privada.
- Establecer el manejo de SNI desconocido para la topología del oyente.
- Confirme que HSTS y Content-Security-Policy coincidan en cada aplicación y subdominio.
- Define los endpoints de API Shield, los métodos aceptados, los tipos de contenido y los requisitos de autorización.
- Agrega límites de velocidad específicos por ruta en lugar de depender únicamente del nivel global.
- Habilite la autenticación en el borde para hosts o rutas protegidas y use tokens de corta duración.
- Mantenga MCP y los escuchas de observabilidad privados, autenticados y separados del tráfico público.
- Ejecute Webship con una cuenta dedicada sin privilegios, una raíz de aplicación de solo lectura cuando sea posible, y solo las capacidades del sistema operativo que necesite.
- Valide la configuración antes del despliegue, luego pruebe el tráfico bloqueado y permitido en un entorno canario.
- Supervise los eventos de auditoría de seguridad y practique el cambio de modo normal a modo bajo ataque o bloqueo.
Un valor predeterminado más seguro es un comienzo, no una afirmación
Ningún servidor web puede decidir qué usuarios deben ver tus facturas, qué orígenes pueden llamar a tu API o con qué rapidez tu endpoint empresarial debe aceptar solicitudes. Esos controles requieren conocimiento de la aplicación.
Webship suministra la capa inferior: analizadores limitados, configuración estricta, encabezados de respuesta defensivos, inspección de solicitudes, controles de abuso y superficies opcionales cerradas. El resultado no es “seguridad resuelta”. Es una brecha más pequeña entre instalar un servidor y operarlo de manera responsable.
Revise la Webship documentación completa antes del despliegue en producción. El esquema de configuración y el binario en ejecución siguen siendo las fuentes autorizadas para la versión exacta que opera.