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

저녁 세션 도중에 사라졌다가 십 분 뒤에 다시 나타나는 RedM 서버는 하드웨어 문제인 경우가 드뭅니다. 대개는 포트 30120을 노린 공격이 진행 중이고, 그것도 플레이어가 가장 많이 접속해 있는 시간대에 벌어집니다. 이 글은 RedM 서버를 DDoS 공격으로부터 방어하는 방법을 보여 줍니다. 먼저 추가 비용 없이 직접 보호할 수 있는 것, 그다음 이런 조치의 물리적 한계, 마지막으로 공격이 여러분의 회선보다 클 때 서버 앞단 네트워크에서 무엇이 이뤄져야 하는지입니다.

모든 내용은 Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 gamename rdr3으로 운영하는 FXServer를 기준으로 합니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요. RedM은 Cfx.re가 만든 Red Dead Redemption 2 모드이고 FiveM의 자매 프로젝트입니다. 둘은 같은 서버 프로그램에서 돌아가므로 네트워크 기술의 일부는 실제로 동일합니다. 그런 부분은 이 글에서 한 문장으로만 짚고, 자세한 내용은 FiveM 서버를 DDoS 공격으로부터 방어하기 글에 있습니다. 이 글의 나머지는 모두 RedM에 고유한 내용입니다.

공격이 지금 진행 중이라면: 지금 server.cfg를 바꾸지 마시고 서버를 재시작하지도 마세요. 먼저 측정값을 확보하세요(“측정값 모으기” 절 참조). 공격이 끝나면 그 값은 사라집니다.

RedM 서버가 DDoS 공격의 표적이 자주 되는 이유

RedM 서버는 플레이어 수로 짐작할 수 있는 것보다 더 값진 표적입니다. 이유는 바로 이 씬의 규모가 작다는 점입니다. 2026년 9월에 공개 서버 목록 트래커들이 집계한 활성 RedM 서버는 약 2,000개, 동시 접속 플레이어는 약 12,400명이었고, FiveM은 약 39,000개 서버에 약 325,000명이었습니다. RedM 서버 2,000개 가운데 하나를 멈춰 세우는 사람은 FiveM 서버 39,000개 가운데 하나를 때리는 사람보다 씬 전체에서 훨씬 큰 몫을 네트워크에서 떼어 냅니다. 그러므로 경쟁 프로젝트에 손해를 입히려는 공격자에게는 지렛대가 비교할 수 없이 큽니다.

여기에 커뮤니티의 구조가 더해집니다. RedM 롤플레이는 정해진 시간에 열리는 고정 세션으로 유지되고, 사전 신청과 캐릭터 승인을 두는 경우가 많습니다. 저녁 8시의 장애는 아무 플레이어가 아니라 바로 그 저녁에 신청한 사람들을 때립니다. 게다가 많은 프로젝트가 작은 예산의 취미로 운영되어 값싼 서버 한 대에 매달려 있고, 전환할 수 있는 두 번째 인스턴스가 없습니다. RedM 씬에서 공개적으로 기록된 사례들은 몇 달에 걸쳐 거의 매일 반복된 공격 연속을 보여 주며, 이 공격은 게임 서버와 별도의 음성 서버를 동시에 때렸습니다.

기술적으로는 게임 트래픽이 UDP로 흐른다는 점이 더해집니다. UDP는 연결이 없는 전송 프로토콜입니다. 서버가 요구할 수 있는 연결 수립 절차가 없고, 출발지 주소는 위조할 수 있습니다. 그래서 공격자는 부하를 만들기 위해 RedM 서버에 들어올 필요도, 규격에 맞게 말을 걸 필요도 없습니다. DDoS 공격이 정확히 무엇이고 어떻게 구성되는지는 DDoS 공격이란 무엇인가? 글에서 설명합니다.

실제로 문제가 되는 포트

RedM 서버는 기본값으로 포트 하나에, 그것도 두 프로토콜 모두에 바인딩합니다. server.cfg에는 이를 위해 다음과 같이 적습니다.

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

