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

저녁마다 몇 분씩 서버 목록에서 사라졌다가 다시 돌아오는 Minecraft Bedrock 서버는 하드웨어 문제인 경우가 드뭅니다. 대개는 공격이 진행 중이고, 그것도 플레이어가 가장 많이 접속해 있는 시간에 딱 맞춰 벌어집니다. 이 글은 Minecraft Bedrock 서버를 DDoS 공격으로부터 방어하는 방법을 다룹니다. 먼저 추가 비용 없이 직접 조치할 수 있는 것을 보여 주고, 그다음 그 조치가 물리적으로 어디에서 한계에 이르는지, 마지막으로 서버 앞단 네트워크에서 무엇이 이뤄져야 하는지 설명합니다.

모든 내용은 Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 운영하는 Bedrock Dedicated Server, PocketMine-MP 또는 Nukkit을 기준으로 합니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요. Java Edition을 운영한다면 그쪽에서 전형적인 프로토콜 공격은 Minecraft DDoS 방어와 nullping 방어에 정리되어 있습니다. Bedrock 서버의 설치 자체는 Nukkit으로 Minecraft Bedrock 서버 설치하기에서 다룹니다.

공격이 지금 진행 중이라면: 설정을 바꾸지 마시고 서버를 재시작하지 마세요. 먼저 측정값부터 확보하세요(“터지기 전에 측정값 모으기” 절). 공격이 끝나면 그 값은 되돌릴 수 없이 사라집니다.

Minecraft Bedrock 서버가 DDoS 공격의 표적이 되는 일이 그토록 잦은 이유

Bedrock Edition은 콘솔, 스마트폰, 태블릿, Windows에서 돌아가는 판본이고, Minecraft 전체에서 가장 큰 플레이어층을 이룹니다. 서버가 많은 곳에 공격 동기도 가장 크게 생깁니다. 경쟁하는 네트워크, 차단된 플레이어, 내부 갈등이 그것입니다. 공격을 시작하는 쪽은 실력도 이렇다 할 비용도 들이지 않습니다. 서버 booter는 정기 구독으로 팔립니다.

기술적인 이유는 더 깊은 곳에 있습니다. Bedrock 서버는 TCP가 아니라 UDP로 말하고, 어떤 로그인도 일어나기 훨씬 전에 묻는 상대 모두에게 응답합니다. 바로 이 두 가지 성질이 19132 UDP 포트를 손쉬운 표적으로 만듭니다. DDoS 공격이 기본적으로 무엇인지는 DDoS 공격이란 무엇인가? 글에서 설명합니다.

RakNet: 아무도 로그인하기 전에 응답하는 UDP 프로토콜

RakNet은 Minecraft Bedrock Edition이 게임 트래픽 전체를 처리하는 데 쓰는 UDP 네트워크 라이브러리입니다. UDP에는 서버가 요구할 수 있는 연결 수립 절차가 없고, 그래서 출발지 주소는 위조할 수 있습니다. RakNet은 그 위에 자체 신뢰성 계층을 올립니다. 시퀀스 번호, 확인 응답(ACK), 그리고 클라이언트가 잃어버린 패킷을 다시 요청할 수 있는 부정 확인 응답(NAK)이 그것입니다.

연결 수립은 패킷 일곱 개로 이뤄지며, 네 개는 클라이언트에서, 세 개는 서버에서 옵니다.

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

클라이언트는 그다음에야 Xbox Live 인증 정보를 담은 로그인 패킷을 보냅니다. Bedrock 서버를 지키려는 사람에게 결정적인 문장이 바로 이것입니다. 서버는 누가 문을 두드리는지 알기도 전에 패킷 일곱 개를 처리하고, 연산 시간과 메모리를 쓰고, 여러 번 응답을 보냈습니다. 따라서 로그인 단계에 걸어 둔 모든 조치는 부하가 이미 발생한 뒤에야 작동합니다.

여기에 더 이른 두 번째 진입점이 더해집니다. 서버가 어느 플레이어의 서버 목록에 이름, 버전, 플레이어 수와 함께 나타나려면 Unconnected Ping(패킷 ID 0x01)에 Unconnected Pong(패킷 ID 0x1C)으로 응답해야 합니다. 이 주고받기는 실제 연결 수립보다 먼저 일어나고, 어떤 인증도 요구하지 않으며, Bedrock Dedicated Server에서는 서버를 모든 서버 목록에서 빼지 않고는 끌 수 없습니다.

증폭 수단으로서의 Unconnected Ping: 숫자로 보기

증폭 공격(Amplification)은 공격자가 출발지 주소를 위조한 작은 요청을 남의 서버에 보내, 그 서버의 더 큰 응답이 피해자에게 쏟아지게 만드는 공격입니다. 이때 Bedrock 서버는 공격을 받는 것이 아니라 이용당합니다. Unconnected Ping의 계산은 다음과 같습니다.

여기서 두 가지가 곧바로 따라옵니다. 첫째, 서버 이름이 길면 응답이 커지고, 그만큼 여러분이 외부 공격자에게 내주는 증폭 계수도 커집니다. 짧은 이름은 겉모습 문제가 아니라 방어 조치입니다. 둘째, 기본 설정의 계수 4는 여러분의 서버가 반사 도구로 쓰일 만큼 매력적이지는 않을 정도로 작지만, 핑 플러드가 들어오는 양의 네 배로 여러분의 송신 회선을 짓누를 만큼은 큽니다.

2024년의 증폭 결함은 신뢰성 계층 자체가 악용될 때 사태가 얼마나 나빠질 수 있는지를 보여 줍니다. 당시 쓰던 RakNet 라이브러리에서는 Connection Request Accepted 패킷이 신뢰성 있는 패킷으로 표시되어 있었습니다. 공격자는 출발지 주소를 위조한 채 연결 수립을 이 지점까지 진행하고, 그다음 0부터 8191까지의 범위를 담은 부정 확인 응답 하나만 보낼 수 있었습니다. 그러면 서버는 공격자가 더 아무것도 하지 않아도 위조된 주소로 수천 개의 패킷을 보냈습니다. 해결은 세 가지로 이뤄졌습니다. 이 패킷을 신뢰성 없는 패킷으로 바꾸고, Open Connection Reply 1에 진짜 클라이언트라면 그대로 되돌려 보내는 쿠키를 함께 실어 보내고, 패킷 상한을 도입했습니다. 출발지 주소마다 10밀리초 단위로 120패킷, 단위마다 전체 1,000패킷입니다.

Bedrock Edition과 Java Edition: DDoS 방어에서 달라지는 점

Java 서버를 한 번 지켜 본 사람은 거의 모든 것을 잘못 옮겨 옵니다. 두 에디션은 이름을 공유하지만 네트워크 프로토콜은 공유하지 않습니다.

SYN 쿠키 줄이 가장 중요합니다. Java Edition에서는 Linux 커널이 SYN 플러드를 막아 내고, Minecraft 프로세스는 그 사실을 알아차리지도 못합니다. Bedrock Edition에는 이 도움이 없습니다. UDP 패킷 하나하나가 서버 프로세스까지 전달되어 거기서 해석됩니다. Bedrock 서버에는 19132 포트로 들어오는 플러드에 맞설 운영체제의 내장 방어가 없습니다. UDP에 그런 것이 없기 때문입니다.

SRV 레코드가 없다는 줄에는 많은 사람이 놀라는 실무적 결과가 따릅니다. Bedrock Edition에서는 포트를 DNS 항목 뒤에 숨길 수 없습니다. 플레이어가 주소와 포트를 손으로 입력하기 때문입니다. 포트를 옮기는 사람은 모든 플레이어에게 새 포트를 알려야 합니다.

실제로 문제가 되는 포트

Bedrock Dedicated Server는 정확히 두 개의 포트에 바인딩되며, 둘 다 UDP입니다. server.properties에서는 다음과 같습니다.

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

이것이 Microsoft의 기본값이며, Bedrock Dedicated Server 참고 문서에서 확인할 수 있습니다. 이 두 포트 주변에는 서버 소프트웨어에 따라 함께 돌아가는 다른 서비스가 놓입니다.

세 번째와 네 번째 줄이 Bedrock 서버에서 가장 흔하게 나오는, 그리고 피할 수 있는 실수입니다. Nukkit과 PocketMine-MP에서는 enable-query가 공장 기본값으로 켜져 있고, Nukkit에서는 실수로 켠 RCON이 19132 TCP에, 곧 게임과 같은 포트 번호에 올라앉습니다. “19132가 열려 있으니 괜찮다”만 보는 사람은 이것을 놓칩니다.

공식 Bedrock Dedicated Server의 특이점도 여기에 속합니다. 이 서버에는 server-ip 지시어가 없습니다. PocketMine-MP와 Nukkit에는 있지만(server-ip, PocketMine에는 server-ipv6까지), 공식 서버에는 없습니다. 그래서 항상 시스템의 모든 주소에서 대기하며, 이를 제한할 유일한 수단은 방화벽입니다.

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

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

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

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

ss -lntup
ss -lnup sport = :19132

여기서 중요한 것은 로컬 주소 열입니다. 0.0.0.0:19132와 [::]:19133은 “인터넷 전체에서 접근할 수 있음”을 뜻합니다. 그 옆에 같은 포트 번호의 TCP 항목이 나타난다면 RCON이 돌고 있습니다. 공격자의 시선은 외부에서 실행하는 포트 스캔이 보여 주며, UDP에는 -sU를 씁니다.

nmap -Pn -sU -p 19132,19133 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 19132 UDP만 열어 두고 나머지는 모두 닫기

Bedrock 서버에는 외부로 단 하나의 허용이면 충분하고, IPv6까지 쓰면 둘입니다. UFW에서는 다음과 같이 하며, 스스로 접속이 막히지 않도록 반드시 이 순서를 지키세요.

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

IPv6 플레이어가 없다면 19133 줄을 빼고, PocketMine-MP에서는 enable-ipv6=false까지 설정하세요. 허용하지 않은 포트는 지킬 필요가 없는 포트입니다. 복구 방법까지 포함한 전체 안내는 스스로 접속이 막히지 않게 UFW 방화벽 설정하기에 있습니다.

3. LAN 노출을 끄지 않으면 19132는 계속 열려 있습니다

포트를 옮기려는 사람 거의 모두가 빠지는 함정이 이것입니다. enable-lan-visibility 지시어는 공장 기본값이 true이고, 서버가 로컬 네트워크의 검색 요청에 응답하도록 만듭니다. Microsoft는 이 때문에 server-port와 server-portv6에 다른 값이 들어 있어도 서버가 기본 포트 19132와 19133에 추가로 바인딩된다고 분명히 적어 두었습니다.

그러니 포트를 19140으로 옮기고 안심한 사람은 여전히 19132에서 대기하고 있는 셈입니다. 인터넷에 놓인 서버라면 server.properties에 다음이 들어가야 합니다.

enable-lan-visibility=false

그다음 ss -lnup으로 19132가 정말 사라졌는지 확인하세요. 덧붙여 같은 설정은 한 호스트의 Bedrock 서버 두 대가 서로 포트를 빼앗는 문제도 해결합니다.

4. 쿼리와 RCON 끄기

PocketMine-MP와 Nukkit에는 GS4 쿼리가 들어 있습니다. UT3 프로토콜 방식의 UDP 서버 조회이고, 이 조회에 게임이 돌아가는 바로 그 19132 포트에서 응답합니다. 자세한 응답에는 서버 이름, 버전, 월드 이름, 허용 목록 상태, 주소와 포트, 플레이어 수, 접속한 모든 플레이어의 이름이 담기고, PocketMine-MP에서는 원한다면 전체 플러그인 목록까지 들어갑니다. 상태 페이지나 Discord 봇에는 편리하지만, 공격자에게는 언제 공격할 만한지를 정확히 알려 주고, 조회마다 연산 시간을 씁니다.

enable-query=off
enable-rcon=off

PocketMine-MP에서는 값이 off가 아니라 false이고, 플러그인 목록은 pocketmine.yml에서 settings.query-plugins: false로 끕니다. 좀처럼 읽기 어려운 평가를 덧붙이면, PocketMine-MP의 GS4 쿼리는 출발지 주소를 함께 섞어 만든 토큰을 검사합니다. 그래서 큰 응답을 위조된 주소로 반사시킬 수는 없습니다. 다만 조회는 여전히 연산 시간을 쓰고, 공개된 데이터는 공격자의 표적 선정을 돕습니다. 공식 Bedrock Dedicated Server에는 쿼리도 RCON도 없으므로 이 항목은 해당되지 않습니다.

