“그날은 아무 일도 없을 줄 알았죠”에서 시작되는 이야기
프리서버를 운영하다 보면, 가장 무서운 순간은 서버가 “느려지는 그 찰나”예요. 평소엔 접속자도 적당하고, 업데이트도 순조롭고, 커뮤니티 분위기도 괜찮았는데… 갑자기 핑이 튀고 접속이 끊기고, 관리자 페이지가 먹통이 되면 머릿속이 하얘집니다. 특히 디도스(DDoS)나 해킹은 “언젠가 한 번은 온다”는 마음으로 준비해야 하는 이슈예요. 실제로 Akamai, Cloudflare 같은 보안 기업들이 매년 내놓는 위협 보고서를 보면 애플리케이션 공격과 대규모 트래픽 공격이 꾸준히 늘고 있고, 공격 단가가 낮아져서(=누구나 마음만 먹으면) 작은 서버도 표적이 되는 흐름이 계속되고 있거든요.
이 글은 “겁주기”가 아니라, 프리서버 운영자가 현실적으로 당장 적용할 수 있는 보안 체크리스트를 한 번에 정리해두는 목적이에요. 서버 지식이 아주 깊지 않아도 따라 할 수 있게, 단계별로 “왜 필요한지 / 뭘 해야 하는지 / 어디서 실수하는지”를 함께 담아볼게요.
1) 위협 모델부터 잡아야 방어가 쉬워져요
보안은 ‘좋은 툴’보다 ‘좋은 가정’에서 시작합니다. 즉, “누가 왜 나를 공격할까?”를 먼저 정리해야 불필요한 비용과 삽질을 줄일 수 있어요. 프리서버는 상용 서비스와 달리 운영 환경이 개인/소규모인 경우가 많아서, 공격자의 동기도 더 다양합니다.
프리서버에서 자주 보는 공격 시나리오
- 디도스: 경쟁 서버 운영자/악성 유저가 접속 불능을 유도 (UDP 플러드, SYN 플러드, L7 HTTP 플러드 등)
- 계정 탈취: 관리자 계정/SSH 계정/DB 계정의 약한 비밀번호를 노림
- 취약점 공격: 웹 패널, 플러그인, 오래된 CMS/프레임워크, 게임 서버 모듈의 알려진 취약점 악용
- 데이터 유출: 유저 DB 덤프, 서버 설정 파일, 결제/후원 기록 등 민감 정보 탈취
- 권한 상승 및 랜섬: 서버 장악 후 백도어 심기, 파일 암호화, 디스코드/커뮤니티로 협박
운영자가 먼저 정리하면 좋은 질문
- 서버에서 “절대 유출되면 안 되는 것”은 무엇인가요? (계정 DB, 관리자 키, 결제 로그 등)
- 다운타임이 30분 생기면 커뮤니티에 어떤 타격이 있나요?
- 내 서버는 어디가 외부에 노출되어 있나요? (SSH, RDP, DB 포트, 웹 패널, 게임 포트)
- 업데이트가 멈춘 구성요소가 있나요? (구형 OS, 구형 PHP/Java, 오래된 패널)
이 질문에 답이 생기면, 이후 체크리스트가 “내 상황에 맞는 우선순위”로 정리됩니다.
2) 기본기 하드닝: ‘열려있는 문’부터 닫는 단계
디도스를 막는 것도 중요하지만, 해킹의 상당수는 “복잡한 제로데이”가 아니라 “기본 설정 미흡”에서 시작돼요. 실제 현장에서도 관리자들이 제일 많이 후회하는 포인트가 바로 이 구간입니다.
서버 계정/접속 보안 체크
- SSH 비밀번호 로그인 금지 → 키 기반 로그인으로 전환
- 가능하면 22번 포트 변경(보안의 전부는 아니지만 스캐닝 소음을 줄이는 효과)
- 관리자 계정 루트 직접 로그인 비활성화, 일반 계정 + sudo 사용
- 2FA 적용 가능한 곳(패널, 깃, 클라우드 콘솔, 도메인 관리)에 전부 적용
- 접속 허용 IP 제한(고정 IP가 있다면 강력 추천)
방화벽/포트 노출 최소화
프리서버는 “일단 열어두고 문제 생기면 닫자”가 아니라, “필요한 것만 열자”가 정답이에요. 특히 DB 포트(예: 3306), 캐시 포트(예: 6379), 관리 패널 포트가 외부에 열려 있으면 사고가 빨라집니다.
- 외부 공개 포트 목록을 먼저 작성하고, 목적이 불명확한 포트는 즉시 차단
- DB/Redis 등은 로컬 바인딩(127.0.0.1) 또는 내부망 전용으로만 접근
- 게임 서버 포트는 필요한 범위만 열고, 지역/ASN 차단이 가능하면 적용
- 서버 내 방화벽(UFW/iptables/nftables) + 클라우드 보안그룹을 이중으로 운영
패치와 버전 관리: “업데이트 미루기”가 가장 비싼 선택
보안 연구/산업계에서 꾸준히 강조하는 사실 중 하나가 “알려진 취약점(known vulnerability)을 방치하는 순간, 공격 난이도는 급락한다”는 점이에요. 공격자는 새로운 방법을 굳이 만들 필요가 없거든요.
- OS 보안 업데이트 자동 적용(최소 보안 패치만이라도)
- 웹 패널/플러그인/CMS는 사용하지 않는 기능 제거(공격 표면 감소)
- 구형 런타임(Java, PHP, Node 등) 사용 시 EOL 여부 확인 후 교체 계획 수립
- 서드파티 모듈은 출처와 유지보수 상태 확인(포크/미검증 파일 주의)
3) 디도스 대비: “버티기”가 아니라 “우회시키기” 전략
디도스는 서버를 더 좋은 걸로 바꾼다고 해결되는 문제가 아닐 때가 많아요. 대역폭이든 PPS(Packet Per Second)든 공격 트래픽이 압도하면 단일 서버는 버티기 어렵습니다. 그래서 핵심은 “공격을 내 서버까지 도달하기 전에 흡수/차단/분산”하는 구조를 만드는 거예요.
디도스 유형별로 대응 포인트가 달라요
- L3/L4(네트워크/전송 계층) 공격: UDP 플러드, SYN 플러드 등 → 대역폭/장비 레벨 방어 필요
- L7(애플리케이션) 공격: HTTP GET/POST 플러드, 로그인/검색 엔드포인트 집중 타격 → WAF/레이트 리밋/캐시 전략 중요
현실적인 방어 조합(소규모 운영 기준)
- CDN/WAF 사용: 웹 사이트/패널이 있다면 Cloudflare 같은 서비스로 L7 공격을 먼저 흡수
- 레이트 리밋: 로그인, 회원가입, 비밀번호 찾기 같은 엔드포인트에 요청 제한 적용
- 캐싱: 공지/다운로드/정적 페이지는 캐싱으로 원서버 부하 감소
- 프록시/게이트웨이 분리: 게임 서버와 웹/패널 서버를 분리해 “한쪽이 맞아도 전체가 죽지 않게”
- 업스트림(호스팅/IDC) 디도스 방어 옵션 확인: “기본 제공”인지 “유료 옵션”인지 반드시 체크
사례로 보는 ‘작게 시작해서 크게 막기’
예를 들어, 어느 프리서버는 커뮤니티 공지 페이지와 런처 다운로드가 같은 서버에서 돌아가다가 L7 공격으로 웹이 터지면서 런처 배포까지 막혀 유저들이 이탈했어요. 이후 공지/다운로드를 CDN으로 옮기고, 런처 파일은 별도 스토리지로 분리했더니 공격을 받아도 “게임 접속 경로”와 “필수 파일 배포”가 동시에 죽는 상황이 크게 줄었습니다. 디도스는 ‘완전 차단’이 아니라 ‘피해 범위 축소’가 생존 전략인 경우가 많습니다.
4) 해킹 방지의 핵심: 인증·권한·비밀관리 3종 세트
해킹 사고는 대개 “한 번 뚫리면 연쇄적으로 번진다”는 특징이 있어요. 그래서 처음부터 권한을 쪼개고, 비밀을 안전하게 보관하고, 인증을 강하게 하는 게 중요합니다.
권한 분리(Least Privilege) 체크리스트
- 게임 서버 프로세스는 루트 권한으로 실행하지 않기
- 웹 서버 계정(www-data 등)의 파일 권한 최소화
- DB 계정은 서비스별로 분리하고 권한도 필요한 테이블/권한만 부여
- 운영자(관리자)도 역할을 나눠서 “모든 권한을 한 계정에 몰아주지 않기”
비밀번호와 키 관리: “어딘가에 적어둔 그 파일”이 가장 위험해요
- .env / config 파일이 외부로 노출되지 않도록 웹 루트 밖으로 분리
- 깃 저장소에 비밀키/DB 비번 커밋 금지(실수로 올렸다면 즉시 키 교체)
- API 키/토큰은 주기적으로 교체하고, 사용 범위를 제한(권한/도메인/IP 제한)
- 관리자 패널은 기본 경로(/admin 등) 변경 + 접근 IP 제한 + 2FA 조합
로그인 공격(브루트포스/크리덴셜 스터핑) 방어
프리서버는 유저가 많아질수록 로그인 시도가 폭증하고, 그 틈에 자동화 공격이 끼어들기 쉬워요. 보안 업체들이 자주 언급하는 통계 중 하나가 “유출된 계정 조합(이메일/비번)을 재사용하는 공격이 여전히 매우 높은 비중”이라는 점인데, 이건 소규모 서비스일수록 더 치명적입니다.
- 로그인 실패 횟수 제한 + 일정 시간 잠금
- 관리자 로그인에는 CAPTCHA 또는 추가 인증
- 비밀번호 정책 강화(길이, 복잡도) + “유출 비밀번호” 차단(가능하면)
- 로그인 시도/성공 로그를 남기고, 평소와 다른 국가/ASN 접속 탐지
5) 모니터링과 로그: “당하고 나서 아는” 상태를 끝내기
진짜 실전에서 큰 차이를 만드는 건 모니터링이에요. 공격을 5분 안에 알아차리느냐, 다음날 유저 제보로 알게 되느냐가 피해 규모를 갈라요. 전문가들이 자주 말하는 원칙도 비슷합니다. “보안은 예방 + 탐지 + 대응의 합”이고, 탐지(Detection)가 없으면 대응은 늦어질 수밖에 없어요.
필수로 챙길 지표와 경보
- CPU/RAM/디스크 I/O 급증 알림
- 네트워크 트래픽(ingress/egress) 급증 알림
- 프로세스 다운/재시작 감지(게임 서버, 웹 서버, DB)
- 로그인 실패 급증, 403/404 폭증, 특정 URL 요청 폭증
- 서버 파일 변경 감지(중요 바이너리/설정 파일)
로그 보관의 기본 원칙
- 접근 로그/에러 로그/인증 로그를 분리 저장
- 로그는 “서버 밖”에도 보관(원서버가 털리면 로그도 지워질 수 있음)
- 보관 기간을 정하고(예: 30~90일), 용량 관리(로테이션) 적용
간단한 사고 징후 예시
예를 들어 평소엔 관리자 패널 로그인 실패가 하루 10건 미만인데 갑자기 1시간에 2,000건이 찍히면, 그 자체로 공격 신호예요. 또 웹 에러 로그에 평소 보지 못한 경로(예: /wp-admin, /phpmyadmin 등)가 반복되면 자동 스캐너가 서버를 훑고 있다는 뜻일 가능성이 큽니다. 이런 건 “바로 차단 룰 추가 + 접근 제한 + 패치 확인”으로 이어져야 합니다.
6) 백업·복구·대응 플랜: 보안의 마지막 퍼즐
디도스와 해킹은 “0%로 만들기”가 현실적으로 어렵습니다. 그래서 마지막 승부는 복구력에서 나요. 침해 사고 대응(IR, Incident Response) 관점에서도, 잘 설계된 백업과 복구 절차가 있으면 공격자가 노리는 ‘운영 마비’ 효과를 크게 줄일 수 있어요.
백업 체크리스트(3-2-1 원칙을 응용)
- 최소 3개 사본: 원본 + 백업 + 추가 백업
- 서로 다른 2개 매체: 예) 서버 디스크 + 외부 스토리지
- 1개는 오프사이트: 다른 리전/다른 계정/다른 제공자에 보관
특히 프리서버는 “DB 백업만” 해두고 끝내는 경우가 많은데, 실제 복구 때는 설정 파일, 인증서, 런처 배포 파일, 서버 바이너리, 플러그인 버전까지 맞아야 정상 복원이 빨라요. 백업 범위를 미리 정의해두는 게 중요합니다.
복구 리허설이 없으면 백업은 반쪽짜리예요
- 월 1회라도 복구 테스트(스테이징 서버에 복원해보기)
- 복구 절차 문서화: 누가/어디서/어떤 순서로 복원하는지
- “깨끗한 시점”을 선택할 수 있도록 백업 버전 여러 개 보관
사고 대응 플로우(간단 템플릿)
- 1단계: 증상 확인(트래픽, 오류, 접속 불가 범위)
- 2단계: 확산 차단(방화벽 룰, 패널 차단, 의심 계정 잠금)
- 3단계: 증거 보존(로그 백업, 스냅샷, 시간대 기록)
- 4단계: 원인 제거(취약점 패치, 키/비밀번호 전면 교체)
- 5단계: 복구(백업 복원, 서비스 검증)
- 6단계: 사후 조치(재발 방지 체크리스트 업데이트, 공지)
여기서 “증거 보존”을 빼먹으면, 다음에 똑같이 당할 확률이 확 올라가요. 공격 경로를 모르니까요.
오늘 할 수 있는 것부터 체크해두면, 그 다음이 쉬워져요
프리서버 보안은 거창한 장비나 비싼 솔루션 하나로 끝나지 않아요. 대신 “기본기 하드닝 → 디도스 우회/흡수 구조 → 인증·권한·비밀관리 → 모니터링 → 백업/복구”를 차근차근 쌓아가는 방식이 가장 안정적입니다. 특히 소규모 운영일수록 한 번의 사고가 커뮤니티 신뢰와 운영 의지를 동시에 흔들 수 있어서, 미리 체크리스트를 만들어두는 게 정말 큰 힘이 돼요.
지금 당장 딱 30분만 투자한다면, (1) 외부 노출 포트 점검, (2) SSH 키 로그인 전환, (3) 관리자 2FA 적용, (4) 로그인 실패/트래픽 급증 알림 설정, (5) 오프사이트 백업 한 개 추가… 이 다섯 가지만 해도 방어력이 눈에 띄게 올라갑니다. 완벽을 목표로 하기보다, “오늘보다 내일 더 단단한 운영”을 만드는 쪽으로 같이 가보자고요.