Auteurs :
Mario Kahlhofer (Dynatrace Research – mario.kahlhofer@dynatrace.com)
Matteo Golinelli (University of Trento – matteo.golinelli@unitn.it)
Stefan Rass (Johannes Kepler University Linz – stefan.rass@jku.at)
Dans le paysage cloud-native en évolution rapide, la cyber-déception offre une approche prometteuse pour perturber les adversaires avant qu’ils ne causent de véritables dégâts. La cyber-déception consiste à placer stratégiquement des pièges, des leurres ou des honeytokens dans toute l’infrastructure afin de détecter, retarder et analyser les attaquants potentiels. Avec l’adoption de plates-formes d’orchestration de conteneurs telles que Kubernetes, ces techniques peuvent être intégrées de manière transparente—sans accès ni modification du code source des applications.
Koney est un nouveau framework d’orchestration de cyber-déception spécialement conçu pour Kubernetes. Grâce à son modèle de déploiement basé sur un opérateur, Koney permet aux opérateurs système de coder, déployer, faire tourner, surveiller et finalement retirer un éventail de techniques de déception « as code ». Dans cet article de blog, nous explorons en détail le fonctionnement interne de Koney, en discutant de son design, de son implémentation et de ses applications réelles. Nous incluons également des exemples de code et des usages en ligne de commande en Bash et Python afin d’aider les développeurs à voir comment intégrer la cyber-déception dans leurs clusters Kubernetes.
À la fin de cette lecture, vous aurez une compréhension solide de :
Ce guide complet s’adresse aussi bien aux débutants qu’aux utilisateurs avancés souhaitant exploiter la déception cloud-native.
Malgré les avantages documentés de la cyber-déception pour la détection et la remédiation précoces des attaques, de nombreuses organisations hésitent encore à déployer cette technologie. Les raisons incluent :
Koney répond aux questions critiques suivantes :
Le framework s’appuie sur les technologies cloud-native (par ex. les service meshes comme Istio et les mécanismes in-kernel tels qu’eBPF) pour intégrer de façon transparente les méthodes de déception dans les applications conteneurisées existantes. L’objectif principal est de simplifier les aspects opérationnels—maintenabilité, évolutivité et performance—tout en écartant les défis techniques profonds qui freinent l’adoption.
Comprendre Koney nécessite une bonne maîtrise des concepts clés de Kubernetes. Voici quelques termes essentiels :
Supposons que vous souhaitiez surveiller les anomalies réseau à l’intérieur d’un pod à l’aide d’eBPF. Une commande de scan typique pourrait ressembler à :
# Inspecter le trafic réseau dans un pod :
kubectl exec -it <pod-name> -- tcpdump -i eth0 -nn
Cette commande permet aux défenseurs de repérer d’éventuels pics inhabituels de trafic, indicateurs d’un scan ou d’une tentative d’exfiltration. De même, Koney exploite des conteneurs sidecar et des sondes eBPF pour injecter de la déception sans interrompre le fonctionnement normal des applications.
Les politiques de cyber-déception définissent la configuration et le comportement des leurres et pièges à déployer dans l’infrastructure. Dans Koney, ces politiques sont décrites « as code », ce qui permet aux équipes de sécurité de les versionner et de les examiner avec les outils standard.
Les pièges dans les systèmes de fichiers impliquent généralement la création de honeyfiles, honeytokens, honeydocuments, voire honeydirectories. Ces fichiers factices imitent des actifs de grande valeur. Un attaquant qui y accède déclenche des journaux et des alertes, révélant ainsi son activité.
Exemple d’extrait YAML pour une politique de déception dans le système de fichiers :
apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
name: honeytoken-policy
spec:
trapType: fileSystem
details:
fileName: "secrets.txt"
content: "username: admin\npassword: Pa$w0rd123"
triggerAlert: true
Les pièges destinés aux applications Web ciblent le trafic HTTP en injectant des points de terminaison factices, en modifiant les en-têtes ou le corps des réponses, voire en falsifiant entièrement des pages.
En pré-définissant des réponses pour des points de terminaison inexistants, on dirige les attaquants vers de faux portails d’administration ou des données leurre.
Par exemple, falsifier l’en-tête « Server » peut tromper un attaquant sur le type de serveur réel.
La manipulation directe du HTML, CSS ou JavaScript peut rediriger ou confondre un attaquant (ex. injection dans robots.txt).
Exemple YAML pour une politique de déception Web :
apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
name: web-deception-policy
spec:
trapType: webApplication
details:
endpoint: "/wp-admin"
responseType: fixed
responseContent: "<html><body><h1>Fake Admin Login Portal</h1></body></html>"
triggerAlert: true
Les documents de politique dans Koney spécifient également la portée exacte de la sélection de ressources. Un opérateur peut, par exemple, déployer une politique uniquement sur des pods avec un label donné ou dans un namespace spécifique.
apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
name: target-specific-policy
spec:
trapType: fileSystem
selector:
matchLabels:
role: sensitive
details:
fileName: "credentials.log"
content: "dummy-credentials"
triggerAlert: true
Koney fonctionne comme un opérateur dans l’écosystème Kubernetes. Il automatise la gestion du cycle de vie des déploiements de déception : installation, rotation, alerte et démontage.
Exécute des commandes directement dans un conteneur pour créer des honeyfiles ou modifier des réponses Web.
# Créer un honeytoken dans un pod
kubectl exec -it <pod-name> -- /bin/sh -c "echo 'dummy data' > /app/honeytoken.txt"
Injecte des artefacts de déception en montant un volume dédié dans le conteneur.
apiVersion: v1
kind: Pod
metadata:
name: decoy-pod
spec:
containers:
- name: app
image: myapp:latest
volumeMounts:
- name: deception-volume
mountPath: /app/decoy-files
volumes:
- name: deception-volume
configMap:
name: decoy-config
Utilise Istio pour intercepter et modifier les requêtes/réponses HTTP à la volée.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: deception-virtual-service
spec:
hosts:
- myapp.example.com
http:
- match:
- uri:
exact: /wp-admin
route:
- destination:
host: decoy-service
port:
number: 80
Outil eBPF surveillant les appels système, les accès fichiers et les événements réseau en temps réel.
import json
def parse_tetragon_log(log_file):
with open(log_file, 'r') as f:
for line in f:
try:
event = json.loads(line)
if 'deception_triggered' in event:
print("Accès suspect détecté :", event)
except json.JSONDecodeError:
continue
if __name__ == "__main__":
parse_tetragon_log('/var/log/tetragon/deception.log')
Analyse les flux de trafic via des filtres Envoy personnalisés.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: captor-filter
spec:
workloadSelector:
labels:
app: myapp
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.lua
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
inlineCode: |
function envoy_on_request(request_handle)
local headers = request_handle:headers()
request_handle:logInfo("Captor Trigger: " .. headers:get("User-Agent"))
end
Koney cible des cas variés : honeyfiles, réponses HTTP fixes, injection d’endpoints dynamiques. Les tests sur un cluster multi-micro-services ont montré un taux de détection supérieur à 90 %.
Des travaux antérieurs ont introduit honeytokens et surveillance temps réel ; Koney étend ces idées au monde containerisé.
La manipulation des réponses HTTP a déjà prouvé son efficacité. L’intégration d’Istio dans Koney automatise et fait évoluer ces techniques.
Le paradigme « policies-as-code » se généralise ; l’opérateur Koney va plus loin en gérant tout le cycle de vie.
Koney démocratise la cyber-déception pour les environnements cloud-native. En formalisant les politiques « as code » et en les automatisant via le pattern opérateur, il abaisse considérablement la barrière à l’adoption.
Principaux points à retenir :
apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
name: filesystem-honeytoken
spec:
trapType: fileSystem
selector:
matchLabels:
app: sensitive-data
details:
fileName: "credentials.txt"
content: |
user: admin
password: L0ngR@nd0mP@ss
triggerAlert: true
rotationInterval: "24h"
apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
name: webapp-deception
spec:
trapType: webApplication
selector:
matchLabels:
app: my-web-app
details:
endpoint: "/admin"
responseType: fixed
responseContent: |
<html>
<body>
<h2>Decoy Admin Panel</h2>
<p>This page is a decoy. Any unauthorized access is logged.</p>
</body>
</html>
triggerAlert: true
rotationInterval: "12h"
kubectl apply -f filesystem-honeytoken.yaml
kubectl apply -f webapp-deception.yaml
# Suivre les logs de l’opérateur Koney
kubectl logs -f deployment/koney-operator -n security
Lectures complémentaires :
Koney offre une approche agile pour sécuriser les environnements conteneurisés. Nous vous encourageons à l’expérimenter dans vos clusters Kubernetes et à contribuer à l’évolution de la cyber-déception.
Bonnes déceptions !
Mots-clés : cyber-déception, Kubernetes, opérateur Koney, cybersécurité, honeypots, honeytokens, Istio, service mesh, eBPF, DevSecOps, sécurité des conteneurs, policy-as-code
Si vous avez trouvé ce contenu utile, imaginez ce que vous pourriez accomplir avec notre programme de formation élite complet de 47 semaines. Rejoignez plus de 1 200 étudiants qui ont transformé leur carrière grâce aux techniques de l'Unité 8200.