logo
DOSSIER : Sécurité informatique : comment se protéger ?
Dossier publié à l'adresse https://www.lagazettedescommunes.com/337105/plusieurs-milliers-de-site-de-collectivites-mal-securises/

VISUALISATION DE DONNÉES
Plusieurs milliers de sites Internet de communes mal sécurisés
Sabine BlancJulien Kirch | A la une | Dossiers d'actualité | France | Publié le 25/03/2015 | Mis à jour le 23/02/2017

La Gazette a dressé une carte indiquant le degré de sécurité de plus de 14000 sites de communes. Bilan : environ 6500 ne sont pas à jour.

Sécurité informatique des sites des communes françaises [1]

Peu après les attentats de janvier, de nombreux sites de collectivités ont été piratés [2]défacés [3] dans ces cas – par des anonymes soutenant les terroristes. Nul besoin d’avoir un bac + 12 en sécurité informatique pour faire tomber un site tant ils sont nombreux à être insuffisamment sécurisés.
Dans le cas de notre enquête, nous recensons environ 6500 communes françaises disposant d’un site qui est non seulement vulnérable, mais qui expose cette vulnérabilité aux personnes en quête de proies faciles.

Pour les identifier, « il suffit » en effet d’analyser le code source ou les en-têtes de la page d’accueil pour lire les versions du serveur, de l’application et du langage utilisées. Ces informations permettent de déterminer si un site est vulnérable à des failles de sécurité, ou du moins de donner des indications sur la manière de l’attaquer en vérifiant si les versions des logiciels utilisés ont fait l’objet d’alertes de la part des éditeurs ou de la communauté des développeurs.

Les risques varient en fonction de la faille, de l’habileté du pirate, de ses moyens et de son but : défaçage, intrusion dans le système pour y glisser des malwares (1) [4] qui contaminent ensuite les personnes qui se connectent, ou pour voler et/ou détruire des données…

Ce constat est inquiétant, alors que l’e-administration est un axe important de la modernisation de l’action publique et répond à une demande effective des citoyens. Or  la confiance est nécessaire [5] au bon déploiement de l’e-administration.

« Niveau de sécurité incertain » signifie que nous n’avons pas pu déterminer de façon sûre si le site est sécurisé ou pas (cf. encadré [6])

Le co-marquage service-public.fr comme base d’enquête

Notre enquête se base sur les données du co-marquage de service-public.fr [7], un service proposé par l’État permettant aux administrations centrales de diffuser des informations locales, soit quelque 15 000 sites référencés (2) [8]. Notre base de données est une photographie à l’instant T, en l’occurrence la première semaine de février. Entre-temps, certains hébergeurs ont effectué des mises à jour, notamment 1&1, dont les serveurs étaient alors exposés à une faille connue à ce moment. 98 sites sont concernés. (voir aussi encadré [9]).

Nos conclusions s’appuient donc sur les éléments visibles et déclarés sur chaque site, considérant que la version annoncée et/ou détectée est la version effectivement en place. Le bon réflexe en terme de sécurité sur internet est plutôt de cacher les versions utilisées que de mentir. Vous trouverez sur Github, ici [10] et [11], notre algorithme pour déterminer le niveau de sécurité. Vous y trouverez en détail la liste des outils encore supportés et donc sécurisés, ceux qui ne le sont plus et ceux où nous n’avons pas pu déterminer.

Guides des bonnes pratiques

Si votre site n’est pas sécurisé ou si vous ne le savez pas, pas de panique : l’Anssi, l’agence gouvernementale chargée de la sécurité des systèmes d’information, propose des documents accessibles pour appréhender cette matière ardue et, dans le cas d’un marché public visant à la construction d’un site internet, d’y faire figurer les conditions de sécurité ad hoc : le guide d’hygiène informatique [12] et la note sur la sécurisation des sites web [13].

Suite aux cyberattaques de janvier 2015, l’Anssi a aussi produit une fiche d’information pour les webmasters [14] et une fiche de bonnes pratiques [15], deux documents courts pour rappeler des fondamentaux, pas forcément coûteux. Enfin, elle vient de sortir une note sur les attaques DDOS [16], celles qui consistent à saturer un site de requêtes pour le faire tomber. Vous pouvez aussi vous adresser à ses observatoires régionaux [17], les OzSSI ou aux Clubs de la sécurité de l’information régionaux (Clusir).

 

Pour vivre heureux, vivons masqués

Même si des mesures techniques comme des pare-feu permettent de se protéger, masquer les données renseignant les versions logicielles et applicatives est la base d’une installation sécurisée. Pourtant, beaucoup de sites parmi ceux analysés ne respectent pas cette règle de bonne hygiène, qui ne coûte rien. Elle ne dispense en aucun cas d’avoir des outils à jour. La sécurité doit concerner toutes les briques logicielles qui composent un site, serveurs, langage de programmation et applications. Si deux briques sont très sécurisées mais que la troisième présente une faille, votre site n’est pas sécurisé. De même, la sécurité d’un site est un processus continu qui repose sur des mises à jour, un site n’est jamais sécurisé une fois pour toute, il l’est à un instant T, en attendant qu’une faille de sécurité soit découverte.


