[Backend/DB] MongoDB 해킹 당한 사건

 
 
인턴에 참여해서 처음 백엔드 개발을 하게되었고 그 과정 중 귀한 경험을 했다.
 
바로 Mongo DB가 해킹당한 것..!
 
사실 해킹 당하기 며칠 전에 팀원들과 함께 모각코를 했었는데 그 날 Mongo DB 세팅을 진행하고 있었다. 이후에 한 팀원이 어떤 블로그 글을 읽으면서 Mongo DB 해킹 조심하라며, 비트코인 요구한다고 해서 당시에 그냥 웃으면서 흘려들었는데 며칠 뒤에 실제로 해킹당했다..

 
 
 
나는 Mongo DB 서버를 AWS EC2에 배포했었는데 어느 순간 부터 아래와 같이 비트코인을 달라는 문구와 함께 주기적으로 데이터가 초기화되는 현상이 발생했었다.

 
처음에는 DB가 하루에 한 번 꼴로 초기화 되길래 팀원들이 테스트를 위해 일시적으로 데이터를 삭제한 줄 알았다.
 
하지만 그런 작업을 한 팀원이 없다는 것을 확인하고 나서 로그를 확인해보니 해킹 당했다는 것을 알게 되었고 관련 문제에 대해 찾아보았다.
 
결론적으로 자동화 봇이 Mongo DB의 취약한 인증을 악용한 랜섬공격을 해서 DB가 초기화 되었던 것이었다.
 
 
 

보안 강화하기

---

서버 보안이 뚫린 원인을 찾아보던 중 MongoDB를 설치하고 계정 설정을 기본값으로 놔두었던 것이 주된 이유라고 판단했다.
 
그래서 아래와 같이 보안 설정을 했다.
 
1. MongoDB shell에 접속해서 관리자용 계정 생성 

$ mongo

> use admin
> db.createUser({
    user: 'username',
    pwd: 'password',
    roles: [{ role: "readWriteAnyDatabase", db: "admin" }]
})

 
2. MongoDB 설정 파일(/etc/mongod.conf)을 열어서 인증 기능 활성화

security:
  authorization: enabled

 

이러한 추가 설정을 해주었더니 이후에 데이터가 사라지는 일은 없어졌다.
 
이후에 추가적인 개선 방안에 대해 찾아보게 되었는데, 그 이유는 팀원 중 한 명이 멘토님께 DB가 뚫렸다는 말씀을 드렸는데 멘토님께서는 프록시 서버를 이용해 DB를 더 심층적으로 보호할 수 있는 방법이 있다고 조언 해 주셨기 때문이다.
 
따라서 멘토님의 조언을 통해 더 안전한 시스템을 구축하기 위해서는 가장 마지막 접근 단계인 DB 자체에서의 보안 조치 이외에도 DB에 접근하기 전 단계에서도 보안 처리가 필요하다는 것을 알게 되었다.
 
그 중 인바운드 규칙 설정과 프록시 서버의 개념에 대해 공부한 것을 정리해보려 한다.
 
 
 

추가 보안 설정

---

1. 인바운드 규칙 설정

현재 MongoDB 서버의 인바운드 규칙은 0.0.0.0으로 설정되어 있었는데, 이는 누구나 접속이 가능하다는 것을 의미한다.
 
따라서 허용되지 않은 IP 주소의 접속을 막기 위해 사내의 공인 IP 주소나 팀원들의 IP 주소만 허용하도록 인바운드 규칙을 수정하는 것이 좋다.

인바운드 규칙: 외부 네트워크에서 내부 네트워크로 들어오는 트래픽을 제어하는 방화벽 규칙으로, 특정 프로토콜, IP, Port로 들어오는 트래픽을 차단 또는 허용할 수 있다.

 
 

2. Proxy 서버 설정

프록시는 CORS 에러가 발생했을 때 서버 쪽 코드를 수정하지 않고 React 내에서 해결할 수 있는 방법에 대해 찾아보다가 처음 알게 되었던 개념이다.
 
결론적으로는 서버 쪽 코드를 수정해서 에러가 해결되어 직접적으로 코드를 짠 적은 없지만 이번에 공부하면서 어떤 개념인지 확실하게 알게 되었다.
 

프록시 (Proxy)

---

 

