Skip to content

Instantly share code, notes, and snippets.

@hexablob
Last active March 19, 2023 16:06
Show Gist options
  • Star 34 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save hexablob/691dc593bc2eecac28150e376323a58f to your computer and use it in GitHub Desktop.
Save hexablob/691dc593bc2eecac28150e376323a58f to your computer and use it in GitHub Desktop.
Installation d'un serveur Debian ; de A à Z.

Installation d'un serveur Debian ; de A à Z.

⚙️ Installation & Configuration du système d'exploitation

La première étape consiste à sélectionner la distribution système Debian 10 dans le menu déroulant lors de la commande de votre nouveau Serveur dédié / VPS chez votre hébergeur préféré.

Procédez ensuite à l'installation de votre serveur avec les paramètres par défaut et veillez à ne pas personnaliser la répartition de l'espace disque des partitions systèmes.

Une fois l'installation effectuée, connectez-vous au serveur en SSH avec les identifiants que vous aurez normalement reçus par mail (en toute logique le login par défaut est debian, s'il ne s'agit pas là dans certains cas des identifiants root.) -- pas de soucis, l'utilisateur par défaut fait dans une grande majorité des cas déjà parti des sudoers système. --

Lors de votre première connexion SSH au serveur, il faudra impérativement mettre à jour l'OS pour être sûr de bénéficier de la dernière version de l'OS qui comprennent très souvent les dernières mises à jour de sécurité de la distribution :

sudo apt update && sudo apt upgrade

⚠️ Avant d'aller plus loin, changez votre mot de passe -- qui je vous le rappelle vient de vous être communiqué par mail ! -- 😱 grâce à la commande : sudo passwd

🔐 Sécurisez votre serveur

La sécurité de votre serveur est un élément fondamental à ne pas négliger pour la vie de votre serveur. Peu importe que votre serveur soit "visité" ou bien qu'il ne soit destiné qu'à "voir des flux transités". C'est une étape cruciale qui doit être prise très au sérieux DÈS le début. A différentes échelles, en fonction de nombreux factures que vous ne pourrez prévoir, un certain nombre de personnes mal intentionnées (ou des robots) vont chercher, -- pour des raisons qui vous échapperont bien souvent -- à se connecter à votre serveur par tous les moyens.

La première étape pour sécuriser votre serveur relève de l'observation et de l'analyse. Vous avez de la chance car sur un serveur Linux la grande majorité des actions internes et externes sont enregistrées dans des fichiers de logs systèmes et applicatifs.

Pour ce faire il existe plusieurs outils d'analyse et surveillance. Le premier dont je recommande l'installation est fail2ban.

fail2ban est une application qui analyse les logs de divers services (SSH, Apache, FTP…) en cherchant des correspondances entre des motifs définis dans ses filtres et les entrées des logs. Lorsqu'une correspondance est trouvée une ou plusieurs actions sont exécutées. Typiquement, fail2ban cherche des tentatives répétées de connexions infructueuses dans les fichiers journaux et procède à un bannissement en ajoutant une règle au pare-feu iptables pour bannir l'adresse IP de la source.

Installez le paquet de la manière suivante : sudo apt install fail2ban

Vous pouvez décider de laisser la configuration par défaut qui est suffisante pour le démarrage. Vous pourrez par la suite personnaliser les règles de filtrage en fonction de vos besoins.

La seconde étape, fondamentale elle aussi, doit veiller à ce que toute connexion entrante soit sécurisée de bout en bout. Cela implique de ne pas utiliser de mot de passe pour les connexions via SSH (port 22). Si vous souhaiter autoriser un utilisateur -- quel qu'il soit -- à accéder à votre serveur, privilégiez la sécurisation par clé RSA (c'est ce que nous allons mettre en place ici).

Nous allons donc suivre les étapes suivantes :

  • Sécuriser l'accès via SSH (cela implique de :
    • Désactiver l'authentification SSH par saisie d'un mot de passe.
    • Restreindre l'authentification à distance avec le compte root.
    • Restreindre l'accès à IPv4 et IPv6.)
  • Installer et configurer un Firewall

