대상 OS: Amazon Linux 2023

cron은 운영 자동화의 핵심 도구지만, 한 번 잘못 설계되면 “주기적으로 실행되는 취약점”이 됩니다. 특히 root 권한의 cron 작업에 외부 입력(파일/URL/공유경로)이 섞이면 사고 규모가 커집니다.

Amazon Linux 2023 기준으로 cron 점검 포인트와, 보안 사고로 이어지는 대표 패턴을 실무 관점에서 정리합니다.

1) cron이 어디에 있는지부터 ‘전수’ 파악

우선 “사용자 크론”과 “시스템 크론”을 나눠서 확인합니다. 누락이 생기면 점검이 의미가 없어집니다.

# 현재 사용자 크론(존재하지 않으면 메시지 출력)
crontab -l

# 시스템 크론
sudo cat /etc/crontab

# 디렉터리 기반 주기 작업
sudo ls -al /etc/cron.d
sudo ls -al /etc/cron.hourly
sudo ls -al /etc/cron.daily
sudo ls -al /etc/cron.weekly
sudo ls -al /etc/cron.monthly


2) “root로 실행되는 작업”을 최우선으로 추려내기

cron에서 위험도는 권한에 비례합니다. root 크론은 ‘실수 = root 실행’이므로 가장 먼저 점검합니다.

# /etc/crontab 및 /etc/cron.d 하위에서 실행 주체/명령을 빠르게 훑기
sudo awk 'NF && $1 !~ /^#/' /etc/crontab 2>/dev/null || true
sudo grep -R "" -n /etc/cron.d 2>/dev/null | head -n 200

여기서 “누가 소유/관리하는 작업인지(팀/서비스)”와 “실행 파일이 어디에 있는지(절대경로/권한)”를 함께 체크합니다.


3) cron이 보안 문제가 되는 대표 패턴(체크리스트)

  • 쓰기 가능한 경로에서 스크립트 실행: 예) /tmp, 공유 디렉터리, 배포 산출물 디렉터리 권한이 느슨한 경우
  • 상대 경로/불명확한 PATH: cron 환경의 PATH가 예상과 다르면 다른 바이너리를 실행할 수 있음
  • 외부 다운로드를 즉시 실행: 예) curl ... | bash 형태(공급망/변조 리스크)
  • 로그/알림 부재: 실패가 반복되어도 눈치채지 못하고 “조용히 보안/가용성”을 갉아먹음
  • 권한 과다: 굳이 root가 아니어도 되는 작업이 root로 실행

특히 “root + 외부 입력” 조합은 피해야 합니다. 외부 입력이 꼭 필요하다면, 최소 권한 계정으로 분리하고 입력 검증/무결성 검증(해시/서명) 절차를 둡니다.


4) systemd timer로 옮겨야 할 때(감사/가시성 개선)

cron 자체가 항상 나쁜 것은 아니지만, 운영에서 “누가 무엇을 언제 실행했는지”가 명확해야 합니다. systemd timer는 로그가 journal에 일관되게 남고, 실행 단위(서비스)로 권한/격리 옵션을 붙이기 쉬워 감사에 유리합니다.

# 현재 등록된 타이머 확인
systemctl list-timers --all

‘중요한 작업’(백업, 배포, 보안 점검)은 timer로 이전을 검토하고, cron은 단순 작업으로 제한하는 식의 분리가 흔한 운영 패턴입니다.


사례(현장에서 자주 겪는 상황)

  • 로그 청소 스크립트가 root cron으로 돌며 경로 검증 없이 파일 삭제 → 운영 실수로 중요한 로그/설정이 제거될 뻔함
  • 배치 작업이 상대 경로로 실행 → 운영자의 PATH/cron PATH 차이로 다른 바이너리가 실행되어 장애 발생
  • 모니터링/리포트 스크립트가 외부 URL에서 데이터를 받아 처리 → 입력 검증 부재로 오작동/정보노출 위험 증가

트러블슈팅(증상→원인→해결)

  • 증상: 수동 실행은 되는데 cron에서만 실패
    원인: cron 환경(PATH/쉘/작업 디렉터리)이 다름, 상대 경로 사용
    해결: 스크립트/바이너리를 절대경로로 지정하고, 필요한 환경변수(PATH 등)를 cron에 명시
  • 증상: 어떤 cron이 돌아가는지 아무도 모름(알 수 없음)
    원인: /etc/cron.* 및 /etc/cron.d 미점검, 문서/소유자 부재
    해결: 전수 목록화 후 소유팀/목적/만료일을 문서화, 중요 작업은 systemd timer로 이전 검토
  • 증상: 주기적으로 이상 트래픽/CPU 스파이크 발생
    원인: cron 작업이 외부 입력/대량 처리/무한 재시도 등을 수행
    해결: 해당 시간대 cron 실행 로그/출력을 남기도록 하고(로그 리다이렉션), 작업에 타임아웃/리밋/재시도 정책을 추가

푸터: cron은 자동화 도구이지만, 보안 관점에서는 “정기 실행되는 권한 엔진”입니다. root cron부터 점검하고, 상대경로/외부 다운로드/쓰기 가능한 경로 실행 같은 패턴을 제거하면 위험이 크게 줄어듭니다.