Archives de catégorie : Concepts

La catégorie concepts regroupe les généralités utiles en sécurité des SI et parfois d’autres plus globales à l’informatique, mais ayant un sens ou un intérêt particuliers en SSI.

Cloud

Le cloud computing est avant tout un terme marketing qui, comme souvent en informatique, ne fait que remettre en avant des notions existantes (mais qui évoluent au cours du temps, les rendant tantôt plus accessibles, tantôt plus pratiques que d’autres). Brut de fonderie, je dirais que ce qu’on appelle couramment cloud consiste principalement à faire tourner son informatique (infrastructure ou applicative) sur les ordinateurs de quelqu’un d’autre.

Définition

Je ne définirai pas forcément le cloud comme le NIST1 qui indique (traduction approximative) :

Le cloud computing est un modèle permettant l’accès en réseau à un pool de ressources partagées de ressources informatiques configurables pouvant être rapidement provisionnées avec un effort minimal de gestion et d’interactions avec le fournisseur.

Les principales caractéristiques sont :

  • Ressources disponibles à la demande ;
  • Large accès via un réseau ;
  • Mise en commun des ressources ;
  • Elasticité (en gros : on peut créer ou supprimer très rapidement des ressources de taille et de caractéristiques très variables) ;
  • Mesurabilité ;

Bien que très intéressante et très réfléchie, je l’adapterai un peu au vu de mon expérience personnelle. D’autant que les modèles proposés ne sont pas vraiment le reflet des pratiques industrielles.

Cloud public, privé, hybride

Le NIST définit (à mon sens) correctement les types privé et public, qui sont respectivement dédié à l’usage d’un seul client (ou organisation) et ouvert à tout client, mais il introduit un type communautaire, constitué de plusieurs organisations ayant un intérêt commun, et qui n’est jamais utilisé en pratique, sauf peut-être dans les clouds gouvernementaux proposés par Amazon.

Point intéressant : aucune mention n’est faite de la localisation des infrastructures clouds par rapport au client. Que le cloud soit interneou externe n’a que peu d’importance dans cette définition, alors qu’en pratique la localisation est une préoccupation constante des directions informatiques.

Leur définition du cloud hybride est également bancale : en gros ça n’est qu’un mix de clouds, alors qu’en général on parle souvent de cloud hybride pour désigner un mélange de cloud et d’infrastructures classiques possédées par le client (ou organisation).

Responsabilité

Un point crucial selon moi a été oublié par le NIST : la responsabilité des ressources. En effet, la virtualisation est une composante intrinsèque des infrastructures clouds (en terme d’elasticité principalement), et elle marque la frontière entre ce qui est de la responsabilité du fournisseur et celle du client.

Ainsi, le niveau hyperviseur (qui est de la responsabilité du fournisseur) sépare la partie matérielle (également de la responsabilité du fournisseur), cachée du client, des services exposés et proposés au client dont la gestion est de sa responsabilité. En clair, le fournisseur doit s’assurer qu’il peut proposer des services fiables et conformes aux clients qui les gèrent selon leurs besoins.

Ce modèle de responsabilité partagée, cher à Amazon2, est pourtant fondamental dans l’usage du cloud pour toutes les questions relatives à la sécurité et à la conformité.

Catégorie « incidents »

Articles intéressants

IAM

Quelques définitions

Afin d’avoir les idées claires, voici quelques définitions aidant à appréhender la structuration d’une gestion de droits informatiques. Il est également utile d’être à l’aise avec la notion de DICP.

  • Un rôle est un ensemble d’habilitations nécessaires à un type d’utilisation d’une ressource.
  • Un rôle applicatif est un rôle propre à une (et une seule) application.
  • Un profil est un ensemble de rôles, souvent regroupés par métier.
  • L’habilitation est le droit d’effectuer une action sur une ressource, souvent associée à un périmètre (temporel, fonctionnel, géographique). C’est le niveau « unitaire ».

