Je vous propose dans ce tutoriel de découvrir comment installer un certificat SSL sur un serveur Apache sous Debian / Ubuntu. Cette étape est indispensable si vous souhaitez déployer un site sécurisé par HTTPS ou migrer un site web existant de HTTP vers HTTPS.

Sommaire

1. Introduction
2. Activer les modules requis pour utiliser SSL sur votre serveur Apache
3. Déposer votre certificat SSL sur votre serveur
4. Vérifier que votre serveur Apache écoute sur le port 443 (HTTPS)
5. Déclarer un VirtualHost pour le HTTPS
6. Activer le VirtualHost
7. Vérifier le niveau de sécurité de votre site
8. Et après ?

1 – Introduction

J’ai écris ce tutoriel dans le cadre de la migration de SysKB de HTTP vers HTTPS. Une migration motivée car Google pénalise depuis quelques mois les sites n’ayant pas migrés en HTTPS. Il était donc temps d’obtenir moi aussi mon petit cadenas vert vous indiquant que les informations qui circulent entres votre navigateur et mon site web sont chiffrées.

Ce tutoriel s’adresse à ceux qui comme moi hébergent leur site Web sur un serveur dédié ou un VPS (Virtual Private Server). Car contrairement à un hébergement de type mutualisé, c’est à vous de gérer la couche Apache de votre stack LAMP (Linux / Apache / MySQL / PHP). La plupart des tutos qui expliquent comment migrer un site HTTP vers HTTPS se contentent d’expliquer comment faire d’un point de vue WordPress et référencement Google, mais n’abordent pas le fait qu’il faut d’abord configurer Apache et déployer votre certificat sur votre serveur Apache. D’ailleurs vous allez le voir c’est assez simple.

SysKB est ainsi hébergé sur un VPS proposé chez 1&1. J’ai opté pour l’offre VPS Cloud XL qui me permet de disposer d’un serveur dédié virtuel performant avec du disque SSD, et suffisament de mémoire et de CPU pour supporter une charge de plusieurs milliers de connexions journalières. Le petit plus c’est que l’offre intègre un certificat SSL gratuit que vous pouvez activer et obtenir en 5 minutes depuis votre interface.

Si vous envisager de créer votre site Web je vous invite à consulter mon guide pour vous aider à choisir une solution d’hébergement pour WordPress.

Je résume, si vous avez un VPS et que vous souhaitez que votre site soit en HTTPS (ce que je vous recommande), suivez ce tuto pour paramétrer Apache.

Pour information, comme je suis un peu dingue, j’ai réalisé toutes les opérations suivantes en production. Après avoir fait une sauvegarde de ma base de données et après avoir enclenché un snapshot de mon VPS me permettant de revenir en arrière au cas où. Pas si dingue finalement.

2 – Activer les modules requis pour utiliser SSL sur votre serveur Apache

Activer le module SSL

Après avoir ouvert une session PuTTy sur votre serveur tapez simplement la commande suivante pour activer le module SSL. Un message vous indiquera clairement si le module est déjà ou non déployé.

a2enmod ssl

Activer le module headers

De la même manière cette commande vous permet d’activer le module Header. Ce module, dont l’installation est fortement recommandé par Google, permet d’activer la directive HSTS.

a2enmod headers

Redémarrer le service Apache

Le redémarrage de votre serveur Apache permet d’activer les deux modules précédemment activés. Ce redémarrage prend à peine quelques secondes sans impact notable sur votre production.

service apache2 restart

3 – Déposer votre certificat SSL sur votre serveur

Création du répertoire qui contiendra le certificat SSL

Il est d’usage de stocker les certificats SSL en respectant cette arborescence, mais ce n’est pas une obligation surtout si vous n’avez qu’un seul site. Remplacez domaine-com par votre propre domaine.

mkdir /etc/ssl/domaine-com/

Déposer votre certificat SSL dans le répertoire

Après avoir commandé votre certificat SSL vous avez plusieurs fichiers à récupérer :

• Le certificat SSL : Il s’agit d’un fichier au format .cer ou en .crt
• Votre clé privée : Il s’agit d’un fichier au format .key
• Le certificat intermédiaire : Il s’agit d’un fichier au format .cer ou en .crt

Une fois que vous avez récupéré ces fichiers vous devez les déposer dans le répertoire précédemment créé. Pour cela je vous recommande d’utiliser un logiciel comme WinSCP qui vous permet d’accéder à l’arborescence de votre serveur via une interface graphique. Voici ce que cela donne pour mon site SysKB.

4 – Vérifier que votre serveur Apache écoute sur le port 443 (HTTPS)

Par défaut Apache écoute sur les ports 80 et 443. Cela signifie qu’il est déjà configuré pour recevoir des requêtes en HTTP et HTTPS. Exécutez la commande netstat afin de vérifier si c’est bien le cas :

