무결성 감시는 안티바이러스도 방화벽도 답하지 않는 질문에 답합니다. 지난주 이후 이 서버에서 무엇이 바뀌었는가. 시그니처 스캐너는 알려진 나쁜 것을 찾고, AIDE는 나쁨에 대해 아무것도 모른 채 이 파일이 어제는 달랐다는 것을 압니다. 기존 파일에 덧붙여진 백도어를 찾는 데는 그것이 통하는 유일한 접근입니다.

AIDE는 명령 둘로 설치됩니다. 보고서를 읽게끔 설정하는 쪽이 더 어려운 부분이고 — 대개 그것 때문에 죽습니다. 첫 보고서가 만 줄로 오고, 두 번째는 아무도 열지 않으며, 한 달 뒤 작업이 지워집니다.

설치와 첫 데이터베이스

sudo apt install aide aide-common
sudo aideinit

초기화는 몇 분에서 반 시간이 걸립니다. 모든 파일에 대해 해시가 계산되니까요. 결과는 .new 접미사가 붙어 작업 데이터베이스 옆에 놓이며, 실제로 쓰이게 만들어야 합니다.

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

그다음부터 확인은 이렇게 실행됩니다.

sudo aide --check

보고서를 읽을 만하게 두려면 무엇을 제외할 것인가

설정은 /etc/aide/aide.conf와 디렉터리 /etc/aide/aide.conf.d/에 있습니다. Debian 기본 설정은 너무 많은 것을 확인하니, 가장 먼저 할 일은 늘 스스로 바뀌는 것을 빼는 일입니다.

  • /var/log — 매초 바뀝니다;
  • /var/lib 전체 — 데이터베이스, 패키지 상태, 서비스 상태;
  • /var/cache, /tmp, /proc, /sys, /run;
  • 사이트의 업로드와 캐시 디렉터리 — 방문자가 그 내용을 바꿉니다.

가장 엄격한 설정으로 확인할 가치가 있는 것은 좁은 목록입니다.

  • /bin, /sbin, /usr/bin, /usr/sbin — 시스템의 실행 파일;
  • /lib, /usr/lib — 라이브러리;
  • /etc — 설정;
  • /root/.ssh와 당신 사용자들의 .ssh 디렉터리;
  • 사이트의 코드, 다만 업로드와 캐시 디렉터리는 빼고.

기준은 이렇습니다. 평범한 일일 보고서는 화면 하나에 들어가야 합니다. 그보다 길다면 제외가 부족한 것이고, 그 보고서는 읽히지 않게 됩니다.

데이터베이스를 어디에 둘 것인가

자주 놓치는 중요한 지점입니다. 다른 누군가에게 root가 있다면 파일을 바꿔치기하고 곧바로 AIDE 데이터베이스를 갱신하는 데 아무 비용도 들지 않습니다 — 그러면 이후의 확인은 모든 것이 괜찮다고 보고합니다. 같은 머신에 쓰기 가능한 상태로 놓인 데이터베이스는 사고에 대해서만 지켜 줍니다.

서버 한 대를 위한 합리적인 최소치:

  • 갱신할 때마다 데이터베이스를 다른 머신으로 복사하고, 확인은 그 사본을 제자리에 놓고 실행하세요;
  • 또는 적어도 데이터베이스의 체크섬을 따로 보관하고 확인 전에 검증하세요:
sha256sum /var/lib/aide/aide.db

그토록 단순한 조치조차 조용한 바꿔치기를 눈에 띄는 사건으로 바꿔 놓습니다.

데이터베이스 갱신은 의식적인 행위다

정당한 변경 뒤에는 — 시스템 업데이트, 사이트의 새 버전 배포 — 데이터베이스를 다시 만듭니다.

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

그것을 언제 하느냐가 중요합니다. 옳은 방식: 보고서를 읽고 모든 변경이 설명 가능함을 확인한 뒤에야 갱신합니다. 그르지만 매우 흔한 방식: 보고서가 깨끗하게 나오도록 aide --update를 일정에 걸어 둡니다. 두 번째 경우에는 시스템이 돌고 보고서는 오지만, 변경은 그것이 일어나는 바로 그 순간에 정상으로 기록됩니다 — 즉 의미가 통째로 사라진 것입니다.

일정과 부하

aide-common 패키지는 일일 작업을 스스로 설치합니다. 확인은 몇 분 동안 디스크와 프로세서에 부하를 주니 한산한 시간에 낮은 우선순위로 돌릴 가치가 있습니다.

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

보고서 읽는 법

세 개의 섹션입니다. 추가된 파일, 삭제된 파일, 바뀐 파일. 각 변경에 대해 정확히 무엇이 다른지 보여 줍니다. 내용, 권한, 소유자, 시각.

먼저 반응해야 할 것:

  • 업데이트 시간대 밖에서 일어난 /bin, /sbin, /usr/bin의 어떤 파일에 대한 변경;
  • 시스템 디렉터리의 새 파일;
  • authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab, /etc/cron.d의 변경;
  • 나타난 파일 /etc/ld.so.preload — 그것은 절대 스스로 나타나지 않습니다.

apt upgrade 직후의 바뀐 파일 백 개는 정상이고, 보고서의 시각이 그것을 확인해 줍니다. 업데이트가 없는 수요일에 /usr/bin의 바뀐 파일 세 개는 멈춰 서서 들여다볼 이유입니다.

AIDE와 debsums

두 도구는 이웃한 문제를 풀지만 그 기준이 다릅니다. AIDE는 당신 자신의 스냅숏과 비교합니다 — 그래서 사이트의 코드를 포함해 어떤 파일의 변경이든 봅니다. debsums는 배포판 패키지의 체크섬과 비교합니다 — 그래서 사전 설정이 전혀 없이도 바꿔치기된 시스템 파일을 보지만, 패키지 밖에서 당신이 설치한 것에 대해서는 아무것도 모릅니다. 둘 다 두는 것이 합리적이며, 실제로는 대개 debsums가 먼저 들어갑니다. 설정도 데이터베이스도 필요 없으니까요.

그리고 두 도구는 약점 하나를 나눠 갖습니다. 보고서는 메일로 오고, 메일은 잃어버립니다. 그러니 중요한 것은 확인이 돌았다는 사실이 아니라 그 최신 결과가 보이는 자리가 있다는 것입니다. 그것이 어떤 모습인지는 아래 데모 페이지에서.