Tech de Gamuza

Onduleur EATON

Christophe — 2025-02-19T15:10:03Z

Liste de tutos :

Compiler imagemagick pour ajouter les delegated

Christophe — 2023-09-14T08:33:18Z

# tranformer une image (jpg) en pdf
Si la commande convert toto.jpg toto.pdf
vous renvoie l'erreur :
>ImageMagick : No decode delegate for this image format

cela veut dire que imagemagick n'est pas compilé avec les bons delegates
la commande convert -list configure | grep DELEGATES ne doit pas vous retourner jpeg

Pour résoudre ce problème, il faut compiler le paquet à la main :

sudo apt update sudo apt install build-essential sudo apt install -y libjpeg-dev wget https://www.imagemagick.org/download/ImageMagick.tar.gz tar xvzf ImageMagick.tar.gz cd ImageMagick-[version_number] ./configure --disable-shared sudo make sudo make install sudo make check

Certbot : commandes utiles

clem — 2021-09-20T09:17:14Z

On suppose une configuration Debian 10 + Apache 2.4 + Certbot installé via Snap.
Toutes les commandes sont exécutées en sudo/root

Lister les certificats

Tous les certificats :
```
certbot certificates
```

Les domaines inclus dans le certificat mon-domaine.tld :
```
certbot certificates --cert-name mon-domaine.tld
```

Renouveler les certificats

Tester le renouvellement pour tous les certificats :
```
certbot renew --dry-run
```

Renouveler tous les certificats : certbot renew

Renouveler le domaine mon-domaine.tld : certbot renew --cert-name mon-domaine.tld

Supprimer un certificat

supprimer le domaine complet : certbot delete --cert-name mon-domaine.tld

supprimer un des sous-domaines inclus dans un certificat : ici on suppose que le certificat mon-domaine.tld inclut www.mon-domaine.tld et test.mon-domaine.tld :
- lister les sous-domaines inclus :
```
certbot certificates --cert-name mon-domaine.tld
```
  retournera :
  Found the following matching certs: Certificate Name: mon-domaine.tld Serial Number: 123456789123456789 Key Type: RSA Domains: mon-domaine.tld www.mon-domaine.tld test.mon-domaine.tld
- il faut alors relancer la commande de création du certificat en omettant le sous-domaine à éliminer, ce qui donne ici (avec une validation par la méthode webroot) : certbot -n certonly --cert-name mon-domaine.tld --expand --webroot -w /chemin/vhost/mon-domaine.tld/ -d mon-domaine.tld -d www.mon-domaine.tld

Références :

la doc officielle de Certbot : https://certbot.eff.org/docs/using.html

Utiliser un tunnel SSH comme VPN

clem — 2021-03-29T22:30:30Z

Administrateur de serveurs, vous avez besoin de tester un site web depuis une autre adresse IP que celle de votre connexion habituelle. La méthode consiste à ouvrir un tunnel SSH sur l'un de vos serveur puis utiliser ce tunnel comme proxy SOCKS de votre navigateur web : vous aurez alors l'équivalent d'un VPN en quelques instant.

Ce tutoriel suppose que vous disposez d'un accès SSH sur le serveur mon-domaine.tld.
On prendra ici comme exemple un compte toto avec une connexion "classique" (port 22, clé privée id_rsa sous Linux/MacOS ou clé id_rsa.ppk sous Windows + Putty)

1. Ouvrir le tunnel SSH

Il faut se connecter à votre serveur avec votre compte Linux habituel en passant l'option -D n° du port souhaité : on prendra ici comme n° de port le 8080, ce qui donne sous Linux/MacOS :

ssh -i ~/.ssh/id_rsa -D 8080 toto@mon-domaine.tld

ou avec Putty dans les paramètres Connexion > SSH > Tunnel :

2. Utiliser ce tunnel comme proxy SOCKS

Sous Firefox la configuration se fait dans Options > Général > Paramètres réseau :

Vérifier que votre adresse IP apparente est modifiée