RCON이 실제로 필요하다면 Nukkit에서는 반드시 rcon.port에 별도의 값을 주고, 그 포트를 본인 주소에만 허용하세요. 그러지 않고 server-port로 되돌아가면, 서버의 원격 제어가 19132 TCP에서, 곧 여러분이 어디에나 “열려 있음”으로 적어 둔 바로 그 번호에서 대기하게 됩니다.

5. Xbox Live 인증 강제하기

Xbox Live 인증은 접속하려는 플레이어가 Microsoft가 서명한 진짜 계정을 가지고 있는지 검사하는 절차입니다. 세 가지 서버 소프트웨어 모두에서 공장 기본값으로 켜져 있고, 그대로 두어야 합니다.

Bedrock Dedicated Server에서 지시어 이름은 online-mode이고, PocketMine-MP와 Nukkit에서는 xbox-auth입니다. 두 경우 모두 true가 공장 상태이며 올바른 값입니다.

online-mode=true
xbox-auth=true

Microsoft는 여기에 중요한 제한을 덧붙입니다. 로컬 네트워크 밖의 서버에 접속하는 클라이언트는 이 설정과 무관하게 언제나 Xbox Live 인증이 필요합니다. 인증 정보는 서명된 토큰 사슬로 로그인 패킷에 실려 전달되며, Xbox 식별자(XUID)와 표시 이름이 함께 들어갑니다.

그리고 오해를 막아 주는 부분이 있습니다. Xbox Live 인증은 여러분의 게임 로직을 지키고, 회선을 지키지는 않습니다. 이 검사는 로그인 패킷에서, 곧 RakNet 연결 수립이 모두 끝난 뒤에 일어납니다. 여러분의 서버를 플러딩하는 공격자는 애초에 접속할 생각이 없습니다. 그 패킷은 거부되지만 이미 도착해 있고, 바로 그 점이 핵심입니다.

6. 허용 목록과 플레이어 상한, 그리고 그것이 못 하는 일

허용 목록(예전 이름은 whitelist)은 접속해도 되는 플레이어의 목록입니다. Bedrock Dedicated Server에서는 allow-list=true로 켜고, 항목은 이름, XUID, ignoresPlayerLimit 필드와 함께 allowlist.json에 들어갑니다. Nukkit과 PocketMine-MP에서는 지시어 이름이 계속 white-list입니다.

allow-list=true
max-players=60
player-idle-timeout=15

player-idle-timeout으로 유휴 시간을 짧게 두면 슬롯 고갈에 효과가 있습니다. 자리만 차지하고 있는 플레이어는 지정한 분 수가 지나면 밖으로 나갑니다. 값 0은 아무도 무활동 때문에 끊기지 않는다는 뜻이고, 실제 계정으로 여러분의 자리를 막아 두는 공격자가 바로 이것을 이용합니다.

여기에도 앞 절의 한계가 그대로 적용되며, 이것이 가장 자주 간과되는 지점입니다. 허용 목록은 로그인 패킷이 처리된 뒤에야 검사됩니다. 접속은 막아 주지만 패킷은 막아 주지 않습니다.

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

작은 공격과 엉성한 봇에는 출발지 주소별 상한이 도움이 됩니다. UDP에서는 connlimit이 아니라 hashlimit을 씁니다. UDP에는 연결이라는 것이 없기 때문입니다.

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

이 규칙은 같은 출발지 주소가 초당 400개를 지속적으로 넘겨 보내는 순간 UDP 패킷을 폐기합니다. 이 값은 출발점일 뿐이고 정답이 아닙니다. 60명이 들어차고 시야 거리가 넓은 서버는 빈 서버보다 훨씬 많은 패킷을 만들고, 너무 좁게 잡으면 자기 플레이어를 내쫓습니다. 먼저 평상시 운영에서 한 주는 측정하세요.

Unconnected Ping에는 훨씬 더 좁게 잡아도 됩니다. 진짜 클라이언트는 서버 목록이 열려 있는 동안에만, 그것도 1초에 한 번 정도로 서버 상태를 묻기 때문입니다. nftables에서는 패킷 ID가 UDP 헤더 바로 뒤 첫 바이트이므로 바로 이 패킷 하나만 정확히 골라낼 수 있습니다.

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

@th,64,8 표현은 전송 헤더의 64번째 비트부터 8비트를 읽으므로, 곧 UDP 페이로드의 첫 바이트입니다. 0x01 값은 Unconnected Ping의 패킷 ID입니다. 무엇이든 폐기하기 전에 같은 자리를 관찰에 쓸 수도 있습니다.

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

