保护 Mordhau 服务器免受 DDoS 攻击

一台 Mordhau 服务器如果在 Frontline 局进行到一半时同时失去所有玩家，随后几分钟离线、并且从服务器列表里消失，问题很少出在硬件上。绝大多数情况下，是有人正在攻击一台 Mordhau 独立服务器必须对外开放的那四个 UDP 端口之一。本文先讲在 Mordhau 的 DDoS 防护上，您不花额外费用就能自己完成的部分，接着讲这些措施在物理上到哪里为止，最后讲服务器前面的网络里必须发生什么。

本文所有内容针对运行在 Debian 12、Debian 13、Ubuntu 22.04 LTS 或 Ubuntu 24.04 LTS 上的官方 Mordhau 独立服务器（Steam 应用编号 629800，Unreal Engine 4）。命令以 root 身份书写，普通用户请在前面加上 sudo。如果攻击正在进行，请先不要改动任何配置，也不要重启服务器，而是先保存测量数据（第 9 节），因为攻击结束后这些数据就没有了。在 Mordhau 上还多出第二个理由，很多运营者都是吃了亏才学到的：服务器进程在退出时会把内存里的状态写回 Game.ini。谁在服务器运行时编辑这个文件，下一次停止时就会丢掉自己的改动。

Mordhau 服务器为什么需要 DDoS 防护，以及谁在攻击它们

Mordhau 服务器之所以被攻击，是因为它们的地址是公开的、全部游戏流量都走 UDP，而且一次宕机立刻对所有人可见。服务器浏览器里的条目以明文包含 IP 地址和游戏端口，否则玩家就找不到这台服务器。公开的服务器列表和跟踪站点通过 Steam 查询端口抓取同样的数据，并把它们再公布一遍。因此您的地址不是秘密，而是一项产品说明。

再加上游戏本身的技术。Unreal Engine 4 通过 UDP 传输移动、命中和招架。UDP 没有可以强制要求的连接建立过程，而 UDP 数据包的源地址可以伪造。因此攻击者既不必进入您的服务器，也不必正确地跟它对话，就能制造负载。在 Mordhau 上这件事比在很多其他游戏里更要紧：一次交锋在零点几秒之间就分出胜负，仅仅多出 200 毫秒的延迟就会让近战变得不可玩，而这远在服务器真正宕机之前。正因如此，一次小规模攻击就足以毁掉一局。DDoS 攻击具体是什么，请看文章 什么是 DDoS 攻击？。

典型的导火索都很平常：社区之间的竞争、被封禁的玩家、输掉的决斗、Discord 里的争吵。攻击对下单的人来说既不需要什么本事，也花不了多少钱，因为租来的 booter 服务会把活干完。运营者经常反映，攻击恰好在服务器满员时开始，一旦服务器空了就停。这不是偶然，而是一个提示：有人在盯着您的服务器浏览器条目，并把玩家数当作触发条件。

Mordhau 上真正相关的那些端口

一台 Mordhau 独立服务器对外正好需要四个 UDP 端口：7777、7778、15000 和 27015。其余的要么是可选的，要么不该放在公网上。这些端口在启动时作为参数传入：

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

其中有两点经常被误解。第一：Beacon 端口 15000 不是附属品。Beacon 在玩家加入的那一刻预留槽位，使他在地图加载完之后不会又被挤出去。如果 15000 被封锁或者过载，玩家就进不来，尽管 7777 端口在回应。第二：RCON 在 Mordhau 上没有预先配置。它只有在您设置了 RconPassword 和 RconPort 之后才会启用，而且走的是 TCP，不是 UDP。

一台 Mordhau 服务器最重要的数据一览：

Mordhau 上会出现的攻击模式

四种模式基本涵盖了针对 Mordhau 服务器的所有手法，而且每一种都打在不同的端口上。

• 对游戏端口 7777 的 UDP 洪水攻击。这是 booter 的标准攻击：往服务器浏览器里写着的那个端口上尽可能多地发伪造数据包。它打的是带宽和数据包速率，而不是某个漏洞，最先表现为延迟尖峰，远在有人掉线之前。
• 对查询端口 27015 的查询洪水攻击。一次 A2S_INFO 查询是 25 字节，而带着服务器名称、地图、游戏模式和玩家数的回应是它的好几倍。攻击者因此投入很少，却在您这边强行制造计算工作和出方向流量。
• 通过您自己查询端口的反射攻击。这里您的服务器不是目标，而是工具：攻击者用伪造的源地址发送查询，您的服务器则回应给受害者。您注意到的现象是 27015 上无法解释的高出方向流量，以及主机商的滥用举报。
• 通过 Beacon 端口 15000 的连接和槽位耗尽。攻击者不烧带宽，而是用自动化的加入行为占满预留的槽位。服务器继续运行，但是满的，真正的玩家再也进不来。

