cron 이 새벽 세 시에 curl 을 했다

이 실습은 VM 에서 돕니다

우분투 24.04 VM 한 대에 Falco 가 modern eBPF 드라이버로 이미 떠 있습니다.
시스콜 계측은 커널 기능이라 실습 파드에서는 아예 불가능합니다. 뜨는 데
2~3분 걸립니다(Falco 를 설치하기 때문입니다).

목표

제목의 사건을 잡는 규칙을 직접 씁니다. 목록과 매크로를 나누고, 알림을 JSON
파일로 남기고, 실제로 예약 작업을 심어 규칙이 잡는 것을 파일에서 확인합니다.
그다음 같은 규칙에 걸리는 정상 작업을 하나 더 만들어 그것만 예외로 빼고,
나쁜 것은 계속 잡히는지 다시 확인합니다.

왜 중요한가

로그 기반 탐지에는 구조적인 한계가 있습니다. 로그는 프로그램이 남기기로 한
것만 남습니다. 시스콜은 다릅니다 — 프로세스를 만들든 파일을 열든 커널을 거쳐야
하고, 커널을 속일 수는 없습니다.

그런데 시스콜을 다 보면 알림이 너무 많아집니다. 그래서 런타임 탐지의 실제
작업은 "무엇을 잡을까" 가 아니라 "무엇을 빼도 되는가" 입니다. 규칙 하나가
정상 백업 작업까지 잡으면 며칠 만에 아무도 알림을 안 봅니다. 그때 규칙을
넓게 고치면 진짜 사건도 함께 빠집니다. 예외를 좁게, 이유를 적어서 두는
습관이 탐지 체계의 수명을 정합니다.

단계

1. Falco 의 판·드라이버·서비스 상태를 /root/falco/01-engine.txt 에 저장하세요.
2. /etc/falco/rules.d/labhub-cron.yaml 에 list 하나, macro 하나, rule 하나로 규칙을 쓰세요. 출력에 %user.name 과 %proc.cmdline 이 들어가야 합니다.
3. /etc/falco/config.d/labhub-output.yaml 에 JSON 출력과 파일 출력(/var/log/falco/events.json)을 켜고 서비스를 다시 시작하세요.
4. /etc/cron.d/telemetry 를 만들어 매분 바깥으로 요청하게 하세요.
5. 1분 이상 기다렸다가 잡힌 알림 한 줄을 /root/falco/05-alert.json 에 저장하세요.
6. /etc/cron.d/backup-sync 를 만들어 같은 규칙에 걸리는 정상 작업을 하나 더 두고, 그것만 규칙의 exceptions 로 뺀 뒤 서비스를 다시 시작하세요.
7. events.json 을 비운 뒤 예약 작업이 한 번 돌 때까지 기다려, 정상 작업은 안 잡히고 나쁜 것은 잡히는지 /root/falco/07-verify.txt 에 확인하세요.
8. 규칙의 근거를 /root/falco/08-report.md 에 ## 무엇을 잡는가·## 왜 예외를 두었나·## auditd 와 무엇이 다른가·## 다음에 넓힐 곳 네 절로 쓰세요.

참고

• 규칙 검증은 falco --validate /etc/falco/falco_rules.yaml --validate <내 파일> 로 합니다. 기본 규칙 파일을 함께 주어야 합니다 — spawned_process 같은 매크로가 그쪽에 정의돼 있습니다.
• cron 이 셸을 띄우고 그 셸이 명령을 부르므로 부모는 셸입니다. 조상을 보려면 proc.aname[2] 처럼 씁니다.
• 서비스 이름은 falco 지만 실제 유닛은 드라이버에 따라 다릅니다. systemctl show -p Id --value falco 로 확인하고 저널은 그 이름으로 봅니다.
• 예약 작업은 매분 돕니다. 기다리는 일은 단계로 나눠 두었으니 채점을 서두르지 마세요.
• 흔한 실수: 예외를 condition 끝에 and not … 으로 녹여 버리는 것. 6개월 뒤에 아무도 그 조각의 이유를 모릅니다.
• 흔한 실수: 예외를 너무 넓게 잡아 규칙 전체가 조용해지는 것. 7단계가 그것을 잡아 줍니다.

단계 8개

1. 무엇이 어떤 드라이버로 도는가
2. 규칙 한 편을 쓴다
3. 알림을 파일에 남긴다
4. 사건을 심는다
5. 잡혔는지 파일에서 본다
6. 정상 하나를 좁게 뺀다
7. 둘 다 다시 돌려 본다
8. 규칙의 근거를 남긴다