Let’s Encrypt (LE)

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 7. Let’s Encrypt (LE)

Certificats & CA

Dans un des chapitres précédents, je vous ai fait installé un Certificat auto-signé (self-signed certificate). Ce qui fait qu’à chaque fois que vous vous connectez à votre page, vous auvez droit à un message d’avertissement comme ci-dessous.

036

Pour éviter ce genre de désagrément, il vous faudra un certificat signé par une autorité de certification (CA). Malgré le fait qu’un site présente un certificat auto-signé ou signé par un CA, garder en tête que rien ne prouve que le site visité est bel et bien émis par son propriétaire. Cependant, la présence de certificats apporte une assurance que les communications avec le serveur sont chiffrées.

Let’s Encrypt est un très bon choix de CA, puisque ce dernier offre des certificats gratuits qui de plus, ssont reconnus par la plupart des navigateurs internets, etc, sans oublier que le projet est soutenu par pas mal d’entreprises de poids, dont la liste se trouve ici.

Installation et configuration de Let’s Encrypt

Letsencrypt se trouve dans le dépot Jessie-backport de debian, mais nous n’allons pas l’installer avec la méthode conventionnelle.

Il faut savoir qu’une fois lestencrypt installé et, surtout en fonction des options d’installation choisies, ce dernier peut modifier les configurations de vos différents serveurs (serveur web, serveur owncloud, etc.) en fonction de ces besoins. Deuxième point à prendre en compte, c’est que cette application étant toujours en mode Béta, si vous n’êtes pas confortable avec l’utilisation de logiciels ou d’applications en mode Béta, passer votre chemin.

Le plugin Webroot, anciennement appelé simplefs, est la meilleure option à choisir, pour pouvoir garder entièrement le contrôle sur chacun de nos serveurs, sans que letsencrypt s’y mèle lors de l’installation, et même après. Avec ce plugin, le client letsencrypt ne fera rien de plus que ce qu’on lui demande de faire, c’est à dire de créer/ renouveller/révoquer un certificat.

Allons-y pour l’installation.

1. Créer un dossier pour l’installation de letsencrypt

$ sudo mkdir -p /var/www/html/owncloud/letsencrypt/.well-known/acme-challenge

Vérifier les permissions, puis restreindre au maximum ce qu’on peut.

$ ls -l /var/www/html/owncloud/
drwxr-xr-x 3 root root 4096 Apr 8 16:58 letsencrypt

$ sudo chown -R www-data:www-data /var/www/html/owncloud/letsencrypt

$ sudo chmod -R 750 /var/www/html/owncloud/letsencrypt

2. Lancer l’installation

Installer le paquet « git » dans un premier temps, qu’on utilisera pour télécharger le client Let’s Encrypt par la suite.

$ sudo apt-get install git

Télécharger une copie conforme du dossier officiel Let’s Encrypt à partir de github, à placer dans le dossier /opt.

Petite note concernant le dossier /opt, sur un système à base de debian, on y place généralement les logiciels tierces, non compris dans les dépôts officiels, dans ce dossier.

$ cd /opt

$ sudo git clone https://github.com/letsencrypt/letsencrypt

$ ls /opt/letsencrypt
  acme
  letshelp-letsencrypt
  CHANGES.rst                     LICENSE.txt
  CONTRIBUTING.md                 linter_plugin.py
  docker-compose.yml              MANIFEST.in
  Dockerfile                      pep8.travis.sh
  Dockerfile-dev                  README.rst
  docs                            readthedocs.org.requirements.txt
  examples                        setup.cfg
  letsencrypt                     setup.py
  letsencrypt-apache              tests
  letsencrypt-auto                tools
  letsencrypt-auto-source         tox.cover.sh
  letsencrypt-compatibility-test  tox.ini
  letsencrypt-nginx               Vagrantfile

Avant d’aller plus loin, vérifions que la commande letsencrypt-auto fonctionne correctement, en lançant la commande de demande d’aide par exemple (« letsencrypt-auto –help » ou « letsencrypt-auto –help all »).

/opt/letsencrypt$ sudo ./letsencrypt-auto --help [all]
!---Tronquée---!
ca-certificates is already the newest version.
gcc is already the newest version.
gcc set to manually installed.
python is already the newest version.
The following extra packages will be installed:
  dh-python libexpat1-dev libmpdec2 libpython-dev libpython2.7-dev
  libpython3-stdlib libpython3.4-minimal libpython3.4-stdlib
  python-chardet-whl python-colorama-whl python-distlib-whl
  python-html5lib-whl python-pip-whl python-pkg-resources
  python-requests-whl python-setuptools-whl python-six-whl
  python-urllib3-whl python2.7-dev python3 python3-minimal
  python3-pkg-resources python3-virtualenv python3.4 python3.4-minimal
Suggested packages:
  augeas-doc augeas-tools python-distribute python-distribute-doc
  python3-doc python3-tk python3-venv python3-setuptools python3.4-venv
  python3.4-doc binfmt-support
Recommended packages:
  libssl-doc
!---Tronquée---!
Installing Python packages...
Installation succeeded.

Comme vous pouvez le constater, letsencrypt installe automatiquement toutes les dépendances dont il a besoin.

L’option « all » après l’instruction « –help », est optionnel, mais nous fournit plus d’information concernant les options disponibles avec la commande lestencrypt.
Si vous avez un résultat comme ci-dessus avec l’option « –help » ou « –help all », c’est que vous êtes bon pour poursuivre la procédure d’obtention de certificats signés par le CA, Let’s Encrypt.

3. letsencrypt-auto

Letsencrypt est un progamme écrit en python, qui se charge d’installer et de mettre à jour automatiquement tous les outils dont il a besoin comme on l’a vu plus haut. Pour l’utiliser, il suffit juste de se placer dans le dossier /opt/letsencrypt, puis de lancer la commande « ./letsencrypt-auto ».
Pour information, durant la phase Béta, le nombre de certificats émis par le CA (Let’s Encrypt), est assez limité. De ce fait, avant de lancer votre requête, faites un test pour vérifié que votre requête serait accordée ou non.

N’oubliez pas de désactiver la redirection http vers https, sinon vous allez avoir droit un message d’erreur du type:

044

Pour ce faire, ajouter un dièse ‘#’ devant l’instruction de redirection.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
# Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

N’oubliez pas de réactiver la redirection, une fois le certificat final obtenu. Ne vous inquiétez pas, je vais vous le rappeler un peu plus tard dans ce chapitre.

4. Test de vérification avant installation du certificat

Poursuivons notre aventure! Faisons un test de requête de certificat.

/opt/letsencrypt$ sudo letsencrypt-auto certonly --test-cert

Selectionner l’option 2 « Place files in webroot directory (webroot)

038

Entrez votre adresse email

039

Accepter les conditions d’utilisation

040

Entrer l’URL, .netlib.re par exemple, pour accéder à votre serveur Owncloud

041

Entrer le chemin du webroot, /var/www/html (sur Debian par défaut)

042

043

Vérifier le résultat

045

# ls /etc/letsencrypt/live/.netlib.re
  cert.pem chain.pem fullchain.pem privkey.pem

Si tout est bon et que le résultat de ce test vous convient, lancer maintenant l’installation.

5. Installation du certificat

Rappeler vous que je me suis enregistré sur deux domaines différents (netlib.re, et nsupdate.info qui est l’alias du premier). Il me faut donc un seul certificat qui serait valide pour ces deux domaines à la fois.

Afin d’automatiser un peu plus les la demande de certificat et d’éviter de retaper toutes les informations comme lors du test, j’ai ajouté d’autres paramètres à la commande letsencrypt-auto.

/opt/letsencrypt$ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  --webroot-path /var/www/html/ \
  --email admin@example.com \
  --domains .netlib.re \
  --domains .nsupdate.info

Pour une version allégée de la même commande,

/opt/letsencrypt $ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  -w /var/www/html/ \
  -m admin@example.com \
  -d .netlib.re \
  -d .nsupdate.info

046

Le message dit que vous avez déjà un certificat associé au même nom de domaine que celui entré manuellement, puis nous demande ce qu’on veut faire. J’ai choisi l’option 2, qui va remplacer/renouveller le certificat existant.

Si tout s’est bien passé, vous devriez avoir un message avec la date d’expiration de votre certificat, comme ci-dessous.

047

Le certificat signé par le CA va se placer ensuite dans le dossier /etc/letsencrypt/live/.

6. Vérification

Vérifions justement le contenu du dossier /etc/letsencrypt/live/, dans lequel doit se trouver toutes les clés générées par les commandes ‘letsencrypt’ ou ‘letsencrypt-auto’.

$ sudo ls -a /etc/letsencrypt/live/.netlib.re/
  . .. cert.pem chain.pem fullchain.pem privkey.pem
  • privkey.pem – clé privée à ne jamais partager avec personne
  • cert.pem – certificat du serveur uniquement
  • chain.pem – certificat pour root et intermédiaire uniquement
  • fullchain.pem – ensemble de tous les certificats (chain.pem + cert.pem)
$ sudo ls -l /etc/letsencrypt/live/.netlib.re/
  total 0
  lrwxrwxrwx 1 root root 45 Apr 19 22:58 cert.pem -> ../../archive/linuxintosh.netlib.re/cert3.pem
  lrwxrwxrwx 1 root root 46 Apr 19 22:58 chain.pem -> ../../archive/linuxintosh.netlib.re/chain3.pem
  lrwxrwxrwx 1 root root 50 Apr 19 22:58 fullchain.pem -> ../../archive/linuxintosh.netlib.re/fullchain3.pem
  lrwxrwxrwx 1 root root 48 Apr 19 22:58 privkey.pem -> ../../archive/linuxintosh.netlib.re/privkey3.pem 

$ sudo ls -l /etc/letsencrypt/archive/.netlib.re/
  total 48
  -rw-r--r-- 1 root root 1870 Apr 8 19:11 cert1.pem
  -rw-r--r-- 1 root root 1850 Apr 8 19:51 cert2.pem
  -rw-r--r-- 1 root root 1850 Apr 19 22:58 cert3.pem
  -rw-r--r-- 1 root root 1675 Apr 8 19:11 chain1.pem
  -rw-r--r-- 1 root root 1647 Apr 8 19:51 chain2.pem
  -rw-r--r-- 1 root root 1647 Apr 19 22:58 chain3.pem
  -rw-r--r-- 1 root root 3545 Apr 8 19:11 fullchain1.pem
  -rw-r--r-- 1 root root 3497 Apr 8 19:51 fullchain2.pem
  -rw-r--r-- 1 root root 3497 Apr 19 22:58 fullchain3.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:11 privkey1.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:51 privkey2.pem
  -rw-r--r-- 1 root root 1708 Apr 19 22:58 privkey3.pem 

$ sudo ls -l /etc/letsencrypt/keys/
  total 12
  -rw------- 1 root root 1704 Apr  8 19:11 0000_key-letsencrypt.pem
  -rw------- 1 root root 1704 Apr  8 19:51 0001_key-letsencrypt.pem
  -rw------- 1 root root 1708 Apr 19 22:58 0002_key-letsencrypt.pem

Pour information, /etc/letsencrypt/archive et /etc/letsencrypt/keys contiennent toutes les anciennes clés et certificats, par contre /etc/letsencrypt/live n’en contient que la dernière version.

Vérifier ensuite qu’il n’y a pas de fichiers qui traine dans le dossier .well-known/acme-challenge/. Si c’est le cas, supprimer tout ce qu’il contient comme information.

$ sudo -s
# rm /var/www/owncloud/letsencrypt/.well-known/acme-challenge/*

 

Mise-à-jour des informations de Owncloud

1. Réactiver la redirection HTTP vers HTTPS

Une fois que votre certificat émis, supprimer le dièse ‘#’ devant « Redirect » afin de pouvoir rediriger de nouveau, les traffics HTTP vers HTTPs.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
  Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

2. Mettre à jour les informations du vHost avec le nouveau certificat signé

Désactiver les certificats auto-signés puisqu’on n’en a plus besoin, puis ajouter le chemin d’accès aux clés et chaînes généré par Let’s Encrypt, dans le fichier de configuration de owncloud.

$ sudo vim /etc/apache2/sites-available/ownCloud.conf

  # Self-signed certificate
  #
  #SSLCertificateFile /etc/ssl/localcerts/owncloud.pem
  #SSLCertificateKeyFile /etc/ssl/localcerts/owncloud.key

  # Let's Encrypt certificate
  #
  SSLCertificateFile /etc/letsencrypt/live/.netlib.re/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/.netlib.re/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/.netlib.re/fullchain.pem

  # Certificate signed by CA
  #
  #SSLCACertificateFile /Path/to/CA/Certificate
  #SSLVerifyDepth 2

3. Vérifier l’état de connection à votre page

Vous devriez pouvoir accéder directement à votre page, sans avoir à valider quoi que ce soit.

048
Navigateur – Chromium

049

 Navigateur – Firefox

4. Un petit test de plus!

Une fois n’est pas coutume, lancer de nouveau un test sur Qualys SSL Labs et voyer le résultat.

060
Cette fois ci, le test passe et j’obtient un A+ comme note. Youpiii!

Quelques informations supplémentaires

1. Renouvellement du certificat

Le certificat signé par Let’s Encrypt n’est valide que pour une durée de 90jours maximum. Il est donc préférable de s’y prendre un peu à l’avance pour mettre à jour notre certificat. Vous pouvez le faire de façon manuelle ou automatique.

Avec la méthode manuelle, taper dans une console,

/opt/letsencrypt$ sudo ./letsencrypt-auto renew
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  sudo /home/USERNAME/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Par contre je n’ai pas réussi à faire fonctionner le renouvellement automatique avec CRON. J’ai essayé plusieurs fois, mais j’ai des doutes sur la fonctionnalité de la commande ci-dessous, bien qu’en théorie, çà devrait marcher.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

  crontab
  * * */1 * * /opt/letsencrypt/letsencrypt-auto renew >> /var/log/apache2/letsencrypt-renew.log 2>&1

Ici, Cron doit exécuter la commande « letsencrypt-auto renew » une fois par jour. A chaque exécution de cette commande, je devrais avoir une information dans le fichier /var/log/apache2/letsencrypt-renew.log, ainsi qu’un email doit être envoyé du serveur, mais nada.
J’ai noté qu’en y apportant une petite modification dans la commande, comme par exemple, si je veux effectuer une requête de renouvellement de certificats à la minute, la commande semble fonctionner après quelques bidouilles. Je ne vais pas trop tarder dessus. Je pense avoir effectué suffisament de test pour vérifier que la commande de renouvellement de certificat fonctionne sans problème, mais couplée avec cron, rien ne va plus!

Voici ce que j’ai réussi à récupérer dans les logs quand çà fonctionne.

/var/log/apache2$ cat letsencrypt-renew.log
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Dans les notes sur la page officielle de Let’s Encrypt, il est dit qu’ils vont sortir un script bientôt pour automatiser la tâche de renouvellement des certificats.

Sinon, utiliser l’installeur Apache ou Nginx au lieu de Webroot comme j’ai procédé dans cet article. Ces installeurs vont gérer directement le renouvellement des certificats, sans que vous ayez à vous soucier de quoi que ce soit.

2. Révocation du certificat

Si pour une raison quelconque, vous souhaitez révoquer votre certificat de Let’s Encrypt, taper la commande ci-dessous en précisant le nom de domaine concerné.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem

Vous n’aurez pas de confirmation de révocation du certificat. Par contre, si vous retaper exactement la même commande, vous allez avoir un message vous prévenant que le certificat a déjà été révoqué.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/linuxintosh.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  An unexpected error occurred:
  The request message was malformed :: Certificate already revoked
  Please see the logfiles in /var/log/letsencrypt for more details.

Vous pouvez le vérifier en accédant à votre page.

061

3. Mise-à-jour du client letsencrypt

Pour mettre à jour le client letsencrypt, accéder au dossier /opt/letsencrypt, puis taper la commande « git pull ».

$ cd /opt/letsencrypt
$ sudo git pull

N’oubliez pas que le client Let’s Encrypt est toujours en mode Béta. Prennez donc le temps de visiter la page officielle de Let’s Encrypt pour lire les informations sur les dernières mise-à-jour.

Les articles ci-dessous sont très intéressants. Je ne peux que vous le recommander. Si l’anglais vous rébute, utilisez l’outil itool de Google pour traduire ces pages.

Why Use a Certificate?
Fishing for Hackers: Analysis of a Linux Server Attack

Sources et Références

User script location in Debian
Fully automate Let’s Encrypt certificate on Debian using central webroot Folder
Client certificate authentication
Apache directives
Set server wide ssl configuration
Install Let’s Encrypt to Create SSL Certificates
Crontab generator
Missing Docs for cert.pem, chain.pem, fullchain.pem, etc #608
Where are my certificates?

Les fichiers journaux

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 6. Les fichiers journaux

Vous vous êtes peut-être demandé où se situe les fichiers journaux (logs) sur votre serveur? C’est ce que je vais traiter dans cette partie. Je ne vais cependant pas me limiter à celà, puisque je vais vous aider à configurer un serveur SMTP pour automatiser l’envoie de certains fichiers journaux par courrier (email).
Je n’ai pas beaucoup parlé des fichiers journaux jusque ici. Pourtant, ces derniers sont très important, surtout pour la compréhension et l’aide au dépannage des problèmes qui peuvent survenir sur nos serveurs.

Où sont enregistré les messages d’erreur du serveur Apache?

Soyons curieux et jettons un coup d’oeil dans le fichier de configuration de /etc/apache2/apache2.conf. Faites une recherche avec le mot clé ErrorLog.

Voici ce que vous devriez trouver.

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a 
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a 
# container, that host's errors will be logged there and not here.
#
ErrorLog ${APACHE_LOG_DIR}/error.log

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
LogLevel warn

Ici, il est précisé que les messages d’erreurs doivent se trouver dans le dossier donné par la variable ${APACHE_LOG_DIR}/.Pour avoir des informations sur les variables dans apache, ouvrez donc le fichier /etc/apache2/envvars et faites une recherche encore une fois.

# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX

Comme on le voit ici, tous les fichiers de log vont être sauvegardés dans le dossier /var/log/apache2/.

Voyons maintenant ce que contient le fichier /var/log/apache2.

$ ls /var/log/apache2
access.log
access.log.1
access.log.X.gz
!---tronquée---!
error.log
error.log.1
error.log.Y.gz
!---tronquée---!
other_vhosts_access.log

On note qu’il y a trois types de fichiers, que je vais présenter un par un ci-dessous.

1. Apache Error Log File
Ce fichier de log (ou fichier journal) contient tous les détails de ce qui s’est mal passé sur le serveur Apache (messages d’erreurs), ainsi que les information de diagnostic, pour y remédier.

2. Apache Access Log File
Le serveur Apache enregistre toutes les requêtes entrantes dans ce fichier journal.

3. Apache vHosts Access File
Les requêtes entrantes en destinations des différents hôtes virtuels y sont enregistrées dans ce fichier.

Maintenant qu’on a vu où sont enregistrés les fichiers journaux, il faut qu’on précise aussi quel niveau d’alerte doit être récupé. Vous avez différents niveaux, mais par défaut, Apache récupère tous les alertes de type WARN.

# emerg : Messages Urgents - Le système est inutilisable
# alert : Messages d’actions qui doivent être effectuées immédiatement
# crit : Messages critiques
# error : Messages d’erreur
# warn : Messages d’avertissement (par défaut)
# notice: Messages normaux mais significatives
# info : Messages d’informations
# debug : Messages de débogage
# trace[1-8]

Et, en ce qui concerne les hôtes virtuels?

Pour pour chaque hôte virtuel, vous pouvez aussi définir quel type d’information vous souhaitez voir dans les fichiers journaux, le niveau d’alerte ainsi que le dossier où les enregistrer.

La template pour s’inspirer des informations à placer dans notre fichier owncloud.conf, se trouve dans le fichier /etc/apache2/sites-enabled/000-default.conf.

$ sudo vim /etc/apache2/sites-available/owncloud.conf

	ServerName .MonDomai.ne
	Redirect permanent / https://.MonDomai.ne

	LogLevel info ssl:warn

	ErrorLog /mon/dossier/error.log
	CustomLog /mon/dossier/access.log combined

Dans cet exemple, nous allons récupérer tous les traffics en HTTPS (level Warning), ainsi que les traffics autre que ceux utilisant le protocol TLS/SSL (level Info), vers notre serveur Owncloud ainsi que ceux en destination de notre serveur Apache.
Je vais m’arrêter ici sans rentrer dans les détails. Vous pouvez toujours lire l’article sur les fichier journaux Apache si vous souhaitez en savoir un peu plus.

Comment faire pour recevoir par courriel, certains fichiers journaux?

Déjà, avant d’aller plus loin, il faut se poser la question de l’utilité d’envoie des fichiers journaux par courriel. Chaque administrateur a sa propre raison de le faire. Personnelement, j’aime bien recevoir par courriel, toutes les activités qui se passent sur mon serveur. Logwatch est de ce fait, un très bon choix.

Installation et configuration de Logwatch

Logwatch est au fait, un script écrit en perl. Son installation et sa configuration est très simple comme nous allons le voir ci-dessous.

$ sudo apt-get install logwatch
!---Tronquée---!
The following extra packages will be installed:
bsd-mailx exim4-base exim4-config exim4-daemon-light libdate-manip-perl
liblockfile-bin liblockfile1 libsys-cpu-perl
Suggested packages:
mail-reader eximon4 exim4-doc-html exim4-doc-info spf-tools-perl swaks
fortune-mod
Recommended packages:
mailx
Vérifier que le programme fonctionne correctement.
$ logwatch
 ################### Logwatch 7.4.0 (03/01/11) #################### 
        Processing Initiated: Wed Apr 13 22:32:28 2016
        Date Range Processed: yesterday
                              ( 2016-Apr-12 )
                              Period is day.
        Detail Level of Output: 0
        Type of Output/Format: stdout / text
        Logfiles for Host: raspi
 ################################################################## 
 
 --------------------- httpd Begin ------------------------ 

 Connection attempts using mod_proxy:
    a.b.c.d -> www.xxxxxxx.com:port: 1 Time(s)
    e.f.g.h -> www.yyyyyyy.com:port: 4 Time(s)
 
!--Tronquée--!
 
 ---------------------- httpd End ------------------------- 

 
 --------------------- pam_unix Begin ------------------------ 

 sudo:
    Authentication Failures:
       USERNAME(1000) -> USERNAME: 1 Time(s)
    Sessions Opened:
       USERNAME -> root: 14 Time(s)
 
 systemd-user:
    Unknown Entries:
       session closed for user USERNAME: 3 Time(s)
       session opened for user USERNAME by (uid=0): 3 Time(s)
 
 
 ---------------------- pam_unix End ------------------------- 

 
 --------------------- SSHD Begin ------------------------ 

 
 Users logging in through sshd:
    USERNAME:
       i.j.k.l: 3 times
 
 ---------------------- SSHD End ------------------------- 

 
 --------------------- Sudo (secure-log) Begin ------------------------ 

 
 USERNAME => root
 ----------------
 /bin/cat                       -   1 Time(s).
 /bin/ls                        -   3 Time(s).
 /sbin/iptables                 -   4 Time(s).
 /sbin/iptables-restore         -   2 Time(s).
 /usr/bin/crontab               -   2 Time(s).
 /usr/bin/vim                   -   2 Time(s).
 
 ---------------------- Sudo (secure-log) End ------------------------- 

 
 --------------------- Disk Space Begin ------------------------ 

 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       7.2G  3.6G  3.4G  52% /
 devtmpfs        483M     0  483M   0% /dev
 /dev/mmcblk0p1   60M   20M   41M  34% /boot
 
 
 ---------------------- Disk Space End ------------------------- 

 
 ###################### Logwatch End #########################

Editer ensuite le fichier /etc/cron.daily/000logwatch, pour que le serveur vous envoie automatiquement les informations obtenues par la commande logwatch comme ci-dessus, par email.

$ sudo vim /etc/cron.daily/00logwatch

Remplacer la ligne,

/usr/sbin/logwatch --output mail

Par

/usr/sbin/logwatch --mailto mon@adresse.mail --detail high

Pour en savoir un peu plus sur CRON, je vous renvoie sur cette page.

Configuration du serveur email

Si vous n’avez pas installé de serveur email, autre que celui installé par défaut sur Debian (Exim), installer l’outil Mailutils, qui vous permettra d’envoyer des emails.
L’installation de l’outil GNU/Mailutils est très simple.
$ apt-get install mailutils
Taper ensuite la commande « mu-tool info » pour avoir plus d’information sur ce que l’outil peut gérer.

