Lutter contre le SPAM avec DKIM et SPF

Posted on par

Il y a fort longtemps, dans une lointaine galaxie nommée Internet, les serveurs SMTP (Simple Mail Transfer Service) relayaient les e-mails sans poser de questions. Puis les vilains SPAMMEURS ont débarqué et il fallut commencer à tout repenser. Nous allons voir ici comment s’est organisée la lutte contre ces êtres démoniaques et pourquoi il est devenu essentiel de mettre en place des technologies telles que SPF et DKIM pour prouver que les e-mails que vous envoyez proviennent bien de votre serveur SMTP et pas d’un autre.

Quel est le rôle du serveur SMTP dans l’envoi et la réception de mail ? Ce dernier est appelé MTA (Mail Transfer Agent) et il est voué à distribuer les e-mails que vous envoyez à leurs destinataires et à recevoir (stocker d’une manière cohérente sur le serveur) ceux que vous recevez. Le MTA est le seul élément indispensable pour envoyer et recevoir des e-mails, les serveurs POP/IMAP sont des services mis en place pour permettre à l’utilisateur de récupérer les e-mails sur le serveur SMTP à l’aide d’un client (Client lourd : Outlook, Thunderbird, Mail… , Webmail, Smartphone …).

Les serveurs SMTP les plus connus et utilisés sont l’historique Sendmail et ses petits frères Postfix Exim Qmail. Les exemples de configuration que vous pourrez trouver dans la suite de l’article sont issus de Postfix.

Comment le serveur SMTP fait-il pour savoir où acheminer le courrier ? Simple comme bonjour, il interroge la zone DNS du domaine — partie à droite de l’@ dans une adresse mail — qu’il souhaite joindre à la recherche d’un enregistrement MX (Mail Exchanger) qui pointe vers l’IP du serveur mail chargé de collecter le courrier pour ce domaine. Si vous cherchez à envoyer un mail à cam@bibabox.fr, votre serveur SMTP va chercher où envoyer le mail dans la zone DNS de bibabox.fr. Vous pouvez faire le test vous-même à l’aide de la commande Nslookup.

> nslookup -q=mx bibabox.fr

bibabox.fr MX preference = 1, mail exchanger = mx0.ovh.net
bibabox.fr MX preference = 100, mail exchanger = mxb.ovh.net

Vous noterez la présence de deux enregistrements MX qui diffèrent par leur « préférence » ou « priorité ». Ici non plus rien de bien sorcier, on commence par essayer de joindre le serveur avec la priorité la plus basse, et s’il ne répond pas on passe au serveur avec une priorité plus haute jusqu’au premier serveur qui répond. A noter qu’il serait sûrement préférable de laisser tomber les enregistrements MX au profit des enregistrements SRV, qui proposent plus de fonctionnalités, comme la répartition de charge ou encore la possibilité de spécifier le port où est hébergé le service.

Pour l’image, le MTA c’est un peu la poste, la société s’occupe de transférer le courrier d’un bureau de poste (serveur) à un autre en se basant sur votre adresse (e-mail) où le code postal fait office de champ MX permettant de savoir dans quel bureau de poste envoyer le courrier. Le MUA c’est votre facteur, il délivre le courrier qui arrive au bureau de poste dans votre boîte aux lettres (Ordinateur, Téléphone, PDA …). L’intérêt de l’échange de mail sur l’échange postal c’est que l’on peut facilement recevoir le courrier à plusieurs endroits simultanément en laissant une copie du message sur le serveur pour une durée plus ou moins longue.

Tout comme la poste, par défaut le serveur SMTP ne cherche pas à vérifier l’adresse de l’émetteur, ni plus qu’il ne cherche à authentifier la personne utilisant le service. Une bagatelle pour les Spammeurs et autres individus malveillants agissant sur la toile. La première chose à faire est donc d’implémenter les mécanismes de sécurité dont vous avez besoin afin que votre serveur SMTP ne devienne pas un relais-ouvert utilisable par le premier venu. Les systèmes de configuration des serveurs mails disposent de mécanismes permettant d’accepter ou de rejeter l’envoi d’un mail en se basant sur la configuration du client ou sur la destination. Les directives de configuration smtpd_client_restrictions ou smtpd_recipient_restrictions (Postfix) permettent par exemple de faire ce travail. C’est pourquoi la valeur de ce genre de directives est extrêmement importante et ne doit en aucun cas être laissée au hasard. Si votre serveur SMTP est ouvert sur internet, il vous faudra aussi certainement mettre en place un mécanisme d’authentification tel que SASL, afin que seuls les utilisateurs disposant d’une boîte mail — et donc d’un couple login/mot de passe associé — sur votre serveur puissent l’utiliser. Bien entendu, comme en SMTP tout passe en clair et que vous n’avez pas envie que quelqu’un puisse attraper votre mot de passe ou lire les mails que vous envoyez, il faudra mettre en place une surcouche SSL/TLS avec un certificat valide pour avoir enfin un service sécurisé à proposer à vos utilisateurs.

