Falco는 Kubernetes를 위한 도구로 알려져 있고, 그에 대한 거의 모든 안내서가 클러스터를 위해 쓰였습니다. 그러나 그것은 클러스터에 묶여 있지 않습니다. 시스템 호출을 지켜보며, 사이트가 있는 평범한 서버에서도 정확히 같은 방식으로 작동합니다. 다만 그 경우에 대해 쓰는 사람이 거의 없을 뿐입니다.

다른 도구들이 침묵하는 자리에서 유용합니다. 사이트의 웹셸은 어떤 권한도 위반하지 않고, 실패한 로그인을 만들지 않으며, 손으로 쓰였다면 어떤 시그니처와도 맞지 않습니다. 그러나 웹 서버로서는 비정상인 행동을 합니다. PHP-FPM 프로세스가 셸을 시작합니다. Falco가 보는 것이 그것입니다.

무엇을 알아채는가

평범한 서버에서의 전형적인 이벤트:

  • 웹 서버나 PHP 프로세스가 낳은 셸 — 사실상 웹셸의 명백한 표시;
  • /tmp, /dev/shm, /var/tmp에서 시작된 프로그램;
  • 그럴 이유가 없는 프로세스가 민감한 파일(/etc/shadow, 개인 키)을 읽는 것;
  • 시스템 바이너리의 수정;
  • 네트워크를 쓰지 않아야 할 프로세스에서 나가는 연결.

설치

핵심 선택은 설치 때 이루어집니다. Falco가 시스템 호출을 어떻게 얻을 것인가. 현대적인 선택지는 eBPF에 기반하며 커널 모듈 빌드도 커널 헤더도 필요로 하지 않습니다.

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

고전적인 커널 모듈은 헤더가 필요하고 커널 업데이트마다 다시 빌드됩니다 — 업데이트가 자동으로 설치되는 서버에서는 그것이 죽은 서비스의 상시적 공급원입니다. 커널이 충분히 새것이라면(5.8 이상) eBPF를 골라 이 문제를 잊으세요.

이벤트가 실제로 오는지 확인하려면:

sudo systemctl status falco
sudo journalctl -u falco -n 50

잡음과 그것을 없애기

이것이 주된 작업입니다. 기본 규칙 모음은 컨테이너 환경을 겨냥하며, 평범한 서버에서는 그 상당 부분이 적용 불가능하거나 끊임없이 걸립니다.

딸려 온 규칙(/etc/falco/falco_rules.yaml)은 편집하지 않습니다 — 그 파일은 업데이트 때 교체됩니다. 당신의 변경은 /etc/falco/falco_rules.local.yaml로 들어가며, 원치 않는 규칙도 거기서 끕니다.

- rule: Terminal shell in container
  enabled: false

컨테이너가 없는 서버에서 대개 손봐야 하는 것:

  • 모든 컨테이너 규칙 — 컨테이너가 없으면 보고서의 자리만 차지합니다;
  • 「Write below etc」 — 패키지를 설치할 때마다, 그리고 당신이 설정 파일을 고칠 때마다 걸립니다. apt, dpkg, unattended-upgrades에 대한 예외가 필요하며, 그러지 않으면 이벤트가 흐름처럼 옵니다;
  • 「Read sensitive file untrusted」 — 모니터링 에이전트, 백업 도구, Lynis 같은 감사 도구에 걸립니다;
  • 임시 디렉터리에서의 실행 — 정당한 예외가 있습니다. 애플리케이션 빌드, 또는 드라이버를 임시 디렉터리에 푸는 자동화된 브라우저. 그런 이벤트는 불안해 보이지만 설명 가능하며, 매번 새로 따지기보다 곧바로 그 구체적인 경로에 대한 예외를 더할 가치가 있습니다.

합리적인 순서는 다른 탐지 도구와 같습니다. 첫 주에는 지켜보며 예외만 더하고, 그다음에야 나타나는 이벤트를 신호로 대하세요. 규칙은 단순합니다 — 보고서에 당신이 읽지 않는 이벤트가 정기적으로 들어 있다면 그것은 당신에게 아무 일도 해 주지 않는 것입니다.

이벤트를 어디로 보낼 것인가

출력은 /etc/falco/falco.yaml에서 설정합니다. 파일, 시스템 저널, 또는 외부 프로그램으로의 파이프. 서버 한 대라면 회전을 붙인 파일로 충분합니다 — 회전을 잊지 마세요. 이벤트 파일은 다른 로그와 마찬가지로 자라며 기본으로는 아무도 지켜보지 않습니다.

우선순위를 써서 나누어 두는 것이 좋습니다. 치명적인 이벤트는 곧바로 눈에 들어오는 자리로, 나머지는 나중에 훑을 일반 저널로.

Falco와 auditd는 같은 것이 아니다

둘 다 시스템 호출을 지켜보지만 목적이 다릅니다. auditd는 나중에 그림을 재구성할 수 있도록 일어나는 일을 기록합니다. 아무것도 평가하지 않고 아무것도 알리지 않으며, 저널을 유지합니다. Falco는 이벤트가 일어나는 순간에 규칙을 적용해 「이것은 수상해 보인다」고 말합니다 — 즉 기록이 아니라 신호를 줍니다.

둘 다 두는 것이 합리적입니다. 재구성을 위한 저널과 반응을 위한 신호. 하나만 골라야 한다면, 사건 뒤에 사건의 순서를 재구성하는 일이 가장 중요한 서버에서는 auditd가 더 유용하고, 돌고 있는 채굴기나 웹셸에 대한 이른 신호를 원한다면 Falco입니다.

작은 서버에 자리를 내줄 가치가 있는가

정직한 답: 늘 그렇지는 않습니다. Falco는 시스템 호출을 처리하며 바쁜 머신에서는 프로세서에 눈에 띕니다. 서버가 사이트 하나를 담고 있고 무결성 감시도 제대로 된 자동 업데이트도 아직 없다면, 여기서 시작할 자리는 아닙니다.

그 순간은 나중에 옵니다 — 기본이 갖춰지고, 로그가 보여 주지 않는 무슨 일이 서버에서 벌어지는가가 남은 질문일 때. 다른 모든 것을 합친 것보다 잘 다루는 이벤트 부류가 하나 있습니다. 웹 서버 프로세스가 시작한 셸. 이벤트가 우선순위와 규칙별로 나뉜 모습은 아래 데모 페이지에서.