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

저녁에 한창 놀고 있는 중에 모든 플레이어를 동시에 내보내고, 몇 분 동안 오프라인이 되었다가 저절로 다시 닿게 되는 Palworld 서버는 하드웨어 문제인 경우가 드뭅니다. 대개는 공격이 진행 중입니다. 이 글은 Palworld 서버를 DDoS 공격으로부터 어떻게 방어하는지 보여 줍니다. 먼저 추가 비용 없이 직접 설정할 수 있는 것, 그다음 그 조치가 기술적으로 끝나는 지점, 마지막으로 서버가 계속 닿는 상태로 남으려면 서버 앞단 네트워크에서 무엇이 이뤄져야 하는지입니다.

모든 내용은 Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 운영하는 Pocketpair의 공식 전용 서버(Steam 앱 ID 2394010)를 기준으로 합니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요. 공격이 지금 진행 중이라면 순서가 있습니다. 먼저 측정하고, 그다음 바꿉니다. 부하 상태에서의 강제 재시작은 마지막 자동 저장 지점 이후 세계에서 벌어진 모든 것을 버리고, 사건의 측정값도 그 뒤에는 함께 사라집니다.

Palworld 서버가 DDoS 공격으로 표적이 되어 멈춰 세워지는 이유

Palworld 서버는 고정된 주소에 있는 작고 고정된 관객입니다. 전용 서버는 32명으로 제한되며, ServerPlayerMaxNum으로 조정하고 유효 범위는 1에서 32까지입니다. 대신 게임 메뉴로 호스팅하면 네 명까지이고, 그것도 호스트 본인이 접속해 있는 동안만입니다. 이 32개의 자리에서 나머지 모든 것이 따라옵니다. 이 사람들은 정해진 저녁 시간에 놀고, 서로를 알고 있으며, 저녁 8시의 장애는 플레이어의 일부가 아니라 전원을 때립니다.

그러면서 서버의 주소는 비밀이 아닙니다. Palworld에는 제공사 서비스를 통한 중개가 없습니다. 플레이어는 직접 연결 입력란에 IP 주소와 포트를 적어 넣고, 서버를 커뮤니티 서버 목록에도 올리려는 운영자는 -publiclobby로 서버를 실행하고 쿼리 포트가 응답하도록 둡니다. 따라서 한 번 접속한 사람은 모두 표적을 알고 있습니다. 월 몇 유로에 이 주소를 두들기는 booter 서비스는 의뢰인에게 실력도 수고도 요구하지 않습니다.

기술적으로는 게임 트래픽 전체가 UDP로 흐른다는 점이 더해집니다. UDP에는 요구할 수 있는 연결 수립 절차가 없고, UDP 패킷의 출발지 주소는 위조할 수 있습니다. 그래서 공격자는 부하를 만들기 위해 서버에 들어올 필요도, 규격에 맞게 말을 걸 필요도 없습니다. 그런 공격에서 기술적으로 무슨 일이 벌어지는지는 DDoS 공격이란 무엇인가? 글에서 설명합니다.

Palworld 서버에서 실제로 문제가 되는 포트

Palworld 서버에는 열어야 할 포트가 정확히 하나, 8211 UDP입니다. 나머지는 모두 선택 사항이고, 맡은 일에 따라서는 인터넷에 놓여 있으면 오히려 해롭습니다. 여기서 유용한 구분이 하나 나옵니다. 포트 8211을 향한 DDoS 공격은 항상 게임 트래픽 자체를 때리고, 포트 27015 UDP를 향한 공격은 반대로 서버 목록의 등록만 때립니다.

여기에 딸린 모든 스위치는 단 하나의 파일에 있습니다. Pal/Saved/Config/LinuxServer/PalWorldSettings.ini이고, Windows에서는 그에 맞춰 Pal\Saved\Config\WindowsServer\PalWorldSettings.ini입니다. 이 파일은 [/Script/Pal.PalGameWorldSettings] 절 줄로 시작하고, 그다음 모든 설정을 목록으로 담은 단 한 줄 OptionSettings=(...)가 옵니다. 괄호 안에서 줄을 바꾸면 전체 설정이 무효가 되고, 서버는 아무 말 없이 기본값으로 되돌아갑니다. 서버 디렉터리의 원본 DefaultPalWorldSettings.ini는 편집하지 마세요. 업데이트마다 덮어써지기 때문입니다.

