Détecter les clapotis d'un lac en regardant la surface de l'eau (detection d'intrusion)
Il y a plein de façon de concevoir la détection d'attaque réseau. Déjà, on fait une grande hypothèse en ne regardant que les "flux" réseaux (au sens netflow, session TCP du terme) et leur métriques, en batch ou indépendamment les uns des autres. Il y a de nombreuses options.
On peut regarder d'autres métriques, par exemple des données de santé de l'infrastructure protégée, voir carrément analyser le payload quand c'est possible (c'est compliqué, voir non applicable, voir illégal dans beaucoup de cas)
Penser des flux indépendants, ou même en batch c'est naïf et ne prend pas compte de la composante temporelle d'une attaque. Un procédé d'attaque consiste en des collectes d'information ou des exploitations. Certaines sont très "verbeuses", d'autres plus subtiles.
Prenons LOG4J par exemple. je vais vous expliquer comment on fait pour exploiter la plus grande faille logicielle des dix dernières années.
en noir un comportement normal, (1) requête web (2) le service web est logué via log4j (3) log4j dit "c'est bon j'ai logué "(4) le client a une réponse.
La faille en rouge ici, c'est que log4J interprète des choses qu'il doit log. C'est assez proche de mettre "select * from DATABASE where 1=1" pour trigger une requête sur la base de donnée. C'est plus vicieux ici: En gros, le (1) rouge va contenir une "requête ldap", le web va le log (2) l'utilitaire vulnérable va donc forcer java à lancer une requête ldap a un serveur malveillant (ici Server X, (3)) et il renvoi (4) une commande à executer. ça peut être "envoyer un mail avec tout le code", ou encore "supprimer la racine", plus généralement "ouvre moi une backdoor que je puisse prendre contrôle de l'application." ou "fait tourné doom sur la page principale", ce qu'on veut.
ce type d'attaque est simple, mais facile à détecter quand on est un humain averti, tels que vous maintenant. Mais pour un robot ? Qui ne voit que des flux passé, sans trop de notion de source ou de destination, pas facile. Pour les règles "bêtes et méchantes" (càd bloquer le ldap en sortant) pas toujours évident, les entreprises sont interdépendantes et peut-être que votre machine a besoin de pouvoir sortir en ldap. Puis, le port ne fait pas foi de toute manière, il suffit de n'importe quel port ouvert disponible. La seule parade facile est de patcher, option que les ingénieurs pendant la semaine de delta ou cette bombe est sortie n'avait pas.)
Il faut donc trouver un moyen d'analyser le réseau et les interdépendances entre les machines pour y détecter des anomalies. Une solution c'est de représenter les différents acteurs voir les différents sous composants des acteurs comme des noeuds dans un graph de connaissance. C'est la base utilisée dans des modèles de graph neural network, prochaine piste. On peut aussi (non excluant) considérer les paquets dans des sequences, avec un timestamp et une durée, dans une "time serie", outil très utilisé. Ici la particularité, c'est que la relation entre "une attaque" ou pas, elle est dans les patterns plus que dans des relations mathématiques plus numérique.
bref, petit point sur les différentes approches. Il y a d'autres questions à ce poser, "comment on récupère des attaques pour s'entrainer à les détecter ?", "Est-ce que c'est réaliste de prendre en compte des sessions en temps réel ?", "Que faire si l'architecture évolue, est-ce que ça ne va pas généré plein d'alerte alors que tout va bien ?" et c'est des questions à aborder dans de prochains billets
bisous