Vagrant et les redirections de ports (Port Forwarding)

Posted on par

S’il y a bien un outil qui fait parler de lui en ce moment, c’est bien Vagrant. Si vous ne savez pas ce que c’est je vous conseille de vous renseigner sur le site officiel http://vagrantup.com/  ou bien chez mon ami http://google.com/

Si vous êtes comme moi vous avez au minimum 5 boxs Vagrant qui tournent en même temps avec une demie douzaine de redirections de port sur chacune. Par conséquent, je ne sais jamais quel port est redirigé vers quoi.

J’en viens au but de cet article : un petit plugin Vagrant que j’ai développé qui ajoute l’argument redirection à la commande vagrant, renvoyant les informations de redirections (port forwarding) des différentes Boxs.

Exemple :

$vagrant status
Current VM states:
clean running
prod not created
dev running
devweb running

$vagrant redirection
[clean] - Redirect :
2210 => 42000
2207 => 80
2208 => 81
2211 => 5432
2209 => 8888
2206 => 22
[prod] - machine not created1
[dev] - Redirect :
2216 => 42000
2213 => 80
2214 => 81
2217 => 5432
2215 => 8888
2212 => 22
[devweb] - Redirect :
2223 => 42000
2219 => 80
2220 => 81
2224 => 5432
2221 => 8888
2218 => 22

Pour l’installer, il suffit d’aller sur la page du projet github : https://github.com/bewiwi/vagrant-getredirection

Puis, télécharger le gem et l’installer avec la commande suivante :
vagrant gem install vagrant-getredirection-0.0.1.gem

 

Comments

comments

Routage et QoS sous Linux, utiliser DSCP

Posted on par

Il est toujours intéressant de pouvoir choisir une interface de sortie lorsque qu’on dispose de plusieurs accès internet. Nous allons voir dans un premier temps comment mettre en place l’infrastructure avec un serveur (routeur) GNU/Linux et ensuite s’intéresser de plus près à la QoS et plus particulièrement à DSCP.

Tout d’abord l’environnement dont nous disposons est donc conipstitué d’un serveur sous Debian 6, d’un accès Internet fibre optique, un accès ADSL, plusieurs accès VPN.

La configuration du serveur en mode routeur tout d’abord, comme vous le savez surement le noyau Linux est capable de réaliser une myriade d’opérations de routage et de manipulation de paquets.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -j MASQUERADE

Nous allons cependant devoir faire quelques réglages. Il faut déjà bien comprendre que pour réaliser cette opération nous allons avoir besoin de plusieurs tables de routage, car qui dit interface de sortie sur Internet dit route par défaut. Une table de routage indique l’adresse du prochain routeur à joindre pour acheminer le paquet vers sa destination. La route par défaut d’une table de routage s’applique pour tout les paquets dont la destination finale est inconnue du routeur. C’est typiquement le cas du trafic à destination d’Internet. Nous ne pouvons avoir qu’une seule route par défaut par table de routage, il nous faut donc une table de routage par interface. On va déclarer ces dernières dans le fichier /etc/iproute2/rt_tables.

255 local
254 main
253 default
103 VPNJP
102 VPNUS
101 VPNFR
100 ADSL
0 unspec

Comme on peut le voir Linux utilise déjà 3 tables de routage, main est la table principale, les autres ne sont pas à modifier. Pour voir le contenu d’une table de routage on utilise la commande ip.

ip route show table main
10.100.100.0/30 dev tap0 ... link src 10.100.100.2
10.101.101.0/30 dev tap1 ... link src 10.101.101.2
10.102.102.0/30 dev tap2 ... link src 10.102.102.2
192.168.42.0/24 dev eth0 ... link src 192.168.42.1
192.168.26.0/24 dev eth1 ... link src 192.168.26.1
default via 192.168.42.254 dev eth0

Par défaut si on omet le terme table c’est la table main qui sera manipulée. 192.168.42.254 est l’ip de la box fibre optique, ça sera donc notre interface de sortie par défaut si le trafic ne match aucune règle. Il faut aussi noter que la commande ip route permet l’abréviation aussi la commande précédente peut s’écrire « ip r s t main ». On va maintenant remplir les autres tables de routage. même si il n’y a que la route par défaut qui nous intéresse il est toujours préférable de la remplir complètement pour éviter les mauvaises surprises et permettre au routage du réseau local de fonctionner correctement sur toutes les interfaces.

ip route add table ADSL 10.100.100.0/30 dev tap0
ip route add table ADSL 10.101.101.0/30 dev tap1
ip route add table ADSL 10.102.102.0/30 dev tap2
ip route add table ADSL 192.168.42.0/30 dev eth0
ip route add table ADSL 192.168.26.0/30 dev eth1
default via 192.168.26.254 dev eth1
ip route add table VPNFR 10.100.100.0/30 dev tap0
ip route add table VPNFR 10.101.101.0/30 dev tap1
ip route add table VPNFR 10.102.102.0/30 dev tap2
ip route add table VPNFR 192.168.42.0/30 dev eth0
ip route add table VPNFR 192.168.26.0/30 dev eth1
default via 10.100.100.1 dev tap0