Sécuriser l'accès via SSH

Commencez par créer un nouvel utilisateur : sudo adduser <username>

Faites de cet utilisateur un sudoer (quelqu'un qui peut "demander" d'exécuter des commandes en tant qu'administrateur du serveur) : usermod -a -G sudo <username>

Si vous êtes sur MacOS ou une distribution Linux, envoyez la clé RSA de votre machine physique au serveur distant avec la commande suivante : ssh-copy-id <username>@ip-du-serveur

Ouvrez le fichier de configuration du service SSH du serveur : sudo nano /etc/ssh/sshd_config

Trouvez les lignes suivantes :

PasswordAuthentication yes  
PermitRootLogin yes

Désactivez les accès par mot de passe et sur le compte root :

PasswordAuthentication no  
PermitRootLogin no

La dernière étape consiste à restreindre l'accès SSH aux connexions sur les interfaces IPv4 et IPv6 en modifiant la variable AddressFamily . Pour autoriser uniquement les connexions sur IPv4 (qui est largement suffisant dans 90% des cas) :

AddressFamily inet

Redémarrez le service SSH pour prendre en considération le nouveau paramétrage : sudo systemctl restart sshd Note importante : conservez au cas où une autre fenêtre où vous êtes déjà connecté(e) au serveur avant de redémarrer le service. Avoir une connexion active sur une seconde fenêtre vous permettra de corriger les erreurs si vous en rencontrez.

Installer et configurer un Firewall

Un Firewall permet de filtrer les connexions entrantes et sortantes. Nous allons donc procéder à l'installation de Uncomplicated Firewall (UFW) qui permet de configurer avec une certaine facilité les interfaces réseaux via iptables.

sudo apt install ufw

Attention, attention ! UFW interdit par défaut toutes les connexions entrantes et sortantes. Ce qui signifie que si vous ne terminez pas sa configuration correctement, vous pouvez vous retrouver bloqué(e) en dehors de votre serveur sans aucun moyen de récupérer votre accès SSH !

Dans un premier temps faites en sorte d'activer la connexion sur les protocoles SSH, HTTP, et HTTPS :

sudo ufw allow ssh  
sudo ufw allow http  
sudo ufw allow https

Vous pouvez désormais activer le service UFW : sudo ufw enable Si vous souhaitez consulter la liste des services autorisés / interdit par le Firewall : sudo ufw status A tout moment, vous pouvez décider de le désactiver de la manière suivante : sudo ufw disable

Autrement, la librairie firewall-cmd est une bonne alternative également.

🔥 Installation de librairies systèmes additionnelles

Ce que j'appelle des "librairies systèmes additionnelles" sont des librairies qui peuvent s'avérer être utiles à l'administration et la maintenance efficace et cohérente du serveur.

La première librairie utile s'intitulé htop et peut être installée directement via le gestionnaire de paquets de la distribution : apt install htop

Lorsque vous exécuterez htop dans votre terminal SSH, un moniteur de ressources hardware s'affiche. Il liste également tous les process en cours d'exécution (l'équivalent visuel d'un ps -aux) sur le serveur. L'avantage qu'il offre est avant tout visuel, mais ses fonctionnalités sont d'une véritable aide lorsque, par exemple, vous souhaitez kill un process en particulier. Vous pouvez rechercher un process en cours par son nom, son PID, puis le terminer en deux raccourcis clavier (touches F1-2-X de votre clavier). Vous pouvez également naviguer au clavier et taper "Entrée ⏎" de votre clavier.

🌍 Installation d'un serveur WEB

Apache2

sudo apt install apache2 installera la dernière version de Apache2 stable avec ses dépendances. N'oubliez pas d'activer les modules apache utiles suivants : a2enmod rewrite ssl

Nginx

sudo apt install nginx installera la dernière version de Nginx stable avec ses dépendances.

Librairies PHP

Pour bénéficier des dernières versions stables (et instables) de PHP, il ne faut pas installer les paquets officiels qui proviennent du repository officiel Debian ou votre hébergeur mais plutôt privilégier ceux qui sont récupérables depuis une source comme https://packages.sury.org/php/

Créez un fichier install_sury.sh et copiez-y à l'intérieur le contenu suivant :

#!/bin/bash
# To add this repository please do:

if [ "$(whoami)" != "root" ]; then
    SUDO=sudo
fi

${SUDO} apt-get -y install apt-transport-https lsb-release ca-certificates
${SUDO} wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
${SUDO} sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
${SUDO} apt-get update

Permettez l'exécution de ce script en tapant la commande : sudo chmod +x install_sury.sh Exécutez ensuite ce script : ./install_sury.sh Si tout s'est bien déroulé, vous pouvez supprimer ce script.

Installez ensuite PHP 7.3 avec : sudo apt install php7.3 Ainsi que d'autres dépendances utiles et fondamentales au bon fonctionnement de PHP et Laravel : sudo apt install php7.3-cli php7.3-common php7.3-curl php7.3-mbstring php7.3-mysql php7.3-xml

Base de données MySQL / MariaDB

Debian est livré par défaut avec le paquet mariadb-server qui est en réalité la version open source de MySQL : le moteur MariaDB.

Installez donc MariaDB avec la commande suivante : sudo apt install mariadb-server mariadb-client mariadb-common (sur une version Debian < 10, remplacez mariadb- par mysql-

Une fois effectué, vous devez configurer MySQL très facilement en exécutant la commande mysql_secure_installation. Vous pouvez laisser les valeurs par défaut suggérées par l'installateur interactif mais tâchez de définir un mot de passe au compte root MySQL.

Une fois l'installation terminée, vérifiez que le service MySQL est bien lancé : systemctl status mysqld Vous pouvez tester la connexion à la base de données : mysql -u root -p (saisissez votre mot de passe root)

Il vous faut dorénavant configurer les privilèges pour MariaDB, rien de bien compliqué.

Composer & NPM/YARN

Quoi de mieux que Composer pour gérer vos packages et dépendances PHP ?

Créez un fichier install_composer.sh et copiez-y à l'intérieur le contenu suivant :

#!/bin/sh

EXPECTED_SIGNATURE="$(wget -q -O - https://composer.github.io/installer.sig)"
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]
then
    >&2 echo 'ERROR: Invalid installer signature'
    rm composer-setup.php
    exit 1
fi

php composer-setup.php --quiet --install-dir=bin
RESULT=$?
rm composer-setup.php
exit $RESULT

Permettez l'exécution de ce script en tapant la commande : sudo chmod +x install_composer.sh Exécutez ensuite ce script : ./install_composer.sh Si tout s'est bien déroulé, vous pouvez supprimer ce script.

Quoi de mieux que NPM / YARN pour gérer vos dépendances NodeJS ?

Avant toute chose il faut pré-installer le PPA NodeJS (Personal Packages Archives) : Dernière version :

sudo apt-get install curl software-properties-common
curl -sL https://deb.nodesource.com/setup_12.x | sudo bash -

Version stable :

sudo apt-get install curl software-properties-common
curl -sL https://deb.nodesource.com/setup_10.x | sudo bash -

Enfin installez NodeJS et vérifiez la version installée :

sudo apt-get install nodejs
node -v
npm -v

🏡 Hébergement de votre application (Laravel pour exemple)

Vous avez installé Apache2 ou Nginx et vous décidez d'héberger votre application développée en Laravel ? Vous êtes au bon endroit.

La première étape consiste à déplacer votre projet au bon endroit. Votre application est donc à déplacer / déployer dans le dossier suivant : /var/www/html/<mon-application>

Installez ensuite les dépendances Laravel : composer install une fois que vous êtes dans le dossier de votre application. N'oubliez pas enfin d'éditer votre fichier d'environnement responsable notamment de la connexion à votre base de données : sudo nano /var/www/html/<mon-application>/.env

Ne pas omettre d'effectuer vos migrations et seeds si vous en avez : php artisan migrate && php artisan db:seed

Paramétrage du Virtual Host

Pour atteindre désormais l'endpoint HTTP(S) de votre application, vous devrez paramétrer ce que l'on appelle communément un "Virtual Host". Le Virtual Host est en effet important car il définit les règles d'accès à votre application. Sachant que votre application est accédée depuis l'utilisateur système www-data, vous devez redéfinir les droits de votre application depuis le dossier de cette dernière comme suit :

sudo chown -R www-data: .
sudo chmod -R ug+rwx storage bootstrap/cache

Si vous utilisez Nginx : Copiez le fichier de configuration Nginx par défaut et renommez-le en fonction du nom de domaine sur lequel vous souhaitez l'héberger (attention, ce dernier doit pointer dans sa configuration DNS vers l'adresse IP du serveur sur lequel vous vous trouver) : sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/mon-application.com

