• 1) Conserver Debian 9 (aka Stretch) ?
  • C'est envisageable car le support sera étendu (gràce à la ELTS = "Extended Long Term Support") du 1er juillet 2022 jusqu'au 30 juin 2027 !
• 2) Nouvelle version majeure d'un OS (Linux ou Windows etc) = "Restart From Scratch"
  • Autrement dit nous recommendons très fortement une nouvelle (ré)installation (de zéro et propre (en supprimant toutes les partitions)).
• 3) Quitter le navire ? Prendre tout le temps nécessaire pour réfléchir afin de remplacer cet OS ainsi que découvrir éventuellement un autre script.
  • Le miracle serait Docker ? Etant donné toutes les mauvaises histoires, ils sont nombreux à considérer que cette prétendue solution est vivement déconseillé pour les débutants.
    

    whereis python;
    python: /usr/lib/python2.7
    ## Il n'y a rien d'autre car en premier lieu, il faudra installer la dernière version 3.10.5 de python.
    python3 --version; ===> -bash: python3: command not found
    

    1.1) Avantage = L'un d'entre eux, c'est que Stretch est beaucoup plus propre (python n'est pas préinstallé etc etc etc).
    2.1) Inconvénient = La sécurité car pour mettre à jour, une grande partie des logiciels, il faudra mettre les mains dans le camboui (sauf s'il existe un dépôt et qu'il reste maintenu)
    3.1) Prenons un exemple avec curl, actuellement nous pouvons constater qu'il y a en tout 1256 vulnerabilities (faille de sécurité) sic...
    3.1) La compile ? Elle requiert beaucoup de savoir (difficile alors il faut soit découvrir un dépot, soit l'accepter, soit prendre un autre OS (basé sur ArchLinux etc))

    openssl version;
    ## Affichera celle préinstallé (par défaut dans l'OS) = "OpenSSL 1.1.0l  10 Sep 2019".
    apt -a show openssl | egrep 'Version|APT-Sources';
    ## Affichera les éventuelles mises à jours disponibles.
    ## Le résultat sera variable en fonction des dépôts (contenu dans le fichier "sources.list").
    wget -c "https://github.com/openssl/openssl/archive/OpenSSL_1_1_1p.tar.gz";\
    tar -xvf OpenSSL_1_1_1p.tar.gz;\
    cd openssl-OpenSSL_1_1_1p;\
    ./config;\
    make;\
    make test;\
    make install;\
    ## From 21-June-2022 the OpenSSL 1.1.1p is now available !
    openssl version;
    ## Permettra de vérifier l'installation ainsi que savoir s'il s'agit de la bonne version !
    

    https://packages.debian.org/stretch/openssl
    https://www.openssl.org/news/newslog.html
    https://packages.debian.org/stretch/python
    https://www.python.org/downloads/
    https://packages.debian.org/stretch/curl
    https://curl.haxx.se/docs/releases.html

    7.84.0	===>	0
    7.83.1	===>	4
    7.83.0	===>	10
    7.82.0	===>	13
    7.81.0	===>	11
    7.80.0	===>	11
    7.79.1	===>	10
    7.79.0	===>	10
    7.78.0	===>	13
    7.77.0	===>	18
    7.76.1	===>	21
    7.76.0	===>	21
    7.75.0	===>	23
    7.74.0	===>	22
    7.73.0	===>	25
    7.72.0	===>	24
    7.71.1	===>	25
    7.71.0	===>	25
    7.70.0	===>	26
    7.69.1	===>	26
    7.69.0	===>	26
    7.68.0	===>	25
    7.67.0	===>	25
    7.66.0	===>	25
    7.65.3	===>	27
    7.65.2	===>	27
    7.65.1	===>	28
    7.65.0	===>	28
    7.64.1	===>	29
    7.64.0	===>	29
    7.63.0	===>	32
    7.62.0	===>	31
    7.61.1	===>	32
    7.61.0	===>	33
    7.60.0	===>	32
    7.59.0	===>	34
    7.58.0	===>	36
    7.57.0	===>	38
    7.56.1	===>	40
    7.56.0	===>	41
    7.55.1	===>	41
    7.55.0	===>	41
    7.54.1	===>	44
    7.54.0	===>	42
    7.53.1	===>	44
    7.53.0	===>	44
    7.52.1	===>	44
    
    NombreDeVulns01  = 44+44+44+42+44+41+41+41+40+38+36+34+32+33+32+31+32+29+29+28+28+27+27 = 817
    NombreDeVulns02  = 25+25+25+26+26+26+25++25++24++25++22++23++21++21++18++13++10++10++11+11+13+10+4+0 = 439
    TotalVulns = NombreDeVulns01 + NombreDeVulns02 = 1256
    curl --version; "curl 7.52.1 (x86_64-pc-linux-gnu)" [...]
    

    HS : Non ce messsage n'annonce absolument en rien un retour de ma part ! D'autant plus que mes services sont devenus payants.
    Une unique exception = Certains jours (moments) j'accorde des conseis lorsque je m'aperçois que le bénévolat me manque.
    Parce que j'ai remarqué que quasiment la totalité des anciens membre (régulièrement présent @xavier @ex_rat @Hardware etc) ont finit par totalement disparaître (renoncer).
    Du sang neuf ? Pourtant j'avais prévenu car cette prétendu version stable de Flarum n'apportera qu'un autre échec sic... Des lustres ? Absolument rien ne fut corrigé !

Bonjour,
Je débute et je voulais créer un serveur mail j'ai donc décidé de suivre le tutoriel
https://mondedie.fr/d/5750-tuto-installer-un-serveur-de-mail-avec-postfix-dovecot-et-rainloop de @Hardware

Il n'est plus maintenu mais pourtant tout se déroulais parfaitement cependant lorsque je suis arrivé à la partie d'envoie d'email via thunderbird j'obtiens:

cannot load Certification Authority data, CAfile="/etc/postfix/ssl/cacert.pem": disabling TLS support

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: warning: TLS library problem: error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('/etc/postfix/ssl/cacert.pem','r'):

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: warning: TLS library problem: error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: warning: TLS library problem: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:../crypto/x509/by_file.c:199:

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: connect from abo.wanadoo.fr[86.xxx.xx.xxx]

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: lost connection after EHLO from abo.wanadoo.fr[86.xxx.xx.xxx]

Jul 27 21:36:15 hostname postfix/submission/smtpd[10487]: disconnect from abo.wanadoo.fr[86.xxx.xx.xxx] ehlo=1 commands=1

J'ai donc fais un ls /etc/postfix/ssl et je n'ai pas de /etc/postfix/ssl/cacert.pem
comment puis-je réparer ceci svp

(J'espère poster ceci correctement)

PS: J'ai réellement besoin de ce serveur mail pour mon application en node js

Cdt merci de votre aide

Cet article provient du Blog de @Hardware, j'espere qu'il m'en voudra pas d'essayer de le mettre à jour.
Merci à lui pour cette base.

Se protéger des attaques de type HTTP-FLOOD avec Ossec et Iptables

Aujourd'hui nous allons voir comment bloquer les attaques DDOS de type HTTP-FLOOD (couche 7 du modèle OSI) avec Ossec et Iptables. Il existe différents types d'attaques DDOS, de taille et de complexité différente.

Celle dont on va se prémunir aujourd'hui est une des plus simple. L'attaquant a juste besoin d’inonder le serveur cible avec de simples requêtes HTTP(S) GET/POST jusqu'à que le serveur ne puisse plus répondre à la charge. On peut facilement faire tomber un site web mal protégé avec un simple outil de bench.

La première chose qu'on peut faire contre ce genre d'attaque, c'est d'appliquer un rate limiting au niveau du serveur web, ça a l'avantage d'être simple à mettre en place et c'est plutôt efficace.

Par exemple avec Nginx :

Connexions maximum par ip

limit_conn_zone $binary_remote_addr zone=limit_per_ip:10m;  
limit_conn limit_per_ip 20;

Nombre de requêtes/s maximum par ip

limit_req_zone $binary_remote_addr zone=allips:10m rate=200r/s;  
limit_req zone=allips burst=200 nodelay;  

Je vous conseille la lecture de cet article qui détail le sujet :

https://www.abyssproject.net/2014/06/bloquer-les-attaques-ddos-nginx/

Comme j'utilise Ossec depuis quelques années, je me dis qu'il peut être intéressant de l'utiliser pour se prémunir de ce genre d'attaque. Ossec s'installe très rapidement et est plutôt léger, selon Daniel Cid son créateur, il peut tourner sur de très petites configurations (moins de 128Mo de RAM) tout en étant efficace quand il est bien configuré.

Voici la procédure pour l'installer sur une Debian Jessie :

cd /tmp  
wget 'https://bintray.com/artifact/download/ossec/ossec-hids/ossec-hids-2.8.3.tar.gz'  
tar xzf ossec-hids-2.8.3.tar.gz && cd ossec-hids-2.8.3/  
apt-get install libgcrypt20-dev libgnutls28-dev  

Lancer l'installateur puis démarrage du service

./install.sh
systemctl enable ossec && systemctl start ossec  

Je ne vais pas détailler le fonctionnement d'Ossec dans cet article, ce n'est pas le but mais vous pouvez toujours aller voir mon tutoriel sur mondedie.fr qui explique comment le configurer.
Tuto [Obsolète]
Discussion du Tuto

Bon on va commencer par appliquer les règles iptables. Donc l'idée de base est simple, on veut limiter le nombre de requêtes TCP sur un port particulier, donc 80/443 dans notre cas.

/sbin/iptables -N http-flood
/sbin/iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 1 -j http-flood
/sbin/iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 1 -j http-flood
/sbin/iptables -A http-flood -m limit --limit 10/s --limit-burst 10 -j RETURN
/sbin/iptables -A http-flood -m limit --limit 1/s --limit-burst 10 -j LOG --log-prefix "HTTP-FLOOD "
/sbin/iptables -A http-flood -j DROP

Il faut comprendre les règles au-dessus de la manière suivante :

• Si il y a plus d'une connexion TCP de manière simultanée (--connlimit-above) provenant d'une même IP,
• alors on lui applique le flag http-flood.
• Tant qu’il y a moins de 10 syn/seconde on laisse passer sinon iptables log le paquet et drop tout le reste.

Pour expliquer un peu plus en détail, en fait le paramètre --limit-burst 10 permet de déclencher le rate limit (--limit 10/s) uniquement si ce taux est dépassé initialement. Donc 10 req simultanées au départ puis iptables surveille que la limite de 10 req/s ne soit pas dépassée. Si c'est le cas, il log puis drop. Le compteur "limit-burst" se réinitialise à chaque fois que la limite (--limit 10/s) n'est pas dépassée.

J'ai mis le module "limit" sur la règle qui log les paquets pour ne pas que le fichier de log ne grossisse trop vite et ainsi éviter une saturation de l'espace disque. Ce n'est pas très utile vu qu'on va bannir la source juste après avec Ossec mais ça coûte rien de mettre une limite à ce niveau là.

Pour ceux qui utilisent Docker, il faut modifier l'ordre d'application des règles en remplaçant -A (append) par -I (insert), iptables parcourant les règles de haut en bas, il faut obligatoirement mettre les deux premières règles en haut de la pile, avant celles de docker, sinon elles ne s’appliqueront pas.

Il faut aussi penser à changer la chaîne par lequel le paquet va passer, avec Docker il s'agit de la chaîne FORWARD. Les règles suivantes fonctionnent bien chez moi avec un conteneur nginx en reverse proxy :

/sbin/iptables -N http-flood
/sbin/iptables -I FORWARD -p tcp --syn --dport 80 -m connlimit --connlimit-above 1 -j http-flood
/sbin/iptables -I FORWARD -p tcp --syn --dport 443 -m connlimit --connlimit-above 1 -j http-flood
/sbin/iptables -A http-flood -m limit --limit 10/s --limit-burst 10 -j RETURN
/sbin/iptables -A http-flood -m limit --limit 1/s --limit-burst 10 -j LOG --log-prefix "HTTP-FLOOD "
/sbin/iptables -A http-flood -j DROP

Bon on passe maintenant à la configuration des règles d'Ossec, ajouter le contenu suivant dans le fichier /var/ossec/rules/local_rules.xml :

<rule id="100042" level="5">  

  <if_sid>4100</if_sid>
  <match>HTTP-FLOOD</match>
  <description>Layer 7 HTTP Flood Attempt</description>
</rule>

<rule id="100043" level="5" frequency="10" timeframe="10">  

  <if_matched_sid>100042</if_matched_sid>
  <same_source_ip />
  <options>alert_by_email</options>
  <description>Multiple Layer 7 HTTP Flood Attempt</description>
  <group>attack,</group>
</rule>  

La première règle se déclenche dès qu'elle rencontre le terme HTTP-FLOOD dans les logs d'iptables (règle 4100, voir : rules/firewall_rules.xml).
La seconde règle se déclenche uniquement si la première est match plus de 20 fois (donc 20 événements HTTP-FLOOD dans les logs) pendant un laps de temps de 10 secondes.

Je sais pas si c'est très clair, si on récapitule ça donne ça :

Iptables limite à 10 connexions simultanées sur les ports 80/43
Si la limite est dépassé alors flag du paquet avec le marqueur HTTP-FLOOD
Puis ajout dans les logs de l'IP incriminée avec le flag HTTP-FLOOD
Le nombre initial d'event dans les logs est de 10 (limit-burst) puis 1/s (limit)
Donc 10 secondes d'attaque (timeframe) = 20 events HTTP-FLOOD dans les logs
Frequency = nbEvents / 2, donc 20 / 2 = 10

Il ne reste plus qu'à configurer notre active-response dans /var/ossec/etc/ossec.conf :

<active-response>  

  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100043</rules_id>                   

  <timeout>3600</timeout>                               

  <repeated_offenders>360,720,1440</repeated_offenders>
</active-response>  

Avec cette AR, l'attaquant est banni via iptables (chaînes INPUT+FORWARD) pendant une durée initiale d'une heure. Si il répète son attaque, il sera de nouveau ban pendant 6H puis 12H puis 24H. La règle 100043 correspond à celle que nous avons créé juste au dessus.

Il est aussi possible de mettre en place un ban permanent avec cette commande :

<command>  

  <name>DropForLife</name>
  <executable>firewall-drop.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>no</timeout_allowed>
</command>  

Puis en la précisant dans l'active response à la place de la commande firewall-drop.

Je ne recommande pas de bannir une IP de manière permanente, on est jamais à l'abris que les adresses IP sources soient forgées aléatoirement, l'attaquant peut prendre par exemple les adresses des serveurs de google et ainsi bloquer de manière permanente le référencement d'un site web par exemple.

Voila la protection est en place, pensez à faire un petit reboot d'Ossec pour qu'il prenne en compte les modifications :

systemctl restart ossec

J'ai par habitude d'utiliser le paquet iptables-persistent pour sauvegarder/restaurer et faire persister les règles après un redémarrage du serveur.

Sur Jessie :

apt-get install iptables-persistent
systemctl enable netfilter-persistent
systemctl start netfilter-persistent

Avant d'appliquer les règles anti-ddos, je fais toujours un backup des règles existantes :

iptables-save > /docker/iptables/default-docker.rules

Couplé avec un petit script pour revenir en arrière si les nouvelles règles posent soucis :

#!/bin/bash

# Suppression de toutes les règles iptables
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -F
/sbin/iptables -X

# Restauration des régles initiales de docker
/sbin/iptables-restore < /docker/iptables/default-docker.rules
/sbin/iptables-save > /etc/iptables/rules.v4

Au moins comme ça pas de danger, on peut revenir en arrière.

Maintenant que les règles iptables sont appliquées et Ossec configuré, on peut passer aux tests !
Accrochez vos ceintures, ça va secouer... ou pas

Pour effectuer un test, j'utilise un petit outil de benchmark de la fondation Apache, nommé Apache Bench

Bon c'est parti, on envoie la sauce :

Faites le test depuis une autre machine que celle que vous utilisez pour vous connecter sur votre serveur, ça paraît logique hein, mais je préfère le signaler quand même ^^

ab -n 2000 -c 100 http://domain.tld  

Une fois la commande lancée, vous devriez voir des logs de ce type apparaître dans les fichiers de log système /var/log/{messages, syslog} :

hostname kernel: [xxx.xxx] HTTP-FLOOD IN=eth0 OUT=docker0 MAC=xx.xx.xx.xx SRC=xx.xx.xx.xx DST=172.17.0.2
LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=55338 DF PROTO=TCP SPT=39526 DPT=8000 WINDOW=29200 RES=0x00
SYN URGP=0  

Si c'est le cas, ça veut dire que iptables fait le job. Il faut maintenant vérifier la réaction de Ossec. Regardez le fichier /var/ossec/logs/active-responses.log, normalement une ligne comme celle-ci est apparue :

/var/ossec/active-response/bin/firewall-drop.sh add - IP_BANNIE 1455541862.10638 100043

Voici une petite commande pour avoir la liste des adresses IP bannies :

iptables -L INPUT | tail -n +3

Voila, c'est une solution parmi tant d'autres, je pense qu'elle reste suffisante pour des attaques non sophistiquées de moyenne ampleur, en tout cas les scripts kiddies et autre attaquant du dimanche n'ont pas la moindre chance.

Pour des attaques plus complexes (IP forgées, botnets...etc), il existe des solutions plus efficaces mais aussi plus chers et plus compliquées à mettre en place mais là on sort un peu du cadre de cet article.

Bonsoir,

Quelques nouveautés

Seafile 7.05 + mariadb + memcached
Ubooquity

J'ai également rajouté l'installation du mailserver de @Hardware via Ansible avec incrémentation automatique de tous les DNS chez cloudflare. L'intérêt est que le temps de propagation est quasi nul et que du coup le test "mail tester" permet d'obtenir un 10 quelques minutes après l'installation.

https://discord.gg/v5dZHB5

De rien cela confirme ce que j'imaginais la solution était simple.
Néanmoins c'était facile à résoudre autrement comme l'atteste ce topic. C'est seulement afin de donner un exemple car celui-là est hyper complet.

NB : En tout cela fait 3 semaines d'absence et je constate que rien n'a changé (c'est déplorable).
Merci d'avance @Hardware ou @hydrog3n ou @ex_rat car désormais tu peux supprimer mes tutoriels.

Aeryax J'aime bien le concept et je me servais de ce genre de magouille auparavant, mais j'aimerais pouvoir m'affranchir du service dynhost... globalement mon script tourne au poil, la clé generé permet de mettre à jour la zone maitre le fichier de zone est legerement different de ce que j'avais fait mais il est cohérent et fonctionne. Il ne me reste plus qu'a trouver comment faire re-signer la zone sur le serveur DNS ( et là du coup j'ai trouvé !!!).

Donc merci @Hardware, parce qu'en lisant l'article sur le serveur DNS et DNSSEC du sus-nommé, je me suis attardé sur la partie "docker" que je découvre avec joie et d'une section :

Do not forget to add a cron task to increment the serial and sign your zone periodically to avoid the expiration of RRSIG RR records! et tout un bout de script pour l'incrementation de la ligne de code necessaire a la re-signature

Donc une fois mes 3 nuits de travail terminé je m'attaque a basculer bind vers le container nsd-dnssec de Hardware et bricoler le tout proprement

J'y voit plus clair, merci de votre précieux conseil qui m'ont fait réfléchir et d'avoir une vision plus large.

Question subsidiaire : peut on attribuer une ip supplémentaire a un seul container ?
J'achète un lot d'ip et dans le lot je veut qu'une ip soit attribué a un container spécifique ?

Merci @Aeryax et @Merrick

Bonjour

Je reviens vers vous pour vous expliquer l'indisponibilité de mondedie.fr durant le weekend dernier.
Depuis le 21 février j'ai entrepris de transférer le nom de domaine mondedie.fr de gandi vers ovh pour des raisons économiques.

En effet gandi est tout bonnement deux fois plus chère qu'ovh pour le même service.
Pourquoi ovh? Parce qu'il nous fallait un registrar qui supporte DNSSEC.

Le transfert a fini par se réaliser durant la nuit de vendredi à samedi. J'ai pu modifier la configuration de notre serveur dns primaire ns1.mondedie.fr et j'ai rajouté le serveur dns secondaire d'ovh à la configuration (enfin je le pensais).

En effet plusieurs personnes n'avaient pas accès à mondedie et d'autres oui.
La raison était qu'ovh ne propose en réalité pas de serveur dns secondaire. Et au lieu d'ajouter des serveurs dns secondaires, j'ai ajouté des serveurs dns primaires sans m'en rendre compte.

C'est pourquoi des personnes tombaient sur la bonne ip et d'autres tombaient sur l'ip par défaut des dns primaire d'ovh (une page vers un webmail apparemment).

Le temps de comprendre et avec l'aide de @Hardware nous avons corrigé cela dimanche dans l'après-midi avec le serveur dns secondaire de @Hardware (ns1.meshup.net) le temps de trouver une solution durable.

Vous pouvez constater que maintenant tout est rentré dans l'ordre

• https://dnssec-debugger.verisignlabs.com/mondedie.fr
• http://dnsviz.net/d/mondedie.fr/dnssec/
• https://www.zonemaster.net/result/ae86521efcf778f4

Voilà j'espère avoir été clair dans mes explications et nous sommes sincèrement désolés pour la gêne occasionnée.

L'équipe de mondedie.fr.

@deneth [...] On peux pas avoir une balise code

Il y a une chose @Magicalex que tu n'as pas comprise. D'une part, certes il y a pire mais d'un autre côté, c'est embêtant de devoir écrire sur plusieurs lignes.
Pour ma part, j'ai déjà trouvé une solution. Alors pour cette raison, je crois que vous pourriez éliminer la gène (en rectifiant le CSS).

D'autre part, je crois qu'il y a des personnes qui voudraient plutôt se servir des balises du BBCode. Disons que c'est une question d'habitude et elles sont surtout plus lisible et pratique.

@Wagner [...] D'ailleurs, il n'y a pas de balise code, ni de bouton pour les images.

Tu pourrais regarder @Hardware si c'est possible de les rajouter dans la barre d'outil ?
Sinon @hydrog3n pourrrais-tu nous renseigner ? Je me demande si de nos jours, c'est facile ou difficile à implémenter ?

Salut,

merci @hydrog3n c'est bien de nous tenir au courant et a priori, finalement ce bug semble être corrigé. En tout cas, pour le moment, il y a disparu.

En fait, c'est assez simple @Hardware à comprendre. Ces derniers temps (ou mois), j'étais présent de manière aléatoire et moins souvent. Comme tous les ans, la fin d'année est complexe (imprévu, vacances, surchargé, repos, etc). Donc je m'en suis pas aperçu...

D'après ce message, j'ai commencé à me rendre compte qu'il y avait surement un problème vers le 28 décembre 2018.
Peu de temps après, j'en ai obtenu la certitude au alentour du 4 janvier 2019. Au départ le bug semblait anodin et ne concernait qu'un nombre limité de personnes. Ensuite, c'est seulement ces derniers semaines que nous sommes rendu compte de son ampleur et que cela avait nettement empiré.

Et puis, je te rappel que nous sommes vraiment très très peu nombreux à être réellement actif (ou présent).
Je croyais que tu étais occupé et que tu finirais par répondre bientôt. Parce que je pensais que tu étais bloqué car tu ne voyais pas l'origine de ce bug.
Après tout, je sais parfaitement qu'il y a parfois des bugs facile ou difficile à rédoudre.

Bien entendu merci @xavier car je n'y avais pas pensé.

Bonsoir,

d'après mes notes @404 oui c'est la bonne syntaxe. Donc @hydrog3n je crois qu'il y a un autre bug, non ?
Parce que j'ai essayé l'autre jour et malgré plusieurs tentatives, la syntaxe n'était pas reconnu...
Alors à la place, j'ai juste mis les liens car je ne voyais aucune de mes images.

En tout cas, je suis certain d'une chose : elle fonctionné avant la mise à jour de Flarum.

@Wagner il n'y a pas de [...] de bouton pour les images.

À noter cet extrait provient de ce topic.

Malheureusement, le bug (du ban) est toujours là car il vient juste de se produire sic... Cela pourrait-il avoir un éventuel rapport avec le nombre d'onglet ? Parce que je consulté plusieurs topics lors de la rédaction.

Au fait @Hardware tu pourrais nous expliquer : pourquoi il est possible de consulter le site de Flarum et ce malgré le blockage complet des cookies ?
Il y a une raison en particulier ? Il y a des jours, j'aimerais pouvoir consulter MD (sans devoir autoriser les cookies). D'autant plus, je ne comprends pas l'intêret et c'est moche car cela casse tout (cela empêche le CSS de se charger alors le site devient illlisible).
Grosso modo, de nos jours, je les autorise seulement lorsque j'en ai réellement besoin.

Tu as raison, j'ai modifié le tuto. Pour communiquer avec Jackett et radarr/sonarr j'utilise ce format d'adresse
http://jackett:9117/api/v2.0/indexers/yggtorrent/results/torznab/, jackett étant le nom du container. Pareil pour rtorrent dans radarr/sonarr

Edit: je viens de regarde celui de @Hardware pour son mailserver

defaultEntryPoints = ["https","http"]

[api]
entryPoint = "traefik"
dashboard = true

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]
    minVersion = "VersionTLS12"
    cipherSuites = [
      "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305",
      "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
      "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
      "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
      "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
      "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
    ]
  [entryPoints.traefik]
  address = ":8080"
  [entryPoints.traefik.auth.basic]
  users = ["admin:{SHA}jLIjfQZ5yojbZGTqxg2pY0VROWQ="]

[acme]
email = "{{ EMAIL }}"
storage = "/etc/traefik/acme/acme.json"
entryPoint = "https"
onHostRule = true
  [acme.tlsChallenge]

[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "{{ DOMAIN }}"
watch = true
exposedbydefault = false

Concernant ta dernière question, @Aerya a posté un lien sur ce sujet
https://mondedie.fr/d/10567-configuration-des-ports-et-services/6

Pour commencer, il faudrait déjà s'efforcer de corriger ce bug.
Parce qu'il vient encore de se produire à cet instant. Certes, je n'ai rien perdu néanmoins cela commence à devenir un brin pénible (c'est la 4ème fois) sic...
Grosso modo, j'étais en pleine rédaction d'un message et le site est (re)devenu totalement HS (ou inacessible).
Heureusement, j'ai eu l'idée de recourir à un VPN et par miracle cela à fonctionné. Parce qu'ensuite j'ai pu de nouveau accéder au site.
Donc @Hardware tu devrais envisager de revoir la sécurité (niveau trop restrictif ? Erreur parmi les réglages ? etc).