출처: 위키백과

 
프록시는 '대리' 또는 '중계'라는 의미로, 서버와 클라이언트 사이의 중계 역할을 하는 것을 말한다.
 
이러한 중계 기능을 하는 장치나 응용 프로그램을 프록시 서버라고 한다. 프록시 서버는 사용되는 위치에 따라 Forward Proxy와 Reverse Proxy로 구분된다.
 

1. Forward Proxy

일반적으로 프록시라고 하면 포워드 프록시를 의미한다.
 
클라이언트 앞에 프록시 서버를 위치시켜, 클라이언트의 요청을 대신 받아 인터넷에 연결하여 서버와 통신 후 결과를 클라이언트에게 반환하는 방식이다.
 
클라이언트 대신 프록시 서버가 웹 서버와 통신하므로 서버에게 클라이언트의 실제 정보를 감출 수 있다.
 
이유는 서버는 포워드 프록시 서버의 IP만 볼 수 있기 때문이다. 이러한 특성때문에 정부나 공공기관 같이 보안이 중요한 곳에서는 특정 웹 서버에만 접근할 수 있도록 제한하기 위해 포워드 프록시를 사용한다.
 

2. Reverse Proxy

리버스 프록시는 포워드 프록시와 반대로 웹 서버 앞에 위치한다.
 
클라이언트가 직접 서버에 요청하는 것이 아니라, 서버 앞에 설치된 프록시 서버에 요청한다. 이후 프록시 서버가 내부 웹 서버로 데이터를 요청하고 결과를 클라이언트에게 전달한다.
 
이렇게 하면 서버의 정보를 클라이언트로부터 감출 수 있다. 클라이언트는 리버스 프록시 서버만 접근하기 때문에 실제 서버의 IP를 알 수 없기 때문이다.
 
웹 애플리케이션 서버(WAS)와 클라이언트가 직접 통신해도 되지만 일반적으로 WAS는 DB 서버와 연결되어 있어 WAS가 공격당할 경우 DB 서버까지 위험에 노출될 수 있다. 이때 리버스 프록시 방식을 사용하여 프록시 서버를 DMZ에 두고 실제 서비스 서버는 내부망에 위치시켜 공격에 대한 위험을 줄일 수 있다.

기업 네트워크 환경에서는 보통 DMZ라는 내부 네트워크와 외부 네트워크 사이의 중간 구간을 두고 이 구간에 메일 서버, 웹 서버, FTP 서버 등 외부 서비스를 제공하는 서버를 배치한다.

 
이번 사건을 방지하려면 리버스 프록시를 구성하여 보안을 강화하는 것이 효과적일 것 같다.
 
 
 

마치며

---

 
지금까지 프론트엔드 개발만 해왔던 터라 보안의 중요성에 대해 이론적으로만 배우거나 간접적으로 경험하는 경우가 대부분이었다.
 
이번 일을 통해 실제로 보안이 취약할 경우 발생할 수 있는 문제점들과 이를 방지하기 위한 다양한 보안 강화 방법들을 직접 알아보고 적용해볼 수 있었다.
 
특히 데이터베이스 수준에서의 계정 설정과 인증 활성화부터 시작해서 네트워크 레벨에서의 인바운드 규칙 설정, 그리고 아키텍처 수준에서의 프록시 서버 활용까지 다층적인 보안 접근법에 대해 배울 수 있었던 것 같아 유익했다.
 
또 보안은 나중에 추가하는 기능이 아니라 설계 단계부터 고려해야 하는 요소임을 알게되었다.
서버를 배포할 때 기본 설정 그대로 사용했던 게 결국 해킹을 당한 주요 원인이라고 생각하기 때문이다. 만약 초기에 보안을 고려했다면 관리자 계정을 처음부터 설정해서 데이터 초기화가 일어나지 않았을 것 같다.
 
앞으로 새로운 프로젝트를 하더라도 이번 경험을 떠올리면서 처음부터 보안을 염두해야겠다!
 
 
 
 
참고
https://nordvpn.com/ko/blog/public-ip-and-private-ip/
https://whackur.tistory.com/177
https://www.cloudflare.com/ko-kr/learning/access-management/what-is-a-vpn/
https://maker5587.tistory.com/47
\https://velog.io/@jmjmjmz732002/Infra-Reverse-Proxy..-%EA%B3%BC%EC%97%B0-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94