Create infographics [18]

La version du serveur, une information souvent non visible

Dans le détail, côté serveurs (3) [19], les sites de communes se montrent plus discrets (et donc plus sécurisés sur ce point) : la plupart d’entre eux n’exposent pas leur version dans la configuration par défaut, ce qui explique que plus des deux tiers des sites ne l’affiche pas. On connaît en revanche la technologie utilisée. Ce qui permet de relever que 2% des sites utilisent des versions de serveurs qui ne sont plus supportées.

Les trois quart des sites utilisent un serveur web Apache, une proportion plus important que pour la moyenne du web, [20] mais qui correspond au positionnement des sites de mairies qui ont en majorité peu de trafic, alors que Nginx est plutôt utilisé pour des sites à gros trafic [21].

Create infographics

Create infographics

Le langage de programmation, faille majeure

Seul un tiers des sites masque le langage de programmation utilisé. Parmi ceux qui le dévoilent, une majorité utilise le langage PHP, et la moitié indique aussi sa version. Parmi ces derniers, seuls 20% utilisent une version à jour. Or, plus une version est ancienne, plus elle présente des vulnérabilités.

Et la taille des villes ne change rien à l’affaire : une grande ville peut présenter les mêmes failles qu’une petite commune sans moyens, et des versions de langages anciennes. Nous avons dénombré 38 communes de plus de 50 000 hab. dont le site est mal sécurisé, sur 145, soit un bon quart. A contrario, Wisembach (406 hab.), Latillé (1480 hab.), Brié-et-Angonnes (2416 hab.), etc. ont des sites à jour, et mieux encore, bien d’autres masquent les informations, le bon réflexe en sécurité : Condé-sur-Marne (716 hab.), Falleron (1511 hab.), Charleval (2481 hab.), etc.

Toutefois, plus une ville est grosse, plus son site a des chances de présenter un bon niveau de sécurité (informations masquées ou site à jour), comme l’indique le graphique ci-dessous.

| Create infographics [18]

| Create infographics [18]

 

https aux abonnés absents

A l’origine, le protocole https, qui chiffre les données qui transitent entre une site et l’ordinateur de l’internaute, était essentiellement utilisé par les sites d’e-commerce. Mais son utilisation s’est peu à peu généralisée en même temps que le public commençait à s’intéresser à ces questions. Depuis 2014 [22], Google privilégie même les sites utilisant https dans ses résultats de recherches. De ce point de vue, les sites des villes ont bien du retard : sur les plus de 14000 sites de notre base, seulement 53 proposent une version sécurisée, et pour 16 d’entre eux ils s’agit de sites hébergés sur des plate-formes comme WordPress ou Google qui fournissent d’office cette fonctionnalité. Toutefois, il semble que la partie « espace personnel », là où les internautes laissent des données personnelles, utilisent https.

Autres enseignements

Les données récupérées à l’occasion de cette enquête permettent par ailleurs d’établir que, sur notre échantillon de 15 000 sites, l’immense majorité des communes françaises de plus de 5000 habitants ont un site. Les exceptions concernent surtout l’outre-mer : Parmi les communes qui n’ont pas de site, certaines se sont rabattues sur une page Facebook, par exemple Baillif en Guadeloupe [23]. L’office du tourisme en revanche peut avoir un site correctement fourni. On peut aussi relever certaines communes qui, en l’absence de site propre, renvoient directement sur leur intercommunalité. A noter aussi que M’Tsangamouji, à Mayotte, a un site dont l’accès… est soumis à mot de passe [24] : une sécurité parfaite, mais pas forcément un exemple à suivre.

Villes de plus de 5000 hab. sans site [25] | Create infographics [18]

Logiquement, la proportion de villes ayant un site internet augmente régulièrement avec la population pour atteindre les 90% pour les villes de plus de 3000 personnes.

| Create infographics [18]

 

Comment avons-nous déterminé si une version de PHP est à jour ?

De nombreux sites présentent un “niveau de sécurité incertain”, ce qui signifie que nous n’avons pas pu déterminer de façon certaine si le site est sécurisé ou pas. Cela provient de la manière dont les logiciels sont développés et installés. Nous allons prendre l’exemple de PHP, le langage majoritairement utilisé. Il existe deux moyens d’avoir une version de PHP à jour :

  • Utiliser une des dernières versions de PHP sorties, elle sont à jour de toutes les failles de sécurité. Si une faille est détectée, l’éditeur sort une nouvelle version et il faut la mettre à jour.
  • Utiliser une version de PHP packagée dans un système d’exploitation supporté par un éditeur ou une communauté de développeurs. Dans ce cas la version de PHP est choisie lors de la sortie du système d’exploitation, et l’équipe en charge de la sécurité dans l’entreprise ou la collectivité, ou la communauté qui s’occupe du système d’exploitation récupère les correctifs de sécurité disponibles dans les nouvelles versions de php et les intègre dans sa propre version. Le numéro de version peut alors ne pas être modifié au sein du système d’exploitation packagée, ce qui n’empêche pas de disposer d’une version à jour.

Malheureusement pour nos analyses, il n’est pas possible, à partir des informations récoltées, de déterminer dans quel cas on se trouve. Le degré de sécurité du site au niveau du langage de programmation est donc incertain. En effet, lorsqu’un site utilise une version de php distribuée dans un système d’exploitation, trois cas sont possibles :

  • la version distribuée dans un système d’exploitation et le système ont été mis à jour : la version de PHP est sécurisée.
  • la version distribuée dans un système d’exploitation et le système n’ont pas été mis à jour : la version de PHP n’est pas sécurisée.
  • une version installée manuellement dans un système d’exploitation différent de son système d’origine : elle n’a donc pas bénéficié des patches de sécurité.

Exemples :

  • Version 5.4.37 : une des dernières version de php sorties et qui ne contient pas de faille de sécurité identifiée. Elle est donc à jour.
  • Version 4.1.2 : une version très ancienne de php, aucun système d’exploitation supporté actuellement ne l’utilise.
  • Version 5.4.20 : une version qui est utilisée par au moins un système d’exploitation supporté actuellement (OpenSuse 13.1) : on est dans un des trois cas décrit ci-dessus, il est donc impossible de savoir si elle est sécurisée.

Ce même procédé est appliqué pour toutes les briques logicielles pour laquelle nous disposons d’informations suffisantes.

Les failles de sécurité ont été catégorisées manuellement pour ne retenir que celles qui sont pertinentes pour le site d’une commune. Ainsi une version d’un logiciel comportant une faille sur une fonctionnalité qui n’est pas utilisée sur ce type de site est tout de même considérée comme sécurisée. La mise à jour d’un site pouvant être compliquée, les administrateurs font parfois le même genre d’évaluation pour savoir si elle est nécessaire ou si on peut s’en passer.

Faut-il publier ces données ?

Plusieurs internautes se sont interrogés sur la pertinence de la publication du détail des données, voire ont indiqué qu’ils trouvaient notre démarche irresponsable. Nous avons eu ce même débat au sein de la rédaction, avant de publier l’article et la carte. N’allaient-on pas encourager des hackers à cibler les sites désignés comme faillibles ? Est-ce le rôle de la Gazette de stigmatiser les communes, souvent petites, qui n’ont pas de site à jour en matière de sécurité ? Voilà les deux questions avancées, au sein de la rédaction, pour défendre la non publication de l’enquête. Une position intermédiaire défendait l’idée de publier les chiffres globaux, mais pas les données détaillées, commune par commune. Au final, nous avons estimé :

  • Des sites de collectivités ont été piratés début janvier, et avant encore, ce qui montre que les hackers n’ont pas besoin de notre article pour lancer leurs actions.
  • Si des journalistes ont eu l’idée d’identifier les failles des sites, il est évident que d’autres, peut-être avec des intentions malveillantes, l’ont aussi. De surcroît, à l’heure de la transparence permise par Internet, taire un fait en espérant qu’il n’émergera pas est une pure illusion. Des dizaines et dizaines de sites expliquent dans les moindres détails comment hacker un site.
  •  Nous ne montrons pas comment pirater un site. Notre enquête identifie les sites qui présentent des failles qui peuvent être exploitées par des hackers. Ce qui n’est pas du tout la même chose.
  • Notre travail consiste à alerter les communes sur d’éventuelles faiblesses de leurs sites, pour sécuriser leurs services. Nous sommes bien dans le rôle de La Gazette, qui explore en permanence la qualité des politiques publiques.

L’ensemble de ces arguments ont finalement plaidé pour la publication de l’article, de la carte, et des données détaillées : en l’occurrence, c’est cette transparence qui peut freiner des initiatives de hackers, car elle permet la mobilisation des communes concernées, en connaissance de cause.
Romain Mazon, rédacteur en chef web La Gazette des communes, Sabine Blanc et Julien Kirch.

Une nouvelle carte mise à jour dans un mois

Suite à notre article, certains webmasters nous ont indiqué avoir mis à jour leur site, ce qui était un de nos buts principaux. On nous a aussi signalé la sortie d’une nouvelle version de PHP. Pour mesurer l’impact lors de ce travail et reconnaître le professionnalisme des webmasters qui se sont montrés réactifs, nous ferons donc une nouvelle passe dans un mois, avec une nouvelle carte.

Projet réalisé sur une idée de Julien Kirch, qui a scrappé les données et formalisé l’analyse technique.

REFERENCES


POUR ALLER PLUS LOIN