Editez-le pour le paramétrer de la manière suivante : sudo nano /etc/nginx/sites-available/mon-application.com

server {
    listen 80;
    listen [::]:80;

    . . .

    root /var/www/html/<mon-application>/public;
    index index.php index.html index.htm index.nginx-debian.html;

    server_name mon-application.com www.mon-application.com;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    . . .
}

Créez un lien symbolique pour que le fichier de configuration actif fasse référence à votre fichier de configuration : sudo ln -s /etc/nginx/sites-available/mon-application.com /etc/nginx/sites-enabled/

Enfin, redémarrez le service Nginx pour prendre en compte votre configuration : sudo systemctl reload nginx

Si vous utilisez Apache : Copiez le fichier de configuration Apache par défaut et renommez-le en fonction du nom de domaine sur lequel vous souhaitez l'héberger (attention, ce dernier doit pointer dans sa configuration DNS vers l'adresse IP du serveur sur lequel vous vous trouver) : sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/mon-application.com.conf

Editez-le pour le paramétrer de la manière suivante : sudo nano /etc/apache2/sites-available/mon-application.com.conf

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
	ServerName mon-application.com
    ServerAlias www.mon-application.com
    DocumentRoot /var/www/html/<mon-application>/public

	<Directory /var/www/html/<mon-application>/>  
		Options All
		AllowOverride All
		Order Allow,Deny
		Allow from all
	</Directory>

    ErrorLog ${APACHE_LOG_DIR}/error-mon-application.log
    CustomLog ${APACHE_LOG_DIR}/access-mon-application.log combined
</VirtualHost>

Apache2 vous offre la possibilité d'activer votre fichier de configuration facilement avec la commande embarquée suivante : sudo a2ensite mon-application.com.conf

Enfin, redémarrez le service Apache pour prendre en compte votre configuration : sudo systemctl restart apache2.

En toute logique, votre application est dorénavant accessible depuis l'interface HTTP -- qui tourne sur le port 80 de votre serveur-- à l'adresse : https://www.mon-application.com (et ça devrait fonctionner également sans le "www" 😉)

🤝 Contribution

Les contributions à ce guide sont les bienvenues en tout temps ! 😍

Manifestez votre intérêt

Soutenez ce repo ⭐️ si ce guide s'est avéré utile pour vous ! 🥰

Made with ❤️ by Twitter Follow

@Romain
Copy link

Romain commented Oct 24, 2019

Salut @sense, merci pour ce guide intéressant.
Je me suis fait le mien avec le temps également qui ressemble dans les grandes lignes à celui-ci.
Il y a un ou deux points qui me semblent devoir faire l'objet d'une discussion.

Le premier concerne la gestion des utilisateurs. Tel que décrit, tu fais tout avec ton utilisateur debian initial. Si un pirate doit tenter d'attaquer le serveur, ce sera probablement le premier utilisateur dont il tentera de prendre possession. La première chose que je fais en général, lorsque je prends la main sur un serveur c'est

  1. me créer un nouvel utilisateur avec des droits sudo
  2. modifier le mot de l'utilisateur debian (ou ubuntu ou peu importe) car il a circulé par mail.
  3. configurer un accès uniquement par clé SSH pour mon utilisateur

La seconde chose concerne le pare-feu. Je dois être parano, mais c'est la seconde chose que je fais, après avoir créé mon utilisateur pour éviter (même si c'est peu probable) une tentative d'intrusion dans le laps de temps de la configuration.

Enfin, je pense que ce serait pas mal d'ajouter à ce guide la configuration de Postfix pour l'envoi des mails en passant par un SMTP externe.

Que penses-tu de ces différents commentaires ?
Romain

@hexablob
Copy link
Author

hexablob commented Oct 24, 2019

Salut @Romain 👋 et merci à toi d'avoir pris le temps d'exprimer ton opinion à propos de ce guide. En effet comme tu l'as compris, j'essais de synthétiser au maximum les informations suite à plusieurs expériences in-vivo. Ici comme ailleurs, je pense qu'un guide quel qu'il soit ne répond jamais à tous les besoins de plus en plus spécifiques à chacun(e). Je dirais même que ce n'est pas sa vocation ici.

Concernant la gestion des utilisateurs, en effet je pense que ce point dans sa version à l'instant T mérite une réflexion plus détaillée. Je viens de repositionner par ailleurs cette section intitulée "Sécurisez votre serveur" en deuxième position du guide car elle constitue un pilier fondamental à la mise en route du serveur ainsi que sa pérennité dans le temps.

Les mots de passe root, ubuntu ou encore debian ont en effet l'habitude d'être transmis par l'hébergeur en clair et via mail. Grosse erreur ! Il est donc en effet important de le(s) modifier dès la première connexion SSH au serveur. L'étape suivante est en effet de créer, s'il n'existe pas déjà, un utilisateur qui fera parti des sudoers du serveur donc les accès seront volontairement limités à ses besoins métiers. L'accès SSH par mot de passe doit effectivement être désactivé comme indiqué dans ce guide, et il va naturellement de soi qu'un petit pare-feu n'est jamais de refus ! Je pense aussi que nous pouvons le coupler, dans des cas bien particuliers (par exemple donner accès à des prestataires ou collaborateurs externes) à une vérification sur l'IP entrante si elle est habituellement fixe (en + de la clé RSA). On pourrait même pousser le délire un petit peu plus loin avec une authentification via PKI.

Concernant l'envoi de mail, c'est aussi un point que je prévois de rédiger dans ce guide. Que ce soit par le biais de Postfix ou Exim (pour ne citer qu'eux), il est important de savoir comment les installer et les configurer dans la version "standard et basique" pour l'envoi de mails. Cependant, installer un serveur de mail complet (avec gestion de comptes de messageries sécurisées), fera très certainement l'objet d'un nouveau guide que je me ferais le plaisir de rédiger ultérieurement.

Merci pour tes retours @Romain ! Nous pouvons poursuivre notre discussion ici qui peut, à juste titre et à mon sens fournir plus d'informations aux personnes intéressées par l'administration système Linux. 😇

@Romain
Copy link

Romain commented Oct 24, 2019

Merci pour ton retour détaillé @sense, je vois qu'on est en phase sur pas mal de points... ;)

@SalaunC
Copy link

SalaunC commented Nov 8, 2019

Pour le ssh, je pense qu'il est obligatoire de changer le port de connexion, ça évite les scan de bots et ça sécurise l'accès un peu plus.

@hexablob
Copy link
Author

Salut @SalaunC 👋 et merci pour ta participation. Je suis d'accord avec toi dans le principe, cependant un petit coup de nmap n'empêche aucunement de déduire très facilement que le service a été bindé sur un autre port. Ensuite cela dépend de l'utilisation à laquelle est destiné le serveur. Le port 22 est déontologiquement parlant dédié au service sshd. Ce que je veux dire par là c'est qu'il existe dans beaucoup de cas des services tiers qui se basent sur ce port pour communiquer avec le serveur. Par exemple lorsqu'on sécurise notre serveur par l'installation d'un pare-feu physique, il existe certains cas de configuration où cette manipulation de changement de port génère des problèmes de communication qui ne peuvent être résolues facilement (certaines marques ne permettent pas de changer le port de com.)

Il y a un topic intéressant sur SO à propos de cela : Should I change the default SSH port on linux servers?

Je vais tout de même rajouter la manipulation parce que c'est très intéressant de savoir le faire, et de le faire dans le cas d'un serveur web "standard". 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment