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

Project Zomboid 서버를 DDoS 공격으로부터 방어하려면 공격자가 무엇을 겨냥하는지부터 알아야 합니다. 전용 서버는 UDP 포트 정확히 두 개, 곧 16261과 16262를 차지하며, 두 포트 모두 네트워크에 열려 있어야 합니다. 그러지 않으면 아무도 접속할 수 없기 때문입니다. 이 글은 비상 상황에서 실제로 중요한 순서로 진행합니다. 먼저 앞으로 십 분 안에 추가 비용 없이 직접 할 수 있는 것, 그다음 이런 조치가 기술적으로 한계에 이르는 지점, 마지막으로 그 앞단 네트워크에서 무엇이 이뤄져야 하는지입니다.

모든 내용은 Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 운영하는 전용 서버(Steam 앱 380870)를 기준으로 하며, Build 41과 Build 42에 모두 적용됩니다. 설정 파일 이름은 servertest.ini이고 ~/Zomboid/Server/에 있으며, 월드 데이터는 ~/Zomboid/Saves/Multiplayer/에 있습니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요.

공격이 지금 진행 중이라면: 지금 servertest.ini를 바꾸지 마시고 서버를 재시작하지도 마세요. 먼저 측정값을 확보하세요(9절). 공격이 끝나면 그 값은 사라집니다. 재시작에는 서버가 월드를 불러오는 시간이 추가로 들고, 공격자가 여러분에게서 빼앗으려는 것이 바로 그 시간입니다.

Project Zomboid 서버가 DDoS 공격의 표적이 되는 이유

Project Zomboid는 죽음이 영구적이고 월드가 몇 달에 걸쳐 이어지는 게임입니다. 위험한 상황 도중에 연결이 끊기면 다른 거의 모든 장르보다 손실이 큽니다. 캐릭터는 사라지고, 월드는 그것을 기억합니다. 바로 이 점이 장애를 무기로 만듭니다. 저녁 8시의 공격은 아무 플레이어가 아니라 고정된 커뮤니티를 때리고, 그것도 잃을 것이 가장 많은 지점을 때립니다.

여기에 공격 자체가 비용도 실력도 요구하지 않는다는 점이 더해집니다. 돈을 내고 빌리는 공격 서비스, 업계에서 booter나 stresser라고 부르는 것들은 클릭 몇 번으로 IP 주소와 포트 하나를 겨냥하며, Project Zomboid에서 그 표적은 언제나 같습니다. 곧 16261 UDP입니다. 차단된 플레이어와 다투고 있거나 경쟁 커뮤니티를 운영하는 사람은 지식도 이렇다 할 비용도 필요 없는 도구를 손에 쥐게 됩니다.

게임 서버가 자기 주소를 공개해야 한다는 점도 있습니다. servertest.ini에 Public=true가 있으면 서버가 게임 내 브라우저에 나타나고, Steam에 연동된 서버는 어차피 Steam 서버 브라우저에서 보입니다. 따라서 질문은 공격자가 여러분의 IP 주소를 찾아내느냐가 아니라, 그 주소를 겨냥했을 때 무슨 일이 벌어지느냐입니다.

기술적으로 가장 불편한 부분은 마지막에 옵니다. 게임 트래픽 전체가 UDP로 흐릅니다. UDP에는 요구할 수 있는 연결 수립 절차가 없고, 패킷은 각각 따로 존재하며, 출발지 주소는 위조할 수 있습니다. 그래서 공격자는 부하를 만들기 위해 서버에 들어올 필요도, 규격에 맞게 말을 걸 필요도 없습니다. DDoS 공격이 구체적으로 무엇인지는 DDoS 공격이란 무엇인가? 글에서 설명합니다.

Project Zomboid 서버에 실제로 필요한 포트

전용 Project Zomboid 서버에 필요한 열린 포트는 정확히 두 개, 16261 UDP와 16262 UDP입니다. 게임의 공식 포트 목록에 세 번째는 없습니다. servertest.ini에서는 둘이 서로 다른 지시어로 적히며, 두 번째 포트가 첫 번째 포트에서 자동으로 정해지지는 않습니다.

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