Pour une gestion claire, les rôles ne devraient être liés qu’à des profils, lesquels correspondent généralement à une fonction exercée au sein d’une organisation.

Principes de base

  • Identifier les systèmes et données sensibles
  • Limiter les accès à privilèges
  • Contrôler les utilisateurs et les systèmes

Document de référence

Voir aussi

  • SAML v2.0
  • OAuth 2.0
  • OpenID et OpenID Connect
  • XACML (eXtensible Access Control Markup Language), langage permettant de définir :
    • des autorisations ou des contrôles d’accès basés sur des attributs,
    • des contrôles d’accès à des points de décision (PDP, Policy Decision Point) puis de les transmettre à des points d’application (PEP, Policy Enforcement Point).
  • SCIM (System for Cross-domain Identity Management), système d’échanges de données, d’attributs, entre systèmes externes.

XACML permet par exemple de définir les droits d’un utilisateur chez un fournisseur cloud à partir de son IAM interne.

Hacker

Un hacker n’est pas un pirate. D’ailleurs la grande mode des hackathons ne cherche pas à faire la promotion des pirates mais de la programmation (collaborative généralement) ou de la bidouille dans n’importe quel domaine.

La bonne traduction de hack devrait être bidouille : un hacker n’est rien d’autre qu’un bidouilleur.

Le bon et le méchant

Nous commettons souvent l’erreur d’assimiler hacker et cracker. Le cracker pirate les systèmes informatiques et casse les sécurités mises en place. J’essaye souvent d’employer les mots pirate, fraudeur, cybercriminel, criminel, attaquant à la place, mais je me laisse parfois aller.

Serveur FTP

Pour mettre en œuvre un serveur FTP, il faut penser à quelques éléments de sécurité. Par exemple :

  • Cloisonner les utilisateurs
  • Interdire les shells
  • Contrôler la provenance des requêtes

Pure-FTPd

Il existe plusieurs serveurs FTP possibles. J’ai choisi pure-ftpd qui m’a l’air léger (~800 ko) et robuste.

Pour créer un utilisateur sous Linux :

Créer l’utilisateur Linux lui-même, de préférence sans accès au shell

$ sudo useradd ftpusr -g ftpaccess -s /usr/sbin/nologin -d /home/ftp
$ sudo pure-pw useradd ftpusr -u ftpusr -g ftpaccess -d /home/ftp 
$ sudo pure-pw mkdb

Dans la commande pure-pw useradd, utilisez l’option -r si possible, laquelle indique l’hôte depuis lequel l’utilisateur peut se connecter. Il faut aussi penser à ajouter le nologin dans la liste des shells (merci), sinon on obtient une erreur 530 bien difficile à corriger…

$ echo '/usr/sbin/nologin' >> /etc/shells

Pour pure-ftpd, on peut configurer le serveur via différents fichiers présents dans le répertoire /etc/pure-ftpd/conf.

$ ll 
total 56 
drwxr-xr-x 2 root root 4096 Aug 29 18:40 ./ 
drwxr-xr-x 5 root root 4096 Aug 29 18:35 ../ 
-rw-r--r-- 1 root root   36 Oct 29  2012 AltLog 
-rw-r--r-- 1 root root    4 Aug 29 17:57 Daemonize 
-rw-r--r-- 1 root root    4 Aug 29 17:57 DontResolve 
-rw-r--r-- 1 root root    6 Oct 29  2012 FSCharset 
-rw-r--r-- 1 root root    4 Aug 29 17:55 IPV4Only 
-rw-r--r-- 1 root root    4 Aug 29 17:56 KeepAllFiles 
-rw-r--r-- 1 root root    2 Aug 29 17:56 MaxClientsNumber 
-rw-r--r-- 1 root root    5 Oct 29  2012 MinUID 
-rw-r--r-- 1 root root    4 Oct 29  2012 NoAnonymous 
-rw-r--r-- 1 root root    4 Aug 29 18:36 PAMAuthentication 
-rw-r--r-- 1 root root   28 Oct 29  2012 PureDB 
-rw-r--r-- 1 root root    4 Aug 29 18:40 UnixAuthentication