netstat -tanpu | grep "LISTEN" | grep "443"

Si aucun processus Apache n’est en écoute sur le port 443 c’est qu’il n’est pas paramétré. Pour cela identifié le fichier qui permet de configurer les ports en écoute en tapant la commande suivante :

grep -R "Listen" /etc/apache2

Modifier le fichier correspondant au “Listen 80” et ajoutez simplement le code suivant qui indique simplement à Apache d’écouter sur le port 443 si le module SSL est installé, ce qui est notre cas :

<IfModule mod_ssl.c>
Listen 443
</IfModule>

Redémarrer Apache :

service apache2 restart

Vérifiez de nouveau si Apache écoute sur le port 443 :

netstat -tanpu | grep "LISTEN" | grep "443"

5 – Déclarer un VirtualHost pour le HTTPS

Pour accéder à votre site Web il existe par défaut un VirtualHost. Les serveurs Apache qui contiennent plusieurs sites contiennent autant de VirtualHost que de sites hébergés.

Pour accéder à votre site en HTTPS il faut créer un VirtualHost dédié. Pour cela il suffit de dupliquer le VirtualHost existant et de le configurer pour HTTPS. C’est beaucoup plus simple de procéder ainsi car vous êtes certains de ne pas faire de mauvaises manipulations.

Accéder au dossier contenant tous les VirtualHost disponibles:

cd /etc/apache2/sites-available

Lister les fichiers présents dans ce répertoire :

ls -la

Vous devez identifier le fichier de configuration contenant le VirtualHost correspondant à votre site HTTP. Si vous n’avez qu’un seul site il n’y aura qu’un seul fichier mais si votre serveur gère des dizaines de domaines et sous domaines vous gagnerez du temps à faire un grep :

grep -R "remplacer-par-le-domaine-concerne" /etc/apache2

Une fois que vous avez identifié le bon fichier il suffit de le dupliquer et le renommer. Dans cet exemple je duplique mon fichier de configuration nommé 000-default.conf en 000-default-ssl.conf.

cp 000-default.conf 000-default-ssl.conf

Configurer le VirtualHost pour le protocole HTTPS :

Modifiez le fichier dupliqué avec la commande nano ou avec WinSCP.

En début de fichier remplacez le port 80 du VirtualHost par le port 443 comme ceci : <VirtualHost *:443>

Ajoutez ensuite les instructions suivantes juste avant le </VirtualHost>

# On active le SSL
SSLEngine On

# On active tous les protocoles (TLS v1.0, TLS v1.1 et TLS v1.2), mais on désactive SSL v2 et v3 (obsolètes et remplacés par TLS)
SSLProtocol All -SSLv3 -SSLv2

# On active les méthodes de chiffrement, et on désactive les méthodes de chiffrement non sécurisés (par la présente d'un !)
SSLCipherSuite HIGH:!aNULL:!MD5:!ADH:!RC4:!DH

# On demande au navigateur de sélectionner une méthode de chiffrement en respectant l'ordre envoyée par le serveur (HIGH uniquement)
SSLHonorCipherOrder on

# On renseigne le chemin vers le certificat SSL de l'adresse à sécuriser
SSLCertificateFile "/etc/ssl/votre-domaine-fr/www-votre-domaine-fr.cer"

# On renseigne le chemin vers la clée privée correspondant au certificat SSL de l'adresse à sécuriser
SSLCertificateKeyFile "/etc/ssl/votre-domaine-fr/www-votre-domaine-fr.key"

# On renseigne le chemin vers le certificat SSL racine, puis vers le(s) certificat(s) SSL intermédiaire(s).
# Si vous disposez de plusieurs certificats intermédiaires, vous pouvez ajouter d'autres directives SSLCACertificateFile.
SSLCACertificateFile "/etc/ssl/votre-domaine-fr/certificat-intermediaire.cer"

Header always set Strict-Transport-Security "max-age=15768000"

Modifiez les chemins d’accès et les intitulés des différents certificats afin qu’ils correspondent à ceux que vous avez déposé à l’étape 3. Vous pouvez supprimer tout le pavé en rouge car l’utilisation des certificats racine et intermédiaires sont optionnels.

6 – Activer le VirtualHost

Activer le VirtualHost dans Apache

Il s’agit maintenant d’activer votre nouveau VirtualHost

a2ensite nom-du-vhost-ssl
# Pour désactiver le vhost si vous avez commis une erreur de configuration :
# Executez : a2dissite nom-du-vhost-ssl

Recharger la configuration d’Apache

Et enfin charger la nouvelle configuration. On aurait pu redémarrrer entièrement le service Apache, mais le Reload suffit.

service apache2 reload

A cette étape votre site est désormais accessible en HTTPS

7 – Vérifier le bon fonctionnement du certificat et le niveau de sécurité de votre site

Vérifiez que votre certificat est bien installé grâce au site SSL Checker

