Après avoir subi une attaque récemment, le site kernel.org a été réinstallé et est revenu on-line.
Les développeurs ont fait suivre une série de best-practice aux développeurs à faire avant de chercher à se reconnecter sur kernel.org. Voici extraits les messages les plus techniques de la mailing list LKML.
Le premier message donne une série de mesures, qui commence par "s'assurer que son système n'est pas compromis". Le reste est plus spécifique à GPG et permet de s'assurer via une chaîne de confiance humaine (et non automatiques comme les certificats SSL/TLS de nos navigateurs) que les clés GPG correspondent bien aux bonnes personnes.
Le second donne une série de bonnes pratiques afin de "vérifier son système" comme indiqué au point 1 du message précédent. Il conseille de tout réinstaller, de faire un check anti-rootkits, de vérifier ses logs, vérifier la signature des paquets. Classique, mais un rappel ne fait pas de mal.
Le troisième précise une série de mesures pour lire et exploiter au mieux ses logs. Je trouve une idée particulièrement bonne: check for suspicious DNS requests from machines that are normally not accessed. A number of services perform DNS requests when connected to, in order to log a resolved address. If the machine was penetrated and the logs wiped, the DNS requests will probably still lie in the firewall logs. While there's nothing suspect from a machine that does tens of thousands DNS requests a day, one that does 10 might be suspect. Le DNS est un allié particulièrement efficace comme IDS, c'est connu.
Le quatrième message indique (entre autre) un point qui me semble évident: si root d'une machine distante est compromis, alors ne faites pas du ssh dessus avec un agent activé si vous n'utilisez qu'une clé! Note that if your laptop allows incoming ssh connections, and you logged into master.kernel.org with ssh forwarding enabled, your laptop may not be safe. Effectivement, mais cela demande quand même un setup particulièrement mal fichu. Pour que cette condition soit vraie il faut que vous chargiez dans l'agent la clé qui vous permette de vous connecter chez vous. Ce genre de setup existe (entre autre) si la même clé est utilisée de partout! Pour des développeurs kernel, ça paraît léger, c'est comme si vous utilisiez le même mot de passe pour tous les services... [Je donne la démo d'exploitation dans un post de blog à venir.]
Les admins qui remontent les services actuellement précisent qu'ils fourniront un rapport détaillé sur l'intrusion. J'espère pouvoir le lire bientôt.
Les développeurs ont fait suivre une série de best-practice aux développeurs à faire avant de chercher à se reconnecter sur kernel.org. Voici extraits les messages les plus techniques de la mailing list LKML.
Le premier message donne une série de mesures, qui commence par "s'assurer que son système n'est pas compromis". Le reste est plus spécifique à GPG et permet de s'assurer via une chaîne de confiance humaine (et non automatiques comme les certificats SSL/TLS de nos navigateurs) que les clés GPG correspondent bien aux bonnes personnes.
Le second donne une série de bonnes pratiques afin de "vérifier son système" comme indiqué au point 1 du message précédent. Il conseille de tout réinstaller, de faire un check anti-rootkits, de vérifier ses logs, vérifier la signature des paquets. Classique, mais un rappel ne fait pas de mal.
Le troisième précise une série de mesures pour lire et exploiter au mieux ses logs. Je trouve une idée particulièrement bonne: check for suspicious DNS requests from machines that are normally not accessed. A number of services perform DNS requests when connected to, in order to log a resolved address. If the machine was penetrated and the logs wiped, the DNS requests will probably still lie in the firewall logs. While there's nothing suspect from a machine that does tens of thousands DNS requests a day, one that does 10 might be suspect. Le DNS est un allié particulièrement efficace comme IDS, c'est connu.
Le quatrième message indique (entre autre) un point qui me semble évident: si root d'une machine distante est compromis, alors ne faites pas du ssh dessus avec un agent activé si vous n'utilisez qu'une clé! Note that if your laptop allows incoming ssh connections, and you logged into master.kernel.org with ssh forwarding enabled, your laptop may not be safe. Effectivement, mais cela demande quand même un setup particulièrement mal fichu. Pour que cette condition soit vraie il faut que vous chargiez dans l'agent la clé qui vous permette de vous connecter chez vous. Ce genre de setup existe (entre autre) si la même clé est utilisée de partout! Pour des développeurs kernel, ça paraît léger, c'est comme si vous utilisiez le même mot de passe pour tous les services... [Je donne la démo d'exploitation dans un post de blog à venir.]
Les admins qui remontent les services actuellement précisent qu'ils fourniront un rapport détaillé sur l'intrusion. J'espère pouvoir le lire bientôt.
Aucun commentaire:
Enregistrer un commentaire