一旦 RCON 开在公网上，还会多出第五种模式：每秒一次针对 RCON 端口的登录尝试。这很少是流量型的，但会消耗计算时间，而且这是五种情况里唯一一种一旦被打中，就会让您彻底失去服务器控制权的。

在花钱之前，您自己能做的事

这一节最长，而且是故意的。配置干净的 Mordhau 服务器能靠自己扛住小型和中型攻击，无论它放在谁那里。

1. 清点：服务器上到底有什么在监听？

在写下第一条防火墙规则之前，先看清楚您的服务器对外提供了什么。不要猜，要查：

ss -lntup

要看的是本地地址那一列。0.0.0.0:7777 和 [::]:7777 表示“整个互联网都能访问”，127.0.0.1:27020 表示“仅本机”，不需要防火墙规则。除了游戏之外，那里往往还会出现一个 Web 面板、一个数据库服务，以及一个早就被遗忘的语音服务。从外面扫一次就能看到攻击者眼中的样子，UDP 要配一份简短的端口清单，因为完整的 UDP 扫描非常慢：

nmap -Pn -sU -p 7777,7778,15000,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 只开放 Mordhau 真正需要的那四个端口

对 Mordhau 来说，对外四条 UDP 放行就够了，其余的要么受到限制，要么干脆不公布。用 UFW 的写法如下，而且顺序必须完全照此执行，以免把自己关在门外：

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau 游戏'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau Beacon'
ufw allow 27015/udp comment 'Mordhau Query'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

请把 203.0.113.10 换成您自己的地址。重要的是这里没有写什么：没有给 Web 面板的放行，没有给数据库的，也没有给文件服务器的。每一个额外开放的端口，都是一个与游戏无关的额外目标。包含自救办法的完整说明见 设置 UFW 防火墙而不把自己关在门外。

3. 限制查询端口 27015，又不从服务器列表里掉出去

查询端口您可以限制，但不能关闭。27015 UDP 一旦被堵死，您的 Mordhau 服务器就会从服务器浏览器里消失，因为玩家数、地图名称和服务器名称正是通过这个端口被读取的。按源地址设一个上限，既能解决问题，又不损失可见性：

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

正规的服务器浏览器每分钟查询您的服务器几次，而不是每秒几次。因此每个源地址每秒十次查询，对任何玩家都很宽裕，对任何机器人都很紧。之后请通过命中计数器检查这条规则到底有没有生效：

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

反射攻击的答案也在这里。在一次反射攻击中，您的服务器不是被攻击，而是被当作放大器滥用：查询带着伪造的源地址到来，而您的回应打中了别人。按源地址的速率限制是对此最有效的本地措施，因为伪造的源地址只有在您的服务器乐意且无限制地回应时才管用。

4. 把 RCON 从公网上撤下来

在 Mordhau 上，RCON 无论如何都不该不受限制地放到互联网上。这个入口在 Game.ini 的 [/Script/Mordhau.MordhauGameSession] 段里开启：

[/Script/Mordhau.MordhauGameSession]
ServerName=My Mordhau Server
MaxSlots=64
ServerPassword=
AdminPassword=YourLongRandomPassword
RconPassword=AnotherLongRandomPassword
RconPort=27020

Mordhau 说的是 Source RCON 协议，也就是走 TCP，因此能和任何常见的 RCON 工具配合。而那些逐个试用户名密码的脚本，用的正是这一点。三条规则覆盖了这种情况。第一：RconPassword 和 AdminPassword 是两个不同的、长的随机密码，而不是服务器名称的变体。第二：把 RCON 端口的放行限制到您自己的地址，就像上面 UFW 那段里那样。第三，如果您没有固定地址：让这个端口从外面保持关闭，通过 SSH 端口转发访问它，之后在本机连接 127.0.0.1:27020：

ssh -N -L 27020:127.0.0.1:27020 root@YOUR.SERVER.IP.ADDRESS

如果 RCON 仍然必须保持开放，那至少要限制每个源地址的并发连接数。一个 RCON 工具需要一条连接，一个暴力破解脚本需要几百条：

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. 保护 Beacon 端口 15000，抵挡连接洪水攻击

