서버 운영 중 삽질한 이야기입니다. 서버 보안과 관련된 이야기이기도 합니다.

비록 서버 운영 경험이 일천하기도 하지만 막상 외부의 강력한 공격에 해킹되는(되었다고 생각되는) 상황에 처하게되면 당황할 수 밖에 없군요.

저처럼 애매한 위치에 있는 사람을 대상으로 기술 지원 서비스를 한다면 수익성은 없을까하는 생각이 뇌리를 스칩니다.

너무 더워 잠 못이루는 새벽 3시.. 갑자기 서버가 요동치다.

몇일 아니 몇주째 밤에도 열대야가 지속되면서 잠을 이루지 못하고 이리 저리 시간을 죽이고 있는데 갑자기 서버가 요동치기 시작합니다.

PC 모니터가 세개이니 한쪽에는 서버를 모니터링한다고 htop을 켜났거든요.. 램을 4GB에서 2GB로 줄여서도 운영이 가능한지 점검해 본다고 이러 저런 테스트를 해보고 있었죠.

평소엔 load average가 0.2~0.3으로 아주 안정적으로 작동하고 있었는데요. (사실 동시 접속자가 많아야 20명이니) 부하 걸릴일이 거의 없거든요.

그런데 갑자기 CPU 작동율이 올라가기 시작해 100%가 되고 메모리 사용도 급격히 증가하면서 순식간에 load average가 5.7까지 올라가더군요.

Htop의 내용등을 보니 fail2ban이 주기적으로 작동하는 것으로 봐서 무차별 공격이 들어온 것 같더군요..
구글링을 해서 이럴때는 뭘 점검해야하나 고민도 들긴하는데 늦은 시간이라 정신이 맹한 상태에서 저러다 셧다운되면 다시 시작 시키자, 설마 뚫리기야 하겠어 이런 마음 가짐으로 다른일을 하면서 잠잘 준비를 했죠..

loag average 5를 넘기는 것을 보니 신기하기도하고 와 이 상태에서도 버티네하며 신기해 하고 있어죠. 생각외로 무섭지는 않았고 귀찮은 일이 벌어질것 같은 불길한 예감은 들었죠..

아무튼 그렇게 서버가 지랄발광을 떨다가 1시간정도 지나니 잠잠해지더군요.
그럼 그렇지하고 안심하고 잠을 청했고 잠드는데 성공했습니다…

루트에 이상한 파일이 생겼어요.

아침에 사이트를 점검해 봤는데 특별히 이상한 것은 없었습니다.
그러다가 루트에서 ls명령을 쳐보니 basic_passwords.txt 라는 파일이 생겼더군요.

불안해하면서 이 파일을 열어보니 패스워드 리스트가 들어 있는데요. 갑자기 못보던 파일이 있으니 굉장히 불안해졌습니다.

이 파일이 왜 생겼을까?
이것은 누가 만들어 놓은 것일까요? 해킹되어서 해커가 놓고 간것인가? 해커가 테스트를 해 보았나? 화이트 해커라서 보안에 신경쓰라고 패스워드 리스트를 두고 간것일까?
불안하니 이런 저런 생각이 무지 들더군요..

결국 궁금함을 참지못해 xetown에 문의를 해보았죠.

이 파일의 정체는 MySQLTuner에서 만든 것

root에 생긴 basic_passwords.txt 파일은 어떤 흔적일까요?

그랬더니 닉네임님이 MySQLTuner 관련 사이트 링크를 알려주엇습니다. 결국 이 파일은 MySQLTuner 에서 가이드하는 파일로서 그 파일속에 든 것처럼 제대로 관리되지 않은 패스워드를 사용하면 안된다는 것을 이야기 해준것이었습니다.

MySQLTuner-perl/basic_passwords.txt

삽질..

xetown에 문의하기 전에는 이 파일의 정확한 의미를 명확하게 파악하지 않은 상태에서 이상한 파일은 해킹되지 않았을까 안절부절하지 못하게 되었죠.

그래서 구글링를 통해서 해킹의 징후를 확인하는 방법을 동원해 점검을 해봤지만 뚜렸한 혐의점을 찾기는 못했습니다.
history도 특별한거 없고 password도 이상 없는 것 같고…전용 툴에서도 이상한 징후는 보이지 않았습니다.

그 불안한 상태에서 서버를 재설치하고 보안을 강화하는 방안을 찾는 등 소동을 피웠습니다.

이 파일의 정확한 의미를 알게되니 그 동안의 삽질이 너무 어이없는 거 있죠.
역시 사람은 제대로 뭘 알아야 손발이 고생을 덜 한다는 생각을 해본 하루엿습니다.

이왕 시작한거 기존 서버를 없애버리고 새로운 서버를 세팅했습니다. 서너시간 걸려서 완성해 놓고보니 삽질은 했지만 괜히 안심이 됩니다.

새로 서버를 세팅하니 조금 낫네요.

새로 서버를 세팅하고 비슷한 시간에 상황이 어떤지를 살펴봤는데요. 평소에 비해서 높은 수준의 공격이 진행되었지만 SSH(Secure Shell) port를 22에서 다른 것으로 변경했더니 확실히 공격 강도가 약해졌습니다.

그리고 Failtoban 규칙도 좀 더 엄격하게 세팅했습니다. 에러 시 대기 시간을 1일로 변경 등

이번 18.04로 새로 설치하면서 22번 포트 변경이 예전 방식과 달라서 변경하지 않았더니 이런 엄청난 공격을 받았다는 것이 밝혀지는 셈입니다.

절대적으로 서버 세팅 시 22번 포트를 다른 포트로 변경해야겠습니다. 우분투 18.04에서 22번 포트를 변경하는 방법은 별도로 포스팅해 정리해 보겠습니다.