• Freelan : http://www.freelan.org/
• N2N : http://www.ntop.org/products/n2n/
• Tinc : http://www.tinc-vpn.org/

Qu’est ce que le Raspberry Pi ? Un mini ordinateur / plug-computer au format carte de crédit, à base d’ARM, et vendu $25 pour le modèle A, et $35 pour le modèle B ! Voici la description hardware du modèle B (le A est identique, moins le port Ethernet et moins 2 ports USB) :

• Broadcom BCM2835 700MHz ARM1176JZFS processor with FPU and Videocore 4 GPU
• GPU provides Open GL ES 2.0, hardware-accelerated OpenVG, and 1080p30 H.264 high-profile decode
• GPU is capable of 1Gpixel/s, 1.5Gtexel/s or 24GFLOPs with texture filtering and DMA infrastructure
• 256MB RAM
• Boots from SD card, running the Fedora version of Linux
• 10/100 BaseT Ethernet socket
• HDMI socket
• USB 2.0 socket
• RCA video socket
• SD card socket
• Powered from microUSB socket
• 3.5mm audio out jack
• Header footprint for camera connection
• Size: 85.6 x 53.98 x 17mm

Avec ce genre d’engin, on peut imaginer toutes sortes d’utilisations : serveur web/mail basse consommation à la maison, serveur de fichiers ou de backup, ou même boitier multimédia puisque XBMC tourne sur le Raspberry Pi (une petite démo est dispo), et est capable de streamer du full HD directement en HDMI sur votre TV !

Mais heureusement ! Je suis prévoyant, je n’ai pas pris un serveur cheap avec un simple disque SATA grand public chez xVH ou xEDIBOX ! Non môssieur, je suis moderne, je prends un hébergement de geek (c’est écrit dans la pub), c’est-à-dire du clahoude comptioutingue avec un serveur dans les nuaaaages, avec des disques stockés sur des SAN redondés (du bête RAID en fait), et avec des sauvegardes automatiques (c’est dans la pub ça aussi) ! Ca fait rêver, ça donne carrément confiance, on y va les yeux fermés.

Bilan de l’échange rigolo avec le support :

technicien : « bon bah euh… oui… le disque semble HS… alors le mieux c’est de remonter le disque sur un autre serveur pour récupérer les quelques (rares) données qui sont encore exploitables, et de réinstaller le serveur… mais du coup vous ne repartez pas de zéro ! ».
moi : « oui mais non. Déjà moi je n’ai rien demandé, c’est vous qui avez fait une erreur, je ne veux pas passer du temps à réparer pour une erreur humaine de votre part. Et puis tant pis : restaurez un backup, même vieux d’une semaine, je m’en fiche ce n’est pas grave du moment que ça repart rapidement » (note: c’est un serveur Nagios)
technicien : « … »
moi : « allo ? … Le backup, disais-je donc. »
technicien : « euh mais non, on n’a pas de backups nous… en fait… »
moi :   »ben si siii, c’est écrit que le stockage est redondé sur votre site ! Donc ben voilà, reprenez un backup de l’autre SAN, et zouh c’est reparti »
technicien : « oui voilà, on a de la redondance : c’est du RAID10″
moi : « ah… mais c’est pas du stockage redondé ça. Hmm… Bon bref, ben y’a les backups automatiques sinon ! C’est écrit sur votre site ! C’est un argument choc ça, j’aime bien le principe ! »
technicien : « oui voilà, mais vous ne les avez pas programmés »
moi : « comment ça ? … c’est le principe, en fait : si c’est automatique, y’a rien à faire. Ca se fait tout seul, ça fait un snapshot ou quelque chose du genre j’imagine. C’est automatique quoi, d’où le nom. Si y’a besoin que je programme un truc, ça s’appelle manuel. Et sur votre site, c’est bien écrit backup automatique, donc… c’est automatique. Non ? »
technicien : « ….. non… en fait, non… »
moi : « ok ok. Donc pas de stockage redondant, et pas de backups automatiques, quoi. Il faudra fouetter le stagiaire, il a écrit n’importe quoi sur votre site. Bon et vous proposez quoi concrètement, alors ? »
technicien : « le plus simple, c’est vraiment de réinstaller »
moi : « je n’ai absolument pas le temps, mais j’ai bien compris que je n’avais pas vraiment le choix du coup. Et donc pour mes données ? … Hmm non, je retire ma question. Merci monsieur, j’ai vraiment bien fait de venir chez vous, à bientôt :-) »
technicien : « voilà, bonne fin de journée ! »

Merci Gandi, c’est super ce que vous faites, j’adore :-) Et sinon chez Nuxit, y’a des backups systèmes automatiques (des vrais), de base, sur tous les serveurs dédiés. Plus des sauvegardes automatiques-à-la-Gandi (donc : à programmer) sur un FTP externe, comme chez tous les autres hébergeurs. Voilà, c’était juste pour info, au cas où vous chercheriez un vrai hébergeur…

• Le tutoriel « Learn Python in 10 minutes » (également dispo en PDF pour $2)
• « Dive Into Python » (ou le PDF), ou bien sa traduction en français
• La doc officielle (dispo également sur ce mirror si docs.python.org est down)
• « Python 2.6 Quick Reference » (ou le PDF)
• Divers tutos ici, là ou encore par là-bas

(1) : ce post a été rédigé un trolldi, je n’avais pas le choix !

C’est par ici : OWASP Appsec Tutorial Series

OWASP Appsec Tutorial Series

• On fait un peu de ménage en virant rsyslog, et on installe syslog-ng à la place. Dans la foulée on bazarde portmap, ainsi que bind9 (les DNS de QuickWeb font parfaitement l’affaire) :

apt-get install syslog-ng && dpkg --purge rsyslog
apt-get remove --purge portmap
apt-get remove --purge bind9

• On supprime openssh, et on installe le tout petit dropbear à la place :

touch /etc/ssh/sshd_not_to_be_run
apt-get install dropbear
sed -i "s/NO_START=1/NO_START=0/" /etc/default/dropbear
/etc/init.d/ssh stop && /etc/init.d/dropbear start
echo -e "PATH=/usr/bin:/bin:/usr/sbin:/sbin\nexport PATH" >> ~/.bashrc

• Voilà, on a déjà gagné quelques megs. Passons aux poids lourds… Apache en premier, qui va poliment laisser sa place à lighttpd (et son module de gestion des vhosts) :

/etc/init.d/apache2 stop
update-rc.d -f apache2 remove
apt-get remove --purge apache2
apt-get install lighttpd
mkdir -p /var/www/monitoring.monsite.fr/html
lighttpd-enable-mod simple-vhost
/etc/init.d/lighttpd force-reload

• Que serait le web sans PHP et MySQL ?

apt-get install mysql-server php5-cgi php5-mysql
cat > /etc/lighttpd/conf-enabled/10-cgi-php.conf
server.modules += ("mod_cgi")
cgi.assign = (".php" => "/usr/bin/php5-cgi")
^D
/etc/lighttpd/conf-enabled/10-simple-vhost.conf :
  simple-vhost.server-root         = "/var/www"
  simple-vhost.document-root       = "html"
/etc/init.d/lighttpd force-reload

• On va immédiatement calmer le gros apétit de MySQL :

cat > /etc/mysql/conf.d/mon_tuning.cnf
[mysqld]
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
query_cache_limit = 256K
query_cache_size = 1M
^D

• Au tour de Zabbix !

apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent
  le pass root mysql
  puis le pass db zabbix
  mysql
  puis le pass frontend zabbix
ln -s /usr/share/zabbix /var/www/monitoring.monsite.fr/html

• On customise un peu le /etc/php5/cgi/php.ini pour faire plaisir à Zabbix :

 date.timezone = Europe/Paris
 post_max_size = 16M
 max_execution_time = 300
 max_input_time = 300