숫자로 보는 Palworld 서버

다음 값들은 필터 규칙과 임계값에 관한 모든 결정의 바탕입니다.

쿼리 포트 27015이 가장 취약한 지점인 이유

쿼리 포트는 Steam 형식 A2S로 상태 요청에 응답하며, 이는 Counter-Strike와 ARK 서버가 처리하는 것과 같은 조회입니다. A2S_INFO 요청은 수십 바이트짜리, 연결 없는 UDP 패킷이고, 서버 이름과 세계, 플레이어 수, 진행 상황을 담은 응답은 그보다 몇 배 큽니다. UDP에서는 출발지 주소를 위조할 수 있으므로, 공격자는 남의 쿼리 포트에 말을 걸어 더 큰 응답을 자기 본래 표적으로 보낼 수 있습니다. 이 경우 여러분의 서버는 피해자가 아니라 증폭기이고, 그 회선이 비용을 치릅니다.

그래서 Valve는 2020년 12월 8일에 A2S_INFO에 선행 챌린지를 더했습니다. 서버가 먼저 S2C_CHALLENGE로 응답하고, 요청한 쪽이 그 토큰을 돌려보내면서 자기 출발지 주소를 위조하지 않았음을 증명합니다. 이것으로 증폭은 약해지지만 끝나지는 않으며, 실제 주소에서 오는 같은 종류의 조회를 그냥 쏟아붓는 플러드에는 전혀 통하지 않습니다.

Palworld에는 여기서 Source 엔진에 비한 중요한 장점이 따라옵니다. 게임 트래픽과 서버 쿼리가 서로 다른 포트에 놓여 있다는 점입니다. Counter-Strike 2에서는 둘이 포트 27015를 나눠 쓰므로 거친 속도 제한은 자기 플레이어까지 함께 내쫓습니다. Palworld에서는 8211 UDP에서 진행 중인 게임 트래픽을 조금도 건드리지 않고 27015 UDP를 강하게 제한하거나 완전히 닫을 수 있습니다. 목록 등록이 필요하지 않은 운영자는 -publiclobby와 쿼리 포트를 대체 없이 지워 버리고, 그로써 공격 표면 하나를 완전히 네트워크에서 빼냅니다.

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

다음 단계들은 볼류메트릭 공격을 막아 내지 못합니다. 그것은 서버에서 돌아가는 어떤 소프트웨어도 해낼 수 없습니다. 그러나 그 아래에 있는 것은 모두 치워 줍니다. 포트 스캔, 쿼리 플러드, 관리 포트를 통한 탈취 시도, 그리고 낯선 사람들이 32개 자리를 모두 차지하는 일입니다. 이것이 일상에서 Palworld 서버를 괴롭히는 것의 대부분이고, 30분이면 됩니다.

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

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

ss -lntup

중요한 것은 로컬 주소가 적힌 열입니다. 0.0.0.0:8211은 “인터넷 전체에서 닿을 수 있음”을 뜻하고, 127.0.0.1:8212는 “로컬에서만”을 뜻하므로 방화벽 규칙이 필요하지 않습니다. 오래 운영한 서버에서는 게임 프로세스 외에도 관리 패널, 지도 표시용 웹 서버, 데이터베이스가 함께 나타나는 일이 잦습니다. 공격자의 시선은 외부에서 실행하는 포트 스캔이 보여 줍니다.

nmap -Pn -sU -p 8211,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Palworld가 실제로 필요한 것만 열기

허용 두 개면 충분하고, 두 번째는 선택 사항입니다. UFW에서는 다음과 같으며, 스스로 접속이 막히지 않도록 반드시 이 순서를 지키세요.

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld 게임 트래픽'
ufw allow 27015/udp comment 'Palworld Steam 쿼리'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

