Archives de catégorie : Sécurisation

La catégorie Sécurisation contient différents principes permettant de sécuriser un objet informatique, de façon théorique (par rapport à un concept) ou pratique (en réponse à une actualité).

S3

S3 (Amazon Simple Storage Service) est un service de stockage d’objets en ligne d’Amazon Web Services (AWS). Bien que très pratique, il peut être très mal utilisé. Résultat : on assiste en ce moment à un florilège de divulgation de données via des S3 fonctionnant très bien mais mal paramétrés.

Il existe des variantes avec d’autres produits mal configurés, comme le service ElasticSearch, qui peut se révéler tout aussi fatal aux informaticiens peu consciencieux (ou débordés), ou la base MongoDB mal sécurisée par défaut.

frame

Responsabilité partagée

La presse se fait souvent l’écho de fuite d’informations liées à S3, allant parfois jusqu’à annoncer une faille sur S3. Or il s’agit d’un service d’infrastructure (IaaS), dont la sécurité est partagée entre le fournisseur d’accès et le client utilisateur du service : le fournisseur est responsable de la sécurité du cloud, le client est responsable de la sécurité dans le cloud.

Le fournisseur est responsable du bon fonctionnement du service, rien de moins mais rien de plus : il doit juste répondre au contrat de service. Par exemple, s’il y a un mécanisme d’autorisation d’accès, il doit s’assurer qu’il est efficace et qu’il fonctionne comme attendu, sans erreur, sans interruption, etc.

De l’autre côté, le client paramètre ce mécanisme d’autorisation d’accès comme il le souhaite. S’il laisse son compartiment S3 ouvert à tout vent (par erreur, par mégarde, par bêtise), c’est de sa faute.

Les failles S3, à qui la faute ?

Et bien jusqu’à présent, toutes les failles sur S3 sont dues à un mauvais paramétrage par le client. Pourtant AWS indique en grand le risque encouru, lors du paramétrage.

Tant et si bien qu’à partir de février 2018, AWS ajoute gratuitement le contrôle sur les droits d’accès sur S31 dans son service Trusted Advisor (ce contrôle était jusqu’alors réservé aux clients ayant un niveau de support payant). Début 20182, on estimait que 7% des buckets S3 étaient accessibles en lecture sans restriction (ce qui est parfois voulu, pour l’hébergement d’éléments web statiques), et que 2% étaient également accessible en écriture sans contrôle (là je suis moins sûr que ça soit normal).

frame

Aujourd’hui ?

Il faut vraiment être neuneu pour laisser un bucket ouvert : AWS a rajouté plein d’outils, de procédures, d’informations affichées pour qu’on ne se prenne plus les pieds dans le tapis.

Quelques exemples

  • Mars 2018
    • 1,3 millions de données client de Walmart (bijouterie) exposés3.
    • Keeper, un gestionnaire de mots de passe, laisse traîner des fichiers en lecture-écriture4.
  • Avril 2018
    • 1,2 To de données correspondant à 48 millions de personnes, non protégées par LocalBox, une société de profilage publicitaire au profil douteux5.
  • Mai 2018
    • Divulgation de données de 15 ou 20 000 joueurs de cricket indiens67.
    • Divulgation de données du service social de Los Angeles8.
    • Mots de passe de l’application TeenSafe en clair9.
    • Une société d’assurance (AgentRun) laisse des milliers de données de souscripteurs10 en accès libre
    • Honda laisse à disposition les informations de 50 000 véhicules et de leur propriétaires11.
  • Juillet 2018
    • Des milliers de données électorales américaines ont été exposées publiquement par une petite société (Robocall) qui les commercialisait12.
    • Une société israélienne expose des données de 14 millions de clients13 de l’opérateur téléphonique Verizon.
  • Août 2018
    • GoDaddy, un célèbre hébergeur web, laisse des informations d’infrastructures de 24 000 machines sur un bucket S3 mal configuré14.
  • Septembre 2018
    • Une société disons de surveillance (= qui produit un logiciel d’espionnage, surfant sur la vague de peur pour alimenter celle de l’insécurité) a laissé une quantité astronomique15 de données récoltées auprès des utilisateurs surveillés accessibles sur S316.
  • Avril 2019
    • Intéressant : 146 Go de données d’utilisateurs Facebook laissés en accès ouvert par des éditeurs tiers17.
  • Juin 2019
    • 1 Tb de données de sauvegardes (comprenant des clés privées) exposées par Attunity (qui a des clients de l’envergure de Netflix ou Ford).

La faute d’Amazon ?

Il n’y a pas qu’Amazon qui soit touché puisque la plupart des fournisseurs de services nuagiques proposent des services permettant le partage de façon publique ; on a vu que Google via Groups recelait de très nombreux documents18 qui n’ont pas à être exposés au grand public. Or les personnes ayant le rôle d’administrateur Google Groups n’ont pas toujours de hauts compétences en administration19, ce qui est normal vu le public visé par le service de Google.

Répétons : le problème ne vient pas du fournisseur de services, ni du service, mais de son utilisation.

Faut-il utiliser S3 ?

A mon humble avis, il faut l’éviter autant que faire se peut. Certes les usages potentiels sont nombreux, certains sont justifiés, d’autres non.

Hébergement de site web statique

AWS met en avant cet usage qui est parfaitement stupide. En effet, avec AWS, comme rien n’est gratuit, on paye à la bande passante utilisée mais aussi en fonction du nombre d’accès. Et ça va très vite…

Le seul usage raisonnable que je vois est de stocker des objets de livraison, qui doivent être accessibles facilement et dont on ne se sert qu’épisodiquement (pour construire une machine virtuelle, déployer une application, etc.).