set gamename rdr3 줄은 RedM 서버를 FiveM 서버와 구분하는 유일한 줄입니다. 이 줄이 없으면 같은 FXServer가 GTA V 서버로 등록되고, RedM 클라이언트는 접속하지 못합니다. RedM에는 자체 쿼리 포트도 자체 RCON 포트도 없습니다. 서버 조회, 연결 수립, 게임 트래픽, RCON이 모두 30120의 같은 두 항목을 지나갑니다. 숫자로 정리하면 다음과 같습니다.

언급한 네 개의 포트 가운데 열린 네트워크에 놓여야 하는 것은 정확히 두 개, 30120 TCP와 30120 UDP입니다. 포트 40120과 포트 3306은 거기에 속하지 않으며, 포트 22의 SSH는 본인 주소로 제한해야 합니다. 이것이 RedM 서버에서 가장 흔하게 나오는, 그리고 피할 수 있는 실수입니다. 많은 프로젝트가 완성된 txAdmin 레시피로 시작한 뒤 서버가 외부에 무엇을 내주고 있는지 한 번도 확인하지 않기 때문입니다.

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

이 절이 가장 길고, 의도한 바입니다. 설정이 깔끔한 RedM 서버는 어디에 놓여 있든 작거나 중간 규모의 공격을 자체 힘으로 견뎌 냅니다. 순서도 의도적으로 정했습니다. 먼저 측정하고, 그다음 닫고, 그 뒤에야 제한합니다.

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

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

ss -lntup

여기서 중요한 것은 로컬 주소 열입니다. 0.0.0.0:30120과 [::]:30120은 “인터넷 전체에서 접근할 수 있음”을 뜻하고, 127.0.0.1:3306은 “로컬에서만 접근할 수 있음”을 뜻하므로 방화벽 규칙이 필요하지 않습니다. RedM 서버에서는 FXServer 외에 40120의 txAdmin, 3306의 MariaDB, 프로젝트 홈페이지용 웹 서버, 그리고 때로는 음성 서비스가 함께 나타납니다. 공격자의 시선은 외부에서 실행하는 포트 스캔이 보여 줍니다.

nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 30120 TCP와 UDP만 열어 두기

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

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10은 본인 주소로 바꾸세요. 주소가 바뀌는 회선에서는 이 방법이 불편하고, 더 나은 방법은 txAdmin을 다루는 다음 절에 있습니다. 복구 방법까지 포함한 전체 안내는 스스로 접속이 막히지 않게 UFW 방화벽 설정하기에서 볼 수 있습니다.

데이터베이스는 어떤 경우에도 열린 네트워크에 두어서는 안 됩니다. VORP, RSGCore, RedEM:RP는 모두 MariaDB나 MySQL이 필요하며, 대개 oxmysql을 통해 server.cfg의 연결 문자열로 접속합니다. 이 연결은 로컬에서 이뤄지므로 포트가 외부에서 접근될 필요가 없습니다. /etc/mysql/mariadb.conf.d/50-server.cnf에 다음 줄이 있는지 확인하세요.

bind-address = 127.0.0.1

3. FXServer의 HTTP 엔드포인트 보호하기

FXServer는 30120의 TCP 쪽에서 HTTP 요청에 응답하며, 그러려고 누군가 Red Dead Redemption 2를 실행할 필요는 없습니다. 여러분의 RedM 서버가 거기에서 무엇을 내주는지 직접 확인해 보세요.

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json은 접속한 플레이어와 그 식별자를, /info.json은 서버 설정과 로드된 리소스를, /dynamic.json은 현재 인원을 나열합니다. 바로 이 세 엔드포인트가 FiveM과 RedM 서버를 겨냥한, 문서로 확인된 레이어 7 공격 경로입니다. 로그인 없이 접근할 수 있고, 얼마든지 반복해서 조회할 수 있으며, 조회마다 서버가 일을 하고, 그 내용은 공격자에게 언제 공격할 값이 있는지를 알려 줍니다. 비용이 들지 않는 대응책이 두 가지 있습니다. 첫째, 플레이어의 접속 주소는 응답에 들어가서는 안 되며, 이를 위해서는 server.cfg에 한 줄이면 충분합니다.

sv_endpointPrivacy true

이 설정은 서버의 공개 출력에서 플레이어의 IP 주소를 숨깁니다. 둘째, Discord 봇이나 프로젝트 홈페이지가 접속 인원을 표시한다면, 방문자마다 엔드포인트를 조회하지 말고 결과를 일정한 간격으로 캐시에 저장하세요. 그러면 방문이 많은 상태 페이지가 방문자마다 한 번이 아니라 간격마다 한 번만 조회합니다. RedM처럼 작은 씬에서는 이 효과가 두 배로 중요합니다. 서버 상태 봇 하나가 여러 Discord 서버에 동시에 연결되어 있을 수 있기 때문입니다.

4. 포트 40120의 txAdmin을 열린 네트워크에서 빼기

txAdmin은 FiveM과 RedM용 FXServer 빌드에 포함된 관리 인터페이스이며, 기본값으로 40120 TCP에서 대기합니다. 그 뒤에는 서버에 대한 완전한 접근 권한이 있습니다. 재시작, 차단 목록, 플레이어 데이터베이스, 리소스 관리입니다. 개방에 쓸 고정 IP 주소가 없다면 포트를 외부에서 닫아 두고 SSH 로컬 포트 포워딩으로 접근하세요. 그다음 브라우저에서 http://127.0.0.1:40120을 엽니다.

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

txAdmin을 공개된 상태로 두면 문제가 한꺼번에 두 개 생깁니다. 로그인 플러드를 걸 수 있는 로그인 화면이 하나이고, 게임과 아무 상관이 없으면서도 요청마다 일을 하는 서비스가 또 하나입니다. 확실하지 않다면 서비스가 127.0.0.1에서만 대기하게 해서 txAdmin을 처음부터 로컬에 바인딩하세요.

5. 출발지 주소별로 연결 수와 패킷 전송률 제한하기

작은 공격과 엉성한 봇에는 출발지 주소별 상한이 도움이 됩니다. 아래 두 규칙은 30120, 곧 이 게임의 두 프로토콜 모두에 적용됩니다.

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

첫 번째 규칙은 한 주소가 동시에 여덟 개를 넘겨 열고 있는 순간 새 TCP 연결을 폐기하고, 두 번째 규칙은 같은 출발지에서 초당 500개를 지속적으로 넘는 UDP 패킷을 폐기합니다. 여기의 출발 값은 FiveM 서버보다 조금 낮게 잡혀 있습니다. 슬롯이 32개인 RedM 서버는 주소당 정상 연결 수가 그만큼 적기 때문입니다. 다만 출발 값은 정답이 아닙니다. 사람이 꽉 찬 RP 저녁은 빈 서버보다 훨씬 많은 패킷을 만들고, 너무 좁게 잡으면 자기 플레이어를 내쫓습니다. 먼저 평상시 운영에서 한 주는 측정하세요.

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

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

그리고 UFW를 쓴다면 이런 규칙은 /etc/ufw/before.rules에 들어가야 합니다. 그러지 않으면 다음 ufw reload에서 사라집니다. 자주 간과되는 병목이 하나 더 있는데, 커널의 연결 추적입니다. 테이블이 가득 차면 서버는 정상 패킷까지 폐기하고, 로그에는 “nf_conntrack: table full”이 남습니다. 현재 값과 상한은 다음 명령으로 확인합니다.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. 32개 슬롯을 접속 플러드로부터 보호하기

RedM 서버의 슬롯은 OneSync 없이 정확히 32개입니다. OneSync를 쓰면 48개이고, 그보다 많은 최대 1,024자리에는 Element Club 구독이 필요합니다. 이 숫자는 보안과 관련이 있습니다. 공격자가 채워야 하는 상한이기 때문입니다. 접속 시도 32개를 동시에 열어 두면 기본 설정 서버를 완전히 점유하게 되고, 플레이어는 한 명도 실제로 게임에 도달하지 못합니다. 자리가 128개인 FiveM 프로젝트라면 같은 문턱이 네 배 높습니다.

RedM에만 있는 장점이 이를 부분적으로 상쇄합니다. RedM은 Steam, Epic Games, Rockstar 어디에서 구매했든 Red Dead Redemption 2의 정품 사본을 요구하며, 여기에 Rockstar 런처도 필요합니다. 그러므로 무료 게임에서 흔한, 수천 개의 일회용 계정을 동원한 접속 플러드는 여기에서는 실제 돈이 듭니다. 그래서 공격은 게임 사본이 필요하지 않은 네트워크 계층과 HTTP 엔드포인트로 옮겨 갑니다.

그래도 정상 접속 경로를 이용하는 모든 것에는 허용 목록이 효과가 있습니다. 허용 목록은 서버 쪽 playerConnecting 이벤트에서 구현하며, Deferrals 함수로 연결을 붙잡아 두고 식별자를 검사한 다음에야 통과시킵니다. 여기에 엄격한 계정 검사와 현실적인 플레이어 상한이 더해집니다.

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance는 1부터 5까지의 값이고, 한 공급자에서 플레이어의 식별자가 얼마나 달라질 수 있는지를 정합니다. 1이 가장 엄격한 설정입니다. sv_authMinTrust도 1부터 5까지이며, 위조된 신원일 가능성이 얼마나 낮아야 하는지를 나타냅니다. 여기서는 5가 가장 엄격한 값입니다. RCON 비밀번호는 RCON이 정말 필요할 때만 설정하세요. 그 접근 경로가 같은 열린 포트 30120에 놓여 있기 때문입니다. 그리고 한 가지는 분명히 해 두어야 합니다. 허용 목록은 게임 로직을 지켜 주지만 회선을 지켜 주지는 않습니다. 서버를 플러딩하는 공격자는 애초에 접속할 생각이 없습니다. 그의 패킷은 거부되지만 이미 도착해 있고, 바로 그 점이 핵심입니다.

7. RedM 서버 목록의 항목을 제대로 판단하기

여기서는 희망적인 생각보다 솔직함이 낫습니다. 여러분의 IP 주소는 비밀로 유지할 수 없습니다. RedM은 FiveM과 같은 Cfx.re 마스터 서버 기반을 쓰고, 목록 항목의 connectEndPoints 항목에 접속 엔드포인트가 평문으로 들어 있습니다. servers-frontend.fivem.net의 공개 인터페이스를 통해 모든 cfx.re 코드에 대해 해당 주소를 조회할 수 있으며, 이는 FiveM과 마찬가지로 RedM에도 적용됩니다. 프로젝트가 순전히 Discord와 직접 연결로 운영되어 공개 항목이 아예 필요하지 않다면 sv_master1 ""로 서버를 비공개로 둘 수 있습니다. 그러면 서버 목록을 통해서는 더 이상 접속할 수 없습니다. 다만 이것은 새 플레이어에 대한 노출 전부를 대가로 치르는 일이고, 서버가 2,000개인 씬에서는 노출이 곧 성장의 동력입니다.

더 효과적인 것은 두 가지 습관입니다. 원시 IP 주소를 여러분 스스로 어디에도 공개하지 마세요. Discord 채널에도 프로젝트 홈페이지에도 올리지 않습니다. 그리고 플레이어가 호스트 이름으로 접속하게 해서, 비상 상황에 모든 참조가 깨지지 않으면서 주소를 바꿀 수 있도록 하세요. 여기서 전형적인 실수는 오래된 DNS 항목입니다. 이전 주소를 가리키는 A 레코드를 잊고 방치하면 어떤 변경도 무의미해집니다.

8. VORP, RSGCore, RedEM 이벤트를 서버 쪽에서 검사하기

DDoS 공격으로 신고되는 장애 가운데 많은 수가 단 하나의 스크립트에서 비롯됩니다. RedM 리소스는 네트워크 이벤트로 통신하며, 서버가 검사 없이 실행하는 이벤트는 열린 문입니다. 클라이언트에서 임의의 값을 담아 TriggerServerEvent를 보내면 달러를 만들어 내거나 말을 스폰하거나, 반복문으로 데이터베이스 조회를 일으켜 서버가 멈출 때까지 밀어붙일 수 있습니다. 이는 널리 쓰이는 세 프레임워크 모두에 똑같이 해당합니다. 2020년부터 가장 큰 스크립트 기반을 가진 VORP Core, RSGCore, 그리고 더 오래된 RedEM:RP입니다.

특히 취약한 것은 인벤토리와 캐릭터 리소스입니다. 호출마다 데이터베이스에 쓰기 때문입니다. 초당 열 번 인벤토리 상태를 저장하는 이벤트 반복문은 어지간한 패킷 플러드보다 RedM 서버에 더 큰 부담을 주며, 그것도 방화벽이 닿지 않는 내부에서 옵니다.

