PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Quelques liens en vrac et en français, 35° édition

samedi 8 juin 2019 à 10:30

J’ai pas vu passer le temps, j’ai par contre vu passer pas mal de lectures, c’est donc reparti pour une nouvelle sélection tirée de ma veille et de mes découvertes au hasard du surf.

L’informatique ? Comment se fait-ce ?

L’auteur fait un constat plutôt juste selon moi de la situation de l’illectronisme global de la société face à l’informatique et ses différents aspects (matériel, communication, impact sociétal), ce qu’on appelle désormais le numérique, alimenté par des sociétés dont le but est justement de garder le public éloigné de son fonctionnement. Et j’ajouterai que nos gouvernants ne risquent pas de relever le tableau quand on voit la situation de l’Éducation Nationale, aussi bien pour les enfants que pour les enseignants.

Aspirer un site avec wget

Alors attention, y’a un gaillard célèbre qui a été salement condamné pour ça (et on connaît la vraie raison), mais ça reste un outil pratique. Wget, avec curl, fait partie de ces outils réseau/web à toujours avoir sur soi, car il permet de faire de la sauvegarde très pratique de contenus.

Monter ses partages à la demande avec autofs

S’il y a bien un truc que je reconnais facilement, c’est la pénibilité de la gestion des dossiers partagés sous Linux. Les solutions pour tenter de minimiser ces problèmes sont nombreuses, parfois une solution pour un problème, ce qui n’aide pas quand on en rencontre plusieurs. Ici, la solution s’appelle autofs, et permet de palier aux problèmes justement des montages réseau qui ont du mal (notamment en WiFi).

Comment (ne pas) déployer une collecte Fluentd pour Docker

Un retour d’expérience intéressant  sur un déploiement particulier de services Docker, avec toute l’investigation, l’explication, bref, du très technique mais du très transparent pour cette petite association qui héberge des services décentralisés (oui, c’est un CHATONS).

Clavier français international pour Windows

S’il y a bien une chose qui me fait rager sous Windows depuis que j’utilise du Linux au quotidien, c’est bien le comportement du clavier, en particulier de la difficulté de saisir des majuscules accentuées, et le comportement de la touche Caps Lock qui est lié. Avez-vous déjà essayé de saisir un É sous Windows ? Sans passer par le correcteur orthographique ou l’outil de caractères spéciaux hein. Ben voilà. Fort heureusement, un Miguel J de Montpellier, apparemment engagé dans la politique locale, a aussi contribué une disposition clavier pour Windows, astucieusement intitulée « fs-oss », permettant de reproduire sous Windows le comportement de l’agencement clavier dont on jouit sous Linux. Abusez-en.

GPU Passthrough: Linux et Windows ensemble, sans redémarrage

Ça reste un fait, certains jeux qui ne sont pas nativement adaptés sous Linux ne risquent pas de pouvoir être mis à disposition, car ils dépendent de composants trop spécifiques, souvent un outil anti-triche. La seule solution serait alors la virtualisation, mais le matériel virtuel n’est conçu que pour un affichage basique. La solution serait alors de pouvoir dédier une carte graphique pour la machine virtuelle, technique appelée GPU Passthrough, et c’est ce que présente Tommy sur son blog. C’est long, c’est contraignant, mais ça semble fonctionner.

7 Points A Vérifier Avant De Changer De Thème WordPress

Perso je conseille de toujours travailler sur une copie avant de procéder à de tels changements, surtout quand on commence à accumuler les articles. Ça fait d’ailleurs partie des conseils que contient cet article pour vous guider afin de ne rien oublier quand vous voudrez changer la tête de votre site préféré.

Comment j’ai quitté Gmail

J’ai adoré cet article de Camille, non pas pour un anti-googlisme primaire, ce n’est pas le cas, mais parce qu’il est réfléchi, sur les problèmes des conditions d’utilisation, sur les besoins, aussi bien en outillage qu’en entourage (car le mail est un outil de communication). Et surtout, on se rend compte au final que pour avoir le même service chez un véritable hébergeur, il faut un nom de domaine (à payer si c’est pas déjà le cas), et payer pour des options supplémentaires, autrement dit on redécouvre le vrai cout du service quand Google se rémunère en ciblage publicitaire (oui oui, en analysant le contenu de vos courriers), ce qui est, faut-il le rappeler, toxique pour les utilisateurs.

Dans le même esprit mais un peu moins « cas pratique », un autre point de vue avec plus de propositions de fournisseurs, et l’inévitable mais ô combien déconseillé auto-hébergement.

Prise en main de VIM configuré pour PHP

Vim est un éditeur de texte en ligne de commande qui est particulièrement apprécié sur serveur pour sa souplesse (et la non-intuitivité de ses raccourcis de commandes :D). Et bien saviez-vous qu’il est tellement adaptable qu’on en faire un véritable éditeur de code avec tous les raffinements que ça implique ? Qu’on peut même le spécialiser pour PHP ?

Mythes et légendes de l’intelligence artificielle

Que ne peut-on pas lire comme bêtises dans la presse généraliste ou les discours marketing à propos de l’intelligence artificielle, nouvelle drogue des investisseurs qui va soit-disant nous mettre à la retraite dans tous les domaines sous prétexte d’être plus performants pour prévenir les évènements. Cet article est donc tout à fait rafraîchissant pour remettre quelques pendules à l’heure sur les fantasmes nourris par ce domaine.

Les Docker files

Cette page regroupe l’essentiel de ce qu’il y a à connaître sur les différents fichiers que l’on doit manipuler quand on exploite des architectures sous Docker. Autre les incontournables Dockerfile et docker-compose, dont les principales directives sont décrites de manière didactiques avec moult exemples, on découvre aussi le dockerignore, que j’ai eu l’occasion moi aussi de découvrir au boulot pour gagner du temps de build.


Voilà, ça y est, c’est fini – LAGAF’

Le badbuzz DigitalOcean : les erreurs du « tout cloud public » (et du fournisseur unique)

mercredi 5 juin 2019 à 18:30

Cela ne vous aura certainement pas échappé sur Twitter (et vu le succès de ma micro-analyse, j’imagine que vous avez certainement vu passer le sujet), un des membres d’une petite entreprise, qui propose une application à destination des entreprises (avec quelques candidats au bullshit bingo dans la description Twitter), alerte que son hébergeur est en train de la tuer parce qu’il a bloqué l’intégralité de son infrastructure. Et soit-disant qu’il n’a aucun moyen de contourner. Et là, on va toucher à un problème trop récurrent sur le web actuel, la dépendance à l’hébergeur.

Digital Ocean est peu connu de ce côté de l’atlantique, mais c’est un hébergeur assez populaire en Amérique du Nord, notamment pour ses tarifs, un peu à l’image d’un OVH en Europe, la qualité en plus (troll gratuit, si on a pu avoir des soucis avec eux chez LBN, en tant que client particulier globalement j’ai pas grand chose à redire). Et donc pour une raison que j’ignore parce que j’ai la flemme de creuser, cette jeune société basée à Paris héberge toute son infrastructure chez eux. Tout va pour le mieux dans le meilleur des mondes.

Et là, patatras, vendredi 31 mai, l’un des membres de la société vient se plaindre sur Twitter que com compte a été bloqué, ainsi que toutes les ressources associées, et que ça va le tuer (enfin sa société). En soi oui, c’est possible, si tu perds toutes les données de ton entreprise, qui sont celles qui te font vivre (enfin celles sur lesquelles tu bâtis ton service, vendu aux entreprises), ben t’as plus rien à vendre, et donc, si les comptes sont en flux tendus, ça devient vite un gros, gros problème. Mais pourquoi donc Digital Ocean (que je vais abrévier DO) a-t-il coupé le compte d’une entreprise qui à priori n’a rien à se reprocher, au moins d’un point de vue technique ?

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8">

Nicolas explique très bien dans son thread, en temps normal son application nécessite cinq droplets, nom donné par DO pour ses instances de machines virtuelles à la demande (comme EC2 sur AWS), qui tiennent différents rôles, et du stockage objet pour les média (et il en a beaucoup, mais comme on paie à la consommation, pas de souci). Seulement pour entretenir la base de données qui est au cœur de l’application, afin d’en garantir les performances, régulièrement une dizaine de droplets supplémentaires sont démarrés pour exécuter du code Python qui s’occupe des opérations de maintenance. Les droplets sont ensuite détruits, puisqu’il n’auront plus d’utilité jusqu’à la prochaine fenêtre de maintenance. Rien de choquant dans une telle architecture, c’est même l’avantage de ces mécaniques chez les fournisseurs de « Cloud » modernes, on crée et utilise des ressources uniquement dans une fenêtre de temps utile, plutôt que de réserver et payer en permanence des ressources qui ne sont pas exploitées (gaspillage toussa). Mais apparemment ce comportement a été détecté comme malveillant, avec pour conséquence de bloquer l’accès à toutes les ressources, ce qui inclut les sauvegardes de données et d’architectures (je ne sais pas comment sont sauvegardés les média sur le stockage objet de DO, ni comment on peut procéder à une restauration).

Pourtant DO promet lui-même de pouvoir déployer « de un à plusieurs milliers » de droplets sur son site :

Et sur le papier, DO n’est pas ultra regardant sur le comportement des instances, tant qu’ils ne sont pas alertés d’abus, généralement au niveau du réseau, quand le trafic est douteux, tous les grands fournisseurs se protègent aussi bien en entrée qu’en sortie. Ici rien de la sorte, à part que les dix droplets créés « attaquent » le droplet qui s’occupe de la base de données, mais c’est du trafic interne, dans le même subnet à priori (facilite le déploiement et la configuration, surtout pour un travail très temporaire). C’est donc étrange qu’un tel blocage ait eu lieu. Rapidement contacté, l’hébergeur a d’abord débloqué le compte, avant de le rebloquer 4h plus tard en refusant ce coup-ci toute discussion, comme très souvent avec de grosses sociétés, David contre Goliath mais c’est Goliath qui met une patate de forain à la fin.

A cause du bruit que ça a fini par faire, DO a finalement restauré le compte (pour combien de temps ?) et promet d’analyser les raisons qui ont poussé leur système à procéder à un tel blocage, mettant en péril l’existence même de la petite société. Au-delà de la nécessaire opération de communication, il n’y a rien de choquant là-dedans, s’il y a un dysfonctionnement qui peut engager à ce point là responsabilité de l’hébergeur, ils vont tout faire pour le corriger, car on sait à quel point un hébergeur aime n’être responsable de rien, encore plus aux US qu’ailleurs.

Une confiance à limiter, une stratégie de catastrophe à revoir

Tous les hébergeurs vous promettent haute disponibilité des infrastructures, intégrité des données, sécurité, et on entend souvent qu’on ne peut avoir que deux des trois. Concernant la disponibilité et l’intégrité, vous avez la possibilité de déployer sur plusieurs « régions » qui correspondent à des centre de données distincts et relativement éloignés géographiquement, et les données du stockage objet sont répliqués sur ces différentes zones.Tout ça est transparent ou presque, le déploiement d’instances sur plusieurs zones doit être de votre fait, ce n’est pas automatique (il y a des contraintes au niveau réseau difficiles à contourner), pour le stockage par contre aucun souci c’est transparent.

Et surtout, ça suppose que vous n’ayez aucun problème avec le compte, et comme on l’a vu ici, dès que le compte est bloqué, tout est bloqué. Il y a donc ici une forte dépendance à un seul hébergeur, et surtout, aucune stratégie de sortie n’a été envisagée, ce qui veut dire qu’il n’existe aucune copie à minima des données base et media (le code des applications est certainement stocké dans une forge git quelconque, donc facile à redéployer), en clair, ce type de catastrophe n’a jamais été envisagé. En même temps, DO est un acteur reconnu, populaire, aux services fiables, pratiques (API, toussa), performants, relativement abordables, donc aucune raison de douter de leur professionnalisme n’est-ce pas ?

Le problème de la facilité d’utilisation de leurs services, c’est que ça a du attirer pas mal de mauvais utilisateurs, qui se sont amusés à déployer du temporaire pour attaquer d’autres infrastructures, ce qui a du pousser DO à mettre en place des mécaniques pour tenter de détecter et de bloquer ces abus, à l’image de certains types d’attaques réseau (rebond sur UDP, SYN ACK, DDoS…). Je ne peux que soupçonner un tel mécanisme étant donné le profil de l’activité (démarrer une dizaine d’instances qui exécute du code qui tape sur une autre machine dont les consommations de ressources explosent tout d’un coup). Et c’est dommage dès lors de faire la pub sur « des milliers » si une dizaine suffit à se faire bannir du système.

Donc même en étant un client payant, il faut toujours se méfier de son fournisseur, quel qu’il soit, et d’autant plus quand une grosse partie de ses opérations est confiée à des robots. Vous pouvez toujours parler d’intelligence artificielle pour améliorer les choses (et j’aime pas ce mot, remember), il faudra toujours des humains pour traiter les cas à la marge, qui ne pourront jamais être évités.

Une stratégie qui coûte cher

Et c’est bien le souci, l’argent. Le coût du stockage objet des 500k+ media est assez bas, et inclut pourtant la réplication dans plusieurs centres de données. Je n’ai pas la volumétrie exacte, mais conserver une copie de ces media sur un stockage plus classique, ou un stockage objet d’un autre hébergeur, en miroir, coûte à minima le double. Et il reste ensuite la base de données, là aussi, compliqué sans avoir la volumétrie mais le stockage rattaché aux droplets est un poil plus cher, même en trouvant un moyen de compresser les sauvegardes, pas évident de limiter la dépense.

Ce genre de stratégie est donc compliqué à mettre en place, pas d’un point de vue technique, c’est très, très rarement un problème, mais surtout d’un point de vue financier. Reste alors à faire un calcul savant sur les risques qu’il y a à perdre l’intégralité de son activité sur une telle connerie, et prendre la décision d’investir un peu plus dans un plan de secours, qui peut aller jusqu’à (re)déployer l’intégralité de l’infrastructure chez un autre hébergeur. Ici, ça pourrait être facile, tout repose sur des machines virtuelles a priori Linux qui sont simples à reproduire ailleurs, reste le stockage objet qui pourrait demander un peu plus de boulot, pas tant pour la mise en place ou la population, que pour la mise à jour des liens dans l’application.

C’est moins le cas quand on commence à utiliser beaucoup de services intégrés, la mode étant au « serverless », ce qui veut dire qu’on est encore plus dépendant de son hébergeur car chacun a sa propre méthode pour arriver à ses fins, ses propres services spécifiques, et donc il peut être très difficile voire impossible de transférer ça sur un nouvel hébergeur, ou alors doit être pensé pour être adaptable sur une architecture plus classique. Beaucoup plus de boulot, donc plus de temps, donc plus d’argent, quand la technique tape dans le porte-monnaie, on en revient toujours au même. Le piège est donc de ne pas chercher à tout pris le moins cher, mais bien d’intégrer les risques, en pensant toujours au pire même si on vivra toujours le meilleur.

La réponse du Cloud Hybride et de l’Infrastructure as Code ?

L’infrastructure as Code, pour la faire court, permet de décrire tous les éléments constitutifs de l’infrastructure dans un ou plusieurs fichiers, qu’on balance ensuite à un outil, soit générique, comme Terraform, soit spécifique à un fournisseur (CloudFormation pour AWS), qui s’occupe de déployer ces éléments. Ce type de pratique permet de conserver et de versionner cette description, et surtout de l’adapter très simplement à un autre fournisseur si le besoin s’en fait sentir. Ça permet d’améliorer ses chances de pouvoir déménager ou redéployer en urgence une infrastructure de zéro si une catastrophe majeure comme celle vécue ici survient. Je commence moi-même à mettre les mains dedans pour pouvoir assumer mon futur rôle d’intégrateur (et que intégrateur, quand je faisais un peu de tout jusqu’ici), et j’avoue que c’est très intéressant. Couplé à un Ansible pour s’occuper ensuite de la configuration des machines virtuelles (et Chef en plus chez LBN, pour gérer les accès, les outils de bases, la configuration du monitoring…), vraiment il faut s’y intéresser, même si c’est pour déployer une seule machine, ça permet d’en saisir les concepts, et la puissance.

Quant au cloud hybride, c’est un peu le sujet à la mode ces trois dernières années, après les premières déconvenues de gros comptes qui ont voulu tout « mettre dans le cloud » avant de voir à la fois les problèmes de réactivité et les soucis de facturation qui deviennent réels à mesure que l’infrastructure devient monstrueuse. Il s’agit de reposer à la fois sur des éléments hébergés « chez soi » que sur un hébergeur public, en utilisant des deux cotés les mêmes technologies. C’est d’autant plus facile que de plus de sociétés même modestes (et pour rappel, la France compte une majorité de PME, et pas d’entreprises multinationales) peuvent avoir accès à des réseaux fibres de plus en plus performants, et la montée en puissance de services « managés » basés sur Kubernetes, pour ne prendre que cet exemple, permettent d’agréger les deux types de ressources pour les exploiter via une interface unique, permettant du coup, au-delà de segmenter ce qui doit être stocké à l’extérieur de ce qui doit rester à l’intérieur, de s’affranchir si besoin de cet hébergeur qui devient vite un problème quand ses mauvais penchants viennent vous embêter un peu trop.

On a notamment IBM qui s’est offert RedHat qui propose pas mal d’outils reposant sur RedHat Enterprise Linux  et OpenShift (sa surcouche maison de Kubernetes, si vous trouvez déjà Kubernetes pénible OpenShift c’est pire, mais c’est beaucoup plus sécurisé). Si vous êtes un windowsien convaincu et avez besoins de VMs classiques, avec VMWare qui permet d’agréger plusieurs « datacenters » dans une même interface Vsphere, vous pouvez coupler un cluster hébergé chez un prestataire et un cluster sur site (« on premise », parce qu’on adore les anglicismes dans l’informatique). Avec un OVH qui propose du Private Cloud reposant justement sur ce type de solution, et même un AWS qui a annoncé se lancer sur ce type de produits récemment, vous avez au moins deux possibilités.

Le pognon, toujours le pognon

Globalement j’ai pas de problèmes avec l’argent, mais c’est un problème qui a trop souvent été mis sous le tapis sur le web. C’est malheureusement une réalité qui revient souvent trop tard sur la table, à force de chercher à tout prix à économiser des centimes, on se retrouve à payer des milliers, voire ici à devoir mettre la clé sous la porte (ça ne sera peut-être pas le cas vu que c’est restauré, mais dans les contrats clients on a souvent des pénalités en cas de non-respect des engagements — si seulement on avait ça pour le grand public, avec les fournisseurs d’accès et les opérateurs mobiles…). Il est donc nécessaire de mettre la priorité sur la couverture de risques plutôt que les rentrées faciles, un point compliqué quand on démarre une activité avec une levée de fonds et que les requins investisseurs attendent leur sandwich à la fin du trimestre.

Ça m’a rappelé une autre affaire, il y a deux ans, où OVH a perdu une baie complète de disques durs à cause d’un souci avec leur refroidissement liquide (et la paresse consistant à laisser du matériel qui n’est pas conçu pour se faire arroser par une fuite plutôt que de l’installer où il fallait, sur le principe du « ça fonctionne on touche pas »). Ça a touché des milliers de sites utilisant une offre d’hébergement mutualisée, un produit très peu cher (on parle de maximum 90€ TTC par an). Les restaurations ont été faites sur plusieurs jours sur une baie neuve avec des données nécessairement un peu anciennes, il y a donc eu pour certains perte de données. Et on a vu des personnes, qui opéraient une boutique en ligne sur cette offre, se plaindre d’avoir perdu masse d’argent et commencer à demander des dédommagements à OVH pour ces pertes engendrées. Oui, des gens qui ont basé leur activité sur une offre à 7€ par mois dont les engagements sont très faibles se plaignent à leur hébergeur de ne pas avoir fait le nécessaire pour assurer la disponibilité de leur principale source de revenus. Nous avons plusieurs clients « modestes » chez LBN en ce sens que leur boutique en ligne n’est pas énorme, mais ils déboursent un peu plus que 7€ pour garantir leur activité (on est plus près de 700€, et l’infra est petite). Et des interruptions trop fréquentes peuvent amener à des pénalités que l’on doit payer, autant dire que si on avait pas la conscience professionnelle pour nous, on aurait le portefeuille (vous voyez on y revient toujours).

