คู่มือ Falco ฉบับสมบูรณ์: Runtime Security สำหรับ Kubernetes ด้วย eBPF ปี 2026

เอาตรง ๆ นะครับ ในปี 2026 ถ้าทีมคุณยังพึ่งแค่ image scan กับ RBAC อย่างเดียว แล้วบอกว่า Kubernetes คลัสเตอร์ปลอดภัยแล้ว ผมขอเตือนเลยว่า ไม่พอแน่นอน เพราะเมื่อผู้โจมตีหลุดผ่าน Admission Control เข้ามาได้ (ซึ่งเกิดขึ้นบ่อยกว่าที่คิด) สิ่งเดียวที่จะตรวจจับพฤติกรรมแปลก ๆ ภายในพ็อดได้ก็คือ Runtime Security และเครื่องมือที่ครองตลาด Open Source ในด้านนี้แบบทิ้งห่างคู่แข่งก็คือ Falco ซึ่งเป็นโครงการระดับ Graduated ของ CNCF โดยใช้ eBPF ดักจับ system call ทุกตัวที่เกิดขึ้นบน node

คู่มือนี้จะพาคุณติดตั้ง Falco v0.43 (ออกเดือนมกราคม 2026) บน Kubernetes ด้วย Helm, เขียน Custom Rules ตรวจจับ Reverse Shell และ Crypto Mining, ตั้งค่า Falcosidekick ส่งแจ้งเตือนเข้า Slack/PagerDuty รวมถึงเปรียบเทียบกับ Tetragon เพื่อช่วยให้คุณตัดสินใจได้ว่าควรเลือกตัวไหนใน Production

ทำไม Runtime Security ถึงสำคัญในปี 2026

การป้องกันแบบ Static เช่นการสแกน image ด้วย Trivy หรือบังคับใช้ Pod Security Admission เป็นแค่ด่านแรกเท่านั้นครับ พอพ็อดทำงานจริงแล้ว สิ่งต่อไปนี้ ไม่มีทางโผล่ใน image scan:

• ผู้โจมตีใช้ช่องโหว่ Zero-day เพื่อ exec เข้าไปในคอนเทนเนอร์ที่กำลังรันอยู่
• มัลแวร์ดาวน์โหลด binary ใหม่ลง /tmp แล้วรันจาก memory (เทคนิค fileless attack ที่กำลังมาแรง)
• การเชื่อมต่อ outbound ไปยัง C2 server หรือ Crypto Mining Pool
• การอ่านไฟล์อ่อนไหวอย่าง /etc/shadow หรือ Kubernetes service account token
• Container Drift หรือการรัน executable ที่ไม่ได้อยู่ใน original image ตั้งแต่แรก

RBAC จับไม่ได้ Network Policy จับไม่ได้ Image Scanner ก็จับไม่ได้ เพราะพฤติกรรมที่อันตรายมันเกิดขึ้น หลัง จากที่พ็อดถูก admit เข้าคลัสเตอร์ไปแล้ว Falco คือกล้องวงจรปิดที่คอยมองทุก syscall บน node เพื่อตอบคำถามเดียวคือ "ตอนนี้คอนเทนเนอร์ของฉันกำลังทำอะไรอยู่จริง ๆ"

ผมเคยเจอเคสที่ลูกค้ารายหนึ่งเชื่อมั่นใน Trivy + OPA Gatekeeper มาก จนวันหนึ่งมีพ็อดถูก hijack ไปขุด Monero อยู่สามวันโดยไม่มีใครรู้ พอเปิด Falco ปุ๊บ มันแจ้งเตือนภายในไม่กี่วินาที บทเรียนคือ — Static + Runtime ต้องคู่กันเสมอ

Falco คืออะไร และทำงานยังไง

Falco เป็นเครื่องมือ Cloud Native Runtime Security ที่ Sysdig สร้างขึ้นและบริจาคให้ CNCF จนได้สถานะ Graduated ในปี 2024 หลักการทำงานสรุปสั้น ๆ ก็แค่ 4 ขั้น:

1. Capture system calls ผ่าน eBPF probe หรือ kernel module
2. Enrich events ด้วย metadata จาก Kubernetes API (namespace, pod, image, label)
3. Evaluate ทุกเหตุการณ์เทียบกับ rule engine ที่เขียนเป็น YAML
4. Output ส่งการแจ้งเตือนไปยัง stdout, syslog หรือ Falcosidekick

เวอร์ชันล่าสุดคือ v0.43.0 รองรับสถาปัตยกรรม x86_64 และ aarch64 รวมถึงทำงานได้บน GKE, EKS, AKS รวมถึง on-premise (ผมเทสบน k3s บน Raspberry Pi 5 ก็ยังรันได้นะ — น่าทึ่งดี)

eBPF vs Kernel Module: ทำไม eBPF ถึงเป็นทางเลือกที่ถูกต้อง

Falco มี driver สามแบบให้เลือก แต่ในปี 2026 บอกตามตรงเลยว่า ทางเลือกที่ถูกต้องเกือบทุกกรณีคือ Modern eBPF:

Driver	Kernel ที่รองรับ	ข้อดี	ข้อเสีย
modern_ebpf	5.8+	ไม่ต้องคอมไพล์, รองรับ CO-RE, โหลดเร็วที่สุด	ต้องการ kernel ใหม่
ebpf (legacy)	4.14+	รองรับ kernel เก่ากว่า	Deprecated ตั้งแต่ v0.43.0
kmod	ทุกเวอร์ชัน	ทำงานได้แม้ไม่มี eBPF	ต้องคอมไพล์, ปัญหา Secure Boot, มี overhead 5-10%

เหตุผลหลักที่ควรใช้ eBPF (จริง ๆ มีมากกว่านี้ แต่นี่คือ 4 ข้อสำคัญที่สุด):

• ความปลอดภัยของ kernel — eBPF program ทำงานใน sandbox ของ kernel verifier ทำให้ ไม่สามารถทำให้ kernel crash ได้แม้เขียน rule ผิด
• ไม่ต้องเซ็น module — ใช้งานบน GKE Container-Optimized OS หรือ EKS Bottlerocket ที่เปิด Secure Boot ได้ทันที (ไม่ต้องไปนั่งหา MOK key ให้ปวดหัว)
• Overhead ต่ำมาก — แค่ 1-3% CPU เทียบกับ kmod ที่อยู่ที่ 5-10%
• CO-RE (Compile Once, Run Everywhere) — binary เดียวรันได้บนทุก kernel โดยไม่ต้องมี kernel headers

การติดตั้ง Falco บน Kubernetes ด้วย Helm

ขั้นตอนที่ 1: เพิ่ม Falco Helm Repository

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm search repo falcosecurity/falco --versions | head -5

ขั้นตอนที่ 2: ติดตั้ง Falco พร้อม Modern eBPF

คำสั่งติดตั้งแบบ Production-ready ที่เปิด JSON output (จำเป็นสำหรับ Falcosidekick) และเปิด collector สำหรับ containerd:

helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set collectors.containerd.enabled=true \
  --set collectors.docker.enabled=false \
  --set falco.json_output=true \
  --set falco.json_include_output_property=true \
  --set falco.log_stderr=true \
  --set falco.log_syslog=false \
  --set tty=true

ขั้นตอนที่ 3: เลือก Driver ตามสภาพแวดล้อม

# Kernel 5.8+ (แนะนำในปี 2026)
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=modern_ebpf

# Kernel 4.14+ (legacy eBPF, deprecated แต่ยังใช้ได้)
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf

# กรณี eBPF ใช้ไม่ได้ (เช่น kernel เก่ามาก)
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=kmod

ขั้นตอนที่ 4: ตรวจสอบการติดตั้ง

# ตรวจสอบว่า Falco DaemonSet รันครบทุก node
kubectl get pods -n falco -o wide

# ดู log ของ Falco
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50

# ยืนยันว่าโหลด modern eBPF probe สำเร็จ
kubectl logs -n falco daemonset/falco | grep -i "driver"
# คาดว่าจะเห็น: Driver loaded: modern_ebpf

การทดสอบการตรวจจับ

มาทดสอบกันว่า Falco ตรวจจับการ kubectl exec ได้จริงหรือเปล่า ซึ่งเป็นพฤติกรรมที่น่าสงสัยมาก ๆ ใน Production pod:

# สร้าง test pod
kubectl run falco-test --image=nginx:1.27 --restart=Never

# รอให้พ็อดพร้อม
kubectl wait --for=condition=ready pod/falco-test --timeout=60s

# Exec เข้าไป trigger alert
kubectl exec -it falco-test -- /bin/bash -c "whoami"

# ดู alert ใน Falco log
kubectl logs -n falco -l app.kubernetes.io/name=falco \
  | grep -i "Terminal shell" | tail -5

คุณควรเห็น output คล้ายแบบนี้:

{"output":"23:14:02.123456789: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 container_id=abc123 image=nginx:1.27 shell=bash parent=runc cmdline=bash -c whoami terminal=34816 container_name=falco-test)","priority":"Notice","rule":"Terminal shell in container"}

การเขียน Custom Rules

Falco ส่งมาพร้อม rule กว่า 90 ตัวก็จริง แต่ภัยคุกคามเฉพาะของแอปคุณ มันต้องเขียน rule เองครับ ไม่มีทางหนีพ้น โครงสร้าง rule ประกอบด้วย condition, output, priority, และ tags ครบ 4 ส่วน

ตัวอย่างที่ 1: ตรวจจับ Reverse Shell

- rule: Reverse Shell Detected
  desc: ตรวจจับการเชื่อมต่อ outbound จาก shell process ในคอนเทนเนอร์
  condition: >
    evt.type=connect and evt.dir=< and container and
    (proc.name in (bash, sh, zsh, dash, ash) or
     proc.name in (nc, ncat, netcat, socat))
  output: >
    Reverse shell detected
    (user=%user.name command=%proc.cmdline
     container=%container.name pod=%k8s.pod.name
     namespace=%k8s.ns.name fd=%fd.name)
  priority: CRITICAL
  tags: [reverse_shell, mitre_command_and_control, T1059]

ตัวอย่างที่ 2: ตรวจจับ Crypto Mining

- rule: Crypto Mining Process Detected
  desc: ตรวจจับ process ที่เกี่ยวข้องกับ Cryptocurrency Mining
  condition: >
    spawned_process and container and
    (proc.name in (xmrig, minerd, cpuminer, cgminer, bfgminer, ethminer)
    or proc.cmdline contains "stratum+tcp"
    or proc.cmdline contains "stratum+ssl"
    or proc.cmdline contains "--donate-level")
  output: >
    Crypto miner detected
    (user=%user.name command=%proc.cmdline
     container=%container.name pod=%k8s.pod.name
     namespace=%k8s.ns.name image=%container.image.repository:%container.image.tag)
  priority: CRITICAL
  tags: [crypto, mining, mitre_impact, T1496]

ตัวอย่างที่ 3: Container Drift Detection (Fileless Attack)