세 가지 원칙이 그 대부분을 막아 줍니다. RegisterNetEvent로는 정말로 클라이언트에서 와야 하는 이벤트만 등록하세요. 클라이언트가 함께 보내는 값에는 절대 의존하지 말고, 플레이어를 서버 쪽에서 source로 확인하세요. 그리고 한 플레이어가 같은 이벤트를 몇 번까지 일으킬 수 있는지 제한하세요. 데이터베이스 조회가 걸린 모든 것에는 특히 그렇습니다. 회선이 조용한데도 서버가 버벅인다면 클라이언트 콘솔의 resmon 1이 리소스별 연산 시간을 보여 주며, 대개 범인이 가장 위에 있습니다.

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 port 30120 -c 200 -q

tcpdump에는 한 가지 원칙이 있습니다. 항상 -c로 개수를 제한하세요. 과부하 상태에서의 캡처는 이미 과부하인 서버에 부담을 더 얹습니다. 그리고 부하가 30120의 UDP 쪽에 있는지 TCP 쪽에 있는지도 함께 살펴보세요. UDP 부하는 게임 트래픽을 겨냥한 패킷 플러드를, TCP 부하는 HTTP 엔드포인트를 겨냥한 플러드를 가리키며, 둘은 서로 다른 대응책이 필요합니다. 측정값을 해석하는 방법은 DDoS 공격 알아내기에 있습니다.

이 조치들이 한계에 이르는 지점

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

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

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

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

RedM이 FiveM과 다른 점

짧게 답하면, 네트워크 기술은 동일하고 환경은 그렇지 않습니다. 둘은 같은 FXServer에서 돌아가고, 둘 다 30120 TCP와 UDP를 쓰며, 둘 다 40120의 txAdmin으로 관리합니다. 위에서 포트와 전송률, 엔드포인트에 관해 읽은 모든 내용이 양쪽 모두에 적용됩니다. 다른 것은 주변 조건이고, 공격이 얼마나 빨리 효과를 내는지는 바로 그것이 결정합니다.

이 표에서 방어에 결정적인 것은 세 가지입니다. 첫째, 씬이 작기 때문에 RedM 서버 하나하나가 더 값진 표적이 됩니다. 장애가 플레이어의 더 큰 몫에 영향을 주기 때문입니다. 둘째, 기본 한도인 32슬롯은 접속 플러드가 서버를 막아 버리는 문턱을 낮춥니다. 셋째, RedM용으로 완성된 보호 레시피는 FiveM보다 인터넷에 적게 돌아다니므로 많은 프로젝트가 손대지 않은 기본 설정으로 돌아갑니다. 방어 방법은 같고, 출발 상태가 더 나쁩니다.

KernelHost가 이에 맞서 제공하는 것

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

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

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

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

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

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

• 전용 방어 IP: 프랑크푸르트 코어에서 발급되며, 서버는 자체 네트워크에서 이 IP로 전환됩니다. 여러분 쪽에서 손볼 것은 없습니다.
• 포트와 프로토콜별로 직접 관리하는 방어 규칙: 고객 포털에서 30120 UDP에 무엇을 허용할지와 30120 TCP에 무엇을 허용할지를 따로 설정하며, 그러려고 티켓을 쓸 필요가 없습니다. RedM에서는 이 분리가 특히 유용합니다. 게임 트래픽과 HTTP 엔드포인트가 같은 포트 번호에 놓여 있으면서 완전히 다른 양상을 보이기 때문입니다.
• 변경은 실시간으로 반영: 공격이 진행되는 중에도 값을 조정할 수 있습니다.
• 애플리케이션에 맞춘 방어 프로필. 30120의 Cfx.re 서버에는 알맞은 프로필이 마련되어 있고, 임의의 TCP 또는 UDP 포트에서 동작하는 개조된 애플리케이션과 자체 애플리케이션에도 마찬가지입니다.

둘 다 KernelHost에 놓인 서버에 적용됩니다. RedM 프로젝트가 현재 다른 곳에서 운영되면서 주기적으로 네트워크에서 밀려난다면, 권하는 것은 추가 상품이 아니라 이전입니다.

두 단계 비교

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

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

“제 서버가 RedM 서버 목록에 나타나지 않습니다. 공격인 것 같습니다”: 먼저 설정을 확인하세요. set gamename rdr3이 없으면 FXServer가 GTA V 서버로 등록되고 RedM 목록에 나타나지 않습니다. portal.cfx.re의 라이선스 키가 없거나 맞지 않으면 항목 자체가 만들어지지 않습니다. 공격은 다르게 보입니다. 항목은 그대로 남아 있고 접속이 실패합니다.

“수백 명의 플레이어가 접속할 때 오류를 받습니다. 플러드처럼 보입니다”: 대개 게임 빌드 문제입니다. sv_enforceGameBuild가 리소스가 기대하는 값과 맞지 않으면 클라이언트는 “server specified an invalid game enforcement”를 알립니다. 프레임워크가 요구하는 값, 보통 1436이나 1491을 설정하고 서버를 완전히 재시작하세요.

“IP 주소를 바꿨는데 두 시간 뒤에 다시 오프라인이 되었습니다”: 공격자는 새 주소를 예전과 같은 경로에서 얻습니다. 대개 목록 항목, Discord 봇, 또는 오래된 DNS 항목입니다. 주소 변경은 시간 벌기이고 해결책이 아닙니다.

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

“서버는 돌아가는데 모든 플레이어에게 고무줄 현상이 생깁니다”: 이것은 공격보다 스크립트인 경우가 더 많습니다. 먼저 resmon 1으로 어떤 리소스가 연산 시간을 먹고 있는지 보고, 프레임워크의 인벤토리와 캐릭터 리소스를 확인하세요. sar -n DEV 1 10이 평범하다면 DDoS 공격이 아니었습니다.

“txAdmin에 실패한 접속 시도가 수백 건 보입니다”: 이것은 접속 플러드이고 회선이 아니라 게임 로직을 때립니다. 이에 맞서는 것이 허용 목록, sv_authMinTrust를 통한 계정 검사, 그리고 출발지 주소별 연결 상한입니다.

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

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

핵심 요약

• RedM 서버에 필요한 열린 포트는 정확히 두 개, 곧 endpoint_add_tcp와 endpoint_add_udp로 지정하는 30120 TCP와 30120 UDP입니다. 자체 쿼리 포트나 자체 RCON 포트는 없습니다.
• 40120 TCP의 txAdmin과 3306 TCP의 데이터베이스는 열린 네트워크에 둘 것이 아니라 각각 본인 주소와 127.0.0.1에 두어야 합니다.
• sv_endpointPrivacy true는 공개 출력에서 플레이어의 IP 주소를 빼고, 캐시에 저장한 서버 상태는 Cfx.re 서버를 겨냥한 문서화된 레이어 7 공격 경로인 /players.json의 부담을 덜어 줍니다.
• RedM 서버의 슬롯은 OneSync 없이 32개, OneSync를 쓰면 48개, Element Club으로는 최대 1,024개입니다. 슬롯 수가 적을수록 접속 플러드가 값싸지고, 허용 목록과 계정 검사가 그만큼 중요해집니다.
• RedM과 FiveM은 같은 FXServer에서 돌아가고 set gamename rdr3 한 줄로만 구분됩니다. 그래서 네트워크 방어는 동일하지만 환경은 다릅니다. RedM 서버 약 2,000개와 FiveM 서버 약 39,000개의 차이는 RedM 프로젝트 하나하나를 더 값진 표적으로 만듭니다.
• 로컬 방화벽 규칙은 회선이 꽉 차는 지점에서 끝납니다. 1 Gbit/s는 초당 125 메가바이트이고, 64 바이트 패킷이라면 초당 약 149만 개가 들어갑니다. 그보다 큰 것은 모두 서버 앞단 네트워크에서 끝나야 합니다.
• KernelHost에서는 2단계 상시 방어가 모든 서버 상품에 포함되어 서버 제공 시점부터 동작하며 null-routing을 쓰지 않습니다. 필터링을 직접 제어하려는 운영자는 월 50.00 EUR부터의 Advanced DDoS Protection으로 전용 방어 IP와 포트 및 프로토콜별 자체 규칙을 받습니다.

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