Alors pourquoi AWS met en avant des usages du type site web statique ou fichiers statiques ? Simple : vous imaginez AWS vous dire d’économiser votre budget et de ne rien dépenser sur leurs infrastructures ?

Innovons dans les attaques

Parfois, il est normal et voulu que des fichiers soient stockés sur un bucket public : on peut même faire un site web statique rien qu’avec S3. Dans ce cas, les fichiers sont disponibles publiquement et c’est le comportement désiré.

Alors les attaquants se sont tournés vers ces fichiers publics pour les compromettre et tenter d’injecter du code ou n’importe quelle cochonnerie, par exemple sur Magecart20. Dans ce cas là, il s’agit d’un problème de gestion des droits, mais de façon plus fine, dans le contrôle d’accès de S3.

Voir aussi

Articles externes

ElasticSearch

ElasticSearch est un moteur de recherche et d’analyse RESTful distribué, d’après son site web (elastic.co). Très utilisé et même proposé sous forme de service par AWS, ce produit permet de gérer des recherches sur de grandes quantités de données.

C’est bien.

Mais cela devient moins amusant quand on le configure mal, les informaticiens pouvant être peu consciencieux ou débordés. Le résultat est alors sans appel : des moteurs de recherche internet (comme Shodan) indexent (trop) facilement les contenus mal protégés, et l’énorme quantité des données gérées par ElasticSearch deviennent purement et simplement disponibles et accessibles à la moindre requête anonyme.

D’après Shodan1, en 2018, 900 To de données ElasticSearch sont disponibles sans protection, et plus de 5 Po de données pour de clusters Hadoop.

Fuites de données

Exactis

Il s’agit du premier cas que j’ai repéré (ça qui ne signifie pas qu’il s’agisse du premier). La volumétrie fait peur : 2 To de données de 340 millions d’utilisateurs2. Pas de cartes bancaires, mais tout un tas de données de profilage, relevant de la vie privée, mais pouvant aussi servir à répondre aux questions de sécurité pour récupérer (frauduleusement) un accès à un quelconque service de messagerie, de réseautage social, etc.

Durée de vie

Ne pas faire attention et laisser les paramètres par défaut peut rapidement conduire à de gros ennuis : une étude de 2020 indique qu’une base non sécurisée est repérée par les méchants en huit heures3. Ils sont à l’affût !

Tellement courant

Les fuites de données dues à une mauvaise mise en oeuvre d’ElasticSearch sont si courantes que la CNIL a publié un guide de bonnes pratiques.

Moteur de recherche et d’analyse Elasticsearch : 4 bonnes pratiques pour renforcer la sécurité des données

Principe d’Elasticsearch

Elasicsearch est un outil de recherche, open source, très populaire. Son fonctionnement repose sur les index inversés, ou inverted indexes, qui recensent des caractéristiques associées à ces documents, comme par exemple des mots clés, mais il peut y avoir bien d’autres usages, comme le traitement d’un grand nombre de logs, sujet très pertinent en sécurité informatique.

Index inversé

Un index inversé est créé après examen de chacun des documents (« crawling »), et création des caractéristiques associées, que l’on définit selon ses besoins. A la suite de cela, on crée un index partant de ces caractéristiques et pointant vers les documents correspondant le mieux aux caractéristiques recherchées.

Dans des moteurs de recherche web (Yahoo, Google, Bing…) on tape une liste de mots clés, et l’index inversé nous renvoie les pages web les plus pertinentes qu’il a recensé auparavant.

Apache Lucene est un outil open source permettant l’indexation de documents, sur lequel est basé Elasticsearch, qui est une société commerciale mais qui propose des versions gratuites de son produit (qui reste open source).

Cluster

Conçu pour des requêtes complexes, et un nombre de documents très important, Elasticsearch se structure en clusters, dont chacun peut contenir de un à plusieurs milliers de nœuds, chaque nœud étant une machine de traitement.

Sharding

On comprend qu’une requête peut être complexe et avoir besoin de beaucoup de ressources, et donc utiliser plusieurs nœuds. De même, il peut arriver que l’indexation produise des tables si grandes qu’elles ne tiennent pas sur un seul nœud. Pour cela, on peut scinder un index sur plusieurs nœuds ; cela s’appelle le sharding.

Réplication

Comme toute bonne architecture distribuée digne de ce nom, toute donnée doit être dupliquée (ou répliquée) afin de pallier aux accidents mais aussi pour paralléliser les traitements, et Elasticsearch le permet.

Manipulons

ElasticSearch (que je vais abréger en ES) se manipule via des API Rest. Ce gros mot signifie qu’on appelle des requêtes HTTP avec une logique définie. Autant je trouve ça super pour développer une appli web, autant c’est pénible pour mes petits doigts quand il faut taper les commandes avec curl. Heureusement Kibana est une interface web qui permet de réaliser la plupart des opérations sur ES.

Opérations CRUD

Pour créer un index : 

$ curl -XPUT 'localhost:9200/documents'

Pour ajouter un document (de format JSON) : 

$ curl -XPUT 'localhost:9200/alerts/cloudtrail/1?pretty' -H 'Content-Type: application/json' -d fichier
$ curl -XPUT 'localhost:9200/alerts/cloudtrail?pretty' -H 'Content-Type: application/json' -d fichier

Les arguments sont le nom de l’index, le type du document, et son identifiant (facultatif). Pour un fichier JSON, depuis la version 6, il faut rajouter le type dans le header. Chouette.

Pour afficher les champs id et version du document #1.

$ curl -XGET 'localhost:9200/logs/cloudtrail/1?pretty&_source=id,version'

Pour savoir simplement si le document #1 existe :

$ curl -i -XHEAD 'localhost:9200/logs/cloudtrail/1?pretty'

Pour modifier un document :

$ curl -XPOST 'localhost:9200/alerts/cloudtrail/1?pretty' -H 'Content-Type: application/json' -d fichier

Il faut utiliser POST sur un document existant, et seuls les champs modifiés ont besoin d’être présents dans le fichier, lequel peut également « scripter » le résultat.

Sans surprise, pour supprimer un document, voici la commande :

$ curl -XDELETE 'localhost:9200/alerts/cloudtrail/1?pretty'

Pour avoir différentes informations sur le cluster, il faut jouer avec les commandes _cat.

$ curl -XGET 'localhost:9200/_cat/'
=^.^=
/_cat/allocation
/_cat/shards
/_cat/shards/{index}
/_cat/master
/_cat/nodes
/_cat/tasks
/_cat/indices
...

D’autres commandes utiles sont : _mget, _bulk.

Statut du machin

Différentes commandes permettent d’avoir des infos sur la santé d’ES. Exemples :

$ curl -XGET 'localhost:9200/_cat/health/?v&pretty'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1535634422 15:07:02 elasticsearch yellow 1 1 6 6 0 0 5 0 - 54.5%

$ curl -XGET 'localhost:9200/_cluster/health/'
{"cluster_name":"elasticsearch","status":"yellow","timed_out":false,"number_of_nodes":1,"number_of_data_nodes":1,"active_primary_shards":6,"active_shards":6,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":5,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":54.54545454545454}

$curl -XGET 'localhost:9200/_cat/indices/?v&pretty'
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open .kibana ppRzSXt0Q8G8OXZg8o7_tQ 1 0 2 0 103.4kb 103.4kb
yellow open logs 8YYRLl5_SauA2sglf9YRfA 5 1 36886 0 32.2mb 32.2mb

Recherches et analyses

Les recherches sont similaires à ce qu’on imagine pour un moteur de recherche, tels que Google ou Yahoo. Un langage permet de créer la requête qui vous conviendra et qui vous rendra riche et célèbre, appelé DSL. Rien de mystérieux dans ce langage calqué sur du JSON, il est très souple et très puissant et permet de scripter des requêtes plus ou moins évoluées. Tout comme SQL, on arrivera facilement à faire des requêtes simples, alors que les requêtes complexes demanderont beaucoup de grattage de tête. Point important : les requêtes sont stateful, ce qui signifie qu’il n’y a pas de mécanisme genre curseur comme en SQL.

En gros, on peut demander quels sont les meilleurs documents selon nos critères, auquel cas un score est calculé (et peut être expliqué dans la réponse) et les meilleurs résultats sont affichés ; sinon on peut filtrer et demander si un enregistrement satisfait à nos critères ou pas (la réponse est alors binaire).

La puissance de l’algorithme

TF/IDF de son petit nom, l’algo qui sert de base pour le calcul du score des documents. Il doit être recalculé à chaque ajout de document, mais il ne dépend que de la base de documents indexés, et de rien d’autre. Il est au cœur du fonctionnement d’ES, mais je n’ai pas trouvé de présentation récente de son fonctionnement sur le site ES ; on peut trouver l’info ici (compose.com) ou ici (sur le site de Lucene, le moteur d’ES).

  • TF : Term frequency, calculé comme étant la racine carré du nombre d’occurrences d’un terme dans un document ; cela permet de savoir à quelle fréquence un terme apparaît dans un champ. Plus un terme apparaît dans un document, plus le document est pertinent ;
  • IDF : Inverse Document Frequency (à expliciter). Il permet de savoir à quelle fréquence un terme apparaît dans un index. Plus un terme est fréquent dans un index, moins il est différenciant.
  • La longueur d’un champ intervient aussi (plus la longueur du champ est court, plus l’apparition d’un terme à l’intérieur de celui-ci a de la pertinence). Ainsi, un terme trouvé dans le titre d’un livre induira un score plus élevé que s’il est trouvé dans le corps du texte du livre.

Quand une requête est lancée, les informations demandées dans la requêtes sont combinées avec les résultats de l’algo TF/IDF, et un score est associé à chaque document. Le tour est joué.

Analyse de données

ES permet aussi de réaliser des agrégations de données, ouvrant ainsi la possibilité à l’analyse de données (« analytics »). Il existe quatre types d’agrégation dans ES (je chercherai s’il existe une traduction) :

  • « Metric » qui permet de faire des calculs sur l’ensemble des données (ou sur un groupe logique, cf ci-dessous). Cela se rapproche des AVG(), SUM() du SQL ;
  • « Bucketing » réalise des groupes logiques de données à partir d’une requête de recherche, similaire au GROUP BY en SQL ;
  • « Matrix » est une fonction expérimentale portant sur plusieurs champs en même temps (à développer) ;
  • « Pipeline » permet d’enchaîner les agréations.
Champs textes

Les champs texte, de format assez libres, ne sont pas par défaut inclus dans les champs pouvant être requêtés (sic), car cela consomme beaucoup de ressources à indexer (et donc de mémoire). Si on souhaite pouvoir filter et requêter sur ces champs, il faut explicitement demander qu’ils soient intégrés dans le fielddata, qui est l’espace mémoire servant justement à ce type de requêtes.

Voir aussi

Mot de passe

Le mot de passe est un élément extrêmement sensible dans la chaîne de la sécurité. C’est le point faible le plus souvent rencontré et, forcément, le plus souvent utilisé pour les piratages et les actes malveillants. Il ne sert à rien de sécuriser sa connexion SSH si vous laissez un mot de passe faible…

On s’en débarrasse bientôt ?

