📌 개요
어느 날, 배포해놨었던 프로젝트의 서버가 난데없이 죽어있길래 부랴부랴 로그를 살펴보니..
DB의 스키마를 찾지 못한다는 로그를 발견 할 수 있었습니다..
제가 직접 건들지 않는이상 database 는 절대 발생 할 수 없는 로그인데 무슨일인가 DB 를 확인해봤으나 웬걸...
사용되고 있던 스키마는 통째로 없어지고 아래와 같은
RECOVER_YOUR_DATA 의 스키마와 함께 RECOVER_YOUR_DATA 테이블이 생성되어 있는것을 마주할 수 있었습니다😂
테이블 내의 데이터를 확인해보면 더욱 난감할 수 밖에 없었습니다.
'All your data is backed up.
You must pay 0.0105 BTC to bc1q307y2v8aujqwrej8m9v998yj0m242km989t8d2
In 48 hours, your data will be publicly disclosed and deleted.
(more information: go to http://2fix.info/mysql)'
'After payment send mail to us: dzen+23ote@onionmail.org and we will provide a link for you to download your data.
Your DBCODE is: 23OTE'
너의 모든 데이터는 백업되었다. 0.0105 비트코인을 지불해야만한다.
(그렇지 않다면) 너의 데이터는 모두 공개가 되고 삭제가 될 것이다.
결제 후 이메일을 날린다면 너의 데이터를 다시 다운 받을 수 있는 링크를 제공해주겠다!
0.0105 BTC 는 처음 보는 단위라 검색해보니.. 130만원 가량을 요구 하는 것 이었음을.. (돈 없어요..)
📌 수많은 침투가 보여졌던 IP 와 접속 시도들
AWS 의 RDS 내에서도 로그를 볼 수 있습니다.
아래와 같이 데이터베이스 - 로그 및 이벤트 탭으로 들어가면 해당 데이터베이스의 로그들이 나열 되어 있는 모습을 볼 수 있습니다.
error 와 관련된 수많은 파일들이 생겨서 펼쳐본 결과,
아래와 같은 로그들을 확인 할 수 있었습니다.
IPv4 를 모두 허용으로 열어놨었기에, 피해가 발생한 듯 보입니다ㅜ
특정 IP 주소(185.59.221.158)에서 약 1~3초에 걸쳐서 지속적으로 비밀번호 대입을 시도한 것으로 보아 brute-force 와 같이 수많은 비밀번호 조합을 시도하여 공격한 듯으로 추정됩니다.
📌 나의 허점
해킹을 당하고 저의 RDS 관리를 돌아보니,, 참 많은 보안적 허점을 열어두고 사용을 했었다는 것을 반성하게 되었습니다. 혹시 여러분들은 아래의 내용 중 몇개에 해당하시나요?
만일 퍼블릭 엑세스를 허용해준 RDS 기준 2가지가 충족되었다면, 굉장히 큰 위험에 놓여있다고 생각하셔도 될 것 같습니다..!
1. RDS 퍼블릭 엑세스 허용
2. 거의 다 허용해줬던 인바운드 규칙
3. username 을 mysql 기준 기본값 root 사용
4. 포트번호를 mysql 기준 기본값 3306 사용
5. 다소 쉬운 비밀번호
❓ 해결 방안
만일 해당 정보가 실서비스를 운영하여 중요한 정보를 내포하고 있었거나, 방대한 양의 데이터가 보관되어 있었다면.. 아찔했을 뻔 했으나, 주기적으로 dump 파일로 데이터를 보관해놨던 습관덕에 데이터 복구작업은 손쉽게 이루어질 수 있었습니다.
( 백업 습관은.. 항상 들여놓도록 합시다..! )
문제는 해당 상황이 다시 발생하지 않도록 위 5가지에서 다양한 변경을 이루었어야 합니다.
🔍 1. RDS 퍼블릭 엑세스 허용 여부 판단하기
먼저, RDS의 퍼블릭 엑세스 허용이 되어있는지 확인 하셔야합니다.
사실 2024년 기준, RDS 의 퍼블릭 엑세스를 허용해준다면, 과금이 진행되기 때문에 많은 분들이 인지하고 있을 것 이라 생각합니다. 다만 저는 EC2 서버가 1대가 아닌 여러대로 구성되어 있기 때문에 불가피하게 RDS 퍼블릭 엑세스는 유지할 수 밖에 없습니다,
DB 인스턴스 수정탭에서 수정 가능합니다
🔍 2. 퍼블릭 엑세스를 허용해줬다면, 인바운드 규칙 고려하기
다음은 인바운드 규칙에서 특정 IP 만 허용하도록 설정해준다면, 더욱 좋을 것 같습니다
🔍 3. username 을 기본값으로 root 로 사용하지 않기 ( 생성 시 변경 불가능 )
RDS 를 처음 생성하면 root 계정을 마스터로 사용할 것인지 설정 할 수 있는데, root 를 그대로 쓰는 것 보다, 특정 계정을 master 로 설정하던지. (이것은 생성할 때 이후로는 변경이 불가합니다!)
혹은 추가적인 계정을 생성하여, 권한을 주는 방법을 이용하면 좋을 것 같습니다.
🔍 4. 포트번호를 기본값 3306 포트 사용하지 않기
마찬가지로, 해커들은 기본값으로 설정해둔 보안 초짜들을 노리기 때문에.. 아마 root 와 3306 을 타겟층으로 삼을 것 입니다.
따라서 DB 인스턴스 수정탭 에서 마찬가지로 포트번호를 변경하시면 좋습니다.
🔍 5. 비밀번호 어렵게 변경하기
마지막으로 가장 반성해야 할 부분인데, 저의 비밀번호는 너무 쉬웠던 경향이 있었습니다.ㅜ (사실 비밀번호만 어려웠어도 해킹 가능성은 현저하게 낮았을 것 같습니다...! )
DB 인스턴스 수정탭 에서 비밀번호를 변경하여 영/대소문, 숫자, 특수문자를 적절히 설정하여 비밀번호를 설정한다면 해커가 감히 뚫어볼 시도는 못할 것이라 예상합니다.
🔥 이것 또한 경험이다..!
사실, 배포를 하게 되면서 해커와의 조우는 거의 처음이라 생소하게 느껴졌는데, 이번기회에 뼈저린 해킹을 당해보니, 더욱 바짝차리고 보안에 대한 신경을 써야겠다는 큰 배움을 얻을 수 있었습니다.
다들 배포 환경에서 해커들 조심하세요..!!!
이상, 해당 포스팅을 읽어주셔서 감사합니다 :-) 🙇♀️🙇♂️
📚참고자료 및 출처