Pour pure-ftpd, chaque fichier contient des informations de configurations. Par exemple, mettre yes dans le fichier NoAnonymous si vous voulez interdire les accès anonymes, ce qui est souvent préférable.

Passage en FTPS

Paramétrage TLS

Il faut d’abord forcer le passage par SSL/TLS via la commande :

$ echo 2 | sudo tee /etc/pure-ftpd/conf/TLS

Vérifiez ensuite les protocoles autorisés, et si vous utilisez ce serveur pour un usage personnel, visez haut et récent dans les protocoles autorisés.

$ cat TLSCipherSuite 
ALL:!aNULL:!SSLv3
Certificat
$ sudo apt install letsencrypt 
$ sudo letsencrypt certonly --agree-tos --email mail -d domaine

Le certificat et la clé privée utilisés doivent être placés dans un fichier unique nommé pure-ftpd.pem et placé dans le répertoire /etc/ssl/private/.

$ sudo cat /etc/letsencrypt/archive/domaine/cert.perm \ 
/etc/letsencrypt/live/ftp.iku.fr/privkey.pem > /etc/ssl/private/pure-ftpd.pem

Le serveur pure-ftpd doit ensuite être redémarré.
xx

  • https://www.howtoforge.com/how-to-configure-pureftpd-to-accept-tls-sessions-on-ubuntu-10.10
  • https://www.linuxbabe.com/linux-server/secure-ftp-server-pure-ftpd-ubuntu-16-04

Sources

  • https://doc.ubuntu-fr.org/pure-ftp
  • https://www.pureftpd.org

DNS

