Accueil
  Bienvenue !
  Who's that Chuck ?

Articles
  Investigation numérique
  Virtual-to-Remote-Physical
  Prométhée, intranet éduc.
  Frenzy, mini CD live
  Sécu. Open/Closed Source
  Installer FreeBSD 5
  Powered by Unknown !
    FreeBSD / Nmap (1/2)
    FreeBSD / Nmap (2/2)
    telnetd
    ftpd
    Apache
    Bind
    Lukemftpd
    OpenSSH
    PHP
    Qpopper
    Sendmail
    Sendmail / Smtpscan
    Sendmail / Smtpmap

  En cours d'élaboration :
  Analyseurs d'empreintes

Logiciels
  Portages
  Projet HeV

Liens
  Sites BSD en français
  Liste systèmes BSD
  Projets à l'honneur

Recherche
  avec

Powered by Unknown !

Le contexte

Il est notoire que lors de la création du réseau Internet et de ses précurseurs, la sécurité avait été quelque peu oubliée du cahier des charges ¹.

En effet, la préoccupation de l'époque était plutôt de faire communiquer les machines et de se donner les moyens de déverminer les problèmes rencontrés. C'est pourquoi bon nombre des protocoles de communication et des implémentations correspondantes prévoyaient la divulgation spontanée ou sur demande, de l'éditeur, du modèle et de la version des logiciels utilisés².

Puis le temps a passé, le Réseau a rencontré le succès que l'on sait et cette tendance s'est transformée et amplifiée : les logiciels d'infrastructure, jusque là quasi invisibles, ont commencé à s'afficher publiquement, leurs éditeurs et utilisateurs respectifs ayant notamment recours aux logos, boutons et bandeaux "Powered by XY"³ pour promouvoir leurs solutions techniques.

Les risques

     Les Barbares habitaient dans les angles tranchants des cités exilées au large du business.⁴

Or pendant ce temps, une autre chose importante avait changé : avec l'accroissement du nombre de machines connectées et l'ouverture aux entreprises puis aux particuliers, le Réseau avait progressivement perdu son statut d'environnement de confiance, les barbares étaient aux portes !

Alors que les bonnes gens commençaient à peine à prendre conscience de la valeur de leurs informations et du fait que certaines étaient plus sensibles que d'autres, des pirates collectaient tranquillement celles sur les logiciels utilisés⁵, les croisaient avec des bases de vulnérabilités⁶, puis les exploitaient pour compromettre la sécurité des machines, réseaux et organisations correspondantes.

Cette époque a fini par connaître elle aussi sa révolution industrielle : avec l'apparition d'outils automatisant la collecte et l'exploitation des informations sensibles, la piraterie s'est démocratisée, accueillant dans ses rangs de nouvelles générations techniquement moins averties, souvent beaucoup moins subtiles⁷ et aux motivations parfois quasi ludiques⁸ !

Aujourd'hui la situation est telle que toute machine, indépendamment de la notoriété de l'organisation l'exploitant, voit sa sécurité éprouvée quelques heures, parfois quelques minutes, après sa mise en ligne. Les particuliers, même connectés temporairement par une connexion téléphonique avec leur fournisseur d'accès Internet, sont également concernés, à plus forte raison depuis le déploiement de solutions d'accès plus permanentes telles que le câble ou l'ADSL⁹.

Dans ces conditions, continuer à fournir gracieusement des informations sensibles au tout venant équivaut vraiment à tendre le bâton pour se faire battre !

Nos recommandations

     Le tout venant a été piraté par les mômes. Qu'est-ce qu'on se fait, ... on se risque sur le bizarre ?¹⁰

Le préalable indispensable est de sécuriser tout système raccordé à Internet.

Sans m'attarder là dessus, car ce n'est pas le sujet de cet article, cela s'articule notamment en moyens de :

• prévention (analyse de risques, politique de sécurité, cloisonnement, durcissement, etc.) ;
• maintien de l'efficacité dans le temps (veille sécuritaire, analyse et application des correctifs de sécurité, etc.) ;
• détection (utilisation de systèmes de détection de changements¹¹, etc.) ;
• correction (gestion d'incidents, gestion de crise, etc.)

Il est ensuite souhaitable de contrôler la diffusion des informations sensibles au nom d'un principe bien connu dans les administrations ou chez les auditeurs : le "besoin d'en connaître"¹². Il s'agit tout bêtement de ne communiquer une information sensible qu'aux personnes qui ont une raison légitime d'y avoir accès, c'est-à-dire en général personne, pour ce qui est des utilisateurs de services Internet.

Dans le cas qui nous intéresse, celui de la divulgation des informations sur les logiciels utilisés, cela peut se faire de plusieurs façons :

• on peut masquer les informations sur l'éditeur, le modèle et la version des logiciels utilisés,
• les remplacer par de fausses informations pour tenter d'intoxiquer l'adversaire¹³,
• ou bien les remplacer par des informations rappelant que les tentatives d'accès illicites seront poursuivies, histoire de faire un peu de dissuasion.

La série d'articles accessibles à partir de cette page explique comment faire cela pour les services réseau classiquement utilisés sous FreeBSD. Alors place à la créativité et vive les Powered by Unknown, by you don't need to know, by you must be joking, comme il vous plaira !

Les objections classiques

C'est de la sécurité par l'obscurité

Dès que l'on commence à parler de masquer les informations permettant d'identifier les logiciels que l'on utilise, on s'attire généralement une réponse quasi pavlovienne : "c'est de la sécurité par l'obscurité !"¹⁴. Traduction, "c'est mal !".

Il s'agit (souvent, mais hélas pas toujours...) d'un bien mauvais procès d'intention car :

• ce n'est pas parce que l'on masque ou remplace ces informations que l'on ne sécurise pas ses machines ;
• ce n'est pas non plus pour cela que l'on s'imagine que les logiciels utilisés ne seront pas malgré tout identifiés ;

Pour faire simple, ce n'est pas parce que l'on ne communique pas une information, qu'on la considère comme un secret, dont la divulgation affaiblirait la sécurité du système correspondant.

En fait, la notion même de sécurité par l'obscurité est très mal comprise. Elle devrait vraiment s'apprécier par son corollaire, "la sécurité par la transparence", c'est-à-dire par le bénéfice qui pourrait être retiré de la communication de l'information concernée.

Or ici, il est clair que la communauté des pirates est désormais la seule qui pourrait tirer un bénéfice de ces informations. Histoire d'enfoncer le clou, il ne s'agirait donc pas de sécurité par l'obscurité, mais plutôt d'insécurité par la transparence ! Après tout, vous viendrait-il à l'idée de publier la topologie de votre réseau, la liste de vos équipements de sécurité et les règles de filtrage de vos pare-feu ? Ces informations ne sont pourtant pas secrètes, non plus ¹⁵.

C'est inutile car les attaques sont systématiques

Une autre objection classique est que le masquage des informations permettant d'identifier les logiciels que l'on utilise ne sert à rien, parce que la plupart des attaques, aujourd'hui, sont automatisées et systématiques : c'est-à-dire qu'elles ne tiennent justement pas compte de ces informations.

En premier lieu cependant, toutes les attaques automatisées ne sont pas systématiques. Les récents vers visant Apache sont là pour le rappeler...¹⁶

Ensuite, ces attaques ne sont pas les plus dangereuses. On les repère en effet assez facilement et les systèmes de détection d'intrusions suffisent généralement à les contrer.

L'intérêt de la non divulgation est donc de gêner les gens qui ont suffisamment de talent pour monter une attaque discrète, en les obligeant à tâtonner un peu plus avant qu'ils ne puissent lancer une attaque décisive, ce qui augmente les chances de les détecter.

Ca ne sert à rien car l'identification d'un serveur est toujours possible avec un analyseur d'empreintes réseau

Certes, mais à bien y regarder :

• pour de multiples raisons, peu d'analyseurs d'empreintes réseau sont réellement efficaces ;
• il est généralement très simple de les contrer (ce que j'espère démontrer dans certains articles de la série) ;
• ils sont eux-mêmes souvent très facilement détectables (et donc bloquables ou intoxicables) ce qui permet d'atteindre un des objectifs du masquage : non pas la protection d'un secret (car encore une fois ça n'en est pas un), mais l'augmentation des chances de détection des individus un peu trop curieux...

Cela vaut donc tout de même la peine de masquer ces informations...

Cela rend la tâche plus difficile aux administrateurs

C'est ce que l'on entend parfois auprès de certains administrateurs qui ont recours aux chaînes de version affichées par les logiciels pour faire de l'inventaire de parc, ou encore à des outils de balayage de ports pour faire de l'inventaire de services réseau...

C'est un cas typique d'emploi d'outils inappropriés pour accomplir une tâche et, pour les deux exemples cités ci-dessus, bien peu fiables par dessus le marché !

Les logiciels modifiés sont plus difficilement maintenables

Cet argument là est déjà plus recevable que les autres.

Heureusement, comme on pourra le constater dans cette série d'articles, beaucoup de logiciels permettent le masquage ou le remplacement de leurs informations identifiantes par (relativement) simple paramétrage.

Pour les autres, disons que la génération d'une version modifiée donnera peut-être l'occasion de mieux en étudier la documentation et d'en optimiser le paramétrage ainsi que le binaire généré.

--
Hubert Tournier, le 17 décembre 2002.
(mis à jour le 14 janvier 2003, suite aux discussions sur le groupe fr.comp.securite).

1. C'était même apparemment une sorte de "private joke" entre les concepteurs, qui concluaient nombre des RFC originels par le paragraphe suivant : Security Considerations : Security issues are not discussed in this memo. [^]
2. Du moins, pour ceux qui prenaient la peine de lire et de comprendre (!) les spécifications des protocoles. Il y a, par exemple, le cas de cet obscur éditeur de la côte nord/ouest des Etats-Unis, dont les butineurs Web s'identifient encore aujourd'hui comme des "Mozilla/x.y (compatible;" :-) [^]
3. Voir, par exemple, OpenLDAP, Powered By. [^]
4. Cf. Bernard Lavilliers ­ Site officiel du chanteur français :: bio, discographie, partitions, textes. [^]
5. Voir, par exemple, The Sendmail Tutorial, à partir de la chaîne de caractères "WHAT THE HELL IS THIS THING?!". [^]
6. Notamment la base Bugtraq. [^]
7. Au point parfois, de passer à la phase d'exploitation sans passer par la case collecte ! [^]
8. Voir les "concours" de défiguration de sites sur Zone-H.org * Hall of Shame ou anciennement sur alldas.de defacement archives. [^]
9. D'où le succès des pare-feu personnels, entrés dans le top 10 des faits marquants du domaine de la sécurité dès l'an 2000. [^]
10. Cf. Les inoubliables dialogues des tontons flingueurs. [^]
11. Sachant que personne ne peut garantir une sécurité 100% efficace... [^]
12. A ce sujet, consulter la procédure administrative de protection d'informations sensibles. [^]
13. Afin, par exemple, de repérer les attaquants plus déterminés en branchant une alarme sur les tentatives d'exploitation de vulnérabilités du logiciel indiqué... [^]
14. Voir la définition du New Hacker's Dictionary qui, pour une fois, semble incomplète, notamment sur l'origine même de l'expression. [^]
15. J'invite les personnes intéressées par ce sujet à consulter l'excellent éditorial de Bruce Schneier : Secrecy, Security, and Obscurity, auquel j'ai emprunté le dernier exemple cité. [^]
16. Voir à ce sujet, le code source du ver FreeBSD.Scalper.Worm, bien que l'examen en diagonale de celui-ci ne m'ait pas semblé très probant. [^]