Votre serveur SMTP est maintenant sécurisé et seuls les utilisateurs authentifiés sont autorisés à l’utiliser, le courrier qui en sort peut donc être considéré comme légitime. Mais puisqu’il est possible d’envoyer des mails sans aucune vérification de l’identité de l’expéditeur via n’importe quel serveur non sécurisé, qu’est-ce-qui prouve à votre destinataire que le courrier qu’il vient de recevoir de vous est bien légitime ? Puisque notre serveur est considéré comme digne de confiance, on va donc chercher à établir l’identité du serveur qui a envoyé le message et à vérifier qu’il s’agit bien d’un serveur digne de confiance. C’est exactement le but des enregistrement DNS SPF et DKIM.

SPF (Sender Policy Framework) est une norme de vérification du nom de domaine de l’expéditeur d’un mail, normalisé dans la RFC4408. SPF vise à réduire les possibilités d’usurpation en publiant, dans le DNS, un enregistrement (de type SPF ou, autrefois, de type TXT) indiquant les adresses IP des serveurs qui sont autorisées à envoyer du courrier pour le domaine considéré. Quand le serveur SMTP de destination reçoit le mail, il peut faire une vérification de ce type, auquel cas soit il décide de refuser purement et simplement le mail soit il peut l’accepter tout de même. Il peut encore décider de notifier l’utilisateur — en rajoutant une ligne dans le corps du message par exemple — ou l’administrateur. Plus généralement cela va surtout influer sur le score que l’anti-spam mis en place chez votre destinataire accorde à votre message et c’est ce dernier qui décidera du sort de ce message. La décision à prendre en cas d’échec de la vérification ou d’absence d’enregistrement SPF appartient à la solution mise en place par l’administrateur. Gardez simplement à l’esprit qu’aujourd’hui encore, seul un trop faible pourcentage des domaines comportent un enregistrement SPF avant de rejeter tout les mails qui ne remplissent pas cette condition.

exemple d’enregistrement SPF :

v=spf1 a mx ptr ip4:1.2.3.4 mx:mail.exemple.com ~all

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un mail, normalisé par l’IETF (Internet Engineering Task Force) dans le RFC 4871 pour palier aux faiblesses de SPF. DKIM a été produit par un consortium industriel en 2004. Il intègre et améliore DomainKeys de Yahoo! et Identified Internet Mail de Cisco. Il est à noter que d’autres acteur majeurs de l’Internet et des systèmes d’information ont pris part au projet, IBM, Microsoft, PGP Corporation, Sendmail, StrongMail Systems … Le but final de la solution est le même que pour SPF : lutter contre le spam et l’usurpation d’identité. On trouve des implémentations libres prêtes à être couplées aux principaux MTA. Le projet le plus abouti à ce jour semble être OpenDKIM.

Exemple d’enregistrement DKIM :

mail._domainkey.example.com. IN TXT « v=DKIM1; k=rsa; p=MEwwPQRJKoZIhvcNADAQCQADOwAwOAIxANPpYHdE2tevfEpvL1Tk2dDYv0pF28/f5MxU83x/0b sn4R4p7waPaz1IbOGs/6bm5QIDAQAB »

Mais qu’apporte DKIM par rapport à SPF ?

SPF se base sur des adresses IP — ou des blocs d’adresses IP — pour vérifier la provenance du message. Seulement, et contrairement à ce qu’essaie de nous faire croire le gouvernement français et sa HADOPI , une adresse IP n’est pas une preuve irréfutable, et il est relativement facile ou en tous cas loin d’être impossible d’usurper une adresse IP sur un réseau. Cette technique s’appelle le spoofing. C’est pourquoi on a recours ici à un système cryptographique asymétrique. On génère une paire de clefs, on stocke la clef publique dans un enregistrement de type TXT de la zone DNS concernée, et on stocke bien précieusement la clef privée sur le serveur. A chaque fois que le serveur SMTP va envoyer un mail, il va chiffrer une petite partie du message à l’aide de sa clef privée. A la réception du message, le serveur SMTP qui détecte ce champ va chercher à le déchiffrer avec la clef publique disponible dans la zone DNS du domaine de l’expéditeur. Si l’opération aboutit, il peut alors assurer que le message reçu provient bien d’un serveur possédant la clef privée. Il devient ainsi impossible — sauf cas du vol de la clef privée — d’usurper l’identité d’un serveur SMTP. Ici aussi les décisions qui découlent de la vérification sont à définir par l’administrateur (acceptation, rejet, notification à l’utilisateur ou à l’administrateur …).

Voici comment Gmail notifie ses utilisateurs du résultat de ses tests :