Euh non. Nul ne peut prédire l’avenir, mais tout comme on nous promet depuis 30 ans des merveilles de l’intelligence artificielle, on nous annonce depuis des années la fin du mot de passe. J’attends toujours. Ca devient drôle quand on voit des articles entiers consacré au sujet, et se terminer de façon sibylline1 en disant qu’il faudra peut-être le garder en secours. On ne sait jamais, on n’est jamais trop prudent.

Pot de Masse : grands principes

Trois principes forts :

  • Tous les utilisateurs (ayant des privilèges élevés, et donc a minima le user root) doivent avoir un mot de passe fort.
  • Aucun utilisateur ne doit pouvoir se connecter au système sans mot de passe, et encore une fois l’idéal est que tout utilisateur ait un mot de passe fort.
  • Un mot de passe doit rester secret.

Inutile de compter sur la biométrie pour remplacer les mots de passe ; quand à une alternative sérieuse et crédible, je n’en connais pas aujourd’hui.

Autre recommandation très utile : utiliser un gestionnaire de mots de passe (de codes secrets) éprouvé et réputé, comme KeePass.

C’est quoi un mot de passe fort ?

C’est un mot de passe difficile à trouver. Mais encore ?

  • Un mot de passe ayant au moins 8 caractères de long (c’est un minimum), voire plus ;
  • Il ne doit pas contenir de mot du dictionnaire, de nom propre ou facile à deviner ;
  • Il doit contenir des caractères, des chiffres, de majuscules, des minuscules ;
  • Il faut utiliser des caractères spéciaux si c’est possible (genre * ! ; ? _ ç ou ce que vous voulez) ;
  • Ne doit avoir aucun rapport avec le site, avec l’auteur du site, etc ; par exemple, n’utilisez pas le nom de votre chat ou chien, votre date de naissance, votre surnom ;

Exemple de bon mot de passe : Zs01_A!rt

Exemple de mauvais mot de passe : sitejean, 23051991 (ma date de naissance), motdepassesecure, adminpwd, …

Ça n’est pas parce que le mot de passe est long que la protection est assurée : il faut à la fois une certaine longueur mais il faut aussi de la complexité. Mine de rien, ça suffit à se protéger d’une bonne partie des attaques sans trop se casser la tête. Ça vaut le coup de faire ce petit effort, non ?

Faut-il changer régulièrement son mot de passe ?

Pas si évident que ça. Par exemple, si vous êtes au bureau et que la politique de sécurité de votre entreprise vous oblige à changer régulièrement votre mot de passe, on induit un risque dérivé : celui que vous écriviez votre mot de passe sur un bout de papier (car vous finissez par oublier votre mot de passe tellement vous le changez souvent) ; même rangé dans un tiroir, l’accès à ce précieux sésame restera d’une facilité infinie. Donc il vaut parfois mieux un bon mot de passe, respectant les principes ci-dessus, et qui n’apparaisse que dans votre tête !

Idéalement, il ne faut changer son mot de passe que s’il a été compromis, ou si on suspecte qu’il a été compromis2, mais on ne le sait pas toujours.

Comment savoir si mon mot de passe est compromis ?

Bêtement : s’il est dans le top 25 des mots de passe les plus utilisés, laissez tomber. Sinon, un site tente d’agréger tous les mots de passe issus de fuites de données connues (cf ci-dessous), et s’il est impossible que le site soit exhaustif, on peut être sûr que si son mot de passe y figure, c’est mort…

Une initiative intéressante

Troy Hunt a eu l’idée de compiler un maximum de mots de passe ayant été exfiltré au cours du temps3, en les regroupant dans une base unique. Ainsi, il est facile de savoir si son mot de passe est à risque, car s’il est apparu quelque part, il y a fort à parier qu’il sera testé en priorité par des pirates.

Un outil4 exploite également cette base : 1password. Je ne connais pas la qualité de cet outil, mais ça peut être également utile.

Comment retenir un mot de passe complexe ?

En ne le changeant que rarement (cf paragraphe précédent, en respectant les restrictions d’usage), ou en le construisant selon une méthode souvent recommandée : chaque caractère est l’initiale des mots d’une phrase.

Exemple 1 : MFp?KilB2 (traduction : Mon Film préféré ? Kill Bill 2)

Exemple 2 : g1so210L (traduction façon SMS : j’ai un seau de 10 litres)

Après il faut jouer avec les majuscules/minuscules, etc. A vous de voir si ça peut vous faciliter la vie. Moi j’avoue ne pas m’en servir, mais l’essentiel est de trouver ce qui vous convient le mieux.

Le fameux mot de passe par défaut

  • https://news.sophos.com/fr-fr/2018/03/29/mots-de-passe-par-defaut-objets-connectes-sur-google/

Mot de passe sous Windows

What Happens When you Type Your Password into Windows? (syfuhs.net)

Au sujet des attaques

Quelques attaque amusantes

  • L’usage de la caméra intégrée aux PC portables pour regarder votre frappe clavier ;
  • Les keyloggers (enregistreurs de frappe) ;
  • Plus rigolo : l’analyse de nos traces thermiques. Pas forcément très fiable, mais peut être réalisée sans accès logique à la machine, ni accès physique direct, ni même être réalisée exactement au moment de la frappe : il suffit d’une caméra thermique. Cependant, les scénarios d’attaque sont limités.

