e-grisel.net

10 ans du HOG Geneva Chapter West Switzerland

etienne — Thu, 08 Sep 2011 18:15:22 +0000

Cette année, le HOG (Harley Owner Group) Geneva Chapter West Switzerland fêtait ses 10 ans d’existence !!

De magnifiques Harleys, une bonne ambiance et un temps agréable, il n’en fallait pas plus pour que la journée soit exceptionnelle

Retrouvez toutes mes photos sur GaleriesPhotos.ch.

Autocross de Novalles 2011

etienne — Tue, 23 Aug 2011 18:48:33 +0000

Ça y est, pour la 13ème année consécutive l’autocross de Novalles s’est déroulé ce samedi 20 août 2011 entre Novalles et Fontaines. Encore une fois le succès fut au rendez-vous, avec une grande quantité de véhicules de tous genres pour un spectacle magnifique, aussi bien pour les petits que pour les grands !

Si vous n’avez pas eu la chance de pouvoir assister ou participer à cette magnifique journée ou si vous y étiez et que vous voulez revivre les meilleurs moments de la journée, les photos officielles sont déjà disponibles sur GaleriesPhotos.ch !

Et pour la première année, un DVD de ces mêmes photos est aussi disponible ! Pour le commander, rendez-vous sur mon site : Etienne Grisel, photographe

Serveur dédié – Apache, PHP, MySQL et phpMyAdmin

etienne — Tue, 26 Oct 2010 15:30:04 +0000

Maintenant que la base de notre serveur est en place, nous allons nous atteler à la mise en place des outils nécessaire au bon fonctionnement de nos sites web.

Pour ce faire, nous allons utiliser les programmes suivants :

le serveur web Apache
le serveur de bases de données MySQL
le moteur de scripts PHP
et le gestionnaire de bases de données MySQL, phpMyAdmin

L’installation des 3 premiers programmes peut se faire en une seule ligne de commande :
[root@serveur:~]# apt-get install apache2 mysql-server libapache2-mod-php5 php5-curl php5-gd php5-mysql

Il ne nous reste plus qu’à configurer ces programmes.

Configuration d’Apache

La configuration par défaut proposée par Debian est presque parfaite et il n’y a à mon avis qu’une seule modification à effectuer dans le fichier /etc/apache2/conf.d/security :
ServerSignature Offafin d’éviter que les versions d’Apache, de PHP et de Linux ne soient affichées sur les pages d’erreurs de nos sites.

Avant de nous attaquer à la configuration des hôtes virtuels pour chaque site que nous hébergerons, modifions légèrement la page d’accueil de l’hôte par défaut, qui sera affichée pour chaque site redirigé sur notre serveur dont nous n’aurons pas encore défini l’hôte virtuel. Ainsi nous pourrons avoir un message d’erreur personnalisé au lieu du simple « It works! » affiché par défaut.

Commençons par renommer le fichier /var/www/index.html en /var/www/index.php :
[root@serveur:~]# mv /var/www/index.html /var/www/index.php puis on l’édite :
[root@serveur:~]# vim /var/www/index.php et on remplace le contenu actuel par le suivant :
<?php echo $_SERVER['HTTP_HOST']; ?>



est actuellement en cours de construction.


Merci de revenir plus tard.

Ainsi la page par défaut d’un site pas encore configuré affichera un message du type « www.mondomaine.ch est actuellement en cours de construction. Merci de revenir plus tard. » où www.mondomaine.ch est automatiquement remplacé par le nom du site demandé.

Ceci étant fait, passons à la configuration des hôtes virtuels de chacun des sites que nous hébergeons. Créons tout d’abord le répertoire qui contiendra tous nos sites ainsi qu’un sous-répertoire par site :
[root@serveur:~]# mkdir /home/www [root@serveur:~]# mkdir /home/www/mondomaine.ch [root@serveur:~]# mkdir /home/www/monautresite.ch [root@serveur:~]# chown -R www-data:www-data /home/www/ La dernière commande permet de définir le propriétaire de tous ces dossiers à www-data, qui est l’utilisateur Apache, afin qu’il puisse accéder sans problème à nos dossiers.

Comme vous pouvez le voir, j’ai créé ces dossiers dans le répertoire /home, car comme le montre la commande df -h, le répertoire /home est sur une partition séparée et bien plus grande que le reste, ainsi nous ne risquons pas de surcharger notre partition de base avec nos sites :
[root@serveur:~]# df -h /dev/sda1 5.0G 826M 4.0G 18% / tmpfs 984M 0 984M 0% /lib/init/rw udev 10M 2.7M 7.4M 27% /dev tmpfs 984M 0 984M 0% /dev/shm /dev/sda2 226G 209M 215G 1% /home

Dirigeons-nous maintenant dans le répertoire /etc/apache2/sites-available/ pour y configurer notre premier hôte virtuel. Nous créons le fichier de configuration au nom de notre site :
[root@serveur:/etc/apache2/sites-available]# vim mondomaine.ch et ajoutons-y les instructions suivantes :
ServerName www.mondomaine.ch ServerAlias mondomaine.ch *.mondomaine.ch ServerAdmin hostmaster@mondomaine.ch DocumentRoot /home/www/mondomaine.ch Options FollowSymLinks AllowOverride None Options -Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog /var/log/apache2/mondomaine.ch.error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/mondomaine.ch.access.log combined sans oublier de rendre disponible le site et de recharger Apache pour qu’il prenne en compte notre configuration :
[root@serveur:/etc/apache2/sites-available]# a2ensite mondomaine.ch [root@serveur:~]# /etc/init.d/apache2 reload et le tour est joué, il ne nous reste plus qu’à mettre les fichiers de notre site dans son répertoire /home/www/mondomaine.ch et notre site sera disponible pour toute la planète !

Configuration de MySQL

La configuration par défaut de MySQL est très bien, si ce n’est que nos bases de données sont sauvegardées dans le répertoire /var/lib/mysql/ et comme nous l’avons vu plus tôt, la partition racine n’est pas bien grande, aussi si nous ne voulons pas nous retrouver coincé par manque de place et avoir un message du style « /etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! » lors d’un redémarrage de MySQL, nous avons intérêts à déplacer nos bases de données sur la partition /home.

On arrête le serveur MySQL :
[root@serveur:~]# /etc/init.d/mysql stop Déplacement des bases :
[root@serveur:~]# mv /var/lib/mysql/ /home/ Modification de la configuration de MySQL (fichier /etc/mysql/my.cnf) :
datadir = /home/mysql Redémarrage du serveur MySQL :
[root@serveur:~]# /etc/init.d/mysql start

Et le tour est joué ! Il ne nous reste plus qu’à créer notre première base de données pour notre premier site.

Connexion à MySQL en temps que root :
[etienne@serveur:~]$ mysql -u root -p Enter password: Créons la base de données pour notre premier site :
mysql> create database mondomaine; Créons un nouvel utilisateur :
mysql> create user "mondomaine"@"localhost"; Et attribuons lui un mot de passe :
mysql> set password for "mondomaine"@"localhost" = password("mot_de_passe"); Pour finir, donnons tous les droits à cet utilisateur sur la base de données que nous venons de créer :
mysql> grant all on mondomaine.* to "mondomaine"@"localhost"; Et nous indiquons à MySQL de prendre en compte la modification des autorisations :
mysql> flush privileges;

Vous pouvez maintenant vous déconnecter de MySQL (mysql> exit;), vous y reconnecter avec votre nouvel utilisateur (mysql -u mondomaine -p) et visualiser les bases de données auxquels il a accès (mysql> show databases;).

Configuration de PHP