Mais alors pourquoi mettre en place de telles solutions puisque tout le monde ne le fait pas ? Tout da’bord car ça fait clairement partie des « Best Practices ». Ensuite, c’est un geste citoyen qui permet de réduire globalement le fléau qu’est le spam — c’est bien pour cela qu’autant d’acteurs industriels se sont rassemblés autour du projet. Enfin, vous gagnerez de précieux points dans les mécanismes anti-spams mis en place chez vos destinataires, ainsi le nombre de vos messages qui finira dans les boîtes de courriers indésirables se trouvera réduit.

Certes, DKIM et SPF authentifient le domaine, mais quid de la partie gauche, le nom d’utilisateur ? Comment vérifier l’authenticité non pas du serveur qui a envoyé le mail mais de l’utilisateur ? Ici pas vraiment de choix, il vous faudra recourir à un système de chiffrage et/ou de signature de données tel que PGP ou S/MIME pour authentifier le message et assurer ainsi la confidentialité et/ou l’intégrité de la transmission.

Si vous souhaitez vous renseigner un peu plus sur les technologies anti-spam, je vous conseille de faire un tour sur ce site.

http://www.altospam.com/fr/panorama-des-technologies-antispam.php

Comments

comments

Raccourciceurs d’URL et nombre de combinaisons possibles

Posted on par

Aujourd’hui un collègue m’a demandé comment fonctionnaient les raccourciceurs d’url tels que bit.ly ou tinyurl et dont une liste quasi-exhaustive est disponible ICI

Effectivement les URL retournées par bit.ly sont du type http://bit.ly/Ux7eFJ soit seulement 6 caractères alphanumériques. On est dès lors en droit de se demander pendant combien de temps il est possible de stocker une URL dans ces conditions car visuellement parlant 6 caractères ça fait peu.

Le principe de fonctionnement d’un raccourciceur d’URL est simple, une base de donnée bien indexée contient les liens URL courtes -> URL longues, puis une page PHP se charge de récupérer la valeur courte passée par l’URL et génère en retour une redirection HTTP HTML ou Javascript vers la page ciblée.

Pour dimensionner le système et générer les URL les plus courtes possibles il faut donc faire un compromis entre le nombre de caractères et le nombre d’URL maximum que l’on souhaite pouvoir gérer. On cherche donc à trouver le nombre de combinaisons possible à partir d’un jeu de caractères donné et du nombre de caractères choisi — Pour le cas de bit.ly nous avons 6 caractères à choisir dans un jeu de 62 caractères ( 26 minuscules + 26 majuscules + 10 chiffres ). Le concept mathématique correspondant à ce problème de logique combinatoire est l’arrangement avec répétition soit comment trouver le nombre de combinaisons possibles où les caractères peuvent être répétés ( tirages avec remise ) et où l’ordre des tirages est significatif ( Ux7eFJ != xUe7JF ). La formule qui permet de résoudre ce problème est extrêmement simple, il s’agit simplement de calculer n^k avec n le nombre de caractères et k le nombre d’éléments du jeu de caractère.

Dans le cas de bit.ly nous obtenons 62^6 = 56 800 235 584 possibilités. On comprend ainsi qu’un faible nombre de caractères suffit à générer un nombre suffisant d’url. Ajoutons à cela les possibilité d’augmenter encore la taille du jeu de caractère en ajoutant les caractères spéciaux — attention ici aux risque d’incompatibilité — en gérant le dédoublonnage — on ne génère pas une nouvelle URL courte si l’URL longue existe déjà en base — en limitant la validité des URL dans le temps ou encore la suppression des plus vielles / moins utilisées des URL lorsque la limite est atteinte.

Exemples pour le jeu alphanumérique ( 62 caractères ) :

62 ^ 2 = 3844 possibilités
62 ^ 3 = 238 328 possibilités
62 ^ 4 = 14 776 336 possibilités
62 ^ 5 = 916 132 832 possibilités
62 ^ 6 = 56 800 235 584 possibilités
62 ^ 7 = 3 521 614 606 208 (3.52 x 10^12) possibilités
62 ^ 8 = 218 340 105 584 896 (2.18 x 10^14) possibilités

Comments

comments

Autoriser uniquement le transfert de port SSH pour un utilisateur

Posted on par

Bonjour,

Aujourd’hui une petite astuce permettant d’autoriser uniquement le transfert de ports en ssh pour un de vos utilisateurs système. Pratique pour juste autoriser quelqu’un a établir un proxy SOCKS, ou rediriger des ports par ssh par le biais de votre serveur.

 

Il suffit pour cela de modifier le shell qu’utilise votre utilisateur. Par défaut le shell utilisé est bash, mais rien ne vous empêche de coder un petit programme en C par exemple qui affiche quelque chose en boucle, ou afficher la matrice par exemple.

 

Pour se faire, installez le paquet cmatrix et il ne vous reste plus qu’a modifier le fichier /etc/passwd.

Transformer la ligne de l’utilisateur voulu de ça :

utilisateur:x:1003:1003::/tmp:/bin/bash

en ça :

utilisateur:x:1003:1003::/tmp:/usr/bin/cmatrix

 

 

Et voilà le résultat :

 

 

 

Comments

comments

Transformer la sortie d’une commande en image

Posted on par

Voici une astuce bien pratique permettant de créer une image a partir de la sortie d’une commande console.

Très pratique pour inclure dans vos articles ou présentations !

 

Image Magick

Tout d’abord vous aurez besoin d’Image Magick qui est présent dans la plupart des dépôts des grandes distributions (apt-get install imagemagick pour Debian/Ubuntu). C’est l’outil de référence pour la manipulation d’image en console (redimensionnement en masse, etc…)

 

Utilisation 

COMMANDE | convert -background black -fill white label:@- IMAGE.png

 

Petite explication 

- Après avoir tappé votre commande, vous utilisez le pipe ( | ) afin de rediriger le flux de sortie de la commande dans une deuxième commande.

- La commande convert recoit la sortie de la commande et la transforme en image.

- Les paramètres « -background black » et   »-fill white » permettent d’avoir un texte blanc sur fond noir (c’est l’inverse par défaut)

 

Exemple 

ifconfig | grep bytes | convert -background black -fill white -border 10 -bordercolor black label:@- resultat.png

J’ai ajouté les arguments   -border 10 et -bordercolor black pour faire une bordure noire de 10px autour du rendu.

 

Pour plus d’options, je vous laisse consulter l’aide :

« convert –help » ou « man convert »  ;)

Comments

comments

Vulnérabilité DoS de type « fire and run away » dans Apache

Posted on par

Ce matin mise à jour Apache, tiens donc, comme à l’accoutumée je cherche à savoir ce que corrige/apporte cette mise à jour, ce que je vous encourage à faire vous aussi.

 

http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser

 

Whaoo, une vulnérabilité à une attaque Dos de type « fire and run away » c’est à dire réalisable avec une seule machine et pas la moindre bande passante. Autant dire que c’est du pain béni pour les hackers du monde entier puisque qu’Apache délivre pas loin – si ce n’est plus -  de 50% du trafic HTTP mondial. Plus impressionnant encore toutes les versions d’Apache depuis la 1.3 sont vulnérables et ce dès leur installation par défaut.

 

La faute à qui ? Une mauvaise implémentation du protocole HTTP/1.1 au niveau des headers ‘Range’ et ‘Range-Request’. Le problème avait pourtant déjà été reporté en 2007 par Michal Zalewski à cette adresse : http://seclists.org/bugtraq/2007/Jan/83

 

Le header Range est détaillé dans la RFC2616 qui définit le protocole HTTP/1.1 :

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35

 

Le header Range permet de spécifier dans une requête HTTP que l’on souhaite seulement récupérer une partie de la réponse (la page).  On peut par exemple chercher à récupérer les n premiers octets. Le problème est que rien – d’après la RFC – n’empêche de récupérer plusieurs fois la même partie de la page, ce qui permet de générer une réponse énorme à partir d’une page de seulement quelques kilooctets. L’implémentation de cette fonctionnalité dans Apache et visiblement dans IIS — du moins à l’époque — ne protège pas le serveur contre une telle requête. Il faut dire que la RFC reste assez vague quant au besoin même d’implémenter cette fonctionnalité.

 

Exploitation de la vulnérabilité :

1 – Ouvrir parallèlement autant de connexion TPC qu’il est possible (ou nécessaire).

2 – Négocier une fenêtre TCP de grande taille (>= 1Go).

3 – Envoyer une requête HTTP partielle par connexion TCP contenant un header Range forgé pour récupérer plusieurs fois la totalité de la page — de l’octet zéro à la fin de la page. La limite est la taille maximum d’un champ header  — 8Ko pour Apache — soit plus de 1000 fois alors imaginez un peu le carnage sur un fichier avi ou un iso.

GET /foo.html HTTP/1.1
Host: example.com
Range: bytes=0-,0-,0-,0-,0-,...

4 – Clore les connections TCP pour lancer l’attaque.

5 – Se déconnecter ou rejeter simplement les réponses du serveur de manière silencieuse — il ne se rendra compte qu’on n’écoute plus seulement une fois la taille de la fenêtre TCP épuisée.

 

Que va-t-il se passer ?

Le serveur va recevoir les requêtes et commencer à mouliner et donc à consommer du temps processeur pour générer les réponses. Pour ce faire il va créer de nouveaux processus qui vont petit à petit – quelques minutes suffisent — remplir  complètement la mémoire du serveur et ce jusqu’à la SWAP. Il en résulte une instabilité certaine du système et un mal-fonctionnement voir un arrêt des services hébergés par la machine, you win.

 

