
Démon pour randomiser tcp_challenge_ack_limit afin de prévenir les attaques par canaux auxiliaires CVE-2016-5696
chackd est un démon qui randomise chaque seconde le paramètre noyau tcp_challenge_ack_limit afin de prévenir les attaques par canal auxiliaire.
Une attaque par canal auxiliaire récemment présentée a fortement attiré l'attention de la communauté [1]. Pour de nombreux serveurs ou appareils smartphone, cette attaque est considérée comme dangereuse pour les connexions ipv4. Il ne fait aucun doute que le noyau corrigera ce problème dans les prochaines versions. Cependant, certains administrateurs pourraient ne pas mettre à jour le noyau pour des raisons spécifiques ou par simple paresse.
Ajuster le paramètre à une valeur très élevée [2] fonctionnera bien. D'un autre côté, pour les applications serveur, cela peut entraîner une quantité de trafic inutile. Pour éviter cela, j'ai écrit le programme chackd. Il peut être paramétré pour viser la solution présentée dans [1].
Le démon chack fait très bien ce travail tout en restant simple. Un de mes précédents concepts consistait à chercher un module noyau chargeable, mais je l'ai abandonné car il existe une interface puissante entre l'espace utilisateur et l'espace noyau appelée proc vfs. Avec les fichiers proc, nous pouvons effectuer le travail avec un simple démon.
C'est mon premier projet open-source avec un avantage intéressant pour les administrateurs qui souhaitent se protéger contre les attaques challenge_ack_limit et ne peuvent pas mettre à jour leur noyau. Il suffit de le compiler et de l'exécuter sur votre serveur.
J'ai besoin de l'aide de la communauté pour faire de ce projet un "standard communautaire".
Veuillez chercher les TODOs dans les fichiers source pour certaines choses sur lesquelles j'aimerais travailler. N'hésitez pas à créer une branche comme vous le souhaitez. J'aimerais beaucoup apprendre de ce projet.
Makefile - Mon souhait pour le Makefile est d'en faire une sorte de standard avec installation, requêtes de version du noyau, etc.
start_daemon - Toute partie de code qui pourrait causer le crash du démon doit être corrigée
stop_daemon - Toute partie de code qui n'est pas un standard doit être corrigée
init_daemon - Toute partie de code qui pourrait causer le crash du démon doit être corrigée
main - Mon intention est que les paramètres principaux soient donnés sous forme d'entiers simples, actuellement cela fonctionne bien. Cependant, il existe peut-être une meilleure manière de les gérer ?
Intervalle de 1 seconde de "sysctl net.ipv4.tcp_challenge_ack_limit"
net.ipv4.tcp_challenge_ack_limit = 222
net.ipv4.tcp_challenge_ack_limit = 227
net.ipv4.tcp_challenge_ack_limit = 191
net.ipv4.tcp_challenge_ack_limit = 178
net.ipv4.tcp_challenge_ack_limit = 229
net.ipv4.tcp_challenge_ack_limit = 167
net.ipv4.tcp_challenge_ack_limit = 189
net.ipv4.tcp_challenge_ack_limit = 229
Bastian Pukallus, veuillez envoyer un mail à [email protected]
[1] http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf
[2] https://www.mail-archive.com/[email protected]/msg705042.html