내 db가 털렸을리 없어! (2탄)

1편에 이어 계속됩니다..

 

 

 

일단 한번 상황을 정리해 보았다

 

이유는 모르겠지만 mysql 데이터가 탈취당했고, 이는 복구 불가능하다고 판단된다

-> 백업 파일이 따로 존재하지 않고, mysql 컨테이너가 ec2 와 도커 볼륨을 통해 연결되어 있음.

-> 둘이 같은 데이터를 공유하기 때문에 둘 다 오염되었을 가능성이 높고, ec2 인스턴스도 신뢰할 수 없는 상황

사실 중요한 데이터도 아니고(그냥 그저 채팅로그) 인스턴스를 삭제하고 재생성하고 다시 똑같이 서버를 구축하면 되겠지만
만약 이게 실제 운영중인 서버였다면 ?? 그리고 또 이런일이 나한테 일어나지 않으리라는 보장이 있을까?? 라는 생각이 든다.

원인이 무엇일까? 어떻게 접근했을까? 

 

 

나의 aws 환경은 elb를 통해 https 도메인을 적용해두었고,  ec2 인스턴스 1대에 연결되어있는 상태이다. 

ec2인스턴스로 들어 올 수 있는 상황
1. 프론트에서 도메인을 타고 넘어 오는 상황
2. ec2의 ip를 직접 치고 오는 상황
혹은
3. 채팅 기능을 이용한 SQL Injection
셋 중에 하나이지 않을까 생각이 든다.

1의 상황에서는 80포트로 들어올 경우 443포트로 리디렉션 접근되게 설정해놓았기 때문에 1번 상황 보다는 2의 상황에 초점을 맞추어 해결해보려고 한다. 
또 3번의 채팅으로 인한 SQL Injection같은 공격은 스프링부트에서 막아줄거라고 생각하고 그 정도 수준의 해커가 내 토이프로젝트 사이트를 노린다?라고 생각이 들지는 않아서 오히려 2번 상황에 초점을 맞추려고 한다.

현재 모두에게 열려있는 ec2의 ip는 mysql 3306번 포트, 스프링부트의 8080번 포트, ssh의 22번 포트이다.
-> 불필요하게 열려있는 것은 내 ip만 접근하게 변경.

 

하면서 생각해보니까 springboot를 통한(443,80 포트) SQL Injection 공격보다는 내가 무의미하게 노출한 mysql port,ssh,8080포트로 인한 접근이 아닐까 생각된다. 

22번 포트 -> pem키가 노출되었다는거는 내 맥북자체가 해킹당했다는 뜻인데 그럴리 없을거라고 생각한다.
8080번 포트 -> 처음에 http환경에서 8080포트를 사용했지만 현재는 의미 없는 포트
3306번 포트 -> mysql의 포트, 여기로 직접 ip를 통해 접근하지 않았을까 생각이 든다. 내 ip로만 설정해 두어도 도커 컴포즈 내부의 통신을 이용하기 때문에 ec2내부에서는 문제 없이 돌아간다.

웹 사이트에서 노션과 깃허브를 통해 처음에 노출되었던 ip를 확인했을 수도 있고, 포트번호 등 필요한 정보를 얻지 않았을까?

 

추가) ssh를 내ip만 설정해버리면 깃헙 액션을 통한 ci/cd가 불가능해진다 -> ssh로 ec2에 접근이 불가능하기 때문에..
         aws 키가 노출되는건 진짜 다 털려버리는 상황이고, 깃헙 액션의 ip는 수시로 바뀌기 때문에 ssh는 모든ip에 열어주도록 하였다.

일단 현재 포트를 다시 설정하고, 혹시 모를 mysql 비밀번호도 재설정하고 다시 배포해두었습니다.

정상적인 사이트 모습...!!

일단 이렇게 보안조치 해놓고 몇일 지켜보겠습니다. 

만약에 아무 이상이 없으면 보안이 잘 해결된것이고, 이상이 있다면 그때는 로그부터 다시 까보고 공부해보겠습니다!!

3편에 계속..