대상 OS: Ubuntu Server 24.04 LTS

서버가 뚫렸을 때 가장 무서운 건 ‘당장 안 보이는 변화’다.
바이너리는 살짝 바뀌고, 설정 파일은 미묘하게 수정되고, 크론은 조용히 추가된다.
침입자는 흔적을 지우지만, 운영자는 “원래 뭐였지?”에서 멈춰 서기 쉽다.
그래서 필요한 게 파일 무결성 감시(File Integrity Monitoring)이고, 가장 단단한 출발점이 AIDE다.
이 글은 Ubuntu 24.04에서 AIDE를 설치하고 베이스라인을 만들고, 예외 규칙을 정리하고, 매일 점검과 경보까지 연결하는 절차를 정리한다.

---

AIDE를 언제 쓰면 효과가 큰가

- 단일/소수 서버(또는 이미지 기반 배포)에서 “기준 상태”가 비교적 명확할 때
- 침해사고 대응(IR)에서 “변경된 파일 목록”이 즉시 필요할 때
- 규정/감사에서 무결성 통제를 요구할 때

반대로 컨테이너가 수시로 재배포되고 파일이 자주 바뀌는 환경은 예외 규칙을 잘 짜지 않으면 알람이 폭주한다.

---

1) 설치 전 체크: 무결성 감시의 관측 지점을 정한다

1.

무엇을 “절대 바뀌면 안 되는 것”으로 볼지 먼저 정한다(예: /usr/bin, /usr/sbin, /etc 핵심 파일).

2.

무엇을 “자주 바뀌는 것”으로 볼지 정한다(예: /var/log, /var/lib, 캐시, 런타임 소켓).

3.

AIDE DB(베이스라인)를 어디에 보관할지 정한다.
가능하면 원격(별도 서버/스토리지)로 복사해 두는 게 안전하다(공격자가 로컬 DB까지 바꿀 수 있기 때문).

---

2) Ubuntu 24.04에 AIDE 설치

sudo apt-get update
sudo apt-get install -y aide

설치되면 기본 설정 파일은 보통 아래에 있다.

dpkg -L aide | grep -E 'aide\.conf$' || true
ls -l /etc/aide /etc/aide/aide.conf 2>/dev/null || true

Ubuntu 패키지 구성에 따라 경로가 조금 다를 수 있으니, 실제 파일 위치를 먼저 확인하고 진행하자.

---

3) 베이스라인(초기 DB) 생성: “깨끗한 시점”에서만 한다

중요: 베이스라인은 ‘정상 상태의 스냅샷’이다. 감염/오염된 상태에서 만들면 그게 기준이 되어버린다.
가능하면 다음 조건을 만족한 시점에 수행한다.

- OS 설치 직후 또는 신뢰 가능한 이미지로 프로비저닝 직후
- 패키지 업데이트/필수 설치 완료 후
- 서비스 구성 완료 후

1.

초기화 실행.

sudo aideinit

2.

초기 DB가 생성되면 보통 새 DB 파일이 만들어지고, 이를 운영용 DB 위치로 “승격”시키는 단계가 필요하다.
(패키지 기본값에 따라 파일명이 다를 수 있다.)

sudo ls -l /var/lib/aide 2>/dev/null || true
sudo find /var/lib/aide -maxdepth 1 -type f -ls 2>/dev/null || true

3.

일반적으로는 `aide.db.new` → `aide.db`로 옮긴다(실제 파일명은 위 출력에 맞춰 조정).

# 예시: 경로/파일명은 환경에 맞게 확인 후 실행
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

---

4) 어떤 규칙을 적용할지: “신호 대비 잡음”을 설계한다

AIDE는 감시 대상이 넓을수록 좋지만, 운영에서는 잡음이 곧 무시로 이어진다.
그래서 초기에 아래 3단으로 나누면 관리가 쉬워진다.

- Tier 1(강): /etc 핵심, /usr/bin, /usr/sbin 등은 강하게
- Tier 2(중): /boot, /lib/modules 같은 커널 관련은 변경 시점이 명확할 때만
- Tier 3(약/제외): /var/log, /tmp, /run 등은 대부분 제외 또는 제한적으로

1.

현재 설정을 먼저 백업한다.

sudo cp -a /etc/aide/aide.conf /etc/aide/aide.conf.bak.$(date +%F-%H%M%S) 2>/dev/null || true

2.

자주 바뀌는 디렉터리를 제외 규칙으로 넣는다(예시).

# 예시: /etc/aide/aide.conf 편집(에디터는 원하는 걸로)
sudo editor /etc/aide/aide.conf

편집 시 아이디어(예시)만 제시한다. 실제 문법/섹션은 배포판 기본 aide.conf를 따르자.

- `/var/log`는 로테이션으로 계속 바뀐다 → 제외 또는 최소 체크
- `/var/lib/docker`, `/var/lib/containerd`는 컨테이너가 바뀔 때마다 변한다 → 제외 권장
- `/etc`는 핵심이지만, 자동화 도구가 자주 만지는 파일(예: resolv.conf)은 예외로 분리

3.

설정 수정 후에는 “DB 재생성”이 아니라 “정상 변경 승인” 프로세스로 관리한다.
즉, 변경이 정상이라면 해당 변경 후 `aideinit`로 새 기준을 만들고, 그 새 DB를 안전하게 보관한다.

---

5) 일일 점검: 크론/타이머로 ‘꾸준히’ 돌린다

1.

AIDE 체크를 수동으로 실행해 본다.

sudo aide --check

2.

결과가 길면 파일로 저장한다.

sudo aide --check | sudo tee /var/log/aide-check-$(date +%F).log >/dev/null

3.

systemd timer로 매일 새벽에 돌리고 싶다면, 전용 유닛을 만들어 관리하는 방식이 깔끔하다.

sudo tee /etc/systemd/system/aide-check.service >/dev/null /dev/null || true
# 생성된 새 DB를 운영용 DB로 반영(환경에 맞게 파일명 확인 후 적용)

핵심: 이 과정을 문서화해두면, 침해사고 시점에도 “무엇이 정상 변경이었는지”가 빨리 정리된다.

---

마무리

Ubuntu Server 24.04에서 AIDE는 화려하지 않지만, 사고 대응에서 효율을 폭발적으로 올려주는 도구다.
정상 상태의 베이스라인을 만들고, 잡음이 적은 규칙으로 시작하고, 매일 자동 점검을 걸어두면,
침입 흔적이 “느낌”이 아니라 “차이(diff)”로 보이기 시작한다.
다음 단계로는 AIDE DB/리포트를 원격 저장소로 자동 복사하고, 중앙 로그/알림(SIEM/ChatOps)과 연결하면 완성도가 올라간다.