Les recommandations sur le thème des sauvegardes foisonnent sur internet et dans la presse informatique. Chacun y vante sa méthode, ses logiciels, etc. Pour ne pas être en reste, et parce que je pense que la manière dont je procède à mes sauvegardes personnelles est intéressante, je vais présenter ci-dessous les quelques principes sur les quels je m'appuie. Continue reading
Archives
Que nous apprend l’affaire « Gawker »
Comme je l'évoquais brièvement dans un précédent article, les serveurs de l'entreprise de média en ligne Gawker ont été piratés récemment, avec pour conséquence immédiate la diffusion au public des logins, emails, et mots de passe chiffrés de plus d'un million d'utilisateurs. Pour plusieurs centaines de milliers d'entre eux, les mots de passe avaient même été déchiffrés avant leur diffusion.
Pour quelqu'un comme moi les dessous de l'affaire sont croustillants, et les détails techniques sont même passionnants. Mais, plus important : tout le monde a une leçon à tirer de ce fiasco monumental.
Cette leçon, et non des moindres, est la suivante : dès l'instant où vous confiez un mot de passe à quelqu'un, ce mot de passe est vulnérable. Ça paraît tout bête comme ça, on se dit "mais oui, c'est sûr qu'en donnant mon mot de passe à mon voisin, alors il n'est plus secret". Non. Relisez bien la leçon, elle est à prendre au premier degré. Oubliez votre voisin, votre copine. Vous créez un compte chez Hotmail, vous choisissez un mot de passe pour pouvoir accéder plus tard à votre boîte mail, vous fournissez ce mot de passe à Hotmail. Ça y est, ce mot de passe n'est plus sûr. Un jour, c'est inévitable, c'est déjà arrivé, et ça arrivera à nouveau, des serveurs Hotmail seront piratés et votre mot de passe pourrait tomber dans les mains de quelqu'un.
L'affaire Gawker est bourrée d'exemples illustrants parfaitement ce principe. Les employés de chez Gawker s'échangeaient des mots de passe par chat, dont les archives des conversations ont été piratées. Le piratage des bases de données des sites de Gawker a montré que les mots de passe des utilisateurs n'étaient pas sécurisés : le chiffrement utilisé était archaïque et connu depuis des années pour être déficient, etc. etc.
Continue reading
De la sécurité de vos mots de passe
En terme de mot de passe, on nous rebat souvent les oreilles avec des recommandations sécuritaires qui tombent sous le sens. Par contre, les arguments qui sous-tendent ces recommandations sont parfois largement infondés.
Tout d'abord, on nous dit de ne pas choisir un mot de passe facile à deviner, c'est bien sûr du bon sens. On nous dit que le mot de passe doit être long, car les ordinateurs actuels permettent de tester des milliers de mots de passe par seconde. Plus le mot de passe est long, plus il sera long à trouver. Certes. C'est mathématiquement exact. Mais à quoi arrive-t-on si on force les gens à utiliser un mot de passe à la fois long et compliqué ? Ils vont utiliser le même mot de passe partout, ils vont le noter quelque part, etc.
Imaginons un instant qu'un pirate tente de deviner votre mot de passe de messagerie. Il a une très bonne connexion internet, et son ping (le délai qui s'écoule entre le moment où il envoie une requête au serveur, et le moment où le serveur dit qu'il a bien reçu cette requête) est de 10 millisecondes. Il faut ajouter à cela le temps de traitement sur le serveur, et l'envoi de la réponse. Mettons pour simplifier que la totalité de la transaction dure 20 ms. Si votre mot de passe de messagerie fait 8 caractères différents et qu'il utilise des lettres minuscules (26 possibilités), des lettres majuscules (26 possibilités), et des chiffres (10 possibilités), c'est probablement assez correct. Ce mot de passe utilise donc 8 caractères différents pris dans une série de 62. Soit un total de 136325,9 milliards de mots de passe possibles. À raison d'un mot de passe testé toutes les 20 ms, cela donne plus de 864 siècles, pour tester tous les mots de passe.
Maintenant, ajoutez des caractères parmi @#&"'(§!)-_$*/:;.,?+ (20 possibilités), et il faudra presque 9114 siècles pour tester tous les mots de passe.
Moralité, la puissance des ordinateurs permet effectivement de tester des millions de mots de passe par heure, mais la latence des connexions internet rend ce mode d'attaque quasiment impossible, car elle ralentit terriblement le processus.
Continue reading
Capture et analyse distante avec Wireshark
Wireshark est un outil sympathique, quand vient le moment d'analyser ce qui passe sur un réseau, qui fait quoi, quel protocole prend toute votre bande passante, etc. Malheureusement, la machine sur la quelle on voudrait faire l'analyse n'est pas toujours celle sur la quelle vous pouvez lancer le logiciel.
Il est possible facilement de capturer les paquets voulus sur une machine, et de les analyser à postériori sur une autre. Par contre, effectuer une analyse en direct et à distance nécessite d'utiliser quelques astuces.
Avant d'aller plus loin dans les explications, voici quelques pré-requis :
- Vous devez installer Wireshark sur votre machine (A)
- Vous devez aussi pouvoir vous connecter en root via SSH sur la machine que vous voulez utiliser pour la capture (B)
Dans un premier temps, il s'agit de créer un socket UNIX via mkfifo. C'est ce socket que votre Wireshark va lire en local sur la machine A.
mkfifo capture.fifo
Dans un deuxième temps, il faut ouvrir une connexion SSH de A vers B, lancer tcpdump dans cette connexion, et rediriger la sortie standard dans votre tout nouveau socket.
ssh root@machineB tcpdump -s 0 -U -n -w - -i ath0 > capture.fifo
Remplacez ath0 par le nom de l'interface réseau qui vous intéresse, et éventuellement, ajoutez aux options de tcpdump les filtres adéquats pour affiner votre analyse.
Attention, pour une connexion avec mot de passe, ssh ne vous demandera le fameux sésame qu'au moment où Wireshark ouvrira le socket. C'est à dire à l'étape suivante.
Dans un troisième et dernier temps, vous pouvez lancer Wireshark sur la machine A si ce n'est déjà fait, et le configurer pour lire votre socket capture.fifo. Pour cela, ouvrez les options de capture, et saisissez le chemin de votre socket dans le champ "interface" :
Enfin, cliquez sur "Start" pour lancer la capture, et si nécessaire, tapez votre mot de passe pour la machine B dans la fenêtre de terminal où votre connexion SSH est établie.
De la sécurité des applications web
Je suis retombé il y a peu de temps sur quelques messages échangés avec le développeur d'un jeu en ligne sur plateforme LAMP (Linux Apache MySQL PHP). C'était entre février et juin 2004, nous (#sden "canal historique") avions beaucoup trop de temps libre, et pas assez de choses intelligentes à faire. À l'époque, le concepteur du jeu ajoutait de nouvelles options et fonctions presque quotidiennement, signe que le code derrière ne devait pas être bien propre. Comme le jeu imposait une limite d'actions par unité de temps, et que tout ceci n'allait pas assez vite pour nous qui passions des journées entières rivés à l'écran, il a fallu prendre les choses en main.
On lui a tout fait, le pauvre. Tout, de l'empoisonnement de variables aux injections SQL. Avec à chaque fois un rapport de bug, bien sûr, nous ne voulions pas avoir le mauvais rôle.
Le plus dur a sans doute été de faire accepter à ce développeur d'applications compilées locales, qu'une application interprétée en ligne ne peut pas se programmer avec laxisme.
Le pire dans tout ça, c'est que le genre d'erreurs grossières de programmation commises par ce développeur est encore monnaie courante. La dernière faille de wordpress en est un parfait exemple.
Alors bien sûr, il existe maintenant des outils sophistiqués pour lutter contre certaines attaques. mod_security pour Apache permet par exemple de bloquer toute forme d'injection SQL, certains empoisonnements de variable et d'autres types d'attaques. Pour être efficace il réclame néanmoins un paramétrage complet calqué sur le fonctionnement de votre application.
Il serait tellement plus efficace de bien coder son application dès le départ !
Sans prétendre être exhaustif, voici quelques recommandations :
Configurez votre serveur web en mode "production", de sorte qu'il n'affiche pas sa version ni la version des modules chargés. Sur Apache, cela se passe dans le httpd.conf sous la forme ServerTokens Prod.
Ainsi, votre serveur est identifié sous le nom Apache au lieu de Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7l DAV/2 PHP/5.2.8 SVN/1.4.4
Si c'est possible, configurez votre firewall pour qu'il ne laisse pas sortir l'utilisateur "apache" (en général www, ou httpd), sur d'autres ports que les ports 80 et 443. Sous PF (freebsd/openbsd) cela peut se faire comme ceci :
pass out quick proto tcp from any port 80 to any user 80 keep state
pass out quick proto tcp from any port 443 to any user 80 keep state
block out log proto { tcp, udp } user 80
Si vous ne pouvez pas faire ce blocage dans le firewall, faites au moins en sorte que votre interpréteur ne puisse pas ouvrir de sockets, ni accéder à n'importe quel fichier du serveur.
Configurez votre interpréteur (souvent PHP) pour ne pas retourner les erreurs. Au pire, créez un virtual host de développement pour vous-seul, qui affiche les erreurs, et assurez vous que les erreurs ne s'affichent pour personne d'autre. Utilisez log_errors = On dans votre php.ini pour enregistrer les erreurs dans un fichier désigné par error_log = /var/log/php_error.log.
Ne faites jamais confiance à l'utilisateur. Il arrivera toujours un moment où il va tripoter l'URL pour changer un paramètre, il peut aller jusqu'à modifier un formulaire pour injecter du code SQL dans une variable postée.
Ne faites pas confiance à javascript pour contrôler la validité des données. Contrôlez toujours côté serveur que les nombres sont des nombres, les chaînes de caractères sont bien ce qu'elles doivent être…
Si vous devez transmettre des données importantes via cookie/url/autre, n'hésitez pas à les chiffrer, ou à les accompagner d'un hash pour détecter une altération éventuelle.
Le referer (l'URL de provenance) est une donnée fournie par l'utilisateur. Ne bâtissez aucun système de sécurité à partir du referer.
Ne vous méprenez pas, il est possible d'attaquer un serveur (par injection SQL notamment) en aveugle. Même si aucune erreur n'est retournée par PHP, la page sans injection sera différente de la page avec injection, et cela suffit en général pour savoir si le code injecté est bien interprété. Il est donc vraiment vital de contrôler les données envoyées par l'utilisateur.
Par essais successif, il peut être possible de lire des informations dans la base de données. Par exemple, on peut créer une injection SQL qui va juste comparer le Nième caractère d'un champ de la table avec un caractère qu'on propose. Il suffit de faire en sorte que la requête SQL échoue si le caractère est juste et ne fasse rien si le caractère n'est pas le bon (ou inversement). Suivant la page html obtenue, même sans affichage d'erreur, on saura quel caractère est en quelle position dans le champs de la table.
Imaginons que mon champ contienne un mot de passe en clair de 10 caractères (c'est MAL). Cela fait un maximum de 10x255 caractères à tester, si on s'en tient à l'ASCII. Via injection SQL, j'aurai donc au maximum 2550 tests à faire pour trouver le mot de passe de 10 caractères. Si je décide non pas de tester le caractère, mais plutôt les bits qui constituent ce caractère, je n'ai plus que 8 tests à faire. En 80 tentatives au maximum, je trouve le mot de passe. Rapide, efficace, et surtout sensiblement plus discret.
Utiliser la liste DROP de Spamhaus dans PF
Spamhaus, dont le travail quotidien consiste à maintenir des listes noires de spammers potentiels ou avérés, met aussi à disposition des utilisateurs une liste noire assez particulière : la liste DROP, pour Don't Route Or Peer.
Cette liste relativement courte regroupe les blocs d'adresses IP dont Spamhaus est certain qu'ils sont utilisés par des pirates ou des spammers professionnels.
Vous pouvez donc utiliser cette liste pour alimenter votre pare-feu, sans trop vous poser de question. Vous ne raterez aucun email légitime, ni aucun visiteur sur vos sites, si vous bloquez toutes ces adresses dans votre firewall.
La liste change de temps en temps. D'après mon expérience, pas plus d'une fois par jour. On peut donc assumer sans risque qu'une mise à jour quotidienne du firewall est largement suffisante. Mon firewall étant PF (Packet Filter sur FreeBSD et OpenBSD), mon exemple sera directement utilisable avec ce pare-feu. Pour les autres logiciels (ipfw par exemple), il faudra faire un travail d'adaptation.
Pour plus de simplicité, je laisse periodic lancer le script chaque nuit vers 3h15. Je crée donc un fichier /usr/local/etc/periodic/daily/310.spamhaus_dropall exécutable, et en lecture uniquement (sauf pour root).
Je dois aussi créer une table spamhaus_dropall dans la configuration de PF en ajoutant les lignes suivantes à mon /etc/pf.conf :
Dans les définitions de tables :
table <spamhaus_dropall> persist { }
Dans les règles proprement dites :
block in log quick proto tcp from <spamhaus_dropall> to any
Cette table, vide par défaut, va stocker le contenu filtré de la liste DROP, et sera mise à jour toutes les nuits.
Ensuite je force pf à relire la configuration par la commande pfctl -vf pf.conf.
Voici le code du script, à écrire dans /usr/local/etc/periodic/daily/310.spamhaus_dropall :
#!/usr/local/bin/bash
echo downloading/cleaning blacklist drop.lasso
TMPFILE=`mktemp /tmp/drop.XXXXXX` || exit 1
/usr/local/bin/curl -s http://www.spamhaus.org/drop/drop.lasso | \
sed 's, ;.*,,' | \
egrep '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}*$' > \
${TMPFILE}
echo flushing the spamhaus_dropall table
egrep -v '^127|^WHITELIST' ${TMPFILE} | \
pfctl -t spamhaus_dropall -vT replace -f -
La première étape consiste à télécharger la liste. Dans la foulée, les commandes sed et egrep me permettent de nettoyer et filtrer le contenu du fichier envoyé par Spamhaus.
Le fichier original ressemble à ceci :
; Spamhaus DROP List 11/24/08 - (c) 2008 The Spamhaus Project 116.199.128.0/19 ; SBL56563 116.50.8.0/21 ; SBL54501 128.199.0.0/16 ; SBL62478
Le fichier filtré et nettoyé, dont le contenu est écrit dans le fichier temporaire TMPFILE ressemble à cela :
116.199.128.0/19 116.50.8.0/21 128.199.0.0/16
L'étape suivante consiste à injecter les nouveaux blocs d'IP dans la table pour les faire prendre en compte par le firewall. Par mesure de précaution, j'ai choisi de filtrer ici les IP de la classe 127.0.0.0/8 ainsi que toutes les IP dont je ne veux absolument pas qu'elles figurent dans la blacklist. On n'est jamais à l'abri d'un dysfonctionnement de Spamhaus, ou du script, ou d'une malveillance locale sur la machine. Je remplace donc ^WHITELIST par tous les préfixes d'IP que je juge nécessaire (par exemple ^83.225. si mon IP résidentielle commence par "83.225"), et je les sépare par un |.
La commande egrep -v me permet donc d'exclure toutes les lignes que je veux sortir de la liste, et envoie le reste à pfctl pour remplacer le contenu de la table spamhaus_dropall par les nouvelles IP.
Voici un exemple de sortie, telle qu'elle apparaît dans le mail de daily :
downloading/cleaning blacklist drop.lasso flushing the spamhaus_dropall table 8 addresses added. 1 addresses deleted. A 192.43.153.0/24 A 192.43.154.0/23 A 192.43.156.0/22 A 192.43.160.0/24 A 192.86.85.0/24 A 78.157.128.0/19 A 91.209.14.0/24 A 94.176.96.0/20 D 94.176.96.0/21
Le script est bien sûr perfectible. Mais c'est une base de travail qui fonctionne.
Neutre comme la Suisse
La neutralité des réseaux n'est pas un vain mot pour les défenseurs d'un Internet sans frontière ni péage. Chacun devrait d'ailleurs prendre conscience que cette neutralité est fragile, et que des lobbies d'opérateurs internet sont bien décidés à y mettre un terme. En mots de tous les jours, cela signifierait que si vous êtes abonnés à Internet chez le fournisseur X, vous pourriez bien avoir des problèmes pour accéder à Youtube, ou à des contenus hébergés par l'entreprise Y. Pire, vous pourriez vous voir interdir ou facturer l'usage de certains protocoles. En tant qu'entreprise, vous devriez payer plus cher pour que les abonnés de tel ou tel fournisseur d'accès puissent accéder à vos serveurs.
L'entreprise Proxad (Online, Free, Dedibox, ...) a déjà recours à ces procédés. Par exemple, une connexion vers un serveur Dedibox sera très lente si vous êtes aux États Unis, alors qu'elle sera rapide si vous êtes en France. Un téléchargement de fichier hébergé sur dl.free.fr sera très rapide si vous êtes sur une connexion ADSL Free, mais d'une lenteur dissuasive chez n'importe quel autre opérateur.
Dans un domaine similaire, on a constaté que le fournisseur d'accès américain Comcast a tenté de bloquer l'utilisation de Bittorrent par des procédés douteux.
Face à ces menaces, l'Electronic Frontier Foundation a commencé à travailler sur un logiciel client-serveur qui sera capable de déterminer si le traffic réseau émis par une machine a été modifié entre la source et la destination. Ce logiciel, Switzerland, est en version 0, donc encore largement inutilisable par le grand public. Néanmoins, son fonctionnement est prometteur, et j'ai déjà pu effectuer quelques tests avec l'aide d'autres utilisateurs.
Le principe de fonctionnement de Switzerland est le suivant :
- Un serveur Switzerland tourne quelque part sur internet
- Les utilisateurs (vous, moi, des serveurs web/mail/... sur internet) lancent le client Switzerland sur leur machine et se connectent au serveur Switzerland
- Les utilisateurs se connectent les uns aux autres et échangent des données (vous relevez vos mails, nous partageons une ISO de FreeBSD via Bittorrent, ...)
- Votre client Switzerland calcule un checksum des paquets que vous envoyez vers moi, ou vers un service en ligne qui utilise le client Switzerland
- Chaque checksum est envoyé au serveur central Switzerland
- Le client Switzerland du destinataire des paquets calcule à son tour le checksum du paquet, et les envoie au serveur Switzerland
- Le serveur Switzerland compare les checksums des paquets, pour détecter les modifications
Dans le cas où une modification est détectée, le serveur Switzerland demande alors aux clients impliqués dans la connexion de lui envoyer les paquets complets, et non plus les checksums. Ainsi, il peut se livrer à une analyse détaillée de ce qui a été modifié. Donc tant qu'il n'y a pas de problème, vos échanges restent absolument privés. Mais dès l'instant où un opérateur modifie des informations dans vos échanges, certaines données seront transmises au serveur Switzerland.
Switzerland est encore loin d'être utilisable. C'est un logiciel en plein développement. Néanmoins, si vous souhaitez le tester voici quelques remarques :
- Lisez bien tout ce qu'on vous dit sur http://www.eff.org/testyourisp/switzerland
- Vous devez avoir une installation de Python pas trop ancienne
- Vous devez avoir une horloge parfaitement synchronisée
- Si vous utilisez open-ntpd comme moi, veillez à ce que ntpdc soit hors d'atteinte (renommez le)
- Si comme moi vous n'utilisez pas ntpd (soit rien, soit autre chose), utiliser l'option -u 0
- Actuellement, le serveur de test officiel est cassé, vous pourrez trouver d'autres adresses de serveur sur le wiki officiel
- Vous devrez probablement désactiver votre firewall pour les tests, les NAT peuvent aussi poser quelques soucis
- Sous Linux, si le client meure en disant "...Check for Large Segment Offloading on gigabit Ethernet cards...", essayez de régler le problème avec la commande `ethtool -K eth1 tso off` (à adapter en fonction de votre configuration)
- C'est un logiciel connecté qui tourne en root, donc la prudence habituelle est de rigueur
Recherchons administratrice système polyvalente
Une fois de plus, nous cherchons une perle rare pour notre service. Voici le texte de l'annonce :
Recherchons administratrice système polyvalente.
Cette administratrice s'intègrera dans une équipe restreinte chargée de l'infrastructure matérielle de l'environnement numérique de travail de l'université Lumière Lyon 2. Cet ENT est utilisé par environ 30 000 personnes. Ces outils regroupent les outils du bureau virtuel (courrier électronique, agenda, carnet d'adresse, documents...), les sites web institutionnels et personnels (plus d'une cinquantaines de sites web), les outils administratifs (gestion de notes pour les enseignants, consultation des notes, emploi du temps pour les étudiants...), la plateforme d'enseignement en ligne…
Elle participera aux activités suivantes :
- Administration, surveillance et maintenance d'une quarantaine de serveurs fonctionnant sous Mac OS X et Linux Debian.
- Administration d'un réseau privé et d'un commutateur d'applications Nortel utilisé pour de la répartition de charge applicative.
- Installation physique et logicielle, câblage de machines fonctionnant sous Mac OS X et Linux Debian à l'intérieur d'une salle serveur.
- Installation, création d'outils de surveillance, d'analyse et de maintenance.
- Participation à la définition des architectures matérielles et logicielles à mettre en place pour le déploiement d'applications WebObjects ou JEE, Ruby ou PHP.
- Mise en place et administration d'applications fonctionnant avec Apache, MySQL et PHP.
- Mise en place et administration d'applications de diffusion de fichiers vidéo ou sons.
- Mise en place de procédure et solution de sauvegarde.
- Administration d'une architecture Xsan.
- Participation aux astreintes pour offrir une continuité de service 24h/24h, 7j/7j, 365j/365j.
Cette administratrice doit avoir des connaissances Linux, Mac OSX. Elle doit être capable d'installer un outil à partir de son code source. Elle doit être capable de lire et d'écrire des scripts shell et des scripts dans un langage comme Ruby, PHP ou Perl. Elle doit être avoir des connaissances dans le domaine de la sécurité, des annuaires.
Elle devra être capable de s'adapter à des technologies et des outils en évolution rapide.
Notez que si vous êtes un homme, vous pouvez quand même tenter votre chance ;-)
Par ailleurs, je ne précise pas à qui il faut écrire, on ne serait probablement pas intéressé par quelqu'un qui ne saurait pas retrouver cette information.