Linux Server Wiki - Contributions [fr]

Serveur debian

2015-12-29T01:05:31Z

Jonass :

[[category:serveur]]
[[category:debian]]
=Généralités sur ce howto=

Je vais commencer par décrire l'arborescence que la suite du howto utilise.
Le dossier <code>/srv/</code> va contenir tous les dossiers et fichiers en rapport directement avec le serveur. Sur mon installation, j'ai créé une partition à part pour <code>/srv/</code> ce qui permet de ne pas perdre les données lors d'une réinstallation.
<code>/srv/bind/</code> contient les différentes zones dns que mon serveur bind9 gère.
<code>/srv/http/</code> contient les différents sites internet que mon serveur héberge du moment qu'ils ne sont pas rattaché à un utilisateur en particulier. Les sites internet rattachés à un utilisateur doivent être dans le dossier home de l'utilisateur en question.

Notez que pour la suite de ce howto, tous les changements de permissions effectués supposent que vous êtes en umask 0027.
Vous pouvez voir votre umask actuel avec la commande umask. Si votre umask n'est pas 0027, tapez :
<pre>umask 0027</pre>

Créez le répertoire /srv s'il n'existe pas :
<pre>
mkdir /srv
chmod o+rx /srv
</pre>

[[Généralités sur debian]]