La configuration de PHP se passe elle dans le fichier /etc/php5/apache2/php.ini. Afin d’assurer une sécurité optimale, les options suivantes sont à vérifier/modifier :
short_open_tag = Off asp_tags = Off safe_mode = Off expose_php = Off display_errors = Off ; empêche l'affichage des erreurs, très important sur un serveur en production log_errors = On ; unique moyen de voir les erreurs sur un serveur en production si vous avez défini l'option display_errors à Off. register_globals = Off
Si vous avez effectué des modifications dans ce fichier, n’oubliez pas de relancer Apache afin qu’il en tienne compte :
[root@serveur:~]# /etc/init.d/apache2 restart

Installation et configuration de phpMyAdmin

Pour ceux qui ne le savent pas encore, phpMyAdmin est un fabuleux programme développé en PHP qui nous permet d’agir directement en ligne sur nos bases de données MySQL.

Afin d’avoir une version toujours à jour, nous allons télécharger la dernière version depuis le site officiel de phpMyAdmin et créer un hôte virtuel du type sql.mondomaine.ch afin d’y accéder directement.

Commençons par créer le répertoire qui va accueillir le programme :
[root@serveur:~]# mkdir /home/phpmyadmin puis récupérons l’archive de la dernière version du logiciel, la version 3.3.8 dans mon cas :
[root@serveur:~]# cd /home/phpmyadmin [root@serveur:/home/phpmyadmin]# wget http://downloads.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.3.8/phpMyAdmin-3.3.8-all-languages.tar.gz décompressons l’archive :
[root@serveur:/home/phpmyadmin]# tar -zxvf phpMyAdmin-3.3.8-all-languages.tar.gz renommons le dossier nouvellement créé afin de simplifier la suite :
[root@serveur:/home/phpmyadmin]# mv phpMyAdmin-3.3.8-all-languages stable supprimons l’archive qui ne nous est plus utile :
[root@serveur:/home/phpmyadmin]# rm phpMyAdmin.3.3.8-all-languages.tar.gz et changeons le propriétaire du dossier /home/phpmyadmin afin qu’Apache puisse y accéder sans problème :
[root@serveur:~]# chown -R www-data:www-data /home/phpmyadmin

Ensuite nous copions le fichier config.sample.inc.php en config.inc.php et nous l’éditons afin d’y ajouter un mot de passe permettant de crypter les données :
[root@serveur: ~]# cd /home/phpmyadmin/stable [root@serveur: ~]# cp config.sample.inc.php config.inc.php [root@serveur: ~]# vim config.inc.php et nous éditions la ligne suivante :
$cfg['blowfish_secret'] = ''; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */ où nous ajoutons le mot de passe de notre choix entre les guillemets simples :
$cfg['blowfish_secret'] = 'un3suite2caractères'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

Passons maintenant à la configuration de notre sous-domaine sql.mondomaine.ch. Si vous avez suivi mon précédent article Serveur dédié – IP Failover, DNS et Reverse IP, vous devez commencez par ajouter le sous-domaine à la configuration du DNS. Éditons le fichier /etc/bind/db.mondomaine.ch et ajoutez-y le sous-domaine comme suit :
sql 10800 IN A 188.165.37.xx en indiquant bien entendu l’adresse IP de votre serveur et sans oublier de modifier le serial en début de page, puis redémarrons le serveur DNS :
[root@serveur:~]# /etc/init.d/bind9 restart

Créons maintenant le fichier de configuration de notre hôte virtuel. Tout se passe dans le répertoire /etc/apache2/sites-available :
[root@serveur:/etc/apache2/sites-available]# vim sql.mondomaine.ch
et ajoutons-y la configuration suivante :
ServerName sql.mondomaine.ch ServerAdmin hotmaster@mondomaine.ch DocumentRoot /home/phpmyadmin/stable Options FollowSymLinks AllowOverride None Options -Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog /var/log/apache2/sql.gwap.ch_error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/sql.gwap.ch_access.log combined

Ajoutons le site à la liste des sites actifs :
[root@serveur:/etc/apache2/sites-available]# a2ensite sql.mondomaine.ch
et rechargeons Apache :
[root@serveur:/etc/apache2/sites-available]# /etc/init.d/apache2 reload

Nous pouvons maintenant tester PhpMyAdmin en allant dans notre navigateur sur l’adresse sql.mondomaine.ch. Si vous avez un message vous informant que l’extension mcrypt ne peut être chargée par PHP, exécutez les lignes suivantes :
[root@serveur:~]# apt-get install php5-mcrypt [root@serveur:~]# /etc/init.d/apache2 reload
et rechargez votre page en vidant le cache (Ctrl-F5 sur Firefox), le message devrait avoir disparu. Nous pouvons maintenant nous connecter à la base de données créée précédemment.

Connexion sécurisée à phpMyAdmin

Tout ceci est bien beau et bien utile, mais nos identifiants à MySQL transitent en clair entre notre domicile et notre serveur, ce qui n’est pas vraiment sécurisé. Aussi allons-nous créer un certificat SSL pour chiffrer toutes les données transitant entre notre domicile et l’hôte virtuel sql.mondomaine.ch.

On commence par créer une arborescence qui permettra le bon fonctionnement de nos commandes :
[etienne@serveur:~]$ mkdir ssl && cd ssl [etienne@serveur:~/ssl]$ mkdir certs crl newcerts private [etienne@serveur:~/ssl]$ echo "01" > serial [etienne@serveur:~/ssl]$ touch index.txt [etienne@serveur:~/ssl]$ cp /usr/lib/ssl/openssl.cnf .
et on édite le fichier openssl.cnf que l’on vient de copier afin de modifier la ligne dir = de la section [ CA_default ] afin de la faire correspondre à notre répertoire :
dir = /home/etienne/ssl

On crée notre clé privée :
openssl genrsa -des3 -out private/cakey.pem 4096

Puis on crée notre certificat auto-signé :
openssl req -new -x509 -nodes -sha1 -days 1825 -key private/cakey.pem -out cacert.pem et on répond aux quelques questions posées.

On continue avec la clé privée de notre domaine :
openssl genrsa -des3 -out mondomaine.key.pem 4096

Et on génère la demande de certificat :
openssl req -new -key mondomaine.key.pem -out mondomaine.csr.pem
et on répond aux questions, en faisant bien attention à mentionner *.mondomaine.ch à la question « Common Name (eg, YOUR name) []: ».

Ensuite nous signons la demande et produisons le certificat final :
openssl ca -config ./openssl.cnf -policy policy_anything -out mondomaine.cert.pem -infiles mondomaine.csr.pem

Afin d’éviter de devoir saisir le mot de passe de la clé privée de notre domaine à chaque redémarrage d’Apache, on va retirer la protection par mot de passe triple DES :
openssl rsa -in mondomaine.key.pem -out mondomaine.key.np.pem

On copie la clé privée ainsi obtenue ainsi que son certificat dans le dossier /etc/apache2/ssl et nous activons le module mod_ssl :
[root@serveur:~]# a2enmod ssl
sans oublier d’ajouter la ligne suivante dans le fichier /etc/apache2/ports.conf :
NameVirtualHost *:443 juste au dessus de la ligne Listen 443.

Passons maintenant à la modification de la configuration de notre hôte virtuel. Nous modifions le fichier /etc/apache2/sites-available/sql.mondomaine.ch comme suit (les changements sont en gras) :
443> ServerName sql.mondomaine.ch ServerAdmin hotmaster@mondomaine.ch DocumentRoot /home/phpmyadmin/stableSSLEngine on SSLCertificateFile /etc/apache2/ssl/mondomaine.cert.pem SSLCertificateKeyFile /etc/apache2/ssl/mondomaine.key.np.pem SSLOptions StrictRequire SSLProtocol all -SSLv2 Options FollowSymLinks AllowOverride None SSLRequireSSL Options -Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog /var/log/apache2/sql.gwap.ch_error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/sql.gwap.ch_access.log combined

Pour terminer, nous devons encore indiquer à Apache qu’il doit aussi lire les certificats .pem et pas uniquement les certificats .crt. Ajoutons la ligne suivante au fichier /etc/apache2/mods-available/ssl.conf :
AddType application/x-x509-ca-cert .pem