첫 번째 줄은 들어오는 상태 조회를, 두 번째 줄은 여러분 자신의 응답을 셉니다. 플레이하는 사람은 거의 없는데 둘 다 초 단위로 수천 개에 이른다면, 그것은 여러분의 플레이어가 아니라 핑 플러드입니다.

지속성에 관한 안내가 두 가지 있습니다. iptables 규칙만 쓰면 재시작 후에 사라지므로 Debian과 Ubuntu에서는 다음과 같이 저장합니다.

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

그리고 UFW를 쓴다면 이런 규칙은 /etc/ufw/before.rules에 들어가야 합니다. 그러지 않으면 다음 ufw reload에서 사라집니다.

8. 커널의 연결 추적 부담 덜기

UDP 게임에서는 TCP보다 훨씬 이른 시점에 닥치는 병목이 있습니다. 커널은 UDP 패킷 한 쌍마다 연결 추적에 항목을 만듭니다. 출발지 주소가 위조된 플러드에서는 패킷마다 새 출발지 주소이고, 따라서 새 항목입니다. 테이블이 가득 차면 서버는 정상 패킷까지 폐기하고, 로그에는 “nf_conntrack: table full, dropping packet”이 남습니다.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

카운터가 계속 상한 가까이에 머문다면 게임 트래픽을 추적에서 뺄 수 있습니다. 효과는 있지만 대가가 없지는 않으므로, 양쪽 방향 모두에 적용하고 그다음 접속 시험을 하세요.

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

이후로는 이 트래픽에 상태 기반 규칙이 더 이상 적용되지 않습니다. 그러니 19132 UDP 허용은 진짜 포트 허용이어야 하고, ESTABLISHED 상태에 의존해서는 안 됩니다. 설정한 뒤에 conntrack -L | grep 19132로 항목이 더 생기지 않는지 확인하고, 규칙을 영구 저장하기 전에 게임으로 한 번 접속해 보세요.

9. Geyser와 Floodgate를 깔끔하게 운영하기

Geyser는 Bedrock 클라이언트가 Java Edition 서버에서 플레이할 수 있게 해 주는 브리지입니다. 19132 UDP에서 Bedrock 연결을 받아 프로토콜을 변환하고, 반대쪽에서는 25565 TCP로 Java 서버와 이야기합니다. Floodgate는 이 Bedrock 플레이어가 Java 계정 없이 접속할 수 있게 해 주는 보완 구성 요소입니다. DDoS 방어 관점에서는 세 가지를 뜻합니다.

첫째, Geyser를 최신으로 유지하세요. 바로 이 브리지가 문서로 확인된 공격의 원인이 된 적이 두 번 있습니다. 2024년 3월에는 위에서 설명한 RakNet 라이브러리의 증폭 결함이 널리 악용되었고, 빌드 478에서 수정되었습니다. 2025년 7월에는 두 번째 사례가 뒤따랐습니다. 리소스 팩 확인용 패킷이 반복해서 전송되면서 플레이어마다 여러 세션이 생겼고, 네트워크 채널이 닫히지 않아 연결이 끊긴 클라이언트도 계속 패킷을 보낼 수 있었습니다. 빌드 897에서 수정되었습니다. 두 사례 모두 프로젝트가 직접 경과 시간표와 함께 공개했습니다.

둘째, Java 서버는 공개 네트워크에 두지 마세요. Geyser 설정에서 remote.address는 auto 또는 127.0.0.1을, remote.port는 25565를 가리킵니다. Java 서버를 그에 맞게 로컬에 바인딩하고, 25565 TCP는 외부로 열지 마세요. 그러지 않으면 공격 표면이 하나가 아니라 둘이 되고, 두 번째 것은 여러분이 규칙을 한 번도 고민해 보지 않은 쪽입니다.

셋째, key.pem 파일은 비밀입니다. 이 파일은 Floodgate가 Bedrock 계정에 대해 Java 인증을 건너뛰게 해 주는 열쇠입니다. 이것을 공개 저장소에 올리거나 지원 티켓에 복사하거나 화면 캡처에 드러내는 사람은 자기 서버의 로그인을 그냥 내준 셈입니다. 프로젝트도 이를 분명히 경고합니다.

