# Webship Servidor Web: Definições Seguras por Predefinição
Um servidor web seguro não deve depender de um operador lembrar-se de mais uma configuração às 2 da manhã. Deve começar a partir de uma linha de base protetora, rejeitar configurações inseguras e exigir escolhas deliberadas antes de expor capacidades sensíveis.
Esse é o modelo por trás do Webship. A sua configuração padrão ativa as principais defesas de pedidos e respostas, limita os recursos que um atacante pode consumir e deixa as superfícies de controlo opcionais desativadas. Pode ajustar esses padrões para uma aplicação real, mas não precisa de descobrir todas as proteções antes de chegar o primeiro pedido.
Seguro por defeito não significa seguro sem contexto. Certificados, autorização de aplicação, 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 ativa seis camadas na sua configuração base:
| Camada | Comportamento padrão | O que reduz | | --- | --- | --- | | Proteção de ficheiros dot | Nega segmentos de caminho estáticos com prefixo dot | Exposição acidental de ficheiros de ambiente, metadados de 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çalhos e codificações de pedidos não suportadas | | Controles DDoS | Funciona em modo normal com estado de cliente limitado | Inundações de pedidos, rastreio ilimitado e exaustão de recursos evitável | | Desafio de bot | Utiliza um cookie de desafio assinado | Abuso automatizado e varredura repetida de baixo custo | | Cabeçalhos de segurança da resposta | Adiciona uma política restritiva ao navegador | Confusão MIME, enquadramento, fuga de referrer, capacidades perigosas do navegador e carregamento amplo de conteúdo | | Escudo API | Utiliza o modo de bloqueio e rejeita rotas desconhecidas uma vez que um contrato de API é definido | Endpoints sombra, métodos não intencionados, tipos de conteúdo inesperados e requisitos de autorização em falta |
O WAF padrão também estabelece limites rígidos sobre o que inspeciona: 32 KiB de cabeçalhos de pedido, um caminho de 2.048 bytes e um corpo de pedido de 1 MiB. Estes são limites de segurança, não ajustes de desempenho arbitrários. Se uma aplicação precisar legitimamente de pedidos maiores, aumente o limite relevante para essa aplicação e teste o resultado em vez de desativar a inspeção globalmente.
A proteção DDoS começa em modo normal a 600 pedidos por minuto com uma tolerância de pico de 100 por chave de cliente. A sua tabela de estado do cliente está limitada a 65.536 entradas. Estes 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 de administração interno não devem partilhar os mesmos limites específicos da aplicação.
As proteções do navegador fazem parte da linha de base
A política de cabeçalho de resposta do Webship está ativada mesmo quando uma aplicação se esquece de adicionar a sua própria. O padrão inclui:
- X-Content-Type-Options: nosniff;
- uma política de negação de frames;
- Política-de-Referenciador: sem-referenciador;
- 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âmara.
Estas predefinições são intencionalmente restritivas. Revise o HSTS antes de o aplicar a um domínio com subdomínios que não estejam totalmente preparados para HTTPS. Revise a Política de Segurança de Conteúdos antes de uma aplicação carregar scripts, estilos, fontes, imagens ou ligações a partir de outras origens. Um padrão seguro deve falhar de forma visível durante a implementação, não ser enfraquecido silenciosamente em produção.
As superfícies opcionais permanecem fechadas
Webship não expõe todas as funcionalidades só porque o binário as contém. Reverse proxying, WebTransport, endpoints de observabilidade, TLS automático, proveniência da resposta e o endpoint de controlo MCP estão desativados por defeito.
O endpoint MCP é limitado a loopback quando ativado e requer uma configuração de segurança explícita. Métricas e estatísticas exigem que a instrumentação seja ativada deliberadamente. A gestão automática de certificados exige que o operador escolha um diretório ACME, contactos, armazenamento e aceite os termos de serviço. Isto impede que funcionalidades operacionais se tornem superfícies de rede inesperadas.
O ouvinte base também se liga 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 implementação.
O proxy inverso preserva a fronteira de confiança
Quando a passagem por proxy reverso está ativada, a passagem TLS continua a ser a predefinição. Webship encaminha o tráfego criptografado sem tomar posse do texto simples da aplicação ou das chaves de sessão ativas. A origem continua a ser responsável pelo TLS e pelo protocolo negociado.
Ative a terminação TLS apenas quando Webship precisar de inspecionar pedidos HTTP, encaminhar por caminho, aplicar políticas WAF e API, reescrever cabeçalhos ou armazenar respostas em cache. A terminação não é inerentemente menos segura; ela desloca a fronteira de confiança. A decisão importante é determinar qual máquina tem permissão para ver o texto simples e porquê.
O modo pass-through também tem limites funcionais. O encaminhamento TCP baseia-se no SNI do ClientHello porque o pedido HTTP está encriptado. O pass-through HTTP/3 requer que as rotas partilhem uma origem UDP. Se precisar de segurança com consciência de conteúdo na borda, termine o TLS aí e proteja a ligação da borda à origem separadamente.
Um ponto de referência de produção que pode rever
O seguinte excerto torna explícitos os padrões importantes 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=()"Numa escuta multi-domínio, unknown_sni = "reject" impede que um nome de host não reconhecido receba o certificado padrão da escuta. Os listeners automatic-TLS do Webship já rejeitam nomes desconhecidos até que exista um certificado.
A validação é um controlo de segurança
Webship valida a configuração antes de ligar os ouvintes. Campos desconhecidos, limites inválidos, identidades incompletas, ouvintes em conflito e combinações de protocolos não suportadas fazem com que a inicialização falhe com um erro específico. A mesma validação é executada antes de instalar uma configuração activa. Um recarregamento falhado mantém a configuração atual activa.
O caminho de configuração autenticado MCP adiciona outra proteção: recusa alterações em tempo real que desativassem um WAF ativo, camada DDoS, API Shield, desafio de bots, política de autenticação de borda ou camada de cabeçalho de resposta. Verificações de versão impedem que um administrador substitua uma cópia de configuração mais recente. Configurações vinculadas a processos ainda requerem uma reinicialização em vez de fingir que uma alteração parcial em tempo real teve sucesso.
Esta é uma distinção útil. As predefinições seguras protegem uma implementação nova. A validação transacional e as atualizações protegidas protegem uma implementação em funcionamento.
Que 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 o HSTS e a Política de Segurança de Conteúdo correspondem a todas as aplicações e subdomínios.
- Defina os endpoints do API Shield, métodos aceites, 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.
- Ative a autenticação de borda para hosts ou caminhos protegidos e utilize 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, numa raiz de aplicação apenas de leitura sempre que possível, e apenas com as capacidades do sistema operativo de que necessita.
- Validar a configuração antes do lançamento, depois testar o tráfego bloqueado e permitido num ambiente canário.
- Monitorizar eventos de auditoria de segurança e ensaiar 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 utilizadores devem ver as suas faturas, quais origens podem chamar a sua API, ou com que rapidez o seu endpoint de negócios deve aceitar pedidos. Esses controlos requerem conhecimento da aplicação.
Webship fornece a camada inferior: analisadores limitados, configuração rigorosa, cabeçalhos de resposta defensivos, inspeção de pedidos, controlos 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 implementaçã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 opera.