et redémarrons le serveur Apache :
[root@serveur:~]# /etc/init.d/apache2 restart

Si nous testons en allant avec notre navigateur sur la page https://sql.mondomaine.ch, nous devons accepter le certificat inconnu (normal, nous l’avons signé nous-même) et nous arrivons sur la version sécurisée de phpMyAdmin. Mais que ce passe-t-il si nous oublions de passer en mode sécurisé (sans le s de https://) ? Hé bien nous arrivons sur notre page d’accueil qui indique que le site est en cours de construction, ce que nous ne voulons pas, nous voulons être redirigé automatiquement sur la version sécurisée.

On commence par activer le module rewrite :
[root@serveur:~]# a2enmod rewrite

Puis nous reprenons notre hôte virtuel (/etc/apache2/sites-available) et ajoutons-y une petite instruction comme suit en tout début de fichier :
ServerName sql.mondomaine.ch RewriteEngine on RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]

Ce qui redirigera toute requête entrant sur le port 80 (non sécurisé) de notre site sql.mondomaine.ch sur le port 443 (sécurisé).

Prochaine étape : MySecureShell pour un SFTP sécurisé et personnalisé
Etape précédente : IP Failover, DNS et Reverse IP

Serveur dédié – IP Failover, DNS et Reverse IP

etienne — Thu, 09 Sep 2010 13:34:33 +0000

Aujourd’hui nous allons nous attaquer à une étape qui demande de la patience, beaucoup de patience. Il s’agit de la configuration des DNS sur une adresse IP FailOver et de son Reverse IP.

Vous avez l’impression que je parle chinois ? Alors voici quelques explications :

Les serveurs DNS (Domain Name System) sont des serveurs capables de gérer un ou plusieurs niveaux de domaines, ce sont eux qui indiquent à votre navigateur sur quel serveur (ou plutôt sur quelle adresse IP) se trouve le site web que vous recherchez. C’est pourquoi lorsque vous commandez un nouveau nom de domaine, vous devez indiquer au moins deux serveurs DNS configurés correctement afin que ceux-ci puissent rediriger les visiteurs de votre site web vers le bon serveur. Et pourquoi deux me direz-vous ? Tout simplement pour palier à une éventuelle panne de l’un d’entre eux. Pour celles et ceux qui aimeraient plus d’information sur ce sujet, le site du zéro fourni une explication claire et détaillée.

Le problème avec les serveurs DNS, c’est qu’ils ne sont pas mis à jour en permanence, mais seulement à intervalles plus ou moins régulières, c’est pourquoi on dit qu’il faut compter entre 10 minutes et 48 heures pour la propagation des DNS et pour que votre serveur puisse être atteint via son nom de domaine.

Venons-en maintenant à l’IP FailOver. Tout serveur dédié se voit attribuer une adresse IP fixe, laquelle vous permet de vous connecter directement à votre serveur. Nous pourrions configurer les DNS et tous nos sites directement dessus, mais que se passerait-il si notre serveur devenait trop faible et que nous devions en prendre un plus performant ? Nous devrions tout configurer avec la nouvelle adresse IP du nouveau serveur et attendre à nouveau quelques heures voire quelques jours que la propagation des DNS se fasse, ce qui risquerait de provoquer des problèmes d’accès à tous nos sites web, et ce ne serait pas professionnel du tout ! Et c’est là qu’intervient l’IP FailOver.

Une IP FailOver est une adresse IP fixe supplémentaire que nous pouvons attribuer à n’importe lequel de nos serveurs. Nous pouvons même en avoir plusieurs pour un seul et même serveur. Ainsi, si votre serveur commence à atteindre ses limites, vous pouvez en commander un nouveau, vous y connecter via son adresse IP fixe, le configurer entièrement, copier les données de votre premier serveur puis, via le Manager d’OVH, rediriger l’IP FailOver sur le nouveau serveur et toutes les requêtes seront directement transmises au nouveau serveur, sans avoir à changer quoi que ce soit auprès de notre registrar.

Et le Reverse IP alors, qu’est-ce que c’est ? Et bien tout simplement, il s’agit de faire l’inverse de ce que fait normalement un serveur DNS. Lorsque vous demandez à un serveur DNS ou se trouve le site monsiteweb.ch, celui-ci va vous donner en retour l’adresse IP du serveur où se trouve le site en question. Le Reverse IP permet tout simplement de connaître le nom du serveur correspondant à une adresse IP donnée. Mais un exemple sera sans doute plus clair :

Quand vous essayez de vous connecter à un site web, votre navigateur va demander à ses serveurs DNS quelle est ou quelles sont les adresses IP du serveur :
[moi@chez-moi:~]$ nslookup e-grisel.net Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: e-grisel.net Address: 80.74.157.22

Nous voyons ainsi que l’adresse IP de mon site est 80.74.157.22, et si nous effectuons l’inverse :
[moi@chez-moi:~]$ nslookup 80.74.157.22 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: 22.157.74.80.in-addr.arpa name = sinope.kreativmedia.ch. Authoritative answers can be found from:

Comme vous le voyez, une recherche sur l’adresse IP de mon site web nous redirige vers sinope.kreativmedia.ch, le serveur qui héberge ce site. Cette fonction est souvent utilisée par les serveurs de mail pour vérifier que le serveur envoyer l’e-mail est bien un serveur et non pas un ordinateur personnel piraté qui essaie d’envoyer du spam. Aussi, si vous ne voulez pas que tous les mails que vous envoyez soient directement marqués comme spam, configurez bien votre Reverse IP.

Bien, maintenant que la théorie est faite, passons à la pratique.

Obtenir une IP FailOver

Pour cela rendez-vous dans votre manager, dans la rubrique Services puis dans la section Gestion IP et sélectionnez IP FailOver. Ensuite, cliquez sur Ajouter une IP Fail-Over, sélectionnez le pays correspondant à votre site web et choisissez le réseau que vous désirez. Il ne reste plus qu’à indiquer à quoi va vous servir cette IP FailOver et sur quelle IP fixe la router.

Configuration des DNS

La configuration des DNS se passe dans le dossier /etc/bind/. Les fichiers que nous allons modifier sont named.conf.local dans lequel nous allons enregistrer chacun des sites web que nous hébergerons, named.conf.options dans lequel nous configurerons les options nécessaires à la communication avec le serveur DNS secondaire d’OVH et nous allons aussi créer un fichier de type db.mondomaine.ch pour chaque domaine qui contiendra la configuration personnalisée du domaine.

named.conf.local

Dans ce fichier nous allons enregistrer une zone pour chacun de nos domaines comme suit :

zone "mondomaine.ch" {
    type master;
    file "/etc/bind/db.mondomaine.ch";
    allow-transfer {213.186.33.199; };
};

Dans la zone, indiquez votre nom de domaine entre guillemets, sans le www. Le type master indique que nous sommes en train de configurer le serveur DNS primaire. La ligne file « /etc/bind/db.mondomaine.ch »; indique où se situe le fichier de configuration de ce domaine, et la directive allow-transfer indique l’adresse IP du serveur DNS secondaire (dans mon cas, il s’agit de l’adresse IP de ns.kimsufi.com) afin que celui-ci soit autorisé à récupérer les informations de notre serveur DNS.

db.mondomaine.ch

Il s’agit ici du fichier indiqué précédemment dans la zone de notre domaine. C’est le fichier le plus important, car c’est ici que nous indiquons l’adresse IP du serveur hébergeant notre domaine.

$TTL    3H

@       IN      SOA     ns.mondomaine.ch.     postmaster.mondomaine.ch. (
                                              2010090805
                                              8H
                                              2H
                                              1W
                                              1D )

@       10800   IN      NS      ns.mondomaine.ch.
@       10800   IN      NS      ns.kimsufi.com.

@       10800   IN      A       188.165.37.xx
www     10800   IN      A       188.165.37.xx
ns      10800   IN      A       188.165.37.xx

