NDC Replay

사설 게임 서버를 막기 위한 방법들 (No More Private Servers)
구승모
NHN NEXT
현재 NHN NEXT에서 게임 프로그래밍 전공 교수 TERA 및 L3 게임 서버 개발. Game Developer Magazine (May 2012)에 "Evolving MMORPG Combat" 게재. China Game Developer Conference (2010)에 "How to Support an Action-Heavy MMORPG from the Angle of Server Architecture" 발표. Electronics Letters (2006)에 "Reducing cache misses through cache line overlapping" 게재. 각종 소프트웨어 공모전에서 국내 최고상을 다수 수상. 게임서버 관련 오픈소스 프로젝트 다수 참여. (http://www.linkedin.com/in/sm9kr)
최근에 출시되는 거의 모든 게임은 (PC, 콘솔, 모바일 등의 플랫폼에 관계없이) 게임 서버와 연결되어 있는 온라인 게임 형태이다. 이러한 온라인 게임을 서비스함에 있어서 사설 서버는 큰 골치거리다. 사설 서버는 게임 서버를 직접 탈취하거나 제작하여 운영하며 게임에 대한 저작권 및 서비스 권리 없이 영리 목적으로 다른 단체가 게임의 원작자 동의 없이 게임을 즐길 수 있도록 하는 서버를 가리키는 말이다. 본 발표에서는 (온라인 게임 서버 개발자로서 9년, 사설 서버 제작 과정을 6년 이상 지켜본 경험을 토대로) 이러한 사설 서버가 어떤 식으로 발생하고, 적은 노력으로도 어떻게 막을(지연 시킬) 수 있는지, 그리고 사설 서버가 발생했을 경우 어떻게 알아채고 대응할 수 있는지에 다룬다.
[새 창에서 슬라이드 보기]
안녕하세요, 반갑습니다. 제가 오늘 발표할 내용은 사설 게임 서버에 관한 내용이고요. 이게 상당히 마이너한 주제인데 이렇게 많이 오신 게 조금 의아합니다, 사실은. 발표 전에 제 소개를 잠깐 하자면요. 저는 사실은 원래 게임 업계 사람은 아니고 한 10년 전쯤에 와우라는 게임을 폐인처럼 하다가 아, 이런 것 한 번 만들어봐야지, 하고 게임 업계로 오게 되었습니다. 그래서 처음에는 NCSOFT에 있다가 나와서 TERA 만드는 데 처음부터 끝까지 참여했고요. 지금은 NHN NEXT에서 게임 트랙 학생들을 가르치고 있습니다. 강연 개요는 다음과 같습니다. 사설 서버는 뭔지 잠깐 설명 드릴 거고요. 그리고 사설 서버들을 어떻게 막을 수 있는가에 대한 내용을 얘기해드리도록 하겠습니다. 강연 대상은 온라인 게임 서버 프로그래머 아니면 플랫폼 프로그래머이고요. 그분들이 아니더라도 게임 서버 보안에 관심 있는 분들이면 다 들으셔도 괜찮을 것 같습니다. 여기서 다루지 않는 것은 전반적인 서버 보안 방법에 대한 것은 다루지 않고요. Reverse Engineering을 어떻게 막느냐, 이런 것도 다루지 않습니다. 말 그대로 사설 게임 서버에 특화된 내용을 다루도록 하겠습니다. 사설 서버 이야기를 잠깐 해보자면, 실제 게임 서비스중인 게임을 해킹해서 탈취해서 서비스하거나 아니면 급하게 흉내 내서 제작해서 서비스하는 그런 게임 서버를 말합니다. 소위 우리가 말하는 플섭이죠. 공식 용어는 Private Server라 하기도 하고, Gray Shard라 하기도 합니다. 대부분의 경우는 영리를 목적으로 만들어 지고요. 주로 두 가지 방법으로 생깁니다. 해커들이 직접 실서버를 탈취하는 경우도 생기고, 개발사를 해킹해서 소스 코드 가져가서 그 기반으로 생기기도 합니다. 두 번째로는 탈취되지 않더라도 서버 에뮬레이터 제작을 통해서 생기기도 합니다. 실제로 있는 서버를 흉내 내는 거죠, 어떻게 보면. 이런 사설 서버가 생기면 직접적으로는 당연히 Profit-Share가 감소하고요. 간접적으로 더 무서운 것은 뭐냐, 게임 자체에 대한 신뢰 하락이고, 유저들이 존중 받지 못한다는 느낌이 들죠. 그래서 실제로 보면 메이플 스토리, 리니지2, 와우 같은 경우는 사설 서버들이 상당히 발달되어 있는데요. 실제로 북미에서 서비스나 아니면 해외 서비스 중인 사설 서버 보면 적게는 수천에서 많게는 수만 명 유저들이 지금 이 시간에도 즐기고 있습니다. 그래서 넥슨이나 블리자드, 엔씨소프트 같은 경우에는 이런 사설 서버들을 직접 소송을 해가지고 셧다운 시킨 경우가 많고요. 그럼 왜 이런 사설 서버를 만드느냐? 사실 궁극적으로는 돈을 벌기 위해서 만듭니다. 꽤 많은 인력들이 사실은 사설 서버를 만들려고 노력을 하고 있고요. 의외로 꽤 짭짤하다고 하네요. 그리고 실제로 서비스가 일어난 국가들을 보면 미국에서도 조금 일어나지만, 보통 러시아 관련 국가들, 아니면 중국 내륙 지방에 사설 서버를 가지고 실제로 서비스를 하고 있습니다. 한때 러시아 시장 온라인 게임 통틀어서 1위가 리니지2 사설 서버였거든요. 그것을 보면 이쪽에서 상당히 인기가 있다는 것을 알 수 있죠. 그리고 돈을 벌기 위한 목적이 아니라 교육적인 목적, 좀 그런데, 만들기도 합니다. 해커들이 도전의식, 아니면 재미로 실제로 서버를 흉내 내서 구현해보는 거죠. 클라이언트는 그대로 있으니까. 그렇게 만들어보기도 하고요. 이런 사설 서버가 어떻게 만들어지는가, 크게 나누어 보면 직접적인 유출이 있고 에뮬레이터 방식이 있다고 했죠. 직접적인 유출도 크게 두 가지로 나눌 수 있어요. 개발사에서 직접 털리는 경우가 있습니다. 대부분의 경우는 보면 트로이 목마를 통해서 유출이 되고요, 대표적으로 하프라이프2 소스 코드가 이렇게 유출이 된 경우죠. 이것은 주위에 보면 은근 이렇게 당하신 분들이 계실 거에요. 그리고 퍼블리셔 측에서 유출되는 경우도 있어요. 이것은 실제로 서비스 중인 서버가 탈취되는 경우에요. 대표적으로 배포 과정 중이나 서비스 중에 해킹 당해서 바이럴이 털리는 경우고요. 그리고 IDC 근무자가 그냥 가지고 나가는 경우가 있습니다. 리지니2 같은 경우는 해외 서비스 중에 어떤 일이 있었냐 하면, 데이터 센터 관리자가 미러링 된 하드 디스크를 들고 나른 적도 있었습니다. 이렇게 털리는 경우도 있고요. 그리고 실제로 사설 서버가 털리지 않더라도 에뮬레이터 제작을 통해서 생기는 경우가 있죠. 실제로 CBT, FGT 외부인 공개 테스트 시작과 동시에 사실 해커들은 이것을 입수합니다. 입수해서 분석을 많이 해요. 폐쇄형 커뮤니티를 만들고, 여기서 아, 패킷 구조가 어떠니 클라이언트 보안 메커니즘이 어떠니 토론을 해서 만들기 시작합니다. 그리고 사설 서버 에뮬레이터는 non-client bot 하고 같이 만들어져요. 왜 그러냐 하면, 서버 에뮬레이터랑 non-client bot 은 사실상 한 뿌리에요. 실제로 서버를 흉내 내면 서버 에뮬레이터고, 클라이언트를 흉내 내면 non-client bot 입니다. 그래서 non-client bot이 있다, 그러면 어디서 서버 에뮬레이터가 있다고 보시면 됩니다. 그래서 오늘 할 얘기는 실제로 작정하면, 그러니까 마음먹고 가져가는 것은 막을 수 없고 클라이언트 이미 적의 수중이 있기 때문에 서버 에뮬레이터 만드는 것을 막을 수가 없습니다. 그렇다고 하지 말자, 이미 털릴 텐데. 그렇지만 비용 대비 효과를 볼 수 있는 방법들이 있습니다. 이 방법들에 대해서 오늘 이야기를 할 예정입니다. 직접 탈취로부터 막기 위해서 어떤 노력을 할 수 있는가에 대한 것을 제가 먼저 얘기를 드리겠습니다. 개발사에서 유출된 경우가 있는데요. 보통 아까 얘기했듯이 트로이 목마를 통해서 털립니다. 보통 어디에 많이 심겨져 있느냐, 트로이 목마가. 개발 관련 툴들 있죠? 크랙 버전, 크랙하는 툴들에 많이 쓰입니다. 여러분들 많이 쓰시는 비주얼. 이런것, 인크레더, 어도비 이런 것들 있죠? CDR 제너레이터, 뭐 이런 것을 실행하면 대부분의 경우에 백도어가 설치됩니다. 여러분들 모르게. 그리고 백도어가 생성되고 해커들에게 리포팅 가고, 그럼 해커들은 이거 가지고 백도어 방어하고 지켜보다가 어느 순간 탁 하고 털어갑니다. 특히 윈도우 도메인 어드민 권한을 갖는 컴퓨터에 설치되면 그 망은 다 털리겠죠. 이렇게 보통 유출이 되고요. 그래서 어떻게 해야 되느냐? 뭐 뻔한 말이에요. 정품 개발 툴 쓰고, 최신 소프트웨어로 업데이트 하자, 이런 얘기도 있고, 근데 이렇게 해도 못 막아요, 결국은. 그래서 보안에 자신 없으면 제일 확실한 것은 개발망 있죠? Source Repository나 아니면 Issue tracking system 같은 것을 아예 인터넷으로부터 분리해 버리면 됩니다. 그럼에도 불구하고 털려요. 왜냐? 내부 사람이 가지고 나가요. 그래서 가장 무서운 적은 내부의 적이라고 하잖아요. 보통 이 경우에는 악의적인 의도가 아닌 경우가 많습니다. 퇴사시 별 생각 없이 가져간다든가, 아니면 집에 가져와서 일하다가 집 컴퓨터가 털리는 경우에요. 이런 경우가 있어요. 이것은 사실 회사에서 직원들에 대한 교육으로 문제를 해결해야 되고요. 그냥 가장 확실한 것은 사실 개발자들한테 잘 해주면 됩니다. 그래서 회사 떠나지 않게 하는 방법이 있습니다. 이게 제일 맞겠죠? 그리고 퍼블리셔 측에서 유출되는 경우가 있어요. 보통 배포 과정 중에 유출되거나, IDC, 데이터 센터를 이용해서 가져가는 경우가 있는데 이것은 사실은 되게 광범위한 주제에요. 그래서 여기에서는 다루지 않고요. 이건 그냥 알아서 잘 해야 되는 겁니다. 그래서 여기서 다루는 것은 서버 바이너리가 유출됐는지 그 여부를 아는 것이 중요합니다. 그래서 어떤 버전이 어디를 통해서 유출되었는지 아는 장치를 넣어야 되고요. 탈취된 서버가 정상적으로 돌지 않도록 하는 장치를 넣어야 됩니다. 그래서 기본적으로 해야 될 것은 인가된 채널로만 배포를 해야 되고요. 급한 패치라고 메일 등으로 전송하고 이러면 안됩니다. 메일이 가장 취약합니다. 그리고 서버 프로그램에는 반드시 유효 기간을 설정해야 됩니다. 보통 이게 데이트 백도어 같은 것을 써서 지금 서버 실행될 때 지금 시각이랑 비교해서 그냥 6개월 정도 지났어, 그러면 무조건 실행이 안되게 한다든지, 뭐 이런 것들이 있겠죠. 그리고 바이너리 핑거 프린팅을 해야 되고요. 이것은 인증된 머신 정보를 서버 바이너리에 삽입하는 거에요. 데이터 용량을 미리 확보해놓고요. 배포 과정 중에 이 서버가 돌아갈 수 있는 어떤 서버들, 인간의 서버 목록이 있잖아요. 맥 주소나 아니면 IP 주소나 여러 가지 하드 유니크한 정보를 이제 박아 넣는 거죠. 그래서 서버 실행할 때 비교해보고, 이 하드웨어가 맞는 하드웨어인가 비교해보고, 아니면 실행 안 되게 하는 그런 장치를 도입할 수 있습니다. 이 두 가지는 사실 반나절 안이면 작업을 하는 거라서요. 안 해서 나쁠 게 전혀 없습니다. 그리고 더 중요한 것은 서버 시작할 때 어디서 서버가 시작되는지 통보를 받는 게 굉장히 중요합니다. 그래야 이게 유출이 되는지 바로 알 수가 있거든요. 아웃바운드 80번 포트를 막는 경우는 거의 없기 때문에 서버 실행할 때 아웃바운드 80번 포트로 나는 어디에서 인가된 서버이고 어디로 배포된 서버이고, 버전은 뭐고, IP는 뭐고, 이런 것을 리포팅 하게 하면 됩니다. 제3지대, 아마존이나 구글 엔진 같은 데서 리포팅을 받아다가 정상적인 서버 정보도 많겠죠. 이것을 모아다가 정리해서 개발자한테 메일로 리포팅하게 하는 이런 방법을 써 놓으면 서버가 어딘가 털렸을 때, 누군가 실행하면 바로 리포팅이 오게 됩니다. 자, 이 부분에 대한 것은 물리적인 탈취죠. 탈취에 대한 부분은 사실은 돈으로 다 해결할 수 있어요. 하드웨어 보안 모듈 사용하면 되고, TPM 같은 것. 그리고 라이선스 서버 솔루션들이 있어요. 서버가 실행할 때마다 뭔가 인증을 받아야만 실행 가능하게 하는 이런 솔루션들이 있는데, 이것을 쓰면 됩니다. 그러면 대부분 해결이 되고요.
그런데 이제 서버 에뮬레이터 같은 경우는 앞에 돈으로 해결 안 되는 종류에요. 이 부분은 어떻게 방지를 할 수 있는가? 거기에 대한 것을 이제 설명 드리도록 하겠습니다. 서버 에뮬레이터의 경우에는 처음부터 보안 반드시 신경 써야 된다고 그랬죠. FGT 한다고 패킷 암호화 안하고 그러면 안 돼요, 절대로. 해커들은 처음부터 가져와서 클라이언트 분석하는데, 이게 클라이언트 분석 당하면 오픈 전에 샌드박스가 무조건 등장을 합니다. 샌드박스란 뭐냐? 월드 접속 및 이동, 되게 진짜 월드 접속만 되는 거의 그런 더미 서버라 보면 돼요. 이게 이제 해커들의 사실 첫 번째 목표거든요. 이게 샌드 박스가 떴다, 그 말은 무슨 말이냐? 서버-클라이언트간 핵심 동작 메커니즘이 파악된 거에요. 뭐냐 하면, 인증, 암호화, 이런 것들이 그냥 다 분석 되었다고 볼 수가 있습니다. 그래서 샌드박스를 만들기 위해서 해커들은 두 가지 측면을 공략을 합니다. 패킷 분석부터 하고요, 클라이언트 역공학을 사용합니다. 이 부분에 대해서 이제 설명을 드릴게요. 클라이언트 역공학은 어떻게 이제 시도를 하느냐? 뭐 여러 가지 방법이 있지만, DLL 인젝션 많이 쓰죠. 해서 가장 먼저 하는 것은 뭐냐 하면, 샌드리시브 클라이언트의 샌드리시브 API 부분을 후킹합니다. 그래서 서버 클라이언트간 어떤 데이터를 주고받는지 파악을 합니다. 그래서 매커니즘을 파악하게 되고요. 이게 되면 사실 샌드박스를 만들 수 있겠죠. 샌드 박스를 만들면 그 다음에 하는 일이 뭐냐? 게임 데이터를 추출합니다. 클라이언트에 있는. 그래서 아트 리소스를 사실은 쓸 일이 없지만 게임에 필요한 각종 데이터시트 정보들이 있죠? 스킬 공격력, 아이템 스탯 테이블, 이런 것들을 추출해서 사설 서버에 사용 하려고 합니다. 그래서 역공학을 막으려면 어떻게 해야 되느냐? 상당히 큰, 광범위한 주제죠. 기초적인 것만 해도 할 게 굉장히 많고요. 이 부분은 개발자가 해커들의 속도를 따라잡기 힘들어요. 개발자 기껏해야 한두 명 할 텐데 해커들은 엄청나게 많죠. 서로 디스커션 해가면서 쫓기 때문에 못합니다. 그래서 웬만하면 클라이언트 전문 난독화 툴을 사용하기를 추천 드립니다. 예를 들어 Themida와 같은 게 있죠? 상당히 의외로 쌉니다 그리고 성능도 꽤 좋고요. 지속적으로 반-역공학 방법들이 업데이트가 계속 됩니다. 거의 90% 이상은 막혀요. 광고에서 나온 것은 아니고요. 그리고 중요한 것은 꼭 필요한 데이터를 패키징 해야 됩니다. 데이터 추출을 막을 수는 없어요. 다 털립니다, 결국은. 그래서 꼭 필요한 클라이언트 온리 데이터만 넣어야 돼요. 의외로 사람들이 개발 과정에서 귀차니즘 때문에 데이터 시트, 데이터 관리를 통합으로 하는 경우가 많아요. 클라이언트만 필요한 정보인데, 어떤 것은 서버에만 필요한 데이터인데도 그냥 같이 넣어가지고 패키징 해 버리는 경우가 있는데 절대 그러면 안 되고요. 반드시 배포 과정 중에 데이터가 서버냐, 클라냐, 공용이냐에 따라서 클라이언트 공용만 해서 넣어야 됩니다. 실제로 서버 에뮬레이터 제작 시 가장 더럽고 귀찮은 부분이 뭐냐 하면, 난독화 풀고 이런 게 아니에요. 실 서버와 같은 데이터 값 있죠? 밸런싱 정보 수집해서 입력하는 겁니다. 그래서 클라이언트 해당 정보가 있다면 사실 입력할 필요도 없어요, 찾을 필요도 없어요. 그냥 추출해다가, 그대로 긁어다가 서버에서 사용합니다. 상당히 위험하죠. 그래서 여기서 얘기 드리고 싶은 것은 클라이언트의 게임 로직이 많으면 많을수록 데이터가 많이 따라갈 수밖에 없어요. 그래서 웬만하면 서버에 로직 옮기고, 클라이언트 데이터는 최소화 하는 게 바람직합니다. 그 다음 패킷 분석 측면에서 설명 드리면요, 서버 클라이언트간 패킷을 캡쳐를 하고, 이게 어떤 내용이 뭐가 있는지 알면 사실상 서버/클라이언트 흉내 다 낼 수 있죠. 사실 암호화하지 않으면 클라이언트 역공학 할 필요도 없습니다. 그냥 바로 만들 수 있어요. 거의 개발자들보다 해커들의 구현 속도가 더 빨라요, 제가 봤을 땐. 그래서 패킷 암호화 반드시 해야 되고요. 근데 이게 아무리 잘해도 파악 당합니다. 왜냐 하면 클라이언트 역공학을 이용해가지고 다 파악이 되죠. 그래서 중요한 것은 패킷 내용을 관리할 수 있는 방법으로 접근을 해야 됩니다. 그래서 패킷 암호화 할 때 주의해야 할 점을 설명 드리면 절대로 직접 설계하거나 구현하지 마십시오. 이미 검증되고 리뷰 많이 받은 코드를 가져다가 사용하는 것이 좋습니다. 아무리 독창적인 알고리즘을 만든다 해도 결국 다 파악됩니다. 그래서 여기서 중요한 것은 암호화 알고리즘보다 암호화에 쓰이는 키를 어떻게 관리하는지가 핵심입니다. 그래서 절대로 클라이언트 키를 받으면 안되고요. 사실상 암호화 안 하는 거랑 같습니다. 그리고 키는 반드시 클라 서버나 세션을 맺을 때마다 무조건 새로 생성해서 교환을 해야 됩니다. 그래서 Diffie-Hellman 키 교환 방식을 반드시 써야 되고요. 이게 세션 성립 시마다 새로운 키로 바꾼 다음에 암호화 하기 위함이죠. 그리고 이 구현체가 상당히 많은데, 공격도 상당히 많아요. 이걸 뚫을 공격도. 그래서 각종 공격들 있죠? Man in the middle 같은 거, 유명한 공격들에 안전한 구현체를 사용하기를 추천 드립니다. Diffie-Hellman 간단히 설명 드리자면 오른 쪽에 보이는 저 갈색 모양, 색깔이 키라고 치면 저것을 서로 전송을 안하고 공유하기 위한 방법이에요. 색깔로 보시면 아시겠지만 색깔을 섞어가지고 자기가 안 가지고 있는 색깔만 전송하고, 그것을 다시 섞으면 나오는 게 되겠죠. 그래서 SRP 같은 게 하나의 괜찮은 구현체인데요. 이런 것 쓰시면 됩니다. 이것 말고도 많이 있어요. 보통 스탠포드 대학에서 만들어져 있고, 인증하고 키 교환 하고 패스워드 암호화 한 방에 해결이 됩니다. 그리고 인증에 사용되는 비밀 정보가 일부 털려도 안전합니다. 중간에서 패스워드가 틀려도 인증이 안 돼요. 중간 단에서 살펴보면. 그래서 사전 공격, 패스워드가 어떤 사전에 있는 거다, 그것도 틀려도 인증이 안됩니다. MITM 공격도 안전하고요. 중요한 것은 인증서가 필요 없어요. CA한테 뭔가 확인 받는 것도 필요 없고요. 이거 말고도 많이 있어요. 이런 것을 추천 드리고요. 그리고 이제 패킷 암호화를 하게 될 텐데, 키를 교환한 다음에, 반드시 패킷 암호화 할 때는 패킷 전체를 스트림 방식으로 암호화 해야 합니다. 모 게임처럼 패킷 헤더만 암호화 하게 되면 사실 페이 로드 데이터들 있죠? 다 보입니다. 이게 이동 패킷인지 채팅 패킷인지 다 보여요. 이렇게 와이어샤퍼로 잡아보면 다 보입니다. 사실은 위험하고요. 반드시 그리고 스트림 방식으로 해야 해요. 스트림 방식으로 하지 않으면 패킷 암호화 하는 패턴이 금방 보입니다. 스트림 방식으로 해서 반드시 전 패킷이 어떤 암호화 된 결과가 이후의 패킷에 영향을 주는 방식으로 처리를 해 줘야 됩니다. 반드시 이렇게 해야 되고요. 그리고 패킷 셔플링을 도입하면 좋습니다. 이게 뭐냐 하면 패킷 번호, 패킷 내용 있죠? 컨텐츠 순서를 무작위로 치환하는 겁니다. 그래서 왼쪽 그림 보시면 사실 CS 로그인 패킷이 1번이고 CS 무브 패킷이 3번이라 치면 이게 바꾸는 거에요. 다음 패치 때에는 이게 342번이 되고, 무브 패킷이 98번이 되고. 바뀌는 거에요. 그러니까 이것을 실시간으로 하시는 굉장히 어렵지만 패치 때만 바꾸는 것은 정말 쉽습니다. 그래서 수동으로 하느냐, 절대 그렇게 하지 마시고요. SVN 리비전 번호나 기트 태그 해시를 이용해서 배포 때 자동으로 패킷 코드, 어차피 생성 하잖아요? 그때 pre-build event로 넣어가지고 생성되도록 하면 됩니다. 패킷 컨텐츠도 바꿀 수 있어요. 멤버의 순서들을 바꾼다던가, 이걸 하면 어떤 효과가 있느냐? 사실 해커들 입장에서 분석하다 자꾸 바뀌어요. 짜증납니다. 짜증 나고요. 실제 이것은 서버 에뮬레이터를 써도 효과가 있는 부분은 어디서 있냐 하면, 넌 클라이언트 봇들 있죠? 패치하고 업데이트 하면 넌 클라이언트 봇이 하루 동안 보이지 않습니다. 시간을 벌 수 있고요. 상당히 귀찮기 때문에, 그리고 만들기는 쉽기 때문에 이렇게 하는 것을 추천 드립니다. 자, 그렇다고 말했죠. 그래서 100% 막는 것은 불가능하다고. 완전히 분석 당합니다. 그래서 어딘 가에서 서버 에뮬레이터가 만들어지고 있는지를 아는 것이 굉장히 중요합니다. 어떤 사실을 이용해서 이것을 알 수 있느냐? 서버 에뮬레이터도 결국은 인터넷의 일반인 대상으로 서비스 한다. 사설 서버도. 그리고 일반인은 HTTP 80 포트 아웃바운드로 막고 사용하는 유저는 없습니다. 그리고 클라이언트는 정식 배포 본은 그대로 사용합니다. 해커들이 만든 게 아니라 어디어디서 실제 서비스 가서 거기서 클라이언트 버전 얼마로 받아서 여기까지 패치하고 사용하세요, 이렇게 해요. 그래서 정식 클라이언트가 내가 어느 서버에 붙는지를 리포팅 하게 하면 됩니다. 그래서 리포팅 받을 때 대상 서버 IP가 127.0.0.1 이런 거 막 하고 있어요. 그러면 어딘가에서 사설 서버 에뮬레이터를 만들고 있다고 보면 됩니다. 그래서 요약하면 이렇게 할 수 있겠죠. 사설 서버 유저는 실제 만들어진 사설 서버 에뮬레이터에 붙으라고 해요. 접속 하라고 하고, 대신 이 클라이언트가 랜덤 샘플링으로 무조건 걸러내면 안되고, 일정 확률로 내 클라이언트 버전은 뭐고, 내가 붙는 서버는 어디고, 그런 정보들을 받아가지고 제 3지대에서 리포팅을 받으면 됩니다. 그러면 내용이 엄청 많겠죠, 클라이언트가. 엄청 많습니다. 그래서 map-reducing 같은 것을 써서 조금 줄여줘야 되고요. 그리고 정식 서버 정보도 엄청 많겠죠. 그런 것도 사실은 다 걸러 내 주고. 특정 확률로 하면 이게 내용이 확 줄어듭니다. 한 1%만 해당 되더라고요. 그래서 이런 정보를 모아다가 리포팅 딱 받았을 때 대상 서버 IP가 우리가 서비스하는 서버들이 아니야, 그러면 거의 사설 서버 에뮬레이터라고 보면 됩니다. Whois로 검색해서 그 지방 법무법인 얘기해서, 해결해달라고 하면 해결해줍니다. 정리하면, 100% 방지법은 없지만 최소한의 노력을 하자. 사실은 앞에서 언급했던 방법들이 난이 높은 일이 아니잖아요. 그리고 어차피 털린다고 손 놓는 것과는 차이가 큰 게, 방충망 놓는다고 생각하시면 돼요. 방충망 해도 벌레는 들어오잖아요. 그런데 있는 것과 없는 것의 차이는 크죠. 그리고 관리의 측면으로 접근하자. 앞에 말했던 리포팅 시스템 한 두 개 넣어 놓으면 앉아서 리포팅이 돼요. 그럼 보이죠. 그래서 쉽게 관리할 수 있어요. 패킷 셔플링 같은 것도 배포 중간에 집어넣으면 상당히 효과적이고요. 실제로 제가 참여했던 프로젝트나 주변 지인 프로젝트에서 이 방법 중에 일부, 다가 아니에요, 진짜 일부분만 썼는데도 실제 효과적이었고요. 앞에서 설명했던 방법 중에 하나도 안 쓰고 있다, 지금 서비스 중인 게임이거나 서비스 할 예정 중인 게임들. 그럼 상당히 위험합니다. 최소한 쉬운 것부터 적용하시기 바랍니다. 네, 오늘 발표는 여기까지 하기로 하고요. 이 슬라이드 따로 올릴게요. 레퍼런스랑. 그리고 뒷 이야기 잠깐 하자면 제가 오랫동안 지켜 보았는데 러시아 친구들이 상당히 잘하더라고요. 정말 잘합니다. 진짜. 그리고 재미있는 사실은 서버 에뮬레이터 개발 활발해지고 있으면 실서버도 사용자가 엄청 늘고 있고요. 이게 중단되거나 안하고 있으면 커뮤니티가 완전 죽은 경우 있잖아요? 그럼 실서버 수도 사실 급감하더라고요. 여기까지 발표는 하도록 하고요. 
제가 이제 질문 한 번 볼게요. 좋은 말씀 해주셨네요. “개발 장비 중고 판매나 하드디스크 복구로서 복구 가능...” 
정말 위험하죠. 사실은 팔지 않고요, 돈 좀 있으면 다 파기합니다. 전문 업체 불러다가. 이것은 아마 김정호 님께서 써 주신 것 같네요. 감사합니다. 하드디스크 반드시 폐기해야 되고요. 개발 시스템 업그레이드 할 때. 
그리고 “직접 경험해 보신 가장 크고 정교한 규모의 사설 서버가 사례가 뭐가 있나요?” 
정말 많습니다. 월드 오브 워크래프트 같은 경우는 정말 실서버 수준이고요. 지금은 모르겠어요. 불성까지만 해도 실서버 수준이었고, C# 버전도 있고, C++ 버전도 있습니다. 그리고 디아블로 3도 처음 나왔을 때 버전이 있어요. 지금 아마 셧다운 당했을 텐데, C#으로 만들었고요. 아이온 같은 경우는 자바로 만들어져 있고, 요즘 대세는 C#으로 많이 시도를 하는 것 같아요. 그리고 W3 같은 C# 서버도 있는데, 정말 배울 게 많았습니다. 제가 그 소스 코드를 보고. 아, C#을 이렇게 쓰는 거구나. 그런 것들이 있습니다. 조금만 찾아보시면 많이 나옵니다. github 같은 데에 있고요. 
“패킷을 감시하고 있거나 클라이언트 역공학 든다면 접속 대상 서버 정보를 통지 받을 때 특정 확률도 받는다. 구체적인 방법?” 
그냥 접속할 때 랜덤 돌리세요. 돌려서 몇%를 보내면 됩니다. 구체적인 방법은 없고요. 조금 머리 쓰면 접속할 때 말고 접속한 후에 그것을 보내면 됩니다. 보내면 되고요. 
그리고 마지막으로 하나만 하고 끝낼게요. “패킷 감시하고 있거나 클라이언트 역공학이 된다면 접속 정보 보고를 해커가 탐지할 가능성이 높아지는...” 
탐지 합니다, 결국은. 탐지하는데 처음에는 탐지를 제대로 못해요. 그래서 하나라도 누가 보내면 알 수가 있어요. 그렇죠? 그 하나를 알게 되면 뭘 알 수 있냐 하면, IP를 알 수 있고, 그러면 그 쪽의 법무법인, 아니면 해외 진출해있다면 그 쪽에서 알아서 해결하려고 하면 다음부터 안 생깁니다. 다른 데 도망가서 생기더라도 누군가 탐지가 되고요. 그리고 중요한 것은 정식 클라이언트를 써요, 서버 에뮬레이터들도 결국은. 그렇기 때문에 정식 클라이언트가 이런 것을 막고 하지는 않거든요. 아마 패치를 내는 경우도 있어요, 해커들이. 이거 패치 반드시 적용하고 쓰세요, 라고 하기는 하는데 그것을 사람들이 100% 따르지는 않아요. 귀찮은데 게임 즐기지, 그러면서 그냥 하죠. 그렇기 때문에 리포팅 받아요, 어쨌든. 그렇습니다.
여기까지 하고요. 2초 남았네요. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