10. 터지기 전에 측정값 모으기

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

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

이 가운데 세 값이 Bedrock 서버에서 특히 많은 것을 말해 줍니다. 19132의 UDP 소켓에서 Recv-Q가 계속 0이 아니라면, 서버 프로세스가 들어오는 패킷을 더 이상 제때 가져가지 못한다는 뜻입니다. UdpRcvbufErrors는 그래서 폐기된 패킷을 정확히 세며, 병목이 회선이 아니라 프로세스라는 가장 단단한 증거입니다. UdpNoPorts는 아무것도 대기하지 않는 포트를 누가 두드릴 때 올라가고, 본격적인 공격에 앞서 넓게 퍼진 포트 스캔이 있을 때 전형적으로 나타나는 모습입니다.

tcpdump에는 한 가지 원칙이 있습니다. 항상 -c로 개수를 제한하세요. 과부하 상태에서의 캡처는 이미 과부하인 서버에 부담을 더 얹습니다. 측정값을 해석하는 방법은 DDoS 공격 알아내기에 있습니다.

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

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

한번 계산해 보겠습니다. 누군가 초당 125 메가바이트보다 많이 보내는 순간 여러분의 회선은 꽉 찹니다. 5 Gbit/s에서 50 Gbit/s에 이르는 공격은 그 다섯 배에서 오십 배입니다. 그 뒤에 있는 hashlimit 규칙이 훌륭한지는 그때 아무 의미가 없습니다. 플레이어의 패킷이 그 앞에서 이미 통과하지 못하기 때문입니다.

두 번째 수치는 패킷 전송률이고, Bedrock 서버에서는 거의 항상 이쪽이 먼저 터집니다. 게임 트래픽 전체가 작은 UDP 패킷 여러 개로 이뤄져 있고, 공격자가 가장 값싸게 움직일 수 있는 종목이 바로 이것입니다. 회선을 3분의 1도 채우지 못하는 공격이 그래도 여러분의 서버를 멈춰 세울 수 있습니다. 패킷을 해석하고 폐기하는 데 연산 시간이 들어가기 때문입니다. 운영자는 이것을 “사용률은 전혀 높지 않았는데 그래도 전부 죽었다”로 경험합니다. 게임 안에서는 같은 일이 랙 스파이크, 고무줄 현상, 건축 도중의 연결 끊김으로 나타납니다.

이에 대한 로컬 설정은 없습니다. 볼류메트릭 공격은 서버 앞단 네트워크에서 끝나야 합니다.

KernelHost가 Bedrock 서버를 향한 DDoS 공격에 맞서 제공하는 것

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

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

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

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

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

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

• 전용 방어 IP: 프랑크푸르트 코어에서 발급되며, 서버는 자체 네트워크에서 이 IP로 전환됩니다. 여러분 쪽에서 손볼 것은 없습니다.
• 포트와 프로토콜별로 직접 관리하는 방어 규칙: 고객 포털에서 19132 UDP에 무엇을 허용할지, 19133 UDP에 무엇을 허용할지, 그리고 서버를 옮겼다면 그 다른 포트에 무엇을 허용할지를 설정합니다.
• 변경은 실시간으로 반영: 유지보수 시간을 기다리지 않고 공격이 진행되는 중에도 값을 조정할 수 있습니다.
• 게임에 맞춘 방어 프로필. Minecraft에는 준비된 프로필이 있고, 임의의 TCP 또는 UDP 포트에서 돌아가는 개조된 애플리케이션과 자체 애플리케이션도 마찬가지입니다. 곧 Nukkit이나 PocketMine-MP, 직접 고른 포트의 Geyser 인스턴스도 해당됩니다.

두 단계 비교

대부분의 Bedrock 프로젝트에는 포함된 상시 방어와 깔끔한 서버 설정이면 충분합니다. Advanced DDoS Protection은 누군가 이 일을 개인적으로 받아들였을 때의 답입니다. 서버를 현재 다른 곳에서 운영하고 있다면 이전이 가장 빠른 해결책입니다. 필터링은 서버 앞단 네트워크에서 동작하고, 그 네트워크가 우리 것이어야 하기 때문입니다.

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

“포트를 19140으로 바꿨는데 19132가 그대로 열려 있습니다”: enable-lan-visibility=true 때문입니다. 그러면 Bedrock Dedicated Server는 server-port에 무엇이 들어 있든 19132와 19133에 추가로 바인딩됩니다. false로 바꾸고 서버를 재시작한 뒤 ss -lnup으로 확인하세요.

“allowlist.json을 편집했더니 제가 못 들어갑니다”: 흔한 원인이 두 가지입니다. 디렉터리에 옛 whitelist.json이 남아 있어서 서버가 그것을 대신 읽고 있거나, XUID 항목이 없거나 잘못되어 있습니다. Xbox Live 인증이 켜져 있으면 이름만으로는 믿을 만하게 동작하지 않습니다.

“공격을 받은 쪽은 저인데 호스팅 업체가 제 서버를 차단했습니다”: 서버가 스스로 패킷을 내보냈는지 확인하세요. 2024년 RakNet 증폭 결함에서 정확히 그런 일이 있었습니다. 해당 서버들이 남의 주소로 수천 개의 패킷을 보냈고, 어뷰즈 신고에는 출발지로 19132 포트가 적혀 있었습니다. tcpdump -ni eth0 'udp src port 19132' -c 200 -q로 서버가 어디에 응답하는지 볼 수 있습니다. 최신 빌드가 원인을 없애 줍니다.

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

“서버가 목록에는 있는데 아무도 들어오지 못합니다”: 항목에 이름과 플레이어 수가 보인다면 Unconnected Pong이 동작하는 것이므로 포트는 기본적으로 닿습니다. 그래도 접속이 실패한다면 대개 Xbox Live 로그인이나 허용 목록 때문입니다. 반대로 IPv6 플레이어만 못 들어온다면 19133 UDP 허용이 빠져 있습니다.

“서버는 돌아가는데 모두 랙 스파이크를 겪습니다”: 공격보다 플러그인일 때가 더 많습니다. 먼저 UDP 소켓의 Recv-Q가 늘어나는지, UdpRcvbufErrors가 올라가는지 확인하세요. 둘 다 조용하고 sar -n DEV 1 10에도 이상이 없으면 DDoS 공격이 아니라 서버 프로세스 자체였습니다. Bedrock Dedicated Server에서는 그럴 때 스크립트 워치독이 도움이 되며, 그 임계값은 server.properties의 script-watchdog-hang-threshold와 script-watchdog-slow-threshold에 있습니다.

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

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

핵심 요약

• Minecraft Bedrock 서버는 외부로 정확히 하나의 포트만 열려 있으면 됩니다. 19132 UDP이고, IPv6 플레이어를 위해서만 19133 UDP가 더해집니다. 쿼리, RCON, 19144 TCP의 스크립트 디버거, 25565 TCP에서 Geyser 뒤에 있는 Java 서버는 공개 네트워크에 두지 않습니다.
• 포트를 옮기는 사람은 enable-lan-visibility=false를 설정해야 합니다. 그러지 않으면 Bedrock Dedicated Server가 19132와 19133에 계속 추가로 바인딩됩니다.
• Xbox Live 인증과 허용 목록은 로그인 패킷에서, 곧 RakNet 연결 수립이 모두 끝난 뒤에 비로소 작동합니다. 게임 로직과 자리를 지켜 주지만 회선은 지켜 주지 않습니다.
• Unconnected Ping은 33 바이트로 요청되고 약 131 바이트로 응답되므로 증폭 계수가 약 4입니다. 짧은 서버 이름이 이 계수를 작게 유지해 줍니다.
• UDP에서는 connlimit이 아니라 hashlimit이 도움이 되고, 출발지 주소가 위조된 경우에는 커널의 연결 추적이 가장 먼저 가득 찹니다. 두 값 모두 첫 공격을 받기 전에 측정해 두어야 합니다.
• 대략 1 Gbit/s면 여러분의 회선은 꽉 차고, 패킷 크기가 64 바이트라면 그 안에 초당 약 149만 개가 들어갑니다. 그 위에서는 서버 앞단 네트워크의 필터링만이 결과를 결정합니다.
• KernelHost에서는 2단계 상시 방어가 모든 서버 상품에 포함되어 서버 제공 시점부터 동작하며, null-routing을 쓰지 않습니다. Advanced DDoS Protection은 여기에 전용 방어 IP와 포트별로 직접 관리하는 규칙을 더해 줍니다.

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