Beacon 端口是一台 Mordhau 服务器上被低估的攻击点。游戏通过它在玩家还在加载时预留其槽位。一个快速连续触发加入的机器人，就能借此占住槽位，却从不真正进入游戏。服务器保持在线，看上去却是满的。按源地址设一个上限就能挡住这种情况，因为真正的玩家每次加入只 beacon 一次，而不是每秒二十次：

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

第二条规则针对游戏端口，需要有分寸。在 Tickrate 为 60 时，服务器与每个已连接玩家在每个方向上交换约每秒 60 个数据包。因此每个源地址每秒 400 个数据包的阈值，给每个真实玩家留下了充足余量，同时仍能命中任何明显在灌包的来源。在设得更严之前，请先在正常运行状态下测一周：设得太严的人会把自己的玩家踢出去，然后还把这当成一次攻击。

纯 iptables 规则在重启后就没了。在 Debian 和 Ubuntu 下这样保存：

apt-get install -y iptables-persistent
netfilter-persistent save

在 UFW 下，这类规则应写进 /etc/ufw/before.rules，否则下一次 ufw reload 时就会消失。

6. Game.ini 和 Engine.ini：真正有用的部分

Mordhau 有两个配置文件，两个在 Linux 下都位于 Mordhau/Saved/Config/LinuxServer/，在 Windows 下位于 Mordhau\Saved\Config\WindowsServer\。Game.ini 管服务器名称、槽位、密码、管理员列表、地图轮换以及来自 mod.io 的 Mod 标识，Engine.ini 管网络行为。请只在服务器停止时编辑这两个文件，否则服务器进程在退出时会用内存里的状态覆盖您的改动。

有三项设置对攻击面是真正相关的。第一是 ServerPassword：它能挡住每一个没被邀请的人，但代价是失去公开的可发现性，而且对 7777 端口上的洪水攻击完全没用，因为攻击者根本不想加入。第二是一个现实的 MaxSlots 数值：Mordhau 的设计上限是 64 名玩家，而每一个额外的槽位都是一个额外的数据包来源，需要您的 CPU 去伺候。第三是 Engine.ini 里的 Tickrate：

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

一台 Mordhau 服务器的默认 Tickrate 是 60。提高到 120 会让每名玩家的数据包速率和 CPU 负载翻倍，而这恰恰是您在受攻击时最用不上的。一台 Tickrate 为 120 的 64 槽位服务器，在正常运行状态下每个方向就已经产生约每秒 8000 个数据包。长期被打的人，用 60 明显比用 120 更稳。

7. 给连接跟踪和接收缓冲区减压

一个常被忽视的瓶颈是内核的连接跟踪。它为每一条 UDP 流维护一个独立的条目，而一场来自数万个伪造源地址的洪水攻击，几秒钟就能把这张表填满。表一满，服务器连正常的数据包也会丢弃，日志里会出现“nf_conntrack: table full”。当前状态和上限用这条命令查看：

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

对此有两种办法。您可以提高上限，也可以把游戏端口完全从跟踪中排除。在游戏服务器上，后者通常是更好的路，因为 UDP 本来就没有需要跟踪的状态：

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

同样有意义的是更大的接收缓冲区和更深的网卡队列，让短时的尖峰不会立刻造成丢弃：

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

要长期生效，这些值应写进 /etc/sysctl.d/ 下的一个文件，例如 99-gameserver.conf。需要理解的一点是：更大的缓冲区不会提高您面对大型攻击的承受力，它们只是避免一次短暂的波动就已经造成丢包。

8. 您的地址就在服务器列表里，这一点改不了

这里实话比幻想更有用：一台公开 Mordhau 服务器的 IP 地址无法保密。它写在服务器浏览器条目里，写在第三方定期读取查询端口而得到的公开服务器列表里，而且每一个连接过一次的玩家都知道它。因此换地址只能争取几个小时，很少能争取到几天，因为攻击者找到新地址的途径和找到旧地址的途径完全一样。

真正有效的是三个习惯。不要自己在任何地方公布裸 IP 地址，也就是不要发在 Discord 频道里，也不要放在项目页面上。让您的玩家通过一个主机名连接，这样万一要换地址，也不会把所有的指向都弄断。还要清掉旧的 DNS 记录，因为一条指向上一个地址、被遗忘的 A 记录会让任何更换都失去意义。测试服务器也一样：同一台机器上任何可以从公网访问的第二台服务器，都会泄露主服务器的地址。

9. 在一切正常的时候测量

