로그 파일 삭제범 검거 과정 2편

1편: https://dydk1215.tistory.com/266

 

 

지난번, 서버 애플리케이션이 돌아가고 있는 EC2 인스턴스에서 로그 파일이 없어지는 현상을 보고 auditd를 설치했었다. auditd는 디렉토리나 파일에 대한 변경사항을 감지해 어떤 이벤트가 발생했는지 파악할 수 있는 툴이다.

 

auditd 설치 후 드디어 로그 파일 삭제 이력이 기록으로 남아서 그 결과를 정리해봤다.

 

이벤트 분석

auditd 로그에 아래와 같은 이벤트가 여러번 발생했다.

 

/usr/bin/git clean -ffdx 명령어가 실행됐고, 그 결과 backend 디렉토리는 물론 frontend 디렉토리까지 파일 삭제 작업이 진행됐던 것이다. 삭제된 파일마다 동일한 이벤트 메타 데이터가 로깅됐다.

 

아쉽게도 해당 명령어를 실행시킨 사용자(uid)는 ubuntu로 떠서, 정확히 누구인지 파악하기는 어려웠다.

 

실체 파악

팀원 중 git clean을 돌린 사람은 없으니 프로그램이 했을 것이고, 당장 의심해볼 만한 게 GitHub Actions runner여서 Actions 실행 기록을 찾아봤다.

 

다행히 로그와 동일한 시간대에 돌아간 Actions가 있어서 우리의 소중한 파일이 삭제되는 현장을 눈으로 직접 확인할 수 있었다!

 

💥 CI/CD 파이프라인 스크립트에 사용한 actions/checkout@v4 액션이 최신 작업물을 받아오기 전에 git clean을 돌린 것이 원인이었다.

 

git clean은 Git으로 트랙킹하지 않는 파일들을 찾아 삭제하는 명령어다. actions/checkout@v4는 혹시 모를 충돌을 방지하기 위해 브랜치 자체도 아예 새로 받아오고, 버전 관리하지 않는 찌꺼기 파일들도 함께 삭제한다. 이 과정에서 우리 빌드 파일과 로그들이 같이 소각되고 있었다.

 

CI/CD 파이프라인 프로세스를 정확히 파악하지 못하고 로그 파일을 저장할 위치를 선정했으니, 로그 파일 삭제범은 결국 나였다...

 

 

처음에 문제를 발견했을 땐 많이 혼란스러웠다. GitHub Actions runner로 빌드와 배포를 하고 있으니 Actions 컨텍스트가 끝나서 파일이 소실되는 것인가라는 가설을 세워보기도 했지만, 결과적으로는 다른 곳에서 클린업 작업을 돌리고 있었다.

 

프로젝트를 본격적으로 운영하기 전에 겪어봐서 참 다행이라고 느낀다. 로그는 Git으로 관리하는 소스코드 디렉토리가 아닌 다른 안전한 곳에 보관하자!