Catégories
Hardware Open-source Planet-libre Reseau Systeme Web

Cours d’introduction au « Cloud Computing »

En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).

Pour ceux que cela intéresse, voici (sous licence « CC By:« ):

Au passage un grand merci à Philippe Scoffoni pour sa relecture et ses remarques.

Catégories
Open-source Planet-libre Web

Un serveur Jabber en 5 minutes chronos sous Debian/Ubuntu

Oui je sais c’est un pompage en règle du billet de Cyrille Borne. Mais bon il faut dire que par les temps qui courent c’est une rudement bonne idée que de disposer de son propre serveur Jabber.

Nous allons donc détailler les étapes d’installation et de configuration d’un serveur Prosody dans sa dernière version (0.7) avec un chiffrement SSL entre les clients et le serveur.

Pourquoi Prosody et pas Jabber ? Tout simplement car il est bien plus simple et léger à installer (un peu trop usine à gaz). Et puis le titre du billet aurait été moins vendeur: « Un serveur Jabber en 3h45 chronos… ».

Installation de Prosody

L’installation de Prosody se fait en utilisant les commandes suivantes:

echo « deb http://packages.prosody.im/debian stable main » | sudo tee -a /etc/apt/sources.list

wget http://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –

sudo aptitude update

sudo aptitude install prosody

Sous Ubuntu 10.04, j’ai du en plus installer à la main la librairie LibLua (pour le SSL):

wget http://prosody.im/downloads/debian/liblua5.1-sec0_0.3.2-2prosody1_i386.deb

sudo dpkg -i liblua5.1-sec0_0.3.2-2prosody1_i386.deb

PS: la librairie LibLua est utilisé pour le chiffrement SSL. Le fichier liblua5.1-sec0_0.3.2-2prosody1_amd64.deb doit être utilisé pour les machines sous AMD 64 bits.

On génère la clés et le certificat SSL:

cd /etc/prosody/certs/

sudo openssl req -new -x509 -days 365 -nodes -out « monbeaudomaine.com.cert » -keyout « monbeaudomaine.com.key »

Configuration de Prosody

Puis on configure en éditant le fichier /etc/prosody/prosody.cfg.lua:

sudo vi /etc/prosody/prosody.cfg.lua

VirtualHost « monbeaudomaine.com »

ssl = {

key = « /etc/prosody/certs/monbeaudomaine.com.key »;

certificate = « /etc/prosody/certs/monbeaudomaine.com.cert »;

}

enabled = true;

On relance Prosody pour prendre en compte la configuration:

sudo /etc/init.d/prosody restart

Si vous avez un Firewall sur votre serveur (ce qui est une bonne idée), il faut penser à ouvrir les ports TCP de Jabber en ajoutant les lignes suivantes dans votre script de configuration iptable (/etc/init.d/iptables.sh dans mon cas):

iptables -A INPUT -p tcp –dport 5222 -j ACCEPT

iptables -A INPUT -p tcp –dport 5269 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 5269 -j ACCEPT

On relance ensuite le Firewall:

sudo /etc/init.d/iptables.sh

Puis on vérifie que les règles existent:

sudo iptables -L | grep xmpp

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-client

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

Création d’un compte utilisateur Jabber dans Prosody

On peut ensuite passer à la création d’un utilisateur Jabber:

sudo prosodyctl adduser monbeauuser@monbeaudomaine.com

Il faut saisir deux fois le même mot de passe…

Configuration d’un client Jabber pour utiliser votre serveur Prosody

Enfin, sur son/ses PC, on configure le client de chat (Pidgin dans mon cas).

Il faut aller dans le menu Comptes > Gérer les comptes puis cliquer sur le bouton Ajouter:

Et hop voili !

Catégories
Open-source Planet-libre Systeme

Installation et configuration de AWN sous Ubuntu

Il n’y a pas si longtemps le dock était le parent pauvre des distributions GNU/Linux. Avec l’apparition de projets comme Docky, Cairo ou AWN, cette tendance s’inverse à vitesse grand V ! Partisant de Docky depuis quelques mois, je vais donner une nouvelle chance à AWN qui, dans ses dernières versions, apportent des fonctionnalités intéressantes.

Allez zou lets’s rock…

Installation de AWN

C’est assez simple sous Ubuntu:

sudo add-apt-repository ppa:awn-testing/ppa
sudo apt-get update
sudo apt-get install avant-window-navigator-trunk avant-window-navigator-data-trunk python-awn-trunk awn-settings-trunk awn-applets-python-core-trunk python-awn-extras-trunk awn-applets-python-extras-trunk awn-applets-c-core-trunk awn-applets-c-extras-trunk

PS: Si vous avez un autre dock (par exemple Docky), il faudra le désinstaller histoire de ne pas se retrouver avec deux docks (mais il est possible de concerver les deux en // durant la phase de test).

sudo aptitude remove docky

Lancement de AWN

A partir du menu Applications > Accessoires > Avant Window Navigator

Configuration de AWN

Voilà ce que donne mon dock (après la configuration à faire ci-dessous):

Pour accèder au menu de configuration, il faut cliquer sur le bouton de gauche du dock puis sur le bouton configuration.

Vous pouvez directement importer une configuration existante (par exemple si vous avez plusieurs PC) en allant dans le menu Thème puis en cliquant sur le bouton Importer. Vous pouvez télécharger mon thème en cliquant ici ou bien suivre pas à pas les étapes suivantes:

Sauvegarder votre configuration AWN

Pour éviter d’avoir à refaire la configuration à chaque installation (ou re-installation de machine), il est possible d’archiver la configuration d’AWN dans un fichier .tgz. Pour cela, il faut se rendre dans le menu Thèmes > Personnaliser puis cliquer sur le bouton exporter le thème.

Mon fichier de configuration se trouve ici.

A l’utilisation…

Je n’avais pas testé AWN depuis un bon moment, j’utilisais Docky comme gestionnaire de dock. Je dois dire que de nombreux progrès ont été fait. La configuration est vraiment simple, intuitive et l’utilisation agréable. Je n’ai eu aucun plantage même avec l’utilisation de la version de développement.

C’est donc décidé pour ma part, je migre vers AWN 🙂

Sources utilisées pour la rédaction de ce billet:

Catégories
Developpement Open-source Planet-libre Reseau Web

Installation et test de NGinx sous Ubuntu

NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d’être plus rapide, plus léger et facile à configurer.

Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !

Installation de NGinx

On commence par ajouter le dépôt officiel pour la version stable:

sudo add-apt-repository ppa:nginx/stable

sudo aptitude update

Puis on installe la bête (facile non ?):

sudo aptitude install nginx

Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l’installation de NGinx se passera normalement, par contre il n’arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu’il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l’utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l’autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).

Premier contact avec NGinx

Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:

sudo service nginx

Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}

On va donc activer la configuration de test:

sudo service nginx configtest

Testing nginx configuration: nginx.

Puis lancer le serveur:

sudo service nginx start

Starting nginx: nginx.

On ouvre un navigateur sur la même machine puis on entre l’UTL suivante: http://localhost/

La page suivante devrait s’afficher:

On peut ensuite arrêter le serveur:

sudo service nginx stop

Stopping nginx: nginx.

Puis passer à l’étape suivante…

Configuration du serveur NGinx

Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d’Apache ne seront pas trop perturbés par la structure de l’arborescence de ce répertoire:

 

drwxr-xr-x 2 root root 4096 2011-01-05 08:26 conf.d/

-rw-r–r– 1 root root 884 2011-01-05 08:04 fastcgi_params

-rw-r–r– 1 root root 2258 2011-01-05 08:04 koi-utf

-rw-r–r– 1 root root 1805 2011-01-05 08:04 koi-win

-rw-r–r– 1 root root 2066 2011-01-05 08:04 mime.types

-rw-r–r– 1 root root 1340 2011-01-05 08:04 nginx.conf

-rw-r–r– 1 root root 465 2011-01-05 08:04 scgi_params

drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-available/

drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-enabled/

-rw-r–r– 1 root root 497 2011-01-05 08:04 uwsgi_params

-rw-r–r– 1 root root 3071 2011-01-05 08:04 win-utf

On y retrouve (entre autres):

  • nginx.conf: le fichier de configuration central
  • conf.d/: un répertoire contenant des fichiers de configuration additionnels
  • sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
  • sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)

On commence par jeter un coups d’oeil au fichier nginx.conf…. Quel bonheur par rapport à celui d’Apache :).

On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l’on a activé tout à l’heure par la commande ‘sudo service nginx configtest’):

server {

listen 80

 

root /usr/share/nginx/www;

index index.html index.htm;

 

server_name localhost;

 

location / {

try_files $uri $uri/ /index.html;

}

 

location /doc {

root /usr/share;

autoindex on;

allow 127.0.0.1;

deny all;

}

 

location /images {

root /usr/share;

autoindex off;

}

 

}

On peut donc voir que l’on a un site qui écoute sur le port TCP/80 (listen   80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l’URL http://localhost/ (server_name localhost).

Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.

On commence par créer l’arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n’existe pas il faut le créer et lui donner les bons droits:

mkdir /home/labo/www

Enfin on édite une page de test:

# vi /home/labo/www/index.html

<html><body>Ma page</body></html>

Ensuite on passe à la création du fichier de configuration du site.

sudo vi /etc/nginx/sites-available/monsite

Avec le contenu suivant (à adapter à votre configuration):

# Mon site a moi

 

server {

listen 80;

 

root /home/labo/www;

index index.html index.htm;

 

server_name localhost;

 

location / {

# First attempt to serve request as file, then

# as directory, then fall back to index.html

try_files $uri $uri/ /index.html;

}

 

}

On supprime le site par defaut et on active le notre:

cd /etc/nginx/sites-enabled

sudo rm default

sudo ln -s ../sites-available/monsite

On redémarre le serveur Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Puis  on teste la page: http://localhost/

Pour rendre le site « visible depuis l’extérieur », il faut changer la ligne:

server_name localhost;

Puis la remplacer par:

server_name www.mondomaine.com;

Il faut bien sur que le nom www.mondomaine.com pointe sur l’adresse IP de votre serveur Nginx…

Test des performances

Pour voir ce qu’il a dans le ventre, j’ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.

J’ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.

Test du serveur Apache:

# httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

Request rate: 4284.8 req/s (0.2 ms/req)

Puis test du serveur NGinx:

# httperf –client=0/1 –server=localhost –port=81 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

Request rate: 6332.6 req/s (0.2 ms/req)

On a donc un gain d’environ 30% en terme de requêtes supportées par le serveur.

 

 

Request rate / Request number

 

Support du PHP

De nos jours, un serveur Web sans support PHP c’est un peu comme un Ferrari avec des roues de 13 pouces. Dans l’optique d’avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s’occupera de l’exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m’a bien aidé).

On commence par installer le module:

sudo add-apt-repository ppa:brianmercer/php

sudo aptitude update && sudo aptitude install php5-fpm

Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).

Il ne reste plus qu’à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):

# Mon site a moi

server {

listen 80;

server_name localhost;

root /home/labo/www;

 

location / {

index index.php index.html;

}

 

location ~ \.php$ {

fastcgi_pass 127.0.0.1:9000;

include /etc/nginx/fastcgi_params;

fastcgi_index index.php;

}

}

Attention de bien avoir configurer la variable root (« root /home/labo/www » dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.

On relance ensuite Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:

<?php

phpinfo();

?>

Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.php

La page suivante devrait s’afficher:

Support de Perl

Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.

Contrairement à PHP, il n’existe pas (encore) de package Ubuntu permettant d’automatiser l’installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !

On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:

sudo perl -MCPAN -e ‘install FCGI’

On installe le processus fastcgi-wrapper.pl qui va s’occuper de l’exécution  des scripts Perl:

sudo wget -O /usr/bin/fastcgi-wrapper.pl http://lindev.fr/public/nginx/fastcgi-wrapper.pl

sudo chmod 755 /usr/bin/fastcgi-wrapper.pl

La plupart des tutos que j’ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d’autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J’ai donc écrit un nouveau script basée sur celui du wrapper PHP.

On automatise le lancement de ce script au démarrage du serveur:

sudo wget -O /etc/init.d/perl-fastcgi https://raw.github.com/nicolargo/ubuntupostinstall/master/perl-fastcgi

sudo chmod 755 /etc/init.d/perl-fastcgi

sudo update-rc.d perl-fastcgi defaults

Puis on le lance en tache de fond:

sudo service perl-fastcgi start

Il ne reste plus qu’à modifier le fichier de configuration Nginx de votre site pour prendre en compte les scripts Perl:

# Mon site a moi

server {

listen 80;

server_name localhost;

root /home/labo/www;

 

location / {

index index.php index.html;

}

 

location ~ \.php$ {

fastcgi_pass 127.0.0.1:9000;

include /etc/nginx/fastcgi_params;

fastcgi_index index.php;

}

 

location ~ \.pl$ {

fastcgi_pass 127.0.0.1:8999;

include /etc/nginx/fastcgi_params;

fastcgi_index index.pl;

}

}

On relance ensuite Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Pour tester que le Perl fonctionne bien, le plus simple est de créer un fichier info.pl (à mettre à la racine du site /home/labo/www/) contenant:

#!/usr/bin/perl

print « Content-type: text/html\n\n »;

print « <html><body>Hello, world.</body></html> »;

Attention, contrairement au script PHP, les fichier .pl douivent avoir les droits en exécution sous peine de ce trouver devant le message suivant:

Error: No such CGI app – /home/labo/www/info.pl may not exist or is not executable by this process.

On doit donc saisir la commande:

chmod a+x /home/labo/www/info.pl

Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.pl

La page suivante devrait s’afficher:

Optimisation corner !

On passe maintenant à quelques optimisations que l’on peut ajouter à la configuration de son site (merci à @T1B0).

On commence par le fait de ne pas loguer les message 404 sur le fichier favicon.ico (histoire de ne pas surcharger ses logs):

location = /favicon.ico {

access_log off;

return 204;

}

Ensuite on optimise la durée d’expiration des en-tête des fichiers statiques (pour les caches):

location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {

expires 30d;

}

Pour aller plus loin, vous pouvez également lire ce billet chez K-Tux. (notamment l’utilisation de memcache qui est intégré à NGinx !).

Conclusion

Vous avez donc à votre disposition un beau serveur Web NGinx avec le support FastCGI PHP & Perl !

Elle est pas belle la vie ?

Catégories
Blog Open-source Planet-libre Systeme Web

4 hacks pour extraire des statistiques de WordPress

C’est le début de l’année et le moment des bilans concernant les statistiques de votre blog. Voici donc un petit billet sur quelques hacks MySQL permettant d’obtenir des statistiques à diffuser vers vos lecteurs ou à garder au chaud !

Avant tout il faut disposer d’un accès à votre base de donnée MySQL (soit via une interface de type phpMySQL, soit directement via une ligne de commande mysql). Pour avoir vos paramètres de connexion à votre BD WordPress il suffit de regarder le fichier wp-config.php à la racine de votre répertoire Web.

Voici l’architecture des tables de votre BD WordPress. Je ne suis plus trop un expert en requêtes MySQL (les cours datent de plus de 10 ans maintenant ;)) alors si vous voyez des améliorations dans les requêtes ci-dessous je suis preneur de commentaires.

