[TroubleShooting] 데이터 이관의 기쁨도 잠시, 내 VM이 채굴기가 된 사건 (PostgreSQL & MinIO)

지난 주말, 드디어 블로그 서버 배포를 완료했습니다.

하지만 진정한 운영의 시작은 이제부터죠. 로컬 개발 환경과 실제 서버 DB를 분리하고 데이터를 동기화하는 과정, 그리고 그 틈을 타 발생한 아찔한 보안 사고 이야기를 공유합니다.

1. 데이터 이관: 로컬에서 서버로 생명 불어넣기

로컬에서 작업하던 소중한 데이터를 실제 서버로 옮기는 작업을 진행했습니다. Docker 환경에서 PostgreSQL을 사용 중이라 로컬 머신(Mac)에도 관련 도구 설치가 필요했습니다.

PostgreSQL 데이터 덤프 및 복구

  1. 도구 설치: brew install postgresql@16

  2. 덤프 파일 생성

    1. bash pg_dump -h localhost -U [유저이름] -d [db] -a --column-inserts > local_data.sql

  3. 서버로 데이터 복구: VM의 DB 포트를 임시로 개방한 뒤 아래 명령어를 실행했습니다.

    1. psql -h [호스트IP] -p [포트번호] -U [유저이름] -d [db] -f local_data.sql

MinIO 오브젝트 스토리지 이관

이미지 파일들이 담긴 MinIO 데이터도 mc(MinIO Client)를 활용해 미러링했습니다.

  1. 클라이언트 설치: brew install minio-mc

  2. 별칭(Alias) 설정: 원본과 대상 서버를 각각 등록합니다. (포트 9000 개방 필요)

    mc alias set source http://<원본IP>:9000 <ACCESS_KEY> <SECRET_KEY>
    mc alias set target http://<대상IP>:9000 <ACCESS_KEY> <SECRET_KEY>
    
  3. 데이터 미러링: mc mirror source target 명령어로 깔끔하게 이관을 마쳤습니다.

모든 데이터가 정상적으로 뜨는 것을 확인하고 가벼운 마음으로 잠자리에 들었습니다. 하지만 이것이 비극의 시작일 줄은 몰랐습니다.


2. 문제 발생: 출근길에 마주한 서버의 비명

다음 날 아침, 설레는 마음으로 블로그에 접속했으나 포스트 리스트가 뜨지 않고 로그인도 되지 않았습니다. 급히 서버에 원격 접속해 상태를 확인하니 처참했습니다.

스크린샷 2026-04-06 오전 10.05.27
  • 현상: CPU 점유율 100%, RAM 사용량 한계치 도달.

  • 범인: /tmp/mysql이라는 생소한 프로세스가 리소스를 독점 중.

저는 PostgreSQL을 사용하는데 mysql이라는 프로세스가 떠 있는 것이 의아했습니다. 확인 결과, 이는 실제 MySQL이 아니라 악성 봇이 침투해 심어놓은 프로그램이었습니다.

3. 원인 분석: "귀찮음이 부른 보안 구멍"

원인은 명확했습니다. 데이터 이관을 위해 DB와 MinIO의 기본 포트를 모든 IP(0.0.0.0/0)에 대해 열어둔 것이 화근이었습니다.

  1. 전 세계를 떠도는 스캔 봇이 오픈된 포트를 발견.

  2. 취약점을 통해 침투 후 악성 프로그램을 실행.

  3. 프로그램 이름을 /tmp/mysql로 위장하여 관리자의 눈을 속이려 함.

  4. 심지어 PostgreSQL의 비밀번호까지 임의로 변경해버리는 치밀함을 보임.

4. 해결 및 방어 전략 (Solution)

사태 파악 즉시 응급 처치를 진행했습니다.

  • 포트 차단: 즉시 방화벽 설정을 통해 외부 접근을 차단했습니다.

  • 프로세스 제거: 악성 프로그램을 강제 종료하고 관련 파일을 삭제하자 CPU와 RAM 수치가 즉시 정상화되었습니다.

  • 비밀번호 재설정: 점령당했던 PostgreSQL 비밀번호를 다시 안전하게 변경했습니다.

  • 화이트리스트 도입: "귀찮다"는 이유로 미뤄왔던 특정 IP 허용(Whitelist) 설정을 적용했습니다. 이제 제 작업 컴퓨터 외에는 누구도 해당 포트에 접근할 수 없습니다.

    • 지금은 불필요했기 때문에 해당 포트는 닫아놨습니다.

5. 회고: 보안에는 '나중에'가 없다

개발자로서 정말 창피한 경험이었지만, 동시에 뼈저린 교훈을 얻었습니다.

  • 불필요한 포트는 즉시 닫기: 작업이 끝나면 1분이라도 열어두지 말고 닫아야 합니다.

  • 화이트리스트는 선택이 아닌 필수: 공용 IP 전체 개방은 "나를 해킹해달라"고 광고하는 것과 같습니다.

  • 기본 포트 변경 및 복잡한 비밀번호: 봇들은 기본 포트를 우선적으로 노립니다.

실무 업무에 바쁘다는 핑계로 가장 기본인 '보안'을 간과했던 저를 반성합니다. 앞으로는 편리함보다 안전을 우선시하는 '성장하는 개발자'가 되도록 인프라 관리에 더욱 신경 쓰겠습니다.