중고등학교 시절. 여유롭지 못했던 주머니 사정과 하루의 거의 대부분을 학교에서 보내야했던 그 때. 하고 싶은 게임은 차고 넘치게 많았지만, 그 중에서도 정말 하고 싶은 게임 한두 개만을 '엄선해서' 해야하던 시절이었다.

아마 그때부터였던 것 같다. '프리 서버'라는 용어를 듣기 시작한 것 말이다. 공식적인 용어로는 프라이빗 서버(Private server), 그레이 샤드(Gray shard), 서버 에뮬레이터(Server emulator) 등으로 불리며, 통상적으로 사설 서버라 불리는 프리 서버.

말 그대로 게임 서버를 '탈취'하거나 원작자의 동의 없이 '제작'하여 서비스하는 행위. 게임을 개발하는 입장에서는 마땅히 뿌리뽑아야할 요소다. NHN NEXT의 구승모 교수는 사설 서버가 왜, 어떻게 생기는지부터 그것을 막기 위한 방법까지를 개괄적으로 풀어냈다.


사설 서버는 주로 2가지 경로를 통해 생겨난다. 하나는 해커들이 직접 탈취한 것을 기반으로 하는 경우. '라그나로크 온라인' 때의 AEGIS이 대표적인 예다. 다른 하나는 실제 정식 서버를 흉내내도록 제작하는 경우. '월드 오브 워크래프트'에 있었던 MaNGOS가 이에 해당한다.

기본적으로 사설 서버는 상당한 수익을 발생시킬 수 있다. 즉, 게임을 개발한 장본인에게 금전적인 손해를 끼치게 되며, 게임 운영에 대한 신뢰도에도 타격을 준다. 또한, 이를 해결하기 위한 소송이 진행될 경우 적지 않은 시간과 비용이 소모된다. 개발사 입장에서는 그야말로 백해무익할 수밖에.

그렇다면 사설 서버는 대체 어떻게 생기는 것일까? 가장 근본적인 원인을 보자면, 소스코드 유출이다. 즉, 개발사 혹은 퍼블리셔에서 소스코드가 직접 유출되는 사례를 들 수 있다.

이 경우 '트로이 목마'를 통한 유출이 대부분이다. 개발에 사용되는 툴들의 크랙(Crack) 버전에 심어서 P2P 프로그램 등을 통해 배포하고, 이것이 개발자의 컴퓨터에서 실행되는 순간 백도어(Backdoor)를 생성해 해커에게 정보가 흘러나가는 구조다. 해커 또한 리포팅이 이루어지는 순간 바로 털어가는 것이 아니라, 어느 정도 결과물이 나왔을 때 한꺼번에 빼가게 마련이다.

* 백도어 (Backdoor) : 일반적인 인증을 통과, 원격 접속을 보장하고 Plaintext에의 접근을 취득하는 등의 행동을 들키지 않고 행하는 방법.

이를 방지하기 위한 조치는 간단하다. 한편으로는 너무 당연한 말이기도 하다. 바로 정품 소프트웨어를 사용하고, 최신 버전 업데이트를 유지하는 것. 아예 개발에 사용되는 머신들을 인터넷으로부터 물리적으로 분리해버리면 가장 확실하게 유출을 막을 수 있다. 물론, 개인 USB 등 인가되지 않은 저장장치 사용을 금지하고 내부 인원 관리에 신경 쓰는 것은 기본적으로 병행해야 한다.

퍼블리셔 측의 배포선(Release Process) 또는 IDC(Internet Data Center, 서버 컴퓨터와 네트워크 회선 등을 제공하는 시설의 일종)를 통해 유출되는 경우도 있다.

따라서, 운영 인원의 권한을 최소화하고 인증 체계를 강화하는 등 뻔한 방법일지라도 잊지 말고 챙겨둬야 한다. 무엇보다, 서버 바이너리의 어떤 버전이 어떤 경로를 통해 유출됐는지를 알아야 하며, 탈취된 서버가 정상적으로 동작하지 않도록 하는 장치를 도입하는 것이 중요하다.

* 바이너리(binary) : 텍스트 형태가 아닌 0, 1 두 숫자로 이루어진 이진 형태의 인코딩 결과물을 의미하며, 프로그램 배포에서는 소스코드가 아닌 실행 파일을 나타낸다.

배포선에서의 유출을 막기 위한 기본 원칙은 반드시 인가된 채널로만 배포하는 것. 급하다고 해서 메일 등의 안전하지 않은 방식을 이용해 패치 등을 전송하는 것은 절대 삼가야 한다. 또한, 서버 프로그램의 유효 기간을 설정하거나 인증된 머신 정보를 서버 바이너리에 삽입함으로써 공식적으로 인가된 실행인지를 확인하는 것도 한 방법이다.