Vous l’aurez compris, l’intérêt de l’attaque est de pouvoir déstabiliser un serveur en envoyant une très faible quantité de données en un temps très court, vous n’avez maintenant plus qu’à regarder tranquillement le serveur s’écrouler — d’où le nom « fire and run away », vous placez un explosif à mèche lente dans un bâtiment, vous vous reculez tranquillement de quelques kilomètres et attendez le spectacle.

 

Visiblement oubliée du grand public — des hackers et experts en sécurité — cette faille refait surface suite au post de ce petit script Perl permettant d’exploiter la faille sur Full Disclosure. Apache a bien évidement réagi et proposé un correctif dans les jours qui ont suivis, il n’est donc plus nécessaire que je vous explique comment contrer cette attaque, il suffit de mettre à jour.

 

Encore plus rapidement l’équipe SpiderLabs a créer des règles permettant de mitiger le risque à l’aide du mod_security. Ce module que je ne peux que vous recommander permet de détecter et de lutter contre de nombreux patterns d’attaque web allant de l’énumération en passant par les injections, les attaques de type  XSS ou CSRF et bien d’autres.  L’article suivant explique comment ils ont procédé pour contrer cette attaque :

http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html

Comments

comments

Joindre des VM Esx(i) sous GNU/Linux

Posted on par

Bonjour,
De nos jours la virtualisation est devenue indispensable en entreprise. Vmware est un des leaders de ce marché et leur produit Esx(i) suffit dans la plupart des cas. Dans cet article je vais vous dévoiler une petite astuce permettant de joindre et d’utiliser les machines virtuelles hébergées sur cette infrastructure.

En effet sous Windows avec l’outils VSphere Client aucun souci pour utiliser les VMs. En ce qui concerne Linux c’est une autre histoire. Certains vous conseilleront de faire une VM Windows avec le client VSphere installé dessus sur votre ESX(i) et ensuite d’utiliser le RDP pour se connecter à cette machine. Je ne trouve pas cette solution convenable surtout pour les petits serveurs qui n’ont pas besoin de cette charge supplémentaire.

Ma solution consiste à passer par VMware Player qui est un outil gratuit et simple à installer sur les distributions GNU/Linux. Une fois installé, il vous suffit de le lancer avec quelques paramètres supplémentaires :

vmplayer -h <ip ESX(i)>

Vous pouvez aussi rajouter le login et password dans la commande

vmplayer -h <ip ESX(i)> -u <votre utilisateur> -p <votre password>

Et si vous n’avez pas de mot de passe (pas bien)

vmplayer -h <ip ESX(i)> -u <votre utilisateur> -p

Le plus pratique par la suite est de se faire un petit launcher sur le Bureau/Menu d’applications pour que ce soit plus ergonomique.

Voilà. Vous pouvez maintenant utiliser vos VMs depuis votre distribution préférée.

Comments

comments

Proxy : méthodes de déploiement

Posted on par

 

Bonjour,

En entreprise, utiliser un proxy web devient quasiment obligatoire. Je ne reviendrais pas ici sur l’installation de ce proxy (ici : Squid) mais uniquement sur la méthode de déploiement sur les machines clientes.
A ce jour j’ai recensé 3 differentes méthodes pour diffuser un proxy. Chacune de ces méthodes a des points forts, des points faibles et des coûts différents.

 

Méthode 1 : Gateway
Cette méthode consiste à rediriger tout le trafic de la machine cliente sur le serveur hébergeant Squid. Il faudra dans ce cas autoriser le trafic à ressortir et rediriger le port 80 sur le port d’écoute de Squid. Dans ce cas on peut imaginer que le serveur est aussi un pare-feu. Cette méthode peut être utilisée dans les petites entreprises avec peu de trafic car elle nécessite un serveur passerelle qui peut coûter cher selon la charge qu’il doit subir.
Plus d’information

 

Méthode 2 : GPO/http_proxy
Pour cette méthode on utilisera les très connues GPO pour les postes clients windows et pour les clients GNU/Linux nous utiliserons les variables d’environnements $http_proxy,$https_proxy et aussi $no_proxy. Cette méthode implique que les windows soient inclus dans un domaine et d’avoir un accès sur les machines linux pour affecter les variables.
Plus d’information sur la variable http_proxy

 

Méthode 3 : wpad.dat et proxy.pac
Cette méthode correspond au mode « Détection automatique des paramètres du réseau » de Firefox. En gros le navigateur va chercher sur le réseau un fichier (wpad.dat) qui contient les paramètres d’utilisation du proxy. Cette méthode ne possède pas spécialement de point faible à part sa mise en place plus complexe. Par contre le fichier wpad.dat peut être paramétré de façon très pointue, permettant un filtrage accru.
Plus d’information sur le déploiement wpad

 