最重要的一步是几乎没人事先做的那一步：在服务器平稳运行时先建立基线。没有正常值，事后您就说不清每秒 4 万个数据包是很多，还是就是个普通的周六晚上。用 apt-get install -y vnstat sysstat 让测量常驻运行。事件发生时四条命令就够了：

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -c 200 -q

用 tcpdump 时有一条铁律：一定要用 -c 限制数量，因为满载状态下抓包会让本来已经过载的服务器更吃力。请特别留意 ip -s link 里的丢包计数器。dropped 数值在上升而 CPU 同时很平静，是“问题在数据包速率而不在计算能力”的最明确提示。如何解读这些数值，见 识别 DDoS 攻击。如何用 SteamCMD 干净地搭起服务器并保持它最新，见 用 SteamCMD 安装游戏服务器。

这些措施到哪里为止：带宽和数据包速率

现在说没有任何配置文件能解决的那一部分。前面所有措施都跑在您的服务器上，也就是线路的末端。防火墙规则处理的是已经跑过网线的数据包。您可以把它丢弃，但没法让它没被发出来。

算一下就清楚了。典型的游戏服务器挂在 1 Gbit/s 上，也就是每秒 125 兆字节，只要有人发得比这更多，线路就满了。一台满员的 64 槽位 Mordhau 服务器只用得上其中一小部分：在 Tickrate 为 60 时，游戏流量约为每个方向每秒 4000 个数据包。而一个租来的 booter 轻松就能提供 5 到 50 Gbit/s，也就是您线路的五到五十倍。这时您后面的 iptables 规则写得多好都不再重要，因为您玩家的数据包在更早的地方就已经过不来了。

第二个量是数据包速率，而它往往比带宽先出事。在 64 字节的小包情况下，一条 1 Gbit/s 的线路里能装进每秒约 149 万个数据包。普通的服务器内核视 CPU 和网卡而定，处理其中几十万个之后就会开始丢包。因此一场连您线路三分之一都填不满的攻击，仍然可能让您的 Mordhau 服务器瘫痪，因为计算时间全花在丢弃上。运营者的体验是“负载根本不高，可是什么都没了”。

为了说明现实中会出现什么量级：在 KernelHost 的服务器上，曾经过滤过对一台语音服务器超过 473.4 Gbit/s、每秒超过 4150 万个数据包的攻击，以及对一台游戏服务器超过 112.2 Gbit/s 的 UDP 洪水攻击。对此没有任何本地设置可用。流量型攻击必须在服务器前面的网络里就被终结。

KernelHost 用什么来应对

每台服务器都标配的持续防护

KernelHost 的 DDoS 防护分两级，持续生效，您不需要开启、订购或配置任何东西：

• 第 1 级：全球清洗网络中 17 Tbps 的清洗能力。流量型攻击在靠近来源的地方就被清洗掉，不会到达数据中心。
• 第 2 级：法兰克福的 Arbor 实时过滤，容量 3.2 Tbps。就在服务器前面，逐个数据包地识别并丢弃与协议相关的攻击特征。

有两点是关键。防护持续运行，不需要先对攻击做出反应，所以开头不会有服务器失联的那几分钟。而且不使用黑洞路由：您的 IP 地址留在网络里，被丢弃的只有恶意数据包。把 IP 地址从网络里撤下来的做法，对您而言和攻击者达到的结果一样。地点是法兰克福。哪些游戏和协议在覆盖范围内，见 实时游戏服务器 DDoS 防护。

针对长期被攻击的 Mordhau 服务器的 Advanced DDoS Protection

有些服务器不是偶尔被打，而是被有针对性地连打几周。为此有 Advanced DDoS Protection，每月 50.00 欧元起，PrePaid 预付费，没有最低合约期，也没有开通费。区别不在于容量更大，而在于控制权：

• 专用防护 IP，来自法兰克福的核心网络，您的服务器会在我们自己的网络内切换到它。您这边不需要做任何改造。
• 按端口和协议自行管理的防护规则，就在客户中心里：您可以分别规定 7777 UDP 上允许什么、15000 UDP 上允许什么、27015 UDP 上允许什么，而不必为此写工单。
• 改动实时生效，因此您可以在攻击进行时随时调整，而不用等维护窗口。
• 与游戏匹配的防护策略。UDP 上的 Unreal Engine 游戏服务器和 Steam 查询端口有现成的策略，任意 TCP 或 UDP 端口上经过修改的程序和自研程序同样有。

Advanced DDoS Protection 面向运行在 KernelHost 的服务器。如果您的 Mordhau 服务器目前放在别处，而且经常被打下线，那么迁移就是通往这套过滤的路。

两级防护对比

对大多数 Mordhau 服务器来说，标配的持续防护配上干净的配置就够了。Advanced DDoS Protection 针对的是有人把这件事当成私人恩怨的情况。

常见错误及解决办法

“我把 27015 端口堵死了，现在我的服务器不在列表里了”：这是可以预料的结果。Steam 查询端口向服务器浏览器提供名称、地图和玩家数。没有它，您的服务器就不再出现，或者被标为无法访问。正确的做法是按源地址限速，而不是封禁。

“服务器在跑，可玩家进不来”：请先检查 15000 UDP。Beacon 在加载期间预留槽位。如果它被封锁、被过滤得太严或者过载，加入就会卡住，尽管 7777 端口在回应、服务器也显示在浏览器里。

“我在 Game.ini 里的改动重启之后又没了”：您是在服务器运行时编辑了这个文件。Mordhau 服务器进程在退出时会把内存里的状态写回去，从而覆盖您的版本。停止服务器、编辑、启动，就按这个顺序。

“我的 iptables 规则不起作用”：常见原因有三个。规则排在 UFW 的链后面，永远轮不到它；规则在上次重启后就没了（这时用 netfilter-persistent save，或者写进 /etc/ufw/before.rules）；或者攻击是流量型的，而规则在一条早就满了的线路上正常工作。用 iptables -L INPUT -n -v 检查命中计数器是否在增长。如果一直是零，说明规则没有被匹配到。

“服务器在跑，可所有人都有延迟尖峰，命中也慢半拍”：请先看入方向数据包速率是否在上升，而 CPU 仍然平静。这正是一次攻击的典型画面。如果数据包速率正常而 CPU 停在 100%，那就不是 DDoS 攻击，多半是 Tickrate 设得太高、槽位太多，或者某个 Mod。

“我的主机商举报 27015 端口有出方向滥用”：您的服务器被当作反射攻击的放大器滥用了。查询带着伪造的源地址到来，而您的服务器回应给了别人。对 27015 UDP 按源地址做速率限制就能终止这件事。

“我原来的主机商把我的 IP 地址封了”：那就是黑洞路由。主机商用它保护自己的网络，对您来说结果和一次成功的攻击完全一样，而且通常在攻击结束后还要持续几个小时。有疑问时请直接问清楚：是过滤还是黑洞路由。这个答案对您可用性的影响，比任何硬件参数都大。

“我在 tcpdump 里看不到任何异常”：如果流量已经在前面的网络里被过滤掉了，服务器上当然就什么都收不到。这在过滤正常工作时是常态。反过来说：线路一旦被打满，您甚至可能连用来测量的那条 SSH 会话都进不来。这时请使用客户中心里的 VNC 控制台，它独立于虚拟机自身的网络运行。

要点总结

• 一台 Mordhau 独立服务器对外正好需要四个 UDP 端口：7777（游戏）、7778（Steam）、15000（Beacon）和 27015（Steam 查询）。其余都应关闭。
• Mordhau 的 RCON 按 Source RCON 协议走 TCP，只有在 Game.ini 里设置了 RconPassword 和 RconPort 之后才会启用。请把这个端口限制到您自己的地址。
• 27015 UDP 您可以限制，但不能关闭：没有它，您的服务器就会从服务器浏览器里消失，因为玩家数、地图和名称都是通过这个端口查询的。
• 15000 UDP 是 Beacon 端口，在加载期间预留槽位。它被封锁或过载时，玩家就进不来，尽管服务器在跑。
• 只在服务器停止时编辑 Game.ini 和 Engine.ini，因为服务器进程在退出时会把内存里的状态写回去。
• 本地防火墙规则止于带宽：1 Gbit/s 是每秒 125 兆字节，在 64 字节包大小时约为每秒 149 万个数据包。超过这个量，就只有服务器前面的网络说得上话。
• 在 KernelHost，两级持续防护包含在每个服务器套餐中，不额外收费，自服务器开通起即生效，并且不使用黑洞路由。想自己掌控过滤的人，可以通过每月 50.00 欧元起的 Advanced DDoS Protection 获得。

如果您的 Mordhau 服务器已经放在 KernelHost，过滤就已经在工作，您什么都不用做。若仍然发现异常，请开一个 支持工单，以便为您的 IP 地址调整过滤规则。攻击正在进行时，您还可以通过 WhatsApp 紧急聊天联系我们：+43 650 8209883。