Modifications Pi-Hole

Pour éviter les problème de migration entre la v5 et la v6, voici ce qui a été utile de faire dans mon cas :

1. Suppression du secret pour la page web
   Dans le service retirer :

secrets:
      - 'webpass'

2. Retirer les lignes secrets

secrets:
  webpass:
    file: "./webpass.secret"

3. supprimer les fichiers de base de données de statistique afin d’éviter un docker qui ne boot pas correctement et l’erreur suivante : ERROR: SQLite3: recovered 3 frames from WAL file /etc/pihole/pihole-FTL.db-wal (283)
   pihole-FTL.db
   pihole-FTL.db-shm
   pihole-FTL.db-wal
4. Mettre à jour : docker compose pull && docker compose down -v && docker compose up -d
5. Définir le mot de passe de l’admin web : docker exec -it votre_container pihole setpassword

Exemple d’un docker-compose simple :

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      #- "67:67/udp"
      - "2080:80/tcp"
      #- "2443:443/tcp"
    volumes:
      - '/var/lib/docker/data/pihole/etc-pihole/:/etc/pihole/'
      - '/var/lib/docker/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    environment:
      TZ: 'Europe/Paris'

    restart: unless-stopped

Pour le reste des options docker pour Pi-Hole, référencez vous à mon article précédent, ainsi que la documentation officielle est très bien faite.

Liste d’url de backlist perso

Voici ma list d’url avec leur description :

Et pour copier ces blacklists :

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts	
https://raw.githubusercontent.com/StevenBlack/hosts/master/extensions/fakenews/hosts
https://v.firebog.net/hosts/static/w3kbl.txt	
https://adaway.org/hosts.txt	
https://raw.githubusercontent.com/anudeepND/blacklist/master/adservers.txt	
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt	
https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&mimetype=plaintext	
https://v.firebog.net/hosts/Easyprivacy.txt	
https://v.firebog.net/hosts/Prigent-Ads.txt	
https://raw.githubusercontent.com/FadeMind/hosts.extras/master/add.2o7Net/hosts	
https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt	
https://hostfiles.frogeye.fr/firstparty-trackers-hosts.txt
https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/gambling/hosts	
https://raw.githubusercontent.com/kevle1/Windows-telemetry-blocklist/master/windowsblock.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/domains/native.winoffice.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/domains/native.amazon.txt	
https://raw.githubusercontent.com/lassekongo83/Frellwits-filter-lists/master/Frellwits-Swedish-Hosts-File.txt	
https://v.firebog.net/hosts/AdguardDNS.txt	
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/rpz/tif.mini.txt

Le projet github de mullvad d’où vient quelques listes.

L’article Pi-Hole migration v5 vers v6 est apparu en premier sur Mon linux.

Cependant, vous pouvez faire plus avec Fredium, synchroniser ces espaces de travail sur vos différentes machines! Vous avez 2 choix :

• Vous créez facilement un compte en ligne
• Vous auto-hébergé la partie serveur de synchronisation Fredium

Je vais partir sur l’auto-hébergement comme pour le reste, surtout que c’est très léger…

Fredium est aussi bénéfique dans le milieu professionnel : elle permet d’avoir plusieurs instances Teams en parallèles, de recevoir des alertes de monitoring avec Telegram, etc.

Fredium-server

Simple docker-compose

Je vous libre le docker-file simple avec l’utilisation d’un mapping de port si vous n’avez pas encore de service Traefik. Vous pouvez vous en service avec docker Desktop pour le tester.

version: '3.7'

services:
  ferdium-server:
    image: ferdium/ferdium-server:latest
    container_name: ferdium-server
    mem_limit: 500M
    environment:
      - NODE_ENV=development
      - IS_CREATION_ENABLED=true
      - IS_DASHBOARD_ENABLED=true
      - IS_REGISTRATION_ENABLED=true
      - CONNECT_WITH_FRANZ=false
      - DATA_DIR=/data
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
    env_file:
      - .env
    volumes:
      - /var/lib/docker/data/ferdium/data:/data
      - ferdium-recipes-vol:/app/recipes
    ports:
      - 3333:3333
    restart: unless-stopped

volumes:
  ferdium-recipes-vol:

Docker-compose pour Traefik

Si vous avez déjà un Traefik, voici la configuration. Veuillez à remplacer le nom du réseau et l’url.

version: '3.7'

networks:
  proxy-net:
    external: true

services:
  ferdium-server:
    image: ferdium/ferdium-server:latest
    container_name: ferdium-server
    mem_limit: 500M
    environment:
      - NODE_ENV=development
      - IS_CREATION_ENABLED=true
      - IS_DASHBOARD_ENABLED=true
      - IS_REGISTRATION_ENABLED=true
      - CONNECT_WITH_FRANZ=false
      - DATA_DIR=/data
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
    env_file:
      - .env
    volumes:
      - /var/lib/docker/data/ferdium/data:/data
      - ferdium-recipes-vol:/app/recipes
    networks:
      - proxy-net
    restart: unless-stopped
    labels:
      - traefik.enable=true
      #redirect http de base dans configuration
      #https entry
      - "traefik.http.routers.ferdium.rule=Host(`ferdium.xxx`)"
      - traefik.http.services.ferdium.loadbalancer.server.port=3333
      - traefik.http.routers.ferdium.tls.certresolver=le
      - traefik.http.routers.ferdium.entrypoints=websecure
      - "traefik.http.routers.ferdium.middlewares=secure-headers@file"

volumes:
  ferdium-recipes-vol:

Fichier d’environement

Pour les données de configuration de mail, il est préférable de mettre dans un fichier .env si l’utilisation de secrets est possible avec l’image. Pour Ferdium en local ce sera suffisant.

Ainsi, remplacez l’url par celle définie pour Traefik, remplacez les données d’email par ceux de votre fournisseur ou relais si vous voulez la récupération de compte en cas de mot de passe perdu.

APP_URL=https://ferdium.xxx
DB_CONNECTION=sqlite
MAIL_CONNECTION=smtp
SMTP_HOST=mail.infomaniak.com
SMTP_PORT=587
MAIL_SSL=true
MAIL_USERNAME="sender@xxx.com"
MAIL_PASSWORD="xxx
MAIL_SENDER="sender@xxx.com"

Plus d’info sur les variables d’environnement de ferdium-server.

Créer votre ou vos comptes avec l’application Fredium

Une fois l’application Fredium téléchargée, vous devez changer de serveurs pour ne pas utiliser les officiels et être en auto-hébergement pur pour organiser vos app!
Cliquez sur « change here »

Sélectionnez un server de type custom, entrez le dns utilisé sur votre Traefik pour Ferdium.

Une fois branché sur votre serveur, vous pouvez créer un compte :

Pour terminer, vous rentrez vos données, l’email est en cas de récupération de mot de passe perdu :

Interdire l’enregistrement d’un nouvel utilisateur

Si vous utilisez Fredium personnellement, vous n’avez pas besoin de laisser la possibilité de s’enregistrer. Il n’y a pas de possibilité d’avoir une « acceptation » des enregistrement, seul point que l’on pourrait reprocher à Fredium-server.

Il faut changer la variable d’environement :

IS_REGISTRATION_ENABLED=true

Par :

IS_REGISTRATION_ENABLED=false

Et faire un docker-compose up -d

L’article Fredium – interface d’application web auto-hébergée est apparu en premier sur Mon linux.

Une autre solution est Watchtower qui peut fonctionner en notification ou mettre à jour les containers directement. Mais il nécessite une interaction avec les containers, ce que je veux éviter.

Je suis donc parti sur docker-notify. L’image docker sur le docker hub n’est plus maintenue. Je suis donc parti du github et un build local. Le github n’est plus trop maintenu actuellement, mais l’on voit des utilisateurs actifs autour et un CI/CD est en place pour mettre à jour les dépendances, ce qui permet d’être à jour sans avoir de nouvelles features. D’autres forks sont actif aussi, surtout celui de TonyRL qui passe par une refonte du dockerFile, utilisation de yarn au lieu de npm, une feature pour utiliser ses identifiants dockerhub, mais la compatibilité avec le fichier de configuration de schlabbi semble cassé, le dernier commit de TonyRL compatible étant le 228513a8.

Création des dossiers :

mkdir -p /etc/docker/docker-notify/conf && cd /etc/docker/docker-notify

Création du fichier d’environnement vim .env :

CONFIG_DIR=/etc/docker/docker-notify/conf

Cloner la dernière version du projet git de Schlabbi :

git clone https://github.com/Schlabbi/docker-notify

