게임 서버 구축 (12)

jw·2023년 12월 16일
게임 서버 구축
0

게임 서버 구축

목록 보기
13/19
post-thumbnail

게임 서버 구현글은 굉장히 오랜만에 쓰는 것 같다.
글을 올리는 원래 시기대로라면, 4차 회의 이후 5차 회의 전까지 썼어야하는게 맞지만,
12일 종강날까지 도저히 여유가 없었어서.. 5차회의까지 진행한 이후 글을 쓴다.

4차(12/8), 5차(12/13) 회의

사실 이번 회의에서는 크게 많이 바뀐 부분은 없었다.

4차 회의 전후로는 각자 맡은 파트 중, 기존에 진행했던 부분중에서 문제점이나 개선할점은 없는지
더 공부했고, 5차 회의때는 현재 운영중인 마인크래프트 서버 중, 상위 Top10 안에 드는 유명한 서버에 가서 플레이해보는 시간을 가졌다 (벤치마킹..이랄까)

오늘 글에서는 다음 내용들을 다룰 것 이다.

  • 도메인 구입 & Cloudflare
  • 메인 서버 로그인 방식 변경 (pem키 & Google-OTP)
  • 타 서버 탐방 인게임
  • 고찰 및 향후 적용 방향

추가로 한 가지 바뀐점이 있다면, 서버 이름을 정했다!

FORECITY

숲을 의미하는 forest와 도시를 의미하는 city를 합쳐서 만들어봤다.
fore는 앞선, 미래를 뜻하기도 하니,
미래 도시 or 숲과 도시가 공존하는 서버 정도로 의미를 두고싶다.

INFRA - 보안

서버 보안 관련하여 알아보던 중, 다음과 같은 글을 보았다.

간단하게 말하자면, 자바 로깅 라이브러리인 Log4j 내부에서 발견되었던 보안 취약점으로, 마인크래프트 자바에디션을 사용하는 유저라면 문제가 되었던 사건이고, 약 2년전 사건이라 본인은 몰랐었는데 꽤나 큰 사건이였다고 한다. 현재는 해결되었다.

보안.. 생각은 늘 하고있었지만, 당장 지식이 많이 없는 우리에게는 구현이 우선이었기에 늘 뒤로 미뤄두던 존재였다. 하지만 현재 인프라 구성이 어느정도 진행이 되었기에, 4,5차 기간동안 특별한 설정을 더 한다기 보다 기존 해왔던 과정들을 돌아보며, 보안과 최적화 부분에 더 신경을 썼다.

도메인 구입 & Cloudflare

먼저, nslookup, ping 등 우리 서버 주소를 통해 서버 컴퓨터의 외부 ip가 버젓이 드러나는걸 막아보기로했다.

후에 진행할 웹 파트도 있기에 무료 도메인을 사용하는 것이 아니라, 유료 최상위 도메인을 구입해서 사용하기로 결정했다. 도메인은 가비아에서 구입했다.

도메인 구입

https://domain.gabia.com/
가비아 도메인 주소

1년 단위기는 하지만, 아무래도 .kr 같은 유명한 도메인들은 비싸다보니 조금 저렴한 신생 도메인으로 눈길을 돌렸다.

그 중에서 96% 할인을 하고있는 .online 도메인을 사용하기로 했다. 게임 서비스다보니.. 잘 맞는 것 같은 느낌도 있었다.

이렇게 주면 뭐가 남나요...싸다 싸

구입 이후 DNS 관리 화면

사실 가비아는 도메인 구입이 목적이지, DNS관리는 다른 네임서버인 Cloudflare에서 진행할 예정이였기 때문에, 별다른 설정은 하지 않고, 기존 가비아 네임서버에서 Cloudflare로 할당된 네임서버로의 변경만 해주었다.

Cloudflare

Cloudflare는 무료로 DNS 설정을 제공한다.
굳이 가비아도 DNS설정을 제공하는데, Cloudflare를 사용하는 이유는 외부 ip 노출을 막기 위해서이다. (사실 앞으로 내가 쓸 이 방법도 완전히 외부 ip 노출을 막아주는 방법은 아니다. 추후 더 공부해볼 예정)

