sécurité

Un périphérique NAS Synology représenté à côté d'une clé dorée, symbolisant l'authentification par clé SSH, sur un fond dégradé bleu avec le logo Synology.

Synology: activer l’authentification par clé SSH pour les scripts rsync

by · Lecture: 5 minutes

Si vous utilisez un Synology, vous savez déjà à quel point il est précieux pour stocker et gérer vos données. Cependant, pour optimiser son utilisation tout en assurant la sécurité de vos fichiers, un petit réglage s’impose : la configuration d’un accès SSH et la création d’un compte dédié rsync, car depuis la dernière mise à jour DSM, le conseiller en sécurité vous alerte désormais lorsque le compte admin est actif, puisqu’il est ciblé avec des attaques par brute-force, ainsi que des rançongiciels.

Dans les lignes qui suivent, on va décomposer ensemble cette tâche pour la rendre aussi simple que possible. Pas de chichis, juste les étapes clés pour sécuriser vos transferts de fichiers et rendre votre expérience NAS encore plus fluide.

Prêt à mettre les mains dans le cambouis ? Allons-y.

1. Activation de SSH sur le NAS

  1. Connexion à DSM : connectez-vous au DiskStation Manager (DSM) de votre Synology.
  2. Panneau de Configuration : allez dans le Panneau de Configuration.
  3. Terminal & SNMP : sélectionnez Terminal & SNMP sous les options avancées.
  4. Activer le service SSH : cochez la case Activer le service SSH. Cela vous permettra de vous connecter au NAS via SSH.
  5. Appliquer : cliquez sur Appliquer pour sauvegarder vos changements.

2. Création de l’utilisateur rsync sur le NAS

  1. Accéder au DSM : connectez-vous au DSM.
  2. Ouvrir le Panneau de Configuration : naviguez jusqu’au Panneau de Configuration.
  3. Création de l’utilisateur : allez dans Utilisateur puis cliquez sur Créer. Suivez l’assistant pour créer un nouvel utilisateur.
    • Pour Nom, entrez rsync.
    • Attribuez un mot de passe fort au compte.
    • Vous voudrez peut-être limiter l’accès de cet utilisateur à des dossiers spécifiques qui seront utilisés pour les opérations rsync.
    • Assurez-vous de ne pas donner à cet utilisateur plus de permissions que nécessaire pour la tâche à effectuer.
  4. Compléter l’assistant : suivez l’assistant, en ajustant les paramètres selon vos besoins de sécurité et opérationnels, puis terminez le processus de création de l’utilisateur.

Assurez-vous que le service SSH est activé sur votre NAS (comme indiqué dans les instructions précédentes). L’utilisateur rsync héritera de l’accès SSH s’il est activé globalement.

Lire la suite

An automatic computer screen displaying the message "sorry you have been blocked".

Contourner le blocage du WAF Cloudflare pour les uploads de zip dans WordPress

by · Lecture: 4 minutes

Le blocage des fichiers zip par le WAF (Web Application Firewall) de Cloudflare est un casse-tête pour de nombreux développeurs WordPress, surtout lors de la mise à jour de plugins et de thèmes. Heureusement, il existe une solution pour contourner ce problème sans compromettre la sécurité de votre site WordPress.

Pourquoi le WAF bloque-t-il les fichiers Zip ?

Cloudflare met régulièrement à jour ses Managed Rules pour renforcer la sécurité. Un upload de fichier zip peut être un vecteur pour des attaques malveéillantes, comme l’installation de shells. Ainsi, Cloudflare bloque ces requêtes pour protéger votre site.

Dans notre cas, par contre, cela nous empêche de faire nos mises à jour et c’est quand même plus simple de mettre à jour les plugins et thèmes payants avec un fichier zip, plutôt que de passer par SFTP ou wp-cli.

Solution #1: créer une exception dans le WAF de Cloudflare

Évidemment, nous n’allons pas désactiver ces règles qui fonctionnent si bien et ajoutent une couche de protection à notre site. Non, nous allons simplement créer une exception aux Managed Rules, que nous placerons avant tous les autres set de règles pour qu’elle soit prise en compte en priorité.

Étape 1: rendez-vous dans le Dashboard de Cloudflare

