Articles et actualités

====================================================
              Newsletter RANDCO  Janvier 2008
====================================================

RANDCO est un cabinet de conseil et d'expertise dans le domaine des infrastructures IT : réseaux, systèmes et sécurité.

--[ Sommaire ]-------------------------

      1. Actualités Société
      2. Nouvel article "Monter un environnement PXE en 5 minutes"
      3. Actualités Supervision
      4. Vu sur le Net : Google fabrique son propre switch 10Gb
      5. L'outil du mois : hping
      6. Nos lectures du moment
      7. Contact

--[ 1. Actualités Société ]----

Tout d'abord, l'équipe RANDCO vous souhaite ses meilleurs voeux pour 2008, tant au niveau personnel que professionnel. De manière accessoire, nous espérons que 2008 sera l'année d'un plus fort partenariat, entre nous.

C'est une année qui commence en fanfare pour RANDCO puisque nous sommes devenus partenaires de Nagios.com, la société qui édite le célèbre outil de supervision Open Source Nagios.

Ceci nous permet d'affirmer nos savoir-faires, et de bénéficier d'information et de support technique privilégiés.

Cette annonce peut sembler contradictoire avec notre volonté farouche de rester indépendants des constructeurs, éditeurs et opérateurs. Pourtant, l'intégration de briques Open Source lorsqu'elle représente une alternative crédible et pérenne aux solutions commerciales est en droite ligne de notre philosophie : vendre avant tout de la prestation intellectuelle.

L' Open Source par ses qualités natives, à savoir possibilité de modification (par l'accès au code source) et réversibilité native (aucun frais de licence, documentation et code accessible à tous), nous permet de mieux répondre aux besoins de nos clients et de rester compétitifs en terme de savoir-faire et de prix. Bref, le contraire même d'une rente de situation...

Et cela nous va bien, car à RANDCO, notre souhait est de concevoir, déployer et administrer des solutions réellement sur mesure pour nos clients !

--[ 2. Nouvel Article « Monter un environnement PXE en 5 minutes » ]----

Nous sommes souvent amenés à intégrer des serveurs sous Linux et il manque toujours soit le DVD de notre distribution préférée (Ubuntu-Server) soit le serveur est livré sans lecteur de DVD, ou bien nous n'avons pas de CD vierge ou de graveur en état de fonctionner....

Bref, dans ces situations 2 solutions s'offrent à nous : utiliser une clé USB bootable (encore faut-il en avoir une !) ou bien monter un environnement PXE d'intégration.

[Lire la suite de l'article].

--[ 3. Actualités Supervision ]----

De multiples nouvelles pour Cacti :

• la version 0.8.7a de Cacti avec la fonctionnalité particulièrement attendue: Temps de polling multiples de 5 minutes à 10 secondes (attention ceci est à manier avec précaution pour ne pas « casser » les graphes courants!), mais également l'export CSV des données graphées, etc.. Le poller à hautes performances (écrit en C) Cactid s'appelle maintenant Spine.

• CactiEZ (image ISO ou VMWare) est mis à jour en version 0.3 et intègre le nouveau Cacti 0.8.7 sur une distribution CentOS 4.5. Cependant nous vous déconseillons cette version car après l'installation du CD en VMWare de nombreux bugs subssistent (dans Nagios certains fichiers sont à corriger et dans Cacti, les graphes des interfaces minute par minute ne fonctionnent pas).

Pour Nagios,

• un nouvelle version stable 2.10 (correction de bugs)

• et une dernière beta en 3.0RC1 (Release Candidate).

• La version 1.4.10 puis 1.4.11 des plugins. De nombreuses options ont été ajoutées aux commandes de check, notamment la possibilité de préciser l'adresse MAC du demandeur lors du check_dhcp. Ceci est important car, par exemple les packages Ubuntu Server actuel ne sont qu'en version 1.4.8 !

--[ 4. Vu sur le Net : Google fabrique son propre switch 10Gb ]----

Google aurait (a ?) construit ses propres switches Ethernet 10Gigabits/s ! La question qui vient tout de suite à l'esprit est "Quelle idée ! pourquoi ne pas acheter un switch du marché ?".

Google veut sans doute continuer à appliquer la philosophie qui lui a si bien réussi : construire en masse des systèmes simples et peu coûteux.

Pour cela ils peuvent s'appuyer sur les nombreux talents du monde des réseaux qu'ils ont débauché à grand coup de stock-options (à commencer par les légendes vivantes telles que l'emblématique Vinton Cerf ). La philosophie de Google consiste à construire des infrastructures bon marché, non redondantes, et à en stocker à plusieurs endroits géographiques la même donnée, à la manière d'un meta-système de fichiers en RAID. Cette non-robustesse revendiquée, provoque d'ailleurs de temps en temps des pertes de données, comme sur Gmail, en Beta depuis plusieurs années.

L'étude des débuts de Google montre par exemple que ses ingénieurs avaient anticipé les serveurs lames en rackant ,de façon très dense, horizontalement des cartes mères « standard »de PC (ce qui finit d'ailleurs par provoquer des incendies).

Google construit ses propres serveurs et ses propres logiciels. Pourquoi ne pas faire de même avec les équipements réseaux ?

Les switches 10G (standard IEEE 802.3ae sur fibre et 802.3an sur cuivre) sont aujourd'hui fabriqués par des constructeurs peu renommés internationalement tels que Force10 ou Arastra. Le principal frein à l'adoption de cette technologie est le coût et la profusion des types de modules optiques .

Ceux-ci sont le XENPACK, le X2, le XFP et le nouveau, moins cher et plus petit, SFP+. Le leader du marché, Cisco, a pour stratégie actuelle de vendre des modules X2 à prix d'or (2.250 € prix unitaire HT fin 2007, à comparer au 100$ d'un SFP+ équipée d'une diode portant à 100m) et ainsi asphyxie, en retardant sa croissance (et l'arrivée de nouveaux entrants) le marché du 10G.

La vente de SFP est d'ailleurs un marché très juteux , à tel point que certains clients ont la tentation d'acheter des modules "comptables" en n'hésitant pas à demander les bonnes adresses sur le forum Cisco NetPro.

Le 10G n'est pas prêt d'être disponible sur des câbles « standard » Cat5E, principalement pour des raisons de consommation électrique excessive, de l'ordre de 10W par port. Les alternatives à la fibre sont peu satisfaisantes : le Cat7 ou bien le CX4 (même connecteurs et câbles que le X4 Infiniband).

Il ne restait donc à Google qu'à créer son « propre » 10Gb sur Cat5 : pour cela les ingénieurs auraient adapté des cartes mère Broadcom (le fabricant tout puissant sur le marché des chips Gigabit) en y connectant 20 modules SFP+, obtenant ainsi un switch à très bas coût et à forte densité.

Des sociétés telles que Level7 (acquise par Broadcom  en janvier 2007) fournissent des solutions logicielles pour commutateurs et routeurs : il ne restait sans doute plus aux ingénieurs de Google qu'à utiliser les API et routines de haut niveau.

La plupart des fonctionnalités qui peuvent intéresser les entreprises (principalement de sécurité telles que BPDU-Guard, Private VLAN ou Dynamic ARP Inspection, ou bien de QoS pour la téléphonie sur IP) ne sont pas présentes, mais Google n'en a pas besoin !

D'ailleurs celles-ci sont en général implémentées au niveau des ASICs (c'est le cas pour Cisco) non pour des raisons de performance mais principalement pour éviter la contrefaçon (posséder les sources de l'IOS ou du CatOs ne suffisent alors plus à construire des switches Cisco-like.

Le gain financier est énorme vu la taille du réseau Google : il ne faut pas oublier que l'économie n'a pas lieu que sur les modules optiques connectés au switches mais également sur ceux insérés dans chaque serveur ! On peut même y ajouter les gains en consommation d'énergie puisque les puissances d'émission seront sans doute optimisées suivant les besoins « standard » des baies Google. Bref, de quoi maintenir son avance technologique et financière sur Yahoo! ou MSN.

Enfin, pourquoi de tels besoins ?

Tout d'abord Google possède sans doute un des plus grand réseau mondial (environ un demi million de serveurs) et on peut imaginer que ses flux de données sont conséquents. Non, contrairement à des idées faussement répandues, ce n'est pas la vidéo qui tire le marché du 10Gb : le multicast et la compression permettent de diffuser la TV en très bonne qualité, en utilisant moins de 10Mbits/s de bande passante.
Nous penchons donc pour 2 raisons (d'ailleurs complémentaires) :

• le nouveau service de stockage de Google

• et la puissance des serveurs : comment irriguer une baie remplie de serveurs 1U capable chacun de générer des flux de données supérieur au Gigabits/s ? En utilisant des switches de type "top of rack"10Gbits !!
  

--[ 4. L'outil du mois « hping » ]----

Hping est un outil Open Source de manipulation de paquet, utilisable directement depuis la commande en ligne. Bien que conçu pour les systèmes Unix/Linux, il a été porté (avec quelques bugs et limitations) sur les plateformes Win32.

Certains de nos lecteurs objecteront que Hping est un vieil outil, diffusé depuis 2000, pourquoi donc en parler maintenant ?

Parce qu'il est la réponse à de nombreuses questions qui reviennent de façon récurrentes lors de nos formations :

• Comment forger un paquet par Spoofing
  
  En utilisant l'option « « --spoof » qui permet de spécifier l'adresse source du paquet. On lance ainsi une Land Attack en une seule ligne :
  
  hping –spoof 192.168.1.1 192.168.1.1 -p 80 -S
  
  En capturant avec tcpdump on obtient bien :
  
  16:35:17.526289 IP (tos 0x0, ttl 64, id 14808, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.1.1.2278 > 192.168.1.1.80: S, cksum 0x30b3 (correct), 1718778307:1718778307(0) win 512

• Comment vérifier si un firewall est stateful ?
  
  Envoyons un paquet correspondant à une règle d'autorisation (par exemple accès à un serveur Web), mais sans respecter la séquence de connexion TCP en 3 phases (3Way TCP HandShake) : notre premier paquet comporte le flag Ack au lieu de Syn :
  
  $ hping -p 80 -n -A www.google.fr -c 1
  HPING www.google.fr (eth0 209.85.135.104): A set, 40 headers + 0 data bytes
  len=46 ip=209.85.135.104 ttl=55 DF id=32621 sport=80 flags=R seq=0 win=0 rtt=19.7 ms
  --- www.google.fr hping statistic ---
  1 packets transmitted, 1 packets received, 0% packet loss
  
  Le serveur nous retourne un paquet portant le flag Reset.
  Maintenant essayons sur un autre site :
  $hping -p 80 -n -A www.microsoft.fr -c 1
  HPING www.microsoft.fr (eth0 193.238.151.9): A set, 40 headers + 0 data bytes
  --- www.microsoft.fr hping statistic ---
  1 packets transmitted, 0 packets received, 100% packet loss
  
  On observe cette fois-ci un mutisme du serveur : le firewall détruit silencieusement tous les paquets n'appartenant pas à une connexion existante.
  
  Il ne faut pas en déduire que Microsoft est plus sécurisé que Google, ce serait certainement audacieux.. Réalisons d'ailleurs l'expérience suivante : nous démarrons un serveur FTP sur un PC Windows XP SP2 à jour, en interdisant l'accès à ces ports dans le Firewall système. Nous obtenons le résultat suivant : les connexions sont silencieusement dropées :
  $hping -p 21 -S 10.1.1.11 -c 1
  HPING 10.1.1.11 (eth0 10.1.1.11): S set, 40 headers + 0 data bytes
  --- 10.1.1.11 hping statistic ---
  1 packets transmitted, 0 packets received, 100% packet loss
  
  Maintenant nous permettons à l'application FTP d'être accessible par Internet et en Intranet :
  
  $hping -p 21 -S 10.1.1.11 -c 1
  HPING 10.1.1.11 (eth0 10.1.1.11): S set, 40 headers + 0 data bytes
  len=50 ip=10.1.1.11 ttl=128 DF id=30081 sport=21 flags=SA seq=0 win=16616 rtt=1.7 ms
  --- 10.1.1.11 hping statistic ---
  1 packets transmitted, 1 packets received, 0% packet loss
  
  Nous envoyons un paquet à destination du serveur FTP portant uniquement le flag Ack :
  
  $hping -p 21 -A 10.1.1.11 -c 1
  HPING 10.1.1.11 (eth0 10.1.1.11): A set, 40 headers + 0 data bytes
  len=50 ip=10.1.1.11 ttl=128 id=30115 sport=21 flags=R seq=0 win=0 rtt=1.2 ms
  --- 10.1.1.11 hping statistic ---
  1 packets transmitted, 1 packets received, 0% packet loss
  
  Ce paquet est rejeté par l'application (flag Reset et non pas « droppé » silencieusement par le firewall comme c'est le cas habituellement avec les firewalls dits « stateful » c-a-d à gestion de contexte).

• Comment tester l'application de la qualité de service ?
  
  Tout simplement en générant du trafic en spécifiant le port TCP/UDP ou bien la classe de service (champ TOS ou DiffServ DSCP) et en comparant les temps de réponse :
  Nous générons du flux Terminal Server (TSE) et FTP pour des paquets d'une taille importante (1400 octets) avec :
  
  $hping -p 21 -S 10.1.1.11 -d 1400
  $hping -p 3389 -S 10.1.1.11 -d 1400
  
  Si par exemple l'opérateur MPLS applique une politique de QoS, les résultats devraient être divergents (dans le cas de saturation du lien, bien sûr).
  Avec hping, on peut directement utiliser le code TOS (qui valent 4 fois le code DSCP). Ainsi, pour envoyer des paquets en utilisant la classe 4, 2ème file d'attente soit AF42 (Assured Forwarding) on marque le code DSCP 36 et donc TOS 144. Pour du trafic classé en EF (Expedited Forwarding – typiquement la voix sur IP), on choisira le code DSCP 46 ou TOS 184 :
  
  $hping -p 3389 -S 10.1.1.11 -d 1400 -tos 144
  $hping -p 3389 -S 10.1.1.11 -d 1400 -tos 184
  
  

• Comment connaître la taille maximale des paquets (MTU) transmissibles entre 2 machines ?
  
  Il suffit de générer un paquet d'un grande taille et de spécifier qu'il ne doit pas être fragmenté en chemin ( flag DF :Don't Fragment) pour obtenir un message ICMP des routeurs exigeant des paquets d'une taille inférieur au MTU du chemin (mécanisme de Path MTU Discovery). Ci dessous les tests démontrent l'existence d'un MTU maximal à 1460 et la mauvaise configuration des routeurs qui filtrent les messages ICMP « Fragmentation Needed » :
  
  $hping -p 25 -n -S -d 1460 --dontfrag smtp.abc.fr -c 1
  HPING smtp.abc.fr (eth0 w.x.y.z): S set, 40 headers + 1460 data bytes
  len=1500 ip=w.x.y.z ttl=121 DF id=72 sport=25 flags=SA rtt=1.4 ms
  --- smtp.abc.fr hping statistic ---
  1 packets transmitted, 1 packets received, 0% packet loss
  
  $hping -p 25 -n -S -d 1461 --dontfrag smtp.abc.fr -c 1
  HPING smtp.abc.fr (eth0 w.x.y.z): S set, 40 headers + 1461 data bytes
  --- smtp.abc.fr hping statistic ---
  1 packets transmitted, 0 packets received, 100% packet loss

• Comment connaître l'activité d'un serveur ?
  
  En observant l'incrément du compteur IP Id entre deux requêtes que nous générerons, nous pouvons en déduire le nombre de paquets envoyé par le serveur dans l'intervalle :
  
  $hping -p 80 -n -S -r -i 10 www.libe.fr
  HPING www.libe.fr (eth0 198.78.202.124): S set, 40 headers + 0 data bytes
  len=46 ip=198.78.202.124 ttl=57 id=55919 sport=80 flags=SA seq=0
  len=46 ip=198.78.202.124 ttl=57 id=+1 sport=80 flags=SA seq=1
  len=46 ip=198.78.202.124 ttl=57 id=+33065 sport=80 flags=SA seq=2
  len=46 ip=198.78.202.124 ttl=57 id=+32471 sport=80 flags=SA seq=3
  len=46 ip=198.78.202.124 ttl=57 id=+1 sport=80 flags=SA seq=4 win=5840

• Comment effectuer un traceroute vers un serveur firewallé ?
  
  Si ce serveur présente un port ouvert (par exemple TCP/80 HTTP), il suffit d'envoyer des paquets TCP d'ouverture de connexion ( flag SYN) avec un TTL croissant linéairement et d'observer les équipements actifs qui renvoient le message ICM « TTL expired during transit » pour reconstituer l'itinéraire aller des paquets :
  
  $hping -T -p 80 -n -S --tr-no-rtt www.hping.org
  HPING www.hping.org (eth0 192.70.106.166): S set, 40 headers + 0 data bytes
  hop=1 TTL 0 during transit from ip=a.b.c.d
  hop=2 TTL 0 during transit from ip=w.x.y.z
  hop=3 TTL 0 during transit from ip=212.27.58.45
  hop=4 TTL 0 during transit from ip=212.27.57.214
  hop=5 TTL 0 during transit from ip=212.27.58.78
  hop=6 TTL 0 during transit from ip=213.228.3.251
  hop=7 TTL 0 during transit from ip=194.79.131.129

  hop=8 TTL 0 during transit from ip=194.79.131.150
  hop=9 TTL 0 during transit from ip=194.79.130.117
  hop=10 TTL 0 during transit from ip=213.215.27.74
  hop=11 TTL 0 during transit from ip=192.70.106.23
  len=46 ip=192.70.106.166 ttl=52 DF id=0 sport=80 flags=SA seq=17 win=5840 rtt=5.5 ms

--[ 5. Nos lectures du moment... ]----

http://gigaom.com/2007/12/21/xavier-niel-free-fr/

Récit d'une rencontre avec le fondateur de Free. On apprend quelques détails sur leur infrastructure réseau et leur organisation. (pour les non initiés, FFTH signifie Fiber To The Home)

http://www.techcrunch.com/2008/01/04/ding-dong-sony-bmg-to-drop-drm/

Les 4 grands Major de l'industrie du disque ont abandonné les DRM (verrous logiciels). Au tour des studios de cinéma ?

http://www.zdnet.fr/actualites/it-management/0,3800005311,39376779,00.htm?xtor=RSS-1

Produits OpenSource et Commercialisation

http://www.vmware.com/appliances/

Un annuaire de VMWare à télécharger

http://www.01net.com/editorial/363494/la-vente-de-l-eee-pc-en-france-reportee-a-la-fin-de-janvier-2008/

Asus lance un ultra-portable communiquant sous Linux pour 300€

http://fr.youtube.com/watch?v=zqRQJds4Nmw#

Un petit moment de détente ..

--[ 6. Contact ]----

RANDCO, SARL au capital de 30.000 Euros.
45 Avenue Hoche
75008 Paris
Contact Commercial : contact@randco.fr
Contact pour la Newsletter : newsletter@randco.fr

Ceci est une newsletter gratuite.

Vous pouvez la transmettre ou bien en recommander la lecture par le biais d'une inscription ou par la consultation de nos archives.

La reproduction de ce texte est permise tant que celle-ci en respecte l'intégralité.