026. Linux 서버 보안 — cron·at 접근 제어 점검

changseop lee·5일 전

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 26/50편 (전체 026/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

cron·at은 정해진 시각에 명령을 실행하는 기능입니다. 정상 운영(백업, 로그 정리)에 꼭 필요하지만, 공격자에게는 재부팅·세션 종료 후에도 다시 실행되는 지속성 수단이 됩니다. 지속성 탐지 자체는 기존 31편과 F영역에서 다루고, 여기서는 "누가 예약 작업을 만들 수 있는가" 를 제한하는 하드닝에 집중합니다.

예약 작업이 저장되는 곳
 ├─ 시스템: /etc/crontab, /etc/cron.d/, /etc/cron.{hourly,daily,weekly,monthly}/  (root 관리)
 └─ 사용자: crontab -e
       Rocky : /var/spool/cron/<user>
       Ubuntu: /var/spool/cron/crontabs/<user>

사용자 crontab 사용 허가 판단
 cron.allow 존재? ── 예 → 목록에 있는 사용자만 허용
        └─ 아니오 → cron.deny에 있는 사용자만 거부 (나머지 허용)

2. 왜 중요한가

  • 기본값은 대개 cron.deny만 있어 거의 모든 계정이 crontab을 쓸 수 있습니다. 웹 서비스 계정(apache, www-data)이 탈취되면 바로 예약 작업을 등록할 수 있다는 뜻입니다.
  • cron.allow 방식(허용 목록)으로 바꾸면 서비스 계정의 crontab 등록 시도 자체가 거부 로그로 남습니다.
  • cron 디렉터리 권한이 느슨하면 일반 사용자가 root로 실행될 작업을 추가할 수 있습니다.

3. 핵심 명령어 / 설정

항목권장 상태확인
/etc/cron.allow존재, 관리 계정만cat /etc/cron.allow
/etc/at.allow존재, 관리 계정만cat /etc/at.allow
/etc/crontab600 root:root (CIS 권고)stat -c '%a %U' /etc/crontab
/etc/cron.d, /etc/cron.*700 root:rootstat -c '%a %n' /etc/cron.*
사용자 crontab 목록예상된 계정만sudo ls -l /var/spool/cron/

4. 실습 (실습 예시)

# 1) 허용 목록 방식으로 전환
echo root   | sudo tee /etc/cron.allow
echo admin1 | sudo tee -a /etc/cron.allow
sudo chmod 600 /etc/cron.allow
echo root   | sudo tee /etc/at.allow

# 2) 권한 강화
sudo chmod 600 /etc/crontab
sudo chmod 700 /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# 3) 사용자 crontab 전수 확인 (Rocky / Ubuntu 경로 차이 주의)
sudo ls -l /var/spool/cron/ /var/spool/cron/crontabs/ 2>/dev/null
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | grep -v '^#' | sed "s/^/[$u] /"; done

# 4) 거부 확인: cron.allow에 없는 testuser로 crontab -e 시도

5. 정상 상태

$ sudo ls -l /var/spool/cron/
-rw-------. 1 root root 61 Sep 20 10:00 root
$ for u in ...; do ...; done
[root] 30 3 * * * /usr/local/sbin/backup.sh

사용자 crontab이 root(관리 목적)만 존재하고 내용이 운영 문서와 일치하는 상태가 정상입니다.

6. 이상 상태

$ sudo ls -l /var/spool/cron/
-rw-------. 1 apache apache 58 Oct  1 02:58 apache
-rw-------. 1 root   root   61 Sep 20 10:00 root
$ sudo crontab -l -u apache
*/5 * * * * /var/tmp/.font-unix/fc >/dev/null 2>&1
  • 웹 서비스 계정에 crontab 생성 + 020편에서 발견한 /var/tmp/.font-unix/fc를 5분마다 실행
  • >/dev/null 2>&1로 출력과 에러를 버려 메일 알림·흔적을 남기지 않으려는 패턴

7. 로그 분석 (분석 방법)

cron 관련 로그는 Rocky는 /var/log/cron, Ubuntu는 /var/log/syslog에 남습니다(가상의 예시 로그).

Oct  1 02:58:01 rocky9-web01 crontab[8601]: (apache) BEGIN EDIT (apache)
Oct  1 02:58:09 rocky9-web01 crontab[8601]: (apache) REPLACE (apache)
Oct  1 02:58:09 rocky9-web01 crontab[8601]: (apache) END EDIT (apache)
Oct  1 03:00:01 rocky9-web01 CROND[8650]: (apache) CMD (/var/tmp/.font-unix/fc >/dev/null 2>&1)
Oct  1 10:15:22 rocky9-web01 crontab[9001]: (testuser) AUTH (crontab command not allowed)
메시지의미
BEGIN EDIT → REPLACEcrontab 편집·저장(등록)
CROND ... CMD예약 작업 실제 실행
AUTH (crontab command not allowed)cron.allow/deny 정책으로 거부

crontab -l -u 결과는 현재 상태만 보여주므로, 등록 시각과 최초 실행 시각은 이 로그로 확정합니다.

8. SOC 관제 포인트

  • 서비스 계정의 BEGIN EDIT/REPLACE는 정상 운영에서 거의 없으므로 높은 우선순위로 봅니다.
  • CMD의 실행 경로가 임시 디렉터리·숨김 파일이면 정탐 가능성이 매우 높습니다.
  • AUTH ... not allowed는 허용 목록이 동작했다는 뜻이자, 등록을 시도한 계정이 있다는 뜻입니다.

9. 탐지 규칙

<group name="local,cron,">
  <rule id="100320" level="10">
    <match>REPLACE (</match>
    <regex type="pcre2">crontab\[\d+\]: \((apache|nginx|www-data|mysql|postgres)\) REPLACE</regex>
    <description>서비스 계정 crontab 등록</description>
  </rule>
  <rule id="100321" level="12">
    <match>CMD (</match>
    <regex type="pcre2">CMD \((/tmp/|/var/tmp/|/dev/shm/)</regex>
    <description>임시 디렉터리 실행 파일을 cron이 실행</description>
  </rule>
</group>

괄호 그룹·대체(|)를 쓰는 정규식은 type="pcre2"로 지정합니다(Wazuh 4.3 이상). 적용 전 wazuh-logtest로 매칭을 확인합니다.

10. 대응 방법

  1. 초기 확인 — 비인가 crontab의 등록 시각·계정·실행 명령과 실행 횟수를 확인합니다.
  2. 범위 확인 — 같은 계정·같은 실행 파일이 다른 서버 crontab에 있는지 확인합니다.
  3. 증거 확보 — crontab 파일 사본, cron 로그, 실행 파일 사본을 보존합니다.
  4. 차단/조치 — crontab을 제거(crontab -r -u 계정)하고 cron.allow로 계정을 제한합니다.
  5. 재발 방지 — cron.allow 방식과 사용자 crontab 디렉터리 감시를 표준으로 적용합니다.

11. 핵심 정리

구분핵심 내용
허가 판단cron.allow 있으면 허용 목록, 없으면 cron.deny
사용자 crontab 위치Rocky /var/spool/cron/ · Ubuntu /var/spool/cron/crontabs/
등록 로그BEGIN EDIT → REPLACE → END EDIT
실행·거부 로그CROND CMD / AUTH (crontab command not allowed)
면접 포인트"서비스 계정 crontab + 임시 경로 실행 = 지속성"

12. 다음 편 예고

다음 편 027. Linux 서버 보안 — systemd 서비스 보안 옵션과 systemd-analyze security 에서는 서비스 프로세스 자체를 가두는 systemd 보안 옵션과 systemd-analyze security를 다룹니다.


이전 편: 025. Linux 서버 보안 — 패키지 무결성 검증 — rpm -Va와 debsums
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글