[[Installation et configuration d'un nouveau kernel]]

[[Configuration d'apt-get]]

[[Installation et configuration de OpenSSH]]

[[Eviter le reboot accidentel de son serveur]]

[[Sécurisation d'un serveur linux]]

[[Installation et configuration de OpenSSL]]

[[Installation et configuration de bind9]]

[[Installation et configuration d'un serveur http apache 2.2]]

[[Sécuriser ses sites avec letsencrypt et acme-tiny]]

[[Installation de configuration de ProFTPd]]

[[Installation et configuration de MySQL]]

[[Mise en place d'un serveur de mail complet]]

[[Installation et mise en place d'un dépôt subversion]]

[[Installation et mise en place de trac]]

[[Installation et configuration de OpenLDAP]]

[[Mise en place de statistiques avec Cacti]]

[[Mise en place de monitoring avec Munin]]

[[Des informations sur votre serveur avec phpsysinfo]]

[[Protéger son serveur des attaques par brute force avec fail2ban]]

[[Surveiller les logs de son serveur avec l'outil logcheck]]

[[Réaliser des backups automatiquement pour ses dépôts svn, bases mysql, et dossiers]]

[[Garder son serveur à l'heure avec ntp]]

[[Le chat vocal avec mumble]]

[[Mise en place d'un VPN avec OpenVPN]]

Sécuriser ses sites avec letsencrypt et acme-tiny

2015-12-29T01:04:46Z

Jonass : Page créée avec « Category:serveur Category:debian Les tutos [[Installation_et_configuration_d'un_serveur_http_apache_2.2|Installation et configuration d'un serveur http apache 2.2]... »

[[Category:serveur]]
[[Category:debian]]
Les tutos [[Installation_et_configuration_d'un_serveur_http_apache_2.2|Installation et configuration d'un serveur http apache 2.2]] ainsi que [[Installation_et_configuration_de_OpenSSL|Installation et configuration de OpenSSL]] vous expliquent comment générer des certificats auto-signés et configurer vos vhosts Apache.

Ceci dit les certificats auto-signés présentent un inconvénient majeur : ils génèrent des alertes de sécurité dans les navigateurs.

Ils conviennent donc tout à fait pour sécuriser une interface d'admin, mais dès lors où votre site est ouvert au "public" ils ne sont plus utilisables, les messages d'alertes dans les navigateurs étant plus que dissuasifs.

Depuis peu une nouvelle autorité de certification a vu le jour : https://letsencrypt.org/

Cette autorité vise à fournir gratuitement des certificats de sécurité reconnus dans les navigateurs (grâce dès aujourd'hui à une signature croisée avec une autre autorité)

Il n'y a donc plus d'excuses pour ne pas proposer de HTTPS sur vos sites !

=Pourquoi acme-tiny ?=
Letsencrypt propose un client officiel qui se charge de presque tout pour vous mais qui a plusieurs défauts, entre autre le fait que vous n'avez pas vraiment la main sur son fonctionnement, qu'il nécessite pas mal de dépendances, doit tourner en root, etc.

Letsencrypt étant un projet OpenSource, il existe de nombreux autres scripts proposant plus ou moins de fonctionnalités, acme-tiny en fait parti : https://github.com/diafygi/acme-tiny

Ce script vous permet de générer le certificat en passant par letsencrypt tout en gardant la main sur votre config Apache, la façon dont vous gérez les certificats, etc.

=Pré-configuration (pour la première utilisation)=
Avant de générer les certificats, commencez par créer un utilisateur dédié qui se chargera de faire tourner le script.
Nous partirons sur un utilisateur nommé acme, avec un home dans /home/acme.

Avec cet utilisateur (su - acme) :
<pre>
cd /home/acme
mkdir work secrets
chmod 750 work
chmod 700 secrets
git clone https://github.com/diafygi/acme-tiny.git
chmod +x acme-tiny/acme_tiny.py
</pre>

Le répertoire secrets servira à héberger les clés (fichiers .key), le work hébergera les différents fichiers des certifiats (crt, csr, pem).

On restreint les droits sur les dossiers et enfin on récupère le script et on le rend exécutable.

=Génération des clés=
Afin de communiquer avec letsencrypt il vous faut un fichier de clé qui vous authentifie auprès d'eux. Ce fichier est extrêmement important (pensez à bien le sauvegarder) et bien sûr totalement privé.

Si vous n'en avez pas encore vous pouvez le générer de la façon suivante :
<pre>
openssl genrsa 4096 > /home/acme/secrets/account.key
chmod 600 /home/acme/secrets/account.key
</pre>
Ce fichier de clé est réutilisable sur tous vos domaines.

Ensuite il vous faudra un fichier de clé par domaine que vous voulez sécuriser, même principe :
<pre>
openssl genrsa 4096 > /home/acme/secrets/networklab.fr.key
chmod 600 /home/acme/secrets/networklab.fr.key
mkdir /home/acme/work/networklab.fr
</pre>
Ici pour le domaine networklab.fr, à adapter dans votre cas. On créé également un répertoire dédié au domaine dans work.

=Configuration pour la demande du certificat=
Afin de demander votre certificat il est nécessaire de générer une demande de certificat.
Si vous n'avez qu'une adresse qui sera derrière votre certificat :
<pre>openssl req -new -sha256 -key /home/acme/secrets/networklab.fr.key -subj "/CN=networklab.fr" > /home/acme/work/networklab.fr/networklab.fr.csr</pre>
Mais plus généralement vous en aurez au moins deux (une avec et une sans le www) :
<pre>openssl req -new -sha256 -key /home/acme/secrets/networklab.fr.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:networklab.fr,DNS:www.networklab.fr")) > /home/acme/work/networklab.fr/networklab.fr.csr</pre>

Avant de générer votre certificat, letsencrypt vient vérifier que votre site vous appartient bien. Pour cela le script va déposer un fichier de "challenge" à l'endroit que vous lui définissez et qui doit être accessible à l'adresse /.well-known/acme-challenge/.

Pour cela il faut donc que votre utilisateur acme puisse écrire dans un dossier de votre site.

Ici nous partons du principe que vous avez un couple d'utilisateur/groupe par site que vous hébergez. Si vous avez une configuration d'Apache avec un seul utilisateur ça n'en sera que plus simple.

En root :
<pre>usermod -a -G networklab.fr acme</pre>
On ajoute le groupe networklab.fr en groupe secondaire de l'utilisateur acme.

Avec l'utilisateur correspondant à votre site (pour nous networklab.fr) :
<pre>
cd /home/networklab.fr/www/
mkdir challenges
chmod g+w challenges/
</pre>
Le dossier challenges hébergera le fichier de challenge que letsencrypt va vérifier. On donne le droit d'écriture au groupe pour que l'utilisateur acme puisse y écrire.

Enfin en root dans la configuration Apache de votre site il faudra ajouter :
<pre>
<Directory "/home/networklab.fr/www/challenges">
AllowOverride FileInfo AuthConfig Limit Indexes
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Alias /.well-known/acme-challenge "/home/networklab.fr/www/challenges"
</pre>

Pensez à bien reload Apache après cette modification.

'''Attention : letsencrypt viendra chercher le fichier de challenge en HTTP et non en HTTPS. Si vous redirigez automatiquement en HTTPS pensez à mettre une exception sur cette adresse.'''

'''De même si vous sécurisez un domaine "d'administration" avec ne protection par .htpasswd pensez également à mettre une exception.'''

Pour cela ajoutez dans le .htaccess :
<pre>
SetEnvIf Request_URI "(challenges/)$" allow
SetEnvIf Request_URI "(\.well-known/acme-challenge/)$" allow
</pre>

=Génération du certificat=
De retour en utilisateur acme, voici le script vous permettant de générer votre certificat :
<pre>
#! /bin/bash
umask 022
python /home/acme/acme-tiny/acme_tiny.py --account-key /home/acme/secrets/account.key --csr /home/acme/work/networklab.fr/networklab.fr.csr --acme-dir /home/networklab.fr/www/challenges/ > /home/acme/work/networklab.fr/networklab.fr.crt
umask 027
wget -O - https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem > /home/acme/work/networklab.fr/intermediate.pem
cat /home/acme/work/networklab.fr/networklab.fr.crt /home/acme/work/networklab.fr/intermediate.pem > /home/acme/work/networklab.fr/networklab.fr.pem
</pre>
Le changement d'umask permet d'écrire le fichier de challenges avec des droits permettant à Apache de servir le fichier (le fichier étant créé en acme:acme, l'umask 027 ne le permet pas).
On lance ensuite le script acme-tiny qui prend en paramètres :
* la clé de votre compte
* le csr (demande de certificat)
* l'emplacement où il doit écrire le fichier de challenge
Et en sortie on récupère le certificat.

On repasse ensuite en umask 027, on récupère le certificat intermédiaire de letsencrypt.

Enfin on combine notre certificat au certificat intermédiaire.

Le script est exactement le même pour un renouvellement de certificat. Vous pouvez donc l'enregistrer (dans notre cas /home/acme/networklab.fr.sh).

Configurez ensuite une tâche cron pour renouveler régulièrement votre certificat.

Actuellement les certificats letsencrypt sont valables 90 jours.

Vous pouvez par exemple partir sur une génération mensuelle :
<pre>
0 4 21 * * /home/acme/networklab.fr.sh
</pre>
''Tous les 21 du mois à 4H00.''

=Configuration de la vhost et reload d'Apache=
Dernière étape en root, il est nécessaire de configurer votre vhost en HTTPS.
Si vous n'aviez que du HTTP vous pouvez rajouter :
<pre>
<VirtualHost *:443>
SSLEngine on
SSLCertificateChainFile /home/acme/work/networklab.fr/intermediate.pem
SSLCertificateFile /home/acme/work/networklab.fr/networklab.fr.pem
SSLCertificateKeyFile /home/acme/secrets/networklab.fr.key
SSLProtocol all -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLHonorCipherOrder on
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENY
ServerName networklab.fr
ServerAlias www.networklab.fr
Include /etc/apache2/sites-config/networklab.fr.conf
</VirtualHost>
</pre>
On retrouve la configuration du certificat intermédiaire, du certificat de notre domaine et de la clé.
Ensuite différentes configurations SSL, à adapter selon la date à laquelle vous lirez ce tuto.

Dernière étape, configurer un reload d'Apache juste après la date prévue pour le renouvellement de vos certificats.
Vous pouvez au choix :
* donner le droit à l'utilisateur acme de reload Apache et le rajouter à votre script
* faire un cron en root à une date/heure définie juste après tous vos scripts de renouvellement

Ici nous utiliserons le cron en root :
<pre>
5 4 21 * * /etc/init.d/apache2 reload
</pre>
''Tous les 21 du mois à 4H05.''

Et voilà, vous aurez dorénavant un site en HTTPS avec renouvellement automatique du certificat. Vous pouvez facilement reproduire la chose pour d'autres domaines en refaisant les étapes 3 à 6.
Pensez à surveiller que vos certificats se renouvellent bien (idéalement avec du monitoring qui vous alertera en cas de soucis !)

Serveur debian

2011-10-03T15:25:18Z

Jonass :

[[category:serveur]]
[[category:debian]]
=Généralités sur ce howto=

Je vais commencer par décrire l'arborescence que la suite du howto utilise.
Le dossier <code>/srv/</code> va contenir tous les dossiers et fichiers en rapport directement avec le serveur. Sur mon installation, j'ai créé une partition à part pour <code>/srv/</code> ce qui permet de ne pas perdre les données lors d'une réinstallation.
<code>/srv/bind/</code> contient les différentes zones dns que mon serveur bind9 gère.
<code>/srv/http/</code> contient les différents sites internet que mon serveur héberge du moment qu'ils ne sont pas rattaché à un utilisateur en particulier. Les sites internet rattachés à un utilisateur doivent être dans le dossier home de l'utilisateur en question.

Notez que pour la suite de ce howto, tous les changements de permissions effectués supposent que vous êtes en umask 0027.
Vous pouvez voir votre umask actuel avec la commande umask. Si votre umask n'est pas 0027, tapez :
<pre>umask 0027</pre>

Créez le répertoire /srv s'il n'existe pas :
<pre>
mkdir /srv
chmod o+rx /srv
</pre>

[[Généralités sur debian]]

[[Installation et configuration d'un nouveau kernel]]

[[Configuration d'apt-get]]

[[Installation et configuration de OpenSSH]]

[[Eviter le reboot accidentel de son serveur]]

[[Sécurisation de base d'un serveur linux]]

[[Installation et configuration de OpenSSL]]

[[Installation et configuration de bind9]]

[[Installation et configuration d'un serveur http apache 2.2]]

[[Installation de configuration de ProFTPd]]

[[Installation et configuration de MySQL]]

[[Mise en place d'un serveur de mail complet]]

[[Installation et mise en place d'un dépôt subversion]]

[[Installation et mise en place de trac]]

[[Installation et configuration de OpenLDAP]]

[[Mise en place de statistiques avec Cacti]]

[[Mise en place de monitoring avec Munin]]

[[Des informations sur votre serveur avec phpsysinfo]]

[[Protéger son serveur des attaques par brute force avec fail2ban]]

[[Surveiller les logs de son serveur avec l'outil logcheck]]

[[Réaliser des backups automatiquement pour ses dépôts svn, bases mysql, et dossiers]]

[[Garder son serveur à l'heure avec ntp]]

[[Le chat vocal avec mumble]]

[[Mise en place d'un VPN avec OpenVPN]]

Mise en place de monitoring avec Munin

2011-10-03T15:24:20Z

Jonass : Page créée avec « Category:serveur Category:debian =Installer Munin= Munin se divise en deux parties : * Le Master : qui s'occupe de l'affichage et de récupérer les valeurs auprès ... »

[[Category:serveur]]
[[Category:debian]]
=Installer Munin=

Munin se divise en deux parties :
* Le Master : qui s'occupe de l'affichage et de récupérer les valeurs auprès des nodes
* Le Node : qui fournit les valeurs au master et contient des plugins pour récupérer les valeurs à grapher

Il existe un grand nombre de plugins, ceux-ci peuvent être écrit en bash/perl/python (ou autre).
Chaque plugin se charge de récupérer (en parsant des logs, requêtant une base de données, etc) les valeurs à envoyer au Master.

Nous allons maintenant installer Munin sur notre première machine, qui aura donc le master et un node :
<pre>
sudo apt-get install munin munin-node
</pre>

=Configurer le Master=

Pour configurer le Master nous allons édité le fichier /etc/munin/munin.conf.

La valeur la plus intéressante dans un premier temps est la suivante :
<pre>
htmldir /var/cache/munin/www
</pre>

C'est dans ce dossier que Munin va stocker le site pour afficher les graphs.

Vous pouvez ensuite configurer les nodes à interroger de la façon suivante :
<pre>
[plop.org]
address 127.0.0.1
use_node_name yes
</pre>

L'addresse étant bien entendu celle du node, ici nous interrogeons le node contenu sur le même serveur.

Note : la configuration du Master ne se reload pas, celui-ci relit sa configuration dès qu'il interroge les nodes.

=Configurer le Node=

Nous pouvons ensuite configurer le node à l'aide du fichier /etc/munin/munin-node.conf.
Les valeurs importantes sont les suivantes :
<pre>
allow ^127\.0\.0\.1$
host *
</pre>

La première ligne permet de n'autoriser que l'addresse indiquer à interroger le node.
La deuxième permet de définir sur quelle interface la node doit écouter.

Le mieux est bien entendu de restreindre au maximum, en changeant la configuration de base par :
<pre>
allow ^127\.0\.0\.1$
host 127.0.0.1
</pre>

Bien entendu si la node n'est pas au même endroit que le Master, vous devrez adapter la configuration.

Après cette configuration il ne faut pas oublier de redémarrer le node :
<pre>
sudo /etc/init.d/munin-node restart
</pre>

=Configurer Apache=

Munin propose une configuration de base pour Apache dans /etc/munin/apache.conf.
Vous pouvez l'adapter à vos besoins, en mettant toujours comme DocumentRoot la valeur défini pour htmldir dans /etc/munin/munin.conf.

N'oubliez pas de mettre en place un htaccess pour protéger vos graphs par un nom d'utilisateur/mot de passe.

=Les plugins=

Dans les versions actuelles de Munin, le Master interroge les nodes toutes les 5 minutes.
Les plugins activés sont définis sur chaque node dans /etc/munin/plugins.
Le principe est de créer un lien symbolique dans ce dossier vers le plugin.
Pour désactiver/activer un plugin, il suffit de créer/supprimer le lien symbolique.

Lorsque le Master interrogera à nouveau le node, il adaptera les graphs en conséquence.

''En cours de rédaction''