모두
모두콘텐츠
얼마 전 웹사이트 장애 상담을 받았는데, 운영자는 트래픽 급증을 의심하고 있었습니다. 확인해 보니 서버 안의 파일 이름이 한꺼번에 바뀌었고, 백업 저장소에도 같은 관리자 계정으로 접근할 수 있는 상태였습니다. 랜섬웨어감염이 의심될 때는 서버 사양을 올리거나 재부팅하기 전에 피해가 번지는 경로부터 끊어야 합니다.
감염이 의심되면 연결부터 끊는다
웹 파일이 갑자기 열리지 않거나 금전을 요구하는 문구가 생겼다면 변경 시각과 범위를 먼저 확인합니다. 파일 몇 개만 바뀌었는지, 데이터베이스와 같은 계정으로 관리하는 다른 서버에도 변화가 있는지 봅니다. 단순한 배포 오류나 저장 공간 부족도 비슷한 장애를 만들 수 있으니, 암호화된 파일과 요구 문구 같은 흔적을 함께 확인해야 합니다.
감염 정황이 뚜렷하면 관리 화면에서 해당 서버의 네트워크를 격리하고 공유 저장소 연결을 차단합니다. 웹호스팅처럼 서버 전체를 제어할 수 없다면 호스팅 업체에 즉시 계정 격리와 같은 계정의 다른 사이트 확인을 요청합니다. 한국인터넷진흥원과 미국 사이버보안·인프라 보안국의 대응 안내도 피해 시스템의 신속한 격리를 우선합니다.
- 감염을 발견한 시각, 마지막 정상 접속 시각, 이상 파일의 경로를 기록합니다.
- 가능하면 로그와 디스크 상태를 보존합니다. 네트워크 격리가 가능하다면 조사 전에 무작정 전원을 끄거나 파일을 지우지 않습니다.
- 관리자 계정은 안전한 별도 기기에서 비밀번호를 바꾸고, 접속 키와 백업 저장소 자격 증명도 교체합니다.
운영 중인 서버에서 곧바로 복호화 도구를 실행하는 일은 조심해야 합니다. 랜섬웨어 종류를 잘못 판단할 수 있고, 추가로 파일을 변경하면 조사와 복구가 어려워집니다. 금전을 지불해도 데이터 복구가 보장되는 것은 아닙니다.
백업은 날짜보다 접근 권한을 먼저 확인한다
백업 파일이 있다는 말만으로 복구 가능하다고 판단하면 사고가 납니다. 운영 서버와 백업 저장소가 같은 관리자 계정을 쓰고 있었다면 공격자가 백업까지 삭제하거나 암호화했을 수 있습니다. 자동 동기화된 폴더도 안전한 백업으로 보기 어렵습니다. 이미 변경된 파일을 그대로 복제했을 가능성이 있기 때문입니다.
예를 들어 하루 한 번 백업하고 최근 7개만 보관한다면, 감염 사실을 일주일 넘게 모르고 지나간 경우 정상 시점이 모두 밀려났을 수 있습니다. 백업 목록에서 생성 시각만 보지 말고 파일 크기, 실행 결과, 실제 내용을 확인해야 합니다. 데이터베이스 덤프가 0바이트이거나 매번 같은 오류로 끝났는데도 작업 상태만 성공으로 표시되는 경우가 있습니다.
복구 후보는 마지막 정상 시점보다 앞선 것으로 고릅니다. 다만 파일 백업과 데이터베이스 백업의 시각이 다르면 게시물이나 주문 기록이 어긋날 수 있습니다. 복원 전 두 시각을 적어 두고, 누락될 수 있는 데이터 범위를 운영 담당자와 확인하는 편이 안전합니다.
깨끗한 환경에 복원하고 재침입 경로를 막는다
감염된 서버에서 악성 파일만 찾아 지우고 서비스를 다시 켜는 방식은 위험합니다. 공격자가 추가 계정, 예약 작업, 웹셸을 남겼을 수 있습니다. 새 서버나 초기화한 환경에 운영체제와 웹서버를 다시 설치한 뒤 검증한 백업을 복원하는 순서가 낫습니다.
복원 전에 웹 애플리케이션과 플러그인의 취약한 버전, 외부에 열린 관리 포트, 재사용한 비밀번호를 점검합니다. 침입 경로가 그대로면 새 서버도 다시 감염될 수 있습니다. 관리자 계정과 배포 계정에는 필요한 권한만 주고, 가능한 곳에는 다중 인증을 적용합니다. 서버에서 백업 저장소의 과거 사본을 삭제할 권한까지 갖지 않도록 분리하는 것도 중요합니다.
서비스 재개는 단계적으로 합니다. 먼저 외부 접근을 막은 상태에서 파일 무결성, 데이터베이스 연결, 관리자 로그인, 주요 페이지를 확인합니다. 그다음 접근을 열고 오류 로그와 비정상적인 파일 변경을 관찰합니다. 고객 정보가 유출됐을 가능성도 별도로 판단해야 합니다. 랜섬웨어는 파일 암호화만 하는 사고라고 단정할 수 없습니다.
복구 시간을 기준으로 백업을 설계한다
개인 블로그와 주문이 들어오는 쇼핑몰의 백업 주기가 같을 이유는 없습니다. 하루치 글을 다시 올릴 수 있는 블로그라면 일일 백업으로 충분할 수 있습니다. 반면 주문 10분치도 잃기 어렵다면 데이터베이스 백업이나 복제 주기를 더 짧게 잡아야 합니다. 복제는 실수와 암호화된 데이터도 따라갈 수 있으므로, 이전 시점으로 돌아갈 수 있는 별도 백업이 필요합니다.
비용을 계산할 때는 저장 용량보다 복구 가능 시간을 먼저 봅니다. 예를 들어 웹 파일 5GB와 데이터베이스 2GB인 사이트라면 수백 GB짜리 서버보다 분리된 백업 저장소와 복원 연습이 더 급할 수 있습니다. 정상 운영 비용뿐 아니라 장애 때 몇 시간 안에 서비스를 다시 열어야 하는지도 사양과 보관 주기를 결정합니다.
저는 백업 작업이 성공했다는 알림보다 분기마다 한 번 실제로 복원해 본 기록을 더 믿습니다. 랜섬웨어감염 뒤에는 저장해 둔 데이터의 양보다, 공격자가 닿지 못한 사본을 얼마나 빨리 검증하고 꺼낼 수 있느냐가 운영 시간을 좌우합니다.
