대상 OS: Rocky Linux 9

파일 무결성/변경 감시는 보안 운영의 핵심이지만, 처음부터 범위를 크게 잡으면 로그 폭주와 운영 피로로 금방 포기하게 됩니다. 핵심은 “모든 파일”이 아니라 침해 시 치명도가 큰 파일부터, 작게 시작하는 것입니다.

Rocky Linux 9에서는 (1) 실시간 변경 이벤트는 auditd, (2) 주기적 무결성 스캔은 AIDE 같은 방식으로 역할을 나누면 운영이 수월합니다.

1) 우선순위 파일 선정: ‘변하면 바로 사고’인 것부터

처음에는 10~30개 정도로 좁게 시작하세요.

  • 계정/권한: /etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/
  • SSH: /etc/ssh/sshd_config, /root/.ssh/authorized_keys, 서비스 계정의 authorized_keys
  • 서비스 설정: nginx/apache, 애플리케이션 설정, systemd 유닛/override
  • 스케줄러: /etc/crontab, /etc/cron.*, 사용자 crontab


2) auditd로 ‘변경 이벤트’부터 잡기(실시간 탐지)

auditd는 “누가/언제/어떤 프로세스로/무슨 파일을” 건드렸는지 남기는 데 강합니다.

sudo dnf install -y audit
sudo systemctl enable --now auditd

핵심 파일에 watch 규칙을 겁니다(예: sudoers 변경 감시).

# 즉시 적용(재부팅 시 유지하려면 rules 파일로 관리 권장)
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_changes
sudo auditctl -w /etc/passwd -p wa -k identity_changes
sudo auditctl -w /etc/shadow -p wa -k identity_changes

조회:

# 오늘 발생한 이벤트
sudo ausearch -k sudoers_changes -ts today
sudo ausearch -k sshd_config_changes -ts today


3) 규칙은 파일로 관리해서 재부팅에도 유지

운영에서는 auditctl 즉시 적용만으로는 부족합니다. 규칙 파일로 관리해 변경 이력을 남기고, 서버 재부팅 후에도 동일하게 적용되게 하세요(배포 방식은 환경에 따라 다를 수 있음).

# 규칙 디렉터리 예시 확인
ls -al /etc/audit
ls -al /etc/audit/rules.d 2>/dev/null


4) AIDE로 ‘주기적 무결성 점검’ 추가(베이스라인 기반)

auditd는 “이벤트가 발생한 것”을 기록하지만, 침해자가 로그를 지우거나 특정 시점 이전 변경을 놓쳤을 수 있습니다. 그래서 별도 기준(베이스라인)으로 파일 해시를 비교하는 도구가 도움이 됩니다.

sudo dnf install -y aide

초기 DB(베이스라인) 생성(운영 시간 외 권장):

sudo aide --init
# 생성된 DB를 활성 DB로 이동(경로는 배포에 따라 다를 수 있음)
sudo ls -al /var/lib/aide

검사 실행:

sudo aide --check


5) 운영 포인트: ‘알람 가능한 수준’으로 유지

  • 규칙/대상 파일을 늘리는 기준을 명확히(예: 월 1회 리뷰)
  • 노이즈가 많으면 과감히 축소(운영 가능한 범위가 최우선)
  • 변경 이벤트는 “정상 변경(배포/패치)”과 “비정상 변경”을 구분할 메모/티켓 흐름이 필요


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

  • 운영자가 장애 대응 중 급히 /etc/sudoers를 수정했는데 기록이 남지 않아, 이후 권한 과다 이슈가 장기 방치된다.
  • 침해자가 SSH 설정을 바꾸거나 authorized_keys에 키를 추가해 지속성을 만들고, 나중에 원인 파악이 어려워진다.
  • 감시 대상을 너무 크게 잡아 경보가 과다 발생하고, 결국 알람을 꺼버려 “아무것도 안 보는 상태”가 된다.

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

  • 증상: auditd는 켜져 있는데 이벤트가 조회되지 않음
    원인: watch 규칙이 적용되지 않았거나, 키(-k)로 조회 조건이 맞지 않음
    해결: sudo auditctl -l로 현재 규칙을 확인하고, 다시 추가 후 테스트 변경(예: 파일에 주석 추가 후 원복)로 검증
  • 증상: 이벤트는 많은데 “누가 바꿨는지” 정보가 빈약함
    원인: 감시 방식/규칙이 목적에 맞지 않거나, 로그 보존/포맷 정책이 미흡
    해결: 핵심 파일 위주로 줄이고, 조회 시 ausearch 출력의 pid/auid를 기반으로 추가 추적(필요 시 규칙 정교화)
  • 증상: AIDE 초기화/체크가 너무 오래 걸림
    원인: 검사 범위가 과도하거나, 큰 디렉터리(예: /var 전체)를 포함함
    해결: AIDE 설정에서 범위를 축소하고 “정말 중요한 경로”만 포함, 운영 시간 외 수행
  • 증상: 정상 배포 때마다 알람이 쏟아짐
    원인: 배포가 변경하는 파일을 감시 대상으로 과하게 포함
    해결: 배포 산출물 경로는 제외하거나, 배포 후 베이스라인 갱신 절차(승인/티켓 기반)를 마련

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -