Discussion:Rootkit/Bon article

Cet article a été reconnu Bon article en vertu de ce vote.
Merci de remplacer ce modèle par {{Contestation BC}} si le vote est remis en cause.

Article accepté comme « bon ».

• Bilan : 5 bon article, 0 attendre/contre, 0 autre(s) vote(s).
• Commentaire : au moins 5 votes  Bon article et (bon article) / (bon article + attendre) = 100% > 66%

Gemini1980 oui ? non ? 15 mars 2011 à 01:40 (CET)

Rootkit

Proposé par : Romainhk (QTx10) 28 février 2011 à 10:34 (CET)

Suite aux remarques de la proposition en BA précédente et à un travail communautaire, beaucoup de changement/d'améliorations ont été apportées à l'article. Espérons maintenant que celui-ci rentre dans les critères . (Diff depuis le 23 mars 2010)

Merci à tous les votants ! Romainhk (QTx10) 15 mars 2011 à 10:15 (CET)

Oui, tu aurais du voté toi aussi ;) Amqui (d) 15 mars 2011 à 15:11 (CET)

Bof, je trouve ça étrange de voter pour son propre article ; ça fait un peu auto-congratulations, et ce n'est pas très neutre (je ne peux évidement pas voter "attendre" ;). Et puis je trouve cela drôle/logique que les candidats à une élection n'aient pas le droit de voter ; mais c'est un avis personnel . Romainhk (QTx10) 15 mars 2011 à 19:15 (CET)

Votes

Format : Motivation, signature.

Bon article

1.  Bon article Bon travail, accessible et sérieux. Prosopee (d) 28 février 2011 à 18:02 (CET)
2.  Bon article Belle métamorphose depuis le dernier vote. Gemini1980 oui ? non ? 1 mars 2011 à 00:30 (CET)
3.  Bon article Je comprends mieux ton absence.--Mit freundlichen Grüßen, Morphypnos ^{[Conversons un peu !]}. 12 mars 2011 à 11:39 (CET)
4.  Bon article je n'ai pas regardé les différences mais pour ma part, cet article est bien à la hauteur du label! Kevin Benoit ^{[Par ici la discussion!]} 12 mars 2011 à 15:16 (CET)
5.  Bon article D'accord. Amqui (d) 12 mars 2011 à 16:33 (CET)

Attendre

 Attendre Voir ci-dessous. Amqui (d) 7 mars 2011 à 01:13 (CET)

Discussions

Toutes les discussions vont ci-dessous.

Remarques d'Amqui

Passage qui aurait besoin d'être sourcé : « [...] elle repose sur le fait que les systèmes d'exploitation Windows 95/98 sont particulièrement laxistes sur la sécurité : il n'y a pas de contrôle de droit d'exécution d'un programme (tout le monde peut exécuter n'importe quelle application, et même reconfigurer le système), les mots de passe sont stockés en clair, etc. ». Puis, d'un point de vue personnel "etc." dans ce cas ne fait pas très encyclopédique. Amqui (d) 2 mars 2011 à 02:05 (CET)

Il s'agit plutôt d'une évidence : dans le contexte des OS de l'époque, ne pas avoir de mot de passe chiffrés, et ne pas avoir de niveaux de privilège, c'est exceptionnellement... en retard (10 ans de retard même). "Laxiste" n'est peut être pas le terme adapté. Je vais reformuler ça, tu m'en diras des nouvelles

C'est vrai que le etc n'est pas justifiable ici. Romainhk (QTx10) 2 mars 2011 à 08:54 (CET)

« Cette altération est possible car les systèmes d'exploitation Windows 95/98 sont en retard en matière de sécurité par rapport aux autres systèmes d'exploitation de l'époque » On mentionne les raisons du retard de Win 95/98 sans mentionner clairement quels autres OS de l'époque ne possèdent pas ses lacunes, i.e. quels OS ne stockent pas ses mots de passe en clair à l'époque par exemple. Amqui (d) 4 mars 2011 à 03:11 (CET)

Pour les Unix, les mots de passes sont chiffrés grâce à shadow, présent sur System V et BSD dès 1990. En 1995, la plupart des Unix descendent plus ou moins directement de ces deux là, dont le futur Mac OS. De même pour les droits d'exécution : tous les unix savent faire ça depuis au moins 1990 (cela fait d'ailleurs parti de la norme POSIX).

Mais la question reste difficile à source : il faudrait vérifier la (non-)disponibilité de ces deux fonctionnalités pour chaque OS (une centaine !?), ou trouver une synthèse de l'usage des mots de passes chiffrés (et je n'en ai pas trouvé :S). On pourrait simplement retirer la comparaison : « Cette altération est possible car les systèmes d'exploitation Windows 95/98 n'offrent pas de mécanismes de sécurité basiques telles que : » , non ? Romainhk (QTx10) 5 mars 2011 à 11:28 (CET)

Ça me parraît plus adéquat considérant les sources disponibles. Je vais relire un autre passage maintenant ;) Amqui (d) 5 mars 2011 à 16:35 (CET)

 Fait. Bonne lecture . Romainhk (QTx10) 9 mars 2011 à 11:07 (CET)

Je crois qu'il ne serait pas trop difficile de sourcer la section Outils et logiciels de détection, simplement un lien vers la page de description des logiciels mentionnés montrant que le dit logiciel œuvre contre les rootkits. Amqui (d) 5 mars 2011 à 16:38 (CET)

Justement, je ne trouve pas toujours pertinent de mettre une source sur une plaquette commerciale changeante. Par exemple pour "Sophos Anti-Rootkit", on pourrait faire un lien sur [1] mais il est évident qu'il s'agit d'un logiciel est un anti-rootkit.

Par contre, pour la dernière liste, il peut effectivement être intéressant de préciser qu'avast, avg et mst contiennent un antirootkit. Romainhk (QTx10) 9 mars 2011 à 11:07 (CET)

Archive du vote précédent

Article rejeté.

• Bilan : 0 bon article, 4 attendre/contre, 0 autre(s) vote(s).
• Commentaire : moins de 5 votes  Bon article et/ou (bon article) / (bon article + attendre) = 20% ≤ 66%

Sardur - allo ? 23 mars 2010 à 00:05 (CET)

Proposé par : Janiko (d) 8 mars 2010 à 14:35 (CET)

Je souhaite relancer un peu l'activité sur le portail de la sécurité informatique, et je souhaite voir si je vais dans la bonne direction . Cet article est basé sur des références sérieuses, et j'espère avoir fait un travail clair. Comme tout article de wikipedia, rien n'est définitif, tout complément, ajout est potentiellement bienvenu. Je pense également que le portail Sécurité informatique est un peu sous-évalué, beaucoup d'articles me semblent de bon niveau. Donc, encore une fois, relançons la machine !

Bonjour à tous, et merci pour les avis. L'article semble juste pour un label BA, je conserve encore un peu la section "bon article" pour avoir d'autres retours. Après je pense que je passerai toute cette partie dans la PDD de l'article lui-même, si tout le monde est d'accord.--Janiko (d) 10 mars 2010 à 11:13 (CET)

On ne peut pas stopper une procédure en cours de route. À son issue, ce ne sera pas la peine de recopier les critiques, cette page est déjà une sous-page de discussion, accessible depuis la PDD. Gemini1980 oui ? non ? 10 mars 2010 à 11:47 (CET)

Votes

Format : Motivation, signature.

Attendre

1.  Attendre Quelques sections peu claires ou non encyclopédiques outre quelques défauts mineurs m'incitent à penser qu'il faut encore attendre un peu. Voir discussion. --STR (d) 8 mars 2010 à 19:47 (CET)
2.  Attendre Beaucoup de sections, pas assez de texte pour les étoffer. Au nombre de références, l'article peut être mieux. Cantons-de-l'Est 8 mars 2010 à 20:47 (CET)
3.  Attendre Avantage de l'article : très abordable ; inconvénient : manque de rédaction et d'approfondissement, auquel j'ajoute quelques problèmes typographiques ; un peu juste pour un BA. Ça vaut vraiment le coup de persévérer. Gemini1980 oui ? non ? 10 mars 2010 à 02:19 (CET)
4.  Attendre Je partage les avis ci-dessus : trop de listes (jusque dans le résumé introductif) et pas assez d'approfondissements (notamment sur la partie « prévention » un peu triviale). Bon courage pour la suite. Binabik (d) 13 mars 2010 à 23:14 (CET)

Discussions

Remarques de O_yP

L'article part sur de bonnes bases. À mon sens, en vue du label, il y aurait quelques améliorations à apporter, mais c'est vraiment possible.

Le principal élément qui m'empêche de voter pour est que l'article contient plusieurs listes à puces, qui énumèrent diverses possibilités brièvement, sans exemples et sans sources. Or, les exemples et les sources apparaissent plus loin. Il faudrait remplacer chaque item de liste par un paragraphe avec exemple(s) et source(s), quitte à les enlever de là où ils sont actuellement. Un plan dans lequel chaque concept est nommé, illustré, sourcé est largement plus clair qu'un plan qui annonce plein de choses pour les illustrer toutes plus tard, en bloc.

De même pour les moyens de détection / prévention / réparation : actuellement, ils sont tous listés à la fin, sans aucune explication. Il faudrait en dire plus et mieux : quel moyen sert à quoi, qu'est-ce que chacun a de particulier. Sans cela, c'est juste une liste qui ne sert pas à grand-chose. Elle est aussi à nettoyer, par exemple Kaspersky envoie vers une page d'homonymie. D'autre part, les liens externes ne doivent pas figurer directement dans le corps de l'article mais en référence.

Il serait bon aussi de parler un peu plus de l'aspect « recherche » : il y a des conférences sur la sécurité informatique, ou des sections (tracks) de conférence sur l'informatique dédiées à la sécurité.

Enfin, quand je vois ce que donne une simple recherche de « rootkit » sur amazon, je trouve dommage que l'article ne cite aucun livre.

Voilà, pour moi c'est essentiellement une question de forme et de rigueur. Avec un peu de travail, l'article peut sans problème viser le label BA. 0_ЧⱣ·✉ 8 mars 2010 à 15:02 (CET)

Bonjour, merci pour ces commentaires. Pour les listes, c'est vrai que certaines ne font qu'indiquer de quoi il s'agit, sans forcément approfondir. Je partais sur l'idée que l'approfondissement relevait du niveau AdQ , mais bon, on peut toujours améliorer. Sur la liste des outils à la fin, je ne suis pas sûr qu'elle soit forcément très pertinente ou à jour ; j'ai hésité à l'enlever, mais dans tous les cas elle devrait rester à l'état de "liste", je vois difficilement comment compléter cette partie.

Après, pour le traitement des "listes", je pensais faire "aller du général au détail", en annonçant les grands types puis en détaillant un peu. Mais encore une fois, je suis preneur de tout conseil ; pourrais-tu (on peut se tutoyer ?) simplement illustrer par une exemple, que je ne parte pas dans une réorganisation stérile ?

Côté références bibliographiques, il y a effectivement beaucoup de choses sur amazon, mais il y a aussi beaucoup de références de travaux sérieux sur le net. Les citations du SANS Institute, du CERTA, de l'université du Michigan et du centre de recherche de Microsoft me semblent un bon départ au moins pour le niveau BA.

Pour finir, et ça n'est pas contre toi que cette remarque se dirige, j'ai un peu "forcé" le vote en BA, faute d'avoir reçu beaucoup de relecture. Hélas, ça rend les choses un peu plus difficiles, car à part toi et Utilisateur:Mafiou44, j'ai un peu manqué d'éléments pour savoir quelles étaient les bonnes orientations. Et c'est un peu ce que je regrette sur le portail sécurité informatique, où l'activité semble bien ralentie (en général).

Donc en résumé, est-ce que je dois garder le vote pour le BA, ou faut-il le retirer pour améliorer encore un peu ? Merci...--Janiko (d) 8 mars 2010 à 16:27 (CET)

(d'accord pour le tutoiement )

Sur les listes, je pense à quelque chose comme ce qui est fait dans l'article en:Rootkit, dans la section Types. La section n'est pas organisée comme une liste à puce, mais au contraire en paragraphes, un par type de rootkit. Chaque paragraphe contient au moins un exemple et une référence. Pour moi, c'est une présentation « labellisable ».

Ok, je vais voir ce qu'on peut faire... ;-)--Janiko (d) 10 mars 2010 à 10:25 (CET)

La pertinence de la liste de moyens de préventions est limite, car en ils ne sont pas spécifiques aux rootkits. Il serait peut-être bon de créer une Liste de logiciels de sécurité informatique, peut-être en renommant et augmentant Liste de logiciels antivirus, qui a tendance à déborder de son cadre.

Ce point me pose un peu problème, mais pas spécialement par rapport à l'article, car :

• Il y a des outils spécifiques pour la détection de rootkits (rkhunter, chkrootkit, unhide).
• Il y a des outils de sécurité traitant également de rootkit, y compris les solutions dites « anti-virus » (Microsoft Security Essentials, Avast, etc).
• Mais surtout il y a des actions (et non des outils) qui concourent à la bonne gestion d'un système, qui ne sont pas spécifiquement destinées aux rootkits mais qui sont quasi-indispensables, comme la gestion des droits utilisateurs et de mots de passe. Dans ce cas, où placer cette rubrique, car il faut aussi expliquer pourquoi ces mesures sont utiles dans le cadre de la sécurité et de la lutte contre les rootkits ?

Donc oui, la liste pourrait être renommée et intégrer la réalité des outils qui désormais traitent plusieurs types de menace, mais il resterait (pour rootkit) à traiter des moyens spécifiques (contrôle d'intégrité des fichiers) ou généraux (mots de passe)--Janiko (d) 10 mars 2010 à 10:25 (CET)

Concernant l'organisation, je pense qu'il est très bien qu'il existe un portail de la sécurité informatique, il y a largement la matière suffisante et ça décharge l'énorme projet informatique. Mais si tu manques de relecteurs, n'hésite pas à solliciter le projet informatique. Je ne suis pas spécialiste de la sécurité et je n'ai donc pas le projet sécurité dans ma liste de suivi, mais pour une relecture en vue de labellisation, il me semblerait tout à fait approprié de mettre un message sur la pdd du projet informatique. Tu aurais eu au moins un relecteur de plus : moi .

Pour le label BA, il ne me semble pas du tout nécessaire d'être très précis et/ou complet sur les conférences et les livres. Ce qui me paraîtrait bon, c'est montrer qu'il y a une recherche académique, en citant juste quelques-unes des principales conférences, avec des références à leurs actes (les références se trouvent facilement en ligne gratuitement, contrairement aux actes complets qui sont généralement payants). De même, quand je parle de livres, je n'envisage pas une vraie bibliographie comme il en faudrait pour le label AdQ, mais simplement en donnant quelques références, on peut montrer 1) que le sujet est important, 2) qu'il concerne différents systèmes (livres pour Windows, pour BSD…), 3) qu'il concerne le grand public, avec des livres du style « les rootkits pour les nuls ».

Continuer la procédure ou pas, c'est toi qui vois. Si tu estimes que mon avis te suffit pour le moment, tu peux parfaitement arrêter la procédure, retravailler l'article et le reproposer plus tard. Mais tu peux aussi la laisser suivre son cours, ce qui apportera d'autres avis, sans doute différents du mien. 0_ЧⱣ·✉ 8 mars 2010 à 16:55 (CET)

Remarques de STR (d · c · b)

Pour commencer par une remarque générale :

• pourquoi l'ouverture d'une porte dérobée est-elle caractéristique d'un rootkit ? Pour moi, c'est plutôt un comportement de cheval de Troie. On retrouve cette notion dans l'introduction et dans la section « Principe du Rootkit ». D'autant plus que la définition du CERTA, l'article logiciel malveillant ou les exemples cités ne font nulle part référence à une porte dérobée comme caractéristique d'un rootkit.

Le but d'un rootkit est d'obtenir un accès à une machine et de le maintenir dans le temps, en se dissimulant. La porte dérobée est une conséquence très fréquente des rootkits, car cela permet le contrôle des ressources voulues depuis l'extérieur, par l'attaquant. A contrario, un virus n'a pas a priori besoin d'être contrôlé, il a besoin d'être actif et de se répandre. L'emploi de porte dérobée est donc fréquent, avec d'autres techniques, cf http://en.seguridadpc.net/rootkits.htm ou http://searchmidmarketsecurity.techtarget.com/sDefinition/0,,sid198_gci547279,00.html. Par contre c'est vrai que ce n'est pas la caractéristique principale. Dans ce cas, faudrait-il faire un paragraphe « Moyens employés » par exemple, du même niveau que « principe », et y inclure en développement la liste à puce actuellement en introduction ? Ca me semblerait cohérent, et supprimerait le problème de l'introduction que n'en est pas vraiment une.

Pour ce qui est des points mineurs :

• il faudrait éviter les termes anglais lorsqu'un équivalent français très usuel existe (library, process...),

Je pensais l'avoir fait, d'où l'intérêt des relectures... Pour l'informatique, c'est toujours ambigu car les termes anglo-saxons sont souvent prédominants (donc j'essaye de garder les deux termes s'ils sont très utilisés, mais ok bien sûr pour franciser au maximum).--Janiko (d) 10 mars 2010 à 11:13 (CET)

• quelques fautes (un machine...),
• des termes vagues (existent depuis plusieurs années, il y a au moins cinq types...).

Ok pour les corrections ; juste sur le au moins : j'ai appris à être très prudent en informatique et surtout en sécurité, et la liste peut facilement évoluer (de nouveaux types peuvent être imaginés et/ou non encore détectés). Une formulation du type il existe cinq grand types connus serait-elle plus appropriée ? Et je vais vérifier mais sur l'article anglais il y a un type supplémentaire (boot level)--Janiko (d) 10 mars 2010 à 11:13 (CET)

Pour ce qui est des sections qui, à mon sens, sont à reprendre :

• l'introduction, qui n'en est plus une quand elle décrit toutes les méthodes de dissimulation et qu'en plus ces méthodes ne sont pas réellement décrites ailleurs dans l'article ;
• la section « Rôle d'un rootkit » :
  • qui commence par parler de tout autre chose que le rôle du rootkit ; de plus, je ne comprends pas en quoi le but d'un rootkit est d'agir en tant que « super-administrateur » (notion qui d'ailleurs n'existe pas dans la plupart des OS) ;
  • je ne vois pas comment accéder à des ressources système normalement protégées sans exploiter une faille de l'OS ou une négligence de l'utilisateur ; l'exemple de Haxdoor ne me semble pas non plus éclairer le propos : ce rootkit modifiait le noyau d'après ce que j'ai pu en lire ; et la section suivante « Mode de contamination » ne parle que de ces deux méthodes ;
  • sur les motivations de l'attaquant, plutôt que d'en faire la liste, c'est tout simplement le but de tout diffuseur de malware ;

C'est vrai, mais il n'en est pas fait mention dans l'article malware. Donc il faudrait se contenter d'un bref rappel, et compléter l'article malware ?--Janiko (d) 10 mars 2010 à 11:13 (CET)

• dans « Exemples de rootkits », il me semble peu pertinent de ne parler que de Sony ;

Je ne suis pas sûr non plus que cette section soit à conserver ; au départ, l'article ne contenait quasiment que cela, donc j'ai hésité. Peut-être faire plus bref, et/ou citer un autre exemple (cf exemple analysé par le SANS Inst. http://www.sans.org/security-resources/idfaq/tfn_toolkit.php)--Janiko (d) 10 mars 2010 à 11:13 (CET)

• la section « Programmes de détection de rootkit » me semble inutile (le but n'est pas d'avoir un catalogue, qui de toutes façons ne sera jamais exhaustif ou à jour) ;

Il est trop fourni, en effet, cf remarque d'OyP sur les logiciels de sécurité. Par contre on pourrait laisser les programmes vraiment spécifiques, car ils sont assez difficiles à trouver, même par une recherche internet (je pense à des outils comme Sophos anti-rootkit, rkhunter, etc). La liste ne sera jamais exhaustive mais elle sera au moins utile pour ceux qui chercherons des outils. --Janiko (d) 10 mars 2010 à 11:13 (CET)

Pour ce qui est des autres ajouts et correction qui seraient utiles :

• dans « Moyens de détection », il manque (au moins) une méthode : la comparaison de résultats d'appels systèmes très bas niveau et d'API de plus haut niveau pour en détecter les incohérences, preuve potentielle de la présence d'un rootkit ;
• dans « Moyens de protection et de prévention », on laisse sous-entendre qu'une détection ou éradication est toujours possible ; en théorie, un rootkit peut être suffisamment bien dissimulé à un niveau suffisamment bas pour qu'il soit totalement indécelable ;
• je ne vois pas en quoi l'EFI serait intrinsèquement protégé des rootkits contrairement au BIOS (ce n'est pas confirmé par la note 6).

Ok pour le 1er point. Après, un rootkit sera forcément détectable, parce qu'il engendre une activité non désirée. Ca se verra sur le CPU ou sur le réseau, même si le rootkit prend le soin d'effacer les logs. Je chercherais des références complémentaires. Pour l'EFI, je n'ai pas creusé la question, mais disons que ça ne protège que dans le cas de l'utilisation du module de persistance, qui rend une partie du BIOS figée, alors que l'EFI peut être totalement réinstallé (si j'ai bien compris). A creuser, cependant... --Janiko (d) 10 mars 2010 à 11:13 (CET)

--STR (d) 8 mars 2010 à 20:35 (CET)