Allez dans Security > WAF > Managed Rules.

Voici ce que vous obtenez:

A screenshot of the WAF settings in Google Analytics showcasing blocked zip files.

Cliquez ensuite sur le bouton Add exception à droite.

Lire la suite

icecast ssl https cloudflare

Configurer Icecast avec un certificat SSL et Cloudflare

by · Lecture: 6 minutes

Voici comment configurer un serveur Icecast pour utiliser un certificat SSL pour proposer des flux radio servis en HTTPS, le tout derrière Cloudflare.

Depuis que Strict Transport Security (HSTS) a été activé par défaut pour tous les sites hébergés sur le serveur, la page de Thunderstruck Radio ne s’affiche plus correctement car le serveur Icecast est encore servi en simple HTTP, donc sans certificat SSL.

Nous allons donc changer tout cela et sécuriser Icecast avec le certificat SSL de notre domaine, de manière à ce que les flux radio ainsi que le flux JSON soient servis en HTTPS.

Étape 1 : créer un sous-domaine au niveau DNS

Il vaut mieux séparer la radio de votre site principal, c’est beaucoup plus simple à gérer et évite les épineux problèmes de configuration.

J’opte pour ajouter le sous-domaine thunderstruck.skyminds.net avec un enregistrement DNS de type A dans Cloudflare:

thunderstruck.skyminds.net.	1	IN	A	xxx.xxx.xxx.xxxCode language: CSS (css)

On garde le sous-domaine en DNS seulement, nul besoin d’activer le cache (puisque c’est un flux).

Étape 2 : ouvrir le port 8443 dans le pare-feu

J’utilise Cloudflare donc nous avons quelques ports HTTPS ouverts par défaut qui peuvent être utilisés sans blocages :

# Ports HTTPS ouverts par défaut chez Cloudflare, sans support cache :

    443
    2053
    2083
    2087
    2096
    8443Code language: PHP (php)

Nous utilisons ufw donc la commande est très simple pour ouvrir le port 8443 :

ufw allow 8443/tcp comment "Icecast SSL"Code language: JavaScript (javascript)

Le serveur accepte désormais les connexions sur le port 8443 pour Icecast.

Étape 3 : configurer le sous-domaine sous NginX

Nous allons maintenant configurer notre sous-domaine et éditer le bloc serveur de notre domaine sous NginX:

nano /etc/nginx/sites-available/skyminds.conf

Et nous y ajoutons ce bloc:

# Thunderstruck.skyminds.net
server {
    listen       8443 ssl http2;
    listen  [::]:8443 ssl http2;

    server_name thunderstruck.skyminds.net;

    # Let's Encrypt
    ssl_certificate         /etc/nginx/ssl/skyminds.net/fullchain.pem;
    ssl_certificate_key     /etc/nginx/ssl/skyminds.net/privkey.pem;

    location / {
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_pass              http://127.0.0.1:8443;
        proxy_read_timeout      90;
        proxy_redirect          off;
        proxy_buffering         off;
        tcp_nodelay             on;

	    # CSP headers
	    add_header Content-Security-Policy "media-src 'self' https://thunderstruck.skyminds.net:8443";
    }
}Code language: PHP (php)

Testez la configuration et rechargez nginx : 

nginx -t

service nginx reload

Étape 4 : unifier le certificat SSL et sa clé privée

Icecast peut fonctionner avec un certificat SSL à partir de la version 2.4.4. Commencez donc par vérifier que cette version est à minima installée sur le serveur:

icecast2 -v

Ensuite, Icecast nécessite un fichier de certificat unique, qui est en fait une compilation du certificat et de sa clé privée.

Nous créons donc un fichier shell qui va contenir notre commande:

nano /home/scripts/icecast-ssl.sh

et dans lequel nous ajoutons notre commande cat : 

#!/bin/bash
cat /etc/nginx/ssl/skyminds.net/fullchain.pem /etc/nginx/ssl/skyminds.net/privkey.pem > /etc/icecast2/bundle.pemCode language: JavaScript (javascript)

Vous pouvez exécuter le fichier de manière à générer le fichier bundle.pem:

bash /home/scripts/icecast-ssl.sh

On assigne maintenant les bons droits pour que le certificat soit lisible par icecast2:

chown icecast2:icecast /etc/icecast2/bundle.pem

Étape 5 : automatiser le renouvellement du certificat Icecast

J’utilise acme.sh pour la génération et le renouvellement automatique de tous les certificats du serveur donc il est très utile d’éditer la configuration du certificat pour que le script de génération du certificat pour SSL ait lieu automatiquement, juste après le renouvellement du certificat de notre domaine.

On édite donc la configuration acme.sh du domaine:

nano /root/.acme.sh/skyminds.net_ecc/skyminds.net.conf

Et nous éditons la directive Le_RenewHook avec le chemin de notre nouveau script shell :

Le_RenewHook='bash /home/scripts/icecast-ssl.sh && service icecast2 restart'Code language: JavaScript (javascript)

Sauvegardez les changements.

Lire la suite

linux ubuntu server unattended upgrade

Ubuntu : activer les mises à jour automatiques avec unattended-upgrades

by · Lecture: 3 minutes

La mise à niveau de votre serveur Ubuntu est une étape importante pour garantir que votre système est toujours à jour et sécurisé. Avec le paquet unattended-upgrades, vous pouvez facilement activer les mises à niveau sans avoir à vous soucier du redémarrage manuel ou des temps d’arrêt.

Comme son nom l’indique, le paquet unattended-upgrades permet de lancer les mises à jour automatiquement à intervalles réguliers, sans action de la part de l’administrateur. Vous pouvez donc planifier les mises à jour lorsque le trafic est faible, et l’outil est même capable de redémarrer le serveur si besoin.

Dans ce tutoriel, nous allons vous montrer comment installer et utiliser unattended-upgrades sous Ubuntu Server 22.04. Nous aborderons également les avantages de l’utilisation de cet outil et la manière dont il peut contribuer à garantir que votre système est toujours à jour.

Cela peut être également un très bon complément si vous avez déjà installé Ubuntu Pro avec le support étendu des mises à jour.

Installer unattended-upgrades

Pour commencer, vous devez d’abord installer le paquet unattended-upgrades sur votre serveur Ubuntu – ouvrez une fenêtre de terminal et entrez la commande suivante :

apt install unattended-upgrades

Une fois que unattended-upgrades est installé, on le paramètre:

dpkg-reconfigure -plow unattended-upgrades

Répondez “Yes” pour installer les mises à jour stable automatiquement.

Activez ensuite l’outil: 

unattended-upgrades enable

Paramètrage d’unattended-upgrades

Le paquet est bien plus puissant qu’il n’y paraît. Personnellement, j’aime bien être informé des mises à jour et des changements sur le serveur, activons donc les notifications.

On édite notre fichier de configuration local (à créer si besoin). C’est le fichier qui ne sera pas écrasé si le paquet est mis à jour:

nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Et en suivant la documentation, on demande la notification récapitulative des mises à jour, le redémarrage automatique si besoin, vers deux heures du matin pour ne pas gêner nos visiteurs:

// email to send notifications
Unattended-Upgrade::Mail "admin@example.com";
// automatic reboot at 2:00 AM
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";	Code language: PHP (php)

Lire la suite

ubuntu pro free

Ubuntu Pro : des mises à jour pour 10 ans

by · Lecture: 4 minutes

Canonical change son offre Ubuntu Pro. Désormais, tout le monde peut profiter gratuitement du support étendu dans la limite de 5 machines.

La distribution Linux Ubuntu est maintenue et développée par l’entreprise Canonical. La distribution en elle-même est disponible gratuitement, mais en parallèle Canonical propose des services payants, notamment Ubuntu Pro, un abonnement qui permet d’avoir une maintenance étendue pour la sécurité et la conformité. En temps normal, Ubuntu Pro est facturé 25 dollars par an et par machine, ainsi que 500 dollars par an et par serveur.

Canonical fait évoluer son offre Ubuntu Pro, ce qui permet aux utilisateurs d’en bénéficier gratuitement dans la limite de 5 machines, que ce soit des ordinateurs ou des serveurs, et que ce soit pour un usage personnel ou commercial.

