# Webship Webserver: Standaard beveiligde instellingen
Een veilige webserver mag niet afhankelijk zijn van het feit dat een operator zich om 2 uur 's nachts nog een instelling herinnert. Het zou moeten beginnen met een beschermende basislijn, onveilige configuraties moeten afwijzen en bewuste keuzes vereisen voordat het gevoelige mogelijkheden blootstelt.
Dat is het model achter Webship. De standaardconfiguratie schakelt de belangrijkste verdedigingsmechanismen voor verzoeken en antwoorden in, beperkt de middelen die een aanvaller kan gebruiken en laat optionele bedieningsvlakken uitgeschakeld. Je kunt die standaardinstellingen aanpassen voor een echte toepassing, maar je hoeft niet elke bescherming te ontdekken voordat het eerste verzoek binnenkomt.
Beveiligd standaard betekent niet beveiligd zonder context. Certificaten, applicatieautorisatie, netwerkbeleid, geheimen en incidentrespons blijven nog steeds bij de operator horen. Het werk van Webship is om het veilige startpunt duidelijk te maken—en het per ongeluk verzwakken moeilijker te maken.
De beveiligingen die ingeschakeld zijn bij start
Webship schakelt zes lagen in in de basisconfiguratie:
| Laag | Standaardgedrag | Wat het vermindert | | --- | --- | --- | | Dot-bestandbescherming | Weigert statische padsegmenten die met een punt beginnen | Onbedoelde blootstelling van omgevingsbestanden, repositorymetadata en lokale configuratie | | Webapplicatie firewall | Blokkeert bekende aanvalspatronen | SQL-injectie, cross-site scripting, traversals, probes van gevoelige paden, commandoinjectie, header-smokkelen en niet-ondersteunde verzoekcoderingen | | DDoS-controles | Werkt in normale modus met begrensde klantstatus | Verzoekflutingen, onbeperkte tracking en vermijdbare uitputting van middelen | | Botuitdaging | Gebruikt een ondertekende uitdagingcookie | Goedkope geautomatiseerde misbruik en herhaalde scanningen | | Beveiligingsheaders voor reacties | Voegt een beperkend browserbeleid toe | MIME-verwarring, framing, referrer-lekkage, gevaarlijke browserfunctionaliteiten en brede contentlading | | API Shield | Gebruikt blokmodus en weigert onbekende routes zodra een API-contract is gedefinieerd | Schaduw-eindpunten, onbedoelde methoden, onverwachte inhoudstypen en ontbrekende autorisatievereisten |
De standaard WAF stelt ook harde grenzen aan wat het inspecteert: 32 KiB aan verzoekheaders, een pad van 2.048 bytes en een verzoekbody van 1 MiB. Dit zijn beveiligingslimieten, geen willekeurige prestatie-instellingen. Als een toepassing legitiem grotere verzoeken nodig heeft, verhoog dan de relevante limiet voor die toepassing en test het resultaat in plaats van de inspectie wereldwijd uit te schakelen.
DDoS-bescherming begint in de normale modus bij 600 verzoeken per minuut met een toegestane piek van 100 per clientsleutel. De client-status tabel is begrensd op 65.536 vermeldingen. Deze waarden zijn een basislijn, geen universeel verkeersmodel: een publieke API, een downloaddienst en een intern beheerpaneel zouden niet dezelfde applicatiespecifieke limieten moeten delen.
Browserbeveiligingen maken deel uit van de basislijn
Het response-headerbeleid van Webship is ingeschakeld, zelfs wanneer een applicatie vergeet zijn eigen toe te voegen. De standaard bevat:
- X-Content-Type-Options: nosniff;
- een frame-ontkenningsbeleid;
- Referrer-Policy: geen-referrer;
- Strict-Transport-Security voor één jaar, inclusief subdomeinen;
- Content-Security-Policy beperkt tot content van dezelfde oorsprong, met beperkingen voor framing en base-URI;
- Permissions-beleid die toegang tot geolocatie, microfoon en camera uitschakelt.
Deze standaardinstellingen zijn opzettelijk beperkend. Controleer HSTS voordat u het toepast op een domein met subdomeinen die niet volledig HTTPS-klaar zijn. Controleer Content-Security-Policy voordat een toepassing scripts, stijlen, lettertypen, afbeeldingen of verbindingen van andere bronnen laadt. Een veilige standaard zou zichtbaar moeten falen tijdens de implementatie, en niet stilletjes verzwakt worden in productie.
Optionele oppervlakken blijven gesloten
Webship maakt niet elke functie zichtbaar alleen omdat deze in de binary zit. Reverse proxying, WebTransport, observability-eindpunten, automatische TLS, response-provenance en het MCP-controle-eindpunt zijn standaard uitgeschakeld.
De MCP endpoint is loopback-gebonden wanneer ingeschakeld en vereist een expliciete beveiligingsconfiguratie. Metrics en statistieken vereisen dat instrumentatie bewust wordt ingeschakeld. Automatisch certificaatbeheer vereist dat de operator een ACME-directory, contacten, opslag en het accepteren van de gebruiksvoorwaarden kiest. Dit voorkomt dat operationele functies onverwachte netwerkoppervlakken worden.
De basisluisteraar bindt zich ook aan 127.0.0.1. Een operator moet expliciet een openbaar adres selecteren. Die ene keuze creëert een nuttig controlemoment voor firewallregels, servicepermissies, TLS-identiteit en implementatietopologie.
Reverse proxying behoudt de vertrouwensgrens
Wanneer reverse proxying is ingeschakeld, blijft TLS pass-through de standaard. Webship stuurt versleuteld verkeer door zonder bezit te nemen van de platte tekst van de applicatie of actieve sessiesleutels. De oorsprong blijft verantwoordelijk voor TLS en het onderhandelde protocol.
Schakel TLS-terminatie alleen in wanneer Webship HTTP-verzoeken moet inspecteren, routeren op pad, WAF- en API-beleid moet toepassen, headers moet herschrijven of antwoorden moet cachen. Terminatie is niet van nature minder veilig; het verplaatst de vertrouwensgrens. De belangrijke beslissing is welke machine de platte tekst mag zien en waarom.
Pass-through heeft ook functionele beperkingen. TCP-routing is gebaseerd op ClientHello SNI omdat het HTTP-verzoek is versleuteld. HTTP/3 pass-through vereist dat routes één UDP-origin delen. Als je inhoudsbewuste beveiliging aan de rand nodig hebt, beëindig TLS daar en bescherm het rand-naar-origin-pad afzonderlijk.
Een productiebaseline die je kunt beoordelen
Het volgende fragment maakt de belangrijke standaardinstellingen expliciet in plaats van te vertrouwen op weglating:
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=()"Op een multi-domeinlistener voorkomt unknown_sni = "reject" dat een onbekende hostnaam het standaardcertificaat van de listener ontvangt. De automatische-TLS-listeners van Webship weigeren al onbekende namen totdat er een certificaat bestaat.
Validatie is een beveiligingsmaatregel
Webship valideert de configuratie voordat het listeners koppelt. Onbekende velden, ongeldige limieten, onvolledige identiteiten, conflicterende listeners en niet-ondersteunde protocolcombinaties veroorzaken een specifieke fout bij het opstarten. Dezelfde validatie wordt uitgevoerd voordat een live-configuratie wordt geïnstalleerd. Een mislukte herlaadbeurt laat de huidige configuratie actief.
Het geverifieerde MCP configuratiepad voegt een extra beveiliging toe: het weigert live wijzigingen die een actieve WAF, DDoS-laag, API Shield, botuitdaging, edge-auth beleid of response-headerlaag zouden uitschakelen. Versiecontroles voorkomen dat een beheerder een nieuwere configuratiesnapshot overschrijft. Instellingen die aan een proces gebonden zijn, vereisen nog steeds een herstart in plaats van te doen alsof een gedeeltelijke live wijziging is geslaagd.
Dit is een nuttig onderscheid. Veilige standaardinstellingen beschermen een nieuwe implementatie. Transactionele validatie en afgeschermde updates beschermen een draaiende implementatie.
Welke operators nog moeten beslissen
Voordat u Webship aan het internet blootstelt:
- Configureer een vertrouwde TLS-identiteit en bescherm de privésleutel.
- Stel onbekende SNI-afhandeling in voor de luisteraartopologie.
- Bevestig dat HSTS en Content-Security-Policy overeenkomen met elke applicatie en subdomein.
- Definieer API Shield-eindpunten, geaccepteerde methoden, inhoudstypes en autorisatievereisten.
- Voeg routespecifieke snelheidslimieten toe in plaats van alleen te vertrouwen op de globale basislijn.
- Schakel edge-authenticatie in voor beschermde hosts of paden en gebruik kortlevende tokens.
- Houd MCP en observability-luisteraars privé, geauthenticeerd en gescheiden van openbaar verkeer.
- Voer Webship uit met een speciaal niet-privileged account, een read-only applicatieroot waar mogelijk, en alleen de besturingssysteemcapaciteiten die het nodig heeft.
- Valideer de configuratie voordat deze wordt uitgerold, test vervolgens geblokkeerd en toegestaan verkeer in een canary-omgeving.
- Houd beveiligingsauditgebeurtenissen in de gaten en oefen de overgang van de normale modus naar onder_aanval of lockdown.
Een veiliger standaard is een begin, geen bewering
Geen enkele webserver kan bepalen welke gebruikers je facturen mogen zien, welke herkomsten je API mogen aanroepen, of hoe snel je bedrijfsendpoint verzoeken moet accepteren. Die controles vereisen kennis van de applicatie.
Webship levert de onderste laag: begrensde parsers, strikte configuratie, defensieve response-headers, inspectie van verzoeken, misbruikcontroles en gesloten optionele oppervlakken. Het resultaat is geen “opgeloste beveiliging.” Het is een kleinere kloof tussen het installeren van een server en het verantwoordelijk bedienen ervan.
Bekijk de volledige Webship documentatie voordat u in productie gaat. Het configuratieschema en het draaiende binaire bestand blijven de gezaghebbende bronnen voor de exacte versie die u gebruikt.