Ces méthodes peuvent être contournées par l’utilisateur (surtout si il est root sur sa machine) c’est pourquoi il ne faut pas oublier de couper le port 80 et 443 en provenance de votre réseau sur votre passerelle de sortie.

 

 

Comments

comments

Host-Proof Hosting et confidentialité des données sur internet

Posted on par

 

 

Il y a 10 ans, mes données étaient toujours toutes avec moi, sur un disque dur, une clef usb, un ZIP… Aujourd’hui, mes emails sont stockés chez Google avec Gmail et Microsoft avec Live, les documents sont sur Google Docs, le code source sur GitHub ou GoogleCode, mes flux RSS sur GoogleReader, mes données personnelles réparties entre Facebook, Twitter, Deezer, Soundcloud,… et tout ceci continue de plus belle avec l’arrivée de produits comme Dropbox, GoogleMusic,… Maintenant je ne suis même plus capable de vous dire dans quel pays mes données sont réellement archivées, traitées, transmises.

 

Une des problématiques majeures du cloud computing — hors l’accès obligatoire à internet — est la multiplication des logins nécessaires pour accéder à l’ensemble des données que vous avez disséminées un peu partout sur la toile, c’est pourquoi je voulais essayer Passpack.com depuis longtemps. Passpack est un applicatif (site) web dédié à la centralisation et à la gestion de mots de passe qui en proposant des fonctionnalités intéressantes comme le One-Click-Login, la génération de mots de passe aléatoires, le renouvellement ou encore le partage de mot de passe entres utilisateurs, Passpack.com est devenu une des références en la matière.

 

Je ne souhaite pas ici m’étendre sur l’éternel débat du bien fondé ou non de cette solution – à vous de faire votre choix — mais je vais vous présenter le concept cryptographique qu’ils utilisent pour stocker les mots de passe afin que vous puissiez appréhender leur approche : le Host-proof hosting.

 

Comme dit précédemment,  la quantité de données envoyées par un utilisateur en direction de systèmes d’information tiers a été décuplée, mais surtout les utilisateurs sont prêt à faire confiance et à envoyer des données sensibles (numéro de carte de crédit,… ). Vous souvenez-vous il y à encore quelques années, quand la plupart de vos proches trouvaient dangereux de faire un achat sur internet ?

 

On vous rabâche que le « petit cadenas » (HTTPS) signifie que l’échange est sécurisé. Certes la confidentialité et l’intégrité des données durant l’échange client-serveur sont assurées par les technologies SSL/TLS qui permettent de se protéger notamment du sniffing. Mais est ce bien suffisant ? Ce « petit cadenas » doit-il nous donner une totale confiance dans le site ? La réponse est bien évidement non, une fois l’échange terminé les données sont stockées et accessibles en clair aux personnes — qu’elles soient malveillantes ou non — ayant accès à l’infrastructure hébergeant le site.

 

Richard Schwartz, qui a co-développé le concept d’Host-proof hosting nous résume le problème de la confiance en ces quelques mots : « Trust in web applications only extends as far as trust in whoever is hosting it », en français : « La confiance d’un utilisateur pour un applicatif web ne peut excéder la confiance qu’il a pour les gens qui l’hébergent ».

 

L‘Host-proof hosting permet de résoudre ce problème en chiffrant les données sensibles avec une clef connue uniquement par l’utilisateur. Tout le chiffrement est exécuté coté client avant l’envoi des données, les hébergeurs sont donc en possession de données chiffrées qu’ils sont incapables de déchiffrer sans que l’utilisateur ne leur fournisse la clef. De même les données retournées par le serveur sont déchiffrées coté client.

Host-Proof Hosting

 

La sécurité du procédé repose sur les algorithmes, la qualité et la longueur de clef choisie — ce qui reste un compromis entre sécurité, performance et praticité — mais sachez qu’avec de bons paramètres il faudra encore plusieurs milliers d’années pour venir à bout des algorithmes de cryptographie symétriques les plus courants AES, BLOWFISH, RC4 et rendre intelligible les données.

 

Passpack à mis à disposition des développeurs une API Javascript simple et efficace dédiée à la mise en place de ce modèle de sécurité, ça se passe ici.

 

Dans la réalité la sécurité du concept repose sur la qualité de sa mise en œuvre, il faut à tout prix empêcher à quiconque de pouvoir accéder à la clef personnelle d’un utilisateur. En général on a tendance à protéger le serveur des données arbitraires qu’il peut recevoir (injections SQL/PHP/XSS/… ), cependant dans le cas des applicatifs de type Host-proof nous allons aussi chercher à protéger le client puisque c’est lui qui reçoit la sacro-sainte clef. Deux catégories de vulnérabilités s’offrent à nous, celles où l’on attaque directement le client dans ce cas l’attaquant doit récupérer la clef personnelle ainsi que le couple login/mot de passe de sa victime et celles où l’on attaque le serveur. Dans ce cas l’attaquant doit avoir un accès au média où les données sensibles sont stockées ainsi que la clef de l’utilisateur à qui appartient les données.

 