사이트에 접속을 하고 회원가입을 하면 이런 페이지가 뜬다

오른쪽 상단의 추가 버튼을 눌러준다

앞서 구입한 forecity.online 도메인을 입력하고, 무료 버전으로 선택

이후 DNS 기록을 추가하는 페이지가 뜨면, 다음과 같이 A레코드를 추가한다. 이 때, A레코드는 실제로 우리가 운영하는 주소, 즉, ping을 치면 서버의 외부 ip가 뜨는 주소이기 때문에 남들이 쉽게 알 수 없을만한 주소로 기입한다. 추가로, 뒤에 있는 상태 버튼을 눌러 프록싱됨 상태는 해제해준다. 설정되어있으면 무료 버전에서는 오히려 느려지는 것이 해제해주는 이유라고 한다.

성공적으로 진행했다면, 이렇게 A레코드가 목록에 추가된다.
이후, 앞서 말했던 네임서버를 가비아 DNS관리에 들어가서 변경해주었다.
30분 ~ 1시간 정도 기다리면, 도메인이 성공적으로 연결되었다는 메일이 온다.

(사실 여기서 좀 많이 돌아갔던게, 도메인 설정이 이렇게 오래걸리는지 몰랐다. 다 맞게 하고선, 왜 접속 안돼? 왜 핑 계속 보내지지.. 이러면서 쓸데없는 시간을 허비했는데.. 이것도 배움이다 생각하고 다음부턴 조금 더 인내심을 가지고 설정해야겠다는 생각을 했다.)

도메인 연결이 성공적으로 끝났다면, DNS관리에서 SRV 레코드를 추가해주어야 한다.
앞서 '앞으로몰라야되는~' 라고 쳤던 그 도메인을 대상으로 넣어준다. 그 외에는 TCP 프로토콜과, 마인크래프트 기본 포트번호인 25565를 넣어주고 저장을 눌러주면 된다.
(이 사진은 나중에 다른 주소로 바꾸어 진행했기에 그대로 게시한다.)

결과

해당 주소로는 ping이 보내지지 않는다.

서버 주소도 이름 값만 나온다.

하지만 서버 접속은 원활하게 잘 된다. 성공!

메인 서버 로그인 방식 변경 (pem키 & Google-OTP)

기존 서버에 관리자 그룹과 권한 설정을 끝내기는 했지만, 여전히 로그인 방식은 password를 입력하는 방식을 쓰고있다. 보안을 위해 pem Key를 이용한 원격 접속 방식과 Google-OTP를 이용한 2FA 로그인 방식을 적용해보았다.

서버 SSH-key 설정

클라이언트에서 아래 명령어를 입력

$ ssh-keygen -t rsa -b 2048 -f server-key

엔터를 쳐주면 경로에 server-key와 server-key.pub 파일이 생성된 것을 확인할 수 있다.

$ cat server-key

해당 명령을 입력하여, 생성된 key 값을 복사한 후,
로컬 pc에서 메모장을 열어 값을 붙여넣고 .pem 확장자명으로 저장해준다.

$ sudo chmod 600 ~/.ssh/authorized_keys

디렉토리의 경로 설정도 함께 진행.

저장했다면, 로컬 환경에서 cmd 접속

$ icacls "pem 파일 경로" /inheritance:r
$ icacls "pem 파일 경로" /grant:r "%USERNAME%:R"

로컬에서 사용할 것 이기 때문에, 권한 및 유저를 다시 설정해준다.

여기까지 끝났다면 마지막으로

$ vi /etc/ssh/sshd_config

config 파일을 편집할 것 인데,
수정한 옵션들은 다음과 같다.

  • PubkeyAuthentication yes
  • PermitEmptyPasswords no
  • PasswordAuthentication no

Google-OTP 설정

OTP란? One Time Password의 약자로 말 그대로 일회용 비밀번호를 의미한다.
SSH로그인 시, 해당 방법도 가능하도록 추가했다.

sshd 설정은 앞서 설정했던 config에서

  • ChallengeResponseAuthentication yes

해당 옵션만 더 추가해주었다.

옵션 추가 이후, OTP 로그인을 설정하기 전에 패키지를 2개 설치해준다

$ yum -y install epel-release
$ yum -y install google-authenticator

설치 완료 이후 SSH PAM 설정을 해준다

vi /etc/pam.d/sshd

편집기를 통해 가장 밑줄에 다음과 같이 추가해준다.
맨 끝 부분의 nullok 옵션 같은 경우, 서버 관리자가 한 명이라면 딱히 상관 없는 옵션일 것 같기는 하지만, 우리 서버는 3명의 인원이 관리를 하기 때문에 개개인의 OTP를 사용하기 위해 넣어주었다.

설정을 완료했으면 ssh 서비스를 재시작한다.

$ systemctl restart sshd

재시작 이후 다음과 같이 입력

$ google-authenticator

그럼 다음과 같이 qr코드와 sekret key와 복구 코드 등을 준다.
(다소 지저분하지만 가리려면 어쩔 수 없었다..)

구글 OTP 앱을 설치하여 서버를 등록해준다.
복구 코드같은 것은 꼭 메모장에.. 캡쳐해서 남겨두었다.

이제 앱 설정이 완료되었다면, 다음으로 진행한다.

Do you want me to update your "/root/.google_authenticator" file? (y/n) 

y

.google_authenticator 파일을 홈 디렉터리에 생성할 것인지?

y로 답하여 진행

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) 

n

30초 마다 한번씩 나오는 비밀번호 한개로 여러번 로그인이 가능하게 할 것인지에 대한 질문.

n으로 답하여 한 비밀번호 당 한번씩만 로그인이 가능하도록 설정

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) 

n

시간동기화 관련 질문이다. 이건 영향이 크지 않아서, 권장값이 n이기에 n으로 진행했지만,
y로 선택하고 진행해도 무방하다.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) 

y

마지막으로 무차별 대입 공격 (brute-force-attack)을 방지하기 위한 설정.
(예전 수업때 들었던 용어였던 것 같은데, 낯설지 않아..)

3-초마다 생성되는 토큰에 3회 이상 인증에 실패하는 경우 일시적으로 로그인을 차단하도록 하라는 내용. 본인은 y로 선택하여 진행하였다.

설정 끝!

결과

  • pem key

  • Google-OTP

로컬 pc의 cmd로 접속해본 모습.

처음 테스트해보는 입장이기에, root 유저로 진행하였고
방법을 숙지한 이후 관리자 별로 재설정하였다.

두 가지 방법 모두 접속이 원활하게 잘 되는 것을 확인할 수 있다.

고찰

보안은 원래 어려운 부분이기도 하고.. 이정도만 해서는 안전하다고 할 수 없을 것 같다.
이 부분은 꾸준하게 공부해보고 vpn 등 다양한 시도를 해봐야겠다고 생각했다. 인프라에서 무엇보다 중요한건 스테이블한 상태니까..

그리고 추가적으로, 사실 처음 구상은 pem키를 사용해 서버에 접속하고, 접속 시 OTP verification 코드를 물어보게 하는게 계획이였다. 그런데 왜인지 모르겠는데 GPT한테 물어보니까 그 방법이 썩 좋은 방법은 아니라고 한다.. 이유를 모르겠다. 2개 다 맞춰야 서버에 접속 가능하니, 더 벽이 많아진 셈이라 좋은 것 아닌가? 그런데 GPT 말대로 자료를 찾아보니 해당 방법을 이용한 사람이 그리 많지 않았다. 둘 중 하나지 않을까 하는 생각을 했다.

  • 굳이 할 필요가 없다.
  • 진짜 보안이 떨어지는게 맞다.

이유야 어쨌든, 일단 두 가지 기능을 모두 쓰기로 했다. pem키가 없는 경우 verification 코드를 물어보고, pem키가 있다면 pem key를 사용해 로그인 하는 방식으로 결정.

타 서버 탐방기는 다음 글에서 다루겠다.

profile
jw
『Infra Engineering』
이전 포스트

게임 서버 구축 (11)

다음 포스트

게임 서버 구축 (13)

0개의 댓글

관련 채용 정보