MongoDB, 아무나 들어오세요? 위험천만한 보안 구멍 막아봅시다 (feat. MongoBleed)

안녕하세요. 풀링포레스트 8년차 개발자 김테크입니다.

오늘은 조금 아찔했던 기억을 끄집어내 볼까 합니다. 개발자라면 누구나 한 번쯤 "아, 설마 이게 뚫리겠어?" 하고 무심코 넘겼던 설정 하나가 거대한 재앙으로 돌아오는 꿈을 꾸곤 하죠. 저도 예전에는 그랬습니다. "우리 서비스는 아직 작으니까 해커들이 관심이나 갖겠어?" 하고요.

하지만 최근 보안 커뮤니티에서 'MongoBleed'라는 키워드가 다시금 화제가 되는 걸 보면서, 8년 전 주니어 시절 겪었던 식은땀 나는 경험이 떠올랐습니다. 오늘은 그 이야기를 통해 왜 데이터베이스 보안이 '나중에 챙길 일'이 아니라 '지금 당장 해야 할 일'인지 이야기해보려 합니다.

"설마 포트 열려있다고 다 털리겠어?"

MongoBleed. 이름부터 섬뜩하죠? 유명한 OpenSSL 취약점이었던 'Heartbleed'를 연상시키기도 하고요. 사실 이 도구의 원리는 생각보다 단순하지만, 그 파괴력은 어마어마합니다.

핵심은 '인증 없이 열려있는 MongoDB 인스턴스를 찾아내고, 데이터를 탈취하거나 삭제하는 것'입니다.

제가 3년 차 때였을 겁니다. 당시 급하게 프로토타입을 만들어야 해서 AWS EC2 인스턴스에 MongoDB를 띄우고 개발을 시작했습니다. 빨리 기능을 보여주는 게 우선이라 bindIp: 0.0.0.0 (모든 IP 허용) 설정을 해두고, 보안 그룹(Security Group)도 27017 포트를 활짝 열어뒀죠. "나중에 인증 걸어야지"라고 생각하고요.

그리고 정확히 3일 뒤, 출근해서 로그를 보는데 이상했습니다. 데이터가 없어진 건 아닌데, 컬렉션 이름이 READ_ME_TO_RECOVER_YOUR_DATA 같은 식으로 바뀌어 있는 겁니다. 네, 랜섬웨어 공격이었습니다. 다행히 테스트 데이터라 피해는 없었지만, 만약 실제 운영 데이터였다면? 생각만 해도 끔찍합니다.

MongoBleed가 노리는 것

최근 공개된(혹은 다시 주목받는) MongoBleed 같은 도구들은 이런 실수를 집요하게 파고듭니다. 기술적으로 대단히 복잡한 해킹 기법을 쓰는 게 아닙니다.

1. 스캐닝: 인터넷 전체를 대상으로 27017 포트(MongoDB 기본 포트)가 열려있는 서버를 무작위로 찾습니다.

2. 연결 시도: 발견된 서버에 인증 없이 접속을 시도합니다.

3. 데이터 탈취/변조: 접속이 되면 데이터베이스 목록을 긁어오거나(dump), 랜섬 노트를 남기고 데이터를 암호화해 버립니다.

이 과정이 자동화되어 있다는 게 무서운 점입니다. 우리가 퇴근하고 자는 사이, 봇(Bot)들은 쉴 새 없이 우리 서버의 문고리를 돌려보고 있는 셈이죠.

풀링포레스트는 어떻게 방어하고 있나

저희 풀링포레스트 팀에서도 인프라를 구축할 때 가장 신경 쓰는 부분이 바로 이 DB 보안입니다. MongoBleed 같은 공격은 사실 '기본'만 지켜도 99% 막을 수 있습니다. 제가 팀원들에게 귀에 못이 박히도록 강조하는 체크리스트를 공유합니다.

1. VPC와 Private Subnet의 생활화
가장 확실한 방법은 DB가 아예 인터넷 세상에 존재하지 않는 것처럼 만드는 겁니다. 저희는 모든 데이터베이스를 외부에서 접근 불가능한 Private Subnet에 배치합니다. 개발자가 DB에 접속해야 할 때는 Bastion Host(점프 서버)나 VPN을 통해서만 접근하도록 강제합니다. 이렇게 하면 27017 포트가 열려있든 말든, 외부 해커는 접근조차 할 수 없습니다.

2. 인증(Authentication)은 선택이 아닌 필수
mongod.conf 파일에서 security: authorization: enabled 옵션을 켜는 건 기본 중의 기본입니다. 개발 환경이라도 예외는 없습니다. "귀찮아서"라는 이유로 인증을 끄는 순간, 그 DB는 공공재가 됩니다.

3. 기본 포트 변경
이건 약간의 '꼼수' 같지만 의외로 효과가 있습니다. 27017 대신 다른 포트를 사용하면 무작위 봇 스캐닝의 타겟에서 벗어날 확률이 높아집니다. 물론 포트 스캐닝을 정밀하게 하면 다 들통나지만, 1차적인 자동화 공격을 피하는 데는 가성비 좋은 방법입니다.

4. 정기적인 취약점 점검 도구 활용
저희 팀은 인프라 배포 시에 보안 그룹 설정이 너무 느슨하지 않은지 자동으로 체크하는 스크립트를 돌립니다. 또한, 클라우드 제공 업체(AWS, GCP 등)에서 제공하는 보안 진단 도구를 주기적으로 확인합니다. "우리 집 문단속 잘 됐나?"를 기계가 대신 확인해 주는 거죠.

"나는 아니겠지"가 가장 위험합니다

사실 MongoBleed 같은 도구가 나오는 건, 그만큼 보안에 구멍 뚫린 DB가 세상에 많다는 방증이기도 합니다.

기술이 발전하고 AI가 코드를 짜주는 세상이 되었지만, 결국 보안 설정 한 줄을 챙기는 건 사람의 몫입니다. 오늘 이 글을 읽으셨다면, 지금 당장 터미널을 열고 우리 서비스의 DB 설정 파일을 한 번 열어보시는 건 어떨까요?

bindIp가 0.0.0.0으로 되어 있지는 않은지, 보안 그룹에 0.0.0.0/0이 열려 있지는 않은지 확인하는 그 1분이, 훗날 닥쳐올 수 있는 거대한 재앙을 막아줄지도 모릅니다.

저희 풀링포레스트 팀도 늘 "보안은 0이 아니면 1이다"라는 마음으로, 조금은 편집증적으로 서버를 지키고 있습니다. 여러분의 소중한 데이터도 안전하길 바랍니다.

오늘도 안전한 배포 되세요!