Si vous êtes amenés donc à construire votre activité sur le web avec un besoin fort d’hébergement extérieur, il est nécessaire de s’assurer que tous les éléments, et notamment les situations de crises majeures comme celle qu’a vécu notre jeune pousse de l’analyse stratégique, soient bien pesés et pris en compte, aussi bien pour l’aspect financier que pour technique. À bon entendeur…

Dive pour analyser vos images Docker

lundi 3 juin 2019 à 18:30

Djerfy m’a fait récemment découvrir un outil écrit en Go particulièrement pratique quand vous manipulez fréquemment des images Docker, et que vous souhaitez vous assurer qu’elles n’ont rien de suspect avant de les déployer sur vos infrastructures. C’est d’ailleurs à l’occasion d’une découverte fâcheuse qu’il m’a partagé l’outil, et je me suis dit que vous faire une petite démonstration ne serait pas inutile.

Installation

Commençons déjà par disposer de l’outil sur notre machine. ArchLinux et Manjaro disposent d’un PKGBUILD sur AUR, sinon sur le dépôt GitHub le développeur met à disposition fichier DEB et RPM pour l’installation sur Debian/Ubuntu et RedHat/CentOS/Fedora.

Sinon, vous pouvez tenter la méthode manuelle après avoir installé Go. Il est même installable sous Mac et Windows. Bref, vous n’avez aucune excuse pour ne pas l’installer et en abuser.

Le fonctionnement par l’exemple

Dive vous permet d’inspecter chaque couche de votre image docker et de mettre en évidence les différences de chaque commande ayant généré une couche. Vous pouvez visionner la taille totale de l’image (pour rappel, Docker mutualise autant que possible les couches, très pratique si vous construisez plusieurs images à partir de la même base), visualiser les commandes associées aux différentes couches… et sur la droite, vous avez une arborescence complète qui s’adapte en fonction de la couche sélectionnée. Vous pouvez également filtrer l’affichage de cette arborescence, et les différences sont mises en lumière avec des couleurs.

Pour illustrer son fonctionnement, j’ai construit une petite image custom à partir de celle d’Nginx à laquelle j’ai ajouté un petit élément. Je n’ai pas choisi cet élément au hasard, ça fait partie des problèmes que Djerfy a détecté dans l’image qu’il avait analysé. J’ai ensuite fait analyser cette image par dive, et pour gagner un peu de temps, j’ai déjà filtré l’affichage afin de limiter les informations présentes :

En haut à gauche, on a les différentes couches avec les commandes associées. Comme Docker travaille avec des empreintes, ce sont les empreintes qui sont indiquées au lieu des noms des images. Idem pour les noms des dossiers/fichiers qu’on ajouterait, aussi bien que les URLs. Ceci dit, on a bien les chemins de destination, et c’est bien suffisant pour déterminer ce qui n’irait pas dans cette image. Ici, on découvre donc que quelque chose a été ajouté dans le dossier /root/.ssh/. Et la couche d’après indique que c’est un fichier id_rsa. L’arborescence de droite filtrée nous le confirme en vert (le jaune indique une modification, le vert une création).

J’ai ensuite vérifié si les soupçons sont avérés :

docker run --name some-nginx -d nginx-custom
9a28ae0c24ed2d153fa90d05ac29f572ade8ec3c5ff0f5ba9da05496e939137c
 seboss666  ~  dev  dive-test  docker container ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
9a28ae0c24ed        nginx-custom        "nginx -g 'daemon of…"   7 seconds ago       Up 5 seconds        80/tcp              some-nginx
 seboss666  ~  dev  dive-test  docker exec -ti some-nginx /bin/bash
root@9a28ae0c24ed:/# cd /root
root@9a28ae0c24ed:~# ls -la
total 20
drwx------ 1 root root 4096 Jun  1 19:10 .
drwxr-xr-x 1 root root 4096 Jun  1 19:11 ..
-rw-r--r-- 1 root root  570 Jan 31  2010 .bashrc
-rw-r--r-- 1 root root  148 Aug 17  2015 .profile
drwx------ 1 root root 4096 Jun  1 19:10 .ssh
root@9a28ae0c24ed:~# cd .ssh/
root@9a28ae0c24ed:~/.ssh# ls -l
total 4
-rw------- 1 root root 887 Jun  1 19:07 id_rsa
root@9a28ae0c24ed:~/.ssh# cat id_rsa 
-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDTFPvEnX5TVL5NdH7IN17FBwXF3SDZiE+kLbgFxntC3kArzgrX
CI40ZYT3bwEcU54dfDTz4whBzVlxf3iJUB1+47rNg6YCo2nuVS0NaJd2Kkh8U7TC
AIjKa0/RSntS7lOMd6cIQhyDUP25WOfpkvaFndwKvMqIsgcAfZskI5nTXQIBJQKB
gQCrJcU3okrAGzKD/Zc6jcJ2PQuZgtxdWcQIk8Wj0V0FyPXCpw+1RTUH45w+PlPt
dDsDJnAfsSlKHB8CFFPk9NmjrWO2t5Qy/bPM46MaJRYJjt41DhBULcJJ7i5Ore4z
3DYeEq4snnxxcDFfW5YOyhbwRSFxJSWR1zKbzztWhU54rQJBAPoCmEDkaZWI6zNB
(...)

