Webship 工程

Webship 網頁伺服器：預設安全設定

Webship 預設啟用其主要的 HTTP 防護、資源限制和回應保護，同時保持可選的控制界面私密或停用。以下是基線以及生產檢查清單。

發佈於 2026年9月10日

# Webship 網頁伺服器：預設安全設定

一個安全的網頁伺服器不應該依賴操作員在凌晨兩點還記得多一項設定。它應該從保護性的基線開始，拒絕不安全的配置，並在暴露敏感功能之前要求作出謹慎的選擇。

那是 Webship 背後的模型。它的預設配置會啟用主要的請求與回應防禦，限制攻擊者可以消耗的資源，並將可選的控制介面保持禁用。你可以為真正的應用程式調整這些預設值，但你不必在第一個請求到達之前就發現每一項防護措施。

預設安全並不意味著在沒有上下文的情況下就是安全的。憑證、應用程式授權、網路策略、機密資訊以及事件回應仍然屬於操作人員的責任。Webship 的工作是讓安全的起點變得明顯——並使意外削弱變得更困難。

啟用的保護措施

Webship 在其基本配置中啟用了六個層級：

| 層 | 預設行為 | 它減少的內容 | | --- | --- | --- | | 點檔保護 | 拒絕以點開頭的靜態路徑段 | 避免環境檔案、程式庫元資料及本地設定被意外暴露 | | 網頁應用防火牆 | 阻擋已知攻擊模式 | SQL 注入、跨站指令碼攻擊、遍歷、敏感路徑探測、命令注入、標頭走私，以及不支援的請求編碼 | | DDoS 控制 | 以正常模式運行並具有受限的客戶端狀態 | 請求洪水、無限制的追蹤，以及可避免的資源耗盡 | | 機器人挑戰 | 使用已簽署的挑戰 Cookie | 低成本自動濫用和重複掃描 | |回應安全標頭 |新增限制性瀏覽器政策 |MIME 混淆、框架、引薦外洩、危險瀏覽器功能及廣泛內容載入 | | API Shield | 使用封鎖模式，並在 API 合約定義後拒絕未知路由 | 隱藏端點、未預期的方法、意外的內容類型，以及缺失的授權要求 |

預設的 WAF 也會對其檢查範圍設置硬性限制：32 KiB 的請求標頭、2,048 字節的路徑，以及 1 MiB 的請求主體。這些是安全限制，而非隨意的性能開關。如果應用程式確實需要更大的請求，請提高該應用程式的相關限制並測試結果，而不是全域禁用檢查。

DDoS 保護在正常模式下從每分鐘 600 個請求開始，並且每個客戶端金鑰允許突發 100 個請求。其客戶端狀態表限制為 65,536 個條目。這些數值是基線，而不是通用的流量模型：公共 API、下載服務和內部管理面板不應使用相同的應用程式專用限制。

瀏覽器保護是基本標準的一部分

Webship 的響應標頭政策即使在應用程式忘記添加自身標頭時也會啟用。預設包含：

X-Content-Type-Options: nosniff;
框架拒絕策略；
引用者政策：不提供引用者
對一年內的嚴格傳輸安全，包括子域名；
內容安全政策限制於同源內容，並設有框架和基本 URI 限制；
權限政策禁用地理定位、麥克風和攝像頭訪問。

這些預設值是故意設置的限制。將 HSTS 套用到尚未完全支持 HTTPS 的子域時，請先審查 HSTS。在應用程式載入來自其他來源的腳本、樣式、字體、圖片或連線之前，請先審查內容安全政策（Content-Security-Policy）。安全的預設值應在部署期間明顯失敗，而不是在生產環境中被悄悄削弱。

可選的表面保持關閉

Webship 並不會因為二進位檔包含某功能就將其全部公開。反向代理、WebTransport、可觀測性端點、自動 TLS、回應來源，以及 MCP 控制端點預設皆為停用。