Nombre de billets publiés en 2010

Cette première requête donne le nombre de billets publiés (status= »publish ») sur l’année 2010 (c’est à dire entre le 1er janvier et le 31 décembre 2010).

mysql> SELECT COUNT(*) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’;

+———-+

| COUNT(*) |

+———-+

| 161 |

+———-+

1 row in set (0.00 sec)

Nombre de commentaires pour les billets publiés en 2010

Une requête un peu plus complexe qui somme (SUM) le nombre de commentaires pour les billets 2010.

mysql> SELECT SUM(comment_count) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY post_status;

+——————–+

| SUM(comment_count) |

+——————–+

| 1314 |

+——————–+

1 row in set (0.01 sec)

Liste des 10 billets les plus commentés publiés en 2010

On continu pas le classement (TOP 10) des nouveaux billets les plus commentés.

mysql> SELECT post_title,comment_count FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ ORDER BY comment_count DESC LIMIT 0,10;

+——————————————————————-+—————+

| post_title | comment_count |

+——————————————————————-+—————+

| Configurer VPNTunnel sous Ubuntu | 58 |

| Installation et test de Flumotion 0.8 | 46 |

| Script d’installation automatique de Nagios | 42 |

| Spideroak, un sérieux concurrent à Dropbox | 40 |

| Utiliser Nmap pour générer vos fichiers de configuration Nagios | 38 |

| Installation d’un serveur OpenVPN sous Debian/Ubuntu | 36 |

| 12 étapes pour optimiser les performances de son blog WordPress | 35 |

| Le blog de Nicolargo a son application IOS | 35 |

| Tu fais quoi après l’installation de Firefox ? | 26 |

| MyScreenCast, comment faire du screencast avec GStreamer | 26 |

+——————————————————————-+—————+

10 rows in set (0.01 sec)

Top 10 des lecteurs ayant le plus posté de commentaires sur le blog en 2010

Enfin une requête un peu plus complexe qui donne le classement des plus gros « commentateurs » sur le blog.

mysql> SELECT comment_author,COUNT(comment_count) AS F01 FROM wp_comments,wp_posts WHERE comment_approved=1 AND comment_post_ID=ID AND comment_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY comment_author ORDER BY F01 DESC LIMIT 0,10;+—————-+—–+

| comment_author | F01 |

+—————-+—–+

| NicoLargo | 315 |

| Albert | 22 |

| Pierre-Yves | 18 |

| ninja21a | 18 |

| Mr Xhark | 15 |

| Sylvain | 14 |

| Christophe | 12 |

| floppy84 | 12 |

| Nico | 11 |

| Guillaume | 10 |

+—————-+—–+

10 rows in set (0.07 sec)

Si vous avez d’autres requêtes MySQL dans votre besace et bien faites tourner !

Catégories
Blog Open-source Planet-libre Reseau Systeme

Sécuriser son blog WordPress #2

Dans ce deuxième billet, nous allons aborder la pierre angulaire de la sécurisation de votre site/blog: la sécurisation du couple infernal Apache/PHP.

Bien qu’il existe d’autres serveurs Web (par exemple le très rapide NGinx ou le très simple Cherokee), Apache reste, à ce jour, le plus répandu. Un des reproche que l’on peut lui faire est sa lourdeur de configuration. Cette lourdeur et l’utilisation de fonctions pas forcement utiles à votre site peut rapidement entraîner des failles de sécurité. Nous allons donc détailler la sécurisation du serveur Web ainsi que celle du moteur de langage PHP qui est utilisé par WordPress.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #2):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Serveur Web Apache

Sécuriser l’installation par défaut d’Apache2

Apache est développé en tenant compte de la sécurité mais dévoile, dans le header HTTP, son identité (son nom et son numéro de version) à chaque client qui se connecte. Ne pas divulguer ces informations permet d’éviter aux scripts kiddies de connaitre directement les failles connues pour la version d’Apache utilisée et peut compliquer le travail des crackers.

Pour cacher ces informations aux clients HTTP, il suffit d’éditer le fichier /etc/apache2/conf.d/security et d’y ajouter/modifier les variables suivantes:

ServerTokens Prod
ServerSignature Off
TraceEnable On

Module de securité IDS pour Apache

Il existe dans Apache un module optionnel nommé ModSecurity2 qui permet de détecter et de protéger son serveur contre des attaques touchant vos applications Web (notamment les « SQL injections », « cross-site scripting », « path traversal attacks »…).

On commence par l’installation de mod-secure:

sudo aptitude install libapache2-mod-security2

Par défaut, aucune règle n’est appliquée. Il faut donc partir du fichier de configuration qui est donné en exemple:

sudo cp /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal /etc/apache2/conf.d/mod-security.conf

