Webship 工程

Webship 网络服务器：默认安全设置

Webship 默认启用其主要的 HTTP 防护、资源限制和响应保护，同时保持可选的控制界面私有或禁用。以下是基线和生产检查清单。

发表于 2026年9月10日

# Webship 网络服务器：默认安全设置

一个安全的网络服务器不应依赖操作人员在凌晨2点记住更多设置。它应该从一个保护基线开始，拒绝不安全的配置，并在暴露敏感功能之前要求做出谨慎的选择。

这就是 Webship 背后的模型。其默认配置会启用主要的请求和响应防护，限制攻击者可以消耗的资源，并保持可选控制面板处于禁用状态。你可以针对实际应用调整这些默认设置，但在第一个请求到来之前，你不必发现每一个防护措施。

默认安全并不意味着在没有上下文的情况下就安全。证书、应用程序授权、网络策略、秘密以及事件响应仍然属于操作员的责任。Webship 的工作是让安全的起点显而易见——并使意外削弱更困难。

启用时的保护

Webship 在其基本配置中启用六个层：

| 层 | 默认行为 | 它减少的内容 | | --- | --- | --- | | 点文件保护 | 拒绝以点开头的静态路径段 | 防止环境文件、仓库元数据和本地配置意外暴露 | | 网络应用防火墙 | 阻止已知攻击模式 | SQL 注入、跨站脚本攻击、遍历、敏感路径探测、命令注入、头部走私和不支持的请求编码 | | DDoS 控制 | 在正常模式下运行，客户端状态有界 | 请求泛滥、无限跟踪以及可避免的资源耗尽 | | 机器人挑战 | 使用签名的挑战 Cookie | 低成本的自动化滥用和重复扫描 | | 响应安全头 | 添加限制性的浏览器策略 | MIME混淆、框架、引用泄露、危险的浏览器功能以及广泛的内容加载 | | API 盾牌 | 一旦定义了 API 合同，使用阻止模式并拒绝未知路由 | 阴影端点、意外的方法、意外的内容类型以及缺失的授权要求 |

默认的 WAF 还会在其检测范围内设置硬性限制：32 KiB 的请求头、2,048 字节的路径，以及 1 MiB 的请求体。这些是安全限制，而不是任意的性能开关。如果某个应用程序确实需要更大的请求，请为该应用程序提高相关限制并测试结果，而不是全局禁用检测。

DDoS 保护在正常模式下从每分钟 600 个请求开始，每个客户端密钥允许突发 100 个请求。其客户端状态表限制为 65,536 条条目。这些值是基线，而不是通用流量模型：公共 API、下载服务和内部管理面板不应共享相同的应用程序特定限制。

浏览器保护是基础的一部分

Webship 的响应头策略即使在应用程序忘记添加自己的策略时也会启用。默认包括：

X-Content-Type-Options: nosniff;
禁止嵌入的策略；
引用来源策略: 无引用来源;
严格传输安全策略为一年，包括子域名；
内容安全策略仅限于同源内容，并带有框架和基本 URI 限制；
权限政策禁用地理定位、麦克风和摄像头访问。

这些默认设置是故意限制性的。在将 HSTS 应用于具有未完全支持 HTTPS 的子域的域之前，请进行审查。在应用程序从其他来源加载脚本、样式、字体、图像或连接之前，请审查内容安全策略（Content-Security-Policy）。安全的默认设置在部署期间应明显失败，而不是在生产中被悄悄削弱。

可选表面保持关闭

Webship 并不会因为二进制文件包含某功能就暴露该功能。反向代理、WebTransport、可观测性端点、自动 TLS、响应来源以及 MCP 控制端点默认都是禁用的。

MCP 端点在启用时是环回作用域的，并且需要明确的安全配置。指标和统计信息需要刻意启用仪表化。自动证书管理要求操作人员选择 ACME 目录、联系人、存储以及服务条款的接受。这可以防止操作功能变成意外的网络接口。

基础监听器也绑定到 127.0.0.1。操作员必须明确选择一个公共地址。这个单一的选择为防火墙规则、服务权限、TLS 身份和部署拓扑创建了一个有用的审查点。

反向代理可以保持信任边界

启用反向代理时，TLS 直通仍然是默认设置。Webship 转发加密流量而不获取应用程序明文或活动会话密钥。源服务器仍然负责 TLS 以及协商的协议。

仅当 Webship 必须检查 HTTP 请求、按路径路由、应用 WAF 和 API 策略、重写头信息或缓存响应时，才启用 TLS 终止。终止本身并不本质上不安全；它只是移动了信任边界。重要的决策是允许哪台机器查看明文以及原因。

直通功能也有其功能限制。由于 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 文档。配置架构和运行中的二进制文件仍然是您所使用版本的权威来源。