Étiquette : plugin

Catégories
Nagios Open-source Systeme

CheckGlances ou la rencontre de Glances et de Nagios

Ce billet a comme objectif de présenter mon dernier développement qui est un plugin Nagios|Shinken pour récupérer des informations systèmes sur des machines hôtes faisant tourner Glances.

Je vous présente donc CheckGlances.py.

Quoi ?

CheckGlances est un plugin compatible avec Nagios et ses forks (Icinga, Centreon…) / ré-implémentations (Shinken). Il respecte au maximum les spécifications données par Nagios.

Développé en Python, il permet d’aller récupérer les statistiques d’un serveur Glances (c’est à dire un glances lancée avec l’option -s) via un lien XML RCP sur HTTP.

Pourquoi ?

Le principal avantage de cette solution est que Glances se base sur une librairie Python nommé PsUtil (pour la récupération des statistiques) et qui a le bon goût d’être multi-plateforme. On a donc un plugin permettant de manière unique de récupérer les statistiques sur des hôtes GNU/Linux, BSD, Mac OS ou Windows.

Un autre avantage est l’ouverture de ce système à des statistiques plus fines. Bien que cette première version se limite à CPU, charge, mémoire et swap. CheckGlances, pourra à terme remonter vers votre serveur de supervision toutes les données traitées par Glances (débit des interfaces réseaux, disk IO, processus, température…).

Comment ?

Je ne vais pas copier/coller la documentation qui se trouve sur le site officiel mais l’installation se fait comme pour n’importe quel autre plugin et dépend donc de votre serveur de supervision et de sa configuration.

Il est également possible de tester le plugin en ligne de commande.

Voici quelques exemples (en partant sur Glances server est lancé sur votre machine locale):

CPU

./checkglances.py -H localhost -s cpu
CPU consumption: 2.96% | 'percent'=2.96 'kernel'=0.73 'iowait'=0.20 'idle'=97.04 'user'=1.89 'irq'=0.00 'nice'=0.00

 LOAD

./checkglances.py -H localhost -s load
LOAD last 5 minutes: 0.22% | 'min1'=0.13 'min5'=0.22 'min15'=0.29

MEM

./checkglances.py -H localhost -s mem
MEM consumption: 59.50% | 'used'=3411509248.00 'cache'=1071792128.00 'total'=3934547968.00 'percent'=59.50 'free'=523038720.00

SWAP 

./checkglances.py -H localhost -s swap
SWAP consumption: 3.70% | 'used'=150159360.00 'total'=4080005120.00 'percent'=3.70 'free'=3929845760.00

Le futur…

Il reste encore pas mal de travail du coté de Glances pour proposer une interface XML RCP industrialisable. En effet, outre le fait que seules quelques statistiques sont remontées, il n’y a pour l’instant pas de sécurité. C’est donc une solution qui est utilisable sur un réseau local mais pas dans une architecture Internet. Mais promis, l’authentification client / server est prévue dans la prochaine version de Glances.

Comme toujours, je suis preneur de toutes les remarques, questions et retour de test sur ce nouvel outil.

 

Catégories
Open-source Planet-libre Reseau

Suivi graphique des attaques DDOS avec Munin

Les attaques DDOS sont une véritable plaie pour les sites Internet. Même pour des sites à forte audience et donc dimensionnés au niveau architecture système et réseau pour absorber ces aléas, il est important de surveiller de prêt ces attaques. Nous avions déjà abordé ce sujet ensemble en mettant en place une alerte Nagios sur attaque DDOS. Nous allons ici compléter cette supervision en apportant un suivi graphique de ces attaques en utilisant un plugin spécifique pour Munin.

Installation de Munin

Il suffit de vous reporter au billet que j’avais écrit sur le sujet il y a quelques mois. Le plugin qui va se charger de la détection des attaques DDOS doit être installé sur chacun des noeuds (« Munin node ») à surveiller.

Principe du Plugin ddos_

Ce plugin se base sur le même principe que le plugin Nagios. Il va lire le nombre de connexions de type SYN_RECV ouvertes et les renvoyer au noeud Munin maître pour que ce dernier stocke l’information dans une base RRD et l’affiche à la demande dans un page Web.

Le plugin est disponible sur mon GitHub (il est donc possible de l’améliorer et d’en faire profiter la communauté).

Si vous êtes intéressé par l’écriture de vos propres plugins pour Munin, le plus simple est de commencer par la lecture de la documentation officielle.

Revenons à notre plugin ddos_.

Pour l’installer sur un noeud, la procédure à suivre est la suivante:

cd /tmp
wget https://raw.github.com/nicolargo/muninplugins/master/ddos_
sudo munin-node-configure --shell
sudo cp ddos_ /usr/share/munin/plugins/
sudo chmod a+x /usr/share/munin/plugins/ddos_
sudo munin-node-configure --shell
sudo ln -s /usr/share/munin/plugins/ddos_ /etc/munin/plugins/ddos_
sudo service munin-node restart

On peut vérifier que le plugin est bien actif en saisissant la commande:

sudo munin-node-configure | grep ddos
ddos_                      | yes  |

Il faut ensuite attendre quelques heures pour voir apparaître le graphe au niveau de votre serveur Munin.

Par défaut, le plugin est configuré pour afficher les valeurs en WARNING quand le nombre de SYN_RECV dépasse le seuil des 50 et en CRITICAL au dessus de 70 (vous pouvez bien sûr changer ces valeurs dans le munin.conf).

C’est pas beau Munin 🙂 ?

Catégories
Blog Open-source Planet-libre Web

Configuration Varnish+Nginx pour WordPress

Vu le nombre d’articles sur l’utilisation du serveur de cache Varnish pour une utilisation avec le CMS WordPress, force est de constater qu’il est difficile de faire le tri pour en sortir LA configuration. Dans ce billet, je vais donc vous présenter ma configuration qui tourne depuis quelques jours sur le serveur hébergeant le Blog de Nicolargo.

Ce serveur sous Debian Squeeze est composé de:

  • Varnish
  • Nginx avec le module PHP-FPM
  • WordPress avec le plugin « Varnish HTTP Purge »

Je maintiendrai à jour une configuration stable (avec des commentaire en Anglais) de cette pile HTTP dans le GIT suivant:

https://github.com/nicolargo/varnish-nginx-wordpress

Une configuration pour quoi faire ?

Le principal objectif est d’optimiser votre serveur pour supporter une montée en charge pouvant aller jusqu’à plusieurs centaines de requêtes HTTP par seconde. C’est à dire une configuration adaptée pour une grande majorité des blogs personnels à fort trafic.

Avec une pile HTTP classique (c’est à dire sans cache), toutes les requêtes vers WordPress vont entraîner:

  • l’exécution d’un script PHP générant en sortie un fichier HTML
  • des requêtes vers la base de donnée MySQL
  • la lecture sur disque des éléments statiques de la page (fichiers CSS, JS, images…)

Lors de ces premières requêtes il est important d’avoir un thème bien optimisé. Le plugin W3 Total Cache peut vous aider dans cette démarche en optimisant les fichiers CSS (compression / regroupement) et en mettant dans un cache certaine requêtes SQL. Il faut également noter qu’avec un système de cache externe comme Varnish, la première requête va également engendrer ces actions mais pas les suivantes.

Les deux premiers points sont fortement consommateurs de ressources matérielles (CPU et mémoire). Ainsi, la charge globale de votre serveur augmente avec le nombre de requêtes simultanées. Arrivé à saturation, votre serveur ne peut plus répondre correctement aux requêtes et le temps de chargement de vos pages commencent à augmenter jusqu’à arriver au point ou il n’est plus capable de rien faire.

L’utilisation d’un cache comme Varnish permet de fournir directement les fichier HTML au navigateur client sans passer par l’exécution du script PHP et les requêtes MySQL.

Concernant le troisième point, le problème vient de la relative lenteur des accès disques (notamment si vous êtes sur un hébergement de type virtuel (aka) VPS).

Une optimisation possible est de lire les objets statiques non pas depuis le disque mais directement depuis un cache mis en RAM. Deux solutions sont possibles, soit faire effectuer cette tache par Varnish (que l’on peut optimiser en utilisant un disque tmpfs pour le répertoire de travail de Varnish) qui en plus des pages HTML va également « cacher » les objets statiques, soit laisser NGinx gérer cela directement, notamment en utilisant une brique comme Memcached. Si les deux sont comparables en terme de performances pures (c’est à dire la capacité à supporter un grand nombre de requêtes simultanées), il semble que NGinx est une consommation CPU moins importante.

Avant de cacher il faut savoir purger

Les lecteurs attentifs ont déjà dû noter qu’il y avait un trou dans la raquette dans l’exposé précédant. En effet, par définition, WordPress génère des sites dynamiques ou les articles peuvent évoluer, des commentaires peuvent être ajoutés. Il faut donc un mécanisme pour prévenir Varnish de mettre à jour son cache quand certaines actions sont faites sur le blog.

Heureusement pour nous, WordPress dispose d’un grand nombre de plugins permettant d’automatiser cette tache. W3 Total Cache, déjà mentionné dans le premier chapitre dispose d’une option pour  communiquer avec Varnish. Il semble cependant qu’il y est des problèmes quand l’on configure ce plugin avec plusieurs serveurs Varnish (pour faire du partage de charge). Je conseille donc l’utilisation d’un plugin ne faisant que la tache de purge:  Varnish HTTP Purge.

Il faut donc désactiver la fonction de purge Varnish dans W3 Total Cache (si ce dernier est installé):

puis activer le plugin Varnish HTTP Purge:

On passe aux résultats

Pour avoir un « test bed » stable, j’ai installé les briques sur une machine dédiée sous Debian Squeeze. J’ai ensuite rédigé un billet de test comprenant du texte et 3 images.

Test de montée en charge locale avec Apache Bench

Dans un premier temps j’ai utilisé l’utilitaire Apache Bench (utilitaire ab) qui permet de simuler en local (c’est à dire sans les contraintes réseau) un grand nombre de requêtes simultanées sur l’URL du billet de test.

Sans Varnish / Sans W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 20.45 [#/sec] (mean)

[/cce]

=> CPU proche de 95% pendant le test.

Sans Varnish / Avec W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 232.62 [#/sec] (mean)

[/cce]

=> CPU proche de 85% pendant le test.

On note une augmentation des performances mais la charge CPU reste forte. Les processus PHP-FPM sont nombreux.

Avec Varnish / Sans W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 8001.76 [#/sec] (mean)

[/cce]

=> CPU proche de 30% pendant le test.

Le gain est impressionnant par rapport à la configuration sans Varnish. On atteint un nombre de requêtes par seconde très important (> 8000 en moyenne) avec une marge CPU ne dépassant pas les 35% !

Avec Varnish / Avec W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 8018.47 [#/sec] (mean)

[/cce]

=> CPU proche de 30% pendant le test.

Comme on n’a pas ou peu de gain supplémentaire en utilisant W3 Total Cache en plus de Varnish. J’ai donc décidé de ne plus utilisé W3 Total Cache sur mon blog WordPress. Il sera remplacé par « Varnish HTTP Purge » pour la gestion des purges de Varnish et « WP Minify » pour la réduction automatique des fichier CSS et JavaScript.

Test de montée en charge online avec Blitz.io

Si vous ne connaissez pas le service Blitz.io, je vous conseille la lecture du très bon billet de Romain sur le sujet.

J’ai utilisé la commande « rush » suivante:

[cce]

–timeout 5000 –region ireland –pattern 1-250:60 http://blogtest.nicolargo.com/2011/09/lorem.html

[/cce]

NGinx seul:

A partir de 50 utilisateurs, le temps de chargement des pages commence à augmenter pour arriver au timeout (limité à 5 secondes pour les tests chez Blitz.io) vers 120 utilisateurs.

NGinx avec Varnish:

Dans cette configuration, je ne rencontre aucune chute de performance avec 250 utilisateurs simultanés.

Grâce à Romain (encore lui) j’ai pu lancer sur le Blog de Nicolargo (Varnish + Nginx) un test avec 500 utilisateurs simultanés (par défaut Blitz.io est limité à 250).

Voici le résultat sur le Blog de Nicolargo:

Pas de problème jusqu’à 500 utilisateurs simultanés !!!

Test des purges

Pour valider que le plugin « Varnish HTTP Purge » fonctionnaite bien j’ai effectué les taches suivantes en vérifiant que la page était bien mise à jour pour un lecteur lambda:

  • Modification d’un billet existant
  • Suppression d’un billet existant
  • Ajout d’un commentaire
  • Modification d’un commentaire
  • Suppression d’un commentaire

Tous les tests ont été concluant.

Conclusion

Le couple Varnish + Nginx est donc une des pile que l’on peut utiliser pour obtenir un blog performant et résistant à une montée en charge bien supérieure aux nombres maximum de visiteurs sur la plupart des sites Internet. Ce n’est bien pas la seule solution et il existe sûrement des piles encore plus optimisé (notamment au niveau statique avec un serveur comme G-WAN), mais il est de mon point de vu, celui qui offre le meilleur ratio stabilité/sécurité/performance.

Pour suivre l’activité de la configuration étudiée dans ce billet, je vous conseille de vous abonnez au projet GitHub.

Quelques unes des sources de ce billet:

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

WordPress et le trop plein de fichiers sess_*

Hier, plusieurs lecteurs (merci à eux :)) m’ont signalés que le message suivant s’affichait en haut de mon blog (sous WordPress 3.1.3):

Warning: session_start() [function.session-start]: open(/var/lib/php5/sess_7cad11067bb359c89ee47b9e692e47bf, O_RDWR) failed: No space left on device (28) in/www/wp-content/plugins/twitconnect/twitconnect.php on line 95

Ce message n’apparaissait que pour les lecteurs non authentifiés et uniquement sur certaines pages. Dans une premier temps j’ai donc décidé de désactivé le plugin incriminé dans le message d’erreur (TwitConnect qui permet de s’authentifier sur le blog avec son compte Twitter). J’ai ensuite regarder l’espace disque de mon serveur sans voir de problème. C’est en allant regarder les fichiers dans le répertoire /var/lib/php5 que j’ai commencer à comprendre pourquoi le plugin en question n’arrivait plus à générer de fichiers de sessions PHP (les fameux fichier sess_*). Il y avait en effet plus de 200.000 fichiers de ce type dans ce répertoire. On arrivait donc en limite maximale du nombre de fichiers par sous répertoire sous GNU/Linux en ext3.

Le problème vient sûrement d’un des plugins que j’utilise qui doit créer ces fichiers de sessions sans jamais les purger. Je suspecte (sans avoi de confirmation) le plugin TwitConnect et j’ai donc ouvert un incident sur le forum officiel du plugin.

Pour ne plus avoir de mauvaises surprises dans le futur, j’ai donc mis en place dans la crontab root journalière une commande qui va effacer les fichiers de sessions de plus de deux jours:

find /var/lib/php5/ -type f -atime +2 -name ‘sess_*’ -exec rm -f {} \;

Si vous utilisez également le plugin WordPress TwitConnect, je vous conseille donc de jeter un oeil sur ce répertoire et le nombre de fichiers sess_*.

Pour obtenir le nombre de fichier dans ce répertoire il suffit de saisir la commande suivante:

sudo ls -l /var/lib/php5/ | wc -l

En journée (après la purge de la nuit) je tourne autour des 45.000 fichiers (environ 25 nouveaux fichiers par minutes, mais cela dépend du nombre de visites non authentifiées sur votre blog…).

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

Sécuriser son blog WordPress #3

WordPress n’a pas forcement bonne presse au niveau de la sécurité. Le coeur PHP du moteur WordPress est pourtant surveillé de très près et les corrections des failles sont assez rapides (voir par  exemple la publication de la version 3.0.4).

Par contre les plugins, qui sont un avantage indéniable de WordPress par rapport aux autres CMS, sont également un talon d’Achille… En effet, WordPress dispose d’une base de plugins impressionnante (plus de 12.700 au moment de l’écriture de ce billet) dont les développeurs sont plus ou moins sensibilisés à la problématique de la sécurité… Ajouter des plugins à votre blog, c’est multiplier les risques au niveau de la sécurité.

Dans ce billet, nous allons voir comment installer puis configurer WordPress pour compliquer la tache des personnes voulant attaquer votre blog.

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

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

Partir sur de bonnes bases

Nous allons détailler l’installation, la configuration initiale puis la gestion des mises à jours de WordPress.

    Installation de WordPress

    Personnellement j’utilise sur mon serveur deux versions de WordPress en parallèle.

    La première est celle du blog « de production » (celui que vous êtes en train de lire) utilise la version stable SVN (c’est à dire la 3.0.4 au jour d’aujourd’hui). J’utilise la commande suivante pour effectuer l’installation (dans le répertoire racine de mon serveur Web: /var/www/blog):

    svn co http://core.svn.wordpress.org/branches/3.0/

    La seconde, dite « de validation » me sert pour tester mon blog (thème et plugins) sur les futures versions de WordPress (3.1 par exemple). Elle n’est pas publique, seul les administrateurs peuvent y accéder. Pour installer cette version de WordPress, j’utilise la commande suivante dans un deuxième répertoire de mon serveur Web (/var/www/blogfutur):

    svn co http://core.svn.wordpress.org/trunk/

    Avant de suivre la fameuse installation en 5 minutes de WordPress, je vous conseille de changer le préfixe des tables MySQL en éditant la ligne suivante dans votre fichier de configuration wp-config.php et en remplacant wp_ par une chaine aléatoire (par exemple apvbty_):

    $table_prefix  = ‘apvbty_’;

    Attention, cette manipulation est à faire seulement sur un nouveau blog. En effet, si vous avez déjà une base de donnée SQL existante il faut d’abord changer le nom du préfixe des tables dans MySQL (voir hack en fin de billet) sous peine de ne plus pouvoir accéder à vos données.

    Une fois l’installation de WordPress finalisée, nous allons commencer par fixer les droits au niveau des fichiers dans ces répertoires. En partant sur l’hypothèse ou votre serveur Web tourne sous l’utilisateur www-data et dans le répertoire /var/www/blog, j’utilise les commandes suivantes:

    chown -R www-data:www-data /var/www/blog

    find /var/www/blog -type d -exec chmod 755 {} \;

    find /var/www/blog -type f -exec chmod 644 {} \;

    chmod 640 /var/www/blog/wp-config.php

    find /var/www/blog/wp-content/themes -type d -exec chmod 775 {} \;

    find /var/www/blog/wp-content/themes -type f -exec chmod 664 {} \;

    Pour vous simplifier la vie, je vous conseille de mettre ces commandes dans un script shell afin de pourvoir rapidement les appliquer sur votre arborescence.

    Mise à jour de WordPress

    Comme nous l’avons vu, les développeurs de WordPress sont assez réactifs sur la correction des failles de sécurité. Encore faut-il que vous pensiez à mettre à jour votre instance de WordPress…

    J’utilise un script shell pour mettre à jour WordPress à partir de SVN:

    #!/bin/bash

    # Simple script pour mettre a jour WordPress

    # Test que le script est lance en root

    if [ $EUID -ne 0 ]; then

    echo « Le script doit être lancé en root: # sudo $0″ 1>&2

    exit 1

    fi

    WPPATH= »/var/www/blog »

    echo « 1) Mise a jour de WordPress »

    cd $WPPATH 2>&1 /dev/null

    CURRENTVERSION=`svn info | grep « Revision:  » | awk ‘{ print $2 }’`

    svn update

    rm $WPPATH/wp-admin/install.php

    cd – 2>&1 /dev/null

    echo « 2) Verification des droits des fichiers »

    chown -R www-data:www-data $WPPATH

    find $WPPATH -type d -exec chmod 755 {} \;

    find $WPPATH -type f -exec chmod 644 {} \;

    chmod 640 $WPPATH/wp-config.php

    find $WPPATH/wp-content/themes -type d -exec chmod 775 {} \;

    find $WPPATH/wp-content/themes -type f -exec chmod 664 {} \;

    echo « 3) Fin de la mise a jour »

    echo « En cas de pb: svn update -r$CURRENTVERSION »

    Il est possible de lancer ce script toutes les nuits (par exemple par crontab) pour éviter de se retrouver avec un blog hacké quand vous partez en congés…

    Le .htaccess

    Ce fichier qui doit se trouver à la racine de votre site Web, contient des entrées utiles à la sécurité de votre site. Le mien commence par:

    # MAIN

    RewriteEngine On

    ServerSignature Off

    Options All -Indexes

    Options +FollowSymLinks


    # SVN protect

    RewriteRule ^(.*/)?\.svn/ – [F,L]


    # Secure .htaccess

    <Files .htaccess>

    Order Allow,Deny

    Deny from all

    </Files>


    # Secure wp-config.php

    <Files wp-config.php>

    Order Deny,Allow

    Deny from all

    </Files>


    # FILTER REQUEST

    <IfModule mod_rewrite.c>

    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    </IfModule>

    Certains plugins ajoutent pas mal de chose dans ce fichier (notamment W3 Total Cache, le plugin d’optimisation des performances que j’ai abordé dans ce billet).

    Un peu de bon sens…

    Vous avez donc entre les mains une installation toute propre et sécurisée de WordPress, c’est normalement à partir de ce moment là que les choses se gâtent…

    On commence par l’erreur de base: ne pas utiliser un mot de passe « strong » pour le compte admin. Encore mieux, créer un nouveau compte administrateur et supprimer le compte admin par défaut.

    L’installation des plugins apportent également son lot de failles de sécurité. C’est là qu’il faut se faire violence et n’installer que les plugins indispensables au bon fonctionnement de votre blog. Il faut également veiller à mettre à jour régulièrement vos plugins (l’interface d’administration de WordPress permet de faire cela très simplement).

    Enfin vos thèmes peuvent également fragiliser votre blog en insérant des codes PHP ou JS. Si vous avez les compétences il faut faire un audit de votre thème ou au minimum utiliser des thèmes connus et validés.

    Des plugins pour la sécurité

    Parmis ces plugins, j’en utile trois dédiés à la sécurisation:

    • Secure WordPress permet d’automatiser certaines actions pour sécuriser votre blog.

    • WordPress File Monitor: Surveille les fichiers du moteur WordPress et vous alerte (par mail et/ou directement dans l’interface d’administration de WordPress) en cas de modification.
    • On peut également citer WordPress Security Scan qui permet de faire un audit de votre blog en testant notamment les droits de vos fichiers, les mots de passes, la base de données…

    Quelques hacks en bonus

    Compliquer la tache des attaques par force brute en supprimant l’indicateur (« mauvais mot de passe ») lors d’une tentative de connexion à l’interface d’administration. Il faut juste ajouter la ligne suivante à votre fichier functions.php (thème):

    add_filter(‘login_errors’, create_function(‘$a’, « return null; »));

    Si vous avez une base de données MySQL existante avec le préfixe par défaut (wp_) et que vous souhaitez le changer, il est possible de faire celà directement à la main par une requête MySQL ou alors plus simplement en utilisant le plugin WP-Security-Scan.

    Tester votre WordPress

    Pour tester la sécurité de votre blog, rien ne vaut une simulation d’attaque. Pour celà vous pouvez utiliser le logiciel libre Nikto.

    On commence par installer Nikto sur un PC client sous Ubuntu (qui va simuler l’attaque):

    sudo aptitude install nikto

    Puis on lance le test (remplacer URL par l’URL de votre blog WordPress):

    nikto -h URL

    Le rapport devrait ensuite s’afficher.

    Sources:

    Catégories
    Nagios Open-source Planet-libre Reseau

    Détection des attaques DDOS avec Nagios

    Les attaques DDOS sont sous le feu de la rampe (et des médias) depuis l’affaire Wikileaks.

    C’est une attaque assez difficile à détecter car contrairement à des attaques plus « classiques », elle se base sur le fait d’inonder la machine cible de requêtes venant d’un nombre important de machines zombies (c’est à dire infecté par un programme qui va lancer une attaque).

    Nous allons dans ce billet voir comment utiliser Nagios pour envoyer des alertes en cas de détection d’une attaque de type DDOS SYN Flood.

    Pour cela j’ai développé (sous licnce GPL v3) un plugin Nagios disponible à l’adresse suivante:

    https://raw.github.com/nicolargo/nagiosautoinstall/master/check_ddos.pl

    Installation du script

    Il faut disposer d’un serveur Nagios correctement configuré. Puis exécuter les commandes suivantes:

    cd /usr/local/nagios/libexec

    sudo rm -f check_ddos.pl

    wget https://raw.github.com/nicolargo/nagiosautoinstall/master/check_ddos.pl

    chmod a+rx check_ddos.pl

    sudo chown nagios:nagios check_ddos.pl

    Test du script:

    ./check_ddos.pl -w 50 -c 60

    No DDOS attack detected (5/50)

    Configuration de Nagios

    Pour ajouter un service de détection DDOS SYN Flood sur la machine locale (en clair pour vérifier les attaques DDOS vers le serveur hébergeant Nagios), il faut dans un premier temps éditer le fichier commands.cfg (par défaut dans le répertoire /usr/local/nagios/etc/objects) pour ajouter la nouvelle commande de detection DDOS SYN Flood:

    # check_ddos

    define command{

    command_name check_ddos

    command_line $USER1$/check_ddos.pl -w $ARG1$ -c $ARG2$

    }

    Puis il faut éditer le fichier localhost.cfg (qui se trouve également dans le répertoire /usr/local/nagios/etc/objects):

    # Define a DDOS SYN Flood detection service

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

    # Warning: >50 SYN_RECV

    # Critical: >70 SYN_RECV

    define service{

    use local-service

    host_name bilbo

    service_description DDOS SYN Flood detect

    check_command check_ddos!50!70

    }

    Nous venons ainsi de définir un service qui va émettre une alerte Warning quand le serveur aura plus de 50 connexions de type SYN_RECV ouvertes (plus de 70 pour une alerte Critical). Ces chiffrent sont bien sur à adapter selon les serveurs…

    En bonus, si une alerte est généré, le plugin affiche le TOP 10 des adresses IP des machines zombies (pratique pour les bloquer avec des règles de Firewall Iptables).

    Si vous souhaitez surveiller les attaques DDOS SYN Flood sur une autre machine, il faut utiliser le plugin NRPE qui va faire l’interface entre le serveur Nagios et le serveur à superviser.

    Sources pour la rédaction de ce billet:

    Catégories
    Nagios Open-source

    Nouvelle version 1.4.15 pour les plugins Nagios

    Nagios plugins

    Nagios, l’outil de supervision libre, se base sur un système de plugin pour surveiller les éléments de votre réseau. Une nouvelle version (1.4.15) vient d’être mise à disposition (voir la liste des nouveautés ici).

    Pour mettre à jour votre serveur, deux solutions:

    Dans ce deuxième cas, il faut suivre les étapes suivantes:

    Récupération du script

    On lance la commande suivante pour télécharger le script sur son serveur et le rendre exécutable:

    [shell]

    wget http://svn.nicolargo.com/nagiosautoinstall/trunk/nagiospluginsautoupdate-ubuntu.sh

    chmod a+x nagiospluginsautoupdate-ubuntu.sh

    [/shell]

    PS: vous pouvez télécharger le script directement par l’URL suivante:

    http://svn.nicolargo.com/nagiosautoinstall/trunk/nagiospluginsautoupdate-ubuntu.sh

    Lancement du script

    Il suffit ensuite de lancer le script et de répondre aux questions posées par le système:

    [shell]
    sudo ./nagiospluginsautoupdate-ubuntu.sh
    [/shell]

    Et si la mise à jour se passe mal ?

    Le script archive la configuration n-1, il suffit donc d’ouvrir un terminal et de saisir les commandes suivantes pour revenir dans l’ancienne version:

    [shell]
    cd /
    sudo tar zxvf /tmp/nagiosplugins-backup.tgz
    [/shell]

    Informations sur la mise à jour

    Si tout est ok, le message suivant devrait s’afficher:

    Nagios Plugins version   1.4.15

    Bonne upgrade !

    Catégories
    Open-source Web

    7 extensions indispensables pour Chromium

    1- AdBlock+

    Enfin un vrai bloqueur de publicité pour Chromium !

    Page du plugin

    Installation du plugin

    2- Xmarks

    Vous avez plusieurs PC avec des navigateurs différents ? Xmarks permet de synchroniser la configuration de vos navigateurs (Chrome, IE, Safari ou Firefox).

    Page du plugin (en bêta, il faut s’inscrire avant de pourvoir télécharger le plugin)

    3- Who is checker

    Ajoute un petit icone permettant d’avoir des informations sur un site Web

    Page du plugin

    Installation du plugin

    4- YouTube Downloader

    Sauvegarder les vidéos YouTube en local sur votre disque en un seul click !

    Page du plugin

    Installation du plugin

    5- iMacro

    Cette extension permet de mémoriser une série d’action sur une page Web et de la rejouer à la demande. Très utile lors du développement de site Web…

    Page du Plugin

    Installation du plugin

    6- SmoothScroll

    Vous trouver le scroll de page trop agressif, alors ce plugin vous propose de le configurer aux petits oignons…

    Page du plugin

    Installation du plugin

    7- TweetPage

    Vous venez de découvrir un site intéressant, alors ce plugin vous permet d’en tweeter l’adresse sur votre compte Twitter.

    Page du plugin

    Installation du plugin

    Catégories
    Open-source Systeme

    Accélérer Firefox sous GNU/Linux

    Depuis la migration de mon navigateur Internet favori vers la version 3.5, j’ai constaté un temps de latence assez important lors de l’ouverture d’un nouvel onglet. La cause de ce délais est l’augmentation de la taille de la base de données interne utilisé par Firefox pour gérer vos préférences (c’est une base MySQL Sqlite). Voici donc un petit plugin bien pratique fonctionnant sous GNU/Linux, Windows et Mac OS OS qui a pour fonction de « nettoyer » régulièrement cette base de données.

    Ce plugin s’appelle Vacuum Places Improved. Une fois installé, il fera le travail automatiquement si vous le configurez de la manière suivante:

    Un bon petit plugin de plus à installer sur votre système !
    Catégories
    Blog Developpement Open-source

    Adsense-deluxe pour WordPress 2.8.1+

    Si comme moi, vous utilisez le plugin Adsense-deluxe pour gérer les espaces publicitaires de votre blog, vous avez eu la désagréable surprise de tomber sur le message suivant suite à une migration de votre blog vers la version 2.8.1 (ou supérieure) de WordPress:

    “You do not have sufficient permissions to access this page”

    Cela vient d’un problème de développement de certains plugins (dont Adsense-deluxe qui ne semble plus maintenu par son éditeur). Pour résoudre le problème et refaire fonctionner ce trsè bon plugin avec les dernières versions de WordPress, il suffit changer une ligne de code dans le plugin (remplacer l’appel de la fonction admin_head par admin_menu). Pour vous simplifier la tache,  j’ai modifié le plugin pour vous, il ne vous reste plus qu’a télécharger la version compatible du plugin ici (fichier ZIP à dézipper dans le sous répertoire plugin de votre blog WordPress):


    Adsense-deluxe for WP 2.8.1+

    PS: votre configuration ne sera pas effacée 😉