CKS - Runtime Security

🎯 Objectifs

Tu vas monitorer et détecter les attaques en temps réel :

✅ Installer et configurer Falco pour la détection d'anomalies
✅ Interpréter les audit logs Kubernetes
✅ Détecter les suspicious behaviors (escalade de privilèges, intrusions)
✅ Utiliser des outils de forensics
✅ Implémenter une chaîne de réponse aux incidents
✅ Monitorer les system calls suspects

🚨 Falco - Détection d'Anomalies

Pourquoi Falco ?

Falco monitore les system calls au niveau du kernel pour détecter les comportements malveillants :

Un pod qui essaie d'escalader ses privilèges
Un conteneur qui essaie de modifier les fichiers système
Un processus non-attendu qui lance un shell interactif
Une tentative de sortie du conteneur (container escape)

Concepts clés

System call = chaque action qu'un processus fait (ouvrir un fichier, écouter un port, créer un process)

Falco intercepte les system calls via eBPF (extended Berkeley Packet Filter) et les analyse contre une règle policy.

Installation

bash

# Ajoute le repo Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Installe Falco
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set ebpf.enabled=true

Configuration basique

yaml

# /etc/falco/falco.yaml
rules_file:
- /etc/falco/rules.yaml
- /etc/falco/rules.d

output_channels:
  - name: stdout
    type: stdout
  - name: syslog
    type: syslog

outputs:
  - rule: Alert
    priority: Warning
    channel: stdout

Règles Falco

Une règle = "si ce pattern de system calls arrive, générer une alerte"

yaml

# Exemple : Détecter un shell interactif dans un conteneur
- rule: Suspicious Shell Activity
  desc: Détecte les shells interactifs non-attendus
  condition: >
    spawned_process and container and
    proc.name in (bash, sh) and
    not proc.parent.name in (docker, docker-containerd)
  output: >
    Suspicious shell
    (user=%user.name container=%container.name cmd=%proc.cmdline)
  priority: WARNING

# Exemple : Détecter les modifications de fichiers système
- rule: Write to System Directory
  desc: Détecte les écritures dans /etc, /sys, /proc
  condition: >
    write and container and
    fd.name startswith /etc/ or fd.name startswith /sys/
  output: >
    File write in system directory
    (user=%user.name file=%fd.name)
  priority: CRITICAL

À faire :

Installe Falco
Lance un pod : kubectl run test --image=alpine -- sleep 1000
Entre dans le pod et lance un shell
Vérifie que Falco détecte l'activité
Lis les logs : kubectl logs -f -n falco falco-xxxxx

📋 Kubernetes Audit Logs

Différence avec Falco

Aspect	Audit Logs	Falco
Cible	API calls (kubectl, API Server)	System calls (processus)
Granularité	Opérations hautes niveau	Très bas niveau
Use case	Compliance, qui a fait quoi	Détection d'anomalies

Interpréter les Audit Logs

json

{
  "level":"RequestResponse",
  "auditID":"abcdef123456",
  "stage":"ResponseComplete",
  "requestObject":{
    "apiVersion":"v1",
    "kind":"Secret",
    "metadata":{"name":"my-secret"}
  },
  "verb":"create",
  "user":{"username":"alice@company.com"},
  "sourceIP":"192.168.1.100",
  "objectRef":{"resource":"secrets","name":"my-secret"},
  "responseStatus":{"code":201,"message":"Created"},
  "requestReceivedTimestamp":"2025-01-15T10:30:00Z",
  "stageTimestamp":"2025-01-15T10:30:01Z"
}

À analyser :

Qui : user.username
Quoi : verb, objectRef.resource
Quand : requestReceivedTimestamp
Résultat : responseStatus.code
D'où : sourceIP

Rechercher les patterns suspects dans les logs

bash

# Qui a créé des secrets ?
grep '"verb":"create".*"kind":"Secret"' audit.log

# Qui a supprimé des pods ?
grep '"verb":"delete".*"resource":"pods"' audit.log

# Tous les DELETE actions (potentiellement dangereuses)
grep '"verb":"delete"' audit.log | jq .

# Les échecs d'authentification (tentatives d'accès non-autorisées)
grep '"responseStatus":{"code":401' audit.log

À faire :

Génère quelques actions : créer un Secret, supprimer un Pod
Lis le fichier audit.log
Retrouve ces actions dans les logs
Identifie les patterns suspects

🔍 Suspicious Behaviors à Connaître

1. Container Escape Attempts

bash

# Indicateurs
- Accès à /proc/sys/kernel (lecture de config kernel)
- Accès à /dev/mem ou /dev/kmem
- Tentative de mount root filesystem

2. Privilege Escalation

bash

# Indicateurs
- Changement UID/GID via system calls (setuid, setgid, capset)
- Ajout de capabilities Linux

3. Lateral Movement

bash

# Indicateurs
- Tentatives SSH/RDP vers d'autres pods
- Scan de ports réseau
- Exfiltration de données via DNS, HTTPS

4. Cryptocurrency Mining

bash

# Indicateurs
- Processus avec noms obfuscés (xmrig, cryptonight)
- Utilisation CPU extrême
- Connexions vers des mining pools

Falco Rules pour ces behaviors

yaml

- rule: Cryptocurrency Mining Activity
  condition: >
    container and proc.name in (xmrig, cryptonight, minerd)
  output: "Crypto mining detected (process=%proc.name)"
  priority: CRITICAL

- rule: Privilege Escalation Attempt
  condition: >
    container and (evt.type=capset or evt.type=setuid)
  output: "Privilege escalation attempt (uid=%process.uid)"
  priority: CRITICAL