Quelques types d’attaque

  • L’attaque par force brute consiste à tester une grande quantité de mot de passe sur un même compte. Elle est facile à détecter et à contenir (en limitant le nombre de tentatives dans un laps de temps donné), à condition d’y penser ! Pour éviter la détection, certains utilisent des botnets pour répartir les tentatives dans le temps et sur différentes IP, afin de brouiller les détections5.
  • Le credential stuffing est la réutilisation (souvent automatisée) d’identifiants valides sur une multitude de sites, en partant du principe que les utilisateurs réutilisent souvent leurs mots de passe…
  • Password spraying, ou pulvérisation de mot de passe (traduction ANSSI), qui consiste à essayer quelques mots de passe communs sur une grande quantité de comptes.
  • Le shoulder surfing est l’observation directe par l’attaquant du mot de passe, en regardant ce que fait l’utilisateur (par dessus son épaule notamment).

Recommandations

Le groupe Gartner recommandait les huit pratiques suivantes (avec mes commentaires) :

  1. Mettez en place un système de blocage automatique des sessions. La session est bloquée soit après une période d’inactivité d’une durée définie, soit lorsque le « token » d’identification de l’utilisateur s’éloigne du poste de travail. C’est souvent une règle de base du système d’exploitation ; cela peut également être complété par certains outils.
  2. Utilisez un système de blocage en cas de tentatives d’accès répétées avec des mots de passe erronés. Le mieux est de mettre en place un blocage temporisé, qui présente l’avantage d’être plus robuste en cas d’attaques visant à bloquer les comptes utilisateurs (attaque équivalente à un déni de service). Ce travail est effectué par certains HIDS comme Ossec, dont je parle sur le site.
  3. Mettez en oeuvre une authentification forte. Les attaques automatiques simples deviennent alors inefficaces. Cela n’est hélas pas possible sur un serveur à distance dutype OVH ou Dedibox, il faut se contenter de l’authentification par mot de passe. L’authentification forte fait appel à des systèmes physiques comme des cartes générant des mots de passe périodiques.
  4. Limitez (ou au moins contrôlez) le nombre de sessions simultanées ouvertes avec un même identifiant. Idéalement, il ne devrait y avoir qu’une personne utilisant un identifiant donné, à un instant donné. Si l’on est amené à tolérer l’utilisation épisodique de sessions simultanées, il n’est tout de même pas normal d’avoir deux sessions simultanées, ouvertes sur des postes situés dans les lieux éloignés. De plus, il est possible d’identifier les comportements anormaux, comme par exemple des connexions depuis l’extérieur avec des identifiants appartenant à des gens travaillant au bureau. Cette recommandation est valable pour les postes de travail comme pour un serveur. Inconvénient : en cas d’attaque avérée, si quelqu’un se connecte en root, personne d’autre (y compris l’administrateur véritable) ! ne pourra se connecter.
  5. Rappelez toujours aux utilisateurs, au démarrage d’une session, les dates et heures de début et de fin de leur session précédente ; et apprenez-leur à contrôler la justesse de cette information. Inutile pour un serveur à distance s’il n’y a que l’administrateur qui s’y connecte.
  6. Accordez toujours, par défaut, des autorisations minimum aux acteurs. Il est plus facile d’ouvrir ensuite les droits indispensables que d’accorder des droits très larges au départ, puis de supprimer ensuite les droits inutiles. En effet, il faut se souvenir que les droits inutiles constituent autant de failles potentielles.
  7. Assurez-vous que les comptes périmés sont supprimés ou inactivés le plus vite possible. Suivez également la création d’utilisateur (Ossec le permet) : rien ne doit se faire sans l’accord de l’administrateur…
  8. Surveillez et protégez-vous contre les codes malins. En effet, les logiciels espions, notamment, sont capables de voler facilement les mots de passe. Pour cela, HIDS, pare-feu et tous les outils recommandés sur ce site.

Sources

Voir aussi

Articles connexes

Liens externes

Windows (sécurité)

A la question « Windows est-il sûr », je ne saurais pas répondre, désolé. Pour autant, est-il plus sûr qu’avant, là d’autres ont répondu oui. Il faut reconnaître que la plupart des grandes sociétés et éditeurs informatiques font des efforts, et Windows 101 est beaucoup moins sensible (c’est-à-dire moins infecté par des programmes malveillants) que Windows 7.

https://www.webroot.com/us/en/about/press-room/releases/ransomware-and-cryptojacking-threats

Ring 0

Mais malgré les nombreux et constants efforts de Microsoft pour sécuriser au maximum le noyau de Windows, des chercheurs finissent presque toujours par trouver un biais ou un scénario permettant d’atteindre le nirvana du pirate Windows, à savoir un accès en « ring 0 », ou encore le niveau le plus interne du système d’exploitation où le code exécuté dispose de tous les droits.

Un scenario possible2 a été présenté en DefCon 2018, en utilisant un driver spécialement préparé pour l’attaque. Au final, le pirate ayant tous les droits, il peut désactiver toutes les protections sans aucun obstacle, même avec un système conçu spécialement pour être hautement protégé (comme présenté par Microsoft dans un article « Standards for a highly secure Windows 10 device »),

Bonnes pratiques

Sécurisation RDP

  • https://security.berkeley.edu/resources/best-practices-how-articles/system-application-security/securing-remote-desktop-rdp-system
  • https://www.ssi.gouv.fr/uploads/IMG/pdf/Securite_de_RDP_article.pdf
  • https://remotedesktopmanager.com/fr/compare

Voir aussi

Liens utiles

Vieux pots

C’est dans les vieux pots1 qu’on fait les meilleures confitures. En 2016, la vulnérabilité la plus utilisée sur Windows date de 20102 ! Pour la petite histoire, à l’époque, il s’agissait d’une faille Windows inconnue du public et des spécialistes, sans correctif, et qui a servi à l’opération contre les centrifugeuses nucléaires iraniennes. Probablement utilisée par des équipes de très haut niveau, ayant des moyens considérables, soit pour découvrir cette faille soit pour l’acheter (puisqu’il existe un marché pour cela).

Ensuite, cette vulnérabilité entre dans un cycle de vie prévisible : elle finit par être connue en juillet 20103, corrigée rapidement par l’éditeur concerné (Microsoft en l’occurrence, puisqu’il s’agit de Windows), en août 20104. La suite ? Il suffit à tous les utilisateurs (particuliers ou entreprises) de mettre à jour leur(s) Windows, et ils sont protégés.

Protégés ?

Oui. A condition d’avoir mis à jour Windows, donc. Et que constate-t-on en 2017 ? Que la faille est encore très utilisée. Donc que de très nombreuses installations de Windows n’ont pas été mises à jour depuis au moins 6 ans ! Et c’est bien tout le problème : une excellente mesure d’hygiène informatique consiste à avoir des composants (système d’exploitation, logiciels importants et/ou souvent utilisés) à jour, pour laisser peu de temps à l’exploitation des failles. Or on voit bien qu’on est très loin de ça…

Pour enfoncer le clou, une étude de Fortinet5 de 2017 ne dit rien d’autre :

[…] dans 90 % des cas, les victimes ont été attaquées par le biais de failles datant de plus de 3 ans et dans 60 % des cas, ces failles étaient vieilles de 10 ans voire plus.

Idem en 2020, on pourrait multiplier les exemples : Palo Alto nous indique que les vulnérabilités les plus fréquemment utilisées ont été identifiées en… 2012 !

Applications web

Il en est de même, mais de façon légèrement différente, dans le monde des applications web. L’OWASP, ainsi que d’autres entreprises de sécurité6, recensent depuis longtemps les types de vulnérabilités les plus utilisées et les plus présentes dans les applications web, et force est de constater que depuis de très nombreuses années, on retrouve immanquablement les mêmes typologies de failles. Les failles XSS et d’injection SQL sont indéboulonnables.

Applications mobiles

Errare humanum est, perseverare diabolicum. L’adage bien connu s’applique toujours, et les développeurs d’applications mobiles ont l’air de répéter les mêmes erreurs que pour les applications web. Personne ne peut écrire de code parfait et exempt de toute faille de sécurité, mais tout le monde doit savoir qu’aujourd’hui il faut protéger son code d’une façon ou d’une autre, en appliquant de bonnes pratiques de codage, de conception ou d’architecture. Et quand on ne sait pas le faire soi-même, on s’appuye sur des frameworks, des outils, des gens qui savent, etc. Et donc, malgré l’expérience des anciens, le code des applications mobiles conservent les mêmes erreurs7 et vulnérabilités, au grand désespoir de tous : les chiffres sont éloquents.

Vu en 2019

Majority of 2019 breaches were the result of unapplied security patches.

HelpNetSecurity

Conclusion

Une seule : faire régulièrement et à fréquence rapide les mises-à-jour de tous vos programmes, surtout le système d’exploitation, les programmes de sécurité (antivirus, pare-feux, etc.). Et faire preuve de discernement quand on reçoit du spam !

Sources

MySQL

Quoiqu’on dise sur le rachat de MySQL par Oracle, cela reste un des systèmes de gestion de bases de données les plus courants dans le monde web.

Sécurisation de l’installation

Il faut lancer l’utilitaire installé par défaut, qui permet déjà de corriger certains points. 

sudo mysql_secure_installation

  • A la 1ère question, sur le plugin des mots de passe, vous pouvez l’activer ou pas : ce plugin sert à vérifier que les mots de passe utilisés sont suffisamment fort. Utile en production, cela peut apporter des contraintes trop importantes en développement. Et rien ne vous empêche de vous forcer à mettre des mots de passe forts par vous-même.
  • Ensuite il vous demandera un mot de passe pour root. A renseigner avec un mot de passe fort impérativement.
  • Puis il demandera la suppression des utilisateurs anonymes, à approuver également.
  • Désactivation d’accès distant pour root : sage précaution encore, à accepter.
  • Dernière chose : suppression des bases de test, évitant ainsi un accès trop facile au SGBD.

Avant de terminer, dites oui au rechargement des privilèges (qui ne seront pas effectifs tout de suite, sinon).

Sauvegarde

Pour réaliser la sauvegarde d’une base de données MySQL, une commande peut suffire : 

mysqldump table -u user -p >> fichier_destination

Attention : cela vous demandera le mot de passe de l’utilisateur correspondant, de façon interactive.

Scan SSL

La confiance n’exclut pas le contrôle, dit-on souvent. Il existe d’excellents outils pour évaluer la sécurité et la robustesse d’un serveur proposant une communication SSL.

Pour ma part, je recommande SSLScan, dont il existe plusieurs variantes. En fouillant un peu, celle qui me semble la plus pertinente est celle de rbsec, car elle est à peu près à jour (elle intègre les versions 1.1 et 1.2 de TLS), et ne mixe pas les technologies puisqu’il s’agit uniquement d’un programme en langage C. Ca permet d’éviter de trop nombreuses dépendances, et ça évite de cumuler les vulnérabilités de multiples technologies (bien que cet aspect puisse être débattu).

Lien interne

  • Test de connexion SSL (par Janiko), à venir

Liens externes

Kubernetes

Kubernetes, ou k8s pour les intimes, est un orchestrateur. On pourrait dire parmi tant d’autres, vus qu’ils fleurissent pour nous aider à tout faire, mais pas tant que ça : il tend de facto à devenir un standard, ou tout du moins l’outil le plus utilisé dans son genre.

Concepts

C’est quoi son genre ?

C’est de déployer une application sur des nœuds. Dis comme ça, ça ne casse pas des briques. Mais disons que c’est un outil (initialement créé par Google mais open source depuis quelques temps) qui dispose d’une certaine puissance et surtout une grande maturité dans son domaine, ce qui est plutôt rare dans le monde si animé du DevOps.

En gros nous avons les grands constituants suivants :

  • Un maître ou master, qui est un machine (ou un ensemble de machines) qui contrôle tout le reste ;
  • Des noeuds ou nodes ou minions, qui sont des ensembles de ressources disponibles pour les déploiements ;
  • Des clusters, qui ne sont rien d’autres que des regroupements de nœuds travaillant pour un master donné ;
  • Des pods ou pods, qui sont la plus petite unité gérée (l’unité atomique), qui correspond à la machine virtuelle dans un environnement de virtualisation, ou à un conteneur pour Docker, etc.
  • Des services, qui sont une abstraction d’un service mis en oeuvre par des pods.

Le rôle de Kubernetes est de déployer un système (une application) selon les spécifications qu’on lui donne, et de le maintenir dans l’état voulu. Cet état peut être défini grâce au mécanisme Replication Controller, qui se met en place par un simple fichier YAML. On peut par exemple indiquer que l’on souhaite 10 ou 20 instances d’un même pod, et que cet état soit maintenu dans le temps.

En résumé, et en image (source wikipedia) :

Un composant est très intéressant : etcd, qui est une base de type clé/valeur (noSQL pour ceux qui aiment ré-inventer la roue), et qui sert de base référentielle persistante pour le master.

YAML, le format

L’ensemble du paramétrage d’une application se fait via des fichiers de type manifest, ou bordereau de livraison, au format YAML ou JSON.

Mon pote le pod

Le pod est l’unité la plus intéressante dans Kubernetes, car c’est l’unité qu’on manipule, qu’on construit, et qui sert effectivement à produire le service demandé. Un pod peut contenir plusieurs conteneurs : ainsi un pod peut intégrer tous les services nécessaires à un fonctionnement intègre et autonome, ce qui peut toujours être utile ou plus pratique en termes d’architecture.

Points notables :

  • Un pod se crée et se gère via un simple fichier de type manifest, au format YAML.
  • Il y a une et une seule adresse IP par pod : pour gérer plusieurs conteneurs (et donc services) au sein d’un pod, il conviendra de le faire via les ports IP.
  • Les communications inter-pods sont tout à fait possibles, via le mécanisme du réseau de pods (pods network), qui repose sur le réseau où ils sont déployés.
  • De manière générale, toutes les ressources au sein d’un pod sont mutualisées : réseau, mémoire, CPU… Il n’y a aucune isolation au sein d’un pod. Par contre, un pod est totalement isolé des autres pods (toujours du point de vue des ressources).
  • Enfin, un pod n’est considéré comme disponible que si l’ensemble des conteneurs devant y être déployés sont effectivement disponibles. Cela renforce la notion d’atomicité du pod.

C’est donc un peu plus conséquent en termes de fonctionnalités qu’un simple conteneur, mais cela reste en dessous du niveau d’une machine virtuelle. D’ailleurs, un pod ne peut pas être scindé, c’est-à-dire déployé par morceaux sur plusieurs noeuds : il est installé sur un et un seul noeud. Et lorsqu’il meurt, on ne relance pas un pod : on en recrée (refabrique) un nouveau, identique, mais qui n’est pas le pod précédent : il n’y a aucune persistance de pod. Le pod est donc un simple mortel, et non un phénix renaissant de ses cendres.

Rendons service

Comme vu ci-dessus, un service est une abstraction d’une fonctionnalité mise en oeuvre par un ensemble de pods. Un service est caractérisé par une adresse IP fixe, un nom, et un port interne et un port exposé (si besoin). Un service peut être de différents types :

  • Cluster interne (ClusterIP) ;
  • Service exposé à l’extérieur (NodePort) ;
  • Équilibreur de charge (LoadBalancer).

Le port interne doit être le même que celui du service mis en oeuvre au niveau du pod (il n’y a pas de translation au niveau du port, mais uniquement au niveau de l’adresse IP).

Ainsi on ne se préoccupe plus du détail de l’instanciation des pods : le service trouve et regroupe les pods réalisant le service (par exemple via des labels qu’on assigne aux pods) et permet d’avoir un point d’entrée unique et stable au service (via une API REST) et même permet un équilibrage de charge.

Le déploiement

C’est le stade ultime dans une architecture Kubernetes : on y gère la mise-à-jour (et le retour arrière), les différents Replicas Sets, de façon à initier l’application ou à la faire monter de version proprement.

Kubernetes sait-il garder un secret ?

Euh… non. Pas bien, en tout cas. En dehors des mécanismes basiques genre TLS qui ne servent qu’au transport, un secret est difficile à protéger au sein d’un déploiement Kubernetes1. Il est possible de gérer des secrets partagés au sein d’un cluster, mais in fine les informations sont stockées en clair2 (ou quasiment, je crois que c’est en base64) dans etcd, qui est l’outil de stockage utilisé par Kubernetes (cf plus haut).

Il ne faut donc pas compter sur le mécanisme par défaut pour une gestion sécurisée des secrets, notamment dans un environnement mutualisé comme le cloud. Dans l’avenir, il sera peut-être possible que ces valeurs secrètes soient stockées correctement chiffrées, mais pour l’instant c’est expérimental3. Les seules solutions fonctionnant en pratique sont d’utiliser les gestionnaires de clés ou les HSM des fournisseurs (AWS, Azure, Google) ou un vault comme celui d’HashiCorp4. Vous ne maîtriserez donc pas totalement vos clés, ce qui peut être un obstacle dans les environnements où la conformité importe.

Installation de MiniKube

Pour apprendre le fonctionnement de Kubernetes, le meilleur moyen sera d’installer MiniKube, un tout-en-un qui tient sur une seule machine mais qui permet d’apprendre les principes. Le support le plus à jour se trouve sur github :

Il y a plusieurs prérequis, dont celui d’avoir installé un outil de virtualisation genre VirtualBox. Il faut aussi avoir installé kubectl.

Linux

Tout en ligne de commande !

Installation de kubectl
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl
Installation de Minikube
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Windows

Il n’y a aussi qu’à recopier les binaires. Pour des questions pratiques, il faut ajouter le chemin d’installation dans le paramètre PATH de Windows, ce qui peut aussi être fait via un installateur pour MiniKube (en version bêta).

Installation de kubectl
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.0/bin/windows/amd64/kubectl.exe
Installation de Minikube

Le lien est https://storage.googleapis.com/minikube/releases/latest/minikube-windows-amd64.exe.

Démarrage

$ minikube start

Liens utiles

Mise à jour du système

La mise-à-jour du système d’exploitation est, me semble-t-il, une des précautions essentielles à prendre sur toute machine connectée à internet, qu’il s’agisse d’un serveur web ou d’un PC.

Il existe plusieurs écoles sur le sujet. Certains recommandent de mettre-à-jour son système automatiquement (dès la parution des correctifs), d’autres préfèrent choisir manuellement les correctifs à installer. Alors que choisir ?

Quelle stratégie adopter ?

Choisir ses mises-à-jour ?

Cela semble la meilleure solution : le webmaster sélectionne les mises-à-jour pour n’appliquer que celles qui sont indispensables et qui répondent à un problème de sécurité.

Avantages

  • Ben on est sûr de ce que l’on fait : on n’introduit pas de mise-à-jour comportant une faille connue ;
  • On ne surcharge pas le système : les mises-à-jour sont réduites, et le système est stable car évoluant peu (juste le nécessaire)

Inconvénients

  • Le webmaster doit être hyper-vigilant : il doit effectuer une vérification très régulière (quotidienne). Cela prend donc énormément de temps et d’énergie ;
  • Il faut connaître ses packages sur le bout des doigts et opérer une veille très active sur les correctifs. Or un système Linux comporte habituellement des centaines de packages qu’il est impossible de maîtriser pour une seule personne.

Installer automatiquement ses mises-à-jour ?

Option inverse : déléguer la mise-à-jour au système en lui demandant périodiquement de se mettre à jour automatiquement (quand c’est possible). A noter que certains packages demandent une validation (pour se conformer aux licences d’utilisation), ceux-ci peuvent ne pas être chargés. Il convient donc malgré tout d’opérer une mise à niveau manuelle régulièrement.

Avantages

  • Aucune perte de temps et moins de travail pour l’administrateur ;

Inconvénients

  • On ne maîtrise plus rien : on fait confiance aux distributions et à la gestion des packages. On peut donc se retrouver avec des fonctionnalités non souhaitées, des packages inutiles ou moins performants.

Course poursuite

Bien que la mise à niveau manuelle semble plus précise et plus pertinente, il faut garder à l’esprit qu’aujourd’hui la sécurité est avant tout une course poursuite :

  • Les pirates cherchent par eux-même des failles, mais leur démarche est également souvent inverse : ils se basent sur les failles connues et publiées pour les utiliser et les exploiter tant qu’elles n’ont pas été corrigées. Or quand elles sont publiques (connues), c’est bien souvent lors de la mise en ligne d’un correctif. Les pirates escomptent donc que les systèmes ne seront pas mis-à-jour immédiatement pour exploiter le plus longtemps possible une faille connue.
  • Or peu de pirates ont le temps, les compétences et les moyens de traquer méthodiquement et de découvrir des failles dans les différents logicels et autres packages Linux.

La bonne approche est donc le plus souvent de maintenir son système à jour dès que possible pour l’exposer le moins longtemps aux failles connues. On sait maintenant que ce sont dans les vieux pots qu’on fait les meilleurs confitures, et que les failles même anciennes sont toujours testées et utilisées par les attaquants.

Bien sûr, ce conseil vaut dans le cadre d’une utilisation personnelle, comme mentionné : c’est le meilleur compromis entre la charge qu’on peut accorder à cette tâche et la qualité de protection attendue, pour un usage non-critique.

Fedora, CentOS, Red Hat-like

Avec ces distributions Linux, le plus simple est de passer par le gestionnaire de paquet yum, qui est installé par défaut sur toutes les distributions récentes.

Pour automatiser, rien de plus simple :

chkconfig yum on

En version longue, pour les utilisateur de sudo :

su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'

Ubuntu, Debian-like

Il existe un package gérant tout cela : unattended-upgrades. Il suffit de l’installer et de le configurer.

$ sudo apt install unattended-upgrades
$ sudo dpkg-reconfigure --priority=low unattended-upgrades

D’autres informations utiles sont ici :

  • https://guide.ubuntu-fr.org/server/automatic-updates.html
  • https://wiki.debian.org/UnattendedUpgrades

Il convient également de vérifier les deux fichiers de configuration suivants :

/etc/apt/apt.conf.d/50unattended-upgrades
/etc/apt/apt.conf.d/20auto-upgrades

Mise-à-jour du noyau sans reboot

Des solutions (hélas payantes) existent : http://www.ksplice.com/uptrack/install#. Toutefois, Ubuntu semble s’y mettre, mais je ne sais pas encore si cela est réservé aux utilisateurs ayant souscrit une formule de support ou pas.