Ubuntu Pro permet d’avoir des correctifs de sécurité plus rapidement lorsqu’une faille de sécurité est découverte, notamment pour avoir une meilleure protection. Ceci s’applique aux failles critiques, élevées ou moyennes, avec un niveau de réactivité qui peut varier. Des milliers d’applications sont prises en charge dans le cadre du programme Ubuntu Pro : Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, etc.

Support à long terme de niveau « entreprise »

La proposition s’applique uniquement aux versions avec support à long terme (LTS) du système d’exploitation basé sur le noyau GNU/Linux. Et ce à partir de Ubuntu LTS 16.04.

Il s’agit de versions de niveau « entreprise » de l’OS. Les LTS sont aussi les plus utilisées par l’écosystème et représentent 95% des déploiements, selon Canonical.

Les utilisateurs peuvent obtenir leur abonnement gratuit à Ubuntu Pro sur la page dédiée au programme. Ubuntu One étant le compte unique dont l’utilisateur a besoin pour en bénéficier et se connecter à l’ensemble des services et sites liés à l’OS.

Lorsque l’on connecte les machines à Ubuntu Pro, elles bénéficient donc d’une couverture de maintenance de sécurité étendue, soit 10 ans au total.

Aussi, l’offre gratuite inclut le service Ubuntu Livepatch, celui-ci permet d’installer des mises à jour critiques du noyau sans redémarrer la machine.

Pour les serveurs, lorsque le système hôte physique exécute Ubuntu, l’ensemble des machines virtuelles Ubuntu sur ce serveur sont couvertes. Ubuntu Pro s’étend également à Google Cloud et AWS.

Configurez Ubuntu Pro sur votre serveur

Avec autant d’avantages, il ne nous reste plus qu’à configurer Ubuntu Pro sur le serveur.

Si votre serveur tourne sous Ubuntu Server, le paquet pro est normalement déjà installé. Vous pouvez vérifier cela avec la commande:

pro --version

Résultat de la commande:

27.11.2~22.04.1Code language: CSS (css)

La version minimale que vous devez posséder est la 27.11.2.

Lire la suite

Nettoyer un site WordPress infecté par un script shell photo 1

Nettoyer un site WordPress infecté par un script shell

by · Lecture: 3 minutes

Il n’est pas rare de voir des sites WordPress infectés par des scripts shell, qui peuvent exploiter certaines failles du core WordPress, de plugins ou de thèmes.

Ces attaques de WordPress sont courantes et concernent les sites qui n’ont pas été protégés par un antivirus ou un plugin de sécurité comme iThemes Security.

Il peut donc arriver que certains malwares infestent votre site WordPress, de manière automatisée si certaines composantes (core, plugins, themes) ne sont pas mis à jour régulièrement.

La technique détaillée ci-dessous vous permet d’identifier et de supprimer ces fichiers dans vos dossiers WordPress.

Important: avant de commencer, faites une sauvegarde du site: fichiers et base de données.

Étape 1 : suppression des fichiers potentiellement infectés

Sur l’installation en question, ces fichiers n’appartiennent pas à WordPress ou sont infectés. Nous les supprimons à vue:

rm 1index.php index.php db.php del.php wikindex.phpCode language: CSS (css)

Nous supprimons également les répertoires wp-admin et wp-includes de WordPress car souvent des fichiers malfaisants sont copiés dedans:

rm wp-admin -rf
rm wp-includes -rf

Étape 2 : réinstallation de WordPress

On réinstalle WordPress:

wp core download --force --skip-content --locale=fr_FR --allow-root

Lire la suite

Générateur de clés WPA sécurisées photo 1

WiFi : générateur de clés WPA sécurisées

by · Lecture: 3 minutes

Le principe du chiffrement WPA-PSK

Il y a peu d’intérêt à utiliser les derniers systèmes d’authentification WiFi comme le WPA-PSK si vous utilisez un mot de passe trop facile à deviner et qui pourra être cracké en quelques minutes à peine sans trop d’effort.

Le chiffrement WPA-PSK, censé pallier les failles de son prédécesseur – WEP – est une version moins sécurisée que le WPA puisqu’il n’y a pas de serveur d’identification Radius.

Le protocole repose sur une clé partagée (Pre-Shared Key ou PSK) qui initialise le processus d’authentification.

Votre clé partagée est créée à l’aide d’un mot de passe de votre choix. Il est souhaitable et recommandé que le mot de passe ne contienne aucun mot figurant dans le dictionnaire, même sous une forme leet speak, les logiciels de crack type brute-force ou dictionnaire connaissent cette astuce depuis quelques années déjà.

La combinaison doit donc être illisible, le genre de clé qui est impossible à donner à un correspondant par téléphone.

Autrement dit, si votre mot de passe est un mot courant qui fait partie d’un dictionnaire, il pourra être cracké à l’aide d’une attaque type brute-force ou dictionnaire en moins d’une minute.

Ensuite, il faut augmenter le nombre de caractères de la clé partagée : il est plus facile de trouver un mot de passe de 4 caractères plutôt que de 63 caractères.

D’où l’intérêt d’utiliser un mot de passe de taille conséquente, composé de signes et caractères spéciaux. Cracker une clé de 63 caractères prend quelques années avec la puissance de calcul actuelle.

Générateur de clés WPA sécurisées

J’ai à cet effet créé un générateur de clés WPA sécurisées : il vous suffit de choisir le type de clé qui convient le mieux à votre usage.

Je vous recommande bien évidemment la clé de 63 caractères mais vous avez aussi la possibilité de choisir le nombre de caractères qui vous plait.

Lire la suite

NAS Synology: renouveller le certificat TLS photo 1

NAS Synology: renouveler le certificat TLS

by · Lecture: 2 minutes

Je suis en train de faire le ménage sur d’anciennes machines que je donne sur donnons.org : cela me permet de récupérer quelques (vieilles) données pour les sauvegarder sur le NAS avant de formater les disques durs pour leur nouvelle vie.

En changeant de machine, je me suis aperçu que le certificat TLS du NAS n’était plus valide… depuis fin février 2019! What??

Après quelques infructueux essais de renouveler le certificat, il semblerait que le passage à DSM 6.2 soit à l’origine du problème.

Visiblement, je ne suis pas le seul affecté.

La redirection No-IP

J’utilise depuis des années une redirection No-IP pour accéder à différents services comme le NAS ou la webradio.

Sur une session SSH sur le NAS, j’ai lancé la commande suivante:

sudo syno-letsencrypt renew-all -vv

Voilà le résultat:

HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 01 Nov 2019 10:43:12 GMT
Content-Type: application/problem+json
Content-Length: 98
Connection: keep-alive
Boulder-Requester: 6426144
Cache-Control: public, max-age=0, no-cache
Replay-Nonce: 0002Lw7vG9KbJRj_7s8e0Zuqit27lxN7Om7tdFuqaB2iCKQ

] Body: [{
  "type": "urn:acme:error:unauthorized",
  "detail": "Certificate is expired",
  "status": 403
}]
terminate called after throwing an instance of 'SLError'
Aborted (core dumped)Code language: HTTP (http)

Je n’ai jamais réussi à renouveller ou à recréer ce certificat.

J’ai donc changé mon fusil d’épaule et utilisé le service DDNS de Synology.

Lire la suite

Obtenir le statut de toutes les jails fail2ban photo

Obtenir le statut de toutes les jails fail2ban

by · Lecture: 2 minutes
fail2ban jails 1280x853

Si vous utilisez fail2ban sur votre serveur dédié – et vous devriez! – il peut être vraiment utile de lister les statuts de toutes les jails fail2ban.

Cela permet de voir quelles sont les jails actives et de vérifier qu’il n’y a aucun problème de configuration.

On peut obtenir le statuts de toutes les jails fail2ban avec la commande suivante:

fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p' | xargs -n1 fail2ban-client statusCode language: JavaScript (javascript)

Voici un exemple de résultat de la commande:

Status for the jail: pam-generic
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:
Status for the jail: postfix
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	4482
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	223
   `- Banned IP list:
Status for the jail: sasl
|- Filter
|  |- Currently failed:	4
|  |- Total failed:	14126
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	4
   |- Total banned:	1927
   `- Banned IP list:	45.148.10.70 46.38.144.17 46.38.144.202 46.38.144.32
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:Code language: PHP (php)

A garder dans sa trousse à outils!

Serveur dédié : mettre à jour OpenSSL sous Debian pour bénéficier de TLS 1.3 photo

Serveur dédié : mettre à jour OpenSSL sous Debian pour bénéficier de TLS 1.3

by · Lecture: 5 minutes

Cet article fait suite à un précédent tutoriel – installer la dernière version d’OpenSSL sous Debian.

Cela fait un petit moment que je voulais mettre à jour ma configuration TLS et je me suis dit que la Toussaint serait parfaite pour cela.

Aujourd’hui, le serveur passe donc à TLS 1.3, ce qui nécessite une mise à jour d’OpenSSL et la mise à jour des ciphers sous NginX.

Mise à jour d’OpenSSL

Je n’avais pas mis OpenSSL à jour depuis le dernier tuto donc il est aisé de connaitre sa version:

openssl version

Résultat :

OpenSSL v1.1.0fCode language: CSS (css)

Un autre moyen de connaître les versions disponibles dans les repos:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -aCode language: JavaScript (javascript)

Résultat:

openssl:amd64 1.1.0f-5 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.0f-5 newer than version in archive
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all/stable 16.2.0-1 uptodate

Pour obtenir la version 1.1.1 d’OpenSSL, qui est le sésame pour TLS 1.3, nous allons temporairement ajouter le repo sid, mettre à jour OpenSSL et ses dérivés puis remettre apt dans sa position stable.

On met à jour nos sources apt:

nano /etc/apt/sources.listCode language: PHP (php)

et on y ajoute sid:

deb http://ftp.debian.org/debian sid main
deb-src http://ftp.debian.org/debian sid mainCode language: JavaScript (javascript)

On met à jour apt:

apt update

Et on met à jour openssl:

apt install openssl libssl1.1Code language: CSS (css)

Résultat:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 libnih-dbus1 libnih1 libssl-dev locales
  python-httplib2
apt-listchanges: News
---------------------

glibc (2.26-5) unstable; urgency=medium

  Starting with version 2.26-1, the glibc requires a 3.2 or later Linux
  kernel.  If you use an older kernel, please upgrade it *before*
  installing this glibc version. Failing to do so will end-up with the
  following failure:

    Preparing to unpack .../libc6_2.26-5_amd64.deb ...
    ERROR: This version of the GNU libc requires kernel version
    3.2 or later.  Please upgrade your kernel before installing
    glibc.

  The decision to not support older kernels is a GNU libc upstream
  decision.

  Note: This obviously does not apply to non-Linux kernels.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 23 Jan 2018 22:03:12 +0100

openssl (1.1.1-2) unstable; urgency=medium

  Following various security recommendations, the default minimum TLS version
  has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
  plan to do same around March 2020.

  The default security level for TLS connections has also be increased from
Suggested packages:
  glibc-doc
The following packages will be upgraded:
Setting up libc6-i386 (2.27-8) ...
Setting up python-httplib2 (0.11.3-1) ...
Processing triggers for libc-bin (2.27-8) ...
Setting up libssl1.1:amd64 (1.1.1-2) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up libc-l10n (2.27-8) ...
Setting up openssl (1.1.1-2) ...
Installing new version of config file /etc/ssl/openssl.cnf ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up libc6-dev:amd64 (2.27-8) ...
Setting up locales (2.27-8) ...
Installing new version of config file /etc/locale.alias ...
Generating locales (this might take a while)...
  en_GB.ISO-8859-1... done
  en_GB.UTF-8... done
  en_GB.ISO-8859-15... done
Generation complete.
Setting up libnih1 (1.0.3-10+b1) ...
Setting up libnih-dbus1 (1.0.3-10+b1) ...
Setting up libssl-dev:amd64 (1.1.1-2) ...
Processing triggers for libc-bin (2.27-8) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Failed to retrieve available kernel versions.
Restarting services...
 invoke-rc.d bind9 restart
 invoke-rc.d cgmanager restart
 invoke-rc.d cgproxy restart
 invoke-rc.d fail2ban restart
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
 invoke-rc.d haveged restart
 invoke-rc.d irqbalance restart
 invoke-rc.d lvm2-lvmetad restart
 invoke-rc.d lvm2-lvmpolld restart
 invoke-rc.d lwresd restart
 invoke-rc.d mdadm restart
 invoke-rc.d mdadm-waitidle restart
 invoke-rc.d minissdpd restart
 invoke-rc.d nginx restart
 invoke-rc.d opendkim restart
 invoke-rc.d opendmarc restart
 invoke-rc.d php7.2-fpm restart
 invoke-rc.d postfix restart
 invoke-rc.d redis-server restart
 invoke-rc.d rsyslog restart
 invoke-rc.d saslauthd restart
 invoke-rc.d ssh restart
Services being skipped:
 invoke-rc.d dbus restart
No containers need to be restarted.</aurel32@debian.org>Code language: PHP (php)

On teste notre nouvelle verison d’openssl:

openssl version

Résultat:

OpenSSL 1.1.1  11 Sep 2018Code language: CSS (css)

Et en un peu plus précis:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -aCode language: JavaScript (javascript)

Résultat:

openssl:amd64 1.1.1-2 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.1-2         sid    ftp.debian.org
openssl:amd64/sid 1.1.1-2 uptodate
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64 3 sid    ftp.debian.org
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all 18.0.0-1 sid    ftp.debian.org
python3-openssl:all/stable 16.2.0-1 upgradeable to 18.0.0-1

Mettre à jour les ciphers pour NginX

Il ne nous reste plus qu’à ajouter les nouveaux ciphers pour TLS 1.3 pour les services sécurisés.

Nous mettons donc la configuration des server blocks NginX à jour:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "TLS13+AESGCM+AES128:EECDH+AESGCM:EECDH+CHACHA20";Code language: CSS (css)

On vérifie la configuration:

nginx -t

et on redémarre le serveur:

service nginx restart

Il ne vous reste plus qu’à vérifier votre configuration TLS sur SSL Labs.

Shell : créer une liste de mot de passe facilement photo

Shell : créer une liste de mots de passe facilement

by · Lecture: 3 minutes

Créer une liste de mots de passe simples

Voici un moyen très simple de créer une liste de mots de passe en utilisant le terminal sous Linux ou MacOS par exemple :

for i in `seq 1 8`; do mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX; doneCode language: JavaScript (javascript)

Explications sur le fonctionnement de la commande:

  • seq 1 8 va nous créer 8 mots de passe différents,
  • mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX va nous créer des mots de passe alphanumériques dont le nombre de caractères dépend du nombre de X. Ici, j’ai mis 24 X donc les mots de passe feront 24 caractères.

Créer une liste de mots de passe sécurisés

La méthode précédente n’est pas vraiment sécurisée car le degré d’entropie est trop faible. Pour augmenter le niveau de sécurité, j’utilise cette commande:

for i in $(seq 1 8); do LC_CTYPE=C tr -dc '[:graph:]' < /dev/urandom | tr -d "'" | tr -d '"' | head -c 64 && echo; doneCode language: JavaScript (javascript)

Voici une explication de la commande :

  • for i in $(seq 1 8); do : Cela commence une boucle for qui se répète 8 fois (de 1 à 8).
  • LC_CTYPE=C : Cela définit la variable d’environnement LC_CTYPE à la valeur C, ce qui assure que le générateur de mots de passe utilise le jeu de caractères ASCII.
  • tr -dc '[:graph:]' < /dev/urandom : Cela utilise la commande tr pour supprimer les caractères non imprimables et générer des caractères graphiques aléatoires à partir de /dev/urandom, qui est une source d’entropie aléatoire sur les systèmes Unix.
  • tr -d "'" | tr -d '"' : Cela utilise deux commandes tr supplémentaires pour supprimer les caractères de guillemets simples (') et les guillemets doubles (") des mots de passe générés. Cela garantit que les guillemets simples et doubles sont supprimés des mots de passe générés.
  • head -c 32 : Cela utilise la commande head pour limiter la longueur des mots de passe générés à 32 caractères.
  • && echo; done : Cela termine la boucle for et ajoute un retour à la ligne (echo) pour afficher chaque mot de passe généré sur une ligne séparée.

Simple et efficace, j’utilise souvent cette commande lors de la création ou l’import d’utilisateurs en masse, lors de la création d’un fichier CSV par exemple.

Cela permet d’avoir des mots de passe un minimum sécurisés dès le départ de la création des comptes utilisateurs.

Suivant →