1. 개요
우연한 계기로, 2023년도 호남지역 정보보호 해커톤운영 및 개발 일체를 담당할 수 있는 기회가 생겼습니다. SaturnX 팀원 각자의 경험과 노하우를 발휘할 수 있는 좋은 기회라고 생각했습니다. 요청이 들어온 당일에 SaturnX 팀 내 일부 팀원과 Squad를 조직하고 목표를 설정하였습니다.
스쿼드
Squad 조직의 역할은 심플하게 구성하였습니다. 각 분야별 문제 출제 역할로서 5명의 팀원과, 문제의 검수 및 난이도 조절 역할로서 팀의 리더가 함께 참여했습니다.
황정식 프로젝트 매니징 & 개발 및 운영 일체
팀 5인 : misc, web, pwnable, reverse engineering, digital forensic 문제 출제 & 검수
리더 : 문제 난이도 검증 및 검수 일체
목표
이번 대회 운영 목표를 설정하는 과정에서 많은 의견이 오고 갔습니다. 특히 앞으로의 팀 활동을 위해서 이번에는 조금 색다른 도전을 해보고 싶어졌습니다. 여러 해킹대회를 운영해보며 누적된 개발 요구사항을 반영해보고 싶었고, 또한 해킹대회 운영 준비 프로세스를 정립하여 추후 새로운 대회를 운영할 때, 보다 효율적으로 수행할 수 있도록 도움이 될 뼈대를 만들고자 하였습니다.
공통 목표
1.
사전에 필요한 요구사항을 파악하고, 공유하여 효율적인 프로젝트 진행을 목표로 함
2.
프로젝트 진행을 위한 로드맵을 설계하고 로드맵을 준수할 수 있도록 노력함
문제 출제 목표
1.
대회 문제 출제 과정 중 대회 참여자의 니즈를 파악하여 적절한 난이도를 설정
2.
1st Solver의 풀이 난이도 설정(70 ~ 80% clear)
3.
분야별 창의적인 아이디어를 통한 문제 스타일 설정 및 풀이 난이도 조절
4.
Flag 형태 통일
서비스 개발 목표
1.
Frontend와 Backend를 분리하여 새로운 프로젝트로 개발진행함
a.
파생되는 트러블 슈팅 테스트를 위한 테스트
b.
테스트 코드 작성 및 인프라 개선 방향 고민
2.
구조 설계
3.
문서화
2. 문제 출제 & 개발
문제 출제
문제 출제 및 개발을 위해 분야별 역할을 나누었습니다. 대회 주관사의 요구사항과 더불어 추가 요청사항이 있는 부분을 유선 통화 Kick-off 를 통해 정리하였습니다. 그리고 정리된 내용을 Notion에 정리하고, 필요한 내용을 요약하여 별도의 SNS 채널을 통해 요구사항과 문제 출제 내용, 일정 등을 공유하였습니다.
[ 요구사항 ]
1. `최다 풀이자가 70% 이상 문제를 풀이할 수 있을 정도`의 난이도로 출제
2. 참가자는 아직 대회 경험이 별로 없어, 의미있는 경험이 될 수 있었으면 함
[ 문제 출제 ]
1. 각 분야별 5문제(담당자별)
2. 초급 수준 4문제
3. 중급 문제 1문제
[ 일정 ]
1. 문제 기한 : 2023.10.14. (토요일)
2. 대회 일정 : 2023.10.28. (토요일) 14:00 ~ 22:00
문제 출제 내용 및 Write Up의 경우 아래의 노션 링크에 템플릿을 생성해두었습니다. 확인 부탁드릷니다.
Plain Text
복사
위의 요구사항과 일정을 맞추기 위해 개발자인 저를 포함하여 스쿼드 조직 모두와 함께 적절한 수준의 문제를 연구하여 출제하였습니다. 출제한 문제는 팀 Notion을 통해 공유하고 적절성 여부를 함께 검토하였습니다. 필요 시 문제의 난이도를 조정하거나 다시 출제하는 등의 검수 과정을 거쳤고, 문제 기한보다 조금 빠르게 출제를 완료할 수 있었습니다.
문제의 수준은 Level은 1 ~ 5로 구분하였습니다. 각 분야별 레벨링은 분야의 특성 상 일정 수준의 배경지식을 갖추고 있다는 가정하에 문제에 도전한다는 가정을 두고, 다음과 같은 목적으로 출제하였습니다.
•
Level 1 : 문제는 구글링 혹은 다양한 방법으로 풀이가 가능할 정도의 쉬운 수준
•
Level 2~3 : 수준의 문제는 충분한 구글링으로도 충분히 풀이 가능할 수 있는 수준
•
Level 4~5 : 수준의 문제는 변별력을 부여하기 위해 모의해킹 기법의 응용이 필요한 수준
서비스 개발
저는 일체의 개발 역할을 담당하게 되어 기존에 사이드 프로젝트 성격으로 개발해두었던 CTF 서비스 내에 필요한 요구사항을 다시 정의하고 Frontend, Backend가 분리되어 개발 및 운영될 수 있도록 구조를 잡아보았습니다. 인프라는 Vultr VPS를 이용하여 구성하였습니다.
Frontend
아쉽게도 React.js 등 프론트 개발 능력이 부족하여, 대체제로써 Flask + Bootstrap Template을 이용하여 프론트 역할을 수행하였습니다. Flask에서는 별다른 연산이 없고 데이터를 받아와 rendering하는 역할을 맡기 때문에 스펙이 높을 필요가 없다고 판단되었습니다. 때문에 2Core 4GB 스펙으로 Dockerize 하지 않고 Host에서 구동하였습니다. 기술스택은 다음과 같습니다.
•
Python : 3.8 + poetry 1.6
•
Framework : Flask 1.1.4 + Bootstrap 5
•
Web-Server : Apache2 + mod_wsgi
Backend
백엔드의 경우 생산성 및 개발 요구사항이 변경될 시 빠른 수정을 위해 DRF를 이용하였습니다. Backend에서는 랭킹 연산이나 문제 조회등의 다양한 요청이 올 것을 고려하여 Frontend보다 많은 Process를 부여하여 운영하였습니다. 서버 스펙은 4Core 8GB로 하였고, 인프라는 Dockerize 하지 않고 Host에서 구동하였습니다. 기술 스택은 다음과 같습니다.
•
Python : 3.11 + poetry 1.6
•
Framework : Django 4.2 + DRF 3.14
•
Web-Server : Nginx + Gunicorn
스트레스 테스트
실질적으로 한 번에 받아들일 수 있는 트래픽의 양을 검수하기 위해 가장 연산이 많이 발생하는 ranking API를 이용하여 스트레스 테스트를 수행하였습니다. 스트레스 테스트를 위해 multiprocessing python code를 작성하였고, 결과적으로 Flask 프론트엔드와 DRF 백엔드 서버의 위 스펙으로 23.5TPS, 약 1400TPM이 나오는 것을 확인하였습니다. 100명의 유저가 동시에 요청이 올 수 있는 조건이며, 초반의 회원가입과 문제 조회 그리고 후반 Ranking 조회 시 트래픽 관리에는 문제 없는 수준으로 판단되었으며, 운영 과정에서 서버 이슈가 없는 것을 확인할 수 있었습니다.
Backend 테스트 시나리오
아래의 시나리오대로 Backend 테스트를 수행하면서 Gunicorn에서 권장하는 프로세스 수(CPU * 2 + 1)만큼 메모리에 올려 구동하였을 때가 가장 적절하게 운영됨을 확인하였습니다.
1. Python을 이용하여 multiprocessing 테스트 스크립트 작성
2. api.saturnx.team/api/v1/ranks 조회 요청
3. CPU 및 RAM 점유율 측정
3.1. Nginx -> Gunicorn Queue 정상 동작 여부 확인
3.2. Gunicorn을 이용하여 생성된 DRF Process가 적절히 사용되는지 확인
3.3. 적절한 Gunicorn process 개수 확인 후 반영
4. Scale Up의 필요성 확인 후 반영
5. 연산/통신 이슈 없을 시 릴리즈
Plain Text
복사
Frontend 테스트 시나리오
Backend 테스트 시나리오를 마치고, Frontend를 통해 적절히 API 통신이 이루어지는지 확인하였습니다. 이는 한 번에 트래픽이 몰렸을 때 해결할 수 있는가, Unique 필드에 이슈가 발생하지 않는가 등을 확인할 수 있었습니다.
1. Python을 이용하여 multiprocessing 테스트 스크립트 작성
2. ctf.saturnx.team/ranks 조회 및 ctf.saturnx.team/sign/up 생성 요청
2.1. ranks 조회의 경우 Session 없이 진행
2.2. sign/up 호출 시 회원가입을 위해 임의의 payload를 전달
3. 가용성 여부 확인
3.1. 회원가입(sign/up) 호출 시 unique 필드 이슈 확인
3.2. ranks 조회 시 API 서버와 통신 후 반환 속도 측정
4. Scale Up의 필요성 확인 후 반영
5. 연산/통신 이슈 없을 시 릴리즈
Plain Text
복사
3. 운영
운영은 온/오프라인 두 환경에서 이루어질 수 있는 게이트웨이로써 Discord를 활용하였습니다. 디스코드를 이용하여 각 분야별 이슈를 대응할 수 있도록 채널을 별도로 생성하고, 권한을 분리하여 채널을 목적에 맞게 이용할 수 있도록 구분하였습니다.
역할(Discord)
역할은 Admin, Operators, Staff, Everyone 네 가지로 구분하였습니다.
•
Admin : 채널 소유자(황정식)
•
Operators : 채널 내 공지사항 및 이용자 관리 권한(SaturnX 팀)
•
Staffs : 외부 대회 운영진
•
Everyone : 대회 참여자
공지사항
대회 운영 규칙은 Discord 채널을 통해 공유하고, 내용은 다음과 같습니다.
## 채널 및 이용 관련 공지사항입니다.
### 이용안내
* 닉네임은 반드시 __**`팀명_이름`**__ 으로 설정해주시기 바랍니다.
* 예시> __**`DUMMYTEAM_황금별`**__
* 서버내에서만 사용할 프로필 이름을 지정할 수 있습니다.
* 2023 HISSC 정보보호해커톤(서버이름) 클릭 -> 서버프로필편집 -> 서버별명
### 채널 안내
* __**`misc`**__ : Misc 분야 문제 문의 채널입니다.
* __**`web`**__ : Web 분야 문제의 문의 채널입니다.
* __**`pwnable`**__ : Pwnable(System) 분야 문제의 문의 채널입니다.
* __**`reversing`**__ : Reverse Engineering 분야 문제의 문의 채널입니다.
* __**`forensic`**__ : Digital Forensic 분야 문제의 문의 채널입니다.
## 플래그 형태 및 인증 방법
* 플래그 형태는 __**`flag{[a-zA-Z0-9_!@$\?\-].*}`**__ 입니다.
* flag{} 의 중괄호 내에 값이 입력되어야 합니다.
* 영어 **`대/소문자`** + **`숫자 0~9`**와 함께 특수문자는 **`_`**, **`!`**, **`@`**, **`$`**, **`?`**, **`-`** 총 6개의 특수문자가 포함될 수 있습니다.
* 제공되는 홈페이지 내에 Flag를 입력할 수 있는 페이지가 있습니다. 해당 페이지에 플래그값을 인증하여 전송하면 인증되게 됩니다.
--> 단, 전수공격과 같은 지나친 입력은 삼가부탁드립니다.
--> Flag 인증시간은 대회 시간 내에만 가능합니다.
Markdown
복사
또한 운영 과정에서 발생하는 공지사항의 경우 채팅과 채팅 내 스레드를 이용하여 적절히 공지하는 형태로 운영하였습니다. 대부분의 이슈는 온라인으로 충분히 해결하였으나, 현장에 방문하여 오프라인으로 관리를 병행하여 효과적인 대응을 할 수 있었습니다.
4. 대회 결과
성공적으로 대회를 마무리 하였으며, 대회 참여자들의 인터뷰를 진행했습니다. 전체적으로 문제의 퀄리티에 대해 좋은 평가를 주었습니다. 특히 분야별 문제 출제 스타일에 대해 독특하고 재미를 유도하여 즐거웠고, 무엇보다 짧은 해킹대회를 감안하여 취약점이 직관적으로 와닿을 수 있게 출제되어 원활한 대회가 이루어질 수 있었다는 평가가 인상깊었습니다. 또한 특정 분야에 치우치지 않고 적절한 난이도로 출제되었음을 알 수 있었습니다.
위 그래프에서 확인할 수 있듯, 난이도별 약간의 차이는 있었으나 중상위권의 치열한 접전을 확인할 수 있었습니다. 각 팀 내의 스페셜리스트가 다르게 분포 되었음에도 불구하고 의도한 것 이상의 효과를 볼 수 있었습니다. 의도한 방향대로 상위권 팀(1~3위)의 팀이 약 60~70% 이상의 문제를 풀이하였습니다. 이를 바탕으로 보아 대회의 본질에 충실한 대회로 마무리할 수 있었습니다.
5. 마무리
이번 해킹대회 운영을 바탕으로 서비스 런칭과 운영을 위해 필요한 조건을 구성하고 이루어가는 과정을 경험할 수 있었습니다. 특히 구체적인 팀의 목표를 설정하여 체계적으로 프로젝트를 마무리하여 뜻깊은 경험이었습니다. 이러한 기회를 주신 (주)비즈웨어와 한국인터넷진흥원, 광주정보문화산업진흥원, 호남정보보호지원센터에 감사드리며 다음번에도 이러한 기회가 주어지면 보다 발전된 모습으로 서비스를 운영하기를 기대해봅니다.