랜섬웨어 복구 실패의 공통점: 백업이 없어서가 아니라 어느 백업이 깨끗한지 몰라서
백업 30일치를 갖고 있었는데 복원하고 이틀 뒤에 또 잠겼다
랜섬웨어 피해를 입은 기업들의 이야기를 들어보면 공통적인 패턴이 하나 있습니다. 백업이 없어서 당한 게 아니라는 것입니다. 백업은 있었는데, 복원을 했는데, 며칠 뒤에 또 암호화됐다는 이야기가 생각보다 많습니다.
왜 이런 일이 생기는 걸까요?
랜섬웨어는 한순간의 사고가 아니라 몇 주짜리 작전입니다
화면이 잠기고 몸값 요구 화면이 뜨는 순간, 대부분의 사람은 그게 공격의 시작이라고 느낍니다. 그런데 실제로는 그 반대입니다. 화면이 잠기는 건 공격의 마지막 단계입니다.
그 앞에는 이런 단계들이 순서대로 일어납니다.
- 계정이나 취약점을 통해 일단 서버 안에 들어옵니다.
- 한동안 조용히 있으면서 권한을 높이고 네트워크를 파악합니다.
- 백업부터 찾아서 지웁니다. 백업이 살아 있으면 몸값을 낼 이유가 없기 때문입니다.
- 데이터를 외부로 복사합니다.
- 그러고 나서야 암호화하고 몸값을 요구합니다.
이 순서에서 두 가지 문제가 따라옵니다.
첫째, 데이터를 이미 빼내갔기 때문에 백업으로 잘 복구해도 협박이 끝나지 않습니다. 국내에서는 개인정보가 유출되면 인지한 날로부터 72시간 안에 신고 의무가 생깁니다. 복구 문제이기 전에 법적 신고 사안이 되는 셈입니다.
둘째, 침입자가 서버 안에 머무는 잠복 기간 동안 만들어진 백업에는 침입자가 심어둔 것들이 같이 들어 있습니다. 웹셸, 등록해둔 SSH 키, 새로 만든 계정 같은 것들이요. 그 백업을 그대로 복원하면 처음부터 다시 당합니다. 복원하고 이틀 뒤에 또 잠기는 게 바로 이 경우입니다.
백업의 조건은 '주기'가 아니라 이 네 가지입니다
많은 분들이 백업을 얼마나 자주 하느냐로 관리합니다. 그런데 실제로 중요한 건 주기보다 다음 네 가지입니다.
① 분리 — 원본과 같은 공간에 두지 않기
같은 서버, 같은 디스크, 마운트해둔 네트워크 드라이브에 백업을 두는 건 분리가 아닙니다. 서버가 장악되면 백업도 같이 지워집니다.
S3 같은 외부 저장소로 보냈다면 한 가지를 더 확인해야 합니다. 그 서버 안에 S3에 접근하는 키가 들어 있고, 서버를 장악한 사람은 그 키도 같이 가집니다. 외부에 뒀는데 백업이 사라지는 경로가 바로 이겁니다.
② 삭제 권한 차단 — 서버가 자기 백업을 지울 수 없게
서버에 넣는 키는 쓰기 전용으로 두는 것이 좋습니다. IAM에서 PutObject만 허용하고 DeleteObject와 DeleteObjectVersion은 막아두면 됩니다. 목록 조회 권한도 굳이 줄 필요가 없습니다.
한 단계 더 나아가면 S3 오브젝트 락을 컴플라이언스 모드로 설정하는 방법이 있습니다. 정해둔 기간 동안은 루트 계정으로도 지울 수 없습니다. 거버넌스 모드는 특정 권한을 가진 사람이 우회할 수 있어서, 진짜로 삭제를 막으려면 컴플라이언스 모드를 써야 합니다.
핵심은 한 줄입니다. 서버가 자기 백업을 지울 수 있으면, 그 서버를 장악한 사람도 지울 수 있다.
③ 보존 기간 — 용량이 아니라 잠복 기간 기준으로
보존 기간을 7일, 30일 같은 기본값으로 두는 경우가 많습니다. 그런데 이 숫자는 디스크 용량이 아니라 침입 잠복 기간을 기준으로 잡아야 합니다.
보존이 30일인데 침입이 40일 전이었다면, 갖고 있는 백업 전부가 감염 이후 시점의 백업입니다. 되돌아갈 곳이 없어집니다.
세대를 나눠서 잡으면 용량을 감당하면서도 과거로 멀리 갈 수 있습니다. 일 단위 30일, 주 단위 12주, 월 단위 12개월 구성이 기준점으로 쓰기 좋습니다. 오래된 세대는 저렴한 스토리지 등급으로 내리면 됩니다.
④ 복원 검증 — 백업 성공 로그는 복원이 된다는 증거가 아닙니다
덤프가 빈 파일로 떠 있거나, 압축이 깨졌거나, 암호화해둔 백업의 복호화 암호를 아무도 기억 못 하는 경우가 실제로 있습니다. 부주의해서가 아니라 평소에 확인할 계기가 없어서 생기는 일입니다.
분기에 한 번은 실제로 복원을 해보는 것이 좋습니다. 연습 없이 실제 사고를 만나면 백업 파일이 있어도 막막합니다.
이 네 가지를 다 해도 남는 질문 — "어느 백업이 깨끗한가"
네 가지를 모두 챙겼더라도 대답하지 못하는 질문이 하나 남습니다.
"그래서 어느 백업을 써야 하나요?"
침입 시점을 모르면 90일치를 갖고 있어도 어느 걸 골라야 할지 모릅니다. 감으로 하나 골랐다가 그게 감염된 백업이면 처음부터 다시입니다. 그래서 탐지가 백업만큼 중요합니다.
다음 네 가지는 거창한 보안 도구 없이 현실적으로 적용할 수 있는 탐지 방법입니다.
배포 파일 무결성 확인 — 배포 후에는 코드 파일이 바뀔 이유가 없습니다. 배포 시점에 파일 해시 목록을 만들어두고 매일 대조합니다. 웹 루트에 없던 파일이 생겼다면 그게 웹셸입니다. 어제 이후 수정된 파일만 추려보는 것만으로도 꽤 잡힙니다. authorized_keys에 추가된 공개키, 새로 생긴 크론잡, 새 계정, 새로 붙은 sudo 권한도 마찬가지입니다. 변화가 없어야 정상인 것들이 바뀌는 순간이 신호입니다.
압축률 모니터링 — 암호화된 데이터는 압축이 되지 않습니다. 무작위에 가까운 데이터라 gzip이 줄일 게 없기 때문입니다. 매일 뜨는 백업 파일의 압축률을 보면 됩니다. 어제까지 크게 줄던 덤프가 오늘은 거의 안 줄었다면, 원본이 이미 암호화됐다는 뜻입니다. 구현은 두 줄이면 됩니다. 압축 후 크기를 압축 전 크기로 나누고, 어제 대비 편차가 임계치를 넘으면 알림을 보냅니다. 오늘 하나만 붙인다면 이걸 먼저 권합니다.
미끼 파일 — 공유 폴더나 데이터 디렉토리에 아무도 건드리지 않는 파일을 심어둡니다. 랜섬웨어는 디렉토리를 훑으면서 전부 암호화하기 때문에 이 파일도 같이 건드립니다. 해시가 바뀌는 순간이 암호화가 시작된 시점입니다. 그리고 이 알림이 울렸을 때 가장 먼저 해야 할 일은 서버를 끄는 게 아니라 백업 잡을 멈추는 것입니다. 알림을 무시하고 그날 밤 정기 백업이 돌면 암호화된 파일로 멀쩡한 백업이 덮어씁니다. 이 순서는 문서로 적어두는 게 맞습니다. 사고가 나면 아무도 침착하지 않습니다.
하트비트 모니터링과 로그 보존 — 침입자가 초반에 하는 일 중 하나가 로그를 지우고 알림을 끄는 것입니다. 알림이 안 오는 것도 경보여야 합니다. 매일 오던 "백업 정상" 메시지가 오늘 안 왔다면 그 자체를 이상 신호로 처리하는 구조가 필요합니다. 로그 보존 기간도 백업 보존 기간과 같게 맞춰두는 것이 좋습니다. 백업은 90일치인데 로그가 7일뿐이라면 침입 시점을 특정할 수가 없고, 결국 어느 백업이 깨끗한지 감으로 골라야 합니다. 로그는 서버 밖으로 내보내야 합니다. 서버 안에만 있으면 같이 지워집니다.
복원은 되돌리기가 아니라 다시 짓기입니다
급할 때 가장 자연스러운 선택이 서버 전체 이미지를 통째로 되돌리는 것입니다. 그런데 그렇게 하면 침입자가 심어둔 것도 같이 되돌아옵니다.
원칙은 이렇습니다. 인프라는 다시 짓고, 데이터만 복원합니다. 서버는 깨끗한 이미지로 새로 올리고, 코드는 저장소의 검증된 태그에서 배포합니다. 백업에서 가져오는 건 데이터베이스 덤프와 업로드 파일뿐입니다.
업로드 파일은 한 번 더 주의가 필요합니다. 사용자가 올린 파일 중에 웹셸이 섞여 있을 수 있어서, 복원할 때 그 디렉토리는 실행 권한을 막고 올리는 게 좋습니다.
그리고 자주 빠뜨리는 게 인증 정보 전량 교체입니다. 그 서버에 있던 건 전부 유출된 것으로 봐야 합니다. 환경변수, DB 비밀번호, API 키, SSH 키까지는 대부분 교체하는데 세션과 토큰 서명 키를 빠뜨리는 경우가 있습니다. 이걸 바꾸지 않으면 침입자가 가져간 세션이 새로 만든 서버에서도 그대로 유효합니다.
Laravel을 쓴다면 추가로 확인할 것이 있습니다. 앱 키를 교체하는 순간 그 키로 암호화해서 DB에 저장해둔 컬럼도 함께 읽히지 않습니다. 키 교체 계획에 해당 컬럼 재암호화까지 같이 포함시켜야 합니다.
오늘 확인해볼 수 있는 7가지 항목
아래 항목 중 "모르겠다"가 나오는 게 있다면 그게 먼저 챙겨야 할 지점입니다.
- 서버에 있는 백업 키로 백업을 삭제할 수 있는 상태는 아닌가
- 침입 시점을 소급해서 알아낼 수 있는가
- 로그 보존 기간이 백업 보존 기간과 같고, 로그가 서버 밖에 보관되어 있는가
- 배포된 코드에 없던 파일이 생기면 알 수 있는가
- 마지막으로 실전처럼 복원을 연습해본 적이 있는가
- 백업 파일의 크기나 압축률이 갑자기 변하면 알림이 오는가
- 암호화가 시작됐을 때 백업 잡부터 멈추는 절차가 문서로 있는가
7개 전부 갖춰진 곳은 드뭅니다. 하나만 먼저 한다면 6번, 압축률 알림을 추천합니다. 구현 비용이 가장 낮으면서 가장 이른 시점에 신호를 줍니다.
이 내용을 영상으로 보고 싶다면 아래 유튜브 링크에서 확인하실 수 있습니다. 각 탐지 방법의 구체적인 구현 방식까지 자료화면과 함께 정리해뒀습니다.
▶ https://youtu.be/ryiqMPWtAAM
서버 백업 구조나 인프라 설계를 새로 검토하고 있다면, 현재 운영 방식에서 어떤 부분이 빠져 있는지부터 함께 정리해드릴 수 있습니다. 부담 없이 현재 상황을 먼저 말씀해 주세요.
→ https://honest-family.com