Connectez vous ensuite sur le site SSLLabs.com pour contrôler si votre serveur est bien sécurisé.

Sans la directive HSTS que l’on a configuré en début de tutoriel vous obtiendrez la note “A“, avec le HSTS vous obtenez un “A+“

Et après ?

A cette étape votre site est déjà accessible en HTTPS.

Mais il y a encore quelques opérations a effectuer pour que tout soit complètement opérationnel :

• Effectuer une redirection HTTP vers HTTPS dans votre .htaccess pour éviter le Duplicate Content.
• Remplacer tous les liens internes HTTP de votre site par HTTPS avec l’extension pour WordPress Search and Replace DB.
• Vérifier qu’il n’y ait pas d’extensions récalcitrantes qui font des appels en HTTP. C’est très simple à savoir, votre site sera sécurisé mais vous risquez de ne pas avoir le cadenas vert.
•  Ajoutez la version HTTPS de votre site dans Google Webmaster Tools. Ne retirez pas l’ancien car Google exige que toutes les versions de vos sites soient renseignées afin justement de ne pas vous pénaliser pour Duplicate Content. Dans la version HTTPS pensez à ajouter votre fichier https://votre-site-fr/sitemap_index.xml. Dans 10 à 15 jours dès que Google aura indexé vos pages en HTTPS vous pourrez retirer le sitemap de votre la propriété HTTP Google Webmaster Tools. Ceci étant cela n’a aucun impact sur l’indexation de votre site.
• Pensez également à mettre à jour Google Analytics.

Pour cela j’ai suivi le tutoriel Comment passer son site WordPress en HTTPS à la section 9 choses à faire absolument après l’activation du HTTPS.

Cet article original intitulé Comment Installer un Certificat SSL sur un serveur Apache 2 [Debian / Ubuntu] a été publié la première sur SysKB.

I. Présentation

Dans ce tutoriel, nous allons apprendre à installer Nextcloud sur Debian 11 pour créer sa propre plateforme d'hébergements de fichiers et de collaboration. Un projet très intéressant pour ceux qui souhaitent garder la maîtrise de leurs données et éviter de payer pour une solution propriétaire ! Grâce à un système d'applications (plugins), les fonctionnalités de Nextcloud peuvent être étendues, ce qui permet de couvrir un maximum de besoin.

• Site officiel de Nextcloud

Dans cet article, on se concentrera sur l'installation de la solution Nextcloud (et on s'appuiera sur cette installation dans un autre tutoriel qui sortira prochainement). Pour le serveur Web sous Debian 11, Apache2 sera utilisé avec PHP 8.1 et MariaDB. Vous pouvez utiliser PHP 8.2 si vous le souhaitez, mais cette version est sortie récemment (décembre 2022).

Note : Nextcloud nécessite à minima PHP 8.0.

II. Installation pas à pas de Nextcloud

A. Installation des paquets

Nous devons commencer par installer les paquets nécessaires au bon fonctionnement du serveur Web. Mettons à jour le cache des paquets et les paquets de la machine :

apt-get update
apt-get upgrade

Puis, nous allons installer Apache2, MariaDB Server et PHP 8.1 ainsi qu'un lot d'extensions PHP utiles :

apt-get install apache2 mariadb-server php8.1 php8.1-common php8.1-curl php8.1-gd php8.1-intl php8.1-mbstring php8.1-xmlrpc php8.1-mysql php8.1-xml php8.1-cli php8.1-zip

En fonction des applications et fonctions que vous envisagez d'utiliser, il pourra être nécessaire d'installer d'autres extensions PHP par la suite.

Pour être sûr que l'extension PHP 8.1 soit bien actif dans Apache2, exécutez cette commande :

a2enmod php8.1

Nous allons aussi installer les paquets "wget" et "unzip" utiles pour télécharger les sources de Nextcloud et décompresser l'archive ZIP.

apt-get install wget unzip

B. Préparer les sources de Nextcloud

Nous devons récupérer les sources d'installation de Nextcloud et les positionner à la racine du serveur Web, à savoir dans "/var/www/html". Ici, on aura le dossier "nextcloud", ce qui implique que pour accéder à l'application il faudra utiliser cette URL :

http://<IP du serveur>/nextcloud/

Toujours sur le serveur Debian, positionnez-vous dans le répertoire "/tmp" pour télécharger la dernière version de Nextcloud avec wget :

cd /tmp
wget https://download.nextcloud.com/server/releases/latest.zip

On décompresse l'archive ZIP téléchargée :

unzip latest.zip

Ce qui donne lieu à un dossier "nextcloud" dans "/tmp" que nous allons déplacer dans son intégralité vers "/var/ww/html/".

mv nextcloud/ /var/www/html/

Il ne reste plus qu'à changer le propriétaire des données de Nextcloud pour que ce soit l'utilisateur d'Apache2 :

chown -R www-data:www-data /var/www/html/nextcloud

Les sources d'installation sont en place. Passons à la suite.

C. Créer une base de données pour Nextcloud

L'instance MariaDB doit être configurée : nous devons créer une base de données dédiée à Nextcloud et un utilisateur spécifique qui aura des droits uniquement sur cette base de données. Mais, avant cela, nous allons exécuter le script de sécurisation de MariaDB, ce qui permettra notamment de changer le mot de passe root.

Exécutez la commande ci-dessous et laissez-vous guider. Si vous avez besoin d'aide, regardez dans cet article.

mysql_secure_installation

Une fois que c'est fait, connectez-vous à votre instance MariaDB avec le compte root et le mot de passe que vous venez de définir.

mysql -u root -p

Après authentification, vous avez accès au prompt MariaDB. Nous devons commencer par créer une base de données que nous appellerons "db23nextcloud".

CREATE DATABASE db23nextcloud;

Puis, on va créer un utilisateur nommé "usr23nextcloud" qui aura le mot de passe "Password14" et qui aura tous les droits sur la base de données "db23nextcloud". Personnalisez ces informations, bien entendu.

GRANT ALL ON db23nextcloud.* TO 'usr23nextcloud'@'localhost' IDENTIFIED BY 'Password14';

On met à jour les autorisations :

FLUSH PRIVILEGES;

Puis, on se déconnecte de l'instance MariaDB :

EXIT;

D. Installation de Nextcloud

Tout est prêt, nous allons pouvoir finaliser l'installation de Nextcloud à l'aide d'un navigateur. Avec votre navigateur préféré, accédez à l'adresse suivante :

http://<IP du serveur>/nextcloud/

Vous devriez arriver sur une page comme celle ci-dessous. Ici, il va falloir définir un nom d'utilisateur et un mot de passe pour le compte Administrateur principal de Nextcloud.

Puis, un peu plus bas dans la base, il faut indiquer les informations de connexion au serveur MariaDB. Ici, on réutilise les informations définies précédemment, comme sur l'image ci-dessous. Cliquez sur "Installer" quand c'est fait.

Quelques secondes plus tard, l'installation est finalisée, bienvenue sur votre serveur Nextcloud !

Dès à présent vous pouvez créer de nouveaux fichiers, ou charger des fichiers existants. Il existe aussi des clients de synchronisations pour les postes de travail, ainsi que des applications mobiles.

IV. Conclusion

Voilà, l'installation de base de Nextcloud est effectuée ! Toutefois, il vous reste encore du travail si c'est un serveur qui doit être mis en place en production : sécurisation Apache2, passage du site en HTTPS, mise en place d'un nom de domaine, installation de CrowdSec pour détecter et bloquer les attaques, etc...

The post Installer Nextcloud sur Debian 11 first appeared on IT-Connect.

FOSSBilling is free and open-source billing designed to be easy for clients and sellers. FOSSBilling is a fork of BoxBilling; it provides a great experience for clients with an intuitive interface and also supports multiple payment gateways.

Portainer is a web-based container management platform that can work with Docker and Kubernetes to manage and deploy containerized applications and services more easily and efficiently. This tutorial will show you how to install Portainer on the Debian 11 server.

Percona XtraDB Cluster is a fully open-source database clustering solution for MySQL. It allows you to create a robust, high-availability MySQL server deployment that provides high performance.

Ansible Semaphore is an open-source web UI for Ansible playbooks. It enables the deployment using Ansible automation via a web browser. In this tutorial, you will install the Ansible Semaphore on a Debian 11 server.

Redmine is a free and open-source project management software and issue-tracking tool. It is written using the Ruby on Rails framework and can be integrated with various version control systems. In this tutorial, you will learn how to install Redmine on a Debian 11 server.

Ntopng is an open-source network monitoring tool that monitors real-time network traffic from a web interface. In this article, you will learn how to install Ntopng on Debian 11.

OTRS is an open-source Ticket Request System that helps organizations process customer tickets and requests. This post will explain how to install OTRS on Debian 11 server.

MSSQL Server or Microsoft SQL Server is an RDBMS (Relational Database Management System) developed by Microsoft. This tutorial will show you how to install and use Microsoft SQL Server on Debian 11.

FreeIPA is an open-source identity management solution for Linux/Unix operating systems. In this guide, you will install and set up the FreeIPA server on Debian 11 machine via Docker.

ProcessWire is a PHP-based Open-Source CMS used to deploy content on the web. This tutorial will show you how to install ProcessWire CMS on Debian 11.

Jellyfin is a free and open-source media streaming application that organizes, manages, and shares digital media files to networked devices. It allows you to stream the uploaded media files to your PC, Laptop, Mobile, and Roku.

Ansible AWX is a free and open-source web application sponsored by Red Hat that allows you to manage Ansible playbooks and inventories. This tutorial will show you how to install Ansible AWX on Debian 11.

Jitsi is a free, open-source solution for building a secure video conference platform. This article will go through the installation and configuration of the Jitsi Video Conference on the latest Debian 11 Bullseye.

Bloquer les modifications des entrées Grub.

Lorsque vous démarrez sur une machine ayant comme système d’exploitation GNU/Linux, il y a de très fortes chances que le chargeur d’amorçage (bootloader) soit Grub. Si c’est le cas, il vous suffit d’appuyer sur la toucher e pour éditer les paramètres de lancement, et pouvoir réaliser toute une série d’actions.

Bien souvent, cela peut être utile pour obtenir un shell root et dépanner sa machine personnelle, mais en entreprise (sur desktops comme serveurs), on préférerait bloquer les modifications d’entrées Grub, pour éviter certaines mésaventures.

C’est ce que nous allons voir ici, comment protéger la modification d’entrées Grub sur une Debian, mais sans pour autant exiger un mot de passe pour démarre l’OS (ce sont deux choses bien distinctes).

Sans plus attendre, allons-y !

I) Créer les users et passwords correspondants

La première étape est donc de créer les couples user/passwords qui permettront de déverrouiller ces dites entrées. Bien-entendu, libre à vous d’en créer un seul, ou une dizaine, c’est au choix !

La première étape est donc de générer le hash pour nos différents passwords, ici je ne créerai qu’un utilisateur, mais le principe est le même, il suffit de le faire autant de fois que l’on a de users :

sudo grub-mkpasswd-pbkdf2

Cette commande va nous permettre d’obtenir un hash de notre password une fois encodé.

On modifie ensuite le fichier /etc/grub.d/40_custom, pour y définir le ou les utilisateurs avec le hash de leur mot de passe :

# Si vous désirez spécifier plusieurs users

set superusers="root utilisateur02 utilisateur03 utilisateur04"

# On rajout le hash correspondant ensuite à chaque user

password_pbkdf2 root grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur02 grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur03 grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur04 grub.pbkdf2.sha512.10000~

Ici je n’ai mis que l’utilisateur root, mais libre à vous de mettre l’utilisateur système de votre choix !

On peut ensuite enregistrer le fichier. puis mettre à jour la configuration de grub via un classique update-grub.

Si vous redémarrez votre machine maintenant, vous verrez que le mot de passe est bien demandé (et avec un agencement de clavier en qwerty au passage !), mais pas seulement pour l’édition, aussi pour le simple boot… et ce n’est pas ce que l’on souhaite ici.

II) Empêcher les modifications, pas le démarrage de l’OS

Rien de très sorcier ici, il nous suffit d’éditer cette fois le fichier /etc/grub/10_linux et de rajouter le flag –unrestricted aux entrées désirées :

 echo "menuentry '$(echo "$title" | grub_quote)' --unrestricted ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {"$  else
      echo "menuentry '$(echo "$os" | grub_quote)' --unrestricted ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^$  fi

Ici, on modifie directement la commande echo « menuentry … » de sorte que lorsque votre kernel sera mis à jour, ces modifications resteront intactes. Bien-entendu, il est aussi possible de ne bloquer l’édition ou le boot que pour une entrée Grub bien particulière.

N’oubliez pas une fois cette modification effectuée de bien exécuter la commande update-grub à nouveau !

Et c’est tout ! Vous savez désormais comment protéger vos entrées Grub, voir même proposer un mot de passe supplémentaire pour le démarrage de votre OS !

Comme d’habitude, j’espère vous avoir appris quelques bricoles, et vous souhaite une bonne journée/soirée !

L’article Debian : Password sur GRUB est apparu en premier sur Notamax.

Wireguard avec serveur Debian et client W10.

Petit article expliquant comment installer Wireguard en tant que serveur sur une Debian 10, et comment ensuite installer son client Windows 10 sur une machine en dehors de ce réseau, de sorte à tester le VPN en mode Client-to-Site.

Sans plus attendre, allons-y !

I) Présentation du lab

Une fois n’est pas coutume, c’est armé de mon petit VMWare Workstation que je ferai ce lab. Et comme toujours, rien de compliqué !

• fw-brussels-01, en 192.168.0.20/24 pour le WAN, et 192.168.1.1/24 pour le LAN ;
• fw-paris-01, en 192.168.0.30/24 pour le WAN, et 192.168.2.1/24 pour le LAN ;
• hoster-vpn-01, en 192.168.2.50/24, sur le réseau LAN de Paris ;
• client-w10, en DHCP et sur le réseau LAN de Bruxelles ;

Le but ici était donc de mimer deux réseaux distincts, avec un serveur VPN présent à Paris, et un client présent à Bruxelles souhaitant s’y connecter.

Côté Firewall –ce n’est pas important– mais il s’agit de simples pfSenses. Fortigate, Sophos, ou même votre simple modem personnel peut suffire, il faudra simplement réaliser du Port Forwarding vers votre serveur VPN.