Le protocole DNS permet de connaître l’adresse réelle d’un serveur web. Plus précisément cela transforme le nom de domaine inclus dans une URL (adresse symbolique du genre https://secu.si) en adresse technique (adresse IP).

Pour cela, de très nombreux serveurs se répartissent la tâche sur toute la planète web. Pour des raisons d’efficacité, nous nous retrouvons souvent connectés directement à un serveur géré par notre fournisseur d’accès internet. Rien de bien fameux, sauf que les fournisseurs d’accès gardent souvent des traces, pour leur usage propre ou parce qu’on leur demande1.

Vie privée ?

A priori pas d’influence de l’utilisation d’un service de DNS sur sa vie privé. Et pourtant…

Transparence et traçabilité

Nous laissons des traces de notre activité dès qu’on sollicite ces serveurs DNS classiques. Même en navigation privée, le serveur DNS sait sur quels sites nous surfons. Il peut aussi interdire la navigation sur certains sites qui lui sont désignés par le pouvoir public.

Autre problème : il existe plusieurs types d’attaques sur la résolution de nom de domaine via DNS. D’où l’intérêt d’utiliser un service DNS à la fois respectueux de la vie privée mais également sécurisé. On peut par exemple savoir ce que vous faites, même si le serveur ne garde pas de traces d’activité, en écoutant les requêtes DNS circulant de façon non sécurisée, en clair.

DNSSEC

?

Les différentes options

Le serveur FAI

L’avantage premier d’utiliser le serveur du FAI est de rester dans la légalité (et donc dans la censure dans certains pays), ainsi que la simplicité d’utilisation vu que c’est le paramétrage par défaut à l’installation de votre ligne d’accès internet.

Les services dédiés

Tout dépend ensuite de la confiance que vous accordez au fournisseur que vous allez sélectionner. Il s’agit parfois d’un moindre mal : on accepte les défauts et contraintes des fournisseurs pour pouvoir contourner des blocages de type censure.

Google

Google n’est pas forcément votre ami. Oui, il vous aide à trouver presque tout ce que vous voulez, mais quand il propose des services périphériques, il y a souvent anguille sous roche. Certes il est très rapide, il y a des gens qui ont essayé, et je suppose qu’ils ont eu de problèmes. Je suppose, soyons honnête, je n’ai pas entendu de cas suspect suite à l’utilisation de Google DNS, mais si techniquement il est extrêmement rapide (c’est vrai), il appartient à Google dont le principal revenu est la publicité, et donc son fond de commerce2 est basé sur le ciblage des utilisateurs. Méfiance, donc.

Les IP du Google DNS sont :

  • 8.8.8.8
  • 8.8.4.4

Des IP simples, on n’en attendait pas moins d’un géant du web.

Quad9

Cette solution est un peu particulière, car il existe deux versions :

  • 9.9.9.9 ou 2620:fe::fe qui utilise DNSSEC et qui renvoie une liste filtrée et épurée des IP dangereuses ou malveillantes, comme celles utilisées par des botnets ;
  • 9.9.9.10 ou 2620:fe::10 qui ne filtre rien, mais qui ne fait pas de DNSSEC contrairement à 9.9.9.9.

Proposée au départ par IBM via X-Force3, elle est gérée par une association à but non lucratif. Pas mal non plus pour le choix des adresses IP.

OpenDNS

Je ne connais pas bien OpenDNS, mais le service a connu des oppositions liées à l’usage publicitaire ayant été fait des données d’utilisation. Aujourd’hui cela appartient à Cisco, la publicité a été arrêtée4, mais là encore la méfiance est de mise.

CloudFlare

CloudFlare est connu pour ses solutions industrielles, notamment anti-DDoS, ayant servi dans différents événements et attaques. Sans être philanthrope, on sait que cette société tient à garder une image propre et elle est plutôt encline à défendre la veuve, l’orphelin et l’internaute.

En avril 2018, CloudFlare a lancé un service de DNS gratuit et sécurisé sur l’adresse IP 1.1.1.1 (chapeau pour avoir mis la main sur cette adresse5).

SPOF

CloudFlare ou Quad9 sont bien placés pour emporter la mise et protéger notre vie privée. Attention toutefois au paramétrage de vos serveurs DNS : une bonne idée pourrait être de panacher les fournisseurs pour éviter le risque de déni de service, car on tombe dans le risque du SPOF si on ne choisit qu’un seul fournisseur. Par contre il faut avoir bien confiance en les deux que vous retiendrez.

Références

Tor Onion Routing

Tor est l’implémentation d’un réseau en oignon. Une des caractéristiques principales de ce réseau est d’avoir une typologie de réseau maillée (chaque hôte est connecté pair à pair, sans hiérarchie), dont l’objet principal est de préserver au maximum l’anonymat des utilisateurs.

Génèse

Étonnamment, le projet a été initié par… l’armée américaine (l’US Naval Research Laboratory, ou NRL). Sans rentrer dans les détails techniques, Tor est une surcouche (« overlay ») d’internet permettant l’usage de services de façon anonyme. Cela inclut :

  • La navigation web, via un navigateur dédié (Tor Browser, basé sur Firefox, pour les PC ; Orbot sur Android) ;
  • La messagerie (Tor Messenger).

Plusieurs autres outils ont été créés dans le but principal d’assurer techniquement le bon fonctionnement du réseau.

Le réseau est géré et maintenu via une fondation (au sens américain), The Tor Project Inc., dont le conseil d’administration comprend des membres éminents de la communauté cryptographique (comme Bruce Schneier). Le financement est au moins partiellement public1, ce qui fait en pratique que le gouvernement américain cherche à la fois à aider le projet Tor (via la fondation) mais aussi à y trouver des vulnérabilités via ses différentes agences (dont la NSA).

Principe

Les paquets ne circulent pas directement et en clair entre l’utilisateur et le service final (par exemple le site web destination). Chaque paquet passera par un minimum de trois nœuds différents et sera chiffré par plusieurs clés. Chaque nœud ne connaît que son prédécesseur et son successeur.

Seules les informations nécessaires un transit du paquet sont déchiffrées au niveau d’un nœud : on épluche ainsi le paquet d’une couche à chaque nœud, afin de le passer au suivant, mais sans déchiffrer le coeur du paquet qui ne sera déchiffré qu’une fois arrivé à sa destination finale.

Attaque de Tor

Comme tout système informatique, Tor est potentiellement vulnérable. On peut chercher à compromettre le navigateur (spécifique, donc), ou le nœud final (nœud de sortie) qui est le plus intéressant. Apparemment, cela a déjà été fait2.

Sources

  • https://tor.eff.org/
  • https://www.nrl.navy.mil/itd/chacs/sites/www.nrl.navy.mil.itd.chacs/files/pdfs/Dingledine%20etal2004.pdf
  • Affaire Appelbaum : https://blog.torproject.org/tor-project-elects-new-board-directors
  • http://libertygb2nyeyay.onion/lh-services-state-fr.html

Poodle

Poodle est le nom donné à une faille inhérente au protocole SSL v3.

Désactivation de SSLv2 et SSLv3 sur Plesk

Sur Plesk, il est possible de désactiver SSL v2 et v3 de façon définitive, grâce à un paramètre disablesslv3 qu’il faut positionner à true. J’avoue avoir eu un peu de mal à trouver comment faire, mais une fois que c’est fait, cela débarrasse de ce boulet !

Pour plus d’informations, il faut aller sur le forum Plesk. Et pour mémoire, voici la manip : 

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -Dpsa -e "insert into misc values('disablesslv3', 'true')"


# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

La 1ère ligne positionne le paramètre, la 2e permet de reconstruire les configurations nécessaires. Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep ssl_protocols

Il s’agit de la configuration de nginx, et les vieux SSL doivent avoir disparu.

Voir aussi Logjam.

SHA-1

SHA-1 est le nom d’un algorithme de hachage très utilisé en cryptographie.

Qu’est-ce qui se passe avec SHA-1

Beaucoup de bruits courent en 2014-2015 au sujet de la vulnérabilité potentielle de cet algorithme de hachage. Il est très fortement utilisé dans toute l’industrie informatique, notamment dans les certificats numériques (mais pas uniquement).

Or des travaux ont mis en évidence des failles possibles sur cet algorithme dès 2005. Toutefois, cela restait théorique car hors de portée de la puissance de calcul disponible à l’époque. Dix ans plus tard, les choses ont bien sûr évolué.

Quel est le problème ?

Avec l’augmentation continue de la puissance de calcul des ordinateurs, le nombre d’empreintes possibles (2 puissance 160 pour SHA-1) devient une limite de plus en plus accessible pour différents types d’attaques, d’autant que certains types d’attaques permettent de réduire la puissance nécessaire.

Microsoft a pris les devants, et a considéré qu’il devenait hasardeux de continuer à reposer sur l’algorithme SHA-1 pour certains types de certificats, et a décidé de ne plus l’utiliser et de n’utiliser que des algorithmes plus robustes, ce qui est une très bonne chose pour la sécurité informatique en général.

D’autres acteurs de l’informatique ont emboîté le pas de Microsoft, notamment les éditeurs de navigateurs internet : ils ont mis en place des mécanismes d’information et d’alerte pour indiquer à l’internaute qu’un site web (plus précisément : le certificat présenté par le site web) utilisera un algorithme considéré comme obsolète. Cela peut aller de la simple information visuelle (message « les technologies utilisées dans ce certificat seront bientôt obsolètes », changement de couleur de l’icône « cadenas ») jusqu’à l’apparition d’une page d’alerte.

Attaque par collision avec préfixe choisi

Ok, je vous perds, et je m’y perds aussi. Expliquons.

Préfixe choisi

Pour faire simple, cela revient à construire deux documents informatiques ayant le même hash. Google et CWI l’ont fait en 20171.

En 2019, une nouvelle étude2 vient montrer cette fois la viabilité économique3 de cette attaque, en chiffrant le coût de sa réalisation.

Voir aussi

Capri, c’est fini

Début 2020, une étude montre qu’il est désormais possible, à un coût raisonnable, de réaliser des attaques sur SHA-1 à préfixe choisi.

En clair, quand un objet est « signé » via un hash SHA-1, il est maintenant possible de le remplacer par un autre objet dont le hash sera identique.

Conclusion : Les certificats signés en SHA-1 et autres bi-clés de type PGP signées ne peuvent plus être considérés comme valides !

Freak

Une de plus ! Freak est une faille quasiment de conception de SSL. Une fonctionnalité, diront certains.

Dans les années 1990, l’administration américaine s’inquiétait de la prolifération des systèmes de chiffrement, et craignait de ne plus en avoir le contrôle (comprendre : ne plus pouvoir déchiffrer les messages codés, en cas de besoin). Elle a donc décidée d’interdire l’exportation de tout ce qui était indéchiffrable avec les moyens de l’époque, d’où une limitation de la taille de clés (par exemple).

Les outils se sont adaptés en conséquence, prévoyant un mécanisme spécial « export » qui ramenait automatiquement à des valeurs convenables la complexité du chiffrement lors d’un échange, même si les deux parties pouvaient faire beaucoup mieux.

Avec le temps, cette limitation est tombée, mais le mécanisme servant à réduire la taille des clés a été reconduit dans la plupart des outils utilisés. Et on s’en est rendu compte seulement en 2015, alors que cette fonctionnalité était largement documentée, et n’était même pas cachée1 !

FREAK a touché toutes les bibliothèques SSL/TLS ou applications utilisant SSL/TLS ayant respecté la réglementation… et oublié de supprimé cette limitation quand les règles se sont assouplies. Exemple : openSSL, S-Channel, Chrome…

Liens externes

Logjam

Logjam est une nouvelle faille dans le désormais périlleux chemin de la cryptographie, touchant une étape de négociation lors d’une connexion [[TLS|SSL/TLS]]. Même si, comme Freak, son exploitation n’est pas forcément facile, cela va imposer à moyen terme l’augmentation de la longueur de certaines clés, ou l’utilisation de certains algorithmes à la place de certains jugés trop faibles, ce qui aura surtout pour effet de compliquer encore la vie des webmasters (et des navigateurs web).

En effet, à force d’augmenter la solidité des mécanismes de sécurité, on finit par demander beaucoup de calculs à la fois au serveur et au navigateur ; or tout le monde n’est pas obligatoirement à niveau, et on pourrait finir (par exemple) par rendre certains sites inaccessibles aux utilisateurs dont les ordinateurs (ou les navigateurs web) ne sauraient pas composer avec cette complexité croissante.

Une synthèse, avec un outil de test ainsi que les recommandations à suivre sont ici : weakdh.org.

Désactivation sur Plesk

Sur Plesk, si vous avez une version 2.2 d’Apache couplé à nginx, il faudra un peu ruser pour ne plus être exposé à Logjam. pour plus d »infos, allez voir le forum.

Il faut en premier lieu créer un fichier DH personnalisé, de complexité (longueur) suffisante : 

openssl dhparam -out dhparams.pem 2048

Ensuite, il faut un template personnalisé pour ses sites web, dans /usr/local/psa/admin/conf/templates/custom/domain. Le fichier à modifier est nginxDomainVirtualHost.php. Il faut ajouter l’option ssl_dhparam en lui mettant le fichier que l’on vient de créer. 

ssl_ciphers                 HIGH:!aNULL:!MD5;


ssl_prefer_server_ciphers   on;


ssl_dhparam             /dhparams.pem;

Ensuite on reconfigure et ça devrait aller. 

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep dh_param

Liens externes

  • http://www.nextinpact.com/news/94144-logjam-apres-freak-nouvelle-faille-dans-chiffrement-connexions.htm
  • http://forum.odin.com/threads/ssl-poodle-sslv3-bug.323338/#post-761018
  • https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf