Mordhau 서버를 DDoS 공격으로부터 방어하기

Frontline 라운드 도중에 모든 플레이어를 한꺼번에 잃고, 그 뒤 몇 분 동안 오프라인이 되어 서버 목록에도 나타나지 않는 Mordhau 서버는 하드웨어 문제인 경우가 드뭅니다. 거의 모든 경우, Mordhau 전용 서버가 외부로 열어 두어야 하는 네 개의 UDP 포트 가운데 하나를 노린 공격이 진행 중입니다. 이 글은 먼저 Mordhau DDoS 방어에서 추가 비용 없이 직접 처리할 수 있는 것을 보여 주고, 그다음 그 조치가 물리적으로 어디에서 한계에 이르는지, 마지막으로 서버 앞단 네트워크에서 무엇이 이뤄져야 하는지 설명합니다.

모든 내용은 Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 운영하는 공식 Mordhau 전용 서버(Steam 앱 ID 629800, Unreal Engine 4)를 기준으로 합니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요. 공격이 지금 진행 중이라면 설정을 먼저 바꾸지 마시고 서버를 재시작하지도 마시고, 측정값부터 확보하세요(9번 절). 공격이 끝나면 그 값은 사라집니다. Mordhau에는 많은 운영자가 아프게 배우는 두 번째 이유가 더 있습니다. 서버 프로세스는 종료할 때 메모리에 있던 상태를 Game.ini로 다시 써 넣습니다. 서버가 돌아가는 중에 이 파일을 편집하면 다음 정지 때 변경 내용을 잃습니다.

Mordhau 서버에 DDoS 방어가 필요한 이유와 공격하는 쪽

Mordhau 서버가 공격받는 이유는 주소가 공개되어 있고, 게임 트래픽 전체가 UDP로 흐르며, 장애가 즉시 모두에게 보이기 때문입니다. 서버 브라우저 항목에는 IP 주소와 게임 포트가 평문으로 들어 있습니다. 그러지 않으면 플레이어가 서버를 찾을 수 없기 때문입니다. 공개 서버 목록과 트래커는 같은 데이터를 Steam 쿼리 포트로 가져가 두 번째로 공개합니다. 따라서 여러분의 주소는 비밀이 아니라 제품 정보입니다.

여기에 게임의 기술이 더해집니다. Unreal Engine 4는 이동, 타격, 패링을 UDP로 전송합니다. UDP에는 요구할 수 있는 연결 수립 절차가 없고, UDP 패킷의 출발지 주소는 위조할 수 있습니다. 그래서 공격자는 부하를 만들기 위해 여러분의 서버에 들어올 필요도, 규격에 맞게 말을 걸 필요도 없습니다. Mordhau에서는 이것이 다른 많은 게임보다 더 무겁게 작용합니다. 공방은 0.1초 단위에서 승부가 갈리고, 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

여기서 두 가지가 자주 잘못 이해됩니다. 첫째, 비컨 포트 15000은 곁다리가 아닙니다. 비컨은 플레이어가 접속하는 순간에 슬롯을 예약해서, 맵을 다 불러온 뒤에 다시 튕겨 나가지 않게 해 줍니다. 15000이 막혀 있거나 과부하 상태면 포트 7777이 응답해도 플레이어가 더 이상 들어오지 못합니다. 둘째, Mordhau에서 RCON은 미리 설정되어 있지 않습니다. RconPassword와 RconPort를 설정해야 비로소 켜지고, 그러면 UDP가 아니라 TCP로 동작합니다.

Mordhau 서버의 핵심 수치를 한눈에 보면 다음과 같습니다.

Mordhau에서 나타나는 공격 양상

Mordhau 서버를 겨냥해 실행되는 공격은 네 가지 양상으로 사실상 모두 설명되며, 각각 다른 포트를 때립니다.

• 게임 포트 7777을 향한 UDP 플러드. booter의 표준 공격입니다. 서버 브라우저에 적힌 포트로 위조된 패킷을 되도록 많이 보냅니다. 취약점이 아니라 대역폭과 패킷 전송률을 노리며, 누군가 연결을 잃기 훨씬 전에 먼저 랙 스파이크로 나타납니다.
• 쿼리 포트 27015를 향한 쿼리 플러드. A2S_INFO 조회는 25 바이트이고, 서버 이름, 맵, 게임 모드, 플레이어 수가 담긴 응답은 그 몇 배입니다. 공격자는 적게 투입하고 여러분에게 연산 작업과 송신 트래픽을 강요합니다.
• 여러분의 쿼리 포트를 거치는 반사 공격. 여기서 여러분의 서버는 표적이 아니라 도구입니다. 공격자가 출발지 주소를 위조한 조회를 보내면 여러분의 서버가 피해자에게 응답합니다. 여러분은 이것을 27015의 설명할 수 없이 높은 송신 트래픽과 업체의 어뷰즈 신고로 알아차립니다.
• 비컨 포트 15000을 통한 접속 플러드와 슬롯 고갈. 대역폭을 태우는 대신, 자동화된 접속이 예약된 슬롯을 차지합니다. 서버는 계속 돌아가지만 꽉 차 있고, 진짜 플레이어는 더 이상 들어오지 못합니다.

여기에 RCON이 네트워크에 열려 있는 순간 다섯 번째 양상이 더해집니다. RCON 포트를 향해 초 단위로 들어오는 로그인 시도입니다. 볼류메트릭인 경우는 드물지만 연산 시간을 쓰고, 다섯 가지 가운데 한 번의 성공으로 서버를 아예 여러분 손에서 빼앗아 가는 유일한 경우입니다.

돈을 쓰기 전에 직접 할 수 있는 일

이 절이 가장 길고, 의도한 바입니다. 설정이 깔끔한 Mordhau 서버는 어디에 놓여 있든 작거나 중간 규모의 공격을 자체 힘으로 견뎌 냅니다.

1. 현황 파악: 서버에서 대체 무엇이 대기하고 있나요?

방화벽 규칙을 한 줄이라도 쓰기 전에 서버가 외부에 무엇을 내주고 있는지 확인하세요. 추측하지 말고 직접 확인합니다.

ss -lntup

여기서 중요한 것은 로컬 주소 열입니다. 0.0.0.0:7777과 [::]:7777은 “인터넷 전체에서 접근할 수 있음”을 뜻하고, 127.0.0.1:27020은 “로컬에서만 접근할 수 있음”을 뜻하므로 방화벽 규칙이 필요하지 않습니다. 게임 외에도 웹 패널, 데이터베이스 서비스, 잊고 방치한 음성 서비스가 함께 나타나는 일이 잦습니다. 공격자의 시선은 외부에서 실행하는 스캔이 보여 주며, 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 비컨'
ufw allow 27015/udp comment 'Mordhau 쿼리'
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은 본인 주소로 바꾸세요. 중요한 것은 여기에 없는 것입니다. 웹 패널 허용도, 데이터베이스 허용도, 파일 서버 허용도 없습니다. 추가로 열린 포트는 모두 게임과 아무 상관이 없는 추가 표적입니다. 복구 방법까지 포함한 전체 안내는 스스로 접속이 막히지 않게 UFW 방화벽 설정하기에 있습니다.

3. 서버 목록에서 사라지지 않으면서 쿼리 포트 27015 제한하기

쿼리 포트는 제한해도 되지만 닫아서는 안 됩니다. 27015 UDP를 막으면 플레이어 수, 맵 이름, 서버 이름이 바로 이 포트로 조회되기 때문에 여러분의 서버가 서버 브라우저에서 사라집니다. 출발지 주소별 상한이 노출을 잃지 않고 이 문제를 해결해 줍니다.

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

정상적인 서버 브라우저는 1분에 몇 번 조회하고, 1초에 몇 번씩 조회하지는 않습니다. 따라서 출발지 주소당 초당 조회 10회는 어떤 플레이어에게도 넉넉하고 어떤 봇에게도 좁습니다. 설정한 뒤에는 매칭 카운터로 규칙이 실제로 걸리는지 확인하세요.

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=내 Mordhau 서버
MaxSlots=64
ServerPassword=
AdminPassword=YOUR_LONG_RANDOM_PASSWORD
RconPassword=ANOTHER_LONG_RANDOM_PASSWORD
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. 비컨 포트 15000을 접속 플러드에 대비해 지키기

비컨 포트는 Mordhau 서버에서 과소평가되는 공격 지점입니다. 게임은 이 포트를 통해 접속하는 플레이어가 아직 불러오는 동안 슬롯을 예약합니다. 빠른 간격으로 접속을 계속 개시하는 봇은 게임에 한 번도 도달하지 않으면서 슬롯을 차지합니다. 서버는 온라인 상태를 유지하면서도 꽉 찬 것처럼 보입니다. 출발지 주소별 상한이 이것을 걸러 냅니다. 진짜 플레이어는 접속마다 정확히 한 번 비컨을 쓰고, 1초에 스무 번 쓰지는 않기 때문입니다.

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