서버를 커뮤니티 서버 목록에 올리지 않으려면 세 번째 줄은 빼세요. 그러면 플레이어는 계속 IP 주소와 포트 8211로 접속하고, 서버는 공개 목록에서만 사라집니다. 복구 방법까지 포함한 전체 안내는 스스로 접속이 막히지 않게 UFW 방화벽 설정하기에 있습니다.

3. 25575의 RCON과 8212의 REST API를 인터넷에서 빼기

두 포트 모두 서버를 완전히 통제할 수 있는 관리 접속이고, 둘 다 공장 설정에서 꺼져 있습니다. RCONEnabled=False와 RESTAPIEnabled=False입니다. 이것을 켜는 사람은 그로써 무엇을 공개하는지 알아야 합니다.

8212 TCP의 REST API는 고정된 사용자 이름 admin과 AdminPassword의 값으로 HTTP Basic Auth 인증을 하며, 그것도 암호화되지 않은 HTTP를 통해서 합니다. 따라서 관리 비밀번호가 요청 하나하나마다 되돌릴 수 있는 형태로 회선을 지나갑니다. 25575 TCP의 RCON도 마찬가지로 암호화되지 않은 텍스트 프로토콜이며, Pocketpair는 REST API를 택하면서 이를 구식으로 표시했습니다. 새 설치에서는 REST API가 올바른 선택이고, 둘 모두에 같은 원칙이 적용됩니다. 공개 네트워크에 두지 않는 것입니다.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="긴 무작위 값"

인터페이스는 SSH 포트 포워딩으로 닿게 만들고, 그다음 로컬에서 127.0.0.1:8212를 상대로 작업합니다.

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

AdminPassword는 절대 비워 두지 마세요. 비어 있는 것이 기본값입니다. openssl rand -base64 32의 값이면 충분합니다. ServerPassword도 마찬가지이며, 이는 곧 다시 다룹니다.

4. 목록 등록을 잃지 않으면서 쿼리 포트 27015 제한하기

연결 없는 Steam 패킷은 네 바이트가 모두 켜진 값(0xffffffff)으로 시작하고, 정상적인 게임 트래픽에는 이 머리가 없습니다. 여기에 출발지 주소별 속도 제한을 걸면 조회는 제동을 걸면서 목록 등록은 유지됩니다. nft -f로 불러오는 nftables에서는 다음과 같습니다.

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

우선순위 -10은 이 규칙이 UFW의 필터 체인보다 먼저 걸리게 하고, @th,64,32는 UDP 머리 뒤의 첫 네 바이트를 읽습니다. 고전적인 iptables에서는 A2S_INFO의 식별 문자열을 비교해 같은 구분을 해냅니다.

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

주소별 초당 조회 열 번은 넉넉하게 잡은 값입니다. 목록 서비스는 보통 몇 분에 한 번 조회하고, 1초에 여러 번 조회하지는 않습니다. 중요한 것은 이 규칙이 8211이 아니라 27015에 걸려 있어야 한다는 점뿐입니다. 그러지 않으면 자기 플레이어를 때립니다.

5. 8211 UDP의 패킷 전송률 제한하기

게임 포트 자체에서는 출발지 주소별 상한이 소수의 출발지에서 오는 작은 플러드에 도움이 됩니다. Palworld에서는 이 한계를 설정하는 것이 비교적 위험하지 않습니다. 동시에 접속한 플레이어가 최대 32명이고, 각각이 정확히 하나의 출발지 주소를 차지하기 때문입니다.

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

이 숫자는 출발점일 뿐이고 정답이 아닙니다. 플레이어 32명과 거점이 많은 꽉 찬 서버는 네 명이 하는 한 판보다 훨씬 많은 패킷을 만들고, 너무 좁게 설정하면 자기 플레이어를 내쫓습니다. 먼저 평상시 운영에서 한 주를 측정하고, 그다음 측정한 최고값의 두 배로 한계를 잡으세요.

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에 머물러 있으면 그 규칙은 걸리지 않는 것입니다.

