# Webship Webbserver: Säker inställning som standard
En säker webbserver bör inte bero på att en operatör kommer ihåg ytterligare en inställning vid klockan 2 på morgonen. Den bör utgå från en skyddande baslinje, avvisa osäker konfiguration och kräva medvetna val innan den exponerar känsliga funktioner.
Det är modellen bakom Webship. Dess standardkonfiguration aktiverar de huvudsakliga försvaren för förfrågningar och svar, begränsar de resurser en angripare kan använda och lämnar valfria kontrollytor inaktiverade. Du kan justera dessa standardinställningar för en verklig applikation, men du behöver inte upptäcka alla skydd innan den första förfrågan kommer.
Säker som standard betyder inte säker utan kontext. Certifikat, applikationsbehörighet, nätverkspolicy, hemligheter och incidenthantering tillhör fortfarande operatören. Webship’s uppgift är att göra utgångspunkten säker tydlig—och göra oavsiktlig försvagning svårare.
Skydden som startar aktiverade
Webship aktiverar sex lager i dess baskonfiguration:
| Lager | Standardbeteende | Vad det minskar | | --- | --- | --- | | Dot-filsskydd | Neka punkt-prefixade statiska sökvägssegment | Oavsiktlig exponering av miljöfiler, repositorymetadata och lokal konfiguration | | Webbaserad applikationsbrandvägg | Blockerar kända attackmönster | SQL-injektion, cross-site scripting, traversal, känsliga sökvägsförfrågningar, kommandoinjektion, header-smuggling och icke stödda begäranenkodningar | | DDoS-kontroller | Körs i normalt läge med begränsat klienttillstånd | Förfrågningsflöden, obegränsad spårning och undvikbar resursutmattning | | Bot-utmaning | Använder en signerad utmaningscookie | Lågkostnadsautomatiserat missbruk och upprepad skanning | | Säkerhetsrubriker för svar | Lägger till en restriktiv webbläsarpolicy | MIME-förvirring, inramning, läckage av referens, farliga webbläsarfunktioner och omfattande innehållsladdning | | API-skydd | Använder blockläge och avvisar okända rutter när ett API-kontrakt är definierat | Skuggendpunkter, oavsiktliga metoder, oväntade innehållstyper och saknade auktoriseringskrav |
Den förvalda WAF placerar också hårda gränser för vad den inspekterar: 32 KiB av begäranrubriker, en 2 048-byte lång sökväg och en 1 MiB lång begäran. Detta är säkerhetsgränser, inte godtyckliga prestandainställningar. Om en applikation legitimt behöver större begäranden, höj den relevanta gränsen för den applikationen och testa resultatet istället för att inaktivera inspektionen globalt.
DDoS-skydd börjar i normalt läge vid 600 förfrågningar per minut med en tillåten burst på 100 per klientnyckel. Dess klienttillståndstabell är begränsad till 65 536 poster. Dessa värden är en grundlinje, inte en universell trafikmodell: ett offentligt API, en nedladdningstjänst och en intern administrationspanel bör inte dela samma applikationsspecifika gränser.
Webbläsarskydd är en del av baslinjen
Webship’s svar-header-policy är aktiverad även när en applikation glömmer att lägga till sin egen. Standardinställningen inkluderar:
- X-Content-Type-Options: nosniff;
- en ram-förnekande policy;
- Referrer-policy: ingen-referrer;
- Strict-Transport-Security i ett år, inklusive underdomäner;
- Content-Security-Policy begränsad till samma ursprungsinnehåll, med ram- och grund-URI-begränsningar;
- Behörighetspolicy som inaktiverar åtkomst till geolokalisering, mikrofon och kamera.
Dessa standardinställningar är avsiktligt restriktiva. Granska HSTS innan du tillämpar det på en domän med underdomäner som inte är helt HTTPS-klara. Granska Content-Security-Policy innan en applikation laddar skript, stilar, typsnitt, bilder eller anslutningar från andra ursprung. En säker standardinställning bör misslyckas synligt under distribution, inte försvagas tyst i produktion.
Valfria ytor förblir stängda
Webship exponerar inte varje funktion bara för att binären innehåller den. Omvänd proxy, WebTransport, observabilitetsändpunkter, automatisk TLS, svarens ursprung och MCP-kontrolländen är inaktiverade som standard.
Den MCP-endpointen är loopback-scope när den är aktiverad och kräver en explicit säkerhetskonfiguration. Mätvärden och statistik kräver att instrumentering aktiveras medvetet. Automatisk certifikathantering kräver att operatören väljer en ACME-katalog, kontakter, lagring och godkännande av användarvillkor. Detta förhindrar att driftfunktioner blir överraskande nätverksytor.
Den grundläggande lyssnaren binder sig också till 127.0.0.1. En operatör måste uttryckligen välja en offentlig adress. Det enda valet skapar en användbar granskningspunkt för brandväggsregler, tjänstetillstånd, TLS-identitet och distributionstopologi.
Omvänd proxy bevarar förtroendegränsen
När omvänd proxying är aktiverad förblir TLS pass-through standard. Webship vidarebefordrar krypterad trafik utan att ta emot applikationens klartext eller aktiva sessionsnycklar. Ursprungssystemet förblir ansvarigt för TLS och det förhandlade protokollet.
Aktivera TLS-terminering endast när Webship måste inspektera HTTP-förfrågningar, routa efter sökväg, tillämpa WAF- och API-policys, skriva om headers eller cachea svar. Terminering är inte i sig mindre säker; den flyttar förtroendegränsen. Den viktiga beslutet är vilken maskin som tillåts se klartext och varför.
Pass-through har också funktionella begränsningar. TCP-routing baseras på ClientHello SNI eftersom HTTP-förfrågan är krypterad. HTTP/3 pass-through kräver att rutter delar en UDP-origin. Om du behöver innehållsmedveten säkerhet vid kanten, terminera TLS där och skydda hoppet från kant till origin separat.
En produktionsbaslinje du kan granska
Följande utdrag gör de viktiga standardinställningarna tydliga istället för att förlita sig på utelämnande:
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=()"På en multi-domän-lyssnare förhindrar unknown_sni = "reject" att ett okänt värdnamn får lyssnarens standardcertifikat. Webships automatiska TLS-lyssnare avvisar redan okända namn tills ett certifikat finns.
Validering är en säkerhetskontroll
Webship validerar konfigurationen innan den binder lyssnare. Okända fält, ogiltiga gränser, ofullständiga identiteter, motstridiga lyssnare och ej stödda protokollkombinationer gör att uppstarten misslyckas med ett specifikt fel. Samma validering körs innan en aktiv konfiguration installeras. Ett misslyckat omladdning lämnar den nuvarande konfigurationen aktiv.
Den autentiserade MCP konfigurationsvägen lägger till ett ytterligare skydd: den vägrar live-ändringar som skulle inaktivera en aktiv WAF, DDoS-lager, API Shield, bot-utmaning, edge-auth-policy eller svarshuvudslager. Versionskontroller förhindrar att en administratör skriver över en nyare konfigurationssnapshot. Processbundna inställningar kräver fortfarande en omstart istället för att låtsas att en delvis live-ändring lyckades.
Detta är en användbar skillnad. Säkra standardinställningar skyddar en ny installation. Transaktionell validering och skyddade uppdateringar skyddar en igångvarande.
Vad operatörer fortfarande behöver besluta
Innan du utsätter Webship för internet:
- Konfigurera en betrodd TLS-identitet och skydda den privata nyckeln.
- Ange hantering av okänd SNI för lyssnartopologin.
- Bekräfta att HSTS och Content-Security-Policy matchar varje applikation och underdomän.
- Definiera API Shield-slutpunkter, accepterade metoder, innehållstyper och auktoriseringskrav.
- Lägg till rutspecifika hastighetsbegränsningar istället för att endast förlita dig på den globala baslinjen.
- Aktivera kantautentisering för skyddade värdar eller sökvägar och använd kortlivade tokens.
- Håll MCP och observabilitetslyssnare privata, autentiserade och separerade från offentlig trafik.
- Kör Webship med ett dedikerat icke-privilegierat konto, en skrivskyddad applikationsrot där det är möjligt och endast de operativsystemsfunktioner det behöver.
- Validera konfigurationen innan utrullning, testa sedan blockerad och tillåten trafik i en kanariefågelmiljö.
- Övervaka säkerhetsgranskningshändelser och öva på övergången från normalt läge till under_angrepp eller låst läge.
En säkrare standard är en början, inte ett påstående
Ingen webbserver kan bestämma vilka användare som ska se dina fakturor, vilka ursprung som får anropa ditt API, eller hur snabbt din affärsändpunkt ska acceptera förfrågningar. Dessa kontroller kräver applikationskunskap.
Webship tillhandahåller det lägre lagret: begränsade parsers, strikt konfiguration, defensiva svarshuvuden, förfrågningsinspektion, missbrukskontroller och stängda valfria ytor. Resultatet är inte “säkerhet löst.” Det är ett mindre gap mellan att installera en server och att driva den på ett ansvarsfullt sätt.
Granska den fullständiga Webship dokumentationen innan produktionssättning. Konfigurationsschemat och den körande binären förblir de auktoritativa källorna för den exakta version du använder.