On édite ensuite le fichier /etc/apache2/conf.d/mod-security.conf:

# Basic configuration options
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Handling of file uploads
# TODO Choose a folder private to Apache.
SecUploadDir /tmp/
SecUploadKeepFiles Off

# Debug log
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0

# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

# Maximum request body size we will
# accept for buffering
#SecRequestBodyLimit 131072
SecRequestBodyLimit 8192000

# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072

# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288

# Verify that we’ve correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
SecRule REQBODY_PROCESSOR_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Failed to parse request body.’,severity:2 »

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
SecRule MULTIPART_STRICT_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}' »

# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.' »

On relance ensuite Apache pour prendre en compte le plugin:

sudo /etc/init.d/apache2 restart

Ce module contient un ensemble d’expressions rationnelles dont l’objectif est de bloquer les requêtes jugées dangereuses. Il bloquera une partie des tentatives de piratage. C’est  tout de même une barrière de protection faillible mais qui peut empêcher l’exploitation de certaines failles. Dans tout les cas, cela n’empêche pas le développeur de coder correctement, en prenant en compte la sécurité au moment du développement des sites.

Module anti DOS

Nous allons installer le module Apache mod_evasive qui permet d’atténuer les attaques DOS faite en utilisant le protocole HTTP en bloquant les adresses IP des clients trop gourmand, c’est à dire ceux qui demandent trop rapidement des pages webs.

Contrairement à ce que l’on peut lire sur certains sites, ce module ne protège pas des DDOS, seulement des DOS (lire ici une explication des attaques DOS et DDOS). Autrement dit, il bloque les reqêtes venant d’une adresse IP (DOS).

Si un très grand nombre d’IPs font une seule requête : votre serveur sera saturé et le mod_evasive n’aura pas servi (DDOS). Bloquer les DDOS est très difficile car les requêtes sont difficilement reconnaissables des requêtes autorisées.

On commence par installer le module:

sudo aptitude install libapache2-mod-evasive

On édite le fichier /etc/apache2/conf.d/mod-evasive:

<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
</IfModule>

C’est la configuration par défaut qui va bloquer pendant 10 secondes (DOSBlockingPeriod) les requêtes HTTP venant de l’adresse IP source si une des assertions suivantes est vérifiée:

  • il y a plus de 2 requêtes (DOSPageCount) sur la même page dans un intervalle de 1 seconde (DOSPageInterval)
  • il y a plus de 50 requêtes (DOSSiteCount) sur l’ensemble du site dans un intervalle de 1 seconde (DOSSiteInterval)

On relance ensuite Apache pour prendre en compte le plugin:

sudo /etc/init.d/apache2 restart

Sécurisation du moteur PHP

PHP est un langage interprété, largement utilisé pour générer dynamiquement des pages HTML. C’est le langage utilisé par le moteur de CMS WordPress. La génération des pages de votre blog se faisant directement sur votre serveur, il est important de protéger l’environnement d’exécution des scripts PHP.

Il est donc conseillé d’utiliser suphp. Il est relativement facile à installer et permet d’exécuter vos scripts PHP sous un utilisateur autre que www-data et donc protéger votre système.

Cela permet aussi de servir plusieurs sites internet sur un même serveur. Si un pirate atteint un site, il ne pourra pas toucher aux autres.

Ce module fournit aussi la possibilité de disposer d’un fichier PHP.ini par site web, et offre donc plus de flexibilité que l’installation standard de PHP.

La sécurité a néanmoins un coup: la performance. Attendez vous à des pertes de performances sur vos applications. Dans le cas d’une application codée correctement et d’un serveur non surchargé, cette perte devrait cependant être minime.

Il est également possible de désactiver certaines fonctions sensible de PHP (system, exec…) en éditant le fichier php.ini (voir exemple dans l’étape n°3 de ce billet).

Pour installer  suPhp sur votre serveur je vous conseille la lecture de cet article. (si vous voulez/devez faire cohabiter deux versions de PHP, par exemple la 4 et la 5, vous pouvez également consulter ce billet).

Conclusion (temporaire)

On dispose donc maintenant d’un système et d’un serveur Web sécurisé. Il ne reste plus qu’à attendre la suite de cette série de billets pour s’attaquer à la sécurisation du moteur de blogging WordPress.

Catégories
Image Open-source Planet-libre Systeme

Mon desktop 201101

Avant tout bonne année 2011 à vous et à vos proches.
Qu’elle vous apporte bonheur et épanouissement personnel !

On commence l’année par le billet mensuel sur mon desktop. On va aujourd’hui s’intéresser à mon PC portable sous Ubuntu Desktop 10.10 configuré le script post install (ubuntupostinstall.sh).

Un aperçu du résultat:

Les principales caractéristiques

Fond d’écran: De saison vu le temps qu’il fait…
GTKLook des fenêtre Equinoxicônes Faenza
Sur ce bureau: Docky + TerminatorNautilus Elementary

Installer de la combo magique (Equinox + Faenza + Nautilus Elementary)

Je n’ai pas trouvé mieux à mon goût pour le moment. Equinox est clair, les icônes Faenza sont lisibles et facile à reconnaître et  Elementary apporte une certaine légèreté à Nautilus.:

sudo aptitude install gtk2-engines-equinox equinox-theme equinox-ubuntu-theme faenza-icon-theme

nautilus -q

Pour coller un peu plus avec le fond d’écran, j’ai choisi le thème Glass d’Equinox en allant dans le menu “Système > Préférences > Apparences > Thème > Equinox Glass“.

Installation de Docky

Ce dock « à la MacOS X »  est disponible dans les dépôt standard, pour l’installer en ligne de commande:

sudo aptitude install docky

Pour le paramétrage, j’utilise:


Voilà ce que j’ai dedant au moment de l’écriture de ce billet:

Paramétrage de mon tableau de bord

J’utilise l’application NetSpeed pour voir en temps réel les débits sur mon interface réseau. Il faut l’installer avec la ligne de commande suivante:

sudo aptitude install netspeed

Ensuite je configure de la manière suivante:

Et vous cela donne quoi vos desktops en ce moment, à vos screenshots !

Catégories
Blog Nagios Open-source Planet-libre Reseau Systeme Web

Superviser son blog avec Nagios

Pour moi, la vraie révolution Internet de ces dernières années est l’apparition de blogs ayant petit à petit pris le relais des sites institutionnels pour diffuser de l’information. Souvent tenu à bout de bras par des particuliers, ils ne disposent pas d’une infrastructure informatique professionnelle.

Ainsi en cas de problème technique, l’administrateur est souvent prévenu par ses lecteurs…

Nous allons donc voir dans ce billet comment utiliser le logiciel libre de supervision Nagios pour surveiller automatiquement son blog.

Voilà ce que donnera le résultat dans l’interface Web de Nagios:

Contexte

Afin d’illustrer ce billet, nous allons partir sur l’hypothèse ou vous disposer d’un blog hébergé sur un serveur dédié ou virtuel sous Ubuntu Server 10.04 avec un accès SSH et un compte utilisateur avec les droits d’administration (sudo>r00t).

Aller on se connecte en SSH sur son serveur et on suit le guide.

Installation de Nagios

Nous allons utiliser le script d’installation automatique de Nagios (développé par votre serviteur).

On commence par le télécharger le script nagiosautoinstall-ubuntu.sh:

mkdir ~/monitoring/

cd ~/monitoring

wget https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoinstall-ubuntu.sh

chmod a+x nagiosautoinstall-ubuntu.sh

Puis on lance l’installation (il y a quelques questions auxquelles il faudra répondre) :

sudo ./nagiosautoinstall-ubuntu.sh

On devrait ensuite pourvoir accéder à l’interface Web de Nagios à partir de l’URL suivant: http://@IP/nagios/

Ou @IP est l’adresse IP de votre serveur.

Configuration de Nagios

Comme Nagios tourne sur la même machine que le serveur à superviser, toutes la configuration se fera dans le fichier de configuration localhost.cfg.

J’utilise deux plugins non inclus dans les plugins de bases de Nagios (mais installé automatiquement par le script nagiosautoinstall-ubuntu.sh):

On édite le fichier /usr/local/nagios/etc/objects/localhost.cfg (à adapter à votre configuration…):

#######################################################################

#

# Supervision du blog blog.nicolargo.com

#

#######################################################################

 

#######################################################################

#######################################################################

#

# HOST DEFINITION

#

#######################################################################

#######################################################################

 

# Define a host for the local machine

 

define host{

use linux-server

host_name blog

alias blog.nicolargo.com

address 127.0.0.1

}

 

#######################################################################

#######################################################################

#

# SERVICE DEFINITIONS

#

#######################################################################

#######################################################################

 

 

# Define a service to « ping » the local machine

 

define service{

use local-service

host_name blog

service_description PING

check_command check_ping!100.0,20%!500.0,60%

}

 

 

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

 

define service{

use local-service

host_name blog

service_description Root Partition

check_command check_local_disk!10%!5%!/

}

 

 

 

# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 2 users, critical

# if > 3 users.

 

define service{

use local-service

host_name blog

service_description Current Users

check_command check_local_users!2!3

}

 

 

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

 

define service{

use local-service

host_name blog

service_description Total Processes

check_command check_local_procs!250!400!RSZDT

}

 

# Check memoire avec script check_memory

# http://blog.nicolargo.com/2008/07/surveiller-la-memoire-de-vos-serveurs-avec-nagios.html

# -w 800000000 -c 900000000

 

define service{

use local-service

host_name blog

service_description Memory

check_command check_memory!800000000!900000000

}

 

# Define a service to check the load on the local machine.

 

define service{

use local-service

host_name blog

service_description Current Load

check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0

}

 

# Define a service to check the swap usage the local machine.

# Critical if less than 10% of swap is free, warning if less than 20% is free

 

define service{

use local-service

host_name blog

service_description Swap Usage

check_command check_local_swap!20!10

}

 

# Define a service to check SSH on the local machine.

# Disable notifications for this service by default, as not all users may have SSH enabled.

 

