Catégories
Image Systeme Web

Top 12 des sites pour télécharger des fonds d’écran

Le 24 décembre n’a jamais été une journée particulièrement productive. Alors au lieu de faire semblant de faire des choses vachement importante, pourquoi ne pas vous occuper un peu de l’objet que vous regardez plus que votre femme (ou que votre homme): je parle bien sûr de votre écran !

Voici donc une sélection de site proposant des fonds d’écran qui changeront un peu votre quotidien.

Desktopography

Une fois par an, Dektopography propose une sélection d’image mélange de nature et de numérique. La version 2010 vient de sortir. En un mot: Superbe ! Si vous découvrez ce site, je vous conseille de regarder les sélections des autres années.

Devian Art

Qui ne connait pas ce site ou les artistes numériques exposent leurs oeuvres ? Personnes depuis que le site c’est fait hacker la liste de ses comptes utilisateurs 🙂


Wlppr

Un concept assez sympa qui propose de mettre en avant un wallpaper. On peut ensuite parcourir la base de donnée de manière plus ou moins ciblé. Des images de qualitées.


Mini Tokyo

Pour les fans de manga !

4 Walled

Encore une sélection orientée manga et BD, mais pas que…

Dlan Ham

Tout un univers qui devrait plaire les fans de Miyazaki…

HD Wallpapers

Une de référence dans le domaine. Une sélection pléthorique avec des qualités HD.

Customize

Customize est un site proposant un peu tout pour configurer son écran. Notamment une section wallpaper avec une belle sélection.

Pixel Grils Presents

Des fonds d’écrans proposés par des internautes que l’on ne trouve pas ailleurs. Sympa !

Social Wallpapering

Un site social permettant de partager ses wallpapers. Quelques belles images. Notamment la dans la section dual monitor.

Interface Lift

Des images très originales avec un moteur de recherche très intuitif.

Wallbase

Mon chouchou. Un moteur de recherche au top. Une sélection d’images de qualités. Des filtres permettant de trouver rapidement ce que l’on cherche (même un section NSFW :)).

Et voilà de quoi faire une petite sélection pour 2011.

Avez vous d’autres perles dans vos bookmarks ?

Catégories
Open-source Web

Le panier du marché libre #3

Un petit panier garni libre de noël glané cette semaine sur le Web.

Profitez bien de vos familles et de vos amis !

Bonne fêtes à vous tous.

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 !

Catégories
Open-source Web

Le panier du marché libre #2

Deuxième édition des paniers du marché libre avec quelques URL glanées cette semaine sur Twitter et RSS.

  • On commence par un guide de survie si vous êtes obligé de travailler sous Windows au boulot. Ce billet vous permet d’installer des logiciels qui vous redonneront « un peu » de liberté.
  • Audio.js est une librairie en JS permettant d’insérer un player audio HTML5 dans vos sites (seulement compatible MP3).
  • Un billet un peu plus technique sur l’art et la manière de faire de l’exec() et system() root en PHP.
  • PluXml est une alternative simple et légère au CMS WordPress (on sait jamais si Microsoft rachète WordPress…).
  • Enfin un tableau comparatif des différents players video HTML5.

Faites nous partager vos découvertes de la semaine !

Catégories
Open-source Planet-libre Reseau Web

Installation et utilisation de LOIC sous GNU/Linux

Depuis que le groupe Anonymous a utilisé Low Orbit Ion Cannon (LOIC) pour attaquer un certain nombre d’entreprises ayant mis des battons dans les roues de Wikileaks et de son patron,  ce logiciel a été mis sur le feux des projecteurs.

Ce logiciel permet en un clic de souris de lancer une attaque de type Deny Of Service (DOS) sur une machine cible. Utilisé par une personne bienveillante, ce logiciel de « script kiddies » peut être utilisé pour tester la réaction d’un de ses serveur par rapport à une telle attaque et également de tester les mécanismes de sécurité associés.

Développé en C# (burk…), LOIC est disponible sous les OS Windows Xp ou supérieur. Il est bien sur possible de l’utiliser également sous GNU/Linux moyennant quelques manipulations…

Installation de LOIC sous GNU/Linux

C’est en lisant ce forum que j’ai trouvé une solution simple et élégante pour installer la dernière version de LOIC sous Ubuntu, Fedora ou Debian (et surement sur toutes distributions GNU/Linux disposant des pré-requis).

On commence par installer les logiciels suivants:

Sous Ubuntu/Debian:

sudo aptitude install git-core monodevelop

Sous Fedora (en root):

yum install git mono-devel

Ensuite on récupére un script SHELL qui va permettre: d’installer, de mettre à jour et de lancer LOIC sur votre distribution GNU/Linux:

mkdir ~loic

cd ~loic

wget https://raw.github.com/nicolargo/loicinstaller/master/loic.sh

chmod a+x loic.sh

Installation de LOIC

On lance la commande suivante:

./loic.sh install

Le script va télécharger la dernière version disponible dans le GIT puis effectuer une installation dans le répertoire ~/loic/LOIC.

Mise à jour de LOIC

On lance la commande suivante:

./loic.sh update

Le script va vérifier l’existence d’une nouvelle version disponible dans le GIT puis effectuer une installation dans le répertoire ~/loic/LOIC.

Lancement de LOIC

On passe au chose sérieuse en lançant le logiciel:

./loic.sh run

La fenêtre suivante devrait apparaitre:

Utilisation de LOIC

Attention à ne pas tester ce logiciel sur un site qui ne vous appartient pas ! En effet, le logiciel ne dispose d’aucun mécanisme pour cacher votre adresse IP et vous serez facilement repéré par le site cible. Cela serait dommage de se faire bannir par les mécanismes de filtrage de votre blog préféré 😉

Comme vous allez le voir, même mon fils de 4 ans et demi peut se servir de ce logiciel. Il suffit de (1) saisir l’URL (ou l’adresse IP) de la machine à attaquer puis (2) de cliquer sur le bouton « Lock on » puis (3) enfin sur le bouton  « IMMA CHARGIN MAH LAZER ».

 

Par défaut, les attaques sont de type flood sont lancées sur le port TCP/80 (mais il est possible de faire des attaques de type UDP ou HTTP). 10 processus sont lancés en parallèle.


La ligne de status devrait se mettre à jour pour voir la progression de l’attaque:

Que fait LOIC ?

En capturant le trafic généré par LOIC à l’aide d’un logiciel comme tshark, on peut voir qu’il génére un grand nombre de requêtes TCP dans le but de saturer la machine cible.

Avec un simple PC bureautique, j’arrive à un débit de requête de l’ordre de 4.5 Mbps. Imaginez le résultat si 1000 personnes font la même chose vers une même cible…

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

Sécuriser son blog WordPress #1

Il n’y a rien de plus rageant que de se faire pirater son blog. En plus de réduire à néant notre amour propre, cela peut avoir, dans le cas d’une indisponibilité prolongée, des impacts non négligeables sur le « saint » référencement dans gOOgle et donc sur le trafic sur votre site (je suis bien placé pour en parler…).

Après avoir détaillé l’installation d’un blog WordPress sur un serveur VPS Gandi Ubuntu Server puis optimiser ce dernier en 12 étapes, nous allons donc aborder des techniques permettant de protéger votre blog WordPress hébergé sur un serveur dédié ou virtuel (mais un bon nombre de ces techniques sont aussi applicables sur n’importe quel site Internet). Il faut garder à l’esprit que cela ne garantira en rien une protection efficace à 100%. Si une personne compétente décide de pirater votre site, il y a de fortes chances qu’elle réussisse. Par contre, ces techniques vous protégeront sûrement d’une grande majorité des attaques lancées via des « script kiddies« .

Cet article va être découpé en plusieurs billets (vous êtes en train de lire le #1):

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

Sécurisation du système d’exploitation

C’est la base de votre infrastructure. Ici, pas la place pour des systèmes d’exploitations (OS) de comique. Il faut du lourd, du sûr, du solide, du stable, du libre: c’est-à-dire une distribution GNU/Linux ou BSD.

Pour les serveurs Web, j’utilise FreeBSD ou Ubuntu Server, selon mon humeur. Comme je le répète assez souvent il vaut mieux choisir un système d’exploitation que l’on maîtrise bien. En discutant avec des “experts”, vous aurez autant de sons de cloches que d’OS…

Dans la suite de ce billet, nous travaillerons sur la sécurisation d’un serveur sous Ubuntu Server 10.04 LTS, ces méthodes sont applicables facilement sur une Debian (et toute autre distribution Debian like).

Pense bête lors de l’installation

Lors de la configuration des partitions du disque dur de votre serveur, ne tombez pas dans la facilité en faisant une partition unique qui contiendra le système, les application et vos données sur un même volume logique.

Séparer intelligemment les répertoires de son système permet de cloisonner les données et simplifie la ré-installation d’un système. Au minimum, il est conseillé de séparer au moins les partitions suivantes:

  • / (~ 5 Go)
  • /boot (~ 100 Mo)
  • /var (~ 12 Go)
  • /home (Tout l’espace restant)
  • /var/tmp (Voir plus bas)
  • /tmp (Voir plus bas)

Dans notre cas, l’idée est de ne pas stocker nos sites sur /var/www mais sur /home, qui contient tout l’espace.

Le répertoire /var, dédié principalement aux logs, pourra alors se remplir sans impacter votre arborescence principale sur / ou vos comptes sur /home.

Surveiller l’espace utilisé sur vos partition est important, une partition pleine empêcherait vos logs de s’écrire ou vos sites de fonctionner correctement. Le programme logwatch (décrit plus bas) vous fournit un récapitulatif de l’espace disque utilisé, il est donc utile pour surveiller ce point.

Utilisation de tmpfs

Sous les systèmes GNU/Linux, on a deux dossiers temporaires: /tmp et /var/tmp. Passer ces dossiers “World Writable” (c’est à dire que n’importe quel utilisateur/processus de votre système peut écrire et lire dans ces répertoires) en tmpfs (disque RAM). Il faut que votre serveur dispose d’une quantité de mémoire RAM conséquente car une partie de celle-ci sera utilisée pour stocker les fichiers temporaires.

Pour mettre en place tmpfs sur un système de fichier (/tmp dans cet exemple), éditez le fichier /etc/fstab et ajouter la ligne suivante :

tmpfs        /tmp     tmpfs        defaults,user_xattr          0    0

Je vous conseil de mettre tmpfs en place pour les répertoires /tmp, /var/tmp et /dev/shm. La rêgle pour savoir síl faut le mettre en place est « sur tous les répertoires dont le données sont volatiles ». Ainsi, /var/lock devrait en faire partie, sauf que certains programmes, mal codé, n’apprécient pas que ce dossier soit vidé.

L’idée derrière l’utilisation de la RAM est de rendre ces répertoire très rapides. Le stockage sur RAM limite aussi intrinsèquement leur taille, que le noyau gère automatiquement pour étendre ou diminuer la taille de ces partitions en fonction des besoins du système.

Mise à jour du système

C’est un des principe de base de la sécurité de votre système informatique (malheureusement aussi un des plus rébarbatif):

« Toujours avoir un système et des applications à jour. »

Pour m’aider dans cette lourde tache, j’utilise l’application cron-apt qui permet de vérifier automatiquement si des mises à jours sont disponibles. Si c’est le cas, le logiciel peut envoyer un mail et optionnellement, mettre à jour le système pour vous.

Installation de cron-apt:

sudo aptitude install cron-apt

Il faut ensuite configurer votre adresse mail dans le fichier /etc/cron-apt/config. Par défaut cron-apt s’exécute automatiquement tout les matins à 4h00.

Voici un exemple de mail envoyé:
Pour les machines sous Fedora, il existe une fonction équivalente directement dans Yum (lire ce billet pour plus d’informations).

Tuning de la sécurité

Configurer les paramètres de sécurité réseau par défaut dans le fichier  /etc/sysctl.conf.

Vous pouvez vous inspirer des billets suivants pour effectuer cette configuration:

Protection contre les « forks bombs »

Une attaque par « forks bombs » est de type DOS (Deny Of Service) qui utilise la commande système fork. Pour se protéger de telle attaque et limiter leurs impacts sur le reste du système,  il faut éditer le fichier /etc/security/limits.conf et y ajouter les lignes suivantes (en adaptant « username » à vos besoins):

username soft nproc        300

username hard nproc        350

username soft nice         0

username hard nice         0

username soft priority     5

username hard priority     5

username –    maxlogins    10

Ces limitations empêchent un utilisateur de se logguer plus de 10 fois sur la machine (en SSH notamment), de lancer plus de 350 processus simultanément (empêche les forks-bombs) et met une priorité faible a ses tâches par défaut (haute priorité < 0, normal 0, basse priorité > 0).

Source: http://www.cyberciti.biz/tips/linux-limiting-user-process.html

Firewall

Ne laisser passer que les flux réseaux utiles à l’utilisation de votre serveur par les utilisateurs (HTTP / HTTPs) et l’administration (SSH).

Concernant le protocole SSH, on lit souvent qu’il faut changer le port d’écoute du daemon SSHd (par défaut TCP/22). Mise à part le bloquage de certains scripts automatique, je ne pense pas que cette sécurité soit suffisante. En effet, un simple scan de votre machine avec Nmap permettra de retrouver facilement le port d’écoute.

Une solution plus efficace pour protéger cette porte d’entrée sur le serveur est d’utiliser la technique du “portknockers”. Avant de s’ouvrir, on doit taper à la porte de notre serveur en  envoyant une séquence de requêtes vers des ports prédéfinis. Par exemple avant de ce connecter en SSH sur le port TCP/22, il faudra envoyer “taper à la porte” des ports 2222, 3333 et 4444.

Le programme knockd permet de configurer facilement un “portknockers” sur son serveur Linux: https://help.ubuntu.com/community/PortKnocking

Fail2Ban analyse les logs de votre système et bloque automatiquement les indésirables au niveau du firewall iptables, ce qui est très efficace. Vous pouvez aussi bloquer manuellement des plages d’IPs considérées comme “malfaisantes”, il m’est arrivé de bloquer un pays entier cas de nombreux tentatives de piratage provenaient de ce site, et qu’aucun visiteur en provenance de ce pays ne viennent sur mes sites (bon c’est vrai cela fait un peu censure :)).

A installer à partir des sources:

sudo aptitude install fail2ban

Le fichier de configuration par défaut est /etc/fail2ban/jail.conf. Vous pouvez notamment y configurer les adresses IP à ignorer (par exemple l’adresse IP publique ou le nom d’hôte de votre propre box):

ignoreip = 127.0.0.1 home.mondomaine.com

Et également ajouter ou modifier les prisons (jail) pour des services spécifiques. Par exemple pour le serveur pure-ftpd:

#

# FTP servers

#


[pure-ftpd]

enabled = true

port = ftp,ftp-data,ftps,ftps-data

filter = pure-ftpd

logpath = /var/log/messages

maxretry = 6

Pour aller plus loin dans la configuration de fail2bna, vous pouvez lire ce billet.

Autres idées en vrac

  • instaurer des quota disk stricts par utilisateur (quotatool) : très utile pour éviter de bloquer tous ses sites à cause d’un script mal codé.
  • empecher le reboot par syskey /etc/inittab : intéressant mais peu utile, une personne avec un accès physique à votre serveur peut de toute façon faire à peu prêt tout ce qu’elle veut.
  • utiliser rsyslog pour envoyer les logs sur un serveur distant, sans accès de modification/suppression de logs de préférence : permet d’analyser les actions d’un pirate après détection du piratage (un pirate ne peut pas effacer toutes les traces laissées par les tentatives de piratage infructueuses). Un peu cher à mettre en place pour un site perso.

Les commentaires sont ouverts pour nous faire partager votre expérience dans la sécurisation de vos sites Internet.

Sources ayant servies à la rédaction de ce billet:

Catégories
Open-source Web

Le panier du marché libre #1

Nouvelle rubrique pour partager avec vous quelques URL ajoutées cette semaine dans mon bookmarks:

Et vous ? Une URL à partager pour cette semaine ?

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

# http://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: