서버가 느린 게 아니었습니다: 채굴기에 기생당한 VPS를 재구축하기로 한 이유
Claude 세션이 반복해서 Killed로 종료된 원인은 메모리 부족이었습니다. 추적 끝에 발견한 채굴기와 루트킷, 그리고 청소 대신 재구축을 선택한 이유를 기록합니다.
IN SHORT
- 1. Claude 세션이 반복해서 Killed로 꺼진 원인은 서버에 숨어 있던 채굴기의 메모리 점유였습니다.
- 2. 백도어 계정과 루트킷 흔적까지 발견되어, 청소가 아니라 서버 재구축을 선택했습니다.
- 3. 새 서버는 키 기반 인증과 최소 권한 원칙으로 다시 세팅할 예정입니다.
처음엔 그냥 Claude 세션이 자꾸 끊기는 문제인 줄 알았습니다.
처음엔 그저 세션이 자꾸 끊기는 문제였다
원격으로 실행하던 작업이 어느 순간 멈추고, 터미널에는 짧게 Killed만 남았습니다. tmux가 문제인가, 브라우저가 메모리를 너무 쓰는 건가, 서버 사양이 작은 탓인가를 하나씩 의심했습니다.
결론은 훨씬 심각했습니다.
원인은 메모리를 뺏는 존재였다
서버 안에 암호화폐 채굴기가 숨어 있었고, 이 프로세스가 메모리를 크게 점유하면서 운영 중인 작업들을 밀어내고 있었습니다. RAM이 부족해지면 리눅스의 OOM(Out Of Memory) Killer가 동작합니다. 이름 그대로, 시스템 전체가 멈추지 않도록 프로세스 하나를 강제로 종료하는 기능입니다. 그 대상이 헤르메스 에이전트를 돌리던 Claude 세션이었습니다.
문제는 채굴기 하나를 종료하는 것으로 끝나지 않았다는 점입니다. 조사 과정에서 자동 재시작 서비스, 권한을 가진 백도어 계정, SSH 설정 변경, 시스템 라이브러리를 가로채는 흔적(루트킷)까지 확인했습니다. 겉으로는 파일이나 계정이 없는 것처럼 보이게 만들 수 있는 방식이라, "발견한 것만 지우면 괜찮다"고 말하기 어려운 상태였습니다.
재구축을 선택한 이유
그래서 이번에는 서버 청소가 아니라 재구축을 선택했습니다. 흔적을 숨기는 방식으로 침투한 이상, 지금 눈에 보이는 것을 다 지웠다고 해서 안전하다고 확신할 수 없었습니다. 다시 만드는 편이 오히려 확실했습니다.
이번에 배운 것들
Killed는 원인이 아니라 결과일 수 있습니다. 작업이 자꾸 죽는다고 해서 도구나 모델만 의심하면 늦습니다. 메모리 사용량, swap, 시스템 로그를 함께 봐야 합니다. 반복적인 OOM은 단순한 성능 문제가 아니라 침해 사고의 신호일 수도 있습니다.
비밀번호 로그인은 편하지만 공격 표면이 넓습니다. 새 서버에서는 SSH 비밀번호 로그인을 끄고 공개키 기반 인증만 쓸 예정입니다. root 계정을 직접 쓰는 대신 별도 운영 계정을 두고, 외부 SSH 접근도 필요한 경로로만 제한하려 합니다.
백업도 그냥 통째로 되돌리면 안 된다는 걸 알았습니다. 코드, Obsidian 기록, 크론 정의, 서비스 설정의 구조는 백업합니다. 하지만 .env, OAuth 토큰, API 키, SSH 키는 백업본에 있어도 그대로 복원하지 않습니다. 침해된 서버에 있던 비밀값은 전부 유출된 것으로 보고 새로 발급해야 합니다.
다시 시작하면서
이번 일은 "작은 VPS라서 생긴 불편" 정도로 넘길 문제가 아니었습니다. 서버는 다시 만들면 되지만, 오래 쌓인 기록과 자동화의 맥락은 그렇게 쉽게 되살릴 수 없습니다.
그래서 필요한 데이터와 작업 기록부터 먼저 밖으로 빼놨습니다. 새 서버는 최소 권한이랑 키 기반 인증부터 다시 잡으려고 합니다. 다음에 비슷한 일이 생겨도, 적어도 이번보다는 빨리 알아챌 수 있을 것 같습니다.
FAQ
Q. Claude 세션이 자꾸 Killed로 꺼지면 항상 서버 침해를 의심해야 하나요?
A. 아닙니다. 메모리 부족은 앱 설정이나 서버 사양 문제로도 흔히 발생합니다. 다만 원인 없이 반복된다면 메모리 사용량과 로그를 함께 확인해보는 것이 안전합니다.
Q. 채굴기(크립토재킹)에 감염되면 어떻게 알 수 있나요?
A. 평소보다 CPU나 메모리 사용량이 비정상적으로 높거나, 모르는 프로세스와 자동 재시작 서비스가 등록돼 있는지 확인하면 단서를 찾을 수 있습니다. 이번 경우에도 프로세스 점유율을 살펴보다가 발견하게 됐습니다.
Q. 악성 프로세스만 지우면 안전한가요?
A. 백도어 계정이나 시스템 라이브러리를 가로채는 방식(루트킷)이 함께 설치돼 있으면, 흔적을 숨긴 채 다시 살아날 수 있습니다. 이런 경우에는 청소보다 서버 재구축이 더 안전한 선택입니다.
Q. 서버를 재구축할 때 비밀번호 대신 SSH 키를 쓰는 이유는 무엇인가요?
A. 비밀번호는 무작위 대입 공격에 노출되기 쉽지만, 공개키 인증은 개인키가 없으면 접속 자체가 불가능합니다. 공격 표면을 줄이는 기본적인 방법입니다.
Q. 침해된 서버의 백업은 그대로 복원해도 되나요?
A. 코드나 설정 구조는 복원해도 괜찮지만, API 키나 인증 토큰처럼 민감한 값은 이미 유출된 것으로 보고 새로 발급하는 것이 안전합니다.