6. 슬롯 고갈에 맞서는 서버 비밀번호, 차단 목록, 그리고 32개의 자리

슬롯 고갈은 Palworld 서버를 향한 가장 값싼 공격이고 대역폭이 필요하지 않습니다. 전용 서버에는 자리가 최대 32개이므로 동시 연결 32개면 커뮤니티 전체가 들어오지 못하게 막을 수 있습니다. 볼류메트릭 공격은 의뢰인에게 돈이 들지만, 32개의 세션은 아무 비용도 들지 않습니다. 그래서 이 길은 작은 서버를 상대로는 어떤 플러드보다 매력적입니다.

Palworld에는 내장된 허용 목록이 없습니다. 운영 도구는 강제 퇴장, 차단, 그리고 서버 비밀번호이고, 슬롯 고갈에 맞서 가장 효과적인 단일 조치가 바로 이 서버 비밀번호입니다.

ServerPassword="여러분의 그룹만 아는 값"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword는 공장 설정에서 비어 있으므로 IP 주소와 포트를 아는 사람은 누구나 들어옵니다. BanListURL은 기본적으로 Pocketpair가 관리하는 목록을 가리키며, 프로젝트 자체의 차단을 운영하려면 자체 텍스트 파일로 돌릴 수 있습니다. ServerPlayerMaxNum은 32를 넘겨 설정하지 마세요. 더 높은 값은 지원되지 않고, 늦어도 다음 업데이트에서 발목을 잡습니다. 그리고 한 가지는 분명해야 합니다. 서버 비밀번호는 여러분의 자리를 지켜 주지만 회선을 지켜 주지는 않습니다. 서버를 플러딩하는 공격자는 애초에 들어올 생각이 없습니다.

7. 연결 추적의 부담을 덜고 버퍼를 키우기

이 항목은 볼륨 공격처럼 보이지만 실제로는 아닌 장애를 설명해 줍니다. 커널은 UDP 트래픽을 위해 연결 추적(conntrack)에 항목을 만들고, 출발지 주소가 위조되어 있으면 주소마다 새 항목이 생깁니다. 테이블이 가득 차면 커널은 구분 없이 패킷을 폐기하므로 공격과 여러분의 플레이어가 함께 튕기고, 로그에는 “nf_conntrack: table full”이 남습니다. 현재 값과 상한은 다음 명령이 보여 줍니다.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

가장 효과적인 방법은 게임 트래픽을 애초에 추적하지 않는 것입니다. Palworld는 자기 세션을 스스로 관리하기 때문입니다.

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

iptables에서 이에 대응하는 것은 iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK이고, OUTPUT에는 --sport로 같은 줄을 씁니다. 그다음 두 포트에는 명시적인 허용이 필요합니다. 추적이 없으면 기존 상태를 검사하는 규칙은 더 이상 걸리지 않기 때문입니다. 서버 프로세스가 가져가는 것보다 패킷이 빨리 도착하면 여기에 더해 수신 버퍼가 넘칩니다. 플레이어에게는 회선이 한가한데도 패킷 손실처럼 보입니다. /etc/sysctl.d/ 아래에 얹고 sysctl -p로 적용합니다.

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

이 값들이 필요한지는 커널이 직접 알려 줍니다. nstat -az의 UdpRcvbufErrors가 올라간다면 값이 효과를 냅니다. 카운터가 0에 머물러 있으면 이 조정은 아무것도 바꾸지 않습니다.

8. 상황이 심각해지기 전에 측정값 모으기

가장 중요하면서 거의 아무도 미리 하지 않는 단계가 있습니다. 모든 것이 정상으로 돌아가는 동안에 기준값을 만들어 두는 것입니다. 평상시 값이 없으면 사건이 끝난 뒤에 초당 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 -c 200 "udp port 8211 or udp port 27015"

tcpdump에는 원칙이 있습니다. 항상 -c로 개수를 제한하세요. 과부하 상태에서의 캡처는 이미 과부하인 서버에 부담을 더 얹습니다. Palworld는 여기에 다른 어떤 도구도 갖지 못한 측정값을 하나 더 내줍니다. REST API가 켜져 있으면 메트릭 엔드포인트가 그중에서도 서버의 프레임 레이트, 현재 플레이어 수, 실행 시간을 돌려줍니다.

curl -s -u admin:YOUR_ADMIN_PASSWORD http://127.0.0.1:8212/v1/api/metrics

이 한 숫자가 가장 흔한 두 원인을 깔끔하게 갈라 줍니다. 패킷 전송률은 평범한데 서버 프레임 레이트가 무너진다면 공격이 아니라 부하이거나, 서버 프로세스에서 알려진 메모리 증가입니다. 프레임 레이트는 안정적인데 수신 패킷이 평상시 값을 크게 넘어 오른다면 공격입니다. 네트워크 값을 하나하나 어떻게 해석하는지는 서버에서 DDoS 공격 알아내기에 있습니다.

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

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

한번 계산해 보겠습니다. 일반적인 게임 서버는 1 Gbit/s 회선에 물려 있고, 이는 초당 125 메가바이트이며, 누군가 그보다 많이 보내는 순간 회선은 꽉 찹니다. 게임 서버 프로젝트를 향한 공격은 보통 5에서 50 Gbit/s 사이, 곧 여러분 회선의 5배에서 50배입니다. 그 뒤에 있는 여러분의 iptables 규칙이 훌륭한지는 그때 더 이상 상관이 없습니다. 플레이어의 패킷이 그 앞에서 이미 통과하지 못하기 때문입니다.

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

Palworld 서버에는 불리한 비율이 더해집니다. 플레이어 32명으로 꽉 찬 서버도 1 Gbit/s 회선의 일부만 쓸 뿐입니다. 따라서 공격은 평상시 운영의 몇 배에 이르기 위해 클 필요가 없고, 바로 그래서 여기서는 큰 플랫폼에서라면 눈에 띄지도 않을 공격으로도 충분합니다.

어느 정도 규모가 실제로 나타나는지 가늠하기 위해 덧붙입니다. 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 주소를 네트워크에서 빼 버리면 여러분에게는 공격자와 같은 결과를 내는 셈입니다. Palworld는 자체 방어 프로필이 있는 게임에 속하며, 어떤 타이틀과 프로토콜이 더 포함되는지는 실시간 게임 서버 DDoS 방어에 정리되어 있습니다.

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

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

• 프랑크푸르트 코어에서 발급되는 전용 방어 IP이며, 서버는 자체 네트워크에서 이 IP로 전환됩니다. 여러분 쪽에서 손볼 것은 없습니다.
• 포트와 프로토콜별로 직접 관리하는 방어 규칙을 고객 포털에서 다룹니다. 8211 UDP에 무엇을 허용할지와 27015 UDP에 무엇을 허용할지를 티켓을 쓰지 않고 따로 정합니다.
• 변경은 실시간으로 반영되므로 공격이 진행되는 중에도 값을 조정할 수 있습니다. 예를 들어 쿼리 포트를 한동안 더 강하게 제한하고 게임 포트는 그대로 두는 식입니다.
• 게임에 맞춘 방어 프로필이 Palworld에도, 임의의 TCP 또는 UDP 포트에서 돌아가는 자체 애플리케이션에도 준비되어 있습니다.

Advanced DDoS Protection은 KernelHost에 놓여 있는 서버를 대상으로 합니다. Palworld 프로젝트를 지금 다른 곳에서 운영하면서 계속 공격받는 운영자는 이를 위해 KernelHost로 옮기고, 그러면 두 단계가 서버 제공 시점부터 동작합니다.

두 단계 비교

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

Palworld 서버에서 자주 나오는 실수와 그 해결 방법

