과제 1에서 서비스 구조를, 과제 2에서 네트워크를 만들었다. 둘 다 막는 쪽의 설계였다. 과제 3은 반대쪽이다. 막지 못했을 때 무슨 일이 일어났는지 알아내고, 판단하고, 대응하는 구조를 만든다.
시작할 때 CERT가 정확히 뭘 하는 조직인지도 잘 몰랐다. 조사해 보니 Computer Emergency Response Team, 즉 침해 사고를 탐지하고 대응하는 팀이고, 이 과제는 그 팀이 일하려면 평소에 어떤 인프라가 깔려 있어야 하는가를 만드는 것이었다. 이 문장이 과제 전체의 핵심이었다.
문제 새벽 03:12에 실행된 프로세스는 이미 종료됐다. ps에도 없고 history도 비어 있다.
여기서 배운 게 사후 조사와 상시 수집의 차이다. ps, netstat, history 같은 명령은 전부 지금 이 순간의 상태를 보여 준다. 프로세스가 끝나면 흔적이 사라지고, history는 공격자가 지울 수 있으며, 애초에 대화형 셸이 아니면 남지도 않는다. 사고가 난 뒤에 들어가서 보는 건 이미 지나간 시점을 복원하려는 시도라 한계가 분명했다.
그래서 필요한 게 Endpoint Telemetry, 즉 서버에서 일어나는 행위를 평소에 계속 기록해 두는 것이다. 문제에서 물은 네 가지를 알려면 각각 이런 게 필요했다.
| 알고 싶은 것 | 수집해야 하는 것 | 리눅스에서의 수단 |
|---|---|---|
| 누가 | 인증·권한 상승 기록, UID | auth.log, sudo 로그, auditd |
| 무슨 명령 | 프로세스 실행 이벤트 (실행 파일, 인자, 부모 프로세스) | auditd execve, eBPF |
| 어떤 파일 | 파일 생성·수정·삭제, 무결성 변화 | auditd watch, FIM |
| 어떤 IP | 아웃바운드 연결, 목적지와 포트 | conntrack, eBPF, VPC Flow Logs |
기록할 때 부모 프로세스(PPID)를 같이 남겨야 한다는 점이 인상적이었다. "이상한 프로세스가 실행됐다"보다 "웹 서버 프로세스가 셸을 실행했고 그 셸이 이 프로세스를 실행했다"가 훨씬 많은 걸 말해 준다. 실행 계보가 곧 침투 경로의 단서다.
문제 게다가 공격자가 서버 권한을 가졌으면 기록도 지울 수 있다.