MCP 端點在啟用時是迴圈回送範圍，並且需要明確的安全配置。指標和統計數據需要刻意啟用儀表配置。自動憑證管理要求操作人員選擇 ACME 目錄、聯絡方式、存儲以及服務條款的接受。這可以防止操作性功能意外成為網路暴露面。

基本監聽器也綁定到 127.0.0.1。操作員必須明確選擇一個公共地址。這個單一選擇為防火牆規則、服務權限、TLS 身份以及部署拓撲創建了一個有用的檢查點。

反向代理保留了信任邊界

當啟用反向代理時，TLS 直通仍然是預設值。Webship 會轉發加密流量，而不取得應用程式明文或活躍的會話金鑰。來源端仍然負責 TLS 和協商的協議。

僅在 Webship 必須檢查 HTTP 請求、按路徑路由、應用 WAF 和 API 政策、重寫標頭或緩存響應時啟用 TLS 終止。終止本身並不天然不安全；它只是移動了信任邊界。重要的決策是允許哪台機器看到明文以及原因。

直通（Pass-through）也有功能上的限制。由於 HTTP 請求是加密的，TCP 路由是基於 ClientHello SNI。HTTP/3 直通要求路由必須共享一個 UDP 來源。如果您需要在邊緣進行內容感知的安全防護，請在那裡終止 TLS，並單獨保護邊緣到來源的傳輸。

您可以審查的生產基準

以下摘錄明確指出了重要的預設值，而不是依賴省略：

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=()"

在多域監聽器上，unknown_sni = "reject" 可以防止未識別的主機名接收監聽器的預設證書。Webship 的自動 TLS 監聽器在證書存在之前，已經會拒絕未知的名稱。

驗證是一種安全控制

Webship 在綁定監聽器之前會驗證配置。未知欄位、無效限制、不完整的身份、衝突的監聽器以及不支援的協議組合會導致啟動失敗並出現特定錯誤。相同的驗證會在安裝即時配置之前執行。重新載入失敗時，當前配置會保持啟用狀態。

經驗證的 MCP 配置路徑增加了另一層防護：它拒絕會停用已啟用的 WAF、DDoS 層、API Shield、機器人挑戰、邊緣認證策略或響應標頭層的即時更改。版本檢查可防止一名管理員覆寫較新的配置快照。與流程綁定的設置仍然需要重啟，而不是假裝部分即時更改已成功。

這是一個有用的區分。安全的預設值保護新的部署。交易驗證和受保護的更新則保護正在運行的部署。

哪些操作員仍需要決定

在將 Webship 暴露於互聯網之前：

配置受信任的 TLS 身份並保護私鑰。
為監聽器拓撲設定未知的 SNI 處理方式。
確認 HSTS 和內容安全策略（Content-Security-Policy）與每個應用程式及子網域相符。
定義 API Shield 端點、接受的方法、內容類型以及授權需求。
新增路由特定的速率限制，而不是僅依賴全局基準。
為受保護的主機或路徑啟用邊緣驗證，並使用短期有效的令牌。
保持MCP與可觀察性聽聽者的隱私、認證，並與公開流量分開。
使用專用的無特權帳戶運行 Webship，在可能的情況下使用唯讀的應用程式根目錄，並僅使用其所需的操作系統功能。
在部署前驗證配置，然後在金絲雀環境中測試被阻擋和允許的流量。
監控安全審計事件，並演練從正常模式切換到受攻擊或鎖定模式。

一個更安全的預設值是一個開始，而不是一個主張

沒有任何網頁伺服器可以決定哪些使用者應該看到你的發票，哪些來源可以調用你的 API，或者你的業務端點應該以多快的速度接受請求。這些控制需要應用程式知識。

Webship 提供了底層功能：受限的解析器、嚴格的配置、防禦性回應標頭、請求檢查、濫用控制以及封閉的可選介面。結果不是「安全問題已解決」。它只是縮小了從安裝伺服器到負責任運作之間的差距。

在正式部署之前，請先完整閱讀 Webship 文件。配置架構與運行中的二進位檔仍是您所使用的確切版本的權威來源。