사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)

25,810 views

Published on

사설 게임 서버를 막는 방법들에 대한 발표 슬라이드

Published in: Engineering
1 Comment
76 Likes
Statistics
Notes
  • key를 가지고 패킷 셔플링을 어떤 식으로 하면 되느냐는 문의가 좀 있습니다. http://preshing.com/20121224/how-to-generate-a-sequence-of-unique-random-integers
    이런거를 응용하셔도 됩니다.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
25,810
On SlideShare
0
From Embeds
0
Number of Embeds
10,987
Actions
Shares
0
Downloads
205
Comments
1
Likes
76
Embeds 0
No embeds

No notes for slide

사설 서버를 막는 방법들 (프리섭, 더이상은 Naver)

  1. 1. 사설 게임 서버를 막기 위한 방법들 (Private Game Server, 더 이상은 Naver!) NHN NEXT 구승모
  2. 2. 발표자 소개
  3. 3. * 2005년 WOW가 인생을 바꿔놓음 * WOW 오리지널 풀파밍 * 전투사령관 캐릭터 둘 그 이외 게임 업계 활동 * China GDC 2010 발표: “How to Support an Action-Heavy MMORPG from Angle of Server Architecture” * Game Developer Magazine 2012. 5월호 특집 게재: “Evolving MMORPG Combat” * 2006~ Server Programmer, L3, NCSOFT * 2007~ Gameplay Programmer, Server Architect, TERA, Bluehole * 2012~ Professor, Game Track, NHN NEXT
  4. 4. 강연 개요
  5. 5. Agenda • 사설 서버란? – 사설 서버의 영향 – 사설 서버가 생기는 경로 • 사설 서버 방지를 위한 노력과 방법 – 직접 탈취로부터 – 서버 에뮬레이터 제작으로부터
  6. 6. 강연 범위 • 강연 대상 – 온라인 게임 프로그래머 (서버, 플랫폼) – 게임 서버 보안에 관심 있는 사람 (프로듀싱, 서비스) • 다루지 않는 것 – 전반적인 서버 보안 방법 (DDOS, SQL Injection, …) – Reverse engineering 방지 관련 테크닉  사설 게임 서버에 특화된 내용을 다룸
  7. 7. 사설 서버 이야기
  8. 8. 사설 게임 서버란? • 게임 서버를 ‘탈취’하거나 ‘제작’하여 (원작자 동의 없이) 서비스 – Private server, Gray shard, Free server, Server emulator [1], … – 대부분의 경우 영리를 목적으로 함 • 주로 2가지 방법으로 생김 – 해커들이 직접 탈취한 것을 기반으로 • (예) AEGIS (Ragnarok Online) [2] – 서버 에뮬레이터 제작을 통하여 • 실제 정식 서버를 흉내(모방) 내도록 제작 • (예) WOW MaNGOS [3]
  9. 9. 사설 서버의 악영향 • 직접적으로는 Profit-share 감소 • 간접적으로는 (더 무서운 것) – 게임 자체에 대한 신뢰 하락 – 유저들이 존중(respect)받지 못한다는 느낌 • Nexon, Blizzard, Ncsoft의 사설 서버에 대한 소송 예 – 북미 1등(?) 메이플스토리 사설 서버인 OdinMS [4] – WOW 부분유료화 형태의 사설 서버인 Scapegaming [5] – 5만 사용자를 거느린 리니지2 사설 서버인 L2Extreme [6]
  10. 10. 왜 사설 서버를? • 돈을 벌기 위해 – 꽤 많은 인력들이 사설 서버 구축을 위해 노력 – 생각보다 많은 사람들이 플레이 함  꽤 짭잘(?) – CIS 관련 국가 및 중국 내륙 • (예) 한 때, 러시아 시장 1위는 리니지2 사설 서버 [7] • 교육적인(?) 목적 – 서버 에뮬레이터 제작의 경우, 해커들의 도전 의식 자극 + 재미 – “게임 서버 프로그래밍 공부하기 정말 좋다”는 함정
  11. 11. 직접 적인 유출(leak)로부터 사설 서버가 생기는 경우 • 개발사에서 직접 유출되는 경우 – 대부분의 경우 트로이 목마를 통한 유출 • 개발실 소스코드 유출 괴담: “출근 해보니 전부 체크아웃 되어 있더라?” • (예) 밸브의 하프라이프2 소스코드 유출 [8] • 우리 나라의 몇몇 회사들도 이렇게 털린 경우가 많음 (카더라 통신) • 퍼블리셔측에서 유출되는 경우 – 서비스 네트워크 또는 배포선에서의 탈취 • (예) 뮤 온라인의 해외 유출 [9] – IDC 근무자에 의한 인위적인 서버 바이너리 탈취
  12. 12. 서버 에뮬레이터 제작을 통하여 생기는 경우 • 해커들은 미리 서버 에뮬레이터 제작을 준비 – 폐쇄형 커뮤니티(private IRC, phpBB 등)를 통해 정보 공유 및 수집 • 패킷 구조, 클라이언트 보안 메커니즘 등 – CBT와 동시에 클라이언트 입수 후, 해당기간 중 다양한 실험 및 공유 • 서버 프로그래머: “어?! 이상하다. 이런 패킷이 올 수가 없는데?” • Non-Client Bot과 같이 만들어 짐 – 서버 에뮬레이터와 비슷한 시기에 (약간 먼저) 등장 • Non-client bot이 있다는 말은? 어딘가에서 서버 에뮬레이터가… • 사실상 한 뿌리: 서버를 흉내 내느냐 클라를 흉내 내느냐의 차이
  13. 13. 오늘의 진짜 주제와 결론 • 100% 막는 방법은 없습니다 – (작정한) 인원에 대한 보안은 정말 어렵기 때문 – 클라이언트는 이미 적의 수중에 있기 때문 • 그래서, 이미 버린 몸(?)이니 포기? – 어차피 털릴텐데 아무것도 안하기? • 그렇지만, 노력대비(?) 효과를 볼 수 있는 방법들은 있음 – 오늘의 핵심 주제
  14. 14. 사설 서버 방지를 위한 방법들 1 (직접 탈취를 막기 위한 노력)
  15. 15. 개발사에서의 직접 유출 • 트로이 목마(Trojan Horse)를 통한 유출이 대부분 – 개발 관련툴 크랙 버전에 심어서 토렌트 등으로 배포 • (예) V-Asst, I-Bld, A-CS, … – 개발자의 컴퓨터에서 실행되는 순간 • 백도어 생성후 해커에게 리포팅 • 리포팅 받은 해커는 바로 털어가지 않고, 지속적으로 감시 및 백도어 강화 • Windows Domain Admin 권한을 갖는 컴퓨터에 설치되는 순간 게임 오버 – 계속 지켜보다가 (어느 정도 완성되면) 순식간에 털어감
  16. 16. HOW-TO • 정품 개발 툴만 사용 – 검증되지 않은 프로그램 사용 금지 • 최신 소프트웨어로 업데이트 – 특히 OS의 경우, 구 버전의 취약점을 공략 • 보안에 자신 없으면 – 개발망을 인터넷으로부터 물리적으로 분리 (가장 확실) • Source repository, Issue tracking system 등
  17. 17. 인원 보안 문제 • 그럼에도 불구하고, 내부 사람에 의해 털릴 수 있음 – 가장 무서운 적은 내부의 적 – 퇴사시 별 생각 없이 습관적으로 가져가는 경우도 있음 • 악의적인 의도가 아닌 경우: (열정이 넘쳐?) 집에 가져와서 일하는 경우 • HOW-TO – 개발망 분리 후, 비인가 저장장치 사용 금지 – 회사에서의 작업물에 대한 교육(개념 주입) 필요 – 개발자들에게 잘해줘서 회사 떠나지 않게 하는 것 (가장 확실) • 개발자 괴롭히면? 복수심에 싹 다 들고 제 3국가 가서 서비스 할 수도.. (농담)
  18. 18. 퍼블리셔측에서의 유출 • 배포선(release process) 또는 IDC에서 유출되는 경우 – 내부 인원에 의한 유출 • 운영 인원의 권한 최소화 및 2-way 인증 필요 (뻔한 이야기) – 직접 해킹 당하는 경우 • 해킹 방어는 광범위한 영역 (본 강연 주제를 벗어남) – 100% 유출 막는 것은 불가 • 서버 바이너리의 유출 여부를 아는 것이 중요 – 어떤 버전이 어디를 통해 유출 되었는지 아는 것이 필요 – 탈취된 서버가 정상적으로 동작하지 않도록 하는 장치 도입
  19. 19. HOW-TO: 기본적으로 해야 할 것 • 인가된 채널로만 배포 – 급한 patch라고 메일 등으로 전송 금지 • 서버 프로그램 유효 기간 설정 (Time-bomb) – (예) 현재 실행 시각이 빌드 시점(__DATE__)로 부터 얼마 지났는지 체크 • Binary Fingerprint – 인증된 머신 정보를 서버 바이너리에 삽입 • (예) .data 영역을 확보 해놓고, 배포시에 인가된 머신 MAC주소로 교체 – 서버 실행시 해당 영역 정보와 머신 정보 비교
  20. 20. HOW-TO: 서버 실행 여부를 통지 받기 • 서버 시작시 80번 포트로 서버 정보 보내기 – 버전, 인가된 머신 번호, 퍼블리셔 코드 등을 암호화해서 전송 – Outbound 80번 포트(http)를 막는 경우는 거의 없음 – 리포팅은 제 3지대(Amazon EC, GAP 등) 서버에서 받기 • 리포팅 받은 것을 주기적으로 모아서 메일로 통보 받으면 편함 {NX_KOR, VER, IP, MAC, …} via HTTP/80 Reporting e-mail
  21. 21. 이것저것 다 귀찮은 경우… • 돈(?)으로 해결 할 수 있음 • 하드웨어 보안 모듈이 설치된 서버에 배포 – TPM[10]을 통한 디스크 암호화 등 • 라이선스 서버 솔루션 사용 – 인터넷을 통한 실시간 인증을 받아야 서버 실행이 가능
  22. 22. 사설 서버 방지를 위한 방법들 2 (서버 에뮬레이터 제작을 방해하기 위한 노력)
  23. 23. 서버 에뮬레이터의 경우 • 처음부터 보안에 신경을 써야 함 – 해커들은 최초의 외부 테스트(FGT, CBT)부터 클라이언트 분석 – 오픈 전에 서버 sandbox가 등장하는지 여부를 결정 • Sandbox? – 월드 접속 및 이동만 되는 일종의 더미 서버로 해커들의 첫 번째 목표 – 서버-클라이언트간 핵심 동작 메커니즘이 분석 당했음을 의미 • 두 측면에서 공략 – 패킷 분석 및 클라이언트 역공학(reverse-engineering)
  24. 24. 클라이언트 역공학 • 동작 메커니즘 분석 – DLL injection등을 통해서 send/recv API 부분을 hooking – 서버-클라이언트간 어떤 데이터를 어떻게 주고 받는지 파악 • 시간과 노력이 많이 들지만 암호화 관련 로직 우회 가능 • 게임 데이터 추출 – 아트 리소스 뿐만 아니라 게임에 필요한 각종 데이터시트 정보들 • (예) 스킬 공격력, 아이템 스탯 테이블 등
  25. 25. HOW-TO: Anti-Reverse Engineering • 광범위한 주제 – 기초적인 것만 해도 해야 할 것이 많음 [11] • 해커들의 속도를 따라잡기 힘든 부분 – 개발자가 일일이 적용하는 것은 비용대비 효과 측면에서 비추 • 클라이언트 바이너리 난독화 전문 툴 사용을 추천 – Themida (WinLicense) [12] 등 (의외로 싸다) – 지속적으로 최신의 반-역공학 방법들이 업데이트 됨
  26. 26. HOW-TO: 꼭 필요한 데이터만 패키징 • 클라이언트에서 꼭 필요한 (client-only) 데이터만 넣기 – 의외로 서버에서만 필요한 데이터도 같이 넣는 경우가 많음 • (주로 귀차니즘 때문에) 통합 데이터시트로 하는 경우 – 배포 툴에서 패키징 자동화하는 것을 추천 • 데이터 항목에 서버/클라/공용 태그 넣기 • [참고] 서버 에뮬레이터 제작시 가장 더럽고(?) 귀찮은 부분 – 실 서버와 같은 데이터 값(밸런싱 정보 등)을 수집하여 입력하는 것 – 클라이언트에 해당 정보가 있다면, 손쉽게 추출해서 사용하게 됨 • (예) W모 게임의 경우, dbc파일 추출 후 그대로 읽어서 사용
  27. 27. 패킷 분석 • 서버-클라이언트간 패킷 수집(capture) – 어떤 내용이 오가는지 알면, 서버/클라이언트 모두 흉내낼 수 있기 때문 – 암호화 하지 않는 경우 클라이언트 역공학을 시도할 필요도 없음 • 패킷 암호화 – 아무리 잘해도 언젠가는 파악당함 (클라이언트 역공학) • 개발자가 덜 귀찮도록 하는 방식으로 관리하는 것이 핵심 • 패킷 내용들이 파악되어도 조금만 수정하면 시간을 또 벌 수 있도록 – 패킷 수집(감청)으로부터 최소한 유저들의 정보를 보호하기 위함 • Raw data 그대로 수집되면 위험한 것들 (ID, PIN, 메일주소, 채팅내용 등)
  28. 28. HOW-TO: 패킷 암호화시 주의할 점 • 직접 설계하거나 구현하지 말 것 – 이미 검증되고 리뷰 많이 받은 잘 만들어진 코드를 사용 [13] • (예) AES256, RC4, … • 아무리 독창적인(?) 암호화 알고리즘을 만들더라도 파악됨 • 결국, key를 잘 관리하는 것이 핵심 • 절대로 key를 클라이언트에 박지(?) 말 것 – 사실상 암호화 하지 않는 것과 같음 – Key는 세션을 맺을 때마다 무조건 새로 생성해서 교환해야 함
  29. 29. HOW-TO: 암호화 통신을 위한 Key 교환 • Diffie-Hellman Key Exchange [14] – 세션 성립시마다 새로운 키로 암호화하기 위함 – 각종 공격(예: MITM)에 안전한 구현체를 사용할 것 (예: SRP) ClientServer 소수 p, g a b crypto-key ClientServer 감청 당해도 crypto-key 파악 불가 Transport K = B^a mod pB = g^b mod p a b B A A = g^a mod p K = A^b mod p
  30. 30. Secure Remote Password Protocol • SRP [15] – 스탠포드 대학에서 제작 (현재 버전은 SRP-6a) – 인증 + 키 교환 + 패스워드 암호화를 한방에 해결! – 인증에 사용되는 비밀 정보가 일부 털려도 안전 – 사전 공격 및 MITM 공격 등으로부터 안전 – 공인 인증 기관 (CA) 필요 없음
  31. 31. HOW-TO: 패킷 암호화시 주의할 점 • 패킷 전체를 스트림 방식으로 암호화 – (예) W모 게임처럼 패킷헤더만 암호화 하는 경우  raw data 노출됨
  32. 32. HOW-TO: 패킷 셔플링 • 패킷 번호 및 패킷 내용 순서 무작위 치환 (shuffle) – 패치 때마다 패킷이 바뀌는 효과  해커들 입장에서는 상당히 귀찮음 – SVN revision 번호 또는 GIT tag hash를 key로 활용 가능 – 배포시 자동화 추천: pre-build event로 패킷 코드 생성(emit)할 때
  33. 33. 이런 노력에도 불구하고, • 서버 에뮬레이터 제작을 100% 막기는 불가 – 어차피 클라이언트는 언젠가는 완전히(?) 분석 당함 – 어딘가에서 서버 에뮬레이터가 만들어지고 있는지 아는 것이 중요 • FACT – 서버 에뮬레이터도 결국 (인터넷상의) 일반인 대상으로 서비스 • HTTP 포트(80)를 일부러 닫고 사용하는 유저는 없다는 점을 이용 – 클라이언트는 정식 배포본을 사용한다는 점을 이용 • 플레이어의 클라이언트가 어느 서버에 접속하는지를 직접 리포팅 • 대상 서버 IP가 127.0.0.1, 192.168.x.x 이런 종류라면 제작 중이라는 뜻
  34. 34. 접속 대상 서버 정보를 통지 받기 map-reduce & whois 사설 서버 사설 서버 유저 (클라이언트) Random sampling report via HTTP 클라이언트가 특정 확률로 서버 정보 리포팅 정식 서버 정보는 걸러내고 리포팅
  35. 35. 정리
  36. 36. 마무리 • 100% 방지법은 없음 – 최소한의 노력은 하자: 언급한 방법들이 난이도 높은 일이 아님 – 어차피 털린다고 손 놓은 것과는 차이가 큼 (방충망이 유무의 차이) • 관리의 측면으로 접근 – 지속적으로 모니터링 및 수정(자동화)을 통해서 시간을 벌기 – 내가 보안에 쓰는 노력보다 해커가 뚫는 노력이 더 큰 것 위주로 적용 • 숨기는 것 보다 찾는 것이 더 어려운 이치 • 실제로 상당히 효과적이었음
  37. 37. 감사합니다. Any Questions?
  38. 38. References 1. http://en.wikipedia.org/wiki/Server_emulator 2. http://en.wikipedia.org/wiki/AEGIS_(Ragnarok_Online) 3. https://github.com/mangos/MaNGOS 4. http://maplenewsnetwork.wordpress.com/2008/06/18/odinms-vs-nexon/ 5. http://www.gamerlaw.co.uk/2010/blizzard-wins-88m-lawsuit-against-wow-private-server-owner/ 6. http://www.gamasutra.com/php-bin/news_index.php?story=11786 7. http://www.thisisgame.com/special/page/event/ion/2008/nboard/79/?n=8335 8. http://www.gamespot.com/articles/half-life-2-source-leaked/1100-6076314/ 9. http://m.inven.co.kr/webzine/wznews.php?idx=14253 10. http://en.wikipedia.org/wiki/Trusted_Platform_Module 11. http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide 12. http://www.oreans.com/themida.php 13. http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding- encryption-and-cryptology 14. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange 15. http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
  39. 39. 뒷이야기 • 수년간 지켜본 입장에서의 개인적인(?) 느낌 • 서버 에뮬레이터 구현 능력 – 프로그래밍 실력? – 러시아 친구들(잉여력까지 느껴짐) >> 중국 해커들 > 미국 해커들 • 실제 게임(실서버)의 흥망성쇠(?)와 상관 관계 있음 – 서버 에뮬 개발이 활발해지고 있는 추세 ∝ 실서버 사용자 수 – 개발이 중단되거나 관련 커뮤니티가 완전 죽은 경우 • 실서버 사용자 급감 상황
  40. 40. 서버 에뮬레이터 제작 커뮤니티 • 서버 에뮬레이터는 다양한 버전이 존재 – Sandbox 이후로 다양한 버전 – 수익금 기부(donation) 문제 등으로 커뮤니티 분열이 잦음 • 누군가 (몰래) 서비스, 핵심 멤버 탈퇴, 원 제작자로부터의 추적 등 – 누군가 기존 작업물을 가져다가(stealing) 새로운 프로젝트로 포장 • 비슷한 이유로 또 분열  반복

×