Double bingo, on a bien ajouté une clé privée directement sur le compte root, et sans mot de passe en plus. Ouais c’est dégueu. Et c’est grosso modo ce qu’on a découvert dans l’image en question, pire, on sait exactement à quoi la clé détectée permet d’accéder.

D’autres fonctionnalités intéressantes

Un des signes qui montrent que l’on est face à un développeur consciencieux est la taille de l’image docker qui est prête à être déployée en production. Dive ambitionne de savoir détecter les gaspillages d’espace dans les images Docker, cependant le développeur lui-même indique la fonctionnalité est encore en cours de développement. Ça reste une fonctionnalité intéressante, à surveiller de près donc. Et vous avez un nouvel outil à rajouter dans votre besace pour Docker 🙂

Fail2ban et reverse proxy : c’est possible !

vendredi 24 mai 2019 à 18:30

Je l’ai dit à maintes reprises, Fail2ban est un outil très intéressant quand on peut l’installer et l’utiliser, et je le recommande dès que possible. Dans le cadre de l’analyse du trafic d’un serveur web toutefois, il y a un gros souci qui survient quand on a une architecture qui va au-delà du simple serveur Apache ou Nginx. Explications.

Dernièrement, un client s’est fait bombarder son site de vente de produits « bios », avec un modèle d’attaque qui semblait simple, mais pas facile à contrer, à savoir tabasser les pages du site et les recherches de produits. Dans un cas comme celui-là, on propose soit mod_evasive, soit fail2ban, soit mod_security, chacun ayant ses forces et ses faiblesses.

Ici, le problème principal vient du fait que le trafic ne parvient pas directement au serveur : en effet, le client fait appel à un CDN, Cloudfront en l’occurrence, et donc le serveur web ne voit techniquement que le trafic des instances Cloudfront par lesquelles passent les visiteurs, qu’ils soient légitimes ou pas.

Petit schéma simplifié de l’architecture du client

Donc au niveau d’Apache, ce qu’on voit, ce sont les IPs CloudFront et pas les IPs clients, qui sont déportées dans un entête HTTP X-Forwarded-For (« XFF »). Compliqué donc pour Fail2ban d’ajouter des règles iptables sur des ips qui ne seront jamais vues par le noyau. Dans un cas alternatif, on pourrait modifier l’action par défaut pour transformer ça en ajout dynamique d’une règle « Deny from  » avec un trigger sur XFF, mais le fichier htaccess est activement utilisé déjà par le moteur du site (Prestashop), le risque de dysfonctionnement est donc trop grand.

Netfilter est un petit malin

Ici c’est un CDN, mais la réflexion reste la même quand le serveur web se trouve derrière n’importe quel reverse-proxy/load-balancer/intermédiaire, tant qu’on a l’entête XFF, on peut agir. Ici, le site est en HTTPS, mais la terminaison est effectuée sur CloudFront, et le trafic repart en HTTP derrière, ce qui peut nous servir.

En effet, en cherchant une solution, j’ai découvert que via iptables, on pouvait définir des règles en fonction de la détection de chaines de caractères. Netfilter sait faire de l’inspection de paquets ! Ça ne fonctionnera qu’en HTTP 1.X évidemment, mais c’est une excellente nouvelle pour nous. Pour procéder, il faut utiliser iptables de cette manière :

iptables -I INPUT 1 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP

Évidemment, vous pouvez adapter la règle à vos besoins, vous avez compris que c’est le –string qui est le plus important. Je ne connais pas l’incidence de l’algorithme sur l’effectivité ou les performances par contre.

Il est donc possible de modifier les actions de fail2ban pour déclencher un drop sur la base du XFF. Pour les détails, je vous laisse consulter cet article en anglais, mais grosso modo :

Une solution qui a ses limites

Comme toute solution à un problème particulier d’ailleurs. En effet, d’une part, comme je l’ai dit ça implique que le protocole soit « en clair » ce qui est le cas d’HTTP 1.1, HTTP 1.0, mais pas HTTP 2, donc si vous avez du HTTP 2 de bout en bout, c’est cuit, il faudra procéder autrement.

Également, l’entête X-Forwarded-For n’est pas aussi fiable que l’adresse IP dans le paquet TCP. En effet, comme tout entête HTTP, il peut être abusé avant même d’être modifié par votre proxy (Cloudfront dans mon exemple), ce qui veut dire qu’il peut y avoir de fausses IPs dedans en plus de la vraie. On pourrait donc imaginer une sorte d’attaque pour bloquer certains visiteurs en ajoutant leur IP à une salve de requêtes avant même qu’ils essaient de visiter le site.