I) Installation de Wireguard sur Debian 10

Je ne vais pas vous faire l’affront de vous ré-expliquer ce qu’est Wireguard (un protocole ET un software, comme pour OpenVPN), je vous renvois sur un ancien article en lieu et place :

Découverte d’OPNSense et Wireguard (VPN Site-à-Site)

Donc, une fois connecté en SSH sur votre joli petit serveur, installons donc le package (on ajoute le dépôt buster-backports, un petit refresh, et le tour est joué) :

sh -c "echo 'deb http://deb.debian.org/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/buster-backports.list"
apt update && apt install wireguard -y

Une fois installé, place à la configuration du serveur !

II) Configuration du serveur Wireguard

La première étape est donc de générer notre paire de clefs publique/privée :

cd /etc/wireguard
# Les fichiers créés dans ce répertoire auront ces permissions de base
umask 077
# Création de la paire de clefs
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickey

Une fois notre paire de clefs générée, on créer le fichier de configuration :

touch /etc/wireguard/wg0.conf

L’interface par défaut sera donc nommée wg0, mais rien ne vous empêche de la nommer vpntest ou encore wg17 si vous avez plusieurs VPN.

Maintenant, place à la configuration :

Dans ce fichier on renseignera donc :

• L’IP de notre interface réseau ;
• Le fait de ne pas sauvegarder automatiquement l’état de la carte réseau lors de son arrêt ;
• Le port sur lequel Wireguard va écouter ;
• Notre Private Key ;
• Le PostUp/PostDown, qui sont des commandes IPtables permettant de réaliser du forward ainsi que du NAT ;
• Nos peers, c’est-à-dire nos clients (voir plus bas) ;

A noter que si votre interface réseau physique se dénomme par ex. eth0, renseignez donc eth0 et non pas ens33 comme dans l’exemple !

### Configuration du serveur
[Interface]
Address = 192.168.2.50/24
ListenPort = 51820
PrivateKey = VotrePrivateKey
SaveConfig = false
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens33-j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE


### Configuration des clients
[Peer]


# Windows 10 test client
PublicKey = CléPubliqueDuClient
AllowedIPs = 10.0.0.1/28

On peut ensuite démarrer le service, et l’activer à chaque démarrage :

systemctl start wg-quick@wg0 && systemctl enable wg-quick@wg0

Comme on peut le voir ici, le service est bien démarré !

Il nous reste encore à activer l’IP Forwarding, pour ce faire, rien de plus simple :

nano /etc/sysctl.conf 

# Décommentez ensuite la ligne suivante
net.ipv4.ip_forward=1

Côté serveur, tout est bon ! Il vous faudra simplement modifier la section Peers pour renseigner la clef publique ainsi que l’IP qu’aura votre/vos client(s).

IV) Installation du client Windows

Rien de plus facile ! On télécharge le client, au format exe ou msi depuis ce site, et on l’installe (Suivant, Suivant… rien de sorcier).

Ensuite, il nous faudra générer la paire de clefs pour ce client, et la rajouter sur notre serveur Wireguard (voir fichier wg0.conf plus haut). Pour ce faire, on retourne sur notre petite Debian :

wg genkey | tee /etc/wireguard/privatekey_w10_client01 | wg pubkey | tee /etc/wireguard/publickey_w10_client01

Comme vous pouvez le voir, c’est exactement la même commande que pour la paire des clefs générée pour le serveur lui-même en début d’article, mais ici bien-entendu on change le nom de fichier pour la pub/private key :

Prenez donc cette clef publique, et décrivez le client dans votre fichier wg0.conf, voir plus haut.

Une fois ceci fait, on peut créer le fichier de config sur notre client :

[Interface]
PrivateKey = WBbkdVpjwR+1Vz1uAEaKg9QcKpvnjZIjqdh7XJZ2EUA=
Address = 10.0.0.1/28
DNS = 1.1.1.1, 192.168.2.1

[Peer]
PublicKey = qw1dykit4465369rHrIr8ETckP9fmCDR5vB7UetbXmA=
AllowedIPs = 192.168.2.0/24
Endpoint = 192.168.0.30:51820

Le tout dans un petit fichier de type « maconfig.conf » par exemple, et c’est tout ! Importez-le sur le client Wireguard and here we go.

On renseigne donc :

• Sa Private Key ;
• Son adresse pour le tunnel ;
• Le ou les serveurs DNS à utiliser ;
• La Public Key du serveur WIreguard ;
• Concernant le champ AllowedIPs, soit vous pouvez rajouter le réseau distant, pour ne router que le trafic à destination de ce réseau via le VPN, soit si vous désirez router la totalité de votre trafic, vous pouvez mettre « 0.0.0.0/0, ::/0 » pour l’IPv4 et IPv6 respectivement ;
• Et enfin concernant l’Endpoint, il s’agit ni plus ni moins que l’IP/L’hostname du serveur distant. Ici il s’agit donc de l’IP WAN de mon pfSense, où j’ai réalisé un simple port forwarding sur le port 51820 en UDP, à destination de mon serveur Wireguard ;