Bien, maintenant il suffit d’ajouter des règles de routage pour choisir la table que l’on veut utiliser. Par exemple on peut rediriger automatiquement tous les paquets provenant de l’ip 192.168.42.42 via la sortie ADSL comme ceci :

ip rule add from 192.168.42.42/32 lookup ADSL

Cependant je veux plus de granularité, j’aimerais pouvoir choisir l’interface de sortie directement sur mon poste client sous Windows 7 / MacOS / Linux. Il est possible d’utiliser le champ IPv4 Type de service (TOS) pour marquer le paquet à travers le réseau ainsi influer sur la décision de routage. Pour remplir ce champ plusieurs possibilité existent, nous allons utiliser DSCP car c’est celle qui est implémentée sous Windows. Sur le serveur nous allons utiliser ces marques pour choisir une table de routage. Malheureusement iproute2 ne gère pas directement DSCP, ce n’est pas grave nous allons utiliser netfilter/iptables qui lui sais reconnaître et manipuler ce champ. Nous allons ainsi marquer le paquet dans le suivi de connexion de netfilter car  iproute2 sait parfaitement matcher des paquet en fonction de ces marques. C’est juste un artifice, rien n’est modifié au niveau du paquet qui conservera sa marque DSCP. Sans vouloir faire un cours sur netfilter/iptables je remet ce schéma sous vos yeux. Nous allons utiliser la table mangle pour modifier les paquets directement en entrée ou en sortie du système.

iptables -t mangle -A PREROUTING -m dscp --dscp 10 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -m dscp --dscp 11 -j MARK --set-mark 11
iptables -t mangle -A PREROUTING -m dscp --dscp 12 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -m dscp --dscp 13 -j MARK --set-mark 13

Ainsi nous pouvons maintenant nous baser sur cette marque pour créer nos règles de routage.

ip rule add fwmark 10 lookup ADSL
ip rule add fwmark 11 lookup VPNFR
ip rule add fwmark 12 lookup VPNUS
ip rule add fwmark 13 lookup VPNJP

Tout est prêt :) . Il ne nous reste plus qu’à utiliser DSCP pour marquer les paquets directement sur les postes clients et qu’il prennent ainsi la route que l’on à choisi.

Sous Linux rien de plus simple on utilise iptables, ainsi il est possible de tagger le champ TOS des paquet avec la précision que l’on connais déjà. Généralement le module owner est d’une grande aide ici puisqu’il permet de matcher les paquet en fonction de l’application, du processus, du user ou du groupe,…

iptables -t mangle -A OUTPUT -p tcp --dport 22 -j DSCP --set-dscp 10
iptables -t mangle -A OUTPUT -p tcp --dport 80 -j DSCP --set-dscp 11

Ainsi le trafic SSH à destination du port 22 passera maintenant par l’ADSL OVH qui est plus stable et le traffic web non chiffré à travers le VPNFR pour plus de confidentialité. A vous d’adapter à vos besoins.

Sous Windows rien de bien plus compliqué surtout si vous disposez d’un domaine ActiveDirectory. Si ce n’est pas le cas rendez vous dans la base de registre avec l’outil regedit.exe et créez la clef suivante.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS

A l’intérieur ajoutez une chaîne de type REG_SZ nommée « Do not use NLA » et comme valeur 1. Ceci permet d’appliquer la QoS sur une connexion réseau qui n’est pas associée à un domaine ActiveDirectory.

Maintenant rendez-vous dans la GPMC via l’outil « Modifier la stratégie de groupe locale » et ajoutez vos règles dans « Paramètres Windows / QoS basée sur la stratégie ». La première fois il vous faudra peut-être exécuter la commande gpupdate et redémarrer pour que les modifications soient prisent en compte.

Voila, vous savez tout et vous et vos utilisateurs êtes maintenant capables de demander poliment  une route à votre routeur Linux. Bien entendu il vous est possible d’outre passer leurs choix en utilisant la table mangle, ainsi si un lien venait à tomber, une petite règle iptables et tout le trafic à destination de l’ADSL passera par la fibre ou inversement. L’autre intérêt est que les marque DSCP sont conservées lors du routage, certes pas lors du passage par le FAI et les réseaux ATM ou autres non compatibles avec IP, mais à travers un lien OpenVPN aucun problème, vous pouvez ainsi vous servir de cette marque pour influer sur la décision de routage directement au niveau du point de sortie du VPN.

Comments

comments

Le Libre en entreprise

Posted on par

Le monde des logiciels libres propose de nombreuses solutions performantes pour les particuliers et les entreprises. Or, certaines entreprises restent réticentes à ces outils pour certaines raisons.

Partant de cette conclusion, j’ai fondé mon mémoire de fin d’études sur l’utilisation du Libre en entreprise. Ce document a été écrit à partir de mon expérience dans une entreprise utilisant principalement des logiciels issus de la communauté du Libre. Il a pour principal but de faire changer les mentalités sur le Libre et pourquoi pas vous distraire un peu.

Je vous invite à m’envoyer vos retours concernant ce document par twitter : @bewiwi , mail : contact[at]bibabox.fr ou un commentaire ci-dessous.

Il ne me reste plus qu’à vous souhaiter une bonne lecture

Download : LeLibreEnEntreprise

Comments

comments

NagvisRackConstructor

Posted on par

Le monitoring est un domaine vaste et on ne peut plus important en entreprise. Si vous avez déjà fait quelques recherches dans ce domaine vous avez surement vu l’excellent outil qu’est Nagios, une de ses nombreuses surcouches du nom de Centreon et un outil de visualisation du nom de NagVis. Si vous débutez dans le domaine de monitoring ou si vous ne voulez pas faire l’installation compliquée je vous conseille la distribution FAN qui regroupe ces trois outils.

Ici nous nous intéresserons juste à Nagvis. Si vous l’avez déjà utilisé et que vous êtes comme moi, vous avez trouvé son interface de construction de carte pas très pratique. C’est pourquoi j’ai développé un petit projet Perl du nom de NagvisRackContrutor qui construit les baies serveurs et ajoute automatiquement les serveurs dans ces mêmes baies. Cela permet d’avoir une map claire qui permet de visualiser rapidement le serveur en erreur et ça permet aussi de se la jouer devant les autres adminsys :D

L’utilisation de ce script est très simpliste. On télécharge le script depuis github :

git clone https://github.com/bewiwi/NagvisRackContructor.git

On l’édite le script rack.pl pour ajouter nos baies et nos serveurs.

Exemple :

my $baies = {
  "Baie n°1" => {
    'size' => 42,
    'materiel' => {
      "srv-vmware" => {'size'=>2,'location'=> 40,'type'=>'server'},
      "srv-test" => {'size'=>1,'location'=> 39,'type'=>'server'},
      "srv-monitoring" => {'size'=>1,'location'=> 8,'type'=>'server'},
      "onduleur" => {'size'=>3,'location'=> 3,'type'=>'battery'},
    },
  },
}

Ici une seule baie de 42 U avec 1 serveur de 2U et 2 serveurs de 1U ainsi qu’un onduleur de 3U (type=>battery)

Une fois le script configuré, il faut donner les images à Nagvis. Pour cela il suffit de les copier dans le dossier correspondant (/usr/share/nagvis/share/userfiles/images/shapes/ sur les distributions FAN).

Le script est fourni avec les images de serveurs 1 et 2U, des switchs 1U et des onduleurs 3U. Si vous avez besoin d’un nouveau type il vous suffit d’ajouter une image correspondant avec le bon nom. Par exemple pour un type switch de 2U l’image devra s’appeler switch_2.png.

Une fois que tout est bon, on lance le script :

perl rack.pl > notremap.cfg

Ensuite on place le fichier ainsi généré dans le dossier de nagvis ( /etc/nagvis/maps pour moi ).

On peut alors apprécier une map avec nos serveurs et leurs statuts le tout bien rangé dans des baies virtuelles.

Download : GitHub

Comments

comments

Quels services/outils mettre sur un PXE ?

Posted on par

Bonjour,

A l’heure de la dématérialisation, vous souhaitez mettre en place un PXE ( boot par le réseau ) pour déployer vos distributions favorites ?  Je vous encourage grandement à le faire si vous en avez l’utilité. Je ne vous expliquerai pas ici comment le faire, internet est rempli de très bons tutoriels. Mais saviez-vous qu’avec un serveur PXE vous n’êtes pas obligé de distribuer uniquement des installations de systèmes, mais aussi partager des outils bien pratiques en cas de problème.

Voici une liste non exhaustive de petits outils à intégrer à vos PXE

  • Memtest  : Outil qui n’a plus besoin d’être présenté.
  • Clonezilla : Vous avez besoin de faire une copie exacte de votre machine ? Clonezilla peut faire des copies disque à disque ou disque vers image simplement et efficacement.
  • SuperGrub2 : Qui n’a jamais cassé son grub ? SuperGrub2 permet de détecter et de démarrer sur les systèmes d’exploitation présents sur la machine
  • Gparted : Besoin de modifier rapidement le  partitionnement des disques, gparted est là.
  • Dell Diagnostic : Quand vous avez un parc constitué de machines Dell, je vous assure que c’est indispensable.
  • Ubuntu 11.04 live x86 : Sinon pour tout le reste le bon vieux ‘live system’ est toujours très pratique.

Si vous préférez, il existe des pack tout faits comme PXE knife et Trinity Rescue Kit. Pour ma part je préfère ajouter mes propres outils manuellement.

J’espère que vous aurez compris que votre PXE peut vous être très utile et qu’il peut remplacer votre mallette de CD simplement.

 

Comments

comments

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