Pire, au moment de proposer cette solution, le modèle d’attaque avait changé : il n’y a plus une seule IP qui tabasse, mais une chiée plus quinze, qui font une requête à chaque fois avant de « changer ». En filtrant/comptant/classant les IPs, on constate que certaines sont très proches les unes des autres, proviennent d’hébergeurs étrangers et donc pas de vrais clients, ce qui laisse penser à une attaque distribuée via des sites compromis. Fail2ban et iptables sont donc compliqués à exploiter dans ce cas, car qualifier une plage d’ip comme provenant à coup sur d’un hébergeur non légitime et pas un vrai client potentiel est compliqué pour un robot. Idem pour la provenance géographique, voir du trafic arriver d’un hébergeur roumain sur un site de produits bios produits et vendus en France est simple à voir pour un humain, mais pour un script par contre…

De la même façon qu’on ne le verra pas avec HTTP 2.0, désormais, avec la majorité des sites reposant sur HTTPS, netfilter ne peut plus exploiter l’inspection pour détecter d’autres modèles, je pense par exemple à un blocage bas niveau de crawlers malveillants tout juste bon à saturer les sites de requêtes sans plus de ménagement; dans ce cas, seul le serveur web restera une barrière fonctionnelle, au prix d’une consommation de ressources un poil plus élevée (filtrage via mod_rewrite ou mod_setenvif).

Malgré tout, cette fonctionnalité d’iptables que je ne connaissais pas reste intéressante je pense, et je pensais qu’il était utile de la partager avec vous.

Quelques astuces diverses, seizième

mercredi 22 mai 2019 à 18:30

J’adore mon boulot, on a constamment les mains dans de nouvelles choses, on (re)découvre certains outils dont on pensait avoir une bonne maîtrise, et ça fait de nouvelles astuces à partager, en plus ça fait longtemps 🙂

Le piège du $_ENV vide dans PHP

Lors d’une migration d’un site sous Magento d’une VM Debian très mal configurée à un cluster AKS (Azure Kubernetes Service, je déconseille, allez sur un autre cloud provider), j’ai rencontré une difficulté liée à la récupération des variables d’environnement, la superglobale $_ENV de PHP était vide alors que phpinfo() me donnait bien ces variables.

Il s’avère que c’est lié à une configuration de la directive « variables-order » :

;old config
;variables-order="GPCS"
variables-order="EGPCS"

Voilà, par défaut il ne remplit que $_GET, $_POST, $_COOKIE, et $_SERVER (vous les avez les lettres ?). Dans un contexte plus classique on mettrait ces variables dans Apache et on les récupérerait via $_SERVER, mais ça ne s’appliquait pas ici.

Un repo git en souffrance : cannot lock ref ‘refs/remotes/origin/master’

J’ai eu cette erreur bizarre en bossant sur mon api de collection de films, en cherchant un peu, j’ai le coupable :