Une fois ceci fait, on peut tester notre connexion !

V) Test et conclusion

Des images valent mieux que mille mots, voici donc ! A noter que je me suis même permis d’installer rapidement un simple serveur Apache sur le LAN distant pour bien vérifier que notre client à accès au réseau.

Vous avez donc réussi à mettre en place un serveur Wireguard sous une Debian, ainsi qu’à connecter un client sous Windows 10, félicitations !

Je ferai sûrement un prochain article dans le cadre de la mise en place d’un VPN de type Site-to-Site.

Comme à mon habitude, j’espère que ce rapide article vous aura plus, et je vous souhaite une bonne journée/soirée !

L’article Wireguard: VPN Client-to-Site est apparu en premier sur Notamax.

Découverte du paquet unattended-upgrades !

Aujourd’hui, et pour recommencer en douceur, nous allons découvrir le paquet unattended-upgrades qui permet comme son nom l’indique de de pouvoir obtenir les mises à jour de sécurité/mises à jour classiques de manière automatique.

Idéal si vous désirez automatiser un tant soit peu les mises à jour de vos différents serveurs persos donc.

I) Installation du package

Disponible de base dans les dépôts, un simple apt install suffit :

sudo apt update
sudo apt install unattended-upgrades -y

Et le tour est joué ! A noter que ce package est naturellement disponible pour Ubuntu, Mint, et autres dérivés.

II) Configuration

Rien de très sorcier, le fichier de configuration se situe ici : /etc/apt/apt.conf.d/50unattended-upgrades.

La première section concerne les différents dépôts qui vont être utilisés. Par défaut, sur une Debian 10 classique, il n’y aura que les dépôts Debian et Debian-Security d’activés. Libre à vous bien-entendu d’ajouter d’autres dépôts personnels si vous le désirez.

La seconde section concernant les paquets que l’on ne souhaite pas mettre à jour automatiquement via cet outil, c’est-à-dire les paquets à blacklister :

Comme on peut le voir, il suffit d’écrire le nom du package, en rajoutant bien le « $ » pour signifier la fin de son nom.

Enfin, les autres sections restantes sont orientées bidouillage :

On peut par exemple faire en sorte d’installer les mises à jour seulement lorsque la machine s’éteint, on peut activer les notifications par mail (en cas de réussite ou non), on peut supprimer automatiquement les anciens kernels non-utilisés… la liste est longue.

Une fois votre configuration aux petits oignons terminée, on peut passer à son activation. Pour cela on copie le template et on l’édite :

cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/

Concernant la modification de ce fichier, rien d’insurmontable ici :

Rajoutez simplement la première ligne, permettant d’activer l’outil, et concernant les deux autres lignes elles indiquent simplement la fréquence à la quelle mettre à jour la liste des paquets dans les dépôts, et à quelle fréquence upgrade les paquets présents sur le système (0 pour désactiver, et X pour tout les X jours, ici j’ai mis chaque semaine).

III) Exécution de l’outil

Pour tester sa bonne mise en place, on peut démarrer l’outil manuellement. Comme on peut le voir sur la capture d’écran ci-dessous, aucun paquets n’est à blacklister, et aucune whitelist n’a été fournie.

sudo unattended-upgrade -d

Et c’est tout ! Désormais vos systèmes se mettront à jour de manière automatique.

C’est tout pour ce rapide article, d’autres plus conséquents arriveront très vite !

L’article Debian : màjs automatiques est apparu en premier sur Notamax.

Installation du logiciel de gestion de parc informatique Open Source.

GLPI, pour Gestionnaire Libre de Parc Informatique, est… et bien son nom l’indique ! Un logiciel qui va nous permettre d’inventoriser notre parc informatique, le tout de manière gratuite et libre.

Je ne vais pas le détailler de fond en comble tant celui-ci est connu dans le monde Open Source, mais ce dernier va nous permettre de :

• Gérer un inventaire de nos différentes machines et équipements, des laptops aux écrans, en passant par les serveurs, les dockings… ;
• Obtenir une vue de nos différents racks informatiques, avec la possibilité de voir le nombre de baies encore disponibles ;
• Encoder les différentes factures d’achats, et les relier aux différents équipements ;
• Gérer l’aspect Helpdesk via un système de ticketing, même si personnellement je préfère la solution Hesk à cet égard ;
• . . .

La liste est encore longue, d’autant plus avec les nombreux plugins mis à disposition !

Courant avril la version 10.0 est sortie, et pour ceux connaissant déjà GLPI, voilà à quoi l’interface ressemblait il y a plusieurs années…

