# Webship Webserver: Standardmäßig sichere Einstellungen
Ein sicherer Webserver sollte nicht davon abhängen, dass ein Betreiber um 2 Uhr morgens noch eine Einstellung erinnert. Er sollte von einer schützenden Grundeinstellung ausgehen, unsichere Konfigurationen ablehnen und bewusste Entscheidungen verlangen, bevor er sensible Funktionen freigibt.
Das ist das Modell hinter Webship. Seine Standardkonfiguration aktiviert die Hauptverteidigungen für Anfragen und Antworten, begrenzt die Ressourcen, die ein Angreifer verbrauchen kann, und lässt optionale Kontrollflächen deaktiviert. Sie können diese Standardwerte für eine echte Anwendung anpassen, aber Sie müssen nicht jede Schutzmaßnahme entdecken, bevor die erste Anfrage eingeht.
Sicher per Voreinstellung bedeutet nicht sicher ohne Kontext. Zertifikate, Anwendungsautorisierung, Netzwerkrichtlinien, Geheimnisse und Vorfallsreaktionen gehören weiterhin dem Betreiber. Die Aufgabe von Webship ist es, den sicheren Ausgangspunkt offensichtlich zu machen und versehentliches Schwächen zu erschweren.
Die Schutzfunktionen, die aktiviert starten
Webship aktiviert in seiner Basiskonfiguration sechs Schichten:
| Schicht | Standardverhalten | Was es reduziert | | --- | --- | --- | | Dot-Datei-Schutz | Verweigert statische Pfadsegmente, die mit einem Punkt beginnen | Verhindert versehentliche Offenlegung von Umgebungsdateien, Repository-Metadaten und lokaler Konfiguration | | Webanwendungs-Firewall | Blockiert bekannte Angriffsmuster | SQL-Injektion, Cross-Site-Scripting, Traversal, Abfragen nach sensiblen Pfaden, Befehlsinjektion, Header-Smuggling und nicht unterstützte Anfragecodierungen | | DDoS-Kontrollen | Läuft im Normalmodus mit begrenztem Client-Zustand | Anfragenfluten, unbegrenzte Überwachung und vermeidbare Ressourcenauslastung | | Bot-Herausforderung | Verwendet ein signiertes Challenge-Cookie | Günstiger automatisierter Missbrauch und wiederholtes Scannen | | Antwort-Sicherheitsheader | Fügt eine restriktive Browser-Richtlinie hinzu | MIME-Verwirrung, Einrahmung, Referrer-Leckage, gefährliche Browser-Fähigkeiten und umfassendes Laden von Inhalten | | API-Schutz | Verwendet den Blockmodus und lehnt unbekannte Routen ab, sobald ein API-Vertrag definiert ist | Schatten-Endpunkte, unbeabsichtigte Methoden, unerwartete Inhaltstypen und fehlende Autorisierungsanforderungen |
Die standardmäßige WAF setzt auch feste Grenzen dafür, was sie überprüft: 32 KiB an Anfrage-Headern, einen 2.048-Byte-Pfad und einen 1 MiB großen Anfragekörper. Dies sind Sicherheitsgrenzen, keine willkürlichen Leistungsschalter. Wenn eine Anwendung legitimerweise größere Anfragen benötigt, erhöhen Sie die entsprechende Grenze für diese Anwendung und testen Sie das Ergebnis, anstatt die Überprüfung global zu deaktivieren.
Der DDoS-Schutz beginnt im Normalmodus bei 600 Anfragen pro Minute mit einer Burst-Erlaubnis von 100 pro Client-Schlüssel. Die Client-Zustandstabelle ist auf 65.536 Einträge begrenzt. Diese Werte sind ein Ausgangspunkt, kein universelles Verkehrsmodell: Eine öffentliche API, ein Download-Dienst und ein internes Admin-Panel sollten nicht die gleichen anwendungsspezifischen Limits teilen.
Browser-Schutzmaßnahmen sind Teil der Basis
Die Antwort-Header-Richtlinie von Webship ist aktiviert, selbst wenn eine Anwendung vergisst, ihre eigene hinzuzufügen. Die Standardrichtlinie umfasst:
- X-Content-Type-Options: nosniff;
- eine Frame-Deny-Richtlinie;
- Referrer-Richtlinie: kein-Referrer;
- Strict-Transport-Security für ein Jahr, einschließlich Subdomains;
- Content-Security-Policy auf Inhalte derselben Herkunft beschränkt, mit Einschränkungen für Framing und Basis-URI;
- Berechtigungsrichtlinie, die den Zugriff auf Geolocation, Mikrofon und Kamera deaktiviert.
Diese Voreinstellungen sind absichtlich restriktiv. Überprüfen Sie HSTS, bevor Sie es auf eine Domain mit Subdomains anwenden, die nicht vollständig HTTPS-fähig sind. Überprüfen Sie die Content-Security-Policy, bevor eine Anwendung Skripte, Styles, Schriftarten, Bilder oder Verbindungen von anderen Ursprüngen lädt. Eine sichere Voreinstellung sollte während der Bereitstellung sichtbar fehlschlagen und nicht stillschweigend in der Produktion abgeschwächt werden.
Optionale Oberflächen bleiben geschlossen
Webship stellt nicht jede Funktion zur Verfügung, nur weil sie im Binärprogramm enthalten ist. Reverse-Proxying, WebTransport, Überwachungsendpunkte, automatische TLS, Antwortherkunft und der MCP-Steuerendpunkt sind standardmäßig deaktiviert.
Der MCP Endpunkt ist beim Aktivieren auf Loopback beschränkt und erfordert eine explizite Sicherheitskonfiguration. Metriken und Statistiken erfordern, dass die Instrumentierung bewusst aktiviert wird. Die automatische Zertifikatsverwaltung erfordert, dass der Betreiber ein ACME-Verzeichnis, Kontakte, Speicher und die Annahme der Nutzungsbedingungen auswählt. Dies verhindert, dass betriebliche Funktionen zu unerwarteten Netzwerkschnittstellen werden.
Der Basis-Listener bindet sich ebenfalls an 127.0.0.1. Ein Betreiber muss explizit eine öffentliche Adresse auswählen. Diese einzelne Wahl schafft einen nützlichen Überprüfungspunkt für Firewall-Regeln, Dienstberechtigungen, TLS-Identität und Bereitstellungstopologie.
Reverse-Proxying bewahrt die Vertrauensgrenze
Wenn Reverse-Proxying aktiviert ist, bleibt die TLS-Durchleitung die Standardeinstellung. Webship leitet verschlüsselten Datenverkehr weiter, ohne den Klartext der Anwendung oder aktive Sitzungsschlüssel zu übernehmen. Der Ursprung bleibt für TLS und das ausgehandelte Protokoll verantwortlich.
Aktivieren Sie die TLS-Beendigung nur, wenn Webship HTTP-Anfragen inspizieren, nach Pfad routen, WAF- und API-Richtlinien anwenden, Header umschreiben oder Antworten zwischenspeichern muss. Die Beendigung ist von sich aus nicht weniger sicher; sie verschiebt die Vertrauensgrenze. Die wichtige Entscheidung ist, welche Maschine den Klartext sehen darf und warum.
Durchleitung hat auch funktionale Grenzen. Das TCP-Routing basiert auf ClientHello SNI, weil die HTTP-Anfrage verschlüsselt ist. HTTP/3 Durchleitung erfordert, dass Routen einen UDP-Ursprung gemeinsam nutzen. Wenn Sie inhaltssensitive Sicherheit am Rand benötigen, beenden Sie TLS dort und schützen Sie den Hop vom Rand zum Ursprung separat.
Eine Produktionsgrundlinie, die Sie überprüfen können
Der folgende Auszug macht die wichtigen Standardwerte explizit, anstatt sich auf das Weglassen zu verlassen:
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=()"Bei einem Multi-Domain-Listener verhindert unknown_sni = "reject", dass ein nicht erkannter Hostname das Standardzertifikat des Listeners erhält. Automatische-TLS-Listener von Webship lehnen unbekannte Namen bereits ab, bis ein Zertifikat vorhanden ist.
Validierung ist eine Sicherheitskontrolle
Webship überprüft die Konfiguration, bevor es Listener bindet. Unbekannte Felder, ungültige Limits, unvollständige Identitäten, widersprüchliche Listener und nicht unterstützte Protokollkombinationen führen beim Start zu einem spezifischen Fehler. Dieselbe Überprüfung wird durchgeführt, bevor eine aktive Konfiguration installiert wird. Ein fehlgeschlagenes Neuladen lässt die aktuelle Konfiguration aktiv.
Der authentifizierte MCP-Konfigurationspfad fügt eine weitere Schutzmaßnahme hinzu: Er verweigert Live-Änderungen, die eine aktive WAF, DDoS-Schicht, API Shield, Bot-Challenge, Edge-Auth-Richtlinie oder Response-Header-Schicht deaktivieren würden. Versionsprüfungen verhindern, dass ein Administrator eine neuere Konfigurationsaufnahme überschreibt. Prozessgebundene Einstellungen erfordern weiterhin einen Neustart, anstatt so zu tun, als ob eine teilweise Live-Änderung erfolgreich war.
Dies ist eine nützliche Unterscheidung. Sichere Voreinstellungen schützen eine neue Bereitstellung. Transaktionale Validierung und geschützte Aktualisierungen schützen eine laufende.
Welche Betreiber noch entscheiden müssen
Bevor Sie Webship dem Internet aussetzen:
- Konfigurieren Sie eine vertrauenswürdige TLS-Identität und schützen Sie den privaten Schlüssel.
- Unbekannte SNI-Behandlung für die Listener-Topologie festlegen.
- Bestätigen Sie, dass HSTS und Content-Security-Policy mit jeder Anwendung und jeder Subdomain übereinstimmen.
- Definieren Sie API-Shield-Endpunkte, akzeptierte Methoden, Inhaltstypen und Autorisierungsanforderungen.
- Fügen Sie routenspezifische Ratenbegrenzungen hinzu, anstatt sich nur auf die globale Baseline zu verlassen.
- Aktivieren Sie die Edge-Authentifizierung für geschützte Hosts oder Pfade und verwenden Sie kurzlebige Token.
- Halten Sie MCP und Beobachtbarkeits-Listener privat, authentifiziert und getrennt vom öffentlichen Verkehr.
- Führen Sie Webship mit einem dedizierten unprivilegierten Konto, einem schreibgeschützten Anwendungsstamm, wo möglich, und nur mit den Betriebssystemfähigkeiten aus, die es benötigt.
- Überprüfen Sie die Konfiguration vor dem Rollout und testen Sie dann blockierten und erlaubten Datenverkehr in einer Canary-Umgebung.
- Überwachen Sie Sicherheitsprüfereignisse und üben Sie den Wechsel vom Normalmodus in den Modus unter Angriff oder Sperrung.
Ein sichereres Standard ist ein Anfang, keine Behauptung
Kein Webserver kann entscheiden, welche Benutzer Ihre Rechnungen sehen sollen, welche Ursprünge Ihre API aufrufen dürfen oder wie schnell Ihr Geschäfts-Endpunkt Anfragen akzeptieren soll. Diese Kontrollen erfordern Kenntnis der Anwendung.
Webship liefert die untere Schicht: begrenzte Parser, strenge Konfiguration, defensive Antwort-Header, Anforderungsüberprüfung, Missbrauchskontrollen und geschlossene optionale Oberflächen. Das Ergebnis ist nicht „Sicherheit gelöst“. Es ist eine kleinere Lücke zwischen der Installation eines Servers und dessen verantwortungsbewusster Bedienung.
Überprüfen Sie die vollständige Webship Dokumentation vor der Produktionsbereitstellung. Das Konfigurationsschema und die laufbare Binärdatei bleiben die maßgeblichen Quellen für die genaue Version, die Sie betreiben.