- rule: Container Drift Detected via memfd
  desc: ตรวจจับ executable ที่รันจาก memory (ไม่ได้อยู่ใน image เดิม)
  condition: >
    spawned_process and container and proc.is_exe_from_memfd = true
  output: >
    Container drift detected - executable from memory
    (container_id=%container.id container_name=%container.name
     image=%container.image.repository:%container.image.tag
     k8s_namespace=%k8s.ns.name k8s_pod=%k8s.pod.name
     user=%user.name process=%proc.name cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [container_drift, mitre_defense_evasion, T1611]

ตัวอย่างที่ 4: ตรวจจับการอ่านไฟล์อ่อนไหว

- list: sensitive_files
  items:
    - /etc/shadow
    - /etc/sudoers
    - /root/.ssh/id_rsa
    - /var/run/secrets/kubernetes.io/serviceaccount/token
    - /var/lib/kubelet/pki/kubelet-client-current.pem

- rule: Read Sensitive File in Container
  desc: แจ้งเตือนเมื่อมีการอ่านไฟล์ลับใน Kubernetes pod
  condition: >
    open_read and container and fd.name in (sensitive_files)
    and not proc.name in (kubelet, kube-proxy)
  output: >
    Sensitive file read inside container
    (user=%user.name file=%fd.name proc=%proc.name
     container=%container.name pod=%k8s.pod.name
     namespace=%k8s.ns.name)
  priority: WARNING
  tags: [filesystem, mitre_credential_access, T1552]

การ Deploy Custom Rules ผ่าน Helm

วิธีที่ดีที่สุดในการ deploy custom rules ก็คือใส่ผ่าน Helm customRules เลย ไม่ต้องไปแก้ ConfigMap เอง:

# custom-values.yaml
customRules:
  custom-runtime-rules.yaml: |-
    - list: shell_binaries
      items: [bash, sh, zsh, ash, dash, csh, tcsh, ksh, fish]

    - rule: Reverse Shell Detected
      desc: ตรวจจับ reverse shell ใน container
      condition: >
        evt.type=connect and evt.dir=< and container and
        proc.name in (shell_binaries, nc, ncat, netcat)
      output: >
        Reverse shell (user=%user.name cmd=%proc.cmdline
        pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: CRITICAL
      tags: [reverse_shell, mitre_execution]

helm upgrade falco falcosecurity/falco \
  --namespace falco -f custom-values.yaml --reuse-values

Falcosidekick: ส่ง Alert ไปยัง Slack, PagerDuty และ SIEM

Falco แค่เขียน log อย่างเดียวมันไม่พอครับ คุณต้อง route alert ไปยังช่องทางที่ทีมมองเห็นจริง ๆ ไม่งั้นก็เปล่าประโยชน์ Falcosidekick ทำหน้าที่นี้พร้อม integration กว่า 50 destination เลยทีเดียว:

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/..." \
  --set falcosidekick.config.slack.minimumpriority="warning" \
  --set falcosidekick.config.pagerduty.routingkey="YOUR_PD_KEY" \
  --set falcosidekick.config.pagerduty.minimumpriority="critical" \
  --set falcosidekick.config.elasticsearch.hostport="https://es.internal:9200" \
  --set falcosidekick.config.elasticsearch.index="falco" \
  --reuse-values

กลยุทธ์การ routing ที่ผมแนะนำในปี 2026 (จากประสบการณ์ที่เคยตั้งให้ลูกค้าหลายราย):

• CRITICAL → PagerDuty (ปลุกทีม on-call ทันที — อย่าเสียดาย!)
• WARNING → Slack (channel #sec-alerts)
• NOTICE/INFO → Elasticsearch / SIEM สำหรับการวิเคราะห์ย้อนหลัง
• ทุกระดับ → ส่งสำเนาเข้า S3/GCS เก็บ 90 วันเป็นอย่างน้อยตามนโยบาย compliance

Falco vs Tetragon: เลือกอะไรในปี 2026

คำถามที่โดนถามบ่อยที่สุด (จริง ๆ ทุกครั้งที่พูดถึงเรื่องนี้) คือ "ใช้ Falco หรือ Tetragon ดี" คำตอบสั้น ๆ ของผมคือ ใช้ทั้งคู่ถ้าทำได้ เพราะแต่ละตัวมีจุดแข็งคนละแบบ:

คุณสมบัติ	Falco	Tetragon
บทบาทหลัก	Detection & Alerting	Detection + Enforcement
เปรียบเทียบ	กล้องวงจรปิด — แจ้งเตือนหลังเหตุการณ์	การ์ดประตู — บล็อกการกระทำก่อนเกิด
Kubernetes Awareness	ต้องเขียน rule เอง	เข้าใจ label/namespace ตั้งแต่ต้น
Performance Overhead	5-10% (legacy), 1-3% (modern eBPF)	<1% (kernel-side filtering)
False Positive	สูงถ้าไม่ tune	ต่ำกว่า เพราะ filter ใน kernel
ขนาด Community	ใหญ่กว่า, CNCF Graduated	ใหม่กว่า, CNCF Incubating
เขียน Policy	YAML rule ดั้งเดิม	Kubernetes CRD (TracingPolicy)

คำแนะนำส่วนตัว:

• เริ่มต้น = Falco (ติดตั้งง่าย, ecosystem ใหญ่, rule สำเร็จรูปเยอะ)
• ต้องการ enforcement = เพิ่ม Tetragon ในภายหลัง
• คลัสเตอร์ขนาดใหญ่ที่มี syscall เยอะมาก = Tetragon ช่วยลด overhead
• Cross-cloud / SaaS detection = Falco เพราะรองรับ AWS, GCP, Azure, Okta, GitHub plugin ครบ

การ Tuning เพื่อลด False Positives

เรื่องนี้สำคัญมาก ๆ การติดตั้ง Falco วันแรกมักจะได้ alert วันละพันรายการจน on-call หมดศรัทธาในระบบไปเลย (ผมเคยเจอเคสที่ทีม security ปิด Slack channel ไปเลยเพราะเสียงเตือนดังตลอดเวลา) การ tune จึงเป็นขั้นตอนที่สำคัญที่สุดหลังการติดตั้ง

ใช้ Exceptions แทนการ Disable Rule

- rule: Terminal shell in container
  exceptions:
    - name: monitoring_pods
      fields: [k8s.ns.name, k8s.pod.label.app]
      values:
        - [monitoring, prometheus-node-exporter]
        - [monitoring, datadog-agent]
        - [logging, fluent-bit]

Override priority แทนการลบ rule

- rule: Read environment variable from /proc files
  priority: INFO   # ลดจาก WARNING เพราะมี Java app เยอะ
  append: false

Monitor Event Drops

ถ้าค่า falco_drops_total ใน Prometheus เพิ่มขึ้นเรื่อย ๆ แสดงว่า node ส่ง syscall เยอะเกินกว่า Falco จะประมวลผลทัน (อาการคือ alert บางตัวจะหายไปเฉย ๆ น่ากลัวมาก) วิธีแก้:

• เพิ่ม CPU limit ของ Falco DaemonSet (default 1 CPU มักจะไม่พอใน production)
• ปิด rule ที่ไม่จำเป็นต่อ threat model ของคุณ
• ใช้ buffered_outputs: true เพื่อเพิ่ม throughput

kubectl exec -n falco daemonset/falco -- \
  curl -s localhost:8765/metrics | grep falco_drops_total

การอัปเดต Rules อย่างต่อเนื่องด้วย falcoctl

Falco แยก rule update ออกจาก chart เพื่อให้รับ rule ใหม่ได้โดยไม่ต้อง restart pod ตั้ง CronJob ให้รัน:

falcoctl artifact install falco-rules --refresh
falcoctl artifact install falco-incubating-rules --refresh

หรือเปิด auto-update ผ่าน Helm ก็ได้ (ทำครั้งเดียว ลืมไปได้เลย):

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set falcoctl.artifact.follow.enabled=true \
  --set falcoctl.artifact.install.enabled=true \
  --reuse-values

Production Readiness Checklist

ก่อนประกาศใช้งาน Falco บน production cluster อย่าลืมตรวจสอบรายการต่อไปนี้ให้ครบ (อันนี้คือ checklist ที่ผมใช้จริงทุกโปรเจกต์):

• ☐ Falco DaemonSet รันบน node ทุกตัว (รวม node pool ใหม่ที่ scale-up ด้วย)
• ☐ Modern eBPF probe โหลดสำเร็จ ไม่มี fallback ไป kmod
• ☐ JSON output เปิด เพื่อให้ SIEM parse ได้
• ☐ Custom rules deploy ผ่าน GitOps (ArgoCD/Flux) ไม่ใช่ kubectl apply ตรง ๆ
• ☐ Falcosidekick route CRITICAL → PagerDuty, WARNING → Slack
• ☐ Allowlist macro เขียนไว้สำหรับ monitoring stack เพื่อลด noise
• ☐ Triage runbook เขียนเสร็จและทดสอบจริงด้วย Tabletop Exercise
• ☐ False positive rate วัดได้ < 5 alert ต่อวันต่อคลัสเตอร์
• ☐ Retention: audit log ≥ 90 วัน, Falco event ≥ 30 วัน
• ☐ Prometheus monitor falco_drops_total และ alert ถ้ามี drop
• ☐ falcoctl auto-update เปิดใช้งานเพื่อรับ rule ใหม่
• ☐ ทดสอบ chaos engineering: รัน reverse shell จำลอง ดูว่า PagerDuty โทรหา on-call จริงไหม

คำถามที่พบบ่อย (FAQ)

Falco ทำงานบน managed Kubernetes เช่น GKE, EKS, AKS ได้ไหม

ได้ครบทุกตัวครับ แต่ ต้องใช้ modern eBPF driver เท่านั้น เพราะ managed control plane ทุกตัวใช้ hardened OS image ที่บล็อกการโหลด unsigned kernel module ถ้าใช้ kmod จะ fail บน GKE Container-Optimized OS, EKS Bottlerocket และทุก node ที่เปิด Secure Boot

Falco overhead เท่าไหร่ใน Production

ภายใต้ workload ปกติ Modern eBPF probe กิน CPU ประมาณ 1-3% ต่อ node ส่วน RAM ประมาณ 200-400 MB ถ้าคลัสเตอร์มี syscall rate สูงมาก (เช่น node ที่รัน thousands of short-lived containers แบบ batch jobs) ตัวเลขอาจขึ้นไป 5-7% ทางที่ดีคือ benchmark ใน staging ก่อน production เสมอ

Falco ป้องกันการโจมตี Zero-day ได้หรือไม่

Falco ไม่ได้ ป้องกัน zero-day โดยตรง แต่ตรวจจับ พฤติกรรมหลังการโจมตี ได้ดีมาก เพราะถึงผู้โจมตีจะใช้ช่องโหว่ที่ไม่มีใครเคยรู้จักมาก่อน แต่พอได้ shell แล้วก็ยังต้องทำสิ่งเหล่านี้: spawn shell, อ่านไฟล์ลับ, เชื่อมต่อ outbound, escalate privilege ซึ่งทั้งหมดถูกตรวจจับด้วย default rule ของ Falco อยู่แล้ว

ความแตกต่างระหว่าง Falco และ Wazuh คืออะไร

Wazuh เป็น HIDS/SIEM ครบวงจรที่เน้นการตรวจสอบ host-level เช่น file integrity, log analysis, vulnerability assessment ส่วน Falco เน้น container/Kubernetes runtime โดยเฉพาะผ่าน syscall monitoring ในสภาพแวดล้อม cloud-native ที่มีทั้ง VM และ Kubernetes คุณควรใช้ Wazuh สำหรับ host และ Falco สำหรับ container โดยส่ง output ของทั้งสองเข้า SIEM เดียวกันเพื่อ correlate event

ใช้ Falco แทน Tetragon ได้ไหม

ได้ในงาน detection ล้วน ๆ แต่ Tetragon มี enforcement ที่ Falco ทำไม่ได้ เช่น kill process, block syscall ใน kernel ถ้าความต้องการของคุณคือ หยุด การโจมตี ไม่ใช่แค่ตรวจจับ ก็ควรเพิ่ม Tetragon คู่กับ Falco แต่ถ้าทรัพยากรจำกัด เริ่มที่ Falco ก่อน เพราะ ecosystem ใหญ่กว่า ติดตั้งและ tune ง่ายกว่ามาก

สรุป

ในปี 2026 Runtime Security ไม่ใช่ตัวเลือกอีกต่อไป แต่เป็นความจำเป็นพื้นฐานของ Kubernetes cluster ทุกระดับครับ Falco v0.43 พร้อม modern eBPF driver ทำให้คุณติดตั้งและตรวจจับภัยคุกคามได้ภายในไม่กี่นาที โดยมี overhead เพียง 1-3% และไม่ต้องคอมไพล์ kernel module ให้ปวดหัว เริ่มต้นด้วย default rule, เขียน custom rule สำหรับ threat model เฉพาะของคุณ, ส่ง alert ผ่าน Falcosidekick เข้า PagerDuty/Slack และอย่าลืม tune false positive ให้อยู่ในเกณฑ์ที่ on-call ทำงานต่อได้จริง

ขั้นต่อไป ลองอ่านคู่มือ Wazuh IDS/SIEM ของเราเพื่อเชื่อม Falco event เข้ากับ centralized SIEM หรือศึกษา คู่มือ nftables สำหรับการ harden firewall บน Kubernetes node เพื่อสร้างเลเยอร์ป้องกันแบบ defense-in-depth ที่สมบูรณ์