“27015를 막았더니 서버가 커뮤니티 목록에서 사라졌습니다”: 그것이 예상되는 동작입니다. 쿼리 포트가 목록 등록을 떠받치기 때문입니다. 일괄 차단하지 말고 4단계처럼 연결 없는 패킷을 출발지 주소별로 제한하세요. 목록 등록이 어차피 필요하지 않다면 포트를 닫아 두고 -publiclobby를 지우고, 플레이어에게 직접 연결용으로 IP 주소와 포트 8211을 알려 주세요.

“IP 주소를 바꿨는데 두 시간 뒤에 다시 오프라인이 되었습니다”: 공격자는 새 주소를 옛 주소와 같은 곳에서 얻었습니다. Palworld에서는 거의 항상 세 경로 가운데 하나입니다. 어차피 직접 연결 입력란에 주소를 적어 두고 있는 플레이어, 그것을 다시 공개하는 상태 표시 Discord 봇, 또는 이전 주소를 가리키는 DNS의 오래된 A 레코드입니다. 주소 변경은 시간을 벌어 주지만 해결책은 아닙니다.

“서버에 랙 스파이크가 있는데 회선은 한가합니다”: Palworld에서는 이것이 공격보다 부하인 경우가 더 많습니다. 서버 프로세스는 실행 시간이 길어지면서 메모리를 꾸준히 더 차지하므로, 계획된 재시작은 정상 운영의 일부이고 임시 방편으로 이해할 것이 아닙니다. 메트릭 엔드포인트로 서버 프레임 레이트를, 그리고 프로세스의 메모리 사용량을 확인하세요. 그러면서 sar -n DEV 1 10이 평범하게 나온다면 DDoS 공격이 아니었습니다.

“32개 자리가 모두 차 있는데 게임 안에는 아무도 보이지 않습니다”: 그것이 슬롯 고갈이고, 회선이 아니라 게임 로직을 때립니다. ServerPassword를 설정하고, 이상한 계정은 차단 목록으로 막고, 8211 UDP에서 출발지 주소별 패킷을 제한하세요.

“REST API가 며칠 동안 외부에 열려 있었습니다”: 그렇다면 관리 비밀번호가 유출된 상태입니다. 암호화되지 않은 HTTP를 통한 HTTP Basic Auth는 요청마다 비밀번호를 되돌릴 수 있는 형태로 전송하기 때문입니다. AdminPassword를 바꾸고, 8212 TCP를 외부로 닫고, 인터페이스는 SSH 포트 포워딩으로만 닿게 하세요.

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

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

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

핵심 요약

• Palworld 서버에는 열어야 할 포트가 정확히 하나, 8211 UDP입니다. 쿼리 포트 27015 UDP는 커뮤니티 서버 목록 등록에만 필요합니다.
• 25575 TCP의 RCON과 8212 TCP의 REST API는 절대 공개 네트워크에 두어서는 안 됩니다. 둘 다 접속 정보를 암호화하지 않고 전송하기 때문입니다. RCON은 여기에 더해 Pocketpair가 구식으로 표시했습니다.
• Palworld에서는 게임 트래픽과 서버 쿼리가 서로 다른 포트에 놓여 있으므로, 8211 UDP에서 진행 중인 게임 트래픽을 건드리지 않고 27015 UDP를 강하게 제한할 수 있습니다.
• 전용 서버는 자리가 32개로 제한되어 있어서 슬롯 고갈이 가장 값싼 공격입니다. 이에 맞서 가장 효과적인 단일 조치는 설정된 ServerPassword입니다. Palworld에는 내장된 허용 목록이 없기 때문입니다.
• 로컬 조치는 회선에서 끝납니다. 1 Gbit/s는 초당 125 메가바이트이고, 64 바이트짜리 패킷이라면 초당 약 149만 개가 들어갑니다. 그 위의 모든 것은 서버 앞단 네트워크에서 끝나야 합니다.
• KernelHost에서는 2단계 상시 방어가 모든 서버 상품에 추가 요금 없이 포함되어 서버 제공 시점부터 동작하며, null-routing을 쓰지 않습니다. 전용 방어 IP와 포트별로 직접 관리하는 규칙을 갖춘 Advanced DDoS Protection은 월 50.00 EUR부터 시작합니다.

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