测验：运行时检测

Falco 규칙 한 편에 반드시 있어야 하는 다섯 항목은?

• rule·desc·condition·output·priority 다섯이다
• rule·desc·condition·source·exceptions 다섯이다
• rule·macro·list·condition·output 다섯이다
• rule·condition·output·tags·enabled 다섯이다

cron 이 셸을 띄우고 그 셸이 curl 을 부르는 구조에서 proc.pname 만 보면 안 되는 이유는?

• proc.pname 은 컨테이너 안에서만 값이 채워지고 호스트에서는 비어 있다
• 부모가 셸이라서 cron 에서 나왔다는 사실이 부모 이름에는 안 나타난다
• proc.pname 은 실행 파일 경로라서 이름만으로는 비교가 되지 않는다
• 셸이 exec 로 자기 자신을 대체해 부모 관계가 아예 사라지기 때문이다

falco --validate 에 내 규칙 파일만 주었더니 Undefined macro 'spawned_process' 로 떨어졌다. 올바른 대처는?

• spawned_process 매크로를 내 파일에 똑같이 다시 정의해 둔다
• 그 조건을 빼고 evt.type=execve 를 직접 적어 매크로를 피한다
• 기본 규칙 파일도 함께 --validate 로 주어 같은 조건에서 검증한다
• 검증을 건너뛰고 서비스를 재시작해 로그로 통과 여부를 확인한다

규칙에서 list 와 macro 가 지켜야 하는 순서 규칙은?

• 규칙 뒤에 두어야 하며 앞에 두면 규칙이 먼저 평가돼 무시된다
• 한 파일에 각각 하나씩만 둘 수 있고 여러 개면 마지막 것이 이긴다
• 이름이 알파벳 순서대로 정렬돼 있어야 엔진이 참조를 해결한다
• 자기보다 앞에 정의된 것만 참조할 수 있어 목록·매크로·규칙 순으로 적는다

오탐 하나를 빼려고 condition 끝에 and not proc.cmdline contains backup 을 붙이는 것보다 exceptions 를 쓰는 것이 나은 이유는?

• exceptions 는 조건과 달리 커널에서 평가돼 성능이 크게 좋아진다
• exceptions 로 뺀 사건은 삭제되지 않고 낮은 심각도로 계속 남는다
• 무엇을 왜 뺐는지가 이름과 값으로 드러나고 값만 따로 덮어쓸 수 있다
• 조건에 not 을 붙이면 Falco 가 규칙 전체를 비활성으로 처리한다

systemd 아래에서 기본 출력만 쓰는 Falco 가 탐지 체계로 부족한 이유는?

• 표준 출력은 버퍼가 작아 알림이 많으면 앞부분부터 잘려 나간다
• 알림이 그 호스트의 저널에만 쌓여 호스트가 사라지면 함께 사라진다
• 기본 출력은 규칙 이름만 내보내고 필드 값은 전혀 담지 않는다
• 서비스로 돌면 알림이 파일로만 가고 저널에는 남지 않기 때문이다