• Un peu de SSL pour sécuriser le tout :

cd /etc/lighttpd/conf-available/
ln -s /etc/lighttpd/conf-available/10-ssl.conf
openssl req -new -x509 -keyout server.pem -out server.pem -days 3650 -nodes
  du bla bla pour generer le certificat... :-)
/etc/init.d/lighttpd restart

• Et voilà, secouez bien fort votre VPS, et Zabbix s’offre à vous :

https://monitoring.monsite.fr

Pour 4 petits € / mois, voilà un beau serveur de monitoring, oui ma bonne dame :-) Et rassurez vous, il reste de la RAM dispo, vous pourrez donc y installer encore quelques vhosts (puisqu’il y a du PHP/MySQL, autant se faire plaisir) :

root@quickweb:~# free -m
 total       used       free     shared    buffers     cached
Mem:           384        138        245          0          0          0
-/+ buffers/cache:        138        245
Swap:            0          0          0

XSS, XSRF, XSSI, path traversal, code execution, SQL injection, etc… :  des noms barbares qui désignent des types de failles de sécu. Si vous ne connaissez pas, ou pas bien, la question et que ça vous interpelle, Google met à disposition Gruyere (anciennement Jarlsberg). Comme son nom l’indique :-), il s’agit d’une appli web pleine de trous (de sécurité), et vous apprenez au fil des exercices à repérer et exploiter un certain nombre de failles, puis ensuite comment s’en protéger. C’est plutôt très bien fait, assez bien expliqué. Si le sujet vous intéresse et que vous n’êtes pas allergique à l’anglais, je vous le recommande vivement ! A noter également : quelques cours intéressants sur la programmation web (Google Code University), qui peuvent aider, en particulier les deux vidéos de présentation de Javascript.

Update (31/03/2011) : Je viens de tomber sur Web Security Dojo, il s’agit d’une machine virtuelle (VirtualBox ou VMware, au choix) qui contient un paquet d’outils de sécurité web (dont Gruyere) :

• OWASP’s WebGoat
• Google Gruyere
• DVWA (Damn Vulnerable Web App)
• Hacme Casino
• OWASP InsecureWebApp
• w3af
• et d’autres sites fournis par Maven Security

Et les outils classique de tout bon pentester : metasploit, burp suite, dirbuster, etc…

Update (11/05/2011) : Une liste assez complète de sites et d’outils pour « s’entrainer » : Pentesting Vulnerable Study Frameworks Complete List

$ dd if=/dev/zero of=bidon bs=1M count=1000 &
[1] 5224
$ cat /proc/5224/io
rchar: 793778451
wchar: 1587738016
syscr: 194481
syscw: 388188
read_bytes: 0
write_bytes: 795377664
cancelled_write_bytes: 0

Il s’agit de compteurs incrémentaux, un peu comme dans /proc/net/dev pour mesurer les débits sur les interfaces réseau. En faisant la différence entre deux mesures, divisé par le temps entre les deux mesures, on peut ainsi facilement obtenir les débits en lecture et écriture sur les disques du process mesuré ! Ou bien sinon, plus simple : iotop fait ça très bien. Il permet de voir quels process sont en train de tuer vos disques durs, à la manière de top pour les CPU :-)

Le principe est simple (et très Google-like) : des machines de stockage low-cost, et une duplication des données sur ces différents noeuds. Pas besoin de SAN très onéreux ou de systèmes ultra complexes : des petits serveurs bon marché avec de gros disques font parfaitement l’affaire, même pas besoin de RAID hardware, MooseFS est résistant. Les fichiers sont découpés en morceaux (appelés chunks) puis répartis sur les différents chunkservers (noeuds de stockage) : selon le paramétrage voulu pour ces fichiers, ou pour le répertoire dans lequel ils se trouvent, chaque chunk sera répliqué sur x noeuds (différents). Ainsi, la perte de l’un des noeuds sera totalement transparente pour l’utilisateur, et sans aucune perte de données !