Docker-compose de Docker-notify

version: '3.7'
services:
  docker-notify:
    build: ./docker-notify
    mem_limit: 300m
    container_name: docker-notify
    restart: unless-stopped
    volumes:
      - $CONFIG_DIR/config.json:/usr/src/app/config.json:ro
      - cache:/usr/src/app/cache

volumes:
  cache:

Explication du docker-compose :

• Je met une limite mémoire sur le container de 300 Mo
• Je nomme le container car je suis en docker « classique » pas de swarm
• Le container démarre automatiquement au démarrage sauf si je l’éteins manuellement
• Le fichier de configuration est monté en bind RO car il n’a pas besoin d’être édité
• Le container à besoin d’avoir un cache. Celui-ci pouvant être perdu, j’utilise un volume temporaire déclaré

Le fichier de configuration json avec notification Telegram

Vous aurez besoin de votre clé API Telegram ainsi que de générer un chatID. Je parle de ces étapes dans l’article sur les notifications Telegram pour les serveurs linux. Suivez donc ces étages pour avoir les identifiants Telegram nécessaire pour faire les notifications en cas de mise à jour d’une image docker particulièrement critique. Pour toutes, ce serait de trop.

Voici le fichier config.json d’exemple à mettre dans /etc/docker/docker-notify/conf :

{
  "checkInterval": 1440,
  "notifyServices":[
      {
          "image": "nextcloud:24",
          "actions": [
              {
                  "type": "mailHook",
                  "instance": "generalMail",
                  "recipient": "belgotux@mondomain.net"
              },
              {
                  "type": "webHook",
                  "instance": "telegram"
              }
          ]
      },
      {
          "image": "nextcloud:latest",
          "actions": [
              {
                  "type": "mailHook",
                  "instance": "generalMail",
                  "recipient": "belgotux@mondomain.net"
              },
			        {
                  "type": "webHook",
                  "instance": "pushbullet"
              }
          ]
      },
      {
          "image": "redis:5-alpine",
          "actions": [
              {
                  "type": "mailHook",
                  "instance": "generalMail",
                  "recipient": "belgotux@mondmain.net"
              }
          ]
      }
  ],
  "smtpServer": {
      "generalMail": {
          "host": "mail.infomaniak.com",
          "port": 465,
          "secure": true,
          "username": "votreuserouvotremail",
          "password": "votrepass",
          "sendername": "Docker-Notify",
          "senderadress": "votremail"
      }
  },
  "webHooks":{
      "telegram": {
          "reqUrl": "https://api.telegram.org/botVOTRE_CLE_API/sendMessage",
          "httpMethod": "GET",
          "httpBody": {
              "text": "$msg",
              "chat_id": "VOTRE_CHAT_ID"
          }
      },
      "pushbullet": {
        "reqUrl": "https://api.pushbullet.com/v2/pushes",
        "httpMethod": "POST",
        "httpHeaders": {
            "Access-Token": "VOTRE_TOKEN",
            "Content-Type": "application/json"
        },
        "httpBody": {
            "type": "note",
            "title": "docker-notify",
            "body": "$msg"
        }
  }
}

Explications :

• checkInterval : le temps de vérification exprimé en minutes, ici toutes les 24h
• notifyServices : la liste de nos images à vérifier ainsi que l’action ou les actions à utiliser. Dans mon cas j’ai les mail et le webHooks telegram
• smtpServer : vous renseignez le serveur mail à utiliser, attention qu’il faut du TLS explicite (port 465) et pas du startTLS (pour 587). Ou alors en claire vers votre relais interne (dans ce cas mettre "secure": false)
• webHooks: permet de faire appel à un mécanisme CI/CD pour recompiler automatiquement votre image perso avec la mise à jour de l’image parent par exemple. Dans mon cas, c’est de cette manière que Telegram est utilisé pour m’avertir de la mise à jour d’une image importante

L’article Notification Telegram – Pushbullet – mail d’une image Docker mise à jour est apparu en premier sur Mon linux.

Installer docker Desktop : Documentation et téléchargement direct.

Commencer par installer le plugin Portainer, cela vous permettra de travailler proprement avec des docker-compose plutôt que de simple container. Il est évidemment possible de faire en ligne de commande, mais l’interface est plus convivial pour du développement.

Ouvrir Portainer :

En configuration pour développement local utiliser Get Started :

Nous pouvons expendre le menu pour se repérer plus facilement la première fois :

On sélectionne notre environnent local pour créer un réseau afin qu’il soit permanent pour être utilisé entre notre reverse proxy Traefik et nos apps. Je le nomme proxy-net :

Notre réseau est présent avec un range IP attribué : 172.24.0.0/16. Si cela pose problème avec un réseau déjà existant dans l’entreprise, vous pouvez en attribuer un autre

On crée notre stack Traefik et un stack Mailhog comme exemple d’application web derrière Traefik. Cela peut être via un copier coller, mais aussi via un repository. Pratique pour mettre le docker-compose.yml dans notre projet directement

Stack de traefik sous Docker Desktop

Voici la stack ou docker-compose pour Traefik :

version: "3.7"

services:
  proxy:
    image: "traefik:v2.8"
    container_name: proxy
    command:
      - --entrypoints.web.address=:80
      - --providers.docker
      - --api.insecure
    ports:
      - "80:80"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    networks:
      - proxy-net

    labels:
      - traefik.enable=true
      - traefik.http.services.mgt.loadbalancer.server.port=8080
      - traefik.http.routers.mgt.entrypoints=web
      - "traefik.http.routers.mgt.rule=Host(`mgt.localhost`)"

networks:
  proxy-net:
    external: true

On test via l’url http://mgt.localhost si on a bien l’interface traefik :

Pas besoin d’ajouter quoi que ce soit dans son fichier hosts pour un sous domaine de localhost.

On y voit déjà notre première application qui passe par le reverse proxy qui n’est autre que l’interface de management de traefik. Dans un environnent accessible depuis l’extérieur nous devrions sécuriser l’accès via un login/password. Mais ici aucune nécessité en localhost sur notre pc si notre fw est bien configuré.

Pour le sécuriser, générer un mot de passe pour Apache via un container :

docker run --rm --name apache httpd:alpine htpasswd -nb user password

Les labels :

- "traefik.http.middlewares.auth-mgt.basicauth.users=MONUSER$xxxx$$STiVjGO4$ATj6up2mVZR7Jqk4YzD8h."
- traefik.http.routers.mgt.middlewares=auth-mgt

Stack de Mailhog sous Docker Desktop

Les points importants sont de déclarer ET d’utiliser le réseau proxy-net commun avec le reverse proxy pour que celui-ci puisse communiquer avec notre application en backend.
Quand un container de notre application expose plusieurs ports, bien définir à Traefik lequel utiliser via loadbalancer.server.port car il ne sera pas choisir à notre place… S’il n’y a qu’un seul port d’exposer, le label est facultatif.

version: "3.7"
networks:
  proxy-net:
    external: true

services:
  mailhog:
    image: mailhog/mailhog
    container_name: mailhog
    ports:
      - 25:25
    networks:
      - proxy-net
    user: root
    labels:
      - traefik.enable=true
      - traefik.http.services.mailhog.loadbalancer.server.port=8025
      - traefik.http.routers.mailhog.entrypoints=web
      - "traefik.http.routers.mailhog.rule=Host(`mailhog.localhost`)"

Une fois le stack lancé, on le voit sur la page de management de traefik et il est accessible via l’url http://mailhog.localhost :

L’article Minimal Docker Desktop stack de développement sous windows est apparu en premier sur Mon linux.

Cela vous permet d’avoir une alternative à uptimerobot mais sous votre contrôle! Cela permet d’avoir des tests depuis un serveur interne, mais vous pouvez très bien avoir un vps 1vcpu/1Go avec uniquement votre traefik et votre uptime-kuma dans votre docker!

Docker Uptime-kuma

Le fichier de docker-compose.yml d’Uptime-kuma est très lisible. Je vous joins le lien direct du docker-hub. Ce docker-compose est à utiliser avec votre proxy Traefik, mais vous pouvez très bien utiliser simplement un port mapping vers le port 80.

version: "3.7"

services:
  uptime:
    image: "louislam/uptime-kuma:latest"
    container_name: uptime
    volumes:
      - $PWD/data:/app/data
    networks:
      - proxy-net
    restart: unless-stopped
    labels:
      - traefik.http.routers.uptime.rule=Host(`uptime.domain.tld`)
      - traefik.http.routers.uptime.tls.certresolver=le
      - traefik.http.routers.uptime.entrypoints=websecure

networks:
  proxy-net:
    external: true

Configuration des notifications uptime-Kuma

Une vaste quantité de notification sont disponibles. Dans mon cas j’utilise la notification mail qui est activée par défaut pour tous les services à monitorer.

Ajouter un nouveau Monitor

Comme pour le mal, j’ai configuré un plugin Pushbullet / Telegram que je mets manuellement sur les services plus critiques. Simplement en activant dans les notifications du service à sa création :

Ici c’est un service de type HTTPS mais qui vérifie également le contenu du site et si un mot clé est bien présent. C’est pratique! Se baser sur un code retour 200 uniquement n’est pas suffisant.

On peut mettre un Heartbeat toutes les 5min, définir un notre d’essai avant d’être en erreur et aussi spécifier un interval plus rapproché Heartbeat Retry Interval en cas d’essai raté.

Une fonction assez simpa est l’utilisation de tag comme vous pouvez le voir sur la liste de gauche :

Page de status

Une fois nos service ajoutés, on peut les organiser par groupes sur une page de status accessible publiquement, avec l’état de nos services :

Cela permet également d’avoir des notes de maintenance ou indiquer un incident :

Simple à configurer et tellement d’avantages!

L’article Uptime-kuma – monitorer clairement ses services est apparu en premier sur Mon linux.

Le DNSsec n’étant pas suffisamment répandu pour ne pas subir une attaque MITM, le mieux actuellement est de sécurisé son trafic jusqu’à un tiers de confiance.

Pour sécuriser encore plus la résolution de nos DNS on peut passer par DoH (dns over https) ou DoT (DNS over TLS). C’est le deuxième qui sera retenu, car il est inutile d’ajouter des couches HTTP. Le DoT est plus natif, un peu comme imaps pour les mails, https pour le web, etc

Les requêtes sortantes peuvent se faire via :

• DNScrypt
• DNS over https DoH
• DNS over TLS DoT

Quel protocole utiliser ? Un article anglais explique bien que le DoT est le choix le plus judicieux

2 choix

• Un container tout fait stateless basé sur unbound
  • container
  • github
• Sa propre configuration Unbound
  • Container unbound avec descriptif
  • Configuration d’exemple pour Unbound utilisé avec DoT

Installation du service DoT

Unbound via l’image qmcgaw/dns permet de générer les fichiers de configuration unbound à partir de varniable d’environement pour une installation rapide et stateless.

Voici la configuration du service à ajouter à celle de l’installation de Pihole vue précédemment.

services:
  dot:
    image: qmcgaw/dns:latest
    container_name: pihole-unbound-DoT
    environment:
      PROVIDERS: 'cloudflare,quad9'
      BLOCK_MALICIOUS: 'on'
      CACHING: 'off'
    networks:
      dnsnet:
        ipv4_address: 10.10.10.34
    restart: unless-stopped

Configurer un relais DNS sécurisé dans Pihole

Après l’installation du container DoT, il faut modifier l’IP du serveur personnalisé.
Aller dans Settings > DNS pour décocher tous les serveurs de gauche et activé un custom avec l’IP de notre container docker unbound-dot :

docker inspect -f '{{ .NetworkSettings.Networks.pihole_dnsnet.IPAddress }}' unbound-dot
10.10.10.34

Attention à bien fixer les IP de vos container cette fois-ci vu que les serveurs DNS ont besoin d’IP et non de nom

Tester si nos DNS sont sécurisés via https://1.1.1.1/help, le résultat qui nous intéresse est « Using DNS over TLS (DoT) » :

Tester la résolution DNS DoT (DNS-over-tls) en ligne de commande. Cela nécessite le paquet knot-dnsutils

kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com mondomain.tld

Passage en revue de l’installation complète avec Pihole

Dans mon exemple, c’est le container pihole qui reçoit les requêtes des clients pour les transférer au container Unbound DoT et de manière sécurisée jusque Cloudflaire. Ils partageront donc un réseau afin de segmenter le tout, plus besoin d’avoir le port de l’host ouvert.
Dans l’exemple le réseau 10.10.10.32/29 nous donne 8 IP dispo dans l’absolut mais :

• 10.10.10.32 est notre network
• 10.10.10.33 étant réservée pour l’host, et faisant gateway pour les containers de ce réseau
• il reste 5 IP dispo de 10.10.10.34 à 10.10.10.38
• 10.10.10.39 est le broadcast

Pour les DNS cela travail essentiellement avec des IP, on fixe donc les IP des containers.
Et on oublie pas la dépendance du service pihole envers notre Unbound pour faire propre.

version: '3.7'

networks:
  dnsnet:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 10.10.10.32/29
  proxy-net:
    external: true

services:

  dot:
    image: qmcgaw/dns:latest
    container_name: pihole-unbound-DoT
    environment:
      PROVIDERS: 'cloudflare,quad9'
      CACHING: 'off'
      BLOCK_MALICIOUS: 'on'
    networks:
      dnsnet:
        ipv4_address: 10.10.10.34
    restart: unless-stopped

  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - '/var/lib/docker/data/pihole/config/etc-pihole/:/etc/pihole/'
      - '/var/lib/docker/data/pihole/config/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    environment:
      TZ: 'Europe/Paris'
      ADMIN_EMAIL: 'YOUR_EMAIL'
      WEBPASSWORD: 'tttttt'
      DNS1: 10.10.10.34
      DNS2: 10.10.10.34
      VIRTUAL_HOST: pihole.domain.tld
    depends_on:
      - dot
    networks:
      proxy-net:
      dnsnet:
          ipv4_address: 10.10.10.35
    restart: unless-stopped

    labels:
      - traefik.enable=true
      - traefik.http.services.pihole.loadbalancer.server.port=80
      - traefik.http.routers.pihole.entrypoints=websecure
      - traefik.http.routers.pihole.tls.certresolver=le
      - "traefik.http.routers.pihole.rule=Host(`pihole.domain.tld`)"

On peut lancer et inspecter les IP des containers via :

docker network inspect pihole_dnsnet

L’article Sécuriser ses DNS avec Pihole et DoT (dns-over-tls) est apparu en premier sur Mon linux.

Il existe aussi quad9 qui block des domaines malicieux gratuitement.

Configuration docker-compose Pihole

Configuration pihole simple

Fichier docker compose de base (sans dhcp) en écoute sur port 2080 en http :

version: '3.7'

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      #- "67:67/udp"
      - "2080:80/tcp"
      #- "2443:443/tcp"
    volumes:
      - '/var/lib/docker/data/pihole/etc-pihole/:/etc/pihole/'
      - '/var/lib/docker/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    environment:
      TZ: 'Europe/Paris'
      ADMIN_EMAIL: 'YOUR_EMAIL'
      WEBPASSWORD: 'TEMP_ADMIN_PASSWORD'
      VIRTUAL_HOST: pihole.domain.tld

    restart: unless-stopped

Après le premier démarrage et configuration on peut changer le mot de passe admin avec cette commande pour ne pas le laisser traîner dans le fichier de configuration : docker exec -it pihole pihole -a -p

Configuration Pihole avec Traefik

Fichier docker avec configuration de traefik devant l’interface web et les dns cloudflare de choisi :

version: '3.7'

networks:
  proxy-net:
    external: true

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - '/var/lib/docker/data/pihole/etc-pihole/:/etc/pihole/'
      - '/var/lib/docker/data/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    environment:
      TZ: 'Europe/Paris'
      ADMIN_EMAIL: 'YOUR_EMAIL'
      WEBPASSWORD: 'tttttt'
      DNS1: '1.1.1.1'
      DNS2: '1.0.0.1'
      VIRTUAL_HOST: 'pihole.domain.tld'

    networks:
      - proxy-net
    restart: unless-stopped

    labels:
      - traefik.http.services.pihole.loadbalancer.server.port=80
      - traefik.http.routers.pihole.entrypoints=websecure
      - traefik.http.routers.pihole.tls.certresolver=le
      - "traefik.http.routers.pihole.rule=Host(`pihole.domain.tld`)"
      - "traefik.http.routers.pihole.middlewares=home-whitelist@file"

Configuration de PiHole via l’interface web

DNS forwarder

Si ce n’est déjà fait via les variables docker, on change les DNS utilisés, car ceux par défaut sont ceux de Google… Pour quelque chose évitant la pub, c’est un peu contradictoire…
Aller dans Settings > onglet DNS
Il est possible de prendre Google, OpenDNS, Level3, Comodo, DNS.WATCH, quad9, cloudflare ou bien des serveurs dns customisés.

Voici une liste des serveurs et leurs qualités, tel que la vie privée :

Pour plus d’info, un bon article décrivant les qualités de chacun de ces fournisseurs de DNS gratuits.

Les DNS customisés sont pratiques si vous voulez chainer avec un bind9 ou powerDNS et beaucoup de dns internes.
Pour une utilisation domestique, tout est prévu dans l’interface pour le faire directement.

résolution dns locaux

C’est une partie qui va remplacer mon serveur bind9 interne, que j’utilisais pour résoudre des services « cloud » maison via leur IP locale quand on est à la maison et l’ip publique quand on est à l’extérieur.

gestion de listes supplémentaires

Il est possible d’ajouter des listes d’hosts à blacklisté autres que la pub, comme les fakenews, réseaux sociaux, porno, etc.
Il est possible de bloquer certaines catégories uniquement pour un certain group d’host.

De base, lorsqu’une url est ajoutée, elle s’applique à tous les clients, qui sont par défaut dans le gorupe « default ».

Une liste des catégories disponibles par la communauté se trouvent sur le github de StevenBlack.

Le site firebog regroupe des listes par catégories dangeureux, publicitaire, tracking

1. J’ajoute donc la liste https://raw.githubusercontent.com/StevenBlack/hosts/master/extensions/fakenews/hosts dans Group Management > Adlists
   

   

2. Ensuite on fait un update manuel pour avoir la nouvelle liste
   

   

3. un test avant/après :
   

   

Gestion des groupes

1. Création d’un groupe « restricted »
   

   

2. On met un client dans ce groupe: en sélectionnant un client connu du serveur dns et en l’associant au groupe « restricted » uniquement. Attention à bien valider
   

   

3. On ajouter la liste gambling et on sélectionne uniquement pour le groupe « restricted », et on ajoute les 2 autres listes au groupe « restricted » également
   

   

4. On fait une mise à jour de Gravity
5. Les clients de base ont une blackliste adware+walware+fakenews et le client « domopi » adware+walware+fakenews+gamebling

Application Android Pi-hole Connect

Une application Android Pi-hole Connect est également disponible afin de gérer facilement une mise en pause du blocage, ajouter un domaine à la whitelist ou actualiser les filtres par exemple.

L’article Pihole pour se passer de publicité et sites malicieux est apparu en premier sur Mon linux.

Installation de certbot

Dans ce cas-ci, il sera installé sur le serveur Apache directement. Suivez d’abord les instructions d’installation selon votre système.

Sous Debian 9, faites directement ceci :

apt-get install certbot python-certbot-apache

Validation d’un seul domaine via let’s encrypt

Pour valider un seul domaine pour un certificat, il faut déjà avoir créé la configuration du site en HTTP. Certbot se chargera de demander le certificat à let’s encrypt et de créer une configuration de site identique en HTTPS, vous n’aurez rien à faire côté Apache. Vous aurez la possibilité de choisir de rediriger les utilisateurs depuis http vers https.

Exécutez ceci et suivez les instructions :

certbot --apache

Pour prendre en compte la modification, rechargez Apache :

service apache2 reload

Par la suite, un renouvellement de certificat pourra se faire via :

certbot renew

Un certificat let’s encrypt n’est valide que 3 mois. Il faut donc le renouveler tous les 3 mois. Heureusement un cron permet de le faire automatiquement, vérifiez que celui-ci est bien présent /etc/cron.d/certbot :

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Validation d’un certificat multi-domaine

Afin de valider un certificat multi-domaine, il faut spécifier ces domaines via des arguments de certbot. Bien évidemment pour le renouvellement il n’y aura rien de spécial à faire, cela suit la même procédure qu’un domaine seul.

Il faut exécuter manuellement:

certbot-auto --apache -d domaineprincipal.tld -d www.domaineprincipal.tld -d ...

Le premier domaine sera utilisé comme domaine principal, tous les autres seront utilisés comme domaines secondaires, appelé « SAN Certificates« . Cela signifie « Subject Alternative Name ».

Notre certificat multi-domaine a été installé directement dans la configuration Apache par Certbot, il suffit d’un reload de la configuration Apache.

L’article Créer un certificat multi-domaine let’s encrypt avec Apache est apparu en premier sur Mon linux.