Les sites web vous donnant l'adresse IP annoncée par votre navigateur sont nombreux : il suffit de vous connecter avec et sans le proxy SOCKS pour constater que celle-ci est bien modifiée !

Installation et utilisation de PhpMyadmin via tunnel SSH

clem — 2021-03-16T17:24:26Z

Sur un serveur web utilisant MySQL ou MariaDB, PhpMyadmin est l'application web la plus simple et pratique pour gérer les bases de données. Son principal problème est justement d'être tellement populaire qu'il devient une cible de choix pour les tentatives de piratage. Une solution pour éviter de l'exposer à "tous les vents" de l'internet consiste à restreindre son accès aux utilisateurs ayant une connexion SSH sur le serveur (connexion SSH en mode clé publique/clé privée uniquement bien sûr...).

Pour cela on va utiliser un tunnel SSH qui va transmettre via SSH une connexion locale (sur le port 9050 à titre d'exemple) vers le port 80 du serveur. Ce tunnel permet donc de solliciter le serveur web comme si la requête était faite en local. Une fois le fonctionnement du tunnel vérifié, il suffira de restreindre l'accès au phpmyadmin aux connexion locales, en modifiant la configuration de son vhost apache, pour qu'il ne soit plus possible d'utiliser PhpMyadmin sans passer par le tunnel.

Ce tutoriel suppose :

que vous avez un serveur web avec Apache + MySQL/MariaDB opérationnel. Ici on traitera la cas d'un Linux Debian 10 "de base".
que PhpMyadmin est installé de façon standard (via les paquets deb par exemple) et disponible sur l'URL https://mon-domaine.tld/phpmyadmin
que vous disposez d'un accès SSH sur le serveur web avec le sudo.
On prendra ici comme exemple un compte toto avec une connexion "classique" (port 22, clé privée id_rsa sous Linux/MacOS ou clé id_rsa.ppk sous Windows + Putty) : la connexion sous Linux/MacOS se fait donc avec la commande : ssh -i ~/.ssh/id_rsa toto@mon-domaine.tld
ou avec Putty :

1. Ouvrir le tunnel SSH :

Pour établir le tunnel on ouvre la connexion en précisant que l'on va faire une redirection du port 9050 de notre machine vers le port 80 du serveur sur son adresse IP locale c'est à dire 127.0.0.1 ou localhost.
Avec un terminal Linux/MacOS (bash ou Zsh) cela donne :

ssh -L 9050:127.0.0.1:80 -i ~/.ssh/id_rsa toto@mon-domaine.tld

Avec Putty on configure le tunnel dans le sous-menu Connection > SSH > Tunnels :

NB : bien évidemment il faut que la connexion SSH reste ouverte tout le temps où l'on utilise le tunnel...

2. Se connecter via le tunnel :

Une fois la connexion établie on peut alors utiliser le tunnel via son navigateur en se rendant sur l'URL locale http://localhost:9050/phpmyadmin
En principe on doit arriver sur le PhpMyadmin du serveur distant :

3. Interdire les accès "externes" au PhpMyadmin :

Une fois que l'on est certain que le tunnel fonctionne, il ne reste qu'a interdire les accès autres que depuis la machine locale (i.e. via le tunnel) au PhpMyadmin. Pour cela on va ajouter une option de configuration d'apache pour le dossier qui héberge l'application PhpMyadmin :

dans /etc/apache/conf-available on crée un nouveau fichier phpmyadmin-secure.conf dans lequel on met une directive Directory de la forme :
```
 Require local 
```
pour un phpmyadmin installé dans /var/www/mon-domaine.tld/html/phpmyadmin (à adapter en fonction de la configuration du serveur bien sûr...)
on active cette option de configuration avec la commande apache :
```
a2enconf phpmyadmin-secure
```
...et pour éviter les mauvaises surprises on teste que tout est OK :
```
apachectl configtest
```
si le retour est OK, on peut recharger la configuration d'apache pour faire prendre en compte cette modification :
```
systemctl reload apache2.service
```

A partir de là, la connexion "directe" via https://mon-domaine.tld/phpmyadmin doit retourner Forbidden (et si on veut améliorer la dissimulation du PhpMyadmin sur cette machine on peut même envisager une Rewrite Rule qui renvoie phpmyadmin en 404)

Références :

https://firxworx.com/blog/it-devops/sysadmin/install-and-secure-phpmyadmin-so-it-must-be-accessed-via-an-ssh-tunnel/

Supprimer une règle de filtrage iptables

clem — 2018-08-21T10:37:40Z

Scénario type :

Vous avez fait plein d'essais de connexion sur un de vos serveur sécurisé avec fail2ban et vous vous retrouvez blacklisté ? Les commandes pour supprimer la règle qui vous exclu.
Bien évidemment on suppose ici que vous avez accès en SSH à la machine : par exemple depuis un autre serveur ou via un VPN... bref depuis une IP qui elle n'est pas exclue !

1. Lister les règles par type et connaître leur numéro

iptables -L --line-numbers

Cela va vous donner la liste des règles en cours dans iptables, classées par types de chaînes, par exemple ici on pourrait avoir :

num target prot opt source destination 1 f2b-recidive tcp -- anywhere anywhere 2 f2b-postfix tcp -- anywhere anywhere multiport dports smtp,submission 3 f2b-suhosin tcp -- anywhere anywhere multiport dports http,https 4 f2b-php-url-fopen tcp -- anywhere anywhere multiport dports http,https 5 f2b-apache-shellshock tcp -- anywhere anywhere multiport dports http,https ... Chain f2b-apache-auth (2 references) num target prot opt source destination 1 REJECT all -- AMarseille-111-2-333-444.w123-456.abo.wanadoo.fr anywhere reject-with icmp-port-unreachable 2 RETURN all -- anywhere anywhere ...

on constate dans cet exemple que l'adresse AMarseille-111-2-333-444.w123-456.abo.wanadoo.fr est bloquée par la règle f2b-apache-auth (typiquement après trop de tentatives de login avec un mot de passe incorrect)

2. Supprimer la règle intempestive :

Méthode 1 : "débannir" l'IP
Dans ce cas la règle à supprimer est celle de la ligne n°1 de la chaine f2b-apache-auth :

iptables -D f2b-apache-auth 1

Avec :

-D : pour supprimer la règle
f2b-apache-auth 1 : référence de la ligne n°1 de la chaine f2b-apache-auth

Méthode 2 : autoriser l'IP inconditionnellement
Ici il s'agit d'ajouter une règle qui accepte votre IP :
Si on suppose que votre IP externe est 111-2-333-444, cela donne :

iptables -I INPUT -s 111-2-333-444 -j ACCEPT

Optimisation des en-têtes HTTP pour apache 2.4

clem — 2018-05-26T02:21:32Z

Problématique :

En fonction des modules chargés et de sa configuration, un serveur apache retourne des en-têtes HTTP ("HTTP headers") lorsqu'il répond à une requête.
Voir https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Response_message pour plus de précisions

Examen des en-tête HTTP à l'aide des outils de développement de Firefox

Un certain nombre de ces réponses sont utiles voire indispensables pour un échange optimal des données entre le serveur et le navigateur : voir les outils de "mesure" de l'optimisation des sites tels que Google page speed ou Dareboost par exemple.

Quelques amélioration des en-têtes HTTP d'un serveur apache 2.4 ayant la configuration "de base" Debian sont donc possibles.
La consultation de ces en-têtes de réponse est possible avec les outils de développement intégrés dans Firefox, onglet "Réseau"

1. Configuration des modules d'apache :

A priori ici on essaye au maximum de faire des configurations pour l'ensemble du serveur : on utilisera donc les fichiers chargés par apache et ses modules.
Pour une distrib Debian 9 "de base", ces fichiers sont donc situés :

pour apache le fichier de configuration par défaut est : /etc/apache2/apache2.conf
pour les modules ce sont les fichiers nom-du-module.conf dans /etc/apache2/mods-available/.

Pour mémoire, un module présent dans /etc/apache2/mods-available/ n'est activé pour apache que si il y a un lien symbolique qui pointe sur lui dans /etc/apache2/mods-enable/.
En ligne de commande pour activer un module :

sudo a2enmod nom-du-module

et pour le désactiver :

sudo a2dismod nom-du-module

Pour configurer un module, en général il suffit d'éditer le fichier nom-du-module.conf :

sudo nano /etc/apache2/mods-avalaible/nom-du-module.conf

2. Optimisations possibles :

Ajouter le mime-type des polices usuelles en @font-face ainsi que celui des fichiers SVG :
Module concerné : mod_mime et son fichier de configuration mime.conf
on va ajouter les lignes suivantes pour activer le mime-type de fichiers de police woff, woff2... [1] ainsi que ceux des dessins vectoriels SVG qui font une entrée en force dans les éléments graphiques du web moderne :
```
	# ajout du mime-type pour les SVG AddType image/svg+xml svg AddType image/svg+xml svgz # ajout du mime-type pour les polices font-face AddType font/ttf .ttf AddType font/eot .eot AddType font/otf .otf AddType font/woff .woff AddType font/woff2 .woff2
```
Ajouter la compression des SVG :
Module concerné : mod_deflate et son fichier de configuration deflate.conf
ajout de la ligne :
```
	# ajout de svg AddOutputFilterByType DEFLATE image/svg+xml
```
Optimiser la mise en cache des fichiers compressés : ajout de l'en-tête Vary : Accept-Encoding :
(cf https://blog.stackpath.com/accept-encoding-vary-important)
Module concerné : mod_headers : ce module n'ayant pas de fichier de configuration par défaut, on peut le créer :
```
sudo nano /etc/apache2/mods-avalaible/headers.conf
```
et ajouter le contenu suivant dedans :
```
  Header append Vary: Accept-Encoding  
```
Il suffit ensuite d'activer ce nouveau fichier avec :
```
sudo a2enmod headers
```
tant qu'on y est on d'enrichir la configuration du module mod_headers, on peut en profiter pour ajouter une série d'en-têtes de sécurité :
- le blocage du chargement des pages web de ce serveur dans des frames ou iframe d'un autre site ("clickjacking") :
- imposer le HTTPS (HSTS)
- le blocage en cas de problème XSS

Ce qui donne dans headers.conf l'ajout du contenu suivant :

 Header always set X-FRAME-OPTIONS "DENY" Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" Header always set X-Content-Type-Options "nosniff" Header always set X-XSS-Protection "1; mode=block"

Pour rendre opérationnelles ces modifications de configuration il ne reste plus qu'à tester et recharger la configuration du serveur apache :

sudo apachectl configtest # doit retourner: Syntax OK sudo systemctl restart apache2.service

3. Complément pour chaque vitualhost : l'en-tête "Content-Security-Policy" (CSP) :

Si l'on veut être complet dans l'optimisation des en-têtes HTTP, il est nécessaire d'ajouter pour chaque virtualhost (soit dans son fichier de définition dans /etc/apache2/sites-avalaible/nom-du-site.tld.conf soit dans un fichier .htaccess à la racine du document-root) un en-tête de type "Content-Security-Policy" (CSP) permettant la mise en place d'une politique de sécurité qui va expliciter au navigateur web les serveurs qui sont autorisés à délivrer des ressources pour former la page :
Dans les 2 cas le fichier devra contenir quelque chose du genre :

# en-tête HTTP "Content-Security-Policy" (CSP)  Header set Content-Security-Policy "base-uri 'self'; object-src 'none'; script-src 'self' https://mon-serveur-annexe.tld"

ici on n'autorise que le serveur du site web et mon-serveur-annexe.tld comme sources de script.

4. Références pour les en-têtes CSP :

Site de référence : https://content-security-policy.com/
des explications plus complètes : https://www.html5rocks.com/en/tutorials/security/content-security-policy/
un outil de test : https://observatory.mozilla.org/
un autre outil de test (permet de choisir la version de CSP) : https://csp-evaluator.withgoogle.com/
deux exemples commentés :
- https://hacks.mozilla.org/2016/02/implementing-content-security-policy/
- https://www.nicolas-hoffmann.net/source/1697-Obtenir-une-bonne-note-sur-Mozilla-Observatory-HTTPS-CSP-SRI-CORS-HSTS-HPKP-etc.html
Sur seenthis :
- https://seenthis.net/messages/522624#message523937
- https://seenthis.net/messages/523919

[1] nb : les types font/woff, font/woff2... ont étés officialisés en février 2017 par la RFCF8081

Configurer la langue par défaut du système : les "locale"

clem — 2018-03-27T10:13:29Z

Sur une installation par défaut de Debian avec apache / PHP, un certain nombre de fonctions de PHP (date() ou mktime() par exemple) retournent des dates formatées en anglais, par exemple Monday 26th of March 2018.
Si l'on souhaite qu'elles soient en français, il faut changer la configuration de la langue par défaut du système en utilisant les locale

Modification du fichier de configuration des langues disponibles :

Le fichier de configuration responsable des langues est /etc/locale.gen : pour l'éditer il faut être en sudo/root
En utilisant nano comme éditeur cela donne :

sudo nano /etc/locale.gen

On va alors ajouter en tête du fichier toutes les variantes du français (avec ou sans UTF8) comme langues disponibles, ce qui donne après modification :

fr_FR ISO-8859-1 fr_FR.UTF-8 UTF-8 fr_FR.UTF-8@euro UTF-8 fr_FR@euro ISO-8859-15 en_US.UTF-8 UTF-8 # aa_DJ ISO-8859-1 # aa_DJ.UTF-8 UTF-8 # aa_ER UTF-8 # aa_ER@saaho UTF-8 # aa_ET UTF-8 # af_ZA ISO-8859-1 # af_ZA.UTF-8 UTF-8 # ak_GH UTF-8 ...

toutes les langues commentées (= précédées d'un #) ne sont pas disponibles

Régénération des locales :

Pour que le système prenne en compte les modifications de locale.gen, il faut lancer la commande régénération des locales (toujours en sudo/root) :

sudo locale-gen

On peut alors vérifier les langues disponibles pour le système avec la commande :

 locale -a

qui devrait donner quelque chose comme :

C C.UTF-8 en_US.utf8 français french fr_FR fr_FR@euro fr_FR.iso88591 fr_FR.iso885915@euro fr_FR.utf8 fr_FR.utf8@euro POSIX

Une fois le serveur apache redémarré pour prendre en compte cette modification du système :

sudo systemctl restart apache2 ou sudo /etc/init.d/apache2 restart

l'affichage de la date par le même script PHP devrait donner : Lundi 26 mars 2018

Références :

https://wiki.debian.org/Locale

Ajouter des règles de filtrage dans iptables "à la volée" et les rendre permanentes

clem — 2018-03-20T23:41:45Z

1. Scénario type :

Sur un serveur Debian qui fait tourner Syncthing, logiciel de synchronisation de dossiers et fichiers (cf https://syncthing.net/), une des méthodes possibles pour permettre d'avoir plusieurs utilisateurs qui synchronisent leurs données en parallèle est d'attribuer un port spécifique à chaque utilisateur. Cela permet d'avoir des instances multiples de Syncthing sans aucun échange possible entre les utilisateurs.
La difficulté de cette méthode est que, par défaut, le firewall du serveur, Iptables, bloque tous les ports qui ne sont pas explicitement ouverts. L'idée est donc d'ouvrir un port spécifique dans le firewall à chaque fois que l'on ajoute une instance de Syncthing afin que le nouvel utilisateur puisse communiquer avec le serveur.

2. Ajouter une règle dans Iptables : ouverture d'un port en entrée/sortie

Par exemple ici on souhaite ouvrir le port 22001 :

iptables -A OUTPUT -p tcp --dport 22001 -j ACCEPT iptables -A INPUT -p tcp --dport 22001 -j ACCEPT

On vérifie alors que les nouvelles règles permettant les entrées et sorties sur le port 22001 sont opérationnelles :

iptables -L

doit alors retourner quelque chose comme (seules les lignes qui nous intéressent sont affichées) :

Chain INPUT (policy DROP) target prot opt source destination [...] ACCEPT tcp -- anywhere anywhere tcp dpt:22001 Chain OUTPUT (policy DROP) target prot opt source destination [...] ACCEPT tcp -- anywhere anywhere tcp dpt:22001 ACCEPT all -- anywhere anywhere

On a donc bien entrée/sortie autorisées sur le port 22001.

NB : autre modification courante lors d'essais et bricolages sur iptables :
autoriser l'IP xx.yyy.zzz.aa quelque soit le protocole et le port :

iptables -A INPUT -s xx.yyy.zzz.aa -j ACCEPT iptables -A OUTPUT -d xx.yyy.zzz.aa -j ACCEPT

3. Rendre les règles permanentes : iptables-save

La commande iptables ... utilisée ci-dessus à pour caractéristique que les règles sont bien intégrées dans le firewall et opérationnelles immédiatement (c'est le principe même de fonctionnement de fail2ban par exemple) mais qu'en revanche ces règles seront perdues au prochain redémarrage d'iptable (typiquement au prochain redémarrage du serveur).
Pour rendre les règles permanentes il faut alors les sauvegarder dans le fichier /etc/iptables/rules.v4 ou /etc/iptables/rules.v6 (selon qu'il s'agit de règles spécifiques pour IP V4 ou V6).
Deux méthodes sont possibles :

méthode 1 : éditer le fichier voulu : par exemple
```
nano /etc/iptables/rules.v4
```
puis copier/coller les règles dans le fichier (AVANT la dernière ligne)
méthode 2 : enregistrer iptables tel qu'il est avec l'utilitaire iptables-save :
```
iptables-save > /etc/iptables/rules.v4
```
Attention ! si vous utilisez fail2ban ou un autre utilitaire qui ajoute temporairement des règles à iptables, il est conseillé de réinitialiser les règles à l'état de démarrage pour ne pas se retrouver à sauvegarder les règles temporaires.
Pour cela on va "redémarrer" iptables AVANT de créer les nouvelle règles permanentes :
```
service netfilter-persistent restart
```
commande qui sera donc faite avant celles du paragraphe 2 qui ajoutent les règles.

Références :

doc de base sur iptables : https://debian-facile.org/doc:reseau:iptables-pare-feu-pour-un-client
gérer les règles et leur sauvegarde sous Debian 9 : https://www.geek17.com/fr/content/debian-9-stretch-securiser-votre-serveur-avec-le-firewall-iptables-32
ipables-save : https://www.thomas-krenn.com/en/wiki/Saving_Iptables_Firewall_Rules_Permanently
des exemples de syntaxe d'iptables : http://lea-linux.org/documentations/Iptables
et la doc ultra complète et poussée sur iptables : https://www.inetdoc.net/guides/iptables-tutorial/

Iptables - bloquer des IP

Christophe — 2016-08-23T09:13:46Z

Comment configurer iptables pour bannir une ou plusieurs adresses IP

Pour une IP seule :

iptables -I INPUT -s IP_ADRESS -j DROP

Pour bloquer la plage d'adresses suivante : 222.186.56.*

iptables -I INPUT -s 222.186.56.0/24 -j DROP

Pour bloquer la plage d'adresses suivante : 222.186.*.*

iptables -I INPUT -s 222.186.0.0/16 -j DROP

Pour bloquer la plage d'adresses suivante : "222.*.*.*

iptables -I INPUT -s 222.0.0.0/8 -j DROP

Bloquer les appels depuis le serveur vers une adresse IP :

iptables -A OUTPUT -d IP_ADRESS -j DROP