define service{

use local-service

host_name blog

service_description SSH

check_command check_ssh

#notifications_enabled 0

}

 

 

 

# Define a service to check HTTP on the local machine.

# Disable notifications for this service by default, as not all users may have HTTP enabled.

 

define service{

use local-service

host_name blog

service_description HTTP

check_command check_http

#notifications_enabled 0

}

 

# Define a service to check URL

# http://blog.nicolargo.com/google89d0cf0b89815a2a.html

 

define service{

use local-service

host_name blog

service_description URL Google check file

check_command check_url!http://blog.nicolargo.com/googl

e89d0cf0b89815a2a.html

}

 

# Define a service to check URL

# http://blog.nicolargo.com/sitemap.xml.gz

 

define service{

use local-service

host_name blog

service_description URL Sitemap

check_command check_url!http://blog.nicolargo.com/sitem

ap.xml.gz

}

 

# Define a DDOS detection service

# http://blog.nicolargo.com/?p=4100

# Warning: >50 SYN_RECV

# Critical: >70 SYN_RECV

 

define service{

use local-service

host_name blog

service_description DDOS detect

check_command check_ddos!50!70

}

Ce fichier de configuration va permettre de superviser les choses suivantes:

  • état du serveur (réponse au ping en moins de 500ms et 60% de paquets perdus)
  • espace disque disponible > 5% de la taille totale (10% pour un warning)
  • pas plus de 3 personnes connectés en même temps sur le serveur (2 pour un warning)
  • pas plus de 400 processus lancés en parallèle (250 pour un warning)
  • mémoire disponible (basée sur RAM 1 Go) > 10% de la mémoire totale (20% pour un warning)
  • charge (CPU) moyenne sur 5 minutes < 10% (5% pour un warning)
  • espace de swap disponible > 10% de la taille totale du swap (20% pur warning)
  • Port SSH en écoute
  • Port HTTP en écoute
  • Vérification de l’existence du fichier de check de Google
  • Vérification de l’existence du fichier sitemap.xml (référencement dans moteur de recherche)

Il y a surement plein d’autres choses à vérifier…

A vos claviers pour nous dire cela dans les commentaire.

Catégories
Nagios Open-source Planet-libre Reseau Systeme Web

La supervision chez Web4All, hébergeur associatif

Ce billet a été rédigé par Jonathan Gaulupeau et à pour double objectif de mettre en avant Web4all, un hébergeur alternatif à but non lucratif et de montrer comment des outils open-source sont utilisés pour assurer une supervision professionnelle de ce type de réseau.


Web4All, qui sommes-nous ?

Web4All est une association à but non lucratif qui a pour but de fournir un hébergement mutualisé de qualité professionnelle au plus grand nombre. Nos offres, plus orientées vers l’utile que vers le tape-à-l’œil, sont parmi les moins chères du marché.

Notre gestion est totalement désintéressée. Tous les acteurs de Web4All sont des bénévoles animés par l’envie de rendre un service de qualité à plus de 2000 clients.

Nous sommes constamment à la recherche du meilleur rapport qualité / prix. Nous étudions pour cela aussi bien des solutions libres que propriétaires. Dans les faits, la quasi-totalité de nous outils est issue de la communauté open-source. Cependant, nos besoins étant parfois très spécifiques, nous développons également nos propres outils.

Pourquoi la supervision ?

Toute entité possédant un ou plusieurs serveurs (quels que soient les systèmes d’exploitation utilisés) se doit de contrôler en permanence leur état. D’autant plus lorsqu’il s’agit, comme nous, de serveurs dont dépend le maintien en conditions opérationnelles des services que nous proposons.

En réalité, ce n’est pas tout à fait le cas, notre infrastructure étant redondée afin de fournir des services à haut taux de disponibilité.

La supervision sous quelle forme, quels outils ?

Je n’ai parlé, jusqu’à présent, que de la supervision en temps réel. Celle qui nous remonte une alarme si un service ne respecte pas des paramètres que nous avons définis. Un technicien peut alors prendre en compte l’alarme, en chercher la cause et, de préférence, la régler. Si, malgré nos précautions, un service est impacté, le technicien en informe les clients par une interface dédiée.

Chez nous, cette supervision est assurée par Nagios.

Quelques services surveillés par Nagios sur un frontal Apache

Toutefois, un autre aspect est important dans la supervision : suivre l’évolution de divers indicateurs sur une période plus ou moins longue. En clair, nous avons besoin, par exemple, pour anticiper l’évolution de nos besoins en terme de stockage, de regarder l’évolution sur l’espace disque que nous avons eu par le passé. Ces indicateurs peuvent nous fournir des informations remontant à des mois, voire des années. Ils nous permettent également de prévoir les pics de charge que subira notre infrastructure. Très pratique pour savoir quand ne pas programmer des tâches d’archivage par exemple. Enfin, cela peut s’avérer très utile lorsqu’il s’agit de réaliser un état de santé général. Nous savons à quoi doivent ressembler nos graphiques, nous pouvons donc voir d’un coup d’œil si tout semble correct.

Cette partie est réalisée par un autre outil : Cacti.

Graphique de trafic réseau réalisé par Cacti

Tous ces indicateurs combinés nous permettent d’évaluer notre qualité, point très important pour la personne chargée de la QoS (Quality of Service). Ils nous permettent également de prévoir nos futurs achats et évolutions de l’infrastructure. Nous pouvons ainsi réaliser tous les tests nécessaires aux évolutions dans un environnement de pré-production, sans travailler dans l’urgence et la panique que pourrait constituer une dégradation de la qualité des services rendus aux clients.

Enfin, nous avons également une carte d’état en temps réel du réseau client de Web4All qui est accessible à tous les clients.

Cette carte se base sur les informations récupérées par Cacti.

Carte d’état en temps réel du réseau client de Web4All

Ce que nous supervisons

Tous ces tests sont réalisés dans Nagios ainsi que dans Cacti.

Les basiques

Les incontournables de la supervision que sont :

  • Le ping -> Un ping est réalisé sur le serveur, nous indiquant s’il est joignable ou non sur le réseau. C’est l’information la plus élémentaire dont nous avons besoin.
  • Le load average -> Le load est récupéré par SNMP. Il nous indique la charge système. Des seuils de criticité sont définis en fonction des habitudes de chaque serveur.
  • La mémoire -> Le taux de mémoire utilisée est récupéré par SNMP. Il nous permet de savoir si une application souffre d’une fuite mémoire par exemple.
  • L’espace disque -> Le taux d’espace libre sur les partitions des serveurs est récupéré par SNMP. Il nous permet d’être alertés avant qu’une partition ne soit pleine.

Le réseau

C’est le cœur de notre activité. Il fait donc l’objet de toutes les attentions.

Nous surveillons le taux de transfert de toutes les interfaces des serveurs. Nous pouvons alors être alertés en cas de pic anormal ainsi qu’étudier l’évolution de la charge réseau afin d’anticiper les besoins en terme de bande passante.

Les services

Chaque service est testé par Nagios grâce à des plug-ins.

Ces plugins sont soit récupérés sur la plateforme d’échange Nagios Exchange soit écrits spécifiquement pour Web4All.

Voici quelques exemples :

  • Serveur DNS -> Test de résolution de nom
  • Serveur Mail -> Test des protocoles POP, IMAP, SMTP, état de la queue des mails, etc.
  • Frontaux Apache -> Test des Apache Server Status
  • Load Balancers -> Vérification du nombre de serveurs dans le pool
  • Serveurs SQL -> Test de connexion à une base de données

Les aide-mémoires

Certains tests n’ont pour but que de nous rappeler de réaliser une action bien précise.

Par exemple, tous nos certificats SSL sont testés afin de nous remonter une alerte plusieurs semaines avant leur date d’expiration.

Conclusion

La supervision est un point essentiel chez Web4All. Elle nous permet d’avoir une meilleure réactivité grâce aux alertes remontées par Nagios, mais elle nous permet également de mieux préparer l’avenir grâce aux graphiques réalisés par Cacti.

Enfin, grâce à la supervision, nous pouvons également fournir à nos clients le taux de disponibilité réel de nos services.

 

A propos de l’auteur: Jonathan est expert sur le logiciel de conception mécanique CATIA V5, la « crise » du secteur automobile l’a poussé à s’orienter vers l’administration des systèmes Unix. Il est aujourd’hui Ingénieur Systèmes & Réseaux. Depuis 2009 il s’est engagé dans l’association Web4All ou il fait partie du Conseil d’Administration et ou il s’occupe de l’administration des serveurs ainsi que de leur supervision.

A propos de Web4All: Web4all est un hébergeur associatif qui propose des hébergements de site web à faible coût ainsi que la vente de nom de domaine et un service emails.

J’espère que comme moi cet article vous a intéressé. N’hésitez pas à poser des questions à Jonathan dans les commentaires de ce billet, je suis sur qu’il se fera un plaisir de vous répondre.

Catégories
Open-source Planet-libre Reseau Systeme Web

Comment installer (vraiment) Dropbox 1.0 sous GNU/Linux

Dropbox vient de mettre à jour son client vers la version 1.0. Malheureusement, la procédure d’installation qui est donnée sur le site ne marchait pas pour moi (j’ai fait le test sous Ubuntu 10.10 et Fedora 14).

Voici donc un petit hack pour mettre à jour le client depuis une version 0.7.110 vers la 1.0.10:

1) Arrêter votre client Dropbox

2) Lancer les commandes suivantes dans un terminal:

cd ~

wget http://dl-web.dropbox.com/u/17/dropbox-lnx.x86-1.0.10.tar.gz

mv .dropbox-dist .dropbox-dist.OLD

tar zxvf dropbox-lnx.x86-1.0.10.tar.gz

rm -f dropbox-lnx.x86-1.0.10.tar.gz

Remarque: Si votre PC à une architecture 64 bits, il faut télécharger: dropbox-lnx.x86_64-1.0.10.tar.gz

3) Puis relancer le client Dropbox…

Et voilà le travail ! A vous les joies du Selective Sync !