역할 분담은 분명합니다. 16261 UDP는 게임 트래픽과 연결 수립을 나르고 서버 브라우저의 조회에 응답합니다. 16262 UDP는 클라이언트의 직접 연결을 담당하는 포트입니다. 첫 번째가 없으면 아무도 서버를 찾지 못하고, 두 번째가 없으면 플레이어가 목록에서 항목은 보지만 들어오지는 못합니다. 이 게임에서 가장 널리 알려진 오류 메시지, 곧 포트 16262가 닫혀 있다는 메시지가 바로 여기에서 나옵니다.

자주 문제를 일으키는 두 가지가 있습니다. 첫째, 서버 인스턴스마다 비어 있는 UDP 포트 두 개가 필요합니다. 같은 머신에서 두 번째 월드를 운영한다면 두 번째 쌍, 예를 들어 16274와 16275를 배정하고 두 값을 두 번째 인스턴스의 servertest.ini에 적어 넣으세요. 둘째, SteamPort1과 SteamPort2는 8766과 8767로 설정 파일에 들어 있지만 서버의 Steam 연동에 속하고 게임 트래픽에는 속하지 않습니다. 이 포트가 없으면 서버가 Steam 목록에 나타나지 않는 경우에만 열고, 미리 대비하는 뜻으로 열지는 마세요.

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

이 절이 가장 길고, 의도한 바입니다. 설정이 깔끔한 서버는 어디에 놓여 있든 작거나 중간 규모의 공격을 자체 힘으로 견뎌 냅니다. 볼류메트릭 공격을 대신 막아 주지는 않지만, 값싼 공격을 무력하게 만들고 비상 상황에서 추측 대신 숫자를 갖게 해 줍니다.

1. 현황 파악: 무엇이 실제로 대기하고 있나요?

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

ss -lntup

여기서 중요한 것은 로컬 주소 열입니다. 0.0.0.0:16261과 [::]:16261은 “인터넷 전체에서 접근할 수 있음”을 뜻하고, 127.0.0.1:27015는 “로컬에서만 접근할 수 있음”을 뜻하므로 방화벽 개방이 필요하지 않습니다. 기본값에 의존하지 말고 결과를 여러분의 설정과 맞춰 보세요.

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

공격자의 시선은 외부에서 실행하는 포트 스캔이 보여 줍니다. Project Zomboid는 UDP만 사용하므로 UDP 스캔이 필요하며, TCP 스캔만으로는 게임 포트가 아예 보이지 않습니다.

nmap -Pn -sU -p 16261,16262,8766,8767 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 16261과 16262만 열어 두기

외부로는 두 개만 열면 충분하고, 나머지는 제한하거나 아예 공개하지 않습니다. UFW에서는 다음과 같이 하며, 스스로 접속이 막히지 않도록 반드시 이 순서를 지키세요.

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid 직접 연결"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10은 본인 주소로 바꾸세요. 방화벽을 켜는 순서가 스스로 접속이 막히는지를 결정합니다. 복구 방법까지 포함한 전체 안내는 스스로 접속이 막히지 않게 UFW 방화벽 설정하기에 있습니다. 그래도 막혔다면, KernelHost의 KVM 루트 서버와 Dedicated Server에서는 고객 포털의 VNC 콘솔로 시스템에 접근할 수 있습니다. 이 콘솔은 게스트 시스템의 네트워크와 무관하게 동작합니다.

데이터베이스와 부가 서비스에 대해 한마디 덧붙이면, Project Zomboid에는 그런 것이 필요하지 않습니다. 게임 외에 0.0.0.0에서 대기하는 것은 이전 설치나 관리 패널에서 남은 것이며, 127.0.0.1에 바인딩하거나 끄는 것이 맞습니다.

3. 포트 27015의 RCON을 인터넷에서 빼기

RCON은 서버의 원격 제어이고 Project Zomboid에서는 27015 TCP에서 동작합니다. 출고 상태의 servertest.ini에는 RCONPassword=가 값 없이 들어 있습니다. RCON을 쓴다면 길고 무작위한 비밀번호를 설정하세요. 이 프로토콜은 암호화 없이 전송하며, 접근할 수 있는 RCON 포트에 약한 비밀번호가 걸려 있으면 공격 트래픽 단 한 패킷 없이도 서버를 통째로 넘겨주게 됩니다.

안전한 방법은 포트를 애초에 외부로 열지 않고 SSH 포트 포워딩으로 접근하는 것입니다. 그다음에는 로컬에서 127.0.0.1:27015로 통신합니다.

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

RCON이 필요하지 않다면 비밀번호 항목을 비워 두고 포트를 닫아 두세요. 접근할 수 없는 서비스는 비밀번호를 하나씩 대입해 볼 수도, 플러딩할 수도 없습니다.

4. 출발지 주소별로 패킷 전송률 제한하기

작은 공격과 엉성한 봇에는 출발지 주소별 상한이 도움이 됩니다. 두 게임 포트가 나란히 있으므로 구간 하나에 대한 규칙으로 충분합니다.

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

이 규칙은 같은 출발지 주소가 초당 400개를 지속적으로 넘겨 보내는 순간 UDP 패킷을 폐기합니다. 이 값은 출발점일 뿐이고 정답이 아닙니다. 같은 도시에 모인 플레이어 30명이 있는 서버는 지도 곳곳에 흩어진 네 명이 있는 서버보다 훨씬 많은 트래픽을 만들고, 너무 좁게 잡으면 자기 플레이어를 내쫓습니다. 먼저 평상시 운영에서 한 주는 측정하고, 그다음 최고치의 몇 배로 한도를 잡으세요.

두 가지를 덧붙입니다. iptables 규칙만 쓰면 재시작 후에 사라지므로 Debian과 Ubuntu에서는 다음과 같이 저장합니다.

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

그리고 UFW를 쓴다면 이런 규칙은 /etc/ufw/before.rules에 들어가야 합니다. 그러지 않으면 다음 ufw reload에서 사라집니다. iptables -L INPUT -n -v의 매칭 카운터로 규칙에 실제로 도달하는지 확인하세요. 카운터가 0에 머물러 있으면 규칙이 잘못된 자리에 있는 것입니다.

5. 연결 추적의 부담 덜기

자주 간과되는 병목이 커널에 있습니다. 연결 추적(conntrack)은 UDP에도 출발지 주소와 포트마다 항목을 만들고, 위조된 출발지로 들어오는 플러드는 이 테이블을 몇 초 만에 채웁니다. 테이블이 가득 차면 서버는 정상 패킷까지 폐기하고, 로그에는 “nf_conntrack: table full”이 남습니다. 현재 값과 상한은 다음 명령으로 확인합니다.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Project Zomboid의 게임 트래픽에는 상태 추적이 필요하지 않습니다. UDP에는 상태가 없기 때문입니다. 그래서 두 게임 포트를 테이블에서 빼 둘 수 있습니다.

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

이것은 커널 부담을 눈에 띄게 줄여 줍니다. 한 가지 중요한 점이 있습니다. 이 규칙은 서버가 패킷을 직접 받는 동안에만 맞습니다. 그 앞에서 주소 변환을 쓰는 경우, 예를 들어 포트를 넘겨 주는 컨테이너 구성이라면 이 규칙을 넣어서는 안 됩니다. 돌아오는 방향이 더 이상 연결되지 않기 때문입니다.

6. 접속과 슬롯 보호하기

다음 줄들은 비용이 들지 않고, 정상 접속 경로로 들어오는 모든 것에 효과가 있습니다.

Password=A-LONG-RANDOM-PASSWORD
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password는 서버 공용 비밀번호이고 개별 플레이어의 계정과는 별개입니다. Open=false는 관리자가 미리 만들어 둔 계정만 접속할 수 있다는 뜻이며, 이것이 이 게임의 허용 목록입니다. MaxAccountsPerUser는 Steam 사용자 한 명이 여러분의 서버에 계정을 몇 개까지 만들 수 있는지를 제한하며, 기본값 0은 무제한을 뜻합니다. MaxPlayers는 출고 기본값이 32이고, 그보다 높은 값에 대해서는 공식 문서가 지도 추가 로딩 불량과 동기화 오류를 명시적으로 경고합니다.

여기서 함정은 PingLimit입니다. 이 지시어는 밀리초 단위 지연이 기준을 넘는 플레이어를 내보내며, 출고 기본값은 0, 곧 꺼진 상태입니다. 공격을 받는 동안에는 여러분 자신의 플레이어 지연이 가장 먼저 올라가므로, 좁게 잡은 값은 정작 붙잡아 두려는 사람들을 내쫓습니다. 이 한도는 끄거나 넉넉하게 설정하세요.

한 가지는 분명히 해 두어야 합니다. 허용 목록은 게임 로직을 지켜 주지만 회선을 지켜 주지는 않습니다. 서버를 플러딩하는 공격자는 애초에 접속할 생각이 없습니다. 그의 패킷은 거부되지만 이미 도착해 있고, 바로 그 점이 핵심입니다.

7. 접속할 때의 모드 검증이 서버에서 가장 비싼 1초입니다

Project Zomboid는 접속할 때 비밀번호만 확인하지 않습니다. 서버의 모드 목록은 servertest.ini의 두 줄에 있습니다. WorkshopItems에는 숫자로 된 Workshop ID가, Mods에는 모드의 로드 ID가 들어가며, 둘 다 세미콜론으로 구분합니다. 접속할 때 클라이언트는 이 목록을 맞춰 보고, 빠진 Workshop 콘텐츠를 Steam을 통해 자동으로 내려받은 다음에야 월드 데이터를 전송받습니다. 여기에 더해 DoLuaChecksum=true이면 서버가 게임 파일의 체크섬을 비교하고, 자기 파일과 맞지 않는 클라이언트를 내보냅니다.

공격자에게는 바로 이 부분이 흥미롭습니다. 이 작업이 실제 게임 참여보다 앞서 발생하기 때문입니다. 접속 시도 하나하나가 버전, 체크섬, 모드 목록, 지도 데이터를 처리하는 연산 시간을 소모하며, 결국 거부되는 시도도 마찬가지입니다. 모드 목록이 길수록 그 시도 하나하나가 더 비싸집니다. 그래서 접속 플러드는 모드를 많이 얹은 서버에서 손대지 않은 서버보다 효과가 크고, 볼류메트릭 공격에 필요한 대역폭의 일부만으로도 충분합니다. 게임 자체는 이에 맞서는 제동 장치 두 개를 갖추고 있습니다.

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer는 서버가 과부하인 동안 새 로그인을 거부해서 진행 중인 판이 함께 무너지지 않게 합니다. LoginQueueEnabled는 접속하는 사람들을 동시에 처리하는 대신 대기열에 세웁니다. LoginQueueConnectTimeout은 접속 하나에 허용되는 시간을 정하며, 기본값은 60초이고 20초부터 1200초까지 지정할 수 있습니다.

여기에 한 가지 세부 사항을 덧붙입니다. 흔히 잘못 해결되는 부분이기 때문입니다. 리눅스 서버에는 DoLuaChecksum이 잘못된 경보를 울려 플레이어를 들여보내지 않는, 문서로 확인된 문제가 있습니다. 그래서 운영자들은 이 검사를 끕니다. 이해할 수 있는 선택이지만, 게임 파일을 바꾼 클라이언트를 막아 주던 통제 하나가 없어집니다. 이 검사를 꺼야 한다면 서버 비밀번호, 허용 목록, 계정 수 제한을 그만큼 더 엄격하게 설정하세요.

8. 서버 목록, UPnP, 그리고 본인 주소

여기서는 희망적인 생각보다 솔직함이 낫습니다. 여러분의 IP 주소는 비밀로 유지할 수 없습니다. Public=true는 서버를 게임 내 브라우저에 보여 주고, Steam에 연동된 서버는 공식 문서에 따르면 어차피 Steam 서버 브라우저에서 보입니다. 따라서 Public=false는 여러분을 보이지 않게 만들지는 못하면서, 새 플레이어에게 발견될 기회만 잃게 만듭니다.

Public=true
PublicName=내 Zomboid 서버
UPnP=false
server_browser_announced_ip=

