auditd는 일이 벌어진 뒤에 생기는 질문에 답합니다. 누가 이 파일을 바꿨는가, 이 사용자는 언제 만들어졌는가, 이 프로세스는 어디서 시작됐는가. 다른 어떤 도구도 그것들에 답하지 않습니다. 애플리케이션 로그에는 그 정보가 없고, 셸 이력은 그것을 남긴 사람이 고칩니다.

어려운 점은 패키지를 설치하는 것만으로는 아무것도 얻지 못한다는 것입니다. 기본 규칙이 사실상 없어 저널은 쓰이지만 내용은 비어 있고, 이 사실은 가장 나쁜 순간에 발견됩니다 — 데이터가 필요한데 없을 때.

설치

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

한 가지 특징. 일부 버전에서는 auditd를 systemctl restart로 재시작할 수 없습니다 — 서비스가 자체 명령으로 관리됩니다. 규칙은 이렇게 다시 읽힙니다.

sudo augenrules --load
sudo auditctl -l

두 번째 명령은 실제로 무엇이 적재됐는지 보여 줍니다. 파일의 내용이 아니라 그것을 믿으세요.

규칙 모음

규칙은 별도 파일로 /etc/audit/rules.d/에 들어갑니다. 아래는 제 몫을 하는 최소한의 모음입니다. 디스크를 파묻지 않으면서 사건 도중에 제기되는 질문의 대부분에 답합니다.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## 사용자와 권한
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## SSH 접근
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## 예약 작업
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## 커널 모듈
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## sudo와 su의 사용
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

문법은 짧습니다. -w는 지켜볼 경로, -p wa는 쓰기와 속성 변경에 반응하라는 뜻, -p x는 실행에, -k는 나중에 검색할 키입니다. 그 키들이 주된 편의입니다. 그것 없이는 저널 검색이 1 GB짜리 텍스트를 뒤지는 일이 됩니다.

그 목록에 없는 것과 그 이유

안내서들은 종종 모든 execve 호출을 — 즉 모든 프로그램의 모든 실행을 — 기록하라고 권합니다. 그 유혹은 이해가 갑니다. 무엇이 이루어졌는지의 완전한 그림이니까요. 실제로는 돌고 있는 서버에서 하루에 수백 메가바이트를 만들고, 프로세서의 눈에 띄는 몫을 먹으며, 저널이 필요해지기 전에 잘려 나가게 만듭니다. 그 수준의 상세함이 필요하다면 좁게 켜세요 — 사용자 한 명에 대해, 또는 조사가 이어지는 동안만.

사이트 디렉터리를 지켜보는 것도 마찬가지입니다. 그 안으로의 쓰기는 끊임없고, 그 규칙은 저널을 의미 없는 이벤트의 흐름으로 바꿔 놓습니다.

읽기

키로 검색하며, 숫자 식별자는 이름으로 풀어서 봅니다.

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

-i 플래그는 가독성에 필수입니다. 그것 없이는 사용자 이름과 시스템 호출 대신 숫자를 받습니다. -ts는 기간을 제한합니다(today, recent, 또는 특정 날짜).

기간에 대한 요약:

sudo aureport --summary -i
sudo aureport --auth -i --failed

이벤트 기록에서 흥미로운 필드가 셋입니다. 세션을 시작한 사용자의 식별자 auid, 행동이 실행된 신원 uid, 그리고 그것을 수행한 프로그램 exe. auid와 uid의 차이가 「정확히 누가 root가 됐는가」에 대한 답입니다. uid=0에 특정 사람의 auid가 붙으면, 세션 안에서 자신을 무엇이라 주장했든 범인이 분명하게 지목됩니다.

디스크

크기 설정은 /etc/audit/auditd.conf에 있습니다.

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

disk_full_action은 따로 보세요. 어떤 구성에서는 디스크가 차면 시스템을 멈추는 것이 기본값입니다 — 감사 요구가 있는 머신에서는 정당하지만 웹 서버에서는 전혀 어울리지 않는 동작입니다. 디스크가 떨어지기 전에 그 값을 확인하세요.

불변 규칙

규칙 파일 끝의 -e 2 줄은 재부팅 전까지 규칙 변경을 금지합니다 — root를 얻은 사람에 대해서도. 그것은 저널의 가치를 눈에 띄게 높입니다. 침입자는 머신을 재부팅하지 않고는 감시를 끌 수 없고, 재부팅은 그 자체로 눈에 띕니다.

뒷면은 명백합니다. 당신 역시 재부팅 없이는 자기 규칙을 바꿀 수 없습니다. 규칙 모음이 자리 잡고 한 달쯤 그것과 함께 살아 본 뒤에 켜세요.

평범한 서버에서 왜 신경 쓰는가

auditd는 아무것도 막지 않습니다. 그 가치는 정확히 한 번 드러납니다 — 사건의 순서를 재구성해야 할 때, 데이터가 있거나 없거나 둘 중 하나입니다. 그것은 소급해서 모을 수 없으며, 그래서 규칙 모음은 미리 자리 잡히고 그 뒤로는 건드리지 않습니다.

설정이 옳다는 실용적 표시는 이렇습니다. 규칙 목록이 비어 있지 않고, 저널이 통제 없이 자라지 않으며, identity와 privileges 키의 이벤트가 드물게 나타나고 각각 설명될 수 있는 것. 그것이 한 페이지에서 어떤 모습인지는 아래 데모에서.