Ce mémo a été publié le 15 août 2018 et peut contenir des informations qui peuvent être incomplètes, non mises à jour voir erronées du fait de son ancienneté. N'hésitez pas à compléter votre recherche sur des articles plus récents.
Rate this post

Mémo pour la configuration de mon serveur dédié chez Ikoula.

Problème de mot de passe root

[Edit] Il semblerait que le problème ne se produise plus.
A voir dans le temps.
[/Edit]

Un problème assez sympathique que j’ai rencontré est que si vous changez le mot de passe root et que vous supprimez les kernels non utilisés par la commande « $ apt autoremove », alors le mot de passe root est réinitialisé.
Très bizarre. Et à priori, Ikoula n’a pas de solution.

Donc voici un contournement que j’ai mis en place.

Ajouter un groupe sshusers

Ajouter la ligne suivante dans le fichier : /etc/ssh/sshd_config

Relancer le service SSH

Ajouter un utilisateur simple pour se connecter en SSH
Ne doit pas être dans la liste des sudoers.

Ajouter un utilisateur qui sera dans la liste des sudoers, mais pas dans le groupe sshusers.

Dans le répertoire de cet utilisateur, ajouter un fichier caché qui contiendra le mot de passe d’origine de root.
Ce fichier devra avoir les droits 600 et appartenir à root:root.

Maintenant, 2 choses :

  • Soit j’ai pensé à modifier le mot de passe root avec le mot de passe généré à la création de l’instance et tout va bien.
  • Soit je n’y ai pas pensé (ce qui est plus que probable 😉 ) et j’ai plus qu’à modifier le mot de passe root avec mon utilisateur sudo et la commande « $ sudo passwd root » pour remettre mon mot de passe.

Activer la swap

Par défaut, la swap n’est pas activée.

Vérification :

Résultat : 0

Passer la configuration à 10.

  1. Editer le fichier /etc/sysctl.conf
  2. Rechercher la ligne vm.swappiness = 0.
  3. Modifier à 10.
Idéalement, relancer le serveur.
Sinon, exécuter ces commandes pour la prise en compte immédiate :

SSMTP

Présent par défaut.
Permet au serveur d’envoyer des e-mails à l’aide d’un compte qui permet la connexion SMTP.
Utile pour la suite pour recevoir les e-mails de sécurité ou de mise à jour du système.

Fichier : /etc/ssmtp/revaliases

Fichier : /etc/ssmtp/ssmtp.conf

Sécurité

SSH

Dans le fichier /etc/ssh/sshd_config

  • Port 11022 : Changer le port
  • PermitRootLogin no : Ne pas permettre la connexion root

Firewall iptables

Chargement des règles au boot

Créez le script qui utilise ce fichier de configuration au démarrage : /etc/network/if-pre-up.d/iptables

Appliquez les droits d’exécution sur ce fichier :

Enregistrer les log iptables dans une log à part

Par défaut, les règles iptables enregistrent la sortie vers la log /var/log/messages.
On va les rediriger vers /var/log/iptables.log

Créez le fichier /etc/rsyslog.d/10-iptables.conf :

Redémarrez rsyslog :

Configuration logrotate pour iptables

Le fichier iptables.log va grossir et doit être purgé pour éviter que le disque doit plein.
Créer le fichier /etc/logrotate.d/iptables

On garde 7 jours de logs compressées.

A partir de là, toutes les règles du style de celle présentée ci-dessous ajouteront une ligne dans le fichier de log /var/log/iptables.log

Règles de base

Fichier : /etc/iptables.up.rules

Charger les règles :

PSAD

Installation

Configuration

Editer le fichier /etc/psad/psad.conf

Modifier ce fichier en cherchant et modifiant les paramètres suivants :

Modifier les 2 premières lignes EMAIL_ADDRESSES et HOSTNAME.

IPT_SYSLOG_FILE est configuré pour analyser le fichier /var/log/iptables.log défini plus haut dans ce mémo.

Dans le fichier /etc/psad/auto_dl, ajoutez cette ligne pour désactiver la détection sur 127.0.0.1 :

Coupler PSAD et IPTABLES

Si fail2ban est déjà installé, il faut l’arrêter.
Sinon, les règles qu’il ajoute seront enregistrée dans le fichier /etc/iptables.up.rules.

Exécuter ces commande :

Enregistrez les modifications dans le fichier /etc/iptables.up.rules :

Editez le fichier /etc/iptables.up.rules et ajoutez les lignes « PSAD_BLOCK_* » après « LOG » et avant « DROP » :

Enregistrer les règles iptables et relancer Fail2ban et Psad :

Vérifier l’état de Psad :

Résultat :

Toutes les lignes doivent avoir « [+] ».
Si il y a un « [-] », faut corriger.

Dans le cas du résultat ci-dessus : « [-] psad: pid file /var/run/psad/psadwatchd.pid does not exist for psadwatchd on domain.tld »
Solution trouvée ici : https://carteryagemann.com/psad-on-pi.html

Créer le fichier /etc/systemd/system/psadwatchd.service :

Démarrer psadwatchd :

Vérifier que tout est en ordre :

Activer le service au démarrage du serveur :

Mise à jour automatique

Pour une mise à jour hebdomadaire, il faut créer un fichier /etc/cron.d/psad

Relancez le service cron pour la prise en compte :

Quelques commandes utiles

Liste des IP bloquée :

Supprimer une ip bloquée :

Supprimer toutes les ips bloquées :

Mise à jour manuelle des signatures :

Fail2ban

Installation :

NE MODIFIER AUCUN FICHIER avec l’extension *.conf. Ils peuvent être remplacés lors des mises à jour.
Pour surcharger, il suffit de créer le même fichier avec l’extension *.local.

Créer le fichier : /etc/fail2ban/jail.d/jail.local

Pour l’option « action », consulter les autres actions disponibles dans le fichier /etc/fail2ban/jail.conf
« action_mwl » envoi un e-mail à chaque arrêt/relance de Fail2Ban et à chaque bannissement détecté.

Relancer Fail2Ban pour la prise en compte :

Vérifier les jails activées :

Résultat :

Vérifier également la boîte e-mail configurée dans jail.local.
Au moins 6 e-mails sont arrivés !

Pour ajouter une log à analyser, des filtres sont déjà disponibles dans le répertoire : /etc/fail2ban/filter.d
Pour les activer, il faut juste copier le nom du fichier sans l’extension, et l’ajouter dans le fichier jail.local.

Ex pour Nginx :

Le fichier présent : /etc/fail2ban/filter.d/nginx-limit-req.conf
Donc il faut ajouter ces lignes dans le fichier /etc/fail2ban/jail.d/jail.local

Au besoin ajouter les paramètres à surcharger puis relancer le service Fail2ban pour la prise en compte.
Pas compliqué.

Logwatch – Surveillance des journaux

Permet d’analyser les logs et de recevoir un e-mail sur l’état du serveur.
Plus d’information sur le site de SourceForge.net.

Installation

Créer le répertoire cache :

Configuration

Il ne faut pas modifier le fichier de configuration d’origine.
Il faut le copier dans le répertoire /etc/logwatch/conf/ et modifier ce dernier :

Idem pour les fichiers qui décrivent les services ou logsfiles.
Origine : /usr/share/logwatch/default.conf/services
Destination : /etc/logwatch/conf/services

Modification de l’e-mail de destination des rapports

Éditer le fichier /etc/logwatch/conf/logwatch.conf
Modifier les lignes :

Modifier le sujet de l’e-mail.
Ajouter cette ligne à la fin du fichier /etc/logwatch/conf/logwatch.conf :

Afficher le rapport dans la console :

Pour envoyer le rapport à une adresse spécifique :

Un rapport sera envoyé tous les jours.
Vérifier la présence du fichier /etc/cron.daily/00logwatch

Recevoir les mises à jour par email

Vous pouvez configurer vos serveurs pour qu’ils exécutent un « apt update », télécharge les nouveaux fichiers et vous avertis que des mises à jour sont disponibles par email.
A vous de les installer manuellement.

L’installation est décrite sur ce mémo : « Debian – Recevoir la liste des mises à jour »

NGINX / PHP / MariaDB

Installation de PHP FPM 7.2

Source : https://packages.sury.org/php/README.txt

Installation de Nginx

Ajouter le dépôt backports :

Fichier : /etc/apt/sources.list.d/backports.list

Installer Nginx :

Let’s Encrypt

Inspiré de : https://www.grafikart.fr/formations/serveur-linux/nginx-ssl-letsencrypt

La dernière commande prend du temps, plus de 20min…

Tester le renouvellement du certificat :

Fichier /etc/nginx/site-availlable/domain.tld :

 

Autre configuration pour un SSL A+

Activer la configuration :

PHP-FPM multi user

Créer l’utilisateur sans répertoire home :

Fichier /etc/nginx/nginx.conf :

Fichier /etc/php/7.2/fpm/pool.d/new_site.conf :

Modifier :

Fichier : /etc/nginx/sites-available/new-site

Relancer PHP et Nginx

 

MariaDB