개인 블로그, 작은 쇼핑몰, 디스코드 봇, 사이드 프로젝트… 이런 걸 한 달에 몇천 원~몇만 원짜리 ‘가상 서버(VPS)’에 올려 두신 분들 많으시죠? 그런데 이번 주말, 러시아의 오래된 호스팅 회사 FirstVDS에서 꽤 무서운 일이 벌어졌어요. 고객들의 서버는 멀쩡히 잘 돌아가고 있었는데, 그 서버 디스크 안에 있던 비밀번호·SSH 키·클라우드 열쇠·AI API 키 같은 ‘비밀’들이 바깥에서 조용히 복사돼 나갔다는 거예요.
더 놀라운 건 회사 설명이에요. 공격 프로그램이 고객 서버 안에서 실행된 게 아니라, 서버를 관리하는 쪽에서 디스크를 ‘읽기 전용’으로 붙여서 내용을 복사했기 때문에 “피해 서버 안에는 공격 흔적이 없다”고 했어요. 내 서버에 아무 이상이 안 보여도 털렸을 수 있다는 뜻이죠. 오늘은 이 사건이 무엇인지, 왜 ‘흔적’이 없었는지, 그리고 서버를 빌려 쓰는 사람이 어떤 순서로 열쇠를 바꿔야 하는지까지 초보 눈높이로 차근차근 풀어볼게요.
한 줄 요약부터
| 질문 | 짧은 답 |
|---|---|
| 무슨 일이에요? | 러시아 호스팅 업체 FirstVDS가 서버 관리 소프트웨어 VMmanager 6의 취약점을 통해 공격받았고, 일부 고객 VPS 디스크의 파일이 밖에서 복사됐어요 |
| 언제요? | FirstVDS 안내 기준 10월 17일 12:27~22:34(모스크바 시각), 한국 시각으로 17일 저녁 6시 27분~18일 새벽 4시 34분에 파일이 읽혔을 수 있어요 |
| 무엇이 샜나요? | SSH 키, 각종 비밀번호 파일, 클라우드·깃허브 토큰, .env 같은 설정 파일, DB 접속 정보, 코인 지갑, OpenAI·Anthropic API 키, 브라우저 쿠키, 명령 기록, 백업 비밀번호 등 |
| 몇 곳이 당했나요? | 회사는 “인프라 일부”라고만 밝혔고, 피해 서버·고객 수는 공개하지 않았어요 |
| 구멍은 막혔나요? | 개발사 ISPsystem이 10월 18일 보안 업데이트를 냈고 19일 새벽(모스크바 시각) 추가 패치도 나왔지만, FirstVDS는 “아직 완전히 막히진 않았다”며 관리 시스템 외부 접속을 계속 닫아 두고 있어요 |
| 나와 상관있나요? | FirstVDS나 VMmanager 6를 쓰는 호스팅에 서버가 있다면 직접 해당돼요. 그렇지 않아도 “서버 안에 비밀을 쌓아 두는 습관”을 점검할 좋은 계기예요 |
먼저 용어 몇 개만 정리해요
이 사건은 용어만 알면 절반은 이해돼요. 처음 보는 단어가 있다면 아래 표를 한 번 훑고 가세요.
| 용어 | 쉽게 말하면 | 이번 사건에서는 |
|---|---|---|
| 호스팅 | 서버를 직접 사지 않고 업체 컴퓨터를 빌려 쓰는 서비스 | FirstVDS는 2002년부터 운영된, 러시아에서 손꼽히게 오래된 호스팅 회사예요 |
| 물리 서버(노드) | 데이터센터에 실제로 놓인 진짜 컴퓨터 한 대 | 한 대 안에 여러 고객의 가상 서버가 함께 돌아가요 |
| VPS(가상 서버) | 물리 서버 한 대를 쪼개 만든 나만의 작은 서버 | 고객들이 웹사이트·앱·DB를 올려 둔 곳이에요 |
| 가상화 관리 플랫폼 | 수많은 VPS를 만들고, 끄고, 옮기는 업체용 관리 프로그램 | ISPsystem의 VMmanager 6가 바로 이 역할이에요 |
| 디스크 마운트 | 저장장치를 컴퓨터에 ‘연결’해서 읽을 수 있게 하는 것 | 공격 프로그램이 고객 VPS 디스크를 읽기 전용으로 연결해 내용을 복사했어요 |
| 시크릿(비밀) | 비밀번호, 키, 토큰처럼 “이것만 있으면 들어갈 수 있는” 정보 | 공격자가 가장 노린 대상이에요 |
건물로 비유하면 단번에 이해돼요
물리 서버를 아파트 건물, VPS를 그 안의 각 호실, 가상화 관리 플랫폼을 관리사무소라고 생각해 보세요. 보통 도둑은 내 방 문을 부수고 들어와야 해요. 문이 부서지면 흔적이 남죠. 그런데 이번엔 도둑이 관리사무소의 마스터키를 손에 넣은 셈이에요. 문을 부수지 않고도 여러 방에 들어가 서랍 속 열쇠 꾸러미만 사진 찍어 나간 거예요. 방 안의 물건은 그대로라서, 주인은 들어왔다는 사실조차 눈치채기 어려웠고요.
| 건물 비유 | 실제 IT 구조 | 이번 사건의 의미 |
|---|---|---|
| 아파트 건물 | 물리 서버(노드) | 공격자가 일부 노드에서 데이터 수집 프로그램을 실행했어요 |
| 관리사무소 | 가상화 관리 플랫폼 VMmanager 6 | 여기의 취약점이 입구가 됐어요 |
| 마스터키 | 관리 플랫폼이 가진 높은 권한 | 고객 VPS 디스크를 바깥에서 붙였다 뗄 수 있는 힘 |
| 내 방(호실) | 고객의 VPS | VPS 자체는 바뀐 게 없어 평소처럼 작동 |
| 서랍 속 열쇠 꾸러미 | 디스크에 저장된 비밀번호·키·토큰 | 사진 찍듯 복사돼 공격자 서버로 전송 |
FirstVDS가 밝힌 내용, 그대로 정리하면
FirstVDS는 고객 공지와 공식 채널을 통해 상황을 알렸어요. 공지의 제목부터 “보안 사고 — 즉시 접근 정보를 바꾸세요”였어요. 회사 설명을 항목별로 옮기면 이래요.
| 항목 | FirstVDS 설명 |
|---|---|
| 무엇이 뚫렸나 | 가상화 관리 시스템 VMmanager 6의 취약점을 통해 인프라 일부에 접근 |
| 어떻게 훔쳤나 | 일부 노드에서 데이터 탈취 프로그램을 실행 → 고객 VPS 디스크를 읽기 전용으로 연결 → 파일 복사 → 공격자 서버로 전송 |
| VPS 안에는? | 프로그램이 디스크를 바꾸지 않았고 VPS 안에서 실행되지도 않아서, 서버에는 공격 흔적이 없고 정상 작동 |
| 누가 대상인가 | 영향받은 고객에게 개인 대시보드와 이메일로 서버 목록·안내를 보냈고, 알림을 못 받았다면 그 노드에서는 흔적을 찾지 못했다는 뜻 |
| 회사 조치 | 관리 시스템 외부 접속 차단, 공격자 서버 주소 차단, 개발사 임시 패치 적용, 추가 알림 발송 |
| 고객에게 당부 | 알림을 받았다면 “서버의 데이터가 복사됐다고 가정하라”, 서버에 있던 모든 비밀을 노출된 것으로 보고 교체 |
| 앞으로 | 조사를 마친 뒤 사후 분석 보고서(포스트모템)를 공개하겠다고 약속 |
미국 보안 매체 더 레코드(The Record)도 19일 이 사건을 보도하면서, 회사가 피해 고객·서버 수, 처음 침입한 방법, 영향받은 소프트웨어 버전, 공격자 정체는 아직 밝히지 않았다고 전했어요. 지금 알려진 건 “어떻게 훔쳤는지”까지이고, “처음에 어떤 구멍으로 들어왔는지”는 아직 베일에 싸여 있는 셈이에요.
한국 시간으로 다시 보는 타임라인
러시아 모스크바는 한국보다 6시간 느려요. 그래서 모스크바의 17일 낮은 한국의 17일 저녁이에요. 여러 곳의 발표를 한국 시간 기준으로 맞춰 정리하면 이래요.
| 한국 시각(KST) | 무슨 일이 | 누가 밝혔나 |
|---|---|---|
| 10월 11일~16일 | 공격자가 VMmanager 6 관리 패널을 미리 감염시킨 흔적 (해당 업체는 12일 첫 흔적 발견) | 같은 패널을 쓰는 다른 호스팅 ForestsNet |
| 10월 17일 18:27 ~ 18일 04:34 | FirstVDS 고객 서버의 파일이 읽혔을 수 있는 시간대 | FirstVDS 고객 공지 |
| 10월 17일(토) | FirstVDS가 공격을 발견하고 관리 시스템 외부 접속 차단 | FirstVDS, The Record |
| 10월 18일 | ISPsystem이 VMmanager 6 2026.05.2-6·2026.05.2-7·2026.09.1-3 버전을 연달아 배포, 변경 내역은 “보안 버그 수정” 한 줄 | ISPsystem 공식 변경 내역 |
| 10월 19일 13:20 무렵 | 추가 패치 설치. 하지만 개발사는 “아직 완전히 고쳐지지 않았다”며 패널을 계속 닫아 두라고 권고 | FirstVDS 공지 업데이트 |
| 10월 19일 20:56 | 미국 보안 매체 The Record 보도 | The Record |
여기서 중요한 포인트가 하나 있어요. 이 구멍은 FirstVDS만의 문제가 아니라 VMmanager 6를 쓰는 여러 호스팅에 걸친 일이라는 거예요. 같은 패널을 쓰는 ForestsNet은 “여러 호스팅 업체 37명이 모인 대화방에서 함께 분석했고, 그중엔 3만 대 넘는 서버를 운영하는 회사도 있다”고 밝혔어요. 또 VMmanager 6를 쓰는 대부분의 다른 호스팅 고객도 같은 조치를 하라고 권했어요. 아직 이 취약점에는 공개된 CVE 번호도 없어요.
왜 ‘흔적’이 없었을까?
보통 서버가 해킹당하면 이상한 로그인 기록, 낯선 프로그램, 바뀐 파일 같은 흔적이 남아요. 보안 프로그램도 서버 안에서 이런 걸 감시하고요. 그런데 이번 공격은 처음부터 끝까지 서버 바깥(관리하는 쪽)에서 일어났어요. 러시아 보안 매체 1275.ru도 “복사가 가상 머신 바깥에서 이뤄져, 서버 안의 일반적인 감시 도구로는 보이지 않았을 수 있다”고 짚었어요.
| 구분 | 평소의 해킹 (안으로 침입) | 이번 사건 (바깥에서 복사) |
|---|---|---|
| 들어오는 길 | 내 서버의 약한 비밀번호, 오래된 프로그램 | 업체의 관리 플랫폼 취약점 |
| 프로그램이 도는 곳 | 내 VPS 안 | VPS를 품고 있는 물리 서버 |
| 디스크 상태 | 파일이 바뀌거나 악성 파일이 생김 | 읽기 전용으로 읽기만 함 |
| 내 로그인 기록 | 낯선 IP 접속이 남는 경우가 많음 | 내 서버에 로그인 자체를 안 함 |
| 내 보안 프로그램 | 탐지할 기회가 있음 | 볼 수 없는 위치에서 일어남 |
| 결론 | 흔적을 찾아 피해를 확인 | 업체 알림을 믿고 ‘털렸다고 가정’하고 움직여야 함 |
공격자가 디스크에서 찾던 것들
FirstVDS 공지에는 공격자가 노린 파일 목록이 꽤 자세히 적혀 있어요. 한눈에 보면 “돈이 되거나, 다른 곳의 문을 여는 열쇠”만 골라 간 걸 알 수 있어요. 회사는 이 목록도 정확하지 않을 수 있으니 서버에 있던 모든 것이 유출됐다고 보라고 했어요.
| 분류 | FirstVDS 공지에 나온 예시 | 털리면 생기는 일 |
|---|---|---|
| 서버 접속 열쇠 | SSH 키, authorized_keys, 비밀번호 파일(shadow, .pgpass, .netrc, .htpasswd, .git-credentials), KeePass·GPG |
다른 서버나 저장소에 내 이름으로 들어갈 수 있어요 |
| 클라우드·개발 도구 | AWS·Google Cloud·Azure·OpenStack, kubeconfig, Docker, Terraform, GitHub·GitLab·npm 토큰 | 클라우드 요금 폭탄, 코드 변조, 배포 파이프라인 오염 |
| 앱·DB 설정 | .env, docker-compose.yml, application.yml, web.config, PostgreSQL·MySQL·MongoDB·Redis 접속 문자열 |
회원 DB를 통째로 빼 가는 2차 유출 |
| 돈과 직결 | 코인 지갑, 시드 문구, 검증자 키, 거래소 API 키 | 자산을 바로 옮겨 갈 수 있어요 |
| AI 서비스 | OpenAI·Anthropic API 키 | 남이 내 키로 AI를 써서 요금이 내 카드로 |
| 브라우저·기록 | 저장된 비밀번호와 쿠키, bash·zsh·mysql·psql·redis·python 명령 기록 | 기록 속에 남은 비밀번호 한 줄까지 노출 |
| 백업 | Restic·Borg 백업 비밀번호 | 백업까지 열어 볼 수 있어 과거 데이터도 위험 |
ForestsNet은 또 다른 피해도 알렸어요. 공격자가 관리 패널 데이터베이스 자체를 손에 넣었다는 거예요.
| 패널 DB에서 샌 것 (ForestsNet 발표) | 의미 | 할 일 |
|---|---|---|
| 서버 목록과 IP 주소 | 어떤 서버가 어디 있는지 지도가 생김 | 외부 접속 포트·방화벽 점검 |
| 패널 계정 이메일 주소 | 업체를 사칭한 피싱 메일이 올 수 있음 | “긴급 조치” 메일 속 링크 대신 업체 사이트에 직접 접속 |
| 패널에서 지정한 root 비밀번호 | 서버 주문·재설치·비밀번호 변경 때 패널로 정한 비밀번호 | 그 뒤로 안 바꿨다면 지금 바로 변경 |
| VNC 콘솔 비밀번호 | 웹 화면으로 서버를 조작하는 콘솔의 비밀번호 | 콘솔 비밀번호도 재설정 |
‘구멍을 막았으니 끝’이 아닌 이유
이번 사건에서 가장 많이 하는 착각이 이거예요. “업체가 패치했다니 이제 괜찮겠지?” 하지만 패치는 앞으로 들어올 길을 막을 뿐이에요. 이미 복사돼 나간 열쇠는 그대로 공격자 손에 있어요. 1275.ru의 표현처럼 “훔친 키와 토큰은 취약점이 닫힌 뒤에도 계속 통한다”는 게 핵심이에요.
| 조치 | 막아 주는 것 | 못 막는 것 |
|---|---|---|
| 업체의 패치·패널 차단 | 같은 방법으로 다시 털리는 것 | 이미 복사된 비밀번호·키·토큰 사용 |
| 새 키 만들기만 하기 | 앞으로 쓸 키를 새로 갖추는 것 | 옛 키가 살아 있으면 공격자는 옛 키로 계속 접속 |
| 옛 키 폐기(revoke) + 새 키 발급 | 훔친 키를 쓸모없게 만드는 것 | 이미 벌어진 일(이미 만든 계정·백도어)은 따로 찾아야 함 |
| 로그 점검 | 이미 침입했는지 확인 | 기록이 남지 않는 행동 |
그래서 FirstVDS도 “새 키를 만들기만 하지 말고, 옛 키를 반드시 폐기하라”고 따로 강조했어요. 클라우드 콘솔, 깃허브·깃랩, 결제 서비스에서 옛 키를 ‘삭제’ 또는 ‘비활성화’해야 진짜 끝나요.
알림을 받았다면: 오늘 밤 할 일 순서
FirstVDS가 안내한 순서를 초보도 따라 하기 쉽게 다시 묶었어요. 핵심은 “돈 → 다른 곳의 문을 여는 열쇠 → 서버 자체 → 확인” 순서예요.
| 순서 | 할 일 | 왜 이 순서? |
|---|---|---|
| ① 돈부터 | 서버에 코인 지갑·시드 문구·거래소 API 키가 있었다면, 다른 깨끗한 기기에서 만든 새 지갑으로 자산을 옮기고 거래소 키 폐기 | 가장 빨리, 되돌릴 수 없게 피해가 나는 곳 |
| ② 클라우드·저장소 토큰 | AWS·구글 클라우드·애저, GitHub·GitLab·npm, CI/CD 토큰, AI API 키를 폐기하고 재발급 | 한 번에 여러 시스템으로 번질 수 있는 ‘만능 열쇠’ |
| ③ 서버 접속 정보 | root와 모든 사용자 비밀번호 변경, SSH 키 새로 발급, authorized_keys에 낯선 키가 없는지 확인 |
내 서버를 다시 내 것으로 |
| ④ DB·서비스 비밀번호 | 설정 파일에 적힌 DB·메일·결제 연동 비밀번호 변경. 명령 기록(history)에 남은 비밀번호도 잊지 말기 | 회원 정보 같은 2차 유출을 막기 |
| ⑤ 백업 | Restic·Borg 등 백업 비밀번호 변경, 백업 자체가 손상되지 않았는지 확인 | 과거 데이터까지 열리는 걸 막기 |
| ⑥ 기록 확인 | 클라우드·저장소·거래소 로그에서 17일 이후 낯선 접속이 있었는지 확인 | 이미 쓰였는지 알아야 다음 대응을 정해요 |
| ⑦ 법적 의무 확인 | 서버에 고객 개인정보가 있었다면 신고·통지 의무가 있는지 전문가와 확인 | FirstVDS는 러시아 규정상 24시간 내 당국 통보 가능성을 안내했어요 |
한국에서 서비스를 운영 중이고 서버에 회원 개인정보가 있었다면, 한국 개인정보 보호법의 유출 통지·신고 규정(유출을 알게 된 때부터 72시간 이내)도 함께 확인해 보셔야 해요. 판단이 어렵다면 개인정보침해 신고센터(118)에 먼저 상담해 볼 수 있어요.
내 서버, 직접 들여다보는 기본 명령어
리눅스 VPS라면 아래 명령으로 “낯선 손님”이 남긴 흔적을 찾아볼 수 있어요. 다만 이번 공격은 서버 안에 흔적을 남기지 않았다고 했으니, 이 점검은 “공격자가 훔친 열쇠로 다시 들어왔는지”를 보는 용도라는 점을 기억하세요.
# 1) 허락한 SSH 키 목록 – 모르는 키가 있으면 삭제
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# 2) 최근 로그인 기록 – 낯선 IP·시간 확인
last -a | head -n 30
# 3) 새로 생긴 사용자 계정 확인
cut -d: -f1 /etc/passwd
# 4) 예약 작업(크론) 확인
crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily
# 5) 실행 중인 서비스 확인
systemctl list-units --type=service --state=running| 명령 | 보는 것 | 이상 신호 |
|---|---|---|
cat ~/.ssh/authorized_keys |
비밀번호 없이 들어올 수 있게 허락한 키 목록 | 내가 넣은 적 없는 키 한 줄 |
last -a |
누가, 언제, 어디서 로그인했는지 | 10월 17일 이후 모르는 IP에서의 접속 |
cut -d: -f1 /etc/passwd |
서버의 사용자 계정 이름들 | 만든 기억이 없는 새 계정 |
crontab -l |
정해진 시간마다 자동 실행되는 작업 | 낯선 주소로 무언가를 내려받는 작업 |
systemctl list-units ... |
지금 돌아가는 서비스 목록 | 이름이 이상하거나 설명이 없는 서비스 |
하나라도 이상한 게 보이고 확신이 서지 않는다면, 혼자 지우기보다 필요한 데이터만 백업한 뒤 서버를 새로 설치하는 편이 안전해요. ForestsNet도 “확신이 없으면 지원팀과 함께 확인하고 필요하면 재설치를 돕겠다”고 안내했어요.
알림을 못 받았거나, 다른 업체를 쓴다면
FirstVDS는 알림을 받지 못한 고객은 해당 노드에서 흔적이 발견되지 않은 것이라고 했어요. 그래도 ForestsNet처럼 “패널 DB가 샜다”고 밝힌 곳도 있으니, 내 상황에 맞게 아래처럼 판단해 보세요.
| 내 상황 | 위험도 | 추천 행동 |
|---|---|---|
| FirstVDS 고객 + 알림 받음 | 매우 높음 | 위 ①~⑦ 전부, 오늘 바로 |
| FirstVDS 고객 + 알림 없음 | 중간 | 패널로 정한 root 비밀번호 변경, SSH 키 로그인 전환, 업체 추가 공지 지켜보기 |
| 다른 업체지만 VMmanager 6 기반 호스팅 | 중간~높음 | 업체 공지 확인, ForestsNet 권고처럼 root 비밀번호·서버 속 비밀 교체 |
| VMmanager 6와 무관한 호스팅·클라우드 | 이번 사건과는 직접 관련 없음 | 이번 기회에 ‘서버 속 비밀 정리 습관’만 점검 |
| 우리 업체가 어떤 관리 플랫폼을 쓰는지 모름 | 모름 | 고객센터에 “VMmanager 6를 쓰는지, 이번 사건 영향이 있는지” 직접 문의 |
10월 19일 밤 기준으로, 이번 보도에서 피해가 언급된 곳은 FirstVDS를 비롯해 VMmanager 6를 쓰는 러시아권 호스팅들이에요. 국내 업체 피해는 아직 보도되지 않았어요. 하지만 이 사건이 주는 교훈은 국내 클라우드를 쓰는 분들에게도 똑같이 해당돼요.
앞으로를 위한 습관: ‘서버에 열쇠를 쌓아 두지 않기’
이번 사건의 진짜 교훈은 “서버를 빌려 쓰는 순간, 업체의 관리 영역은 내가 지킬 수 없다”는 거예요. 그렇다면 내가 할 수 있는 건 하나, 털려도 피해가 작게 만드는 거예요.
| 습관 | 왜 좋은가 | 이번 같은 사건에서 |
|---|---|---|
| 비밀번호 대신 SSH 키 로그인, 비밀번호 로그인 끄기 | 비밀번호를 맞히거나 재사용하는 공격을 차단 | 패널로 정한 root 비밀번호가 새도 바로 들어오긴 어려워요 |
| API 키에 최소 권한·사용 한도 걸기 | 키 하나가 할 수 있는 일을 좁혀요 | AI 키가 새도 요금 폭탄의 크기를 줄여요 |
| 클라우드 콘솔·깃허브에 2단계 인증 | 비밀번호만으로는 로그인 불가 | 토큰 공격까지 막진 못하지만 계정 탈취는 어려워져요 |
| 코인 지갑·시드 문구는 서버에 두지 않기 | 서버는 24시간 인터넷에 노출된 곳 | 이번 공격자가 가장 먼저 노린 항목이에요 |
| 명령 기록에 비밀번호 남기지 않기 | mysql -p비밀번호처럼 치면 기록에 남아요 |
공격자가 명령 기록 파일까지 가져갔어요 |
.env에 꼭 필요한 값만, 안 쓰는 키는 바로 삭제 |
디스크에 적힌 비밀의 수를 줄여요 | 털릴 ‘재료’ 자체가 적어져요 |
| 백업은 다른 곳에, 복원도 시험 | 서버와 백업이 같이 털리는 걸 막아요 | 백업 비밀번호까지 노린 공격이었어요 |
| VPS 안에서 디스크 암호화 고려 | 디스크를 밖에서 읽어도 내용을 바로 알아보기 어렵게 | 다만 업체 쪽 권한이 아주 높으면 완벽한 방패는 아니에요 |
서버 종류별로, 누가 무엇을 지키나
| 서비스 종류 | 업체가 지키는 것 | 내가 지키는 것 | 이번 사건 같은 ‘관리층’ 공격 |
|---|---|---|---|
| 공유 웹호스팅 | 서버·운영체제·관리 패널 대부분 | 내 사이트 계정·플러그인 | 업체가 털리면 사실상 나도 영향 |
| VPS | 물리 서버·가상화 관리 플랫폼 | 운영체제 안쪽 전부(계정·프로그램·비밀) | 이번 사건 유형: 내 쪽은 멀쩡해도 털릴 수 있음 |
| 대형 퍼블릭 클라우드 | 데이터센터·가상화 계층 | 계정·권한·키·데이터 설정 | 관리층 공격 위험은 같지만, 보안 공지·감사 체계가 상대적으로 촘촘한 편 |
| 내 집 서버(홈랩) | 없음(전부 내 책임) | 하드웨어부터 전부 | 남의 관리층은 없지만 모든 관리가 내 몫 |
호스팅 고를 때 물어볼 것
| 체크 항목 | 왜 중요한가 |
|---|---|
| 보안 공지 채널(이메일·상태 페이지·SNS)이 있나 | 이번처럼 업체 알림이 유일한 단서일 수 있어요 |
| 관리 패널·콘솔에 2단계 인증을 켤 수 있나 | 패널 계정 탈취를 어렵게 해요 |
| 어떤 가상화 관리 플랫폼을 쓰나, 업데이트는 얼마나 빠른가 | 관리층 취약점 대응 속도가 곧 내 안전이에요 |
| 사고 때 사후 분석 보고서를 공개해 왔나 | 투명한 업체일수록 대응 계획을 세우기 쉬워요 |
| 백업이 서버와 분리돼 있나 | 서버와 백업이 같이 털리는 걸 막아요 |
자주 하는 오해
| 오해 | 실제 |
|---|---|
| “내 서버 로그에 아무것도 없으니 안전하다” | 이번 공격은 서버 바깥에서 디스크를 읽어 서버 안에 흔적이 없었어요. 업체 알림이 더 중요한 단서예요 |
| “업체가 패치했으니 끝났다” | 패치는 새 침입을 막을 뿐, 이미 복사된 키는 그대로 쓸 수 있어요 |
| “새 키를 만들었으니 됐다” | 옛 키를 폐기해야 공격자 손의 키가 무용지물이 돼요 |
| “러시아 업체 얘기라 나랑은 상관없다” | VMmanager 6를 쓰는 호스팅이면 해당될 수 있고, ‘서버 속 비밀’ 문제는 어느 나라 서버든 같아요 |
| “비밀번호만 바꾸면 된다” | SSH 키, 클라우드·깃허브 토큰, AI API 키, 백업 비밀번호까지 열쇠의 종류가 훨씬 많아요 |
정리하며
이번 FirstVDS 사건은 “서버가 멀쩡하다 = 안전하다”는 공식이 깨질 수 있다는 걸 보여 줬어요. 공격자는 내 방 문을 부수지 않고 관리사무소의 마스터키로 들어와, 서랍 속 열쇠 꾸러미만 조용히 복사해 갔어요. 몇 곳이 피해를 봤는지, 처음에 어떤 구멍으로 들어왔는지는 아직 밝혀지지 않았고, 개발사도 아직 완전한 수정판을 내놓지 못했어요. 추가 발표를 지켜봐야 해요.
그 전에 우리가 할 수 있는 건 분명해요. 해당 업체를 쓴다면 오늘 밤 돈 → 클라우드·저장소 토큰 → 서버 접속 정보 → DB·백업 → 기록 확인 순서로 열쇠를 바꾸고, 옛 키는 꼭 폐기하기. 해당되지 않는다면 이번 기회에 내 서버에 쌓여 있는 열쇠가 몇 개인지 한 번 세어 보기. 그것만으로도 다음 사고가 왔을 때 피해를 훨씬 작게 만들 수 있어요.