아래 내용들은 해킹당한줄 모르고 열심히 삽질한 일기입니다
총 5번째 mariadb가 서버가 shut down 되었고, 다시 실행했을때는 데이터가 모두 날아갔었다.
sequelize에 의심을 품고있었다.
그래서 sequelize의 sync도 하지않도록했지만 여전히그랬다.
이후엔 node프로젝트를 실행하는 방식을바꿨다.
기존에는 tsc 컴파일 -> build된 app.js 실행 이었는데,
nodemon, ts-node, pm2 install typescript 를 통해서 별도의 컴파일명령어 실행없이
바로 컴파일후 실행되도록 했다. (혹시나..해서)
그리고 불안한 마음에 계속, 디비로그를 찾아보았다.
에러에 관련된 로그는 자동으로 수집되고있었다.
Ubuntu 환경기준
/var/log/mysql/error.log
/var/log/mysql/error.log.1.gz
에 기록되고있었고, 확인한 결과 아래와같은 기록이남아있었다.
2022-04-23 3:53:27 139732870526720 [Note] /usr/sbin/mysqld: Normal shutdown
2022-04-23 3:53:27 139732870526720 [Note] Event Scheduler: Purging the queue. 0 events
2022-04-23 3:53:27 139732340152064 [Note] InnoDB: FTS optimize thread exiting.
2022-04-23 3:53:27 139732870526720 [Note] InnoDB: Starting shutdown...
2022-04-23 3:53:28 139732870526720 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
2022-04-23 3:53:30 139732870526720 [Note] InnoDB: Shutdown completed; log sequence number 4117780
2022-04-23 3:53:30 139732870526720 [Note] /usr/sbin/mysqld: Shutdown complete
결론적으로 shutdown명령을 내린것었는데..
순간 해킹당했나? 누가 악의적으로 계속 디비를 종료시키는건가? 싶었다.
하지만 나의 작은 서버를 누가 해킹하리.. 그래서 그런일은 배제하고나니, 디비를 다루는 주체는 sequelize밖에 없었다.
그부분에서 내가 ORM을 처음 도입해봤고, 사용법이 미숙해 shutdown명령어가 나가는 거라 예상했고
원초적인 해결책은 아니지만, shutdown을 못하도록 권한을 뺏는 방법을 생각했다.
그래서 모든 유저에게 shutdown권한을 없애버렸고, 아직까지는 잘되고있다.
(2022.04.24 추가) 아니다 또 터졌다..
그런데 진짜해결한거같다. EC2서버에서 express서버가 두개가 돌아가고있었는데,동일한 계정으로 같은 Maiadb에서 다른 schema를 사용하고있었다.
아마 그부분이 뭔가충돌을 야기한거같은데, 검색해보니, 그거에대한 문제는 없는거같은데 일단은 경과를 지켜봐야할거같다.
이번 사건을 겪고나서..
- 디비가 강제로 종료되기직전의 로그를 못찾았을때는 원인을 모르니 너무 답답했다.. 정말 로그를 잘 남기는것이 중요하고,로그들과 데이터도 항상 백업을 잘 해둬야한다는 것을 느꼈다.
- "개발자는 개발하는사람이아니라 문제를 해결하는 사람이구나". 만드는거는 누구나, 구글링을 통해서 할수있다고 생각한다. 하지만 어떤 에러나 얘기치못한 상황이 나타났을때, 그걸 해결해야하는사람이 개발자고, 그런개발자가 되기위해서는 어느 한분야만 안다고 되는것이 아니라 전반적인 개발지식? 이 있어야하고, 그지식은 경험으로 쌓는것임을.. 느낀다.
- 좀 더 에러와 예외상황을 고려하면서 개발하게 될거같다. 그냥 단순히 구현은 마치 바닥에있는 쓰래기를 옆으로 밀어두는것과 비슷한거같다. 당장 눈앞의 상황을 모면하려하지말고, 꼼꼼하게 짚어나가야 한다.
해킹
디비 데이터가 다 사라지고 하나의 글귀만이 남아있었는데, mariadb에서 어떤 문제가발생했을때 자동으로 데이터를 백업해주고,
복구할때는 유료로 서비스를 제공한다는 안내문구인 줄로만 알고있었다.
하나의 컬럼에 긴 글이담겨있어서 제대로 읽어볼 생각을 안했다..
같이 일하는 사람이 "해킹아니냐"는 말에 다시읽어보니 다크웹에뿌린다는 둥.. 비트코인으로 여기로보내라는둥.. 내용이었다.
mariadb 비번은 아무리 테스트라도 '1234'는 하지 말도록 합시다..
'Archive' 카테고리의 다른 글
아무설정필요없이 Docker로 mariadb 바로설치하고 사용하기 (0) | 2022.05.05 |
---|---|
AWS EC2 를 사고 해야하는 일 정리 (0) | 2022.05.04 |
결국한번 더터져버린 db & 삽질과 세팅의 모든것 (0) | 2022.04.22 |
원인모를 DB 폭파현상 (0) | 2022.04.21 |
드디어 나도.. EC2 배포자동화 (Github Actions) (2) | 2022.04.20 |