$ mu-tool info
VERSION=2.99.98
SYSCONFDIR=/etc
MAILSPOOLDIR=/var/mail/
SCHEME=mbox
LOG_FACILITY=mail
IPV6
USE_LIBPAM
HAVE_LIBLTDL
WITH_KYOTOCABINET
WITH_GNUTLS
WITH_GSASL
WITH_GSSAPI
WITH_GUILE
WITH_PYTHON
WITH_PTHREAD
WITH_READLINE
HAVE_MYSQL
WITH_LDAP
WITH_LIBWRAP
ENABLE_VIRTUAL_DOMAINS
ENABLE_IMAP
ENABLE_POP
ENABLE_MH
ENABLE_MAILDIR
ENABLE_SMTP
ENABLE_SENDMAIL

Vérifier maintenant que vous pouvez envoyer un email du serveur.

Pour faire simple, j’envoie un email sans contenu, d’où le message « le corp du message est vide, etc. »

$ mail -s "Hello World!" mon@adresse.mail < /dev/null
Null message body; hope that's ok
!--Tronquée--!
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

mon@adresse.mail
Mailing to remote domains not supported

Ici, le message d’erreur est très clair. Le message ne peut pas être envoyé, puisque l’envoie d’email à un serveut distant n’est pas supporté.

Vérifions la configuration de notre serveur email, Exim.

$ sudo dpkg-reconfigure exim4-config

Choisissez « internet site », afin de pouvoir envoyer et recevoir les emails via le protocol SMTP.

050

Donner un nom au système email.

051

Ne rien modifier sur cette page.

052

Pour les autres destinations, j’ai choisi le même nom qu’à l’étape précédente.

053

Passer à la page suivante sans rien modifier sur celle-ci.

054

Pareil pour cette page.

055

Cliquer sur NON à la demande de garder un nombre minimal de requêtes DNS.

056

Choisissez ensuite l’option mbox.

057

Choisissez de ne pas découper le fichier de configuration de Exim en plusieurs petits fichiers configurables individuellement.

058

Ajouter toutes les adresses emails sur lesquelles vous souhaitez recevoir les alertes. L’ajout de root n’est pas obligatoire.

059

Mettez à jour les informations du Parefeux

Ajouter une règle dans le parefeux pour autoriser les paquets SMTPs à sortir de votre réseau.

$ sudo vim /etc/iptables.firewall.rules
# Allows SMTP access
-A INPUT -p tcp --dport 25 -j ACCEPT

$ sudo iptables-restore < /etc/iptables.firewall.rules

Vérifier ensuite que la nouvelle règle est prise en compte.

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere tcp dpt:urd
ACCEPT tcp -- anywhere anywhere tcp dpt:submission
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Envoyer un email de test en ligne de commande, puis de vérifier si vous l’avez reçu dans votre boîte email.

$ mail -s "Hello World!" mon@adresse.mail < /dev/null
Null message body; hope that's ok

Sources et Réferences

How To Configure Logging And Log Rotation In Apache On An Ubuntu VPS
Log Files
Install Logwatch To Keep An Eye On Things
Linux mail command examples – send mails from command line
How To Install the Send-Only Mail Server « Exim » on Ubuntu 12.04
How to send email from the Linux command line
Exim Internet Mailer

Connection SSH

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 5. Connection SSH

Qu’est ce que le SSH?

« Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés.
Le protocole SSH a été conçu avec l’objectif de remplacer les différents programmes rlogin, telnet, rcp, ftp et rsh. » (Wikipedia)

Pour faire simple, il y a deux manières pour se connecter à un serveur distant.

Un de façon non sécurité, et que l’on déconseille fortement, puisque tout le traffic passe en mode clair sur le réseau. C’est comme si vous communiquer avec votre banquier à l’autre bout de la rue, avec un mégaphone, pour lui faire part de vos possessions et biens, ainsi que leurs emplacements.

L’autre méthode serait de chiffrer tous les échanges entre votre poste et le serveur, afin que ces communications restent confidentiels à l’abris des regards indiscrets.

Pas mal d’astuces sur la façon de mieux sécuriser l’accès au serveur SSH on déjà été proposés dans les précédents chapitre, donc je ne vais pas m’étaler dessus.Ici, je vais essayer d’ajouter quelques points non vus précédement.

Gel du terminal après disconnection du SSH

Vous avez certainement noté un problème de « gel » de votre terminal, un certain temps d’inactivité, lorsque vous vous connectez en SSH à votre serveur, et que vous n’arrivez plus à prendre la main dessus! C’est tout à fait normal, puisqu’un fois la session en SSH terminée, votre machine se déconnecte du serveur, mais ne vous laisser pas reprendre la main sur la console.