Pas forcément très séduisant n’est-ce pas ? Et bien désormais, c’est une véritable refonte graphique qui a eut lieu ! Regardez ce changement ! (En plus de plusieurs optimisations et fonctionnalités majeures rajoutées !)

Quand même un sacré changement non ? Je comptais depuis plusieurs mois voir années faire un article sur son installation, et avec cette mise à jour majeure récemment sortie, je m’y suis donc enfin mis.

Sans plus attendre, allons-y !

I) Installation de GLPI

Nous partirons sur une classique debian 10, et une fois celle-ci installée et configurée de manière basique, nous allons pouvoir commencer à nous atteler à l’installation de notre soft.

Tout d’abord, les prérequis :

• Un serveur web, dans notre cas ce sera un classique apache ;
• Une base données, ici ce sera mariadb ;
• PHP 7.4 à 8.1, concernant la version 10.0 que nous allons installer. Au passage, en voulant installer la version 8.0 j’ai obtenu un joli « PHP 7.4.0 – 8.2.0 (exclusive) required« , donc nous allons installer la version 7.4 spécifiquement… ;

Sous Debian 10, en installant simplement le package « php« , la version 7.1 sera installée, nous allons donc installer manuellement la version 7.4.

# Serveur web et SGBD
apt update && apt install apache2 mariadb-server -y

On rajoute ensuite le dépôt PHP :

wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | tee /etc/apt/sources.list.d/php.list

Puis on update les dépôts, et on installe la version 7.4 avec les dépendances requises par GLPI :

apt update && apt install php7.4 php7.4-curl php7.4-curl php7.4-gd php-json php7.4-mbstring php7.4-mysql php7.4-xml php7.4-xml php7.4-intl php7.4-xml php7.4-curl php7.4-gd php7.4-gd php7.4-intl -y && service apache2 restart

Passons ensuite à la configuration de notre base de données !

# Pour définir un mot de passe root, et faire les réglages de base
mysql_secure_installation

# On se connecte en CLI 
mysql -u root -p

# On créé notre base de données et son utilisateur 
create database glpi ;
create user 'glpi-user'@'localhost' identified by 'Pa$$W0Rd' ;
grant all privileges on glpi.* to 'glpi-user'@'localhost' ;
flush privileges ;

Bien-entendu, libre à vous de choisir un nom spécifique pour votre base de données, votre utilisateur, ainsi qu’un mot de passe.

On peut ensuite télécharge l’archive contenant la dernière version stable de GLPI (à l’heure où j’écris ces lignes) :

wget https://github.com/glpi-project/glpi/releases/download/10.0.1/glpi-10.0.1.tgz

On décompresse le tout, et on set les droits pour le serveur web :

gunzip glpi-10.0.1.tgz
rm glpi-10.0.1.tgz
rm -r /var/www/html/
cp glpi-10.0.1.tar /var/www/ && cd /var/www/
tar xvf glpi-10.0.1.tar
mv glpi html
chown -R www-data:www-data html/

Une fois le tout installé, on peut passer directement à l’interface web pour la finalisation !

Je vous conseille cependant d’aller lire la documentation, qui stipule de ne pas directement se ruer sur l’interface web, mais d’effectuer diverses configurations supplémentaires au niveau sécurité. Ici cela reste un lab/une présentation, mais toujours bon de le mentionner ! Surtout que leur doc’ est plutôt bien fournie.

II) Configuration de l’instance GLPI via la WebUI

Une fois notre langue choisie, on peut choisir l’option Install ou Update, ici ce sera donc Install :

Nous avons ensuite droit à un récapitulatif des extensions éventuelles manquantes, soit obligatoires, soit facultatives :

On renseigne ensuite les informations concernant notre base de données, ici elle est installée en local donc nous utiliserons 127.0.0.1 bien-entendu :

On choisi notre base de données sur laquelle notre utilisateur a les droits :

Et le tour est joué !

On peut ensuite éventuellement envoyer les statistiques d’usage, s’inscrire, expliquer comment nous avons connu GLPI… classique.

Puis un petit récap’ sur les identifiants et mots de passe par défaut, à changer une fois connecté bien-sûr :

III) Connexion à l’interface web

Le login par défaut pour le compte admin étant donc glpi/glpi, nous pouvons nous connecter et tadaaaa :

On notera les deux petits warnings, un concernant le changement de mot de passe par défaut (logique), et l’autre concernant la suppression du fichier d’installation.

IV) Conclusion

Vous avez donc terminé d’installer votre instance GLPI ! Bien-entendu, diverses optimisations sont possibles, et je n’ai pas parlé des plugins, cet article était avant tout une découverte et un tuto sur son installation.

Comme d’habitude, j’espère vous avoir appris quelques bricoles, et essayez de toujours privilégiez l’Open Source, ça en vaut la peine

Bonne journée/soirée à vous !

L’article GLPI : découverte et installation de base est apparu en premier sur Notamax.