La valeur de $TTL donne la durée de vie en secondes de l’enregistrement dans les caches. Le caractère @ remplace le nom de notre zone (dans notre exemple, mondomaine.ch, si vous préférez indiquer directement votre nom de domaine, n’oubliez pas d’ajouter un « . » à la fin). Après le SOA (Start Of Authority), nous devons indiquer notre serveur DNS primaire (ns.mondomaine.ch), suivi d’un « . » puis d’une adresse e-mail valide suivie directement d’un « . ». Remarquez que le @ est remplacé par un point. Si votre adresse e-mail contient un « . », vous devez l’échapper avec un « \ » (par exemple : etienne\.grisel.mondomaine.ch.). S’ensuit entre parenthèses les données suivantes :

serial : 2010090805 ; il s’agit d’un numéro de série composée de l’année, du mois, du jour et d’un numéro incrémenté à chaque modification (YYYYMMDD01)

refresh : 8H ; Ce paramètre donne l’intervalle de temps en secondes (ou abrégée en heures ou en jours) entre deux vérifications du numéro de série (serial) par le serveur DNS. La valeur recommandée est de 24 heures (1D ou 24H ou 86400) et devra être réduite si les modifications sont fréquentes pour cette zone.

retry : 2H ; La vérification du numéro de série par un serveur secondaire peut se solder par un échec dû par exemple à des problèmes de connexion. Dans ce cas la valeur du retry donne l’intervalle en secondes entre deux tentatives de lecture du serial du fichier de zone. La valeur recommandée est 21400, soit 6 heures. Elle devra être ajustée en fonction de la connectivité entre les serveurs autoritaires de la zone.

expire : 1W ; Un serveur peut ne pas réussir à vérifier le serial ou à transférer le fichier de zone. Le paramètre expire donne le temps maximum pendant lequel les données du serveur secondaire peuvent être diffusées avant d’être considérées comme périmées, si aucune vérification ni transfert de zone n’ont pu être effectuées depuis leur téléchargement. La valeur recommandée est de 3600000, soit 41 jours. Cette valeur doit être au minimum 7 fois plus importante que la valeur du refresh, sinon le registrar de votre nom de domaine risque de refuser l’inscription de notre serveur comme DNS.

ttl : 1D ; Défini la durée de vie pour le negative caching, c’est-à-dire le temps qu’une réponse négative doit rester dans les caches.

Ensuite les deux lignes contenant l’enregistrement NS, soit les serveurs DNS qui gèrent notre nom de domaine. Le @ reprend notre nom de zone, le chiffre représente la TTL (Time To Live) spécifique à cette ligne, le IN indique que nous sommes dans une classe internet (la seule encore vraiment utilisée de nos jours), le NS indique que nous parlons des serveurs de noms (DNS) et pour finir nous indiquons le nom de notre serveur. N’oubliez pas d’indiquer le « . » à la fin des noms des serveurs DNS, sinon le programme croira qu’il doit encore ajouter notre zone à la fin de la ligne (ce qui nous donnerait ns.mondomaine.ch.mondomaine.ch et ns.kimsufi.com.mondomaine.ch) et rendrait notre configuration inutilisable.

Pour finir nous mettons en correspondance notre adresse IP FailOver et les noms de machines. Encore une fois, le @ remplace notre zone (mondomaine.ch), le www indique notre sous-domaine principal (comme il n’y a pas de « . » après www, le programme l’interprète comme étant www.mondomaine.ch.) et le ns indique le sous-domaine correspondant à notre serveur DNS.

Je reviendrai sur ce fichier lors de la configuration du serveur de mail, car nous devrons y ajouter une ligne pour indiquer au serveur DNS où il se situe.

Vous trouverez plus d’information sur les différentes options de ce fichier sur le site de l’afnic.

named.conf.options

Dans ce fichier, nous allons uniquement commenter deux lignes avec un double « // » et ajouter la ligne allow-transfer pour permettre au serveur secondaire d’accéder à notre serveur DNS. Modifiez le fichier pour qu’il ressemble à ça :

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        auth-nxdomain no;    # conform to RFC1035
//      listen-on-v6 { ::1; };
//      listen-on { 127.0.0.1; };
        allow-recursion { 127.0.0.1; };
        allow-transfer { 213.186.33.199; };
};

Les lignes modifiées sont indiquées en gras.

Reverse IP

Comme indiqué précédemment, la reverse IP permet de mettre en correspondance notre adresse IP FailOver (dans mon cas 188.165.37.xx) avec le nom de notre serveur (ns.mondomaine.ch).

Pour commencer, nous allons reprendre notre fichier named.conf.local et nous allons y ajouter la zone suivante :

zone "37.165.188.in-addr.arpa" {
    type master;
    file "/etc/bind/db.mondomaine.ch.rev";
};

Le nom de la zone est composé de notre adresse IP FailOver inversée, sans le dernier chiffre et suivie de .in-addr.arpa (dans mon cas, l’adresse IP 188.165.37.xx devient 37.165.188 suivie de .in-addr.arpa). Le nom du fichier utilisé est identique au précédant, sauf que nous y avons ajouté .rev pour éviter d’écraser le fichier configuré précédemment. Vous pouvez mettre n’importe quel nom de fichier, du moment que vous créer bien un fichier de ce nom contenant la configuration que nous allons voir maintenant.

/etc/bind/db.mondomaine.ch.rev
Ce fichier est très semblable au précédent, mais il y a quand même quelques petites différences à ne pas louper :

$TTL    3H

@       IN      SOA     ns.mondomaine.ch.     postmaster.mondomaine.ch (
                        2010090805
                        8H
                        2H
                        1W
                        1D )

@       10800   IN      NS      ns.mondomaine.ch.
@       10800   IN      NS      ns.kimsufi.com.

xx       IN      PTR     ns.mondomaine.ch.

Les premières lignes sont identiques au fichier précédent, nous avons uniquement supprimé la correspondance entre notre zone et notre adresse IP FailOver, que nous remplaçons par la dernière ligne indiquée ci-dessus. Elle commence par le dernier chiffre de notre adresse IP FailOver (indiqué par xx dans mon exemple), suivi de la classe IN, du record type PTR et du nom que nous voulons donner à notre serveur. Dans mon cas je veux qu’il indique la même chose que le nom de mon serveur DNS, mais nous aurions tout aussi bien pu mettre bidule.mondomaine.ch. ou machin.mondomaine.ch., du moment que le nom de notre domaine est indiqué et que nous n’oublions pas le « . » à la fin du nom de notre serveur.

Enfin, nous devons rajouter une interface réseau pour notre nouvelle adresse IP, sinon le serveur ne reconnaîtra pas l’IP FailOver. Pour cela nous éditons le fichier /etc/network/interfaces et nous y ajoutons les lignes suivantes :

auto eth0:0
iface eth0:0 inet static
        address notre.adresse.ip.failover
        netmask 255.255.255.255
        broadcast notre.adresse.ip.failover

et pour finir nous redémarrons l’interface réseau :

[root@serveur:~]# /etc/init.d/networking restart

Nous pouvons vérifier le résultat en effectuant un ping sur notre nouvelle adresse IP.

Pour terminer

Pour vérifier que notre configuration est correcte, nous pouvons utiliser la commande named-checkconf -z directement depuis notre serveur pour vérifier qu’il n’y a pas d’erreur :

[root@serveur:~]# named-checkconf -z
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone mondomaine.ch/IN: loaded serial 2010090805
zone 37.165.188.in-addr.arpa/IN: loaded serial 2010090805

Si cette commande n’affiche aucune erreur, nous rechargeons BIND pour qu’il prenne en charge nos modifications et qu’il lance la propagation :

[root@serveur:~]# /etc/init.d/bind9 reload

Vous pouvez préférer relancer le programme avec la commande suivante :

[root@serveur:~]# /etc/init.d/bind9 restart

Un autre utilitaire lui aussi très utile pour vérifier votre configuration est nslookup (nslookup.exe sous Windows) :

[root@serveur:~]# nslookup
> mondomaine.ch
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	mondomaine.ch
Address: 188.165.37.xx
>

Si vous ne voyez aucune erreur c’est que votre configuration est correcte. Pour en avoir le cœur net, nous pouvons encore tester (sous Linux uniquement) la commande dig :

# dig mondomaine.ch

; <<>> DiG 9.6-ESV-R1 <<>> mondomaine.ch
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43215
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;mondomaine.ch.			IN	A

;; ANSWER SECTION:
mondomaine.ch.		10800	IN	A	188.165.37.xx

;; AUTHORITY SECTION:
mondomaine.ch.		10800	IN	NS	ns.kimsufi.com.
mondomaine.ch.		10800	IN	NS	ns.mondomaine.ch.

;; ADDITIONAL SECTION:
ns.mondomaine.ch.		10800	IN	A	188.165.37.xx
ns.kimsufi.com.		23649	IN	A	213.186.33.199

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep  9 15:11:36 2010
;; MSG SIZE  rcvd: 118

Nous retrouvons en effet toutes les informations que nous avons enregistré précédemment.

Nous sommes presque au bout de nos efforts, mais avant que nous puissions passer à la suite, il faut encore que nous indiquions à notre serveur secondaire de venir prendre en charge notre configuration. Cela se passe dans le manager d’OVH, dans la rubrique Services, section Gestion DNS, option DNS secondaire. Nous cliquons sur Nouveau domaine, nous indiquons le nom du domaine que nous voulons ajouter, sans le www et nous sélectionnons l’adresse IP FailOver que nous avons utilisée un peu plus haut. Et c’est maintenant qu’il va nous falloir être patient ; en effet, il faut compter entre 10 minutes et 48 heures pour que notre configuration soit propagée sur le serveur secondaire. Pour vérifier que tout soit en ordre, nous pouvons utiliser les sites ZoneCheck et DNSdoctor pour tester la propagation et d’éventuelles erreurs résiduelles.

Une fois que la propagation est effective et que les sites mentionnés précédemment n’indiquent plus d’erreur fatale, nous pouvons enregistrer nos DNS auprès de notre registrar. Dans mon cas il s’agit du site de la société Switch SA, qui gère les noms de domaine en .ch et .li. Commençons par enregistrer notre nouveau serveur de nom : dans le menu de gauche, rubrique Serveur de noms -> Enregistrer, indiquez votre serveur de nom (ns.mondomaine.ch) et l’adresse IP FailOver (188.165.37.xx). Une fois ceci fait, rendez-vous dans la rubrique Noms de domaine -> Gestion, cochez le domaine à modifier et cliquez sur Traiter ceux qui sont marqués. Dans la section Serveur de noms, cliquez sur autre pour ajouter le serveur primaire (ns.mondomaine.ch) et le serveur secondaire (ns.kimsufi.com) puis continuer. Si tout se passe bien et que les données ont bien été propagées, la rubrique Serveur de nom de la page récapitulative devrait vous afficher un joli vu vert ou orange. Sinon allez voir les détails et corrigez les erreurs indiquées.

Pour finir, nous allons enregistrer notre Reverse IP dans le manager d’OVH, rubrique Services, section Reverse IPv4, nous cliquons sur l’icône à droite de la ligne correspondant à notre adresse IP FailOver et nous indiquons le reverse que nous venons de configurer (ns.mondomaine.ch). Si tout se passe bien, vous aurez un message indiquant que tout s’est bien déroulé, sinon vous devrez patienter encore un peu que la propagation de votre configuration arrive au serveur d’OVH gérant les reverse IP.

Pour information, j’ai dû attendre une dizaine d’heures pour que la propagation soit effective sur le serveur secondaire (ns.kimsufi.com) et deux heures supplémentaires pour que ma demande de Reverse IP soit prise en compte, mais d’après ce que j’ai lu sur internet, cela peut prendre bien plus de temps dans certains cas. Et si après 3-4 jours vous n’y arrivez toujours pas, c’est peut-être qu’il y a quelque-chose qui cloche dans votre configuration, il ne vous restera alors plus qu’à tout revérifier

Prochaine étape : Apache, PHP, MySQL et PHPmyAdmin
Étape précédente : Un peu de sécurité supplémentaire avec Fail2ban

Serveur dédié – Un peu de sécurité supplémentaire avec Fail2ban

etienne — Thu, 05 Aug 2010 14:07:59 +0000

Bon, maintenant que notre firewall est en place nous devons aussi pensez à surveiller l’activité qui se passe sur les ports que nous avons laissé ouverts, et pour cela il existe un programme spécifique intitulé Fail2ban qui va analyser les logs de notre serveur et bloquer les indésirables (tentatives d’intrusion) pendant un temps défini.

Le principe de fail2ban est simple, nous allons lui configurer des filtres et des règles, et d’après cela il va analyser les logs de nos serveurs, et s’il décèle une tentative d’intrusion, il va ajouter une règle à Iptables pendant un certain temps afin de bloquer l’IP de l’indésirable

Analyse des logs

Avant de commencer l’installation et la configuration de fail2ban, attardons-nous un instant sur les logs de notre serveur.

Les logs se trouvent dans le répertoire /var/log/. La seule exception que je connaisse concerne les logs des sites web que nous allons installer plus tard et qui se trouvent dans leur dossier respectif, mais nous reviendrons plus tard quand nous configurerons nos VirtualHosts pour Apache. Les logs étant de simples fichiers texte, nous pouvons utiliser différentes commandes pour les afficher :
[root@serveur:~]# cat /var/log/auth.log va afficher la totalité du contenu de ce log. Une autre solution pour n’avoir que les 10 dernières lignes ajoutées est d’utiliser la commande suivante :
[root@serveur:~]# tail /var/log/auth.log Si vous désirez voir plus de lignes, par exemples les 20 dernières, nous ajoutons l’option -n suivie du nombre de lignes :
[root@serveur:~]# tail -n 20 /var/log/auth.log et la dernière option de la mort qui tue, l’option -f qui affiche les données au fur et à mesure:
[root@serveur:~]# tail -n 20 -f /var/log/auth.log vous pourrez peut-être ainsi visualiser une tentative d’intrusion en live.

Installation et configuration de Fail2ban

Bon, passons maintenant aux choses sérieuses. Tout d’abord l’installation :
[root@serveur:~]# apt-get install fail2ban Sur un serveur OVH, et si vous avez configuré le firewall comme expliqué dans mon article précédent, il faut d’abord modifier notre firewall pour accepter les connexions FTP en sortie. Pour ce faire, éditer le fichier /etc/init.d/firewall et dé-commenter (enlever le #) de la ligne correspondant au FTP Out.

Configuration

La configuration se passe dans le répertoire /etc/fail2ban/ ou vous trouverez 2 dossiers (action.d et filter.d) et deux fichiers (fail2ban.conf et jail.conf). Nous allons copier les deux fichiers et les renommer en fail2ban.local et jail.local.
[root@serveur:~]# cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local [root@serveur:~]# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local Cette opération n’est pas obligatoire, mais il se peut que les fichiers d’origine soient remplacés lors d’une mise à jour du programme, et si nous y effectuons des modifications elles seront supprimées, alors que les nouveaux fichiers (fail2ban.local et jail.local) ne seront jamais remplacés lors d’une mise à jour, ils sont lus par le programme après les fichiers en .conf et leurs instructions supplantent celles inscrites dans les fichiers en .conf.

La partie la plus importante de la configuration se passe dans le fichier nouvellement créé jail.local. Par défaut, quelques sections sont insérées comme templates. Nous devons activer les sections qui nous intéressent et les adapter à notre configuration. Voici un exemple de section :
[ssh-iptables] enabled = true filter = sshd action = iptables [name=SSH, port=ssh, protocol=tcp] logpath = /var/log/auth.log maxretry = 5

Avec ces quelques réglages voici ce qui va se passer :

la section ssh-iptables est activée (enabled = true)
le filtre sshd.conf du sous-répertoire filter.d sera utilisé
les actions décrites dans iptables.conf (sous-répertoire action.d) seront exécutées si la sortie du filtre est positive.
le fichier de log analysé par le filtre est /var/log/auth.log

Nous allons effectuer quelques modifications que je commenterai (seules les modifications sont affichées).

Section [DEFAULT]
ignoreip = 127.0.0.1 (nous ignorons les tentatives de cette IP, nous n’allons quand même pas nous auto-bloquer )
bantime = 600 (temps de bannissement en secondes)
maxretry = 3 (nombre de tentatives possibles avant blocage)

Toutes les options définies dans la section [DEFAULT] peuvent être outrepassées par chaque prison.
Section [ssh] :
enabled = true (nous activons la prison)
maxretry = 3 (nombre de tentatives avant blocage)
Section [ssh-ddos] :
enabled = true (nous activons la prison)
maxretry = 3 (nombre de tentatives avant blocage)
Section [apache] :
enabled = true (nous activons la prison)
maxretry = 6 (nombre de tentatives avant blocage)
Section [apache-noscript] :
enabled = true (nous activons la prison)
maxretry = 6 (nombre de tentatives avant blocage)
Section [apache-overflows] :
enabled = true (nous activons la prison)
maxretry = 2 (nombre de tentatives avant blocage)

Et nous laissons le reste tel quel pour l’instant. Nous y reviendrons éventuellement plus tard lorsque nous installerons notre serveur mail.

Configurons maintenant les filtres pour les prisons que nous avons activées.

ssh
Le filtre de cette prison se trouve dans le fichier sshd.conf du sous-répertoire filter.d. Quelques expressions régulières sont déjà existantes, nous allons les compléter avec les nôtres :
failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from \s*$ ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from \s*$ ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$ ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s*$ ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$ ^%(__prefix_line)sUser .+ from not allowed because not listed in AllowUsers$ ^%(__prefix_line)sUser .+ from not allowed because none of user's groups are listed in AllowGroups\s*$ ^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=(?:\s+user=.*)?\s*$ ^%(__prefix_line)srefused connect from \S+ \s*$ ^%(__prefix_line)sAddress .* POSSIBLE BREAK-IN ATTEMPT\s*$ Authentication failure for .* from Failed [-/\w]+ for .* from ROOT LOGIN REFUSED .* FROM [iI](?:llegal|nvalid) user .* from Les lignes que j’ai ajoutées sont indiquées en italique.

ssh-ddos
Fichier : /etc/fail2ban/filter.d/ssh-ddos.conf
Rien à modifier ici.

apache
Fichier : /etc/fail2ban/filter.d/apache-auth.conf
Rien à modifier ici.

apache-noscript
Fichier : /etc/fail2ban/filter.d/apache-noscript.conf
Rien à modifier ici.

apache-overflows
Fichier : /etc/fail2ban/filter.d/apache-overflows.conf
Rien à modifier ici.

Test de notre configuration

Si vous créez vos propres expressions régulières (regex), vous voudrez sans doute pouvoir tester leur exactitude et leur fonctionnement. Pour tester une seule expression régulière nous utiliserons la syntaxe suivante :
[root@serveur:~]# fail2ban-regex "ligne" "failregex" « ligne » étant un copier-coller d’une ligne complète d’un log posant quelques soucis et « failregex » représente votre expression régulière, il nous faut donc remplacer ces deux termes (ligne et failregex) par nos propres données. N’oubliez pas d’entourer la ligne ainsi que l’expression régulière par des guillemets doubles.

fail2ban-regex accepte aussi des fichiers. Il est ainsi plus facile de tester et débugger nos expressions régulières :
[root@serveur:~]# fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf ou utiliser une combinaison des deux :
[root@serveur:~]# fail2ban-regex /var/log/auth.log "Failed [-/\w]+ for .* from "

Limitations

C’est assez difficile d’évaluer le temps de réaction de Fail2ban. Il attend 1 seconde avant de vérifier s’il y a de nouveaux logs à scanner. Dans la plupart des cas ça ne pose aucun problème, mais parfois il est possible qu’il y ait plus de tentatives d’intrusions que spécifié par maxretry.

Conclusion

Il ne nous reste plus qu’à redémarrer fail2ban pour qu’il prenne en charge nos modifications :
[root@serveur:~]# /etc/init.d/fail2ban restart Et vous pourrez ensuite aller voir dans les logs (/var/log/fail2ban.log) que nos modifications sont bien prises en compte.

Prochaine étape : IP Failover, DNS et Reverse IP
Etape précédente : Mise en place du firewall

Pour plus d’informations sur la configuration de ce programme, n’hésitez pas à vous rendre sur le site officiel : www.fail2ban.org

Serveur dédié – Mise en place du firewall

etienne — Wed, 04 Aug 2010 17:36:38 +0000

Maintenant que notre connexion SSH est parfaitement configurée, attelons-nous à mettre en place un bon firewall.

Le noyau Linux contient de base le programme Iptables qui officie comme firewall, mais de base celui-ci est vide et n’empêche aucune tentative de connexion sur quelque port que ce soit, c’est pourquoi nous allons mettre en place un script bash que j’ai réécrit sur la base de plusieurs sources diverses et variées.

Nous allons ouvrir 3 terminaux chacun connecté à notre serveur via SSH. Dans le premier nous vérifierons la bonne mise en place du firewall, dans le deuxième nous lancerons le script qui renseignera le firewall, et dans le troisième nous exécuterons une petite ligne de commande qui remettra automatiquement le firewall à zéro si nous nous retrouvons bloqué.

Premier terminal
Vérification des règles du firewall :
[root@serveur:~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain LOG_REJECT_SMTP (0 references) target prot opt source destination Vous devriez avoir le même type d’affichage, à savoir aucune ligne n’apparaissant sous les lignes commençant par target. Nous reviendrons plus tard sur ce terminal.

Deuxième terminal
Nous créons un fichier intitulé firewall dans le dossier /etc/init.d/ :
[root@serveur:~]# vim /etc/init.d/firewall et nous y ajoutons le code suivant :
#!/bin/bash IPT=/sbin/iptables function start { # Vider les tables actuelles $IPT -t filter -F # Vider les règles personnelles $IPT -t filter -X # Interdire toute connexion entrante et sortante $IPT -t filter -P INPUT DROP $IPT -t filter -P FORWARD DROP $IPT -t filter -P OUTPUT DROP # --- # Ne pas casser les connexions etablies $IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT $IPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Autoriser loopback $IPT -t filter -A INPUT -i lo -j ACCEPT $IPT -t filter -A OUTPUT -o lo -j ACCEPT # ICMP (Ping) $IPT -t filter -A INPUT -p icmp -j ACCEPT $IPT -t filter -A OUTPUT -p icmp -j ACCEPT # RTM (Real Time Monitoring) pour OVH $IPT -A INPUT -p udp --dport 6100:6200 -j ACCEPT $IPT -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT # --- # SSH In $IPT -t filter -A INPUT -p tcp --dport 22 -j ACCEPT # SSH Out $IPT -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT # DNS In/Out / Nécessaire pour Bind9 et pour Inadyn $IPT -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT $IPT -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT $IPT -t filter -A INPUT -p tcp --dport 53 -j ACCEPT $IPT -t filter -A INPUT -p udp --dport 53 -j ACCEPT # NTP Out $IPT -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT # HTTP + HTTPS Out #$IPT -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT # HTTP + HTTPS In #$IPT -t filter -A INPUT -p tcp --dport 80 -j ACCEPT #$IPT -t filter -A INPUT -p tcp --dport 443 -j ACCEPT #$IPT -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT # Mail SMTP:25 #$IPT -t filter -A INPUT -p tcp --dport 25 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT # Mail POP3:110 #$IPT -t filter -A INPUT -p tcp --dport 110 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT # Mail IMAP:143 #$IPT -t filter -A INPUT -p tcp --dport 143 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT # Mail POP3S:995 #$IPT -t filter -A INPUT -p tcp --dport 995 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 995 -j ACCEPT # FTP Out #$IPT -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT # FTP In #modprobe ip_conntrack_ftp # ligne facultative avec les serveurs OVH #$IPT -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT #$IPT -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Webmin:10000 #$IPT -t filter -A INPUT -p tcp --dport 10000 -j ACCEPT #$IPT -t filter -A OUTPUT -p tcp --dport 10000 -j ACCEPT # Anti flood ou déni de service $IPT -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT $IPT -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT # Limitation des scans de ports à 1 scan par seconde $IPT -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT # Anti relais SMTP $IPT -N LOG_REJECT_SMTP $IPT -A LOG_REJECT_SMTP -j LOG --log-prefix ' SMTP REJECT PAQUET : ' $IPT -A LOG_REJECT_SMTP -j DROP } function stop { $IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT $IPT -t filter -F } case "$1" in start|restart) echo -n "Démarrage du firewall..." stop start echo "OK." ;; stop) echo -n "Arrêt du firewall..." stop echo "OK." ;; *) echo "Utilisation : $0 {start|stop|restart}"; exit 1 ;; esac exit 0 Nous enregistrons le fichier et lui donnons les droits en exécution :
[root@serveur:~]# chmod +x /etc/init.d/firewall Comme vous pouvez le constater, j’ai commenté une bonne partie des commandes, ce qui fait qu’elles ne seront pas enregistrées dans Iptables. Nous les modifierons au fur et à mesure de l’installation des programmes qui auront besoin de ces accès.

Troisième terminal
Ici nous allons préparer une ligne de commande qui va arrêter automatiquement notre firewall après avoir pressé une touche quelconque ou au plus tard 20 secondes après son lancement, ainsi nous pouvons tester sans risque notre script. Voici la ligne à préparer :
[root@serveur:~]# while true; do test=""; read -t 20 -p "OK? " test ; [ -z "$test" ] && /etc/init.d/firewall stop ; done Si vous n’avez pas suffisamment de temps pour effectuer vos tests, vous pouvez modifier le chiffre après le -t.

Testons notre firewall
Allez dans le 3e terminal et lancer la ligne de commande. Passez rapidement dans le 2e terminal et lancez le firewall :
[root@serveur:~]# /etc/init.d/firewall start Dirigez-vous ensuite directement dans le 1er terminal et vérifiez si vos nouvelles règles ont été enregistrées :
[root@serveur:~]# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:8443 Chain FORWARD (policy DROP) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 ACCEPT udp -- anywhere anywhere limit: avg 1/sec burst 5 ACCEPT tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:ntp ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:https Chain LOG_REJECT_SMTP (0 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix ` SMTP REJECT PAQUET : ' DROP all -- anywhere anywhere Vous voyez que nos différentes instructions ont bien été enregistrée.

Mise en place du firewall
Maintenant que nous avons testé notre firewall, nous pouvons le lancer pour de bon :
[root@serveur:~]# /etc/init.d/firewall start Il faut aussi que nous enregistrions notre firewall pour qu’il se lance automatiquement au démarrage du serveur et qu’il s’arrête automatiquement à l’arrêt du serveur (ben oui, ici on fait bien les choses ) :
[root@serveur:~]# update-rc.d firewall start 40 S . stop 89 0 6 . Adding system startup for /etc/init.d/firewall ... /etc/rc0.d/K89firewall -> ../init.d/firewall /etc/rc6.d/K89firewall -> ../init.d/firewall /etc/rcS.d/S40firewall -> ../init.d/firewall

Et voilà, le tour est joué !

Prochaine étape : Un peu de sécurité supplémentaire avec Fail2ban
Etape précédente : Configuration de SSH

Dernières modifications :
16.08.2010 Ouverture des ports 6100 à 6200 en UDP pour autoriser le RTM (Real Time Monitoring) d’OVH

Serveur dédié – Configuration de SSH

etienne — Wed, 04 Aug 2010 09:24:34 +0000

Après avoir commandé le serveur dédié et reçu les codes d’accès, il y a plusieurs étapes à effectuer lors de la première connexion au serveur :

Modifier le mot de passe root
Créer un nouvel utilisateur
Sécuriser SSH
Faire une mise à jour du serveur
Modifier les locales

Modifier le mot de passe root

La modification du mot de passe root s’effectue très simplement avec la ligne de code suivante :

[root@serveur:~]# passwd Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd: le mot de passe a été mis à jour avec succès

La commande est identique pour chaque utilisateur qui désire changer son mot de passe. Pour changer le mot de passe d’un utilisateur lorsqu’on est root, la commande est la suivante :

[root@serveur:~]# passwd user

ou user représente le login de l’utilisateur

Créer un nouvel utilisateur

Afin d’éviter d’avoir à se connecter au serveur en utilisant root, nous allons créer un nouvel utilisateur :

[root@serveur:~]# adduser --home /home/etienne etienne Ajout de l'utilisateur "etienne"... Ajout du nouveau groupe "etienne" (1000)... Ajout du nouvel utilisateur "etienne" (1000) avec le groupe "etienne"... Création du répertoire personnel "/home/etienne"... Copie des fichiers depuis "/etc/skel"... Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd : le mot de passe a été mis à jour avec succès Modification des informations relatives à l'utilisateur etienne Entrez la nouvelle valeur ou "Entrée" pour conserver la valeur proposée Nom complet []: Etienne Grisel N° de bureau []: Téléphone professionnel []: Téléphone personnel []: Autre []: Ces informations sont-elles correctes ? [O/n] O

Et voilà, c’est aussi simple que cela, nous pouvons passer à la suite.

Sécuriser SSH

Il faut savoir que lorsque vous vous connecter à votre serveur via SSH comme cela :
[etienne@home:~]$ ssh root@ip.de.mon.serveur vos données circulent en clair sur internet jusqu’à ce que vous ayez saisi votre mot de passe, ce qui n’est pas très sécurisé, c’est pourquoi nous allons utiliser le système des clés publiques afin que tout soit crypté dès le début. Et petit avantage supplémentaire, vous n’aurez plus à saisir votre mot de passe à chaque connexion.

Commençons par générer une clef locale sur votre ordinateur personnel (Linux) :
[etienne@home:~]$ ssh-keygen -t dsa et accepter la localisation proposée. Ensuite saisir une « passphrase », sorte de mot de passe sous forme de phrase. Vous aurez ainsi 2 fichiers créés, l’un contenant votre clef privée (/home/etienne/.ssh/id_dsa) et l’autre contenant votre clef publique (/home/etienne/.ssh/id_dsa.pub).

Il faut ensuite enregistrer votre clef publique sur le serveur afin qu’il puisse vous identifier
[etienne@home:~]$ scp ~/.ssh/id_dsa.pub etienne@ip.de.mon.serveur:~/ puis sur le serveur (copie la clé sur le serveur)
[etienne@serveur:~]$ cat id_dsa.pub >> ~/.ssh/authorized_keys (enregistre la clé)[etienne@serveur:~]$ rm ~/id_dsa.pub (supprime le fichier que nous venons de transférer) et le tour est joué.

Pour éviter de devoir à chaque fois taper la totalité de votre adresse IP ou du nom de domaine, vous pouvez créer un alias. Pour ce faire créer un fichier « config » dans le dossier ~/.ssh/ de votre ordinateur local et ajoutez-y les données suivantes:
Host mon_alias User votre_user_sur_le_serveur HostName adresse_ip_du_serveur_ou_nom_du_serveur puis pour vous connecter
ssh mon_alias

Nous allons maintenant vérifier que le fichier de configuration de SSH (/etc/ssh/sshd_config) est configuré de manière sûre. Voici les données que nous devons, à mon humble avis, vérifier et éventuellement modifier :

Port 22
Il s’agit du port sur lequel nous nous connectons via SSH (par défaut 22). La logique voudrait qu’on le modifie afin d’éviter les attaques de force brute, mais en faisant ainsi nous ôtons toute possibilité à notre prestataire (OVH dans mon cas) de pouvoir nous dépanner en cas de besoin, je vous propose donc de le laisser tel quel.

Protocol 2
Il s’agit de la version du protocole SSH utilisée. Le protocole 1 ayant quelques failles de sécurité, il faut impérativement utiliser la version 2.

PermitRootLogin yes
Autorisons-nous root à se connecter directement en SSH ? En théorie non, car un pirate pourrait utiliser une attaque par dictionnaire pour tenter de se connecter en root sur notre serveur, mais pour les mêmes raisons que pour le choix du port, nous allons laisser l’accès à root. Une bonne utilisation du firewall (via Iptables) et de Fail2ban nous permettrons de limiter au maximum les risques.

RSAAuthentication yes
PubkeyAuthentication yes
Ces options nous permettent de nous connecter à l’aide d’une clef publique, comme nous l’avons vu précédemment. Je vous recommande chaudement de mettre ces options à yes.

PermitEmptyPasswords no
Voulons-nous autoriser l’accès à notre serveur SSH sans mot de passe ? Bien sûr que non, cela serait une énorme faille dans la sécurité de notre serveur ! Nous laissons donc la valeur à no.

PasswordAuthentication yes
Voulons-nous pouvoir nous connecter en utilisant un mot de passe (comme nous le faisions avant d’utiliser le système des clefs publiques) ? Normalement ce n’est plus nécessaire, à moins de devoir se connecter au serveur depuis un autre ordinateur que celui sur lequel vous avez généré la clef. Si ce n’est pas le cas, nous pouvons passer cette option à no (n’oubliez pas d’enlever le # au début de la ligne, sinon elle restera en commentaire et vos modifications ne seront pas prisent en compte). Nous reviendrons sur cette option dans un prochain article sur MySecureShell, mais pour l’instant mieux vaut rester prudent et empêcher qu’un pirate tente une attaque par dictionnaire.

Nous avons fait le tour des options qui me semblent importantes. Pour que le serveur SSH les prenne en compte, n’oublions pas de le redémarrer
[root@serveur:~]# /etc/init.d/ssh restart et de tester une connexion via un autre terminal que celui avec lequel nous sommes connectés afin de s’assurer que nous ne nous sommes pas auto-exclu de notre serveur.

Faire une mise à jour du serveur

Une chose très importante sur un serveur internet, tout comme sur chaque ordinateur, c’est de s’assurer que les logiciels que nous utilisons sont toujours à jour. Pour cela, sur Debian GNU/Linux ou toute autre distribution linux dérivée de Debian, on exécute la ligne de code suivante :
[root@serveur:~]# apt-get update && apt-get upgrade
Si des logiciels doivent être mis à jour, une liste vous sera proposée et vous n’aurez plus qu’à valider par une pression sur la touche [Enter] de votre clavier. N’oubliez pas d’effectuer cette opération régulièrement si vous ne voulez pas risquer une intrusion sur votre serveur.

Modifier les locales

Un problème que j’ai eu lors de mes premières connexions, c’est que tous les accents et caractères spéciaux étaient remplacés par un losange noir avec un point d’interrogation. Pour éviter cela, une petite commande toute simple et le tour est joué :
[root@serveur:~]# dpkg-reconfigure locales et dans la deuxième page on sélectionne par défaut l’option fr_FR.UTF-8 ou n’importe quelle option qui fini par UTF-8. Ensuite il ne nous reste plus qu’à nous déconnecter et nous reconnecter et le problème a disparu ! Magique n’est-ce pas ?

Prochaine étape : Mise en place du firewall
Etape précédente : Introduction

Serveur dédié – Introduction

etienne — Tue, 03 Aug 2010 22:25:06 +0000

Comme certains d’entre vous le savent, je crée et je gère depuis une dizaine d’années quelques sites web pour moi ou pour des proches. Au fur et à mesure mon expérience a grandi, mes sites sont devenus plus sophistiqués techniquement et mes besoins au niveau de l’hébergement sont devenus plus pointus, à tel point que je me suis décidé aujourd’hui à prendre un serveur dédié.

Après avoir effectué de longues et studieuses recherches sur internet, j’ai trouvé beaucoup de sites qui parlent d’une partie de l’installation et/ou de la configuration d’un site web ou d’un serveur dédié, mais je n’en ai pas trouvé un seul qui regroupe toutes les informations utiles. Aussi ai-je décidé de prendre mon courage à deux mains et d’écrire au fur et à mesure tout ce que je fais sur mon serveur afin de pouvoir « facilement » en configurer un nouveau quand j’en aurai besoin, mais aussi afin que vous puissiez vous épargner les heures de recherche que j’ai déjà effectuées. N’étant moi-même qu’un amateur dans ce domaine, je ne suis pas à l’abri de l’erreur et accepterai de ce fait avec grand plaisir vos commentaires et remarques qui me permettront de corriger et améliorer mes articles.

Concernant le serveur dédié, mon choix s’est porté sur l’offre de base de Kimsufi.com qui me permet d’avoir un vrai serveur dédié à moindre frais et dont les capacités devraient être largement suffisantes pour tenir la charge de quelques petits sites personnels. Le choix du système d’exploitation (Debian GNU/Linux) s’est fait naturellement car j’utilise Ubuntu (dérivé de Debian) depuis ses débuts sur mon PC personnel et Debian sur mon petit serveur de test à domicile, aussi suis-je déjà en terrain relativement connu.

L’installation et la configuration d’un serveur dédié ne se faisant pas à la hâte, j’ai décidé de procéder par étapes :

Configuration de SSH
Mise en place du firewall
Un peu de sécurité supplémentaire avec Fail2ban
IP Failover, DNS et Reverse IP
Apache, PHP, MySQL et phpMyAdmin
MySecureShell pour un SFTP sécurisé et personnalisé
Nginx comme reverse proxy pour le contenu statique
Un serveur mail avec Postfix et Courier
RoundCube, un webmail léger
Backup FTP

En voilà un sacré programme ! et il s’étoffera sans doute au fur et à mesure de mes expériences et de vos commentaires. En maintenant assez de blabla, passons à la première étape : la configuration de SSH.

Dernières modifications :
05.08.2010 Modification de l’intitulé de certaines étapes
16.10.2010 Modification de l’ordre des étapes

Novalles Auto Cross 2009

etienne — Wed, 02 Sep 2009 12:57:39 +0000

Cette année avait lieu la 11e édition de l’Auto Cross de Novalles. Le soleil, la bise, des quads, un hélicoptère et pas moins de 64 voitures préparées pour l’occasion s’étaient donnés rendez-vous près du petit village de Novalles.

Une fois encore, le spectacle fut au rendez-vous, avec quelques belles figures de style telles que des tonneaux, des roues baladeuses et des demonstrations de véhicules téléguidés.

Si vous n’avez pas eu la chance d’assister à ce superbe spectacle, ou si vous désirez vous replonger dans l’ambiance de cette belle journée, les photos du Novalles Auto Cross 2009 sont disponibles sur mon autre site.

Photos de judo

etienne — Sat, 28 Mar 2009 21:14:53 +0000

Ce samedi à eu lieu à Yverdon le deuxième tour de la ligue A Suisse de Judo, entre les équipes féminines et masculines de l’école Dégallier et leurs adversaires de Suisse Alémanique (désolé, je n’ai pas retenu leur provenance) et de Genève.

Retrouvez toutes les photos sur mon site dédié: galeriesphotos.ch