UPnP는 출고 기본값이 true이고, 서버가 인터넷 게이트웨이에서 직접 포트 개방을 설정하려고 시도하게 만듭니다. 임대한 서버에는 그런 게이트웨이가 없으므로 이 시도는 헛돌고, 끄는 것이 맞습니다. server_browser_announced_ip는 비워 둡니다. 서버에 주소가 여러 개 있고 그중 하나로 지정해서 나타나게 하려는 경우만 예외입니다. 나중에 전용 방어 IP로 전환할 때 바로 이 항목이 다시 필요해집니다.

어떤 설정보다 도움이 되는 습관이 두 가지 있습니다. 원시 IP 주소를 여러분 스스로 어디에도 공개하지 마세요. Discord 채널에도 프로젝트 홈페이지에도 올리지 말고, 플레이어에게는 호스트 이름을 알려 주세요. 주소를 바꿀 때의 전형적인 실수는 오래된 DNS 항목입니다. 이전 주소를 가리키는 A 레코드를 잊고 방치하면 어떤 변경도 무의미해집니다.

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

가장 중요하면서 거의 아무도 미리 하지 않는 단계가 있습니다. 모든 것이 조용한 동안에 기준값을 만들어 두는 것입니다. 평상시 값이 없으면 사건이 끝난 뒤에 초당 40,000 패킷이 많았던 것인지 그냥 토요일 저녁이었던 것인지 말할 수 없습니다. apt-get install -y vnstat sysstat로 측정이 상시 돌아갑니다. 사건이 진행되는 동안에는 네 개의 명령으로 충분합니다.

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

앞의 두 개는 인터페이스의 패킷 전송률과 폐기 카운터를, 세 번째는 트래픽의 짧은 표본을, 네 번째는 서버가 systemd 서비스로 돌아가는 경우 서버의 메시지를 보여 줍니다(서비스 이름은 환경에 맞게 바꾸세요). tcpdump에는 한 가지 원칙이 있습니다. 항상 -c로 개수를 제한하세요. 과부하 상태에서의 캡처는 이미 과부하인 서버에 부담을 더 얹습니다. 측정값을 해석하는 방법은 서버에서 DDoS 공격 알아내기에 있습니다.

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

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

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

게임 서버 커뮤니티를 겨냥한 일반적인 공격은 5 Gbit/s에서 50 Gbit/s 사이, 곧 일반적인 회선의 5배에서 50배입니다. 이에 맞설 로컬 설정은 없습니다. 볼류메트릭 공격은 서버 앞단 네트워크에서 끝나야 합니다.

KernelHost가 게임 서버 DDoS 공격에 맞서 제공하는 것

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

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

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

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

계속 공격받는 프로젝트를 위한 Advanced DDoS Protection

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

• 전용 방어 IP: 프랑크푸르트 코어에서 발급되며, 서버는 자체 네트워크에서 이 IP로 전환됩니다. 여러분 쪽에서 손볼 것은 없고, 새 주소는 플레이어가 서버를 찾는 곳에만 적어 넣으면 됩니다.
• 포트와 프로토콜별로 직접 관리하는 방어 규칙: 고객 포털에서 16261과 16262 UDP에 무엇을 허용할지 정하고, 나머지는 티켓을 쓰지 않아도 닫힌 상태로 남습니다.
• 변경은 실시간으로 반영: 공격이 진행되는 중에도 값을 조정할 수 있습니다.
• 알맞은 방어 프로필. 널리 쓰이는 게임에는 완성된 프로필이 있고, 개조된 애플리케이션과 자체 애플리케이션에는 포트와 프로토콜별로 규칙을 직접 설정합니다. Project Zomboid는 게임 트래픽 전체가 나란히 놓인 UDP 포트 두 개로 흐르므로 특히 정밀하게 좁힐 수 있습니다.

두 단계 비교

대부분의 Project Zomboid 서버에는 깔끔한 설정과 포함된 상시 방어면 충분합니다. Advanced DDoS Protection은 누군가 이 일을 개인적으로 받아들였을 때의 답입니다.

자주 나오는 실수와 해결 방법