$ cat .git/refs/remotes/origin/master
{"chrome://browser/content/browser.xul":{

Normalement il devrait y avoir un hash md5 correspondant au dernier commit enregistré du dépôt distant, je ne sais absolument pas comment ça s’est produit mais c’est dégueulasse. Ceci dit ce n’est pas complètement bloquant, j’ai pu pousser mes modifications malgré tout, mais ça l’a perturbé quand même. Pour réparer il faut plusieurs commandes (et une sauvegarde en cas de besoin) :

git branch --unset-upstream
rm .git/refs/remotes/origin/master
git gc --prune=now
git branch --set-upstream-to=origin/master master

Si ça vous arrive sur une autre branche que master, vous devrez évidemment adapter le nom. Vous pouvez tenter un git pull pour vérifier qu’il n’y a plus d’erreur.

Sublime Text : afficher les espaces et les tabulations

Quand vous n’avez pas à disposition un linter potable, au hasard pour Python, vous tombez facilement sur des erreurs d’indentation mixte espaces/tabulation, ce qui est interdit en Python 3. Dans Sublime Text, pour mieux mettre ça en lumière, vous pouvez afficher les « espaces blancs », qui auront alors une forme différente en fonction du contexte :

"draw_white_space": "all",

Et comme une image vaut mieux qu’un long discours…

Les espaces sont représentés par des points, les tabulations par des traits horizontaux

Find : chercher les fichiers et/ou dossiers vides

Alors j’avoue j’ai plus le contexte de ce qui m’a poussé à faire cette découverte, mais voilà, si vous voulez faire le ménage des dossiers vides, ou déjà les identifier, c’est comme ça :

find . -type d -empty

Par contre, je me souviens avoir lu en fonction des sources qu’il pouvait y avoir des différences entre la version BSD et la version GNU de find (ah, ces libristes…).

wp-cli et « this does not seem to be a wordpress installation » : attention au yaml !

J’ai déjà évoqué wp-cli sur l’article qui me permet d’agréger les astuces diverses sur une page de récap. Cet outil puissant devrait vraiment faire partie des indispensables de tout administrateur WordPress. Mais parfois, il réserve quelques surprises, comme ici sur un WordPress fraîchement livré par une agence de développement, en voulant remplacer le domaine par celui de l’environnement concerné :

Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.

Et ça, même en passant le bon chemin (par défaut on l’exécute à la racine du WordPress). Il s’avère que les petits malins de l’agence ont glissé un petit fichier wp-cli.yml, interprété par l’outil, qui contenait la directive suivante :

path: web/wp

Évidemment, ça va fonctionner beaucoup moins bien. Une fois retiré ce fichier, wp-cli a fait son boulot comme un charme.

Sublime Text, crawl, cpu au secours !

J’ai eu un problème au boulot avec Sublime Text avec une arborescence conséquente, plusieurs Gigaoctets et des centaines (milliers ?) de fichiers, à chaque ouverture Sublime Text me tabasse le CPU pendant plusieurs minutes, parfois la dizaine facile. Et lors de la création du contexte de build pour Docker, la mémoire vive explose à son tour. Mais certains dossiers ne sont même pas inclus dans le dépôt, ni dans l’image Docker de destination, donc pas la peine de perdre son temps à les parcourir.

Et bien il y a une option dans Sublime Text pour ça, il suffit d’ajouter à son fichier de configuration :

"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS", "sites/static_*"],

Dans mon cas, c’est le sites/static_* qui m’a permis de gagner 2Go de contexte de build, et 8 minutes de consommation CPU au lancement, dû au crawl. Vous pouvez ajouter les vôtres, vous me remercierez ensuite 🙂

AWS EC2 et resolv.conf écrasé : retrouvez le bon DNS

Lorsque comme LBN vous gérez certaines configurations globales via un outil comme chef, il arrive parfois que l’on fasse des conneries, et qu’on paramètre certaines choses de travers sur des plateformes spécifiques. Dans mon cas les résolveurs DNS renseignés sur une instance EC2, qui à l’origine sont fournis par AWS via DHCP, ont sauté et été remplacés par des résolveurs qui ont plusieurs problèmes, le principal étant de ne pas être publics et donc de refuser la résolution récursive :

[root@server-p-01:~]# dig domain.tld

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61389
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;domain.tld. IN A

;; Query time: 17 msec
;; SERVER: 1.2.3.4#53(1.2.3.4)
;; WHEN: Tue Mar 26 13:23:51 2019
;; MSG SIZE rcvd: 36

Pour récupérer celui d’AWS, qui peut varier en fonction de la région, la zone de disponibilité, des subnets, on peut soit forcer un dhclient, soit regarder les anciennes réponses, car dhclient enregistre les baux dans un fichier, /var/lib/dhclient/dhclient-eth0.leases :

lease {
  interface "eth0";
  fixed-address 4.5.6.7;
  option subnet-mask 255.255.255.224;
  option routers 4.5.6.254;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 1.2.3.4;
(...)
}

Mieux que de reboot le serveur hein ?

Désactiver/interdire HTTP 1.0 sur Apache/Nginx

De nos jours, et à moins d’un besoin très, très spécifique, il n’est plus nécessaire de conserver ce protocole qui remonte à trop longtemps pour être honnête. Et en effet, dernièrement, à part via des outils peu scrupuleux qui tabassaient des plateformes ou tentaient de l’exploitation de faille, je n’ai pas vu d’utilisation légitime d’HTTP 1.0. Pour le bloquer au niveau de nos serveurs web préférés, il faut ajouter les directives suivantes :

#Apache
RewriteEngine On
RewriteCond %{THE_REQUEST} HTTP/1.0$
RewriteRule .* - [R=429]

#Nginx
if ($server_protocol ~* "HTTP/1.0") {
    return 429;
}

Évidemment, si vous avez une utilisation légitime d’HTTP 1.0 (et encore, ça me surprend quand même j’ai découvert que file_get_contents() en PHP fonctionnait comme ça…), il faudra procéder autrement (peut-être ajouter un filtrage IP supplémentaire).

Du lien symbolique « automatique » à partir d’un dossier

Quand on installe des certificats X509 pour des clients, on a l’habitude de créer des dossiers par année d’installation, et de créer des liens symboliques vers les fichiers dans le dossier en cours, liens qui servent ensuite dans la configuration du serveur web. Quand les fichiers du dossier de l’année ont déjà le bon nom, pour faire les liens symboliques, on peut le faire en une seule commande :

ln -s 2019/* .

Pour chaque fichier du dossier 2019, ça va créer le lien dans le dossier courant, lien qui porte le même nom que le fichier source. Très pratique 🙂

Améliorer les performances des volumes Docker

J’ai du pas mal manipuler de Docker ces dernières semaines, et aussi bien dans ma machine virtuelle que sur les plateformes client, les performances du stockages sont un point d’attention à ne pas laisser de côté. Docker permet quelques manipulations sur ce point, sur la machine virtuelle, je ne peux que vous recommander, si vous ne faites que des tests, d’abuser du cache. Une des méthodes les plus simples, dans le fichier docker-compose, déclarer votre volume de cette manière :

volumes:
      - /home/seboss666/docker/grafana:/var/lib/grafana:cached

Pour les détails et les impacts sur les performances (et l’intégrité des données), je vous laisse avec cet article en français, une fois n’est pas coutume, qui s’est penché sur le sujet.


Trois mois mine de rien, il était temps de remettre ça. J’ai plus rien en stock par contre dans l’immédiat, et je ne sais pas encore quand je vais pouvoir remettre ça.