두 번째 규칙은 게임 포트를 겨냥하며 눈대중이 필요합니다. 틱레이트가 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의 모드 식별자를 다루고, Engine.ini는 네트워크 동작을 다룹니다. 두 파일은 반드시 서버를 정지한 상태에서만 편집하세요. 그러지 않으면 서버 프로세스가 종료할 때 메모리에 있던 상태로 여러분의 변경 내용을 덮어씁니다.

공격 표면과 정말로 관련이 있는 설정은 세 가지입니다. 첫째로 ServerPassword입니다. 초대받지 않은 사람 모두를 막아 주지만 공개 검색 가능성을 잃게 하고, 포트 7777을 향한 플러드에는 전혀 도움이 되지 않습니다. 공격자는 애초에 접속할 생각이 없기 때문입니다. 둘째로 현실적인 MaxSlots 값입니다. Mordhau는 최대 64명을 전제로 설계되어 있고, 슬롯이 하나 늘어날 때마다 여러분의 CPU가 처리해야 하는 패킷 출처가 하나 늘어납니다. 셋째로 Engine.ini의 틱레이트입니다.

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Mordhau 서버의 기본 틱레이트는 60입니다. 이를 120으로 올리면 플레이어당 패킷 전송률과 CPU 부하가 두 배가 되며, 공격을 받는 중에 결코 반갑지 않은 것이 바로 그것입니다. 틱레이트 120의 64 슬롯 서버는 평상시 운영에서도 방향별로 초당 8,000패킷 규모를 만듭니다. 계속 공격받는 서버라면 120보다 60으로 운영할 때 체감할 수 있을 만큼 안정적입니다.

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 주소는 비밀로 지킬 수 없습니다. 서버 브라우저 항목에 적혀 있고, 쿼리 포트를 주기적으로 읽어 가는 제3자의 공개 서버 목록에도 적혀 있으며, 한 번이라도 접속해 본 플레이어는 모두 그것을 알고 있습니다. 그래서 주소를 바꾸면 몇 시간, 드물게 며칠을 벌 뿐입니다. 공격자는 새 주소도 옛 주소와 같은 경로로 찾아냅니다.

여기에는 세 가지 습관이 효과가 있습니다. 날것의 IP 주소를 여러분 스스로 어디에도 공개하지 마세요. Discord 채널에도, 프로젝트 페이지에도 적지 않습니다. 플레이어는 호스트 이름으로 연결하게 해서, 비상시에 주소를 바꾸어도 모든 안내가 깨지지 않게 하세요. 그리고 옛 DNS 항목을 치우세요. 이전 주소를 가리키는 A 레코드를 잊고 두면 어떤 변경도 무의미해집니다. 테스트 서버도 마찬가지입니다. 같은 머신에서 외부에 닿을 수 있는 두 번째 서버는 본 서버의 주소를 알려 줍니다.

9. 모든 것이 정상으로 돌아가는 동안에 측정하기

가장 중요하면서 거의 아무도 미리 하지 않는 단계가 있습니다. 서버가 조용히 돌아가는 동안에 기준값을 만들어 두는 것입니다. 평상시 값이 없으면 사건이 끝난 뒤에 초당 40,000 패킷이 많았던 것인지 그냥 토요일 저녁이었던 것인지 말할 수 없습니다. 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의 폐기 카운터를 주의해서 보세요. CPU는 조용한데 dropped 값이 올라간다면, 문제가 연산 능력이 아니라 패킷 전송률이라는 가장 분명한 신호입니다. 측정값을 해석하는 방법은 DDoS 공격 알아내기에 있습니다. 서버를 SteamCMD로 깔끔하게 설치하고 최신으로 유지하는 방법은 SteamCMD로 게임 서버 설치하기에서 다룹니다.

이 조치들이 한계에 이르는 지점: 대역폭과 패킷 전송률

이제 어떤 설정 파일로도 해결할 수 없는 부분입니다. 지금까지의 모든 조치는 여러분의 서버, 즉 회선의 끝에서 동작합니다. 방화벽 규칙은 이미 케이블을 지나온 패킷을 두고 판단합니다. 그 패킷을 폐기할 수는 있지만, 보내지 않은 것으로 만들 수는 없습니다.

한번 계산해 보겠습니다. 일반적인 게임 서버는 1 Gbit/s 회선에 물려 있고, 이는 초당 125 메가바이트이며, 누군가 그보다 많이 보내는 순간 회선은 꽉 찹니다. 64 슬롯을 가득 채운 Mordhau 서버는 그중 일부만 씁니다. 틱레이트 60에서 게임 트래픽은 방향별로 초당 4,000패킷 규모입니다. 반면 대여한 booter는 어렵지 않게 5 Gbit/s에서 50 Gbit/s를, 곧 여러분 회선의 다섯 배에서 오십 배를 실어 옵니다. 그 뒤에 있는 iptables 규칙이 훌륭한지는 그때 아무 의미가 없습니다. 플레이어의 패킷이 그 앞에서 이미 통과하지 못하기 때문입니다.

두 번째 수치는 패킷 전송률이고, 대역폭보다 먼저 터지는 일이 많습니다. 64 바이트짜리 작은 패킷이라면 1 Gbit/s 회선에 초당 약 149만 개가 들어갑니다. 일반적인 서버 커널은 CPU와 네트워크 카드에 따라 그중 수십만 개를 처리한 뒤 폐기를 시작합니다. 그러니 회선을 3분의 1도 채우지 못하는 공격도 여러분의 Mordhau 서버를 멈춰 세울 수 있습니다. 폐기에 연산 시간이 들어가기 때문입니다. 운영자는 이것을 “사용률은 전혀 높지 않았는데 그래도 전부 죽었다”로 경험합니다.

실제로 어떤 규모가 나타나는지 짚어 보면, KernelHost 서버에서는 음성 서버로 들어온 초당 4,150만 패킷 이상과 함께 473.4 Gbit/s 이상의 공격, 그리고 게임 서버로 들어온 112.2 Gbit/s 이상의 UDP 플러드가 걸러졌습니다. 이에 대한 로컬 설정은 없습니다. 볼류메트릭 공격은 서버 앞단 네트워크에서 끝나야 합니다.

KernelHost가 이에 맞서 제공하는 것

모든 서버에 포함된 상시 방어

KernelHost의 DDoS 방어는 두 단계로 구성되어 있고 상시 동작합니다. 여러분이 무엇을 켜거나 주문하거나 설정할 필요가 없습니다.

• 1단계: 글로벌 스크러빙 네트워크의 17 Tbps 방어 용량. 볼류메트릭 공격은 발생지에 가까운 곳에서 정화되어 데이터센터에 닿기 전에 걸러집니다.
• 2단계: 프랑크푸르트암마인의 3.2 Tbps Arbor 실시간 필터링. 서버 바로 앞에서 프로토콜별 패턴을 찾아내 패킷 하나하나를 폐기합니다.

두 가지 특성이 결정적입니다. 이 방어는 상시 동작하므로 공격에 반응해서 비로소 시작될 필요가 없습니다. 그래서 초반에 서버가 사라지는 몇 분이 존재하지 않습니다. 그리고 null-routing을 쓰지 않습니다. 여러분의 IP 주소는 네트워크에 그대로 남고, 폐기되는 것은 악성 패킷뿐입니다. IP 주소를 네트워크에서 빼 버리면 여러분에게는 공격이 성공한 것과 같은 결과가 됩니다. 위치는 프랑크푸르트암마인입니다. 어떤 게임과 프로토콜이 포함되는지는 실시간 게임 서버 DDoS 방어에 정리되어 있습니다.

계속 공격받는 Mordhau 서버를 위한 Advanced DDoS Protection

어떤 서버는 어쩌다 한두 번이 아니라, 표적이 되어 몇 주에 걸쳐 공격받습니다. 이런 경우를 위해 Advanced DDoS Protection이 월 50.00 EUR부터, PrePaid 방식으로, 최소 이용 기간과 설치비 없이 제공됩니다. 차이는 용량이 더 커지는 데 있지 않고 통제권에 있습니다.

• 전용 방어 IP: 프랑크푸르트 코어에서 발급되며, 서버는 자체 네트워크에서 이 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 포트를 확인하세요. 비컨은 불러오는 동안 슬롯을 예약합니다. 이 포트가 막혀 있거나 너무 좁게 걸러지거나 과부하 상태면, 포트 7777이 응답하고 서버가 브라우저에 보여도 접속이 멈춰 버립니다.

“Game.ini에 넣은 변경이 재시작 후에 다시 사라집니다”: 서버가 돌아가는 중에 파일을 편집한 것입니다. Mordhau 서버 프로세스는 종료할 때 메모리에 있던 상태를 다시 써 넣으면서 여러분의 판본을 덮어씁니다. 서버 정지, 편집, 시작의 순서를 지키세요.

“iptables 규칙이 적용되지 않습니다”: 흔한 원인이 세 가지입니다. 규칙이 UFW 체인 뒤에 있어 전혀 도달하지 못하거나, 마지막 재시작 이후 사라졌거나(이때는 netfilter-persistent save 또는 /etc/ufw/before.rules 항목이 도움이 됩니다), 공격이 볼류메트릭이어서 규칙은 이미 꽉 찬 회선에서 제대로 동작하고 있는 경우입니다. iptables -L INPUT -n -v로 매칭 카운터가 올라가는지 확인하세요. 0에 머물러 있으면 규칙에 도달하지 못하는 것입니다.

“서버는 돌아가는데 모두 랙 스파이크를 겪고 타격이 늦게 들어갑니다”: 먼저 CPU가 조용한 상태에서 수신 패킷 전송률이 올라가는지 확인하세요. 바로 그것이 공격의 양상입니다. 패킷 전송률은 평범한데 CPU가 100퍼센트에 머물러 있다면 DDoS 공격이 아니라 대개 너무 높은 틱레이트, 너무 많은 슬롯 또는 모드가 원인입니다.

“업체가 포트 27015에서 나가는 어뷰즈를 알려 왔습니다”: 여러분의 서버가 반사 공격의 증폭기로 악용된 것입니다. 조회는 출발지 주소가 위조된 채 들어왔고, 응답한 것은 여러분의 서버이며 그 대상은 남의 피해자였습니다. 27015 UDP에 출발지 주소별 속도 제한을 걸면 끝납니다.

“기존 업체가 제 IP 주소를 차단했습니다”: 그것이 null-routing입니다. 업체는 그렇게 자기 네트워크를 지키지만, 여러분에게 남는 결과는 공격이 성공한 것과 똑같고, 보통 그 뒤로 몇 시간 더 이어집니다. 확실하지 않으면 필터링을 하는지 null-routing을 하는지 물어보세요. 그 답이 어떤 하드웨어 사양보다 여러분의 가용성을 더 크게 좌우합니다.

“tcpdump에 이상한 것이 보이지 않습니다”: 트래픽이 이미 앞단 네트워크에서 걸러지고 있으면 서버에는 아무것도 도착하지 않는 것이 당연합니다. 필터링이 작동하고 있을 때의 정상적인 모습입니다. 반대로 회선이 포화되면 측정에 쓰려던 SSH 세션조차 닿지 않을 수 있습니다. 그럴 때는 게스트 시스템의 네트워크와 무관하게 동작하는 고객 포털의 VNC 콘솔을 이용하세요.

핵심 요약

• Mordhau 전용 서버는 외부로 정확히 네 개의 UDP 포트가 필요합니다. 7777(게임), 7778(Steam), 15000(비컨), 27015(Steam 쿼리)입니다. 나머지는 모두 닫습니다.
• Mordhau의 RCON은 Source RCON 프로토콜에 따라 TCP로 동작하고, Game.ini의 RconPassword와 RconPort로 비로소 켜집니다. 이 포트는 본인 주소로만 제한하세요.
• 27015 UDP는 제한해도 되지만 닫아서는 안 됩니다. 플레이어 수, 맵, 이름이 이 포트로 조회되기 때문에, 닫으면 서버가 서버 브라우저에서 사라집니다.
• 15000 UDP는 비컨 포트이고 불러오는 동안 슬롯을 예약합니다. 막혀 있거나 과부하 상태면 서버가 돌아가는데도 플레이어가 들어오지 못합니다.
• Game.ini와 Engine.ini는 서버를 정지한 상태에서만 편집하세요. 서버 프로세스가 종료할 때 메모리에 있던 상태를 다시 써 넣기 때문입니다.
• 로컬 방화벽 규칙은 대역폭에서 끝납니다. 1 Gbit/s는 초당 125 메가바이트이고, 64 바이트 패킷이라면 초당 약 149만 개입니다. 그 위에서는 서버 앞단 네트워크만이 결과를 결정합니다.
• KernelHost에서는 2단계 상시 방어가 모든 서버 상품에 추가 요금 없이 포함되어 서버 제공 시점부터 동작하며, null-routing을 쓰지 않습니다. 필터링을 직접 조정하려는 분은 월 50.00 EUR부터의 Advanced DDoS Protection으로 그것을 얻습니다.

Mordhau 서버가 이미 KernelHost에 있다면 필터링은 여러분이 아무것도 하지 않아도 동작하고 있습니다. 그래도 이상한 점이 보이면 지원 티켓을 열어 주세요. 해당 IP 주소의 필터 규칙을 다시 맞춰 드립니다. 공격이 진행 중일 때는 WhatsApp 긴급 채팅 +43 650 8209883으로도 연락하실 수 있습니다.