# Webship Server Web: Impostazioni Sicure per Default
Un server web sicuro non dovrebbe dipendere dal fatto che un operatore ricordi un'impostazione in più alle 2 del mattino. Dovrebbe partire da una base protettiva, rifiutare configurazioni insicure e richiedere scelte deliberate prima di esporre capacità sensibili.
Quello è il modello dietro Webship. La sua configurazione predefinita attiva le principali difese per le richieste e le risposte, limita le risorse che un attaccante può consumare e lascia disattivate le superfici di controllo opzionali. Puoi regolare tali impostazioni predefinite per un'applicazione reale, ma non è necessario scoprire ogni protezione prima che arrivi la prima richiesta.
Sicuro per impostazione predefinita non significa sicuro senza contesto. Certificati, autorizzazione delle applicazioni, policy di rete, segreti e risposta agli incidenti appartengono ancora all'operatore. Il lavoro di Webship è rendere evidente il punto di partenza sicuro—e rendere più difficile l'indebolimento accidentale.
Le protezioni che iniziano attivate
Webship abilita sei livelli nella sua configurazione di base:
| Livello | Comportamento predefinito | Cosa riduce | | --- | --- | --- | | Protezione dei file dot | Nega i segmenti di percorso statici che iniziano con un punto | Esposizione accidentale di file di ambiente, metadati del repository e configurazione locale | | Firewall per applicazioni web | Blocca modelli di attacco conosciuti | Iniezione SQL, cross-site scripting, traversal, probe su percorsi sensibili, iniezione di comandi, contrabbando di intestazioni e codifiche di richiesta non supportate | | Controlli DDoS | Funziona in modalità normale con stato cliente limitato | Inondazioni di richieste, tracciamento illimitato e esaurimento evitabile delle risorse | | Sfida del bot | Utilizza un cookie di sfida firmato | Abusi automatizzati a basso costo e scansioni ripetute | | Intestazioni di sicurezza della risposta | Aggiunge una politica restrittiva del browser | Confusione MIME, framing, perdita del referrer, capacità pericolose del browser e caricamento ampio dei contenuti | | Scudo API | Utilizza la modalità di blocco e rifiuta le route sconosciute una volta definito un contratto API | Endpoint ombra, metodi non intenzionati, tipi di contenuto imprevisti e requisiti di autorizzazione mancanti |
Il WAF predefinito impone anche limiti rigidi su ciò che ispeziona: 32 KiB di intestazioni della richiesta, un percorso di 2.048 byte e un corpo della richiesta di 1 MiB. Questi sono limiti di sicurezza, non interruttori di prestazioni arbitrari. Se un'applicazione ha legittimamente bisogno di richieste più grandi, aumenta il limite pertinente per quell'applicazione e testa il risultato invece di disabilitare l'ispezione a livello globale.
La protezione DDoS inizia in modalità normale a 600 richieste al minuto con una tolleranza di picco di 100 per chiave client. La sua tabella dello stato del client è limitata a 65.536 voci. Questi valori sono un punto di riferimento, non un modello di traffico universale: un'API pubblica, un servizio di download e un pannello di amministrazione interno non dovrebbero condividere gli stessi limiti specifici dell'applicazione.
Le protezioni del browser fanno parte delle basi
La policy dell'intestazione di risposta di Webship è attiva anche quando un'applicazione dimentica di aggiungere la propria. Il valore predefinito include:
- X-Content-Type-Options: nosniff;
- una politica di negazione del frame;
- Referrer-Policy: no-referrer;
- Strict-Transport-Security per un anno, inclusi i sottodomini;
- Content-Security-Policy limitata ai contenuti della stessa origine, con restrizioni su framing e base-URI;
- Policy delle autorizzazioni che disabilita l'accesso alla geolocalizzazione, al microfono e alla fotocamera.
Questi valori predefiniti sono intenzionalmente restrittivi. Rivedere HSTS prima di applicarlo a un dominio con sottodomini che non sono completamente pronti per HTTPS. Rivedere Content-Security-Policy prima che un'applicazione carichi script, stili, font, immagini o connessioni da altre origini. Un valore predefinito sicuro dovrebbe fallire visibilmente durante il deployment, non essere indebolito silenziosamente in produzione.
Le superfici opzionali rimangono chiuse
Webship non espone ogni funzionalità solo perché il binario la contiene. Il reverse proxying, WebTransport, gli endpoint di osservabilità, il TLS automatico, la provenienza delle risposte e l'endpoint di controllo MCP sono disattivati per impostazione predefinita.
L'endpoint MCP è a ambito loopback quando abilitato e richiede una configurazione di sicurezza esplicita. Metriche e statistiche richiedono che l'instrumetazione sia abilitata deliberatamente. La gestione automatica dei certificati richiede che l'operatore scelga una directory ACME, contatti, archiviazione e accettazione dei termini di servizio. Questo impedisce che le funzionalità operative diventino superfici di rete improvvise.
L'ascoltatore di base si collega anche a 127.0.0.1. Un operatore deve selezionare esplicitamente un indirizzo pubblico. Questa singola scelta crea un punto di revisione utile per le regole del firewall, i permessi del servizio, l'identità TLS e la topologia di distribuzione.
Il reverse proxy preserva il confine di fiducia
Quando il reverse proxy è abilitato, il pass-through TLS rimane il default. Webship inoltra il traffico crittografato senza assumere il possesso del testo in chiaro dell'applicazione o delle chiavi di sessione attive. L'origine rimane responsabile del TLS e del protocollo negoziato.
Abilita la terminazione TLS solo quando Webship deve ispezionare le richieste HTTP, instradare per percorso, applicare regole WAF e policy API, riscrivere intestazioni o memorizzare nella cache le risposte. La terminazione non è intrinsecamente meno sicura; sposta il confine di fiducia. La decisione importante è quale macchina è autorizzata a vedere il testo in chiaro e perché.
Il pass-through ha anche limiti funzionali. Il routing TCP si basa su ClientHello SNI perché la richiesta HTTP è criptata. Il pass-through HTTP/3 richiede che le rotte condividano un unico'origine UDP. Se hai bisogno di sicurezza consapevole dei contenuti al confine, termina TLS lì e proteggi separatamente il tragitto dal confine all'origine.
Una base di produzione che puoi esaminare
Il seguente estratto rende espliciti i valori predefiniti importanti invece di fare affidamento sull'omissione:
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=()"Su un listener multi-dominio, unknown_sni = "reject" impedisce a un hostname non riconosciuto di ricevere il certificato predefinito del listener. I listener automatici-TLS di Webship rifiutano già i nomi sconosciuti fino a quando non esiste un certificato.
La convalida è un controllo di sicurezza
Webship convalida la configurazione prima di collegare i listener. Campi sconosciuti, limiti non validi, identità incomplete, listener in conflitto e combinazioni di protocolli non supportate provocano un errore specifico all'avvio. La stessa convalida viene eseguita prima che una configurazione live venga installata. Un caricamento non riuscito lascia attiva la configurazione corrente.
Il percorso di configurazione autenticato MCP aggiunge un'altra protezione: rifiuta modifiche in tempo reale che disabiliterebbero un WAF attivo, uno strato DDoS, API Shield, una sfida bot, una politica edge-auth o uno strato di intestazioni di risposta. I controlli di versione impediscono a un amministratore di sovrascrivere uno snapshot di configurazione più recente. Le impostazioni legate al processo richiedono ancora un riavvio invece di fingere che una modifica parziale in tempo reale abbia avuto successo.
Questa è una distinzione utile. I valori predefiniti sicuri proteggono una nuova implementazione. La validazione transazionale e gli aggiornamenti protetti proteggono una implementazione in esecuzione.
Quali operatori devono ancora decidere
Prima di esporre Webship a Internet:
- Configura un'identità TLS affidabile e proteggi la chiave privata.
- Imposta la gestione SNI sconosciuta per la topologia del listener.
- Conferma che HSTS e Content-Security-Policy corrispondano a ogni applicazione e sottodominio.
- Definire gli endpoint di API Shield, i metodi accettati, i tipi di contenuto e i requisiti di autorizzazione.
- Aggiungi limiti di velocità specifici per il percorso invece di fare affidamento solo sul valore di base globale.
- Abilitare l'autenticazione ai bordi per host o percorsi protetti e utilizzare token a breve durata.
- Mantieni MCP e i listener di osservabilità privati, autenticati e separati dal traffico pubblico.
- Esegui Webship con un account dedicato senza privilegi, un root dell'applicazione in sola lettura dove possibile, e solo le capacità del sistema operativo di cui ha bisogno.
- Convalidare la configurazione prima del rilascio, quindi testare il traffico bloccato e consentito in un ambiente canarino.
- Monitorare gli eventi di audit della sicurezza e provare il passaggio dalla modalità normale a quella sotto attacco o in blocco.
Un'impostazione predefinita più sicura è un inizio, non una dichiarazione
Nessun server web può decidere quali utenti dovrebbero vedere le tue fatture, quali origini possono chiamare la tua API o quanto velocemente il tuo endpoint aziendale dovrebbe accettare le richieste. Questi controlli richiedono conoscenze dell'applicazione.
Webship fornisce lo strato inferiore: parser limitati, configurazione rigorosa, intestazioni di risposta difensive, ispezione delle richieste, controlli di abuso e superfici opzionali chiuse. Il risultato non è “sicurezza risolta.” È una distanza più piccola tra l'installazione di un server e la sua gestione responsabile.
Rivedi la completa Webship documentazione prima del deployment in produzione. Lo schema di configurazione e il binario in esecuzione rimangono le fonti autorevoli per la versione esatta che stai utilizzando.