Pour y remédier, vous avez une liste de méthode.

Méthode 1:

Taper deux fois la touche « ENTREE » puis successivement sur les touches « ~ » et « . », sans les guillemets.

$ man ssh
!---Tronquée---!
The supported escapes (assuming the default ‘~’) are:
~.      Disconnect.
!---Tronquée---!

Méthode 2:

Si vous pensez que cette solution n’est pas pratique, vous pouvez toujours ajouter une ligne avec la commande « ~. », sans les guillemets bien sûr, dans le fichier .ssh/config de votre RPi.

raspi$ vim ~/.ssh/config
~.
raspi$ sudo service ssh restart

Méthode 3:

Une solution des plus classique, serait d’éditer l’un des fichiers de configuration du serveur ou de votre poste de travail. Il n’est pas nécessaire de le faire sur les deux à la fois.

SSH serveur

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
raspi$ sudo service sshd restart

N’oublier pas de redémarrer le service correspondant à chaque modification d’un fichier de configuration sur un serveur.

SSH client

Ajouter les deux lignes ci-dessous dans le fichier dans la configuration locale de votre ssh.

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

L’option ServerAliveInterval va garder la connection active même si l’utilisateur est inactif. Et l’option ClientAliveInterval va tout de même envoyer des paquets vides vers le serveur toutes les 60 secondes, pour garder la connection active.

Méthode 4:

Sur le même principe qu’à la méthode 3, vous pouvez ajouter comme argument ServerAliveInterval, lorsque vous vous connectez en SSH.

monOrdi$ ssh -o ServerAliveInterval=60 user@example.com

Méthode 5:

Configurer PUTTY, avec une valeur de keepalive interval:

monOrdi$ sudo apt-get install putty

037

 

Création d’une Banière personnalisée

Afficher un message d’acceuil (Message du jour ou MOTD) lors de la connection en SSH, est une très bonne idée. Une banière peut servir à afficher un message d’avertissement, etc., celà dépend de vos besoins.
Le message d’information affiché par défaut, lors de la connection sur notre serveur RPi nous donne les informations d’utilisation du logiciel, ainsi que les informations sur la dernière connection réussie sur le serveur.

018

Pour donner une touche plus personnelle à votre banière, rendez-vous dans le fichier /etc/motd et apportez-y toutes les modifications nécessaires.

Si comme moi, vous êtes nostalgique du logo de tux, alors récupérer le logo sur github. Copier  ensuite avec un outil graphique en mode root (gvim, gksudo gedit, etc.), les lignes situées entre BEGIN_LOGO et END_LOGO.
Mais avant tout, garder tout de même une copie de l’ancien fichier motd.

raspi$ sudo mv  /etc/motd /etc/motd_old

Il va de soit que, pour se connecter en mode graphique, il nous faut un visionneur de bureau distant, Remmina par exemple, et qu’il faut aussi ouvrir le port 3389 du parefeux de votre serveur RPi si ce n’est pas le cas.

raspi$ sudo gvim /etc/motd

Et voici le résultat avec le choix de « classic.log ».

019

Customisation du MOTD

Pour un tunning un peu plus poussé de votre page, voici deux liens qui pourraient vous être utile: Customize your MOTD – LINUX,et Custom MOTD – Message of the Day.

Mettre à jour de la passephrase

Dans le cas où vous avez créé une passphrase lors de la création de clés pour une connection sécurisée entre votre poste et le serveur RPi, si comme moi vous avez utilisé un mot de passe simple pour faire des tests, il est donc temps de mettre un mot-de-passe un peu plus sûr.
Pour ce faire, à partir de l’ordinateur sur lequel vous avez généré la clé, taper,

monOrdi$ cd ~/.ssh/

monOrdi$ ls
id_rsa id_rsa.pub
monOrdi$ ssh-keygen -f id_rsa -p

A lire

Je vous recommande aussi de lire les articles suivants, si vous souhaitez approfondir vos connaissances sur le SSH:

Secure Secure Shell
Awesome SSH
The ultimate ssh tips & tricks

Sources et Réferences

SSH – ubuntu-fr
Banner Files
OpenSSH Change a Passphrase With ssh-keygen command
Connecting to a server using SSH on Linux or Mac OS