최근에 새로운 포트폴리오를 작성하면서, 이 참에 그동한 일한 이력을 정리하거나 새로이 갱신하기 위해서 기존에 쓰던 Notion 대신 워드프레스에 갱신하려고 기존에 등록해 둔 도메인으로 접속했다.
그런데 왜인지 모르지만 Too Many Redirections 오류가 뜨는게 아닌가.
그래서 우선 DB부터 확인해보자, 하고 OCP 인스턴스에 접속해 테이블을 조회해보니…

눈을 씻고 봐도 해당 컬럼 밖에 없었다.
이게 무슨일이야 하고 이곳저곳 검색하고, AI에게도 물어보니 결론은 금방 나왔다.
내 DB가 랜섬웨어 봇에게 탈탈 털린 것이다.
저 RECOVER_YOUR_DATA_info라는 테이블은 보안이 취약한 DB를 스캔해 기존 데이터를 싹 지워버리고(DROP), “복구하고 싶으면 비트코인을 보내라”며 남겨두는 전형적인 협박 편지였다. 워드프레스가 자꾸 가입 페이지(wp-signup.php)로 리디렉션 시켰던 이유도 설정 문제가 아니라, 연결할 데이터베이스 자체가 텅 비어버렸기 때문이었다.
잠시 멍해졌지만, 다행히 아직 본격적인 포트폴리오 데이터를 마이그레이션하기 전이었다. 잃을 것이 없는 지금이 오히려 인프라 보안을 점검할 완벽한 타이밍이라는 생각이 들었다. 도대체 내 서버의 어느 구멍이 뚫렸던 것일까?
Dear Sir/Madam, We hope this message finds you well. We would like to let you know that we created a backup of your databases/tables (we keep them for 60 days and then permanently delete them). We offer you our recover service – 궁금한 사람을 위해 남겨둔다.
그래서 어떻게 해결해야 하는가
해킹을 당했다는 사실을 인지한 직후, 가장 먼저 해야 할 일은 당황해서 서버를 끄는 것이 아니라 공격 경로를 차단하는 것이었다.
경로 확인하고 차단하기
봇넷이 내 DB에 무혈입성할 수 있었던 이유는 너무나도 명백했다.
개발과 세팅의 편의성을 위해 외부 DB 툴(DBeaver 등)에서 바로 접속하겠다고 3306 포트(MariaDB)를 퍼블릭하게 열어둔 것이 화근이었다. 더군다나 테스트용으로 설정해 둔 단순한 비밀번호는 해커들의 공격에 1초도 버티지 못했을 것이다.
우선 록키 리눅스의 방화벽(firewalld) 설정에서 당장 3306 포트부터 닫아버렸다.
# 외부망에서 3306 포트 접근 즉각 차단
sudo firewall-cmd --permanent --remove-port=3306/tcp
sudo firewall-cmd --reload
# 변경된 방화벽 규칙 확인 (80, 443 포트만 정상 개방된 것 확인)
sudo firewall-cmd --list-all
이 조치로 웹 서버(Apache)와 DB는 로컬(localhost) 내부망에서만 통신하게 되었고, 외부의 직접 접근은 완벽히 차단되었다.
권한 탈환하기
포트는 막았지만, 이미 털려버린 DB 내부를 정리해야 했다. 그런데 설상가상으로 최고 관리자인 root 계정으로 접속조차 되지 않았다. Access denied. 해커가 스크립트를 돌리며 권한을 꼬아놓았거나 패스워드가 유실된 상황이었다.
정상적인 로그인이 불가능하다면, 억지로 문짝을 뜯고 들어가는 수밖에 없다. DB 데몬을 잠시 멈추고, 권한 검사를 아예 생략하는 --skip-grant-tables 옵션을 이용해 안전 모드로 진입했다.
DB 삭제 및 재구축하기
DB 쉘에 들어온 후, 가장 먼저 빼앗겼던 계정들의 비밀번호를 영문, 숫자, 특수문자가 조합된 비밀번호로 덮어씌웠다.
그다음, 랜섬웨어 봇이 남겨둔 협박 테이블과 오염된 DB를 깔끔하게 날려버리고 깨끗하게 새로 만들었다.
-- 1. 조작된 환경에서도 권한 설정을 할 수 있도록 강제 새로고침
FLUSH PRIVILEGES;
-- 2. root 및 워드프레스 전용 계정 비밀번호 재설정
ALTER USER 'root'@'localhost' IDENTIFIED BY '비밀번호';
ALTER USER 'host'@'localhost' IDENTIFIED BY '비밀번호';
-- 3. 기존의 오염된 데이터베이스 삭제
DROP DATABASE IF EXISTS wordpress_db;
-- 4. 새 데이터베이스 생성 및 권한 부여
CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'host'@'localhost';
FLUSH PRIVILEGES;
시스템 정상화 및 교훈
DB 세팅을 마친 뒤, 조작했던 환경 변수를 원래대로 돌려놓고 DB 서비스를 정상적으로 재시작했다. 워드프레스의 wp-config.php 파일에도 새로 설정한 비밀번호를 갱신해 주었다. 완전히 새로운 시크릿 창을 열어 사이트에 접속하자, 그 지긋지긋했던 리디렉션 에러 대신 반가운 워드프레스 초기 설치 화면이 나를 반겼다.
앞으로 외부에서 DB GUI 툴을 사용해 접속해야 할 일이 있다면, 방화벽을 여는 대신 반드시 22번 포트를 경유하는 SSH 터널링(SSH Tunneling)을 통해서만 안전하게 통신할 것이다. 비싼 돈 주고도 못 배울 귀중한 인프라 보안 실전 훈련을 본격적인 마이그레이션 전에 겪어서 오히려 다행이라고 생각한다.