소스코드 유출을 막기 위한 예방책들의 경우 사실 금전적으로 해결할 수 있다. TPM(Trusted Platform Module, 신뢰할 수 있는 플랫폼 모듈)이라든가 라이선스 서버 등 별도의 솔루션을 사용하면 좀 더 수월해지기 때문이다.

문제는 해커 등에 의해 서버 에뮬레이터가 제작되는 경우. 이는 애초에 100% 막아낸다는 것이 물리적으로 불가능하다. 일단 수적 열세에 시달릴 수밖에 없다. 개발하는 사람에 비해 해킹을 시도하는 사람의 수가 훨씬 많기 때문. 그 와중에서 말 그대로 '작정하고' 시도하는 사람들을 완벽하게 막아내는 것은 한없이 어려운 일이다.

해커들은 FGT나 CBT 등 최초의 외부 테스트 때부터 클라이언트 분석을 시작한다. 그렇기 때문에 보안은 개발 초기부터 각별하게 신경써야 하는 부분이다. 오픈 전에 서버 샌드박스(Sandbox)가 등장하는 경우, 서버-클라이언트 간의 핵심 메커니즘이 분석 당했다는 의미가 된다.

해커들은 패킷(Packet, 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록)을 분석하거나 클라이언트 역공학(Reverse Engineering)을 통해 서버를 공략한다. 즉, 서버-클라이언트가 어떤 데이터를 어떻게 주고 받는지를 파악하거나, 아트 리소스 및 게임 데이터시트 등의 정보를 추출해가는 것.

* 샌드박스(Sandbox) : 월드 접속 및 이동만 가능한 일종의 더미(Dummy) 서버로, 해커들의 첫 번째 목표가 된다.
* 클라이언트 역공학 (Reverse Engineering) : 장치 또는 시스템의 기술적인 원리를 그 구조분석을 통해 발견하는 과정.

그렇다면, 역공학을 막기 위해(Anti-Reverse Engineering) 할 수 있는 것은 무엇인가?

기본적으로 수적 열세에 처해 있기 때문에 해커들의 움직임에 일일이 대응하는 것은 비효율적일 수밖에 없다. 이에 구승모 교수는 클라이언트 바이너리 난독화 전문 툴을 사용할 것을 추천했다. 생각보다 가격이 저렴한 툴들이 많이 있으며, 지속적으로 역공학을 막기 위한 방법들이 업데이트되기 때문에 유용하게 사용할 수 있다는 설명이다.

패킷 분석을 막기 위해서는 당연히 우선 암호화가 필요하다. 단, 아무리 암호화를 잘 하더라도 언젠가는 파악당하기 때문에, 가급적 개발자의 손이 많이 가지 않는 방식으로 관리하는 것이 포인트다. 이를테면, 패킷 내용이 파악되더라도 약간의 수정만 가하면 해커로 하여금 더 많은 시간을 소비하도록 만드는 방식이 필요하다. 이는 유저 ID나 PIN, 메일주소 등 유저들의 정보를 보호하기 위해서도 필수적으로 갖춰져 있어야 한다.

구승모 교수는 "패킷 암호화 시에는 직접 설계하거나 구현하지 말고 잘 만들어진 기존의 코드를 사용하라"고 말했다. 아무리 암호화 알고리즘을 잘 만들더라도 언젠가는 파악당할 수밖에 없기 때문에, 기존에 검증된 것들을 사용하는 편이 좋다는 것.




서버 에뮬레이터 제작을 막기 위해 수많은 노력이 들어가지만, 여전히 100% 막기는 불가능하다. 하지만 보다 효율적인 방어를 위해서 따라서, 서버 에뮬레이터가 어디서 만들어지고 있는지를 아는 것이 무엇보다 중요하다.

정보를 빼내는 것과 지켜내는 것은, 사실 어느 쪽이 절대적으로 우위에 있다고 볼 수 없는 관계다. 그들은 끊임없이 목적 달성을 위한 방법을 찾게 되며, 그 과정에서 수없이 맞서게 된다. 사설 서버가 생기는 것을 막으려는 움직임 역시 이 관계의 일환이라고 할 수 있다.

기억해야할 것은, 100% 막을 수 없다고 해서 손을 놓아버려서는 안 된다는 사실이다. 구승모 교수는 이를 방충망의 원리에 빗대어 이야기했다. 방충망을 설치한다고 해서 벌레가 들어오지 않는 것은 아니지만, 그것이 있을 때와 없을 때의 차이는 크기 때문이다.

그는 "보안을 위해 들이는 노력보다 뚫기 위해 필요한 노력이 더 큰 방법들이 여럿 있다"고 말했다. 또한, "이러한 방법들이 그리 어려운 것은 아니며, 실제로 상당히 효과를 볼 수 있다"며, "100% 막을 수는 없지만 그렇다고 방치해서는 안 된다"고 강조하며 강연을 마무리 지었다.

▶ 구승모 교수 강연 슬라이드 쉐어 바로가기

▲ '손놓아버리지 않는 것'이 중요하다