J’ai un « petit » cluster de 12 serveurs de 4 To chacun, soit un volume brut de 48 To, qui tourne depuis plusieurs mois sans jamais avoir eu le moindre problème. Ce cluster a pourtant tout testé : le crash électrique dans la baie, le crash de plusieurs serveurs de stockage successifs, des fichiers effacés par une erreur humaine (et récupérés proprement car MooseFS gère une trash). Pas le moindre octet perdu, et les perfs sont relativement correctes. Bref, un filesystem très intéressant, qui mérite vraiment d’être plus connu, et merveilleux pour du stockage lourd où la sécurité des données est critique. La liste de diffusion compte plusieurs déçus de GlusterFS, qui revivent depuis :-), et un cluster de plusieurs péta-octets est même en cours de mise en service par une société américaine. A suivre…

Update (15/04/2011) : Dans le dernier numéro de GNU Linux Magazine France (n°137, avril 2011), vous trouverez un long article sur MooseFS.

• sur la même machine : si le disque dur crash, on perd les données et les backups… bien joué…
• sur un des nombreux sites web dédié au stockage en ligne : pourquoi pas, mais c’est cher, et il faut avoir confiance dans la société qui gère vos données.
• sur un serveur distant qui vous appartient : ouaip, mais encore faut-il avoir un autre serveur (ou un serveur dédié virtuel pas cher !)
• sur un serveur distant qui ne vous appartient pas : un collègue qui vous prête généreusement un bout de disque. Encore une fois, il faut avoir confiance en lui, vous lui confiez (l’accès à) vos données.

Bref, il n’y a pas vraiment de solution idéale : Vos données devront être stockées ailleurs, sur une machine où vous ne serez probablement pas le seul à avoir accès, et là il faut avoir confiance ! Ou pas…

Voici une solution simple : En prenant un serveur dédié virtuel (voir précédent billet) à pas cher :-), vous disposez de quelques dizaines de Go de sauvegarde pour une poignée de centimes d’euros par mois. En général, ce sera sur un serveur OpenVZ aux USA, géré par on ne sait qui, sécurisé on ne sait comment. Vous pouvez alors utiliser openssl pour chiffrer vos données à l’aide  d’un algorithme de chiffrement symétrique sur les jolis .tar.gz que vous générez (par exemple), puis les envoyer en scp vers ce VDS de backup. Dans les grandes lignes, voici la marche à suivre :

1) Générer un mot de passe sûr (secure), fiable et que vous pouvez retenir facilement, ou stocker en lui sûr. Si vous êtes en manque d’inspiration, on peut par exemple faire ceci :

$ cat /dev/urandom | tr -cd '[:graph:]' | head -c 20 > mon_pass
$ cat mon_pass; echo
V+7*Vde|th"h[=fUXc"=
$

ATTENTION : Conservez le fichier mon_pass bien au chaud, évidemment, sinon vos données ne seront pas récupérables le jour où vous en aurez besoin !

2) Générer vos fichiers de sauvegarde (disons un bon gros .tar.gz de derrière les fagots)

3) Encodage du fichier en AES-256-ECB, avec votre password :

openssl enc -aes-256-ecb -in mon_backup.tar.gz -out mon_backup.tar.gz.secure -kfile mon_pass

Le fichier mon_backup.tar.gz.secure contient la version chiffrée de vos backups, que vous pouvez maintenant laisser trainer n’importe où :-)

4) Copie du backup sécurisé vers le serveur pas/peu secure

5) En cas de catastrophe, pour décoder votre fichier de backup et en récupérer le contenu (à l’aide de votre fichier de password, que vous aurez eu l’intelligence de bien sauvegarder au chaud) :

openssl enc -d -aes-256-ecb -in mon_backup.tar.gz.secure -out mon_backup.tar.gz -kfile mon_pass

Et hop !

Sinon, deuxième possibilité, dans le même esprit : Utiliser Duplicity avec GnuPG.