- rule: Container Escape Attempt
  condition: >
    container and fd.name in (/proc/sys/kernel/*, /dev/mem, /dev/kmem)
  output: "Container escape detected"
  priority: CRITICAL

🔧 Forensics et Incident Response

Quand une attaque est détectée...

Étape 1 : Isoler le pod

bash

# Crée une Network Policy restrictive
kubectl label pod <pod> quarantine=true
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine
spec:
  podSelector:
    matchLabels:
      quarantine: "true"
  policyTypes:
  - Ingress
  - Egress
  # Tout est bloqué
EOF

Étape 2 : Capturer les evidences

bash

# Exporte les logs d'audit
kubectl get events -A -o json > events.json

# Récupère les logs du pod
kubectl logs <pod> > pod-logs.txt

# Dump les process en cours dans le pod
kubectl exec <pod> -- ps auxww > processes.txt

# Dump la mémoire (si possible)
kubectl debug <pod> -- cat /proc/self/maps > memory-maps.txt

Étape 3 : Investiguer avec Falco

bash

# Voir les règles qui ont matché
kubectl logs -n falco falco-xxxxx | grep "<pod-name>"

# Analyser les patterns d'attaque
kubectl logs -n falco falco-xxxxx | grep "CRITICAL"

Étape 4 : Répondre

bash

# Redéploie le pod sans l'image contaminée
kubectl set image deployment/myapp app=myapp:patched

# Ou supprime purement et simplement
kubectl delete pod <pod>

# Rétention : Garde les logs pour post-mortem

📝 Falco Rules Essentielles pour CKS

Tu dois connaître ces patterns :

yaml

# Write below root
- rule: Write below root
  condition: write and container and fd.name startswith /

# Read sensitive files
- rule: Read Sensitive File
  condition: read and container and fd.name in (/etc/passwd, /etc/shadow)

# Unauthorized process
- rule: Unauthorized Process
  condition: spawned_process and container and proc.name not in (allowed_list)

# Network activity
- rule: Suspicious Network Activity
  condition: outbound and container and fd.snet not in (allowed_networks)

# File modification
- rule: System Binary Modification
  condition: write and container and fd.name startswith /usr/bin

📝 Checklist Runtime Security

Falco : installé et règles configurées
Audit logs : policy définie, logs envoyés à un SIEM
Détection : règles pour escalade, escape, lateral movement
Isolation : Network Policies pour quarantine d'urgence
Response : procédure documentée pour incidents
Monitoring : alerts Falco configurées (Slack, email, webhook)
Forensics : outils installés (strace, tcpdump, etc)
Retention : logs gardés 90+ jours pour audit

CKS - Runtime Security

🎯 Objectifs

Tu vas monitorer et détecter les attaques en temps réel :

✅ Installer et configurer Falco pour la détection d'anomalies
✅ Interpréter les audit logs Kubernetes
✅ Détecter les suspicious behaviors (escalade de privilèges, intrusions)
✅ Utiliser des outils de forensics
✅ Implémenter une chaîne de réponse aux incidents
✅ Monitorer les system calls suspects

🚨 Falco - Détection d'Anomalies

Pourquoi Falco ?

Falco monitore les system calls au niveau du kernel pour détecter les comportements malveillants :

Un pod qui essaie d'escalader ses privilèges
Un conteneur qui essaie de modifier les fichiers système
Un processus non-attendu qui lance un shell interactif
Une tentative de sortie du conteneur (container escape)

Concepts clés

System call = chaque action qu'un processus fait (ouvrir un fichier, écouter un port, créer un process)

Falco intercepte les system calls via eBPF (extended Berkeley Packet Filter) et les analyse contre une règle policy.

Installation

bash

# Ajoute le repo Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Installe Falco
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set ebpf.enabled=true

Configuration basique

yaml

# /etc/falco/falco.yaml
rules_file:
- /etc/falco/rules.yaml
- /etc/falco/rules.d

output_channels:
  - name: stdout
    type: stdout
  - name: syslog
    type: syslog

outputs:
  - rule: Alert
    priority: Warning
    channel: stdout

Règles Falco

Une règle = "si ce pattern de system calls arrive, générer une alerte"

yaml

# Exemple : Détecter un shell interactif dans un conteneur
- rule: Suspicious Shell Activity
  desc: Détecte les shells interactifs non-attendus
  condition: >
    spawned_process and container and
    proc.name in (bash, sh) and
    not proc.parent.name in (docker, docker-containerd)
  output: >
    Suspicious shell
    (user=%user.name container=%container.name cmd=%proc.cmdline)
  priority: WARNING

# Exemple : Détecter les modifications de fichiers système
- rule: Write to System Directory
  desc: Détecte les écritures dans /etc, /sys, /proc
  condition: >
    write and container and
    fd.name startswith /etc/ or fd.name startswith /sys/
  output: >
    File write in system directory
    (user=%user.name file=%fd.name)
  priority: CRITICAL

À faire :

Installe Falco
Lance un pod : kubectl run test --image=alpine -- sleep 1000
Entre dans le pod et lance un shell
Vérifie que Falco détecte l'activité
Lis les logs : kubectl logs -f -n falco falco-xxxxx

📋 Kubernetes Audit Logs

Différence avec Falco

Aspect	Audit Logs	Falco
Cible	API calls (kubectl, API Server)	System calls (processus)
Granularité	Opérations hautes niveau	Très bas niveau
Use case	Compliance, qui a fait quoi	Détection d'anomalies

Interpréter les Audit Logs

json

{
  "level":"RequestResponse",
  "auditID":"abcdef123456",
  "stage":"ResponseComplete",
  "requestObject":{
    "apiVersion":"v1",
    "kind":"Secret",
    "metadata":{"name":"my-secret"}
  },
  "verb":"create",
  "user":{"username":"alice@company.com"},
  "sourceIP":"192.168.1.100",
  "objectRef":{"resource":"secrets","name":"my-secret"},
  "responseStatus":{"code":201,"message":"Created"},
  "requestReceivedTimestamp":"2025-01-15T10:30:00Z",
  "stageTimestamp":"2025-01-15T10:30:01Z"
}

À analyser :

Qui : user.username
Quoi : verb, objectRef.resource
Quand : requestReceivedTimestamp
Résultat : responseStatus.code
D'où : sourceIP

Rechercher les patterns suspects dans les logs

bash

# Qui a créé des secrets ?
grep '"verb":"create".*"kind":"Secret"' audit.log

# Qui a supprimé des pods ?
grep '"verb":"delete".*"resource":"pods"' audit.log

# Tous les DELETE actions (potentiellement dangereuses)
grep '"verb":"delete"' audit.log | jq .

# Les échecs d'authentification (tentatives d'accès non-autorisées)
grep '"responseStatus":{"code":401' audit.log

À faire :

Génère quelques actions : créer un Secret, supprimer un Pod
Lis le fichier audit.log
Retrouve ces actions dans les logs
Identifie les patterns suspects

🔍 Suspicious Behaviors à Connaître

1. Container Escape Attempts

bash

# Indicateurs
- Accès à /proc/sys/kernel (lecture de config kernel)
- Accès à /dev/mem ou /dev/kmem
- Tentative de mount root filesystem

2. Privilege Escalation

bash

# Indicateurs
- Changement UID/GID via system calls (setuid, setgid, capset)
- Ajout de capabilities Linux

3. Lateral Movement

bash

# Indicateurs
- Tentatives SSH/RDP vers d'autres pods
- Scan de ports réseau
- Exfiltration de données via DNS, HTTPS

4. Cryptocurrency Mining

bash

# Indicateurs
- Processus avec noms obfuscés (xmrig, cryptonight)
- Utilisation CPU extrême
- Connexions vers des mining pools

Falco Rules pour ces behaviors

yaml

- rule: Cryptocurrency Mining Activity
  condition: >
    container and proc.name in (xmrig, cryptonight, minerd)
  output: "Crypto mining detected (process=%proc.name)"
  priority: CRITICAL

- rule: Privilege Escalation Attempt
  condition: >
    container and (evt.type=capset or evt.type=setuid)
  output: "Privilege escalation attempt (uid=%process.uid)"
  priority: CRITICAL

- rule: Container Escape Attempt
  condition: >
    container and fd.name in (/proc/sys/kernel/*, /dev/mem, /dev/kmem)
  output: "Container escape detected"
  priority: CRITICAL

🔧 Forensics et Incident Response

Quand une attaque est détectée...

Étape 1 : Isoler le pod

bash

# Crée une Network Policy restrictive
kubectl label pod <pod> quarantine=true
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine
spec:
  podSelector:
    matchLabels:
      quarantine: "true"
  policyTypes:
  - Ingress
  - Egress
  # Tout est bloqué
EOF

Étape 2 : Capturer les evidences

bash

# Exporte les logs d'audit
kubectl get events -A -o json > events.json

# Récupère les logs du pod
kubectl logs <pod> > pod-logs.txt

# Dump les process en cours dans le pod
kubectl exec <pod> -- ps auxww > processes.txt

# Dump la mémoire (si possible)
kubectl debug <pod> -- cat /proc/self/maps > memory-maps.txt

Étape 3 : Investiguer avec Falco

bash

# Voir les règles qui ont matché
kubectl logs -n falco falco-xxxxx | grep "<pod-name>"

# Analyser les patterns d'attaque
kubectl logs -n falco falco-xxxxx | grep "CRITICAL"

Étape 4 : Répondre

bash

# Redéploie le pod sans l'image contaminée
kubectl set image deployment/myapp app=myapp:patched

# Ou supprime purement et simplement
kubectl delete pod <pod>

# Rétention : Garde les logs pour post-mortem

📝 Falco Rules Essentielles pour CKS

Tu dois connaître ces patterns :

yaml

# Write below root
- rule: Write below root
  condition: write and container and fd.name startswith /

# Read sensitive files
- rule: Read Sensitive File
  condition: read and container and fd.name in (/etc/passwd, /etc/shadow)

# Unauthorized process
- rule: Unauthorized Process
  condition: spawned_process and container and proc.name not in (allowed_list)

# Network activity
- rule: Suspicious Network Activity
  condition: outbound and container and fd.snet not in (allowed_networks)

# File modification
- rule: System Binary Modification
  condition: write and container and fd.name startswith /usr/bin

📝 Checklist Runtime Security

Falco : installé et règles configurées
Audit logs : policy définie, logs envoyés à un SIEM
Détection : règles pour escalade, escape, lateral movement
Isolation : Network Policies pour quarantine d'urgence
Response : procédure documentée pour incidents
Monitoring : alerts Falco configurées (Slack, email, webhook)
Forensics : outils installés (strace, tcpdump, etc)
Retention : logs gardés 90+ jours pour audit