RTB Logo
Raccoon The Box
← Home 박스 제출하기

Q & A — 라쿤더박스 자주 묻는 질문

· 처음 박스를 만드는 박스 제작자 분들을 위해, 예시 Linux 스크립트 example_machine.sh 파일을 제공합니다.
· 실제 RTB 제출용 스크립트를 작성할 때, 구조와 흐름을 참고해 주세요.
📦 예시 Linux 박스 스크립트 다운로드 (example_machine.sh)

Q. 박스를 처음 만들어보는데 어디서 시작해야 하나요?

시작은 “어떤 취약점을 보여주고 싶은지 + 간단한 시나리오”를 정하는 것부터입니다. 단순히 OWASP Top 10 몇 개를 끼워 넣는 것보다, 한 가지 흐름을 가진 작은 서비스/시스템을 상상해 보세요.

예를 들어:

  • 취약한 파일 업로드 → 웹쉘 → 로컬 권한 상승 (Easy)
  • 약한 인증 + 잘못된 액세스 제어 → 내부 관리 페이지 접근 (Medium)
  • 간단한 내부 서비스 SSRF → 메타데이터에서 크레덴셜 탈취 (Medium)

Q. RTB 난이도(Easy / Medium / Hard / Insane)는 어떻게 정하나요?

난이도는 “플레이어가 얼마나 많은 단계를 거쳐야 하는지”, 그리고 “얼마나 많은 배경지식을 요구하는지”로 구분합니다.

먼저 본인이 생각하는 난이도로 제출하고 최종 난이도는 RTB 검수 과정에서 조정될 수 있습을 알려드립니다.

Q. ‘좋은 박스’는 어떤 느낌인가요?

RTB는 단순한 CTF식 또는 특유의 "굳이 꼬아서" 내는 식의 문제보다는 아래와 같은 항목을 중점으로 한 박스제작을 권고 드립니다.

  • 현실성: 실제로 존재할 법한 서비스/시스템 구조
  • 명확한 흐름: 각 단계가 논리적으로 이어지는 공격 경로
  • 학습 포인트: 박스를 끝내면 “이 기술을 배웠다”라고 말할 수 있는 키워드 2~3개
  • 적절한 길이: Easy/Medium 기준 2~4단계 정도의 깔끔한 경로

반대로, 아무 의미 없는 서비스 여러 개를 붙여놓고 “여기도 취약, 저기도 취약”만 있는 구조는 피하는 것이 좋습니다.

Q. 박스 제작자는 어떤 식으로 소개되나요?

박스가 선정되면 RTB에서는 다음 정보를 함께 공유할 수 있습니다.

  • 박스 제작자 닉네임 또는 이름
  • 제작자 GitHub / 블로그 / LinkedIn 링크 (선택)
  • 선택 사항으로 박스 제작자가 직접 작성한 공식 워크스루 글/영상

이 정보들은 모두 이력서, 포트폴리오, 취업 면접에서 본인이 만든 실습 환경을 설명할 때 활용할 수 있습니다.

Q. 저작권은 누구에게 있나요?

박스의 저작권과 IP는 100% 박스 제작자 본인에게 귀속됩니다. 라쿤더박스(레드라쿤)는 단지:

  • 교육용 플랫폼에 해당 박스를 게시하고,
  • 라이브/녹화 강의나 워크스루에서 소개할 수 있는 비독점적 사용 권한

만 갖습니다. 제작자가 원할 경우, 일정 절차를 통해 비공개/삭제 요청도 가능합니다.

Q. 실제 회사/실제 서비스 이름을 써도 되나요?

아니요, 실제 조직/서비스/실제 계정 정보는 절대 사용하면 안 됩니다.

  • 실제 회사 이름 → 가상의 회사/서비스 이름으로 변경
  • 실제 계정/토큰/개인정보 → 전부 가짜 데이터로 치환
  • 실제 내부 시스템 구조 재현은 되도록 피하고, 일반화된 구조 사용

박스는 어디까지나 교육용·연습용 환경이어야 하고, 실제 시스템의 비밀정보를 포함해서는 안 됩니다.

Q. 박스 용량이나 스펙에 제한이 있나요?

대략적인 가이드라인은 다음과 같습니다.

  • Linux: 가능한 한 BASH 스크립트 기반으로 설치되도록 구성
  • Windows: OVA/OVF 기준 수십 GB 이상은 지양 (압축 포함)
  • 불필요한 대용량 샘플 데이터, 로그 파일은 최소화

애매한 경우에는 박스 제작하기 설명에 “용량이 크지만 이런 이유로 필요합니다”라고 적어 주세요.

Q. write-up은 누가 작성하나요?

기본적으로 박스 제작자 본인이 원하는 형식으로 작성해서 GitHub Gist, 블로그, PDF 등으로 공유할 수 있습니다. RTB는 그 링크를 박스와 함께 소개하는 방식입니다.

별도로, 라쿤더박스에서 교육용 풀이 영상/워크스루를 추가 제작할 수 있으며 이때도 박스 제작자의 이름을 함께 언급합니다.

Q. 이미 개인 CTF용으로 만든 VM이 있는데, RTB용으로 재활용해도 되나요?

가능합니다. 다만 RTB에 맞게 다음 항목들을 한 번 더 점검해 주세요.

  • CTF 특유의 난해한 러빗홀(의미 없는 꼬아서 낸 트릭들) 줄이기
  • 스토리/서비스 설명을 조금 더 "실제 환경" 느낌으로 정리
  • 루트 플래그 외에 학습 포인트 2~3개가 잘 드러나는지 확인
  • 자동 프로비저닝 스크립트 또는 재현 절차 정리

Q. 박스를 만들 때 "안 하면 안 되는" 체크리스트가 있나요?

간단한 체크리스트는 다음과 같습니다.

  • ☑ 실제 개인정보/계정/토큰이 들어가지 않았는가?
  • ☑ user / root 플래그가 명확하게 분리되어 있는가?
  • ☑ 의도하지 않은 너무 쉬운 우회 경로(unintended path)가 없는가?
  • ☑ 플레이어가 막혔을 때 참고할 수 있는 최소한의 힌트를 넣을 계획이 있는가?
  • ☑ 박스 삭제/비공개 요청 시를 위해, 제작자가 로컬에 원본을 잘 보관하고 있는가?

RTB 난이도 가이드 — Difficulty Overview

라쿤더박스에서 박스를 제출할 때 참고할 수 있는 권장 난이도 가이드 표입니다. 실제 운영 시에는 이 기준을 바탕으로 RTB 측에서 난이도를 조정할 수 있습니다.

난이도 설명
Easy
  • 보통 2–3단계 정도의 짧은 경로
  • 공개 PoC 또는 기본적인 취약점(예: 단순 업로드 우회, 약한 패스워드)
  • 복잡한 바이너리 익스플로잇 없음
  • 기본적인 권한 상승(잘 알려진 SUID, 단순 misconfig)만 포함
Medium
  • 보통 3단계 이상의 경로
  • 커스텀 구성, 직접 분석이 필요한 취약점
  • 경로는 비교적 명확하되, 어느 정도의 탐색과 추리가 필요
  • 간단한 스크립트 작성/자동화가 요구될 수 있음
Hard
  • 대략 3–5단계 또는 여러 취약점 체이닝
  • 여러 서비스/계정/권한을 넘나드는 복합 경로
  • 심화된 네트워크/시스템/AD 개념이 필요
  • 헛된 러빗홀은 최소화하되, 난이도는 높음
Insane
  • 5단계 이상 또는 매우 난이도 높은 2–3단계
  • 복잡한 익스플로잇, 체이닝, 논리적 퍼즐 등 자유로운 구성
  • 플레이어에게 강한 인내심과 깊은 이해도를 요구
  • 러빗홀이 존재할 수 있으나, 가능한 한 “의미 있는 학습 포인트”를 가져야 함

박스 제작 가이드 — 처음 만드는 RTB 박스 가이드

라쿤더박스에 박스를 제출하고 싶은 박스 제작자들을 위해, “처음 박스를 만드는 과정”을 단계별로 정리한 가이드입니다.

1. 아이디어 & 취약점 선정

먼저 “어떤 공격/취약점을 보여줄 것인지”를 정합니다. 예를 들어:

  • 간단한 파일 업로드 우회 + SUID 권한 상승 (Easy)
  • 약한 웹 인증 → LFI → 로그 포이즈닝 → 쉘 (Medium)
  • 내부 대시보드 RCE → 크레덴셜 획득 → 시스템 전반 장악 (Hard)

취약점만 나열하는 것이 아니라, 플레이어가 배우게 될 키워드를 2~3개 정도 정리해 두면 좋습니다.

2. 스토리라인 만들기

"이 호스트가 실제로 존재한다면 어떤 백그라운드를 설정해야할까?"를 상상해 봅니다.

  • 가상의 코인 거래소, 병원, 스타트업, 교육기관 등 설정
  • 공격 경로와 서비스 목적이 어느 정도 자연스럽게 연결되도록 구성
  • 너무 직설적인 CTF 느낌(의미 없이 취약점만 있는 환경)은 피하기

완벽한 소설이 필요하진 않지만, 최소한 "이 기능이 왜 있는지" 정도는 설명할 수 있어야 하며 박스를 푸는 유저들이 "이유있는 행동"을 유도해야 합니다.

예시: 간단한 RTB 박스 시나리오

  • 가상의 회사 라쿤 코인 채용 포털
  • 지원서 업로드 기능에 파일 검증 취약점이 있음
  • 업로드된 파일이 웹 루트에서 실행 가능 → 웹쉘
  • 시스템 내부에 잘못 설정된 SUID 바이너리 → root 권한 상승

3. 설계 (Design) 가이드

화이트보드, 메모장 등을 활용해 간단한 다이어그램을 그려보세요.

  1. 초기 칩투 (웹, SSH, 특정 포트 등)의 Attack Vector는 어디인가?
  2. 어떤 정보/취약점을 통해 다음 공격 단계 (Initial access -> lateral movement)로 넘어가는가?
  3. 최종적으로 root 또는 핵심 자산에 어떻게 도달하는가?

이 다이어그램이 논리적으로 말이 되면, 실제 박스도 대부분 자연스럽게 구성됩니다.

4. 개발 & 자동화

RTB는 가능하면 "스크립트 또는 재현 가능한 이미지"를 권장합니다. 예: setup.sh 스크립트 하나로 VM에 취약 구성이 자동 적용.

  • 기본 OS 설치 → 스냅샷
  • 서비스 설치/설정 → 스냅샷
  • 취약점 주입 → 스냅샷

이런 식으로 단계를 쪼개두면, 문제 생겼을 때 되돌리기가 쉬워집니다.

Linux 박스 예시 흐름

  1. Ubuntu 서버 기본 설치 + 업데이트
  2. Apache/Nginx, PHP, DB 등 필요한 패키지 설치
  3. 가상의 웹앱 코드 배포 (취약한 업로드, 취약한 로그인 등)
  4. 루트 플래그 파일(/root/root.txt) 생성
  5. 모든 과정을 example_machine.sh 같은 스크립트로 묶기

5. 테스트 & 러빗홀 관리

제작 중에는 "플레이어 입장에서 처음부터 끝까지" 여러 번 테스트해야 합니다.

  • 의도하지 않은 더 쉬운 경로(unintended path)가 있는지 확인
  • 한 번 exploit하면 서버가 망가지는 구조(one-shot)는 가능한 피하기
  • 필요하다면 cron/스크립트로 환경을 주기적으로 초기화

또한, .bash_history, 로그 등 스포일러가 될 수 있는 흔적들은 제거하거나 /dev/null 로 링크하는 등의 처리가 필요합니다.

6. 마무리 & 제출

마지막으로 user / root flag 파일을 만들고, 전체 경로를 다시 한 번 직접 플레이해 봅니다. 모든 단계가 문서화되었다면, 라쿤더박스에 제출할 준비가 된 것입니다.

RTB에서는 박스 제작자의 저작권을 존중하며, 교육 목적의 비독점적 사용 권한만 가집니다. (자세한 내용은 박스 제작하기 페이지의 약관을 참고해 주세요.)