Dans le premier cas c’est à la sécurité de l’environnement de scripting du navigateur — et sur ce point il est juste de s’interroger car ces environnements ne sont pas vraiment réputés pour être sans faille — que l’on va s’attaquer. On veillera ainsi à ce que l’applicatif client soit capable de vérifier lui même son intégrité grâce à une somme de contrôle — stockée sur un ou plusieurs serveurs tiers. Le but est ensuite de limiter les risques au maximum, il serait par exemple de bonne augure de veiller à ne pas stocker la clef en mémoire. Il faut être conscient que le risque-zéro n’existe pas, les Keylogger/Rootkits/Spyware/Phishings/… sont légions et que vous ne pouvez pas directement lutter contre. Il est donc nécessaire d’avertir au maximum l’utilisateur sur ces menaces afin qu’il ne place pas son entière confiance uniquement sur ce concept.

 

Dans le second cas, l’attaquant a déjà réussi à prendre le contrôle du serveur web — tout du moins assez pour pouvoir modifier le contenu qu’il renvoie — et il a aussi accès aux données sensibles — vous pouvez prendre le cas d’un admin malveillant — tout ce qu’il manque à l’attaquant c’est la clef correspondant aux données qu’il souhaite rendre intelligibles. Il doit donc modifier le comportement du site pour que ce dernier lui renvoie la clef lorsque l’utilisateur la saisit soit en modifiant le code HTML — ajout d’un formulaire par exemple — soit en modifiant le code de l’applicatif client. La protection la plus efficace reste la mise en place d’un simple contrôle d’intégrité et de comportement de la page réalisé avec par une machine tierce en continu pour remonter une alerte en temps réel et stopper le service ce qui limite drastiquement les risques de transmission de données. On peut aussi imaginer un mécanisme demandant à l’utilisateur de vérifier lui-même l’intégrité du contenu. On essayera aussi de rendre aussi inintelligible que possible le lien entre les données et l’utilisateur à qui elles appartiennent. L’utilisation de mécanismes distribués permet de mitiger ce type de risque en demandant à l’attaquant de prendre le contrôle de plusieurs systèmes, ce qui se révèle rapidement impossible, qui plus est dans le cadre d’une solution ou la sécurité des données est au cœur des préoccupations.

 

Comment savoir si un site à mis en place une solution de type Host-proof hosting pour protéger mes données ? Ici pas de petit cadenas, à vous de vous faire votre idée et de faire confiance ou non à ce site. Premièrement, le site doit vous demander régulièrement une clef secrète puisqu’il ne la stocke pas, ensuite il va falloir aller voir directement au niveau des données échangées avec le serveur et vérifier que les données sensibles ne passent pas en clair — l’extension Firebug pour Firefox fera merveilleusement bien l’affaire.

 

Le concept est donc viable mais requiert que son implémentation ne laisse « aucune » chance à l’attaquant de récupérer la clef ce qui relève du domaine du possible — le nombre de principe permettant de mitiger suffisamment le risque étant assez élevé — mais demande un travail et une surveillance accrus de la sécurité car la moindre faille peut compromettre tout l’ensemble.

 

Comments

comments

Proxy HTTP Apache2 avec mod_proxy

Posted on par

Que ce soit pour obtenir une adresse IP différente ou pour passer au travers des règles de filtrages de certains sites/firewalls,
vous pouvez avoir l’envie de faire transiter votre flux web par votre serveur Apache personnel.

Pour ceci nous allons créer un hôte virtuel dédié à cette usage, l’ouverture d’un proxy sans authentification étant extrêmement dangereuse car n’importe qui peut utiliser votre IP, nous allons donc recourir à une authentification de type HTTP/Basic pour en sécuriser l’accès.

Attention ici il n’est absolument pas question de chiffrer le flux HTTP, c’est une simple redirection de ce dernier vers un nouveau point de sortie, qui plus est les requêtes DNS sont toujours traitées par votre serveur DNS habituel, gardez donc à l’esprit que cette technique ne vous rends pas invisible, notamment vis à vis de votre réseau local.

J’ai choisi ici le port 443 pour héberger le service, tout d’abord parce que c’est un port qui est généralement toujours ouvert quelque soit l’endroit d’où l’on se connecte et ensuite car je n’ai pas de site HTTPS hébergé sur cette machine. A vous de faire votre choix pour ce paramètre.

Il vous faut dans un premier temps créer un fichier contenant les couples login/mot de passe avec la commande htpasswd :

htpasswd -c /etc/apache2/htpasswd username

On vas ensuite créer le fichier de configuration de notre vhost dans le dossier /etc/apache2/sites-available/proxy :

<VirtualHost *:443>

ServerName proxy.mydom.fr
DocumentRoot /var/www/proxyjail

ProxyRequests On
ProxyVia On

php_value engine off

<Proxy *>
AuthType Basic
AuthName « Restricted Area »
AuthUserFile /etc/apache2/htpasswd
require valid-user

Order deny,allow
Allow from all
</Proxy>

<Directory /var/www/proxyjail>
AllowOverride None
Options -All
</Directory>

</VirtualHost>

Certes notre virtual host ne vas normalement pas être utilisé pour délivrer du contenu HTML local — encore moins PHP ou un autre langage de scripting d’ou la presence de la ligne « php_value engine off  » — il est cependant obligatoire qu’il dispose d’un DocumentRoot. Utiliser /var/www comme DocumentRoot dans notre cas permettrait certainement à un utilisateur malveillant d’accéder à beaucoup de choses qu’il ne devrait pas.
Nous allons donc créer le dossier /var/www/proxyjail et s’en servir pour enfermer les utilisateurs du proxy à l’intérieur. ( Attention ici il n’est pas question de chroot ).

mkdir /var/www/proxyjail
chmod 744 /var/www/proxyjail
touch /var/www/index.html

Pour finir il suffit d’activer le vhost et de relancer apache

a2ensite proxy
apache2ctl configtest && /etc/init.d/apache2 restart

Il ne vous reste plus qu’à configurer votre navigateur pour qu’il utilise votre proxy et le tour est joué :
Configuration du proxy sous Firefox

 

 

Comments

comments

Se connecter à un VPN PPTP

Posted on par

Point-to-Point Tunneling Protocol (PPTP) est un protocole d’encapsulation PPP sur IP conçu par Microsoft, permettant la mise en place de réseaux privés virtuels (VPN) au-dessus d’un réseau public.
Ce protocole est supporté par quasiment toute les plateformes : Microsoft Windows depuis 95OSR2, Mac OS X, GNU/Linux, BSD, Cisco CiOS, Iphone iOS, Androïd, Palm,… et est extrêmement simple à mettre en place. Cependant PPTP est loin d’être sécurisé, en effet de nombreuses failles de sécurités ont été trouvées dans l’implémentation de MPPE, le protocole d’authentification PPP. C’est pourquoi il est fortement déconseillé d’utiliser PPTP avec IPv6 et/ou dans les cas où la confidentialité et l’intégrité des données sont jugées indispensables.

Nous allons voir ici comment se connecter à un serveur PPTP sous GNU/Linux.

Installation du client :

apt-get install pptp-linux

Prérequis :

  • adresse (IP ou DNS) du serveur PPTP ($SERVER)
  • le nom que vous souhaitez donner au tunnel ($TUNNEL),
  • login ($USERNAME) ( peut être de la forme DOMAIN\USERNAME )
  • mot de passe ($PASSWORD)

Configuration :

Vérifier la présence des options suivantes dans le fichier /etc/ppp/options.pptp

lock noauth nobsdcomp nodeflate

Ajouter une ligne au fichier /etc/ppp/chap-secrets qui gère l’authentification ( attention le mot de passe est stocké en clair )

$USERNAME PPTP $PASSWORD *

Pensez à échapper les caractères spéciaux dans le cas DOMAIN\\USERNAME

Créer le fichier /etc/ppp/peers/$TUNNEL :

pty « pptp $SERVER –nolaunchpppd »
name $DOMAIN\\$USERNAME
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam $TUNNEL
persist

L’option « persist » active la reconnexion auto en cas de perte de connexion.

Tester le tunnel :

pon $TUNNEL debug dump logfd 2 nodetach

Démarrer le tunnel :

pon $TUNNEL

Arrêter le tunnel :

poff $TUNNEL

Pour démarrer automatiquement le tunnel vous pouvez ajouter ceci au fichier /etc/network/interfaces :

auto tunnel
iface tunnel inet ppp
provider $TUNNEL

Tester le démarage auto :

/etc/init.d/networking restart

Pour plus d’informations ou en cas de problèmes : http://pptpclient.sourceforge.net/howto-debian.phtml

Voilà, la liaison VPN PPTP est maintenant établie, vous pouvez la voir apparaitre dans le résultat de la commande ifconfig sous le nom pppX.

root@Boris:~# ifconfig ppp0

ppp0      Link encap:Point-to-Point Protocol
inet addr:10.20.80.19  P-t-P:10.20.80.10  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:80 (80.0 B)  TX bytes:80 (80.0 B)

Par défaut, vous avez accès au réseau local distant mais la réciproque n’est pas vraie, pas plus que votre réseau local ne peut accéder au réseau local distant. Pour ceci il ne reste plus qu’à configurer le routage (via la table de routage et iptables ) pour rediriger les flux que vous souhaitez dans votre tunnel.

Comments

comments