“플레이어들이 포트 16262가 닫혀 있다는 메시지를 받습니다”: 공격이 아니라 개방이 빠진 것입니다. 서버에는 16261 UDP와 16262 UDP 두 포트가 모두 필요하며, 그것도 UDP 규칙으로 필요합니다. 같은 번호의 TCP 개방은 아무 효과가 없습니다. ufw status verbose와 외부에서의 UDP 스캔으로 두 포트가 정말 열려 있는지 확인하세요.

“IP 주소를 바꿨는데 두 시간 뒤에 다시 오프라인이 되었습니다”: 공격자는 새 주소를 예전과 같은 경로에서 얻습니다. 대개 서버 목록의 항목, 상태를 표시하는 Discord 봇, 또는 오래된 DNS 항목입니다. Project Zomboid에서는 주소 변경에 비용이 더 붙습니다. 클라이언트가 지도 데이터를 주소와 포트로 된 폴더에, 곧 Zomboid/Saves 아래 123.45.0.12_16261_... 형태의 이름으로 로컬에 저장하기 때문입니다. 주소를 바꾸면 플레이어마다 탐색한 지도를 서버에서 다시 받습니다. 그러니 주소 변경은 추가 비용이 붙는 시간 벌기이고 해결책이 아닙니다.

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

“플레이어가 접속할 때 튕기는데 서버는 정상으로 계속 돌아갑니다”: 이것은 공격이 아니라 거의 항상 검증 과정입니다. 원인은 클라이언트와 서버의 버전 차이, 빠졌거나 오래된 Workshop 항목, 또는 맞지 않는 체크섬입니다. 클라이언트는 보통 일치하지 않는 모드를 알려 줍니다. WorkshopItems와 Mods를 한 줄씩 맞춰 보세요.

“몇 분마다 랙 스파이크가 생기고 그다음 다시 정상으로 돌아갑니다”: 플레이어가 지쳐 그만둘 때까지만 이어지는 짧은 공격의 전형적인 양상입니다. CPU 부하가 아니라 네트워크 카운터를 먼저 보세요. sar -n DEV 1 10과 폐기 카운터가 평범하다면 공격이 아니라 부하였습니다. 같은 셀에 플레이어가 너무 많거나, 비싼 모드가 있거나, Java 인스턴스에 메모리가 부족한 경우입니다.

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

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

핵심 요약

• 전용 Project Zomboid 서버에 필요한 열린 포트는 정확히 두 개, 곧 16261 UDP(DefaultPort)와 16262 UDP(UDPPort)입니다. 둘 다 servertest.ini에 서로 다른 지시어로 들어 있습니다.
• RCON은 27015 TCP에서 동작하고 출고 상태에서는 비밀번호 없이 등록되어 있습니다. 이 포트는 열린 인터넷에 둘 것이 아니라 본인 주소로 제한하거나 닫아야 합니다.
• 접속할 때의 모드 검증이 가장 비싼 지점입니다. 버전, 체크섬, Workshop 목록, 지도 데이터가 연산 시간을 소모하며, 거부되는 시도마다 마찬가지입니다. 이에 맞서는 내장 제동 장치가 DenyLoginOnOverloadedServer와 접속 대기열입니다.
• 서버 비밀번호와 Open=false, MaxAccountsPerUser=1은 게임 로직을 지켜 줍니다. 포화된 회선에는 이 설정 가운데 어느 것도 통하지 않습니다.
• 물리적 한계는 정해져 있습니다. 1 Gbit/s는 초당 125 메가바이트이고, 64 바이트 패킷이라면 초당 약 149만 개입니다. 게임 서버를 겨냥한 일반적인 공격은 5 Gbit/s에서 50 Gbit/s 사이입니다.
• 볼류메트릭 공격은 서버 앞단 네트워크에서 끝나야 합니다. KernelHost에서는 글로벌 스크러빙 네트워크의 17 Tbps 방어 용량과 프랑크푸르트암마인의 3.2 Tbps Arbor 실시간 필터링이 이를 맡으며, 추가 요금 없이 그리고 null-routing 없이 동작합니다.
• 계속 공격받는 운영자는 Advanced DDoS Protection으로 필터링을 직접 제어합니다. 전용 방어 IP, 포트와 프로토콜별 규칙, 실시간으로 반영되는 변경, 월 50.00 EUR부터입니다.

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