# Webship Servidor Web: Configurações Seguras por Padrão
Um servidor web seguro não deve depender de um operador lembrar de mais uma configuração às 2 da manhã. Ele deve começar a partir de uma linha de base protetiva, rejeitar configurações inseguras e exigir escolhas deliberadas antes de expor capacidades sensíveis.
Esse é o modelo por trás do Webship. Sua configuração padrão ativa as principais defesas de requisição e resposta, limita os recursos que um atacante pode consumir e deixa as superfícies de controle opcionais desativadas. Você pode ajustar esses padrões para uma aplicação real, mas não precisa descobrir todas as proteções antes da chegada da primeira requisição.
Seguro por padrão não significa seguro sem contexto. Certificados, autorização de aplicativos, política de rede, segredos e resposta a incidentes ainda pertencem ao operador. O trabalho do Webship é tornar o ponto de partida seguro óbvio—e tornar o enfraquecimento acidental mais difícil.
As proteções que começam ativadas
Webship habilita seis camadas em sua configuração básica:
| Camada | Comportamento padrão | O que ela reduz | | --- | --- | --- | | Proteção de arquivos dot | Nega segmentos de caminho estáticos prefixados com dot | Exposição acidental de arquivos de ambiente, metadados do repositório e configuração local | | Firewall de aplicação web | Bloqueia padrões de ataque conhecidos | Injeção SQL, cross-site scripting, traversal, sondagens de caminhos sensíveis, injeção de comandos, contrabando de cabeçalho e codificações de requisição não suportadas | | Controles de DDoS | Funciona no modo normal com estado de cliente limitado | Inundações de solicitações, rastreamento ilimitado e exaustão de recursos evitável | | Desafio de bot | Utiliza um cookie de desafio assinado | Abuso automatizado de baixo custo e varredura repetida | | Cabeçalhos de segurança da resposta | Adiciona uma política restritiva para o navegador | Confusão de MIME, enquadramento, vazamento de referenciador, capacidades perigosas do navegador e carregamento amplo de conteúdo | | API Shield | Utiliza o modo de bloqueio e rejeita rotas desconhecidas uma vez que um contrato de API é definido | Endpoints ocultos, métodos não intencionados, tipos de conteúdo inesperados e requisitos de autorização ausentes |
O WAF padrão também estabelece limites rígidos sobre o que ele inspeciona: 32 KiB de cabeçalhos de solicitação, um caminho de 2.048 bytes e um corpo de solicitação de 1 MiB. Estes são limites de segurança, não ajustes arbitrários de desempenho. Se uma aplicação realmente precisar de solicitações maiores, aumente o limite relevante para essa aplicação e teste o resultado em vez de desativar a inspeção globalmente.
A proteção contra DDoS começa em modo normal com 600 requisições por minuto e uma tolerância de estouro de 100 por chave de cliente. Sua tabela de estado do cliente é limitada a 65.536 entradas. Esses valores são uma referência, não um modelo universal de tráfego: uma API pública, um serviço de download e um painel administrativo interno não devem compartilhar os mesmos limites específicos de aplicação.
As proteções do navegador fazem parte do padrão
A política de cabeçalho de resposta do Webship está ativada mesmo quando um aplicativo se esquece de adicionar a sua própria. O padrão inclui:
- X-Content-Type-Options: nosniff;
- uma política de negação de quadro;
- Política de Referência: sem-referência;
- Strict-Transport-Security por um ano, incluindo subdomínios;
- Política de Segurança de Conteúdo limitada a conteúdo da mesma origem, com restrições de enquadramento e base-URI;
- Política de permissões desativando o acesso à geolocalização, microfone e câmera.
Esses padrões são intencionalmente restritivos. Revise o HSTS antes de aplicá-lo a um domínio com subdomínios que não estejam totalmente prontos para HTTPS. Revise a Política de Segurança de Conteúdo antes que um aplicativo carregue scripts, estilos, fontes, imagens ou conexões de outras origens. Um padrão seguro deve falhar visivelmente durante a implantação, e não ser silenciosamente enfraquecido em produção.
Superfícies opcionais permanecem fechadas
Webship não expõe todos os recursos apenas porque o binário os contém. Proxy reverso, WebTransport, endpoints de observabilidade, TLS automático, proveniência da resposta e o endpoint de controle MCP estão desativados por padrão.
O endpoint MCP é limitado a loopback quando habilitado e requer uma configuração de segurança explícita. Métricas e estatísticas exigem que a instrumentação seja habilitada deliberadamente. O gerenciamento automático de certificados exige que o operador escolha um diretório ACME, contatos, armazenamento e aceite os termos de serviço. Isso impede que recursos operacionais se tornem superfícies de rede inesperadas.
O listener base também se conecta a 127.0.0.1. Um operador deve selecionar explicitamente um endereço público. Essa única escolha cria um ponto de revisão útil para regras de firewall, permissões de serviço, identidade TLS e topologia de implantação.
O proxy reverso preserva a fronteira de confiança
Quando o proxy reverso está habilitado, o encaminhamento TLS continua sendo o padrão. Webship encaminha o tráfego criptografado sem assumir a posse do texto simples do aplicativo ou das chaves de sessão ativas. A origem continua responsável pelo TLS e pelo protocolo negociado.
Habilite a terminação TLS apenas quando Webship precisar inspecionar solicitações HTTP, rotear por caminho, aplicar políticas de WAF e API, reescrever cabeçalhos ou armazenar respostas em cache. A terminação não é inerentemente menos segura; ela apenas move o limite de confiança. A decisão importante é qual máquina tem permissão para ver o texto simples e por quê.
O modo pass-through também possui limites funcionais. O roteamento TCP é baseado no ClientHello SNI porque a solicitação HTTP está criptografada. O pass-through HTTP/3 requer que as rotas compartilhem uma origem UDP. Se você precisar de segurança com consciência de conteúdo na borda, encerre o TLS lá e proteja o trecho da borda até a origem separadamente.
Um padrão de produção que você pode revisar
O seguinte trecho torna os padrões importantes explícitos em vez de depender da omissão:
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=()"Em um ouvinte multi-domínio, unknown_sni = "reject" impede que um hostname não reconhecido receba o certificado padrão do ouvinte. Os ouvintes de TLS automático do Webship já rejeitam nomes desconhecidos até que um certificado exista.
Validação é um controle de segurança
Webship valida a configuração antes de vincular os listeners. Campos desconhecidos, limites inválidos, identidades incompletas, listeners conflitantes e combinações de protocolos não suportadas causam falha na inicialização com um erro específico. A mesma validação é executada antes de uma configuração ativa ser instalada. Um recarregamento falho mantém a configuração atual ativa.
O caminho de configuração MCP autenticado adiciona outra proteção: ele recusa alterações ao vivo que desativariam um WAF ativo, camada DDoS, API Shield, desafio de bot, política de autenticação de borda ou camada de cabeçalho de resposta. Verificações de versão impedem que um administrador sobrescreva um snapshot de configuração mais recente. Configurações vinculadas ao processo ainda exigem uma reinicialização em vez de fingir que uma alteração parcial ao vivo foi bem-sucedida.
Esta é uma distinção útil. Padrões seguros protegem uma implantação nova. Validação transacional e atualizações protegidas protegem uma em execução.
Quais operadores ainda precisam decidir
Antes de expor Webship à internet:
- Configure uma identidade TLS confiável e proteja a chave privada.
- Definir o tratamento de SNI desconhecido para a topologia do ouvinte.
- Confirme que HSTS e Content-Security-Policy correspondem a cada aplicação e subdomínio.
- Defina os endpoints do API Shield, métodos aceitos, tipos de conteúdo e requisitos de autorização.
- Adicione limites de taxa específicos para cada rota em vez de depender apenas da linha de base global.
- Habilite a autenticação de borda para hosts ou caminhos protegidos e use tokens de curta duração.
- Mantenha MCP e os ouvintes de observabilidade privados, autenticados e separados do tráfego público.
- Execute Webship com uma conta dedicada sem privilégios, uma raiz de aplicativo apenas de leitura sempre que possível, e somente com as capacidades do sistema operacional que ela necessita.
- Valide a configuração antes do lançamento e, em seguida, teste o tráfego bloqueado e permitido em um ambiente canário.
- Monitore eventos de auditoria de segurança e pratique a mudança do modo normal para sob_ataque ou bloqueio.
Um padrão mais seguro é um começo, não uma afirmação
Nenhum servidor web pode decidir quais usuários devem ver suas faturas, quais origens podem chamar sua API ou com que rapidez seu endpoint de negócios deve aceitar solicitações. Esses controles exigem conhecimento da aplicação.
Webship fornece a camada inferior: analisadores limitados, configuração rigorosa, cabeçalhos de resposta defensivos, inspeção de solicitações, controles de abuso e superfícies opcionais fechadas. O resultado não é 'segurança resolvida'. É uma lacuna menor entre instalar um servidor e operá-lo de forma responsável.
Revise a Webship documentação completa antes da implantação em produção. O esquema de configuração e o binário em execução permanecem as fontes autoritativas para a versão exata que você opera.