Et le meilleur ? Ça fonctionne aussi avec le Nunstick 😍 !

Voici un petit RETEX sur mon installation solaire faite par moi même après un an de fonctionnement.

Je vais comparer deux périodes, 2024 et 2025, la première sans panneaux solaires et la deuxième avec. En faisant les calculs préliminaires à mon installation, j'avais fait plusieurs scénarios avec autoconsommation, revente, les deux, panneaux en toiture fait par des professionnels, installation faite par moi avec différentes puissance et les coûts en fonction de la législation (il faut une entreprise RGE si on veut revendre, Consuel si c'est sur le toit ou supérieur à une certaine puissance), aides de l'état si installé par un pro et j'en passe. Il en est ressorti que le plus économique et le plus rentable semblait être une installation en plug and play d'au moins 2kW. Mon objectif est de voir si ce type d'installation ultra basique permet d'avoir quelque chose d'intéressant financièrement sans avoir à faire des travaux trop lourds et compliqués ni d'y passer trop de temps.

Le mode de consommation

Il s'agit d'une installation en autoconsommation de type plug and play au max de ce qui est possible sur le plan légal (3kW max). Ce n'est pas une installation sur un toit et elle n'est donc pas soumise à une validation par le Consuel ni par une déclaration quelconque. Il n'y a donc pas de frais supplémentaires cachés.

Cela implique que si l'installation produit plus que la maison ne consomme, personne ne rachète cette production, elle est renvoyée vers Enedis gratos pour eux et tant pis pour moi. D'un autre coté, je n'ai pas eu besoin de changer mon abonnement pour un autre plus cher, ni quoi que ce soit d'autre.

⚠️ Attention : La sécurité c'est important ⚠️

Même si elle n'a pas été faite par un pro, mon installation est conforme à la réglementation NF C 15-100. Je précise que je n'ai pas de formation en électricité mais que comme pour tout, ce n'est pas très compliqué si on respecte le bon vieil adage : RTFM.

Le contexte

Voici un peu le contexte pré installation, sur l'année 2024.

La maison et son DPE

Il s'agit d'une maison des années 60 d'environ 120 m² sans isolation des murs. C'est du parpaing avec enduit extérieur et plâtre à l’intérieur. Elle à été évaluée à D au DPE à l'époque de la vente. J'ai quand même isolé les combles en décembre 2023 avant la période de test.

La maison est située dans le sud de la France. Donc dans une région bien ensoleillée et où une bonne PAC air/eau permet de se chauffer (même avec une maison pas trop isolée).

Équipements et habitudes

Presque tout est électrique : Four, chauffe eau classique à résistance et pompe à chaleur air/eau pour le chauffage. La clim est assurée en été par 2 pompes à chaleur air/air. J'ai installé une plaque à induction en début 2025. En 2024 j'avais donc en plus de l'électricité consommée une facture de gaz d'environ une dizaine d'euros par mois pour la cuisine.

Je travaille à la maison et je dois donc faire la cuisine tous les midis, maintenir le chauffage la journée et j'ai plusieurs pc allumés pour pouvoir faire le boulot. Avec les enfants c'est aussi une machine à laver par 1 jour et demi + sèche linge qui doivent tourner.

Pour le chauffage, la consigne est programmée pour 19 degrés en journée et 18 la nuit de 23H à 7H.

Consommation de base

Ce qui fait qu'en 2024 j'ai dépensé environ 3700 euros en électricité pour 11 950 kWh consommés.

L'installation solaire

J'ai reçu mes panneaux solaire en fin 2024. L'installation à été mise en service juste avant janvier. J'ai donc un résultat sur une année complète de janvier à décembre 2025. Peu de temps après, j'ai équipé mon tableau électrique d'un module Shelly 3EM et j'ai monté un home assistant sur un vieux raspberry qui m'a permis de mesurer ma consommation électrique et ma production solaire sur l'année. J'ai pris des micros onduleurs avec un firmware de type EZ1 - APsystems qui permettent d'être interrogés par API local. Je suis donc propriétaire de mes données et le système fonctionne encore même en cas de coupure internet.

Le coût de l'installation

Parlons un peu de l'installation.

• Les panneaux x 8 + micro onduleurs x 4 : 1100 euros (livraison comprise).
• Les supports en acier : 280 euros (livraison comprise).
• Le matériel pour raccorder au tableau électrique, comprenant interrupteur différentiel 63A et 2 disjoncteurs divisionnaire + 2 câbles 2.5mm² + 4 prises (2 par câble) + gaines: 250 euros.
• le Shelly 3EM avec 3 pinces 120A (optionnel) : 70 euros.

Soit au total environ 1700 euros TTC.

J'ai mis une bonne journée de travail pour installer les panneaux et faire le raccordement électrique au tableau.

Je pense qu'il est possible de trouver ou de bricoler des supports bien moins chers que ceux que j'ai acheté.

La consommation sur 2025

En 2025 j'ai consommé 9325 kWh sur le réseau électrique. J'ai eu une facture pour la période de 2550 euros environ. Presque tout Janvier est manquant sur mon screenshot car je n'avais pas encore le Shelly en service pour faire les mesures.

J'ai fait quelques ajustements progressivement grâce au monitoring de ma consommation. C'est important car il faut vraiment changer ses habitudes pour optimiser ses dépenses.

Quelques points particuliers

Il est important de noter quelques points qui pourraient avoir une influence sur mes calculs.

Sur les 8 panneaux, un est arrivé cassé et j'ai du attendre début février pour recevoir son remplaçant. J'ai donc fait tout janvier avec seulement 7 panneaux sur les 8.

Le shelly m'a permis de monitorer, en plus de la consommation de base, la consommation spécifique de mon chauffe eau et de ma pompe a chaleur air/eau. En voyant la consommation des différents postes j'ai fait des adaptations au fil du temps qui auraient été plus rentables plus tôt si j'y avait pensé dès le début.

Je me suis ainsi rendu compte que ma PAC tirait trop fort et faisait des cycles de chauffage trop court et trop intenses. J'ai donc regardé sa configuration et j'ai constaté que la loi d'eau n'était pas correctement configurée. J'ai fait la modif en début mars 2025. Sa consommation est depuis bien mieux répartie sur la totalité de la journée et donc d'avantage pendant les heures ou le soleil est là. J'ai donc au moins deux des mois les plus froids avec une PAC qui faisait des pic de consommation sur le réseau aux pires moments, le matin et le soir quand il n'y avait pas de soleil 😫 !

En mi avril seulement j'ai décidé de me servir du shelly pour remplacer le déclenchement de nuit de mon chauffe eau. Je l'ai programmé pour qu'il se déclenche au moment de la surproduction solaire pour absorber le surplus en journée. Ça m'a fait un sacré gain ! Entre 4 et 8 kWh par jour stockés dans le chauffe eau (selon la température de l'eau en entrée et la consommation du jour)! C'est rentable surtout les mois ou le chauffage est éteint, sinon le système ne se déclenche pas et la routine d'allumage nocturne prend le relais. J'aurais donc pu gagner pas mal plus la aussi 😢.

Je n'ai pas tout de suite pris l'habitude de lancer les machines gourmandes en décalé au moment ou il y a du soleil. Il m'est très souvent arrivé de lancer un sèche linge ou une machine à laver au moment de faire la cuisine le midi 🫢.

J'ai isolé par l'intérieur un quart de la maison en décembre 2025. Et pour voir l'impact (et parce que j'en avais marre de me peler !) j'ai augmenté le chauffage à 20 degrés en journée. Malgré cela, j'ai quand même moins consommé sur le réseau, 1450kWh au lieu de 1798kWh. L'isolation m'a permis de chauffer plus pour moins cher. L'augmentation du chauffage n'a donc pas eu d'impact négatif sur la consommation et le test reste donc valide.

Les minimales de températures ont été plus basses en novembre 2025 qu'en 2024, mais légèrement plus hautes en décembre 2025. Par contre très peu d'ensoleillement en décembre chez moi. Les informations sur le site infoclimat sont top pour ajuster les comparaisons en fonction des conditions extérieures.

Mes panneaux sont posés à même le sol et ils ne produisent rien avant 10h le matin et après la fin d'après midi vers 16h quand on est près du solstice d'hivers à cause de divers obstacles (haie et arbres).

La rentabilité et le confort

Bon malgré tous les ajustements un peu tardifs, les points qui pourraient êtres améliorés et l'augmentation de la consommation à cause du froid++ en 2025 j'ai quand même fait une économie de 1270 euros (3700+120 de gaz - 2550) la première année ! Il est donc possible d'amortir ses panneaux (+ son installation électrique dédiée) en moins d'un an et demi en réfléchissant un peu (même en étant un peu lent à la détente sur les habitudes).

Je précise aussi que même avec ces ajustements, j'ai quand même eu des périodes de surproductions, surtout en été. Ceci dit l'avantage en été c'est qu'il fait chaud, j'ai donc pu absorber le surplus en augmentant la climatisation. C'est donc, sans être un gain financier, un sacré gain de confort. Parce que pouvoir se refroidir en pleine canicule gratuitement aux heures les plus chaudes ce n'est pas négligeable.

Conclusion

Les panneaux solaires sont donc particulièrement rentables dans les conditions de mon test et au final très rapidement ( moins de 1.5 an). Il faut cependant garder à l'esprit les quelques points suivants :

• Faire l'installation soi même si possible, c'est ce qui permet de faire une énorme économie. Plus qu'en payant un pro avec des aides de l'état.
• Changer ses habitudes et répartir les consommations sur la journée et non plus la nuit.
• Utiliser son chauffe eau comme batterie c'est une bonne idée.
• Ne pas chercher à être 100% autonome. Les batteries sont trop chères et font exploser les coûts, surtout qu'il faut augmenter la surface de panneaux pour les charger.
• Trouver l'équilibre pour la rentabilité n'est pas toujours simple et ça peut être très différent entre deux foyers.
• L'isolation c'est important !

J'espère en tout cas que ça t'auras donné envie de tenter l'aventure. Si tu veux échanger sur le sujet, n'hésite pas.

Cet article est assez technique et il faut avoir au moins connaissance de comment fonctionnent les réseaux IP et du principe des masques de sous-réseau pour pouvoir tout comprendre. Contrairement aux articles qu'on trouve souvent sur les DMZ, nous allons en créer une en dual stack IPv4/IPv6 avec des outils plus modernes et faciles à maintenir que les classique iptables, bind9, etc.

Une DMZ ?

DMZ veut dire DeMilitarized Zone ou encore Zone démilitarisée en français. A la base, cela consiste à créer une zone dans notre réseau contenant des machines accessibles par internet mais distincte de notre réseau local (domestique ou d'entreprise). Le tout est géré par un pare-feu qui va s'occuper du routage et de la segmentation les différentes zones réseaux en permettant seulement aux flux légitimes de passer d'une zone à l'autre.

Aujourd'hui c'est aussi le seul moyen d'héberger chez soi des sites en IPv6 sans avoir tout son réseau accessible depuis internet. La plupart des fournisseurs d'accès à internet (FAI) ne proposent pas d'interface de configuration du pare-feu en IPv6. C'est tout ouvert ou tout fermé.

Une DMZ ok mais avec quoi ?

Depuis le temps, tu dois commencer à me connaître et tu sais qu'on va la faire avec presque rien. Parce que presque rien c'est bien, comme ça tu choisis ton système d'exploitation et tu peux recycler du vieux materiel. C'est donc pas cher à l'achat et il n'y a pas de licence à payer régulièrement.

Le materiel

En terme de matériel, on utilisera le même type que pour faire un routeur statique décrit dans mon précédent article. En résumé, un vieux PC avec des cartes réseaux additionnelles, un minipc noname vendu sous l’appellation firewall, un banana pi ou encore un odroid h4 avec une carte d'extension réseau si tu veux le top du top en terme de rapport coût/performance/efficience énergétique. C'est comme tu préfères.

Le système d'exploitation

Perso j'aime bien Archlinux mais pour commencer simple on va faire ça sous Debian 13 (Trixie) avec uniquement une configuration du kernel qui va bien et quelques outils. Nous ne verrons pas ici l'installation de Debian 13 car il y a de très bon tutos pour ça sur internet ainsi que le manuel officiel.

Les pré-requis

Pour qu'une dmz fonctionne bien et pour ne pas multiplier les machines, on va installer ou activer sur notre machine pare-feu/routeur les fonctionnalités suivantes :

• Le transfert de paquets d'une interface réseaux à une autre (forwarding).
• Un firewall avec nftables (la base).
• Un service de DHCP pour que les machines en IPv4 puissent acquérir une adresse IPv4 automatiquement.
• Un service de Router Advertisement pour que les machines en IPv6 puisse acquérir une adresse IPv6 automatiquement.
• un service de DNS pour pouvoir accéder à nos autres machines via un nom de domaine local (optionnel).

Après avoir installé Debian 13, installons les paquets nécessaires pour pouvoir commencer (en root).

apt update
apt install systemd-resolved kea nftables
systemctl enable systemd-networkd

Le réseau

Définir le plan d'adressage

Il va falloir choisir quels sous-réseaux vont être utilisés pour les différentes zone. Pour l'IPv4, vu qu'on est sur des adresses privées, on peut donc choisir ce qu'on veut dans la classe C. Pour l'IPv6, il va falloir voir quels sont les réseaux mis à disposition par ton FAI. En général les FAI en donnent 5 ou 6 et ils sont en masque sur 64 bits (ou encore en /64 en notation CIDR).

Pour pouvoir les connaître il faut se connecter à l'interface de gestion de sa box.

Ensuite il va falloir définir les IP des différentes interfaces de la machine qui va être notre routeur/firewall. Tout doit être définit en statique. On ne veut pas que ses IP changent à chaque redémarrage et que ça ne perturbe toute la config.

On partira du principe que j'ai les sous-réseaux IPv6 suivants donnés par mon FAI (comme sur l'image d'exemple ci-dessus). On va les utiliser de la manière suivante :

• 2001:db8:1:10::/64 sera le réseau d'interconnexion entre la box et le routeur, nommé "wan".
• 2001:db8:1:11::/64 sera le réseau nommé "lan" sur lequel on aura les PC standarts de connecté.
• 2001:db8:1:12::/64 sera le réseau nomé "dmz" sur lequel sera raccordé les machines qui devront être accessible depuis internet.

Pour ce tuto je vais choisir les IPs définies ci-dessous.

Pour l'interface wan :

• IPv6 publique : 2001:db8:1:10::1ce:face/64
• IPv6 locale : fe80::1ce:face/64
• IPv4 : 192.168.0.100/24

Pour l'interface lan :

• IPv6 publique : 2001:db8:1:11::1ce:cafe/64
• IPv6 locale : fe80::1ce:cafe/64
• IPv4 : 192.168.1.1/24

Pour l'interface dmz :

• IPv6 publique : 2001:db8:1:12::1ce:beef/64
• IPv6 locale : fe80::1ce:beef/64
• IPv4 : 192.168.2.1/24

Nommage des interfaces réseau

Première étape si on ne veux pas s'emmêler les pinceaux : nommer ses interfaces réseau. Il va falloir activer systemd-networkd et configurer au moins trois interfaces : wan, lan et dmz. Pour cela il va te falloir faire un petit tour sur mon article sur le nommage des interfaces.

Une fois le service systemd-networkd activé, les fichiers .link créés et la machine redémarrée, on va pouvoir passer à la suite.

Configuration des interfaces réseau

Ci dessous, les fichiers des configuration des 3 interfaces à placer dans /etc/systemd/network/.

Pour le fichier 10-wan.network :

[Match]
Name=wan

[Network]
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no
KeepConfiguration=yes

[Route]
# IPv6 du lien local de la box internet
Gateway=fe80::aa:bb:cc:dd
GatewayOnLink=yes

[Route]
# IPv4 de la box internet
Gateway=192.168.0.254
GatewayOnLink=yes

[Address]
Address=192.168.0.100/24

[Address]
Address=2001:db8:1:10::1ce:face/64

[Address]
Address=fe80::1ce:face/64 

Pour le fichier 11-lan.network :

[Match]
Name=lan

[Network]
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no

[Address]
Address=192.168.1.1/24

[Address]
Address=2001:db8:1:11::1ce:cafe/64

[Address]
Address=fe80::1ce:cafe/64 

Pour le fichier 12-dmz.network :

[Match]
Name=dmz

[Network]
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no

[Address]
Address=192.168.2.1/24

[Address]
Address=2001:db8:1:12::1ce:beef/64

[Address]
Address=fe80::1ce:beef/64 

Activation du transfert de paquets

Pour permettre à une machine linux de transférer les paquets d'une interface à l'autre il faut activer l'option de forwarding dans la config du systeme.

Ca se fait via le fichier /etc/sysctl.d/sysctl.conf. Il va falloir dé-commenter (ou ajouter) les lignes suivant:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Le DHCP

Le DHCP est un protocole permettant l'attribution automatique d'une IPv4 à une machine qui se connecte sur un réseau. Pour que ça fonctionne on doit avoir un serveur DHCP qui répond aux sollicitations des machines. On va utiliser Kea DHCP qui est le remplaçant du vénérable ISC DHCP.

On n'utilisera pas le DHCPv6 car il y a encore (trop) de machines qui ne respectent pas ce standard voir même qui, comme les smartphones android, n'implémentent même pas de quoi communiquer avec le serveur.

Le fichier de configuration de Kea /etc/kea/kea-dhcp4.conf est assez verbeux et contient pas mal d'indications. Les sections qui vont nous intéresser sont les suivantes.

Au début du fichier, on déclare sur quelles interfaces on sert le service DHCPv4 :

"Dhcp4": {
    // Add names of your network interfaces to listen on.
    "interfaces-config": {
        // See section 8.2.4 for more details. You probably want to add just
        // interface name (e.g. "eth0" or specific IPv4 address on that
        // interface name (e.g. "eth0/192.0.2.1").
        "interfaces": ["lan", "dmz"] // <--- Modifier ICI 
    
        // Kea DHCPv4 server by default listens using raw sockets. This ensures
        // all packets, including those sent by directly connected clients
        // that don't have IPv4 address yet, are received. However, if your
        // traffic is always relayed, it is often better to use regular
        // UDP sockets. If you want to do that, uncomment this line:
        // "dhcp-socket-type": "udp"
    },  
    
    //....... Reste du fichier
}

Puis on declare la config des sous réseaux lan et dmz dans la section subnet4:

"Dhcp4": {
    //....... Début du fichier

     "subnet4": [
        {
            "id": 1,
           
            "subnet": "192.168.1.0/24",
            "interface": "lan",
            // Plage d'adresse dynamique à alouer.
            "pools": [ { "pool": "192.168.1.2 - 192.168.1.200" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "192.168.1.1"  // <--- ICI mettre l'IP de l'interface lan.
                },
                {
                        "name": "domain-name-servers", // <--- ICI mettre votre DNS. 
                        // Si vous faites la partie optionnelle de ce tuto mettre l'IP de l'interface lan
                        // Sinon mettre l'IP de votre box (ex 192.168.0.254) ou du DNS de votre choix (ex : DNS4EU en 86.54.11.1)
                        "data": "192.168.1.1"
                }

            ],

            // Si vous voulez que certaines machines aient toujours la même ip c'est dans cette section qu'on le déclare
            "reservations": [
                        //exemple avec une machine
                        {
                                "hw-address": "11:22:33:44:55:66", // L'adresse MAC de la machine
                                "ip-address": "192.168.1.201", // L'adresse IP souhaitées. Doit être en dehors de la plage dynamique.
                                "hostname": "PC_bureau"
                        },
                        // exemple avec une seconde machine. N'oubliez pas la virgule entre les deux.
                        {
                                "hw-address": "11:22:33:44:dd:ff",// L'adresse MAC de la machine
                                "ip-address": "192.168.69.202",
                                "hostname": "PC_portable_2"
                        }
            ]
        },
        {
            "id": 2,
            "subnet": "192.168.2.0/24",
            "interface": "dmz",
            // Ici on définit un pool plus restreint. La plupart des IP seront configurées en fixe directement sur les machines.
            "pools": [ { "pool": "192.168.2.2 - 192.168.2.100" } ],

            "option-data": [
                {
                    "name": "routers",
                    "data": "192.168.2.1" // <--- ICI mettre l'IP de l'interface dmz.
                },
                {
                        "name": "domain-name-servers",
                        "data": "192.168.2.1"// <--- ICI mettre votre DNS. 
                        // Si vous faites la partie optionnelle de ce tuto mettre l'IP de l'interface wan
                        // Sinon mettre l'IP de votre box (ex 192.168.0.254) ou du DNS de votre choix (ex : DNS4EU en 86.54.11.1)
                }

            ],

            "reservations": [
                 //exemple avec une machine
                        {
                                "hw-address": "aa:bb:cc:44:55:66", // L'adresse MAC de la machine
                                "ip-address": "192.168.2.101", // L'adresse IP souhaitées. Doit être en dehors de la plage dynamique.
                                "hostname": "server_mail"
                        }
            ]
        }
    ],

    //....... Reste du fichier
}

Puis on n'oublie pas de recharger la config de Kea.

systemctl restart kea-dhcp4-server.service 

Le routing advertisement

C'est un peu le même principe que pour le DCHP. En prefix on met le réseau correspondant à l'interface et en RDNSS l'adress IPv6 du DNS. Si tu fais la partie du tuto optionnelle sur le DNS, il faut mettre l'IP de l'interface elle même. Sinon tu peux utiliser un résolveur public (ex : DNS4EU en 2a13:1001::86:54:11:1)

interface lan_bridge {
   AdvSendAdvert on;
   prefix 2001:db8:1:11::/64
   {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };

   RDNSS 2001:db8:1:11::1ce:cafe {};
};

interface dmz {
   AdvSendAdvert on;
   prefix 2001:db8:1:12::/64
   {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };

   RDNSS 2001:db8:1:12::1ce:beef {};
};

Puis on n'oublie pas de recharger la config.

systemctl reload radvd.service 

Le pare-feu

Là on attaque la partie la plus complexe.

Pour schématiser, le pare-feu applique les règles en fonction du sens des paquets IP :

• Inbound : les paquets qui arrivent par une interface réseau et à destination d'une des IP de cette machine.
• Output : Les paquets emis par cette machine et qui sortent par une interface.
• Forward : les paquetes qui arrive par une interface réseau et qui ne sont pas à destination d'une IP de cette machine. Ils doivent la traverser pour en atteindre une autre.

En plus des fonctionnalités de filtrage il va falloir utiliser du NAT. En effet, notre DMZ est capable de router le trafic vers la Box internet en IPv4 et IPv6, mais les box des FAIs n'ont presque jamais la possibilité de configurer des routes statiques en IPv4. Il faut donc ruser avec du NAT.

Un schéma récapitulatif du comportement de nftable est dispo sur le site officiel :

La config

On va configurer nftable via le fichier /etc/nftables.conf. L'avantage de nftable sur iptables (à part qu'il est son successeur et que iptables est censé ne plus être utilisé hein), c'est qu'on peut définir des variables et des tableaux. C'est donc bien plus facile à maintenir et à comprendre. On verra dans la section suivante comment se servir des compteurs.

Pour l'exemple on va dire qu'on a deux serveurs dans la zone DMZ, un serveur web et un serveur de mail. Les explications sont dans les commentaires du fichier. Le fichier étant un peu larges, tu peux utiliser shift+molette de souris pour déplacer le texte latéralement dans le bloc ci-dessous.

#!/usr/sbin/nft -f

# On nettoie tout avant d’appliquer la config
flush ruleset

# ---- Variables du réseau ----
# Nom de l'interface lan. 
define DEV_LAN = "lan"
# Nom de l'interface wan
define DEV_WAN = "wan"
# Nom de l'interface dmz
define DEV_DMZ = "dmz"

# Declaration des subnets locaux
define NET_DMZ = 192.168.2.0/24
define NET_LAN = 192.168.1.0/24
define NET_IPV6_LAN = 2001:db8:1:11::/64

# Déclaration des IP spécifiques
define INT_WAN_IP = 192.168.0.100

define IPV6_SERVEUR_mail = 2001:db8:1:12::dad:c0de
define IPV4_SERVEUR_mail = 192.168.2.101
define IPV6_SERVEUR_web = 2001:db8:1:12::dad:cafe
define IPV4_SERVEUR_web = 192.168.2.102


table inet global {


	# --------------------- Chaines d'aiguillage -----------------------

	# Point d'entrée principal pour tout le traffic (non source-naté) IPv4 et ipv6 à destination de cette machine
	# Cette règle va aiguiller les décisions vers les blocs (chains) inbound correspondants.
	chain inbound {
		type filter hook input priority 0; policy drop;
		
		# Allow traffic from established and related packets, drop invalid
		ct state vmap { established : accept, related : accept, invalid : drop }

		# allow loopback traffic, anything else jump to chain for further evaluation
		iif vmap { lo : accept, $DEV_WAN : jump inbound_wan, $DEV_DMZ : jump inbound_dmz, $DEV_LAN_BRIDGE : jump inbound_lan}
		
		# On revient ici après les aiguillages (jump) si le paquet n'a pas été accepté. 
		# Et si on arrive ici, le paquet est detruit par la policy drop en debut de bloc.
	}


	# point d'entrée principale pour tout le traffic ipv4 et ipv6 qui est routé au travers de cette machine
	# Cette règle va aiguiller les décisions vers les blocs (chains) forward correspondants.
	chain forward {
		type filter hook forward priority 0; policy drop;

		# accepte de forward depuis la loopback
		iif lo counter accept

		# Allow traffic from established and related packets, drop invalid
		ct state invalid counter drop
		ct state { established, related } counter accept

		# Accepte de transferer le trafic depuis le LAN 
		iif $DEV_LAN_BRIDGE counter accept
		# Le traffic venant du WAN va être évalué.
		iif $DEV_WAN counter jump forward_from_wan
		# Le traffic venant de la DMZ va être évalué.
		iif $DEV_DMZ counter jump forward_from_dmz
		
		# On revient ici après les aiguillages (jump) si le paquet n'a pas été accepté. 
		# Et si on arrive ici, le paquet est detruit par la policy drop en debut de bloc
		# On met un petit compteur au besoin pour voir ce qui est drop.
		counter
	}
	
	
	# Sortie. Pas de filtre. Cette machine est considéré de confiance.
	chain output {
		type filter hook output priority 0;
	}
	# --------------------- fin : Chaines d'aiguillage ----------------

	# --------------------- Chaines de décision -----------------------
	
	# Ici c'est la chaîne de décision pour les paquets qui viennent du WAN (d'internet) à destination de cette machine
	# On bloque tout sauf l'ICMPv6 nécessaire au routage.
	chain inbound_wan {
		
		# On accepte les paquets IPv6 permettant à notre routeur de communiquer avec les autres.
		# On limite cependant a 10 requêtes par seconde pour eviter de se faire flooder la machine 
		# par une machine malveillante depuis internet
		icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,nd-router-advert,mld-listener-query,destination-unreachable,packet-too-big,time-exceeded,parameter-problem} limit rate 10/second accept		

		# Ce qui est bloqué est noté dans un compteur nommé.
		counter name dropped_from_wan
	}

	# Ici c'est la chaîne décision pour les paquets qui viennent du LAN a destination de cette machine
	# Les utilisateurs du LAN sont considérés de confiance. On permet l'accès a cette machine (pour le SSH, le DHCP, 
	# les requêtes DNS si vous faites la partie optionnel du tuto, etc).
	chain inbound_lan {
	
		ip6 saddr $NET_IPV6_LAN accept 
		ip saddr $NET_LAN accept
	}

	# Ici c'est la chaîne de décision pour les paquets qui viennent de la zone DMZ a destination de cette machine
	# Les machines de la DMZ sont considérées comme potentiellement compromises. On permet l'accès 
	# à cette machine pour certains services légitimes, mais on bloque tout le reste.
	chain inbound_dmz {

		# Comme pour la chaine inbound_wan au dessus, on accepte l'ICMPv6 mais en limitant pour éviter le flooding.
		icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,nd-router-advert,mld-listener-query,destination-unreachable,packet-too-big,time-exceeded,parameter-problem} limit rate 10/second counter accept
		# On accepte également le ping ipv4 de manière limité afin de permettre le bon fonctionnement (ex : packet too big) et l'éventuel debugging des serveurs.
		icmp type echo-request limit rate 10/second counter accept
		
		# Communication entrante avec le routeur (cette machine)
		# On accepte le DHCP
		udp dport 67 accept
		# On accepte le DNS
		udp dport 53 accept
		tcp dport 53 accept
		# On accepte le mdns (tu sais le truc avec avahi-daemon et les requêtes en .local)
		udp dport 5353 accept
		
		# Ce qui est bloqué est noté dans un compteur nommé.
		counter name dropped_from_dmz
	}

	# Décisions pour le trafic qui vient du WAN et traverse cette machine
	chain forward_from_wan {
		
		# Comme pour la chaine inbound_wan au dessus, on accepte l'ICMPv6 mais en limitant pour éviter le flooding.
		icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,nd-router-advert,mld-listener-query,destination-unreachable,packet-too-big,time-exceeded,parameter-problem} limit rate 10/second counter accept
		# Pareil pour l'ICMPv4
		icmp type echo-request limit rate 10/second counter accept


		
		# Accepte HTTP/s vers le serveur web.
		ip6 daddr $IPV6_SERVEUR_web tcp dport { http, https} counter accept
		ip daddr $IPV4_SERVEUR_web tcp dport { http, https} counter accept

		# Accepte les Mails vers le serveur mail (SMTP, IMAPS et submission).
		ip6 daddr $IPV6_SERVEUR_mail tcp dport { 25, 587, 993} counter accept
		ip daddr $IPV4_SERVEUR_mail tcp dport { 25, 587, 993} counter accept

		# Ce qui est bloqué est noté dans un compteur nommé.
		counter name dropped_from_wan
	}

	# Décisions pour le trafic qui vient de la zone DMZ et traverse cette machine
	chain forward_from_dmz {
		# Comme pour la chaine inbound_wan au dessus, on accepte l'ICMPv6 mais en limitant pour éviter le flooding.
		icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,nd-router-advert,mld-listener-query,destination-unreachable,packet-too-big,time-exceeded,parameter-problem} limit rate 10/second counter accept
		# Pareil pour l'ICMPv4
		icmp type echo-request limit rate 10/second counter accept

		# Vers le wan
		# Http(s) utilisé pour mise a jours debian.
		# Port 25 utilisé pour envoyer des mail depuis le serveur mail
		oif $DEV_WAN tcp dport {25, http, https} counter accept

		# On accepte les requetes ntp vers le wan
		oif $DEV_WAN tcp dport 123 accept
		oif $DEV_WAN udp dport 123 accept
		
		# Ce qui est bloqué est noté dans un compteur local.
		counter
	}

	# --------------------- fin : Chaines de décision -----------------

		
	# --------------------- Chaines de NAT ----------------------------
	
	# Nat de l'IPv4	en sortie (masquarade)
	chain postrouting {
		type nat hook postrouting priority 100; policy accept;

		# masquerade private IP addresses
		ip saddr $NET_LAN oif $DEV_WAN masquerade
		ip saddr $NET_DMZ oif $DEV_WAN masquerade
		
	}
	
	# Nat de l'IPv4 en entrée. Obligatoire car pas de routage possible sur la box internet
	chain prerouting {
		type nat hook prerouting priority -100;

		iif $DEV_WAN ip daddr $INT_WAN_IP tcp dport { 25, 143, 587, 993} counter dnat ip to $IPV4_SERVEUR_mail
		iif $DEV_WAN ip daddr $INT_WAN_IP tcp dport { http, https} counter dnat ip to $IPV4_SERVEUR_web


	}
	
    # --------------------- fin : Chaines de NAT ----------------------

	# --------------------- Compteurs nommés --------------------------


	counter dropped_from_wan{
		comment "paquets bloqués en entrée wan en direction du parefeu ou du réseau local"
	}

	counter dropped_from_dmz{
		comment "paquets bloqués en entrée dmz en direction du parefeu, du réseau local ou du wan"
	}
	# --------------------- fin : Compteurs nommés --------------------

}

Une fois la configuration écrite, on la recharge :

systemctl reload nftables.service

Les commandes utiles

Nftables permet de consulter les différents compteurs. C'est utile pour comprendre où sont bloqués les paquets en cas d'erreur de configuration. Ça permet aussi de vérifier que les blocages volontaires fonctionnent correctement.

Pour voir les compteurs nommés :

nft list counters

Pour voir les compteurs locaux d'une chaine. Exemple avec la chaine forward_from_wan :

nft list chain inet global forward_from_wan

Il aussi est possible de réinitialiser les compteurs sans redémarrer nftables :

nft reset counters

(Optionnel) le DNS

Cette partie optionnelle permet que toutes les requêtes DNS du LAN et de la DMZ passent par le routeur. Il se chargera ensuite d'envoyer les requêtes vers un résolveur de confiance en TLS, ce qui assurera un minimum de confidentialité.

Avoir un résolveur local permet aussi d'ajouter des noms d'hôte à ses propres machines, ce qui est plutôt pratique pour ne pas taper des IPv6 à rallonge pour se connecter aux serveurs de mail, nas, etc.

Commençons par installer le daemon qui va bien :

apt install unbound

Il suffit ensuite de créer un fichier de configuration de zone dans /etc/unbound/unbound.conf.d/ma_zone.conf

Puis de l'éditer de la manière suivante (les explications sont dans les commentaires) :

## Simple recursive caching DNS
## unbound.conf -- https://DNSwatch.COM
#
server:
	
	# verbosity number, 0 is least verbose. 1 is default.
        verbosity: 1


	# number of threads to create. 1 disables threading.
	# num-threads: 1

	# the amount of memory to use for the RRset cache.
        # plain value in bytes or you can append k, m or G. default is "4Mb".
        rrset-cache-size: 128m

	# the amount of memory to use for the message cache.
        # plain value in bytes or you can append k, m or G. default is "4Mb".
        msg-cache-size: 64m

	# Enforce privacy of these addresses. Strips them away from answers.
        # It may cause DNSSEC validation to additionally mark it as bogus.
        # Protects against 'DNS Rebinding' (uses browser as network proxy).
        # Only 'private-domain' and 'local-data' names are allowed to have
        # these private addresses. No default.
        private-address: 10.0.0.0/8
        private-address: 172.16.0.0/12
        private-address: 192.168.0.0/16
        private-address: 169.254.0.0/16
        private-address: fd00::/8
        private-address: fe80::/10
        private-address: ::ffff:0:0/96
        # ---vvvvvv---  ICI on ajoute les réseaux IPv6 sur lesquels on veut définir des noms d'hôtes. ---vvvvvvvvvv---
        private-address: 2001:db8:1:12::/64 # <---- ICI exemple avec réseau DMZ dans lequel on va déclarer un nas

	# Allow the domain (and its subdomains) to contain private addresses.
        # local-data statements are allowed to contain private addresses too.
        private-domain: "maison" #  <---- ICI le domaine de premier niveau qu'on veut déclarer

	# a number of locally served zones can be configured.
	# 	local-zone: <zone> <type>
	# 	local-data: "<resource record string>"
	# o deny serves local data (if any), else, drops queries.
	# o refuse serves local data (if any), else, replies with error.
	# o static serves local data, else, nxdomain or nodata answer.
	# o transparent gives local data, but resolves normally for other names
	# o redirect serves the zone data for any subdomain in the zone.
	# o nodefault can be used to normally resolve AS112 zones.
	# o typetransparent resolves normally for other types and other names
	# o inform acts like transparent, but logs client IP address
	# o inform_deny drops queries and logs client IP address
	# o inform_redirect redirects queries and logs client IP address
	# o always_transparent, always_refuse, always_nxdomain, always_nodata,
	#   always_deny resolve in that way but ignore local data for
	#   that name
	# o always_null returns 0.0.0.0 or ::0 for any name in the zone.
	# o noview breaks out of that view towards global local-zones.
	#
	# defaults are localhost address, reverse for 127.0.0.1 and ::1
	# and nxdomain for AS112 zones. If you configure one of these zones
	# the default content is omitted, or you can omit it with 'nodefault'.
	#
	# If you configure local-data without specifying local-zone, by
	# default a transparent local-zone is created for the data.
	#
	# You can add locally served data with
	# local-zone: "local." static
	# local-data: "mycomputer.local. IN A 192.0.2.51"
	# local-data: 'mytext.local TXT "content of text record"'
	#

	# note : les CNAMEs ne fonctionnent pas en local-data et local-zone
	local-zone: "maison." static
	local-data: "nas.maison.       IN A    192.168.2.250" #  <---- ICI l'IPv4 de la machine d'exemple
	local-data: "nas.maison.       IN AAAA 2001:db8:1:12::250" #  <---- ICI l'IPv6 de la machine d'exemple


	# specify the interfaces to answer queries from by ip-address.
	# The default is to listen to localhost (127.0.0.1 and ::1).
	# specify 0.0.0.0 and ::0 to bind to all available interfaces.
	# specify every interface[@port] on a new 'interface:' labelled line.
	# The listen interfaces are not changed on reload, only on restart.
	# interface: 192.0.2.153
	interface: 127.0.0.1
	interface: ::1
	interface: 192.168.1.1 # <------- ICI on ajoute l'IPv4 de l'interface LAN
	interface: 2001:db8:1:11::1ce:cafe # <------- ICI on ajoute l'IPv6 de l'interface LAN
	interface: 192.168.2.1 # <------- ICI on ajoute l'IPv4 de l'interface DMZ
	interface: 2001:db8:1:12::1ce:beef # <------- ICI on ajoute l'IPv6 de l'interface DMZ


	# specify the interfaces to send outgoing queries to authoritative
	# server from by ip-address. If none, the default (all) interface
	# is used. Specify every interface on a 'outgoing-interface:' line.
	ip-freebind: yes
	outgoing-interface: 192.168.0.100 # <------- ICI on ajoute l'IPv4 de l'interface WAN
	outgoing-interface: 2001:db8:1:10::1ce:face # <------- ICI on ajoute l'IPv6 de l'interface WAN

	#prefer-ip6: yes

	# control which clients are allowed to make (recursive) queries
	# to this server. Specify classless netblocks with /size and action.
	# By default everything is refused, except for localhost.
	# Choose deny (drop message), refuse (polite error reply),
	# allow (recursive ok), allow_setrd (recursive ok, rd bit is forced on),
	# allow_snoop (recursive and nonrecursive ok)
	# deny_non_local (drop queries unless can be answered from local-data)
	# refuse_non_local (like deny_non_local but polite error reply).
	access-control: 127.0.0.0/8 allow
	access-control: ::1 allow
	access-control: 192.168.1.0/24 allow # <------- ICI on ajoute la zone LAN en IPv4
	access-control: 2001:db8:1:11::::/64 allow # <------- ICI on ajoute la zone LAN en IPv6
	access-control: 192.168.2.0/24 allow # <------- ICI on ajoute la zone DMZ en IPv4
	access-control: 2001:db8:1:12::/64 allow # <------- ICI on ajoute la zone DMZ en IPv6

	# enable to not answer id.server and hostname.bind queries.
        hide-identity: yes

        # enable to not answer version.server and version.bind queries.
        hide-version: yes

	# request upstream over TLS (with plain DNS inside the TLS stream).
	# Default is no.  Can be turned on and off with unbound-control.
	tls-upstream: no

# Forward zones
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of servers. These servers have to handle
# recursion to other nameservers. List zero or more nameservers by hostname
# or by ipaddress. Use an entry with name "." to forward all queries.
# If you enable forward-first, it attempts without the forward if it fails.
forward-zone:
	name: "."
	forward-tls-upstream: yes # <------- ICI on indique que les requêtes sortantes sont en TLS.
	# Résolveurs DNS4EU
	forward-addr: 2a13:1001::86:54:11:1@853 # <------- ICI on ajoute le résolveur de notre choix 
	forward-addr: 2a13:1001::86:54:11:201@853 # <------- ICI on peut en mettre un autre 
	forward-first: no

Une fois la configuration terminée, il faut la recharger.

systemctl reload unbound.service 

Avec cet exemple un "ping nas.maison" fonctionnera depuis une machine connecté dans les zone DMZ et/ou LAN. Et par la magie du domaine privé, le raccourcis "ping nas" devrait fonctionner aussi.

La box internet

A partir d'ici, tu vas pouvoir déplacer tout ce qui est branché à la box vers les bonnes interfaces du routeur. S'il y a plus d'une machine sur une zone il faudra utiliser un Switch.

Selon ton FAI tu vas pouvoir :

• Désactiver la fonction firewall IPv6.
• Activer la fonction DMZ IPV4 en indiquant en destination l'adresse IPv4 de l'interface WAN (optionnel, ici 192.168.0.100).
• Changer les éventuelles règles de NAT qu'il y avait déjà, en direction de l'IPv4 de l'interface WAN (toujours 192.168.0.100 dans ce tuto) si tu n'as pas activé la fonction DMZ.

Conclusion

Nous avons vu comment créer une bulle isolée dans ton réseau qui a accès à internet mais seulement vers les ports autorisés et qui ne peut pas initier de connections vers ton LAN. Cette bulle qu'on a nommé DMZ permet d'y déployer des serveurs qu'on peut rendre accessibles avec les règles appropriées depuis l’extérieur.

Tu peux également ajouter autant de zones du même type tant que tu disposes d'interfaces réseaux supplémentaires. Il peut être intéressant justement de créer une bulle spéciale pour les objets connecté pour lesquels tu ne peux avoir aucune certitude sur ce qu'ils font sur ton réseau.

Nous verrons dans de prochains articles comment ajouter une liste noire d'IP malveillantes dans notre pare-feu et aussi comment intégrer une antenne wifi, dans une des zones, directement sur le routeur.

Pour ceux qui ne connaissent pas, I2P est un réseau superposé et décentralisé qui anonymise le trafic au travers d'une couche dédiée par dessus internet.

J'avais envie de partager quelques sites comme on faisait avant les réseaux sociaux. J'ai donc mis une sections liens. J'ai déja mis quelques sites que j'aime bien et j'en rajouterai au fil de mes decouvertes.

La deuxieme section du site, les notes me permettront d'y mettre des articles moins fouillés et plus liés à des reflexions personnelles ou à des news dont j'ai envie de parler.

Un peu de contexte

Le routage, ça sert à quoi ?

Pour simplifier, le principe du routage c'est d'acheminer les paquets d'un réseau qui est géré par quelqu'un au réseau géré par quelqu'un d'autre. Les réseaux peuvent être connecté directement ou passer par d'autres réseaux intermédiaires. Il faut donc pourvoir aiguiller les paquets à chaque interconnexion vers les bons chemins. Les routeurs sont donc l’équivalent des carrefours avec des panneaux qui indiquent quel chemin prendre pour aller ou on veut (village A, village B, toute directions, etc).

Pourquoi faire un routeur soi-même ?

Comme je l'ai dit dans l'intro, ça n'est pas toujours intéressant d'acheter un vrai routeur du commerce si c'est juste pour simuler plusieurs petits réseaux dans le cas d'un labo. Même principe pour un réseau domestique. Les routeurs avec lesquels on peut faire des configs avancées coûtent cher. Et en plus le choix du hardware est ultra limité.

Avec ce tuto tu pourra utiliser un vieux PC auquel tu auras ajouté une carte réseau à moindre coût, voir même des adaptateurs USB vers ethernet pour environ 10 euros. Tu peux meme utiliser un odroid type H4 avec une carte d’extension 4 ports si vraiment t'aime la performance et l'efficience en terme de consommation électrique. Peut importe du moment que c'est un truc sur lequel tu peux installer une distribution linux et qu'il y a au moins 2 interfaces réseau.

A oui et je précise aussi que ce type de config fonctionne avec des machines virtuelles. Il est donc possible de créer des réseaus complexes dans des truc basiques comme virtualbox. C'est d’ailleurs ce que j'ai fait lors de l’écriture de cet article pour être certain que je ne te raconte pas de dinguerie.

Du routage mais pas trop hardcore

On va voir comment faire du routage statique. Il serait tout à fait possible de faire du routage dynamique avec BGP, de l'OSPF, voir même du RIP pour le fun (les trois sont des protocoles de communication inter-routeurs), mais on va commencer par quelque chose de plus accessible. Je rappelle que le but c'est de faire une routeur domestique, de labo ou de petite entreprise. Il n'y en aura normalement qu'un ou deux max sur un tel réseau.

C'est parti !

Prérequis

C'est mieux si tu connais au moins vaguement le principe des réseaux IP et des sous-réseaux.

Il va falloir activer le service systemd-networkd.service et nommer tes interfaces réseau. Si tu ne sais pas comment faire tu va devoir lire un autre des mes articles (ça me fait aussi un prétexte pour que tu reste un peu plus dans le coin 😁 ).

Comme d'habitude les commande sont à taper en root.

Ce qu'on va faire

Le routeur va permettre aux machines du réseau lan_bureaux de communiquer avec celles du réseau lan_serveurs. Les interfaces Ethernets du routeur seront nommées en fonction du réseau sur lequel chacune d'elle est raccordée. Ça sera plus simple et on évitera les confusions pendant la config (c'est pour ca qu'il faut les nommer correctement !).

Voila le shéma :

Réseau lan_serveurs

Ce réseau aura comme plage d'adresses :

• ipv4 : 192.168.111.0/24
• ipv6 : fd00:ace::/32

L'interface "lan_serveurs" du routeur est connectée à un switch sur lequel sont raccordées les machines de ce réseau. Elle aura comme adresses :

• ipv4 : 192.168.111.1
• ipv6 : fd00:ace::1

Réseau lan_bureaux

Ce réseau aura comme plage d'adresses :

• ipv4 : 192.168.222.0/24
• ipv6 : fd00:b0b::/32

L'interface "lan_bureaux" du routeur est connectée à un switch sur lequel sont raccordées les machines de ce réseau. Elle aura comme adresses :

• ipv4 : 192.168.222.1
• ipv6 : fd00:b0b::1

Les logiciels utilisés

Pas de choses complexes ici avec des interfaces graphiques ou web lourdes, uniquement de la ligne de commande et des programmes basiques disponibles sur presque toutes les distribution linux :

• Systemd-networkd parce que c'est puissant et facile à configurer et déja préinstallé.
• Le kernel linux parce que ça fait le boulot et que de toute façon il est déjà la.

Voila c'est tout. Pas de framework à la noix ou d'interface web qui mange toutes les ressources. La distribution linux que j'utilise pour faire mes routeurs est une Debian 12 mais ça marche aussi avec ce que tu veux du moment que tu peux installer Systemd-networkd.

Ip forwarding

Par défaut le système détruit les paquets qui arrivent et qui ne sont pas à destination de l'adresse IP d'une de ses propres interfaces. On va donc activer la fonction permettant de faire transiter les paquets d'une interface entrante à une autre sortante.

Il va falloir éditer le fichier de configuration utilisateur du kernel /etc/sysctl.d/99-sysctl.conf. On va activer le forwarding de paquet pour l'ipv4 et l'ipv6 en décommentant les lignes suivantes :

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Puis on recharge la config pour prendre en compte les modifications :

sysctl --system

Configuration des interfaces

Réseau lan_serveurs

Créer le fichier /etc/systemd/network/20-lan_serveurs.network qui contiendra :

[Match]
Name=lan_serveurs

[Network]
# Désactivation de l'autoconfig
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no

[Address]
Address=192.168.111.1/24

[Address]
Address=fd00:ace::1/32

Réseau lan_bureaux

Créer le fichier /etc/systemd/network/20-lan_serveurs.network qui contiendra :

[Match]
Name=lan_bureaux

[Network]
# Désactivation de l'autoconfig
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no

[Address]
Address=192.168.222.1/24

[Address]
Address=fd00:b0b::1/32

Activation de la conf

Une fois les fichiers édités, recharger la configuration réseau :

systemctl reload systemd-networkd

Controler la conf avec la commande suivante :

ip address

Ce qui doit donner :

3: lan_serveurs: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:3c:d3:d9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.1/24 brd 192.168.111.255 scope global lan_serveurs
       valid_lft forever preferred_lft forever
    inet6 fd00:ace::1/16 scope global 
       valid_lft forever preferred_lft forever
4: lan_bureaux: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:85:07:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.222.1/24 brd 192.168.222.255 scope global lan_bureaux
       valid_lft forever preferred_lft forever
    inet6 fd00:b0b::1/16 scope global 
       valid_lft forever preferred_lft forever

Routage

Cette partie va être très simple puisque systemd-networkd ajoute automatiquement à la table de routage principale de la machine les réseaux dans lesquels se trouvent les interfaces configurées par son biais.

Il faut juste verifier que les routes sont bien apparues (pour l'ipv4):

ip route

ce qui doit donner :

192.168.111.0/24 dev lan_serveurs proto kernel scope link src 192.168.111.1 
192.168.222.0/24 dev lan_bureaux proto kernel scope link src 192.168.222.1 

Et pour ipv6

ip -6 route

fd00:ace::/32 dev lan_serveurs proto kernel metric 256 pref medium
fd00:b0b::/32 dev lan_bureaux proto kernel metric 256 pref medium

Tests de bon fonctionnement

Verifications

Dans le Réseau lan_bureaux on a une machine configurée comme ceci :

[Match]
Name=enp0s3

[Address]
Address=192.168.222.10/24

[Address]
Address=fd00:b0b::10/32

[Route]
Gateway=fd00:b0b::1

[Route]
Gateway=192.168.222.1

Et dans le réseau lan_serveurs on a un serveur configurée comme ceci :

[Match]
Name=lan

[Address]
Address=192.168.111.50/24

[Address]
Address=fd00:ace::50/32

[Route]
Gateway=92.168.111.1

[Route]
Gateway=fd00:ace::1

Depuis la machine dans le lan_bureaux on peut tester :

ping 192.168.111.50

Ce qui donne :

PING 192.168.111.50 (192.168.111.50) 56(84) bytes of data.
64 bytes from 192.168.111.50: icmp_seq=1 ttl=63 time=0.322 ms
64 bytes from 192.168.111.50: icmp_seq=2 ttl=63 time=0.462 ms

Ca fonctionne en ipv4.

Et en ipv6 :

ping -6 fd00:ace::50

Ce qui donne :

PING fd00:ace::50(fd00:ace::50) 56 data bytes
64 bytes from fd00:ace::50: icmp_seq=1 ttl=63 time=0.510 ms
64 bytes from fd00:ace::50: icmp_seq=2 ttl=63 time=0.593 ms

A ce stade tout est bon.

Explications

L'ajout d'une section [Route] dans un fichier systemd-networkd sans préciser de réseau de Destination est l'équivalent d'un panneau "toutes directions". Cela indique à la machine sur laquelle est configurée cette interface que si elle ne connait pas le réseau de destination, elle envoie par defaut les paquets à l'adresse pointée en gateway. Pour un pc sur réseau domestique (celui que tu as probablement chez toi) il s'agit de l'adresse de la box internet.

Si on voulait router du traffic vers un réseau spécifique précis on pourrrait le faire par exemple comme ceci :

[Match]
Name=enp0s3

[Address]
Address=192.168.222.10/24

[Address]
Address=fd00:b0b::10/32

[Route]
Gateway=fd00:b0b::1

[Route]
Gateway=192.168.222.1

[Route]
# Route vers un VPN monté localement en 10.8.0.1
Gateway=10.8.0.1
Destination=192.168.50.0/24

C'est ce qu'on ferait dans le cas d'un VPN installé sur la machine de bureau, par exemple, qui n'aspirerait que les flux relatifs à un réseau (ici 192.168.50.0/24) qui est à l'autre bout du tunnel VPN.

Conclusion

Et voila, tu as pu voir comment transformer n'importe quelle machine linux en routeur en modifiant seulement quelques fichiers de config déja présents sur le système. Avec quelques règles de pare-feu on pourrait même facilement transformer une machine comme notre routeur en DMZ.

Pour info aussi, avec ce type de config, j'ai fabriqué des switchs et des routeurs qui fonctionnent jusqu'à 100Gbps sur 6 interfaces avec des chassis de serveurs DELL et juste une Debian.

Mais ne me crois pas sur parole, teste par toi même. Et surtout amuse toi bien ;)

Le sujet

Comme tu peux t'en douter il s'agit avant tout d'un livre sur les shellcodes, mais pas uniquement. C'est aussi l'occasion de revoir ou d'approfondir tes connaissances en systèmes (Linux et Windows), en réseau, en assembleur, en language C et en bien d'autres domaines.

Niveau requis

C'est vraiment fait pour tous les niveaux du moment qu'on a quelques notions en ligne de commande windows ou linux et qu'on sait vaguement ce qu'est le système hexadecimal. Connaitre au moins un language de developpement et un peu le réseau est un plus, mais même sans, cela reste très accessible. La decouverte est progressive et les petits programmes que tu vas pouvoir créer vont évoluer tout au long de ta lecture.

Particularité

Contrairement à la pupart des explications et des tutos qu'on trouve en ligne actuellement sur le sujet, les techniques présentées sont à jour et modernes. Les communications réseaux sont etablies en IPv4 ET en IPv6 et les commandes systemes appelées sont fonctionnelles pour des processeurs 32 ET 64 bits, le tout sur des versions de systèmes d'exploitation récents. Les shellcodes créés sont modulables et avec les explications données il est possible de les adapter et de fabriquer facilement de nouvelles fonctionnalités selon ses propres besoins.

Mon avis

Si tu connais les arsouyes et leurs publications, tu ne seras pas dépaysé. La lecture est agréable et toujours emprunte d'une pointe d'humour et de quelques easter-eggs qui, si tu es de nature curieuse, t'emmenerons dans quelques trous de lapin.

J'ai aimé le coté exploration, où on arpenterait une terra icognita avec une vieille carte sur laquelle se trouverait de nombreuses annotations des explorateurs et des exploratrices qui nous auraient précédés. Ici est indiqué comment il a fallu faire de l'ingenieurie inverse sur un systeme propriétaire. Là se trouve une note sur comment on pourrait obfusquer tel appel systeme. Ou encore comment en lisant le putain de manuel, on peut se rendre compte du nombre de choses qu'on peut faire mais qui nous est masqué par des programmes et des libs de plus haut niveau (utilisés pour se simplifier la vie la plupart du temps).

J'ai trouvé amusant de tester chaque ligne de code présents dans le livre et je me suis pris au jeu d'en faire parfois quelques variantes pour vérifer certains comportement du systèmes. Je dois dire, sans spoiler, qu'il y a aussi une technique en particulier qui m'a vraiment surpris. Je me souviens encore m'être dit quelque chose comme ça :

Mais c'est une dinguerie ! Ce n'est pas possible qu'on puisse VRAIMENT faire faire ça au systeme ! Aucunes des libs ni aucuns des langages de programmation que je connais n'authorise ce genre de chose ! ... Ah ben si ça marche 🤯 !

Et pourtant je pensais m'y connaitre franchement pas mal, que ce soit en système, en prog ou en réseau.

Pour conclure, je dirais que tu ne perdras rien à le lire, bien au contraire et je pense que c'est tout à fait le genre de bouquin qui a sa place dans toutes les bibliothèques des entreprises et des institutions qui font de l'informatique leur metier.

SPOILER : Il existe une pièce d'usure qu'il faut changer tous les 7 ans environ et que les spécialistes ne semblent pas vouloir connaître.

Le contexte

Nous avons acheté une maison il y a presque 2 ans maintenant. Il s'agit d'une maison des années 60 qui, à une époque, devait être plutôt chouette. Je dis à une époque car rien n'a été correctement entretenu et TOUT nous a laché dans la première année et demi. Et je parle des choses qui fonctionnaient encore quand nous avons emménagé car la moitié des équipements étaient HS.

Mais je m'égare, car il n'est pas question ici de me plaindre, je savais (plus ou moins) à quoi m'en tenir lorsque nous l'avons acheté. Il est plutôt question de partager le résultat de réparations que j'ai faites et pour lesquelles j'ai trouvé assez peu d'informations, autant sur le net que de la part des professionnels avec qui j'ai pu interagir.

Le problème de base

La maison a été équipée il y a environ 14 ans d'une pompe à chaleur (PAC) air/eau, c'est a dire qu'il y a un gros radiateur avec ventilateur dehors pour collecter la chaleur de l'air extérieur et un module intérieur qui chauffe de l'eau et la fait circuler dans des radiateurs en fonte. C'est comme un gros frigo mais à l'envers, ca chauffe dedans et ça refroidi dehors, le tout grâce à un compresseur et un système de détente de gaz.

En emménageant nous avons testé cet équipement et tout semblait bien se passer :

• Le circulateur faisait bien circuler l'eau dans les radiateurs intérieurs.
• Le compresseur go brrr ! ok ça compressait bien.
• Il faisait froid devant le radiateur externe, chaud dans les radiateurs intérieurs.
• La pression de l'eau semblait constante.

Maiiiiiis une fois l'hiver arrivé, c'est la que ça à commencé à mal se passer. Ça chauffait bien, mais seulement lors de la première chauffe de la journée et après plus du tout, et la pression de l'eau tombait a 0.2~0.3 bar alors qu'elle était à 1 bar avant la chauffe.

Du coup je remets de l'eau pour remonter la pression à 1 bar et ça chauffe de nouveau.

Je vérifie alors TOUS les tuyaux, même ceux dans le vide sanitaire (ce passage pourrait faire l'objet d'une histoire entière avec des os de rats, des araignées inconnues, une invasion d'escargots lubriques et un cadavre de chat momifié D:) pour être sûr qu'il n'y avait pas de fuite dans le circuit et tout était OK.

Seul truc un peu étrange, c'est qu'il semblait y avoir un peu plus d'eau sur le sol au niveau de l’évacuation extérieure. Mais elle était aussi relié en amont au groupe de sécurité du ballon d'eau chaude, ça ne paraissait pas forcement incongru, surtout en hiver.

En observant minutieusement la pression de l'eau pendant la chauffe je vois qu'elle n'est pas constante elle monte tout doucement jusqu’à 3 bar et ensuite elle descend rapidement à 0.3 bar.

On a donc la séquence suivante :

• Eau à 1 bar
• Mise en chauffe ok
• Eau qui monte à 3 bar
• Pression qui diminue d'un coup à moins d'un bar
• Chauffe qui ne marche presque plus.

Je me dis : j'y connais rien en plomberie ni en pompe à chaleur, mais ça ressemble quand même beaucoup à un système de sécurité qui se serait mis en route pour éviter une surpression. Ce qui expliquerait aussi l’afflux d'eau sur le sol à l’extérieur. Mais ce que j'ignorais à ce moment c'est pourquoi la pression augmentait dans mon circuit d'eau chaude alors qu'elle aurait dû être stable.

Première approche (échec) : appeler un professionnel

Et là j'ai eu de tout, des pros très sympa mais pas disponibles avant l'an prochain, des moins sympa qui ne s'occupent pas de PACs qu'ils n'ont pas installé eux même et des carrément azimutés qui m'ont indiqué que au delà de 10 ans il fallait tout changer et qu'il n'ouvriraient même pas le bloc intérieur pour faire un diagnostic.

La dernière catégorie a été la plus représentée, soit 4 sur l’échantillon de 7 professionnels contactés.

Deuxième approche (succès) : se débrouiller

A ce stade, je n'avais pas grand chose à perdre et je me suis dit que ça ne devait pas être si compliqué de tenter un truc moi même. Après tout, je passe mes journées à devoir fabriquer des trucs sur des technos pour lesquelles je n'ai pas forcément toujours des connaissances de base.

Trouver les informations

Bon là, pas de secret, il fallait chercher sur internet si quelqu'un aurait eu une pompe à chaleur qui présentait les mêmes symptômes que la mienne. Et après avoir écumé plein de sites de bricoleurs avec des réponses allant de "change tout" à "fait cette invocation de réparation quantique en araméen" j'ai fini par tomber sur une vidéo d'un type qui décrivait le changement d'un vase d'expansion d'une PAC air/eau. Il indiquait que le changement était nécessaire dans le cadre d'un problème similaire au mien.

C'est la que j'ai eu l'illumination : RTFM.

Je ne sais pas pourquoi je n'ai pas eu l'idée avant, mais je suis allé sur le site du fabriquant et bien qu’étant un ancien modèle j'ai pu retrouver le manuel d'installation et d'utilisation de ma PAC. On y voyait une vue éclatée du bloc intérieur avec les différentes pièces décrites. Celle qui a attiré mon attention a été le fameux vase d'expansion intégré, chargé de réguler la pression lorsque l'eau chauffe et augmente de volume ! Dans le manuel, c’était bien précisé qu'il fallait changer cette pièce tous les 7 ans car la membrane élastique à l’intérieur s'usait et que C'ETAIT NORMAL !

Agir

A partir de la il ne m'a pas été difficile de trouver la référence de la pièce sur le manuel, de la commander sur un site de pièces détachées (pour 270 euros + un joint fibre à 0.10 euros) et de la changer en démontant et en remontant le tout avec un simple jeux de clés plates.

Voila à quoi ressemble le bloc intérieur :

Pour les curieuses et les curieux, j'ai procédé comme ceci :

• Etape 1 : Couper l'alimentation électrique des bloc intérieur et extérieur via les différentiels présent sur votre tableau électrique.

• Etape 2 : démonter les caches du bazar :

• Etape 3 : démonter la plaque de protection latérale :

• Etape 4 : démonter le vieux vase d'expansion. Attention, prévoir quelque chose pour collecter l'eau qui va couler du tuyau démonté. Selon l'installation il peut y avoir plusieurs litres d'eau qui vont s’écouler.

• Etape 5 : Faire toutes les étapes précédentes en sens inverse une fois le nouveau vase installé ( Penser à changer l'ancien joint au niveau du raccord à visser).

• Etape 6 : Rajouter de l'eau dans le circuit de chauffage grâce au robinet dédié jusqu’à 1 bar.

• Etape 7 : Rallumer le tout et savourer.

Mais rager quand même un peu

Apres la remise en fonctionnement me sont venus des sentiments contradictoire qui pourraient se résumer à :

• Haha !! Je viens de m’éviter un remplacement complet ! Je viens d’économiser plus d'une dizaine de milliers d'euros !!!
• Mais en fait, c’était super clair et commun mon problème.... pourquoi les artisans qui pouvaient intervenir m’ont tous proposé un remplacement complet ?
• Ahhhhh ! mais les chacals, il n'y a que deux explications : la nullité ou la fourberie !

Bon en vrai, je ne veux pas mettre tous les artisans dans le même sac, j'imagine que ceux qui étaient bons et qui auraient pu me dépanner honnêtement étaient ceux qui avaient l'agenda rempli jusqu'à l'année d’après... Mais quand même, autant de nuls ou d'escrocs, ca fait quand même chier 😤 !

Car pour information, la PAC vient de passer son second hiver et elle ronronne toujours parfaitement. Le tout avec une pression stable.

Conclusion

Total de l'opération :

• En excluant le temps passé à contacter des artisans, 3 heures de recherches et de lectures techniques, 15 minutes pour commander le vase d'expansion et 45 minutes pour le changer (alors que je n'avais jamais démonté une PAC).
• 270 euros et des poussières au lieu de 13 à 18 milles euros pour une installation de ce type.

Moralité, quand on a besoin d'un professionnel, si on ne s'est pas renseigné un peu avant sur le sujet, on peut quand même bien se faire rouler dans la farine. Que ça soit par incompétence ou par malice le résultat reste le même, on peut perdre beaucoup d'argent.

Ah oui et on ne le dira jamais assez : RTFM !

L'interet

Avec un switch administrable et évolutif on peut imaginer faire pas mal de choses tel que :

• Monitorer du trafic et faire des captures réseau.
• Copier le trafic et le renvoyer vers une interface sur laquelle est branchée une sonde de detection de menace (IDS) type suricata.
• Avoir un point d'arrivée ou de depart d'un tunnel VPN.
• Gérer son propre hardware wifi et installer des cartes externes très performantes.
• Faire un répéteur wifi.
• Faire du filtrage complexe avec nftables (seul moyen actuel de faire du filtrage fin en IPv6 à la maison).
• Gérer son propre DNS intégré.
• Gérer son propre DHCP intégré.
• Activer l'IP forwarding et faire du routage !

Le matériel

Dans ce domaine, le choix est assez vaste. Il est possible d'utiliser un vieux PC de récup auquel on va ajouter une ou deux carte réseaux (1, 2 ou 4 ports Ethernet). Il existe aussi des machines vendues en ligne sous la dénomination mini PC firewall qui sont parfaites pour ça. Ces dernières ont ma préférence car leur refroidissement est passif et avec un SSD elles sont parfaitement silencieuses.

La config

L'idée de base est de permettre le trafic à travers toutes les interfaces réseau de la machine. Une adresse IP sera disponible sur une interface virtuelle afin d'être disponible depuis n'importe laquelle des interfaces physiques.

Schema D'exemple

Ci-dessous, un exemple un peu plus visuel.

L'idée est de pouvoir accéder à l'interface virtuelle de la machine via son ip depuis n'importe quelle interface physique intégrée au bridge.

Interface bridge

C'est l'interface virtuelle qui va nous permettre de lier les interfaces physique ensemble et d'avoir un point pour attribuer une IP.

On va créer un fichier .netdev nommé 05-lan_bridge.netdev contenant :

[NetDev]
Name=lan_bridge
Kind=bridge

# Si boucles dans le réseau, activer le spanning tree 
# en décommentant les lignes ci dessous.
#[BRIDGE]
#STP=yes

Ce fichier permet de creer l'interface.

Ensuite, on va pouvoir lui attribuer la config liée à notre réseau.

Dans cet exemple le switch dispose d'une adresse ip V4 et d'une V6. Il est donc important de définir les gateway pour les deux réseaux.

[Match]
Name=lan_bridge

[Network]
# 3 parametres ci dessous utilisés car on attribue ici une ip fixe
DHCP=no
IPv6AcceptRA=false
LinkLocalAddressing=no
DNS=10.8.0.252 #optionnel

[Address]
Address=10.8.0.1/24

[Address]
Address=fe80::1ce:cafe/64 

[Route]
Gateway=fe80::e69e:12ff:fe0b:653a
GatewayOnLink=yes

[Route]
Gateway=10.8.0.254
GatewayOnLink=yes

Interfaces physiques

Les fichiers .network indiquent à quel bridge ces interfaces sont attachées. L'interface bridge contiendra les paramètres réseaux de niveau 3, donc pas besoin de préciser plus de parametres ici. Pour plus de detail sur la configuration des interfaces et leur nommage tu peux voir mon article à ce sujet.

Exemple : interface 1

Fichier 10-lan_1.link :

[Match]
MACAddress=08:00:27:3c:d3:10

[Link]
Description=Interface vers maison
Name=lan_1

Fichier 10-lan_1.network :

[Match]
Name=lan_1

[Network]
Bridge=lan_bridge

Exemple : interface 2

Fichier 20-lan_2.link :

[Match]
MACAddress=08:00:27:3c:d3:d9

[Link]
Description=Interface vers labo
Name=lan_2

Fichier 20-lan_2.network :

[Match]
Name=lan_2

[Network]
Bridge=lan_bridge

Activation de la config

N'oublie pas de redémarrer le service systemd-networkd.service pour activer la configuration.

Une fois la config rechargée, la machine se comportera comme un switch réseau au niveau du groupe d'interfaces liées par un bridge. De plus, une autre machine connectée à n'importe quelle interfaces physique de notre switch pourra le pinger (ou s'y connecter en SSH, etc) via l'IP unique du Bridge.

Depuis le temps que je m'en sers pour tout un tas de projets, je me suis dit que ça pourrait être utile à d'autres allergiques au SQL 😁. Histone est donc disponible en license libre (GNU AGPLv3) .

Le projet

La génèse

Histone a été developpé à ses débuts en 2008 pour fonctionner sur un serveur NAS DNS-313 de D-Link modifié (CPU 300 MHz, 64Mo de RAM, le tout sous debian 4). Il fait moins de 20 Ko. Il est donc concu pour être trés économe en ressource et peut fonctionner sur des petits systèmes embarqués.

Il est vrai qu'a l'ère du tout centralisé et du cloud, il peut paraitre étonnant de concevoir un système de persistance sous forme de fichiers un peu "à l'ancienne". Il y a deux raison a cela.

La premiere est que j'utilise pour la plupart de mes projet des petites machine, qui bien que performantes, n'ont pas les capacités des gros serveurs dédiés à des taches d'hébergement. Un systeme de gestion de base de données (SGBD) tel que MySQL est trop gourmand pour de telles configurations.

La seconde vient du fait que j'ai pu observé que la plupart du temps, lorqu'un SGBD est installé sur une machine, il ne sert que pour l'unique site web hebergé sur la même machine.

Malgres mes recherches, je n'ai trouvé, à l'époque, aucun systeme de persistances des données suffisamment optimisé pour de telles contraintes. Il existait bien quelques bibliotheques PHP pour manipuler des fichiers XML, mais les temps d'acces explosaient quand il commençait à y avoir plusieurs milliers d'enregistrements.

Les caractéristiques

Histone fonctionne sur quelques principes simples :

• Que du PHP "vanilla", pas de lib externe, ni de module, ni de ces abominations de frameworks.
• Pas de langage de requêtes compliqué, type SQL, tout se fait en orienté objet.
• Les données sont stockées dans des fichiers PHP natif, pour profiter de la gestion du cache du Zend Engine.
• Un champ "id" en clé primaire par table qui est un nombre (Integer) et auto incrémental. Et c'est tout.
• Autant de clé étrangères qu'on veut, déclarées dans un fichier "structure.php" dédié à chaque table.
• Les modules de cache de type APCu sont géré automatiquement, ce qui augmente encore les perfs en lecture.
• Pas de jointure ou de vues. La logique est a implémenter dans le code applicatif.

Pour donner une idée de ses performances, il a servi de base de donnée à plusieurs sites sur ce fameux DNS-313 cité plus haut pendants plusieurs années (avant que le raspberry pi n'existe), dont un des site contenait un forum avec plusieurs milliers de posts. Les temps de réponses ne depassaient jamais les 300 millisecondes.

Envie de tester ? C'est parti !

Télécharger

Voici le lien de téléchargement : Histone

Installation

Décompression

Apres avoir téléchargé le fichier ZIP, décompresse le à la racine de ton site. Tu peux ensuite supprimer le fichier ZIP, il ne sera plus utile. Une fois décompréssé tu dois avoir une arboresence comme celle ci :

• core
  • model
    • Archivable.php
    • Archivist.php
    • Cache_helper.php
    • Ribosome.php
• local
  • data

Création de la base

Pour creer une nouvelle table dans la base de donnée, il suffit simplement de créer un dossier portant le nom voulu dans le dossier data. Dans ce dossier il faut creer un fichier structure.php qui permet de renseigner les éventuelles clé étrangères. Toutes les tables ont automatiquement un champ ID qui est auto incrémental.

Exemple avec cas d'usage : livres et bibliothèques

Je veux créer la table Livre et la table Bibliothèque.

On aura donc :

• core
  • model
    • Archivable.php
    • Archivist.php
    • Cache_helper.php
    • Ribosome.php
• local
  • data
    • Livre
      • strucure.php
    • Bibilotheque
      • structure.php

Un livre appartient à une seule bibliothèque, mais une bibliothèque peut contenir plusieurs livres. On aura donc une relation de 1-n, matérialisée par une clé étrangère dans la table livre que j'appelerais id_bibliotheque.

Une fois n'est pas coutume, modélisé en UML ca nous donne :

Une fois les deux dossier créés, édite les fichiers structures pour configurer les clés étrangères.

Pour Livre :

<?php
	$structure = ['id_bibliotheque'];
?>

Pour Bibliotheque :

<?php
	$structure = [];
?>

Le fichier est obligatoire, même si la table n'a pas de clé étrangères.

Le nom des clé étrangèress est libre. La declaration des clé étrangères de cette facon permet d'optimiser drastiquement les acces aux données.

Utilisation

Importation des ressouces

Tout d'abord il faut importer les differents fichiers :

<?php
include('core/model/Cache_helper.php');
include('core/model/Ribosome.php');
include('core/model/Archivist.php');
include('core/model/Archivable.php');
?>

Ensuite il faut créé un objet d'acces à la base de donnée

<?php

$arch = new Archivist();

?>

Pour finir il faut creer un objet qui va representer une entrée dans la base de donnée. Il est imperatif de préciser le nom de la table lorsque l'on créée un Archivable.

<?php

$livre = new Archivable("Livre");

?>

Maintenant que tu as les bases, passons aux choses serieuses : les requetes dans la base de donnée.

Insertion

On commence par renseigner les attributs à sauvegarder, cela se fait par la méthode set(String nomAttribut, String/int valeurAttribut) de l'objet Archivable. Puis on l'ajout à la base de donnée avec la methode archive(Archivable object) de l'Archiviste.

<?php
$arch = new Archivist();

$livre = new Archivable("Livre");
$livre->set('titre', 'De la brièveté de la vie');
$livre->set('auteur', 'Sénèque');

$id = $arch->archive($livre);

echo('Livre ajoué avec l\'id : '.$id );

// on peut en ajouter un autre en creant un nouveau Archivable de type livre
$livre = new Archivable("Livre");
$livre->set('titre', 'De la vie heureuse');
$livre->set('auteur', 'Sénèque');

$arch->archive($livre);

?>

Simple non ?

Petite précision, les champs/colonnes d'une table sont créé dynamiquement en fonction des objets qui sont ajoutés ou supprimés. Toutes les tables disposent en outre d'un identifiant unique 'id' par enregistrement, mais pas besoin de te tracasser avec sa gestion, il est créé et auto incrémenté lors de l'insertion d'une nouvelle entrée.

Selection

Ce coup ci on va utiliser la methode restore(Archivable $archivable) de l'Archiviste. Cette methode renvoi un tableau contenant les entrées trouvés ou un tableau vide si rien ne correspont.

<?php

//Création d'un objet Archivable qui va permettre de requeter la table Livre
$livres_à_trouver = new Archivable('Livre');

//Je vais récuperer tous les livres dont l'auteur s'appelle exactement Sénèque
$livres_à_trouver->set('auteur', 'Sénèque');

//les objets trouvés sont renvoyé sous forme d'un tableau d'Archivables
$livres_trouvés = $arch->restore($livres_à_trouver);

// on peut verifier qu'on a bien trouvé des livres. Comme ceci par ex:
if(empty($livres_trouvés)){
	//si la liste est vide on l'indique
	echo('aucun livre trouvé.')
	//et on quitte qvant d'executer la boucle qui suit (à replacer par un return dans une fonction).
	exit(0)
}

// on peut afficher les archivables trouvé de cette manière 
foreach($livres_trouvés as $livre){
	echo(' Livre trouvé : '.$livre->get('titre').' écrit par '.$livre->get('auteur').' avec id automatique : '.$livre->get('id'));
}
?>

Pour faire un recherche approximative maintenant, on va plutot utiliser la methode search(Archivable $archivable)

<?php
	
$livres_à_trouver = new Archivable('Livre');
$livres_à_trouver->set('titre', 'la vie');
$livres_trouvés = $arch->search($livres_à_trouver);

// Et on affiche les livres trouvés
foreach($livres_trouvés as $livre){
	echo(' Livre trouvé : '.$livre->get('titre').' écrit par '.$livre->get('auteur'));
}

?>

Modification

Pour faire une modification, on utilise deux objets Arhivable. Le premier sert à faire une recherche, de la même manière que la fonction restore. Le deuxieme contient les attributs à modifier ou à ajouter.

<?php
$livres_à_trouver = new Archivable('Livre');
$livres_à_trouver->set('auteur', 'Sénèque');

$livre_modifié = new Archivable('Livre');
$livre_modifié->set('auteur', 'Lucius Annaeus Seneca');


$arch->update($livres_à_trouver, $livre_modifié);
?>

Suppression

Pour faire une suppression, le principe et le même que pour une selection.

<?php

# pour supprimer tous les livres dont l'auteur est Sénèque
$livres_à_supprimer = new Archivable('Livre');
$livres_à_supprimer->set('auteur', 'Sénèque');

$arch->delete($livres_à_supprimer);


# Pour supprimer Le livre dont l'id est 1
$livre_à_supprimer = new Archivable('Livre');
$livre_à_supprimer->set('id', 1);

$arch->delete($livre_à_supprimer);


?>

Les petits plus Histone

Le tri

Il est possible également de demander à l'archiviste de trier les donnée avant de les afficher:

<?php

# On récupere tous les livres
$livres_à_trouver = new Archivable('Livre');
$liste_livres = $arch->restore($livres_à_trouver);

#  Trie les livre par titre et par ordre alphabetique avec le troisième argument à true
$liste_livres = $arch->sort($liste_livres, 'titre', true);

#  Trie les livre par auteur et par ordre alphabetique inverse avec le troisième argument à false
$liste_livres = $arch->sort($liste_livres, 'auteur', false);

// Et on affiche les livres trouvés et triés
foreach($liste_livres as $livre){
	echo(' Livre trouvé : '.$livre->get('titre').' écrit par '.$livre->get('auteur'));
}

?>

L'implementation de ArrayAccess

Les objets archivable implementent l'interface ArrayAccess. Il est donc possible de les utiliser comme un tableau à une dimension.

<?php

$livre_à_trouver = new Archivable('Livre');
$livre_à_trouver['auteur'] = 'Sénèque';
$livre_à_trouver['titre'] = 'De la vie heureuse';

$liste_livres = $arch->restore($livres_à_trouver);


// Et on affiche les livres trouvés et triés
foreach($liste_livres as $livre){
	echo(' Livre trouvé : '.$livre['titre'].' écrit par '.$livre['auteur']);
}

?>

Le but est d'alleger un peu le code de l'accès aux attributs des objets archivables.

La recherche unique

Il est possible de recuperer seulement le premier Archivable qui correspond à un critère précis. C'est utile lors d'une requete sur un objet qu'on sait être unique.

<?php

$livre_à_trouver = new Archivable('Livre');
$livre_à_trouver['id'] = 1;

$livre_trouvé = $arch->restore_first($livres_à_trouver);

// on peut verifier qu'on a bien trouvé des livres. Comme ceci par ex:
if(empty($livre_trouvé)){
	//si livre_trouvé est vide ou égale à NULL ou à false .
	echo('aucun livre trouvé.')
	//et on quitte qvant d'executer la suite (à replacer par un return dans une fonction)
	exit(0)
}

// ici on s'évite une boucle fastidieuse
echo(' Livre trouvé : '.$livre_trouvé['titre'].' écrit par '.$livre_trouvé['auteur']);

?>

Contribuer

Tu peux contribuer à l'amélioration d'Histone en m'envoyant des patch/diff, il est open source (license AGPLv3).

Prérequis

L'environnement de base

Nous allons voir comment faire ce type de configuration sur un serveur de type Debian 10, 11 ou 12 sans interface graphique.

Sous Debian, le réseau est géré par défaut par le service networking, tu peux le vérifier en tappant la commande :

systemctl status networking.service

Ca doit donner un truc comme ca :

La config par defaut

Le système de nommage par défaut doit donner quelque chose comme ceci avec la commande "ip link" :

On ne va pas se mentir, ici impossible de savoir qu'est ce qui est branché à quoi sans un plan d'adressage noté quelque part.

Par défaut, le daemon systemd-networkd doit être présent mais désactivé.

Pour s'en assurer :

systemctl status systemd-networkd

Ce qui doit te donner :

Nouvelle configuration

On va procéder en deux parties, d'abord activer les daemons nécessaires puis configurer les interfaces. A partir d'ici toutes les commandes sont à tapper en tant que root (ou en prefixant tout avec sudo, c'est comme tu veux).

Activation de systemd-networkd

On va d'abord activer le lancement de systemd-neworkd au démarrage.

systemctl enable systemd-networkd

Ce qui nous donne :

Le daemon se lancera au boot mais il n'est pas encore démarré. Ca tombe bien, ca va te permettre de configurer les interfaces. A ce stade tes interfaces réseaux sont probablement configurées dans /etc/network/interfaces. Pour éviter les conflits de configuration entre les services systemd-networkd et networking, commente tout ce qui concerne tes interfaces, loopback compris.

Une fois terminé, tu devrais avoir un fichier qui ressemble à ceci :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
#auto lo
#iface lo inet loopback

# The primary network interface
#allow-hotplug enp0s3
#iface enp0s3 inet dhcp

Activation de systemd-resolved (optionnel)

Si tu as besoin que ta machine puisse configurer automatiquement l'adresse de son DNS via DHCP (on va y revenir plus bas) il va te falloir activer le daemon systemd-resolved.

apt install systemd-resolved
systemctl enable systemd-resolved

Sans cela seul l'autoconfig de l'IP fonctionnera via DHCP. Il te faudra donc configurer l'adresse du DNS de la machine à la main dans /etc/resov.conf.

Configuration des interfaces

Pour chaque interface il va y avoir 2 fichiers. Un pour définir le nom de l'interface et le deuxieme pour appliquer la config réseau que tu veux. Ces fichiers doivent se placer dans /etc/systemd/network/.

Pour chaque interface, tu vas devoir créer un fichier [nombre inferieur à 99]-[nom que tu veux].link puis un fichier [nombre inferieur à 99]-[nom que tu veux].network.

Exemple avec une interface "wan"

Le fichier de nommage /etc/systemd/network/10-wan.link :

[Match]
MACAddress=08:00:27:1f:0d:02

[Link]
Description=Interface vers box internet
Name=wan

Puis un fichier portant le même nom ".network". Il n'est pas obligatoire que le nom soit le même mais c'est plus cohérent.

Le contenu de /etc/systemd/network/10-wan.network pour une config automatique via DHCP :

[Match]
Name=wan

[Network]
DHCP=yes

DHCP=yes permet de requêter ton DHCP local (en general la box internet si c'est à la maison) afin de récuperer :

• Une IP pour l'interface.
• La gateway du sous réseau.
• L'adresse du DNS associé.

Si tu veux que la partie DNS fonctionne avec ce type de config n'oublie pas d'installer le daemon systemd-resolved.

Exemple avec une interface "lan_serveurs"

Le fichier de nommage /etc/systemd/network/20-lan_serveurs.link :

[Match]
MACAddress=08:00:27:3c:d3:d9

[Link]
Description=Interface vers lan serveurs
Name=lan_serveurs

Le fichier /etc/systemd/network/20-lan_serveurs.network pour une config en IP statique:

[Match]
Name=lan_serveurs

[Network]
Address=10.8.0.15/24
Gateway=10.8.0.254/24 #optionnel
DNS=10.8.0.252 #optionnel

Désactivation du service networking

Maintenant que systemd-networkd.service est configuré, on va désactiver le service networking.service qui ne sert plus a rien.

systemctl disable networking.service

Redémarrage

Pour valider tous les changements, il faut redémarrer la machine :

reboot

Résultat de la manip

Une fois toutes tes interfaces renommées et configurées, un "ip link" doit donner quelque chose comme ceci :

Et voila ! La c'est propre ! Et quand il faudra configurer le pare-feu de la machine, ça sera quand même plus simple 😎.

Aller plus loin

L'exellent article sur le wiki d'archlinux est assez complet et il y a pas mal d'exemples pour des configurations plus complexe.

Dans cet article tu peux aussi voir comment, à partir de cette configuration, il est possible de transformer une machine sous debian équipé de plusieurs interfaces réseau en switch manageable.

Le contexte

Comme tu le sais probablement déjà, lorqu'on expose un truc sur internet, il ne faut pas attendre longtemps avant que des bots ou des idiots tombent sur ta plage d'adresse IP et se mettent à tout scanner pour trouver une faille à exploiter.

On ne va pas parler ici de sécurité mais plutôt de performance. Il y a d'autres outils dédiés de pour faire la sécu.

Cela étant dit, chaque fois qu'un serveur reçoit une requête, il doit l'interpréter, traiter la demande, éventuellement faire de la redirection et réécriture d'URL, chercher les fichiers sur le disque et faire une réponse en bonne et due forme. Tout ceci à pour conséquence de consommer des ressources en CPU, RAM, et temps d'acces disque. Ce n'est pas un problème quand ce sont des visiteuses et visiteurs amicaux mais c'est franchement inutile lorqu'il s'agit d'un blaireau qui cherche à nuire à ta machine.

La méthode

On va simplement configurer nginx pour couper avec dedain toutes les connexions entrantes qui ne sont pas à destination d'un nom de domaine déclaré (ex : https://site-qui-rox.net/). Ca parait basique, mais ca permet de ne pas traiter une proportion assez élevée de requêtes inutiles.

Chose importante, on va partir du principe que personne n'a besoin de venir se connecter sur ton site web via son ip (ex : https://10.10.0.8/). Ceux qui font ça ne méritent pas de lire le contenu de ton site de toute façon.

Précision quand même : si tu veux pouvoir acceder à ton site malgré tout par son IP (sur un LAN sans DNS par exemple), tu peux toujours utiliser ton fichier hosts pour déclarer un nom local.

Configuration de Nginx

Sous debian, il suffit de créer (ou de remplacer) le fichier /etc/nginx/sites-enabled/default.conf et de le configurer comme ceci :

server {
  # On écoute sur les ports HTTP et HTTPS
  # default_server permet d'aspirer les requetes vers des server_name non déclarés
  listen 80 default_server; ## ecoute en ipv4, port 80
  listen [::]:80 default_server; ## ecoute en ipv6, port 80
  listen 443 default_server; ## ecoute en ipv4, port 443 sans ssl
  listen [::]:443 default_server; ## ecoute en ipv6, port 443 sans ssl

  # Rejet des connexions SSL. On n'est pas pas pour servir un café !
  # Ce paramètre est impératif pour pouvoir traiter le port 443
  # dans le même bloc "serveur" que le port 80.
  ssl_reject_handshake on;

  server_name "";
  # Les petits fichiers de logs qui permettent de voir tout ce qui est drop
  access_log /var/log/nginx/default-access.log;
  error_log /var/log/nginx/default-error.log error;

  # Le mot magique. 
  # return 444 indique à nginx de couper la connexion TCP
  # sans autre forme de procès
  return 444;
}

Je donne ci dessous un exemple de config d'un site qui serait accessible via l'adresse https://sitequirox.net et hébergé sur le même serveur :

# Ce bloc sert à rediriger le traffic http vers https
server {
  listen   80;
  listen   [::]:80;

  server_name sitequirox.net;

  access_log /var/log/nginx/sitequirox-access.log;
  error_log /var/log/nginx/sitequirox-error.log error;

  return 301 https://$host$request_uri;
}

# bloc HTTPS
server {
  listen  443 ssl; 
  listen [::]:443 ssl;
	
  server_name sitequirox.net;
  
  access_log /var/log/nginx/sitequirox-access.log;
  error_log /var/log/nginx/sitequirox-error.log error;

  ssl_certificate /etc/letsencrypt/live/sitequirox.net/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sitequirox.net/privkey.pem;

  root /srv/www/sitequirox.net/;
  index index.html;

  location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;	
  }

}

Et n'oublie pas de recharger la conf de nginx après l'avoir modifié.

systemctl reload nginx

Conclusion

Cette méthode permet, de manière très simple, d'économiser les ressources du serveur en ne traitant pas les requêtes inutiles.

Le second avantage avec la configuration que j'ai donné est que tu pourras voir toutes les requêtes non légitimes dans un fichier de log dédié. La récupération des IP malveillantes provenant d'attaques non ciblées en devient simplifiée.

Je vais vous parler de l'utilisation des certificats TLS, qui vont se comporter exactement comme des clés, pour vous identifier dans vos application. Nous allons voir comment mettre en place une authentification de ce type avec un cas pratique en utilisant php et nginx sur un serveur linux débian.

Avant de commencer

Autant le dire tout de suite, cet article va être assez technique et probablement un peu long. Mais ne vous inquiétez pas, en suivant bien pas à pas les différentes sections, vous serez en mesure d'implémenter un système d'authentification par certificats TLS dans n'importe quelle application web basée sur PHP.

Nous n'utiliserons ici que des fonctions disponible en PHP "vanilla". Seules des connaissances basiques en administration système linux et en développement PHP seront donc nécessaires.

Un certificat TLS ? Mais qu'est ce donc ?

Pour simplifier, c'est un fichier qui va permettre de crypter (ou chiffrer) des trucs qui peuvent être aussi bien des connections réseau que des fichiers. Ce fichier peut contenir des informations sur l'entité a qui il appartient, tel qu'un pseudo ou une adresse mail par exemple pour un utilisateur, ou bien un nom de domaine pour un serveur. C'est le cas par exemple des certificats fournis par les sites accessibles en HTTPS.

Pourquoi utiliser un certificat ?

L'intérêt d'un certificat c'est qu'il peut être signé (marqué et validé en quelque sorte) par un autre certificat auquel on fait confiance. Ce qui permettra par la suite que lorsqu'un utilisateur vous présentera son certificat, vous pourrez vérifier s'il a bien été validé par le votre.

En HTTPS il est possible au serveur web de demander au navigateur de lui transmettre le certificat personnel d'un utilisateur pour son domaine.

Ce certificat personnel sera donc à enregistrer dans le navigateur de l'utilisateur et sera transmis automatiquement, à chaque fois qu'il se connectera au serveur correspondant disposant du certificat de confiance.

Nous aurons donc tous les avantages d'une connexion HTTPS, avec en plus :

• Plus besoin de taper de mot de passe pour s'authentifier.

• Plus jamais de perte de session. L'authentification est permanente.

• Plus besoin d'utiliser des sessions PHP coté serveur.

• Plus besoin d'utiliser des cookies pour conserver l'authentification pendant la navigation.

• Et la cerise sur le gâteau : Plusieurs certificats peuvent êtres associés à un même utilisateur.

Le dernier point est important. Un utilisateur pourra disposer de plusieurs certificats. Il pourra donc en avoir un sur son PC portable et un autre, différent, sur sont PC de bureau. Dans le cas ou son PC portable serait volé ou compromis, il suffira dans l'application de désactiver la clé correspondante. L'utilisateur pourra donc continuer a se connecter depuis sont PC de bureau tout en empêchant toute connexion depuis son PC portable devenu non légitime.

Nginx et php

Nginx est le serveur web qui va permettre de servir les pages de votre application/site web. C'est lui qui va recevoir les requêtes du navigateur du client. Il va servir les fichier statiques et rediriger les requêtes à destination des fichiers PHP via le processus php-fpm.

Installation

Installer le tout avec apt de manière classique (en root):

apt update
apt install openssl nginx php-fpm

Nginx : configuration

C'est nginx qui va servir de point d'arrivé pour la connexion TLS. Il va donc être en charge de vérifier si le client connecté en HTTPS utilise un certificat approuvé et connu. Si c'est le cas, il va falloir qu'il transmette les informations contenues dans le certificat à PHP. Si ce n'est pas le cas, il doit pouvoir quand meme servir des pages HTTPS et c'est l'application PHP qui se chargera de présenter un mode "déconnecté".

Pour l'exemple, notre site sera accessible à l'adresse https://mon-site-web.net et ses fichiers seront stockés à l'emplacement /srv/www/mon-site-web.net dans la machine qui l'héberge. Si vous voulez tester ca chez vous, pensez à creer une entrée DNS sur votre domaine ou à renseigner dans votre fichier hosts local (présent sur windows et sur linux) l'ip de votre serveur, afin de pouvoir joindre votre site avec son nom de domaine.

Voici comment configurer NGINX (prenez le temps de lire les commentaires):

# Ce bloc sert à rediriger les connexions entrantes HTTP 
# vers les memes URL mais en HTTPS
server {
        listen 80;
        listen [::]:80;
        server_name mon-site-web.net;
        return 301 https://$host$request_uri;
}

server {

    # SSL configuration
    listen 443 ssl;
    listen [::]:443 ssl;

    # Certificat publique et clé privée du serveur.
    # Necessaire pour etablir des connexion TLS (HTTPS).
    # Peuvent etre générés gratuitement avec let's encrypt par exemple
    ssl_certificate /etc/letsencrypt/live/mon-site-web.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mon-site-web.net/privkey.pem;
    
    # Certificat de confiance de ce serveur. Il va servir a vérifier
    # que le certificat envoyé par le navigateur client est authentique.
    # Il n'y a aucun lien avec le certificat HTTPS ci dessus.
    #
    # L'option ssl_verify_client permet de demander au client s'il a un certificat valide.
    # Le mode "optional" permet au client ne présentant pas de certificat valide, ou n'en possedant
    # pas, de quand meme de naviguer en https sur notre site.
    #
    # Tant qu'on a pas encore générer le certificat de confiance de notre
    # application on laisse les deux lignes en commentaire.
    #ssl_client_certificate /srv/www/mon-site-web.net/local/certs/server.pem;
    #ssl_verify_client optional;

    root /srv/www/mon-site-web.net;
    index index.php;
    server_name mon-site.net;

    # On sert les fichiers statiques
    location / {    
        try_files $uri $uri/ =404;
    }

    #on sert les fichiers dynamiques
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php-fpm.sock;
        # /!\ Variables SSL a déclarer absolument pour que Nginx puisse
        # extraire les information du certificat client et les transmettre
        # à notre application en PHP
        fastcgi_param SSL_CLIENT_VERIFY $ssl_client_verify;
        fastcgi_param SSL_CLIENT_I_DN $ssl_client_i_dn;
        fastcgi_param SSL_CLIENT_S_DN $ssl_client_s_dn;
        fastcgi_param SSL_CLIENT_M_SERIAL $ssl_client_serial;
    }


}

Cette configuration est à placer dans /etc/nginx/site-enabled/mon-site-web.net.

Redemarrer ensuite nginx :

systemctl restart nginx

PHP

Cette partie va etre un peu plus longue. PHP va devoir gérer les points suivants :

• La génération du certificat de confiance maître utilisé par nginx.
• La base des utilisateurs avec leur niveau de droits eventuel.
• La generation des certificats des utilisateurs.
• La correspondance entre les certificats et les utilisateur.
• La signature (marquage comme valide) des certificats des utilisateurs par le certificat de confiance maître.

Génération du certificat de confiance maître.

Cette action est à effectuer une seule fois. Typiquement lors d'un processus d'installation de votre application/site web. Nous allons generer un certificat publique et une clé secrete qui servira à signer (rendre valide) les certificats des utilisateurs.

Afin d'éviter que la clé secrete ne puisse être lue par tout le monde, nous allons l'enregistrer en tant que variable dans un fichier PHP. De cette manière, même si quelqu'un fait une requete sur le fichier de clé secrete, le fichier sera executé en tant que PHP et n'affichera qu'une page blanche. Cette clé secrete sera en plus sécurisée par un password qu'on enregistrera dans un fichier de config.

Un exemple de code permettant de generer le certificat publique, la clé secrete et son password :

<?php
/**
 * Classe gerant l'acces et la sauvegarde de la configuration
*/
class Config{
    
    private static $conf_file = 'local/config.php';
	private $conf;


	public function __construct(){
        if(!file_exists(self::$conf_file)){
            $this->conf = [];
            return;
        }
		include(self::$conf_file);
		$this->conf = $config;
	}

        
	public function get($field){
		if(!isset($this->conf[$field])){
			return false;
		}
		return $this->conf[$field];
		
	}

	public function set($field, $valeur){
		$this->conf[$field] = $valeur;		
	}

	public function save(){
		$contenuFicher = '<?php'.PHP_EOL.'$config = '.var_export($this->conf, true).';'.PHP_EOL.'?>';				
		file_put_contents(self::$conf_file, $contenuFicher, LOCK_EX);	
	}
}

/**
 * Genere un password aléatoire.
 * 
 * @return string Le password généré.
 */
function generate_ca_pass(){
    return $string = substr(str_replace(['+', '/', '='], '', base64_encode(random_bytes(32))), 0, 32); 
}


/**
 * Generation de la paire de clés.
 * 
 * 
 * @param string $CN 		FQDN du site. Ex : mon-site-web.net
 * @param string $OU 		Le nom de l'organisation. Ex : mon-super-site ou super-site
 * @param string $country 	Le code du pays en 2 lettres. Ex : FR
*/
function generate_root_ca_keypair($CN, $OU, $country){
    $subject = array(
        "commonName" => $CN,
        "countryName" =>  $country,
        "organizationalUnitName" => $OU,
        "organizationName" => $CN,
        "stateOrProvinceName" => $OU,
    );

    // Génère le password de la clé privée.
    $ca_password = generate_ca_pass();

    //Sauvegarde la clé dans la config.
    $config = new Config();
    $config->set('cert_pass', $ca_password);
    $config->save();
    

    // Génère une nouvelle de clé privée RSA 2048 bits
    $private_key = openssl_pkey_new(array(
        "private_key_type" => OPENSSL_KEYTYPE_RSA,
        "private_key_bits" => 2048
    ));

    // Génère une requête de signature de certificat
    $csr = openssl_csr_new($subject, $private_key, array('digest_alg' => 'sha256'));

    // Génère un certificat autosigné et l'enregistre dans un fichier
    // on indique 1000 ans de validié ($days=365000), histoire d'avoir un peu de marge ^_^
    $x509 = openssl_csr_sign($csr, null, $private_key, $days=365000, array('digest_alg' => 'sha256'));
    openssl_x509_export_to_file($x509, 'local/certs/server.pem');


    //Prépare la clé sous forme exportable en lui assignant le mot de passe généré.
    $ecc_private= '';
    openssl_pkey_export($private_key, $ecc_private, $ca_password);
    //Ecrit la clé privée dans un fichier
    $contenuFicher = '<?php'.PHP_EOL.'$privkey=\''.$ecc_private.'\''.PHP_EOL.'?>';
    file_put_contents('local/certs/server.key.php', $contenuFicher, LOCK_EX);
}


# ==================== main =========================

#creations des dossiers 
if(!file_exists('local')){
    mkdir('local');
}
if(!file_exists('local/certs')){
    mkdir('local/certs');
}

// Génération du certificat maitre et de sa clé privée.
generate_root_ca_keypair('mon-site-web.net', 'super-site', 'FR');

?>

Collez le code ci dessus dans un fichier (ex : install.php), puis faire une requête vers votre site pour generer la config et certificat racine de confiance. (ex https://mon-site-web.net/install.php).

Prenez garde à n'éxecuter qu'une fois cette requete car à chaque nouvelle execution, un nouveau certificat racine sera générer. Il vous faudra donc supprimer ou trouver un moyen de désactiver ce fichier apres son exacution.

A partir d'ici, vous devez décommenter les lignes concernant ssl_client_certificate et ssl_verify_client dans le fichier de configuration de Nginx. Redemarrer nginx pour prendre en compte la nouvelle configuration et ainsi activer la lecture du certificat client.

Génération du certificat des utilisateur.

Dans cette section nous ne verrons pas comment creer des utilisateurs pour votre site, ni comment utiliser une eventuelle base de donner pour le faire. Le choix vous appartient. Je pars du principe qu'un utilisateur doit disposer d'un identifiant numérique unique dans votre base de données.

Les certificats que nous allons générer pour les utilisateur ne contiendront donc que 2 élément :

• l'ID de l'utilisateur qui devra correspondre à un ID dans votre base de donnée.
• L'ID du certificat lui meme, car un utilisateur doit pouvoir posseder plusieurs certificats. On utilisera le champ x500uid du certificat.
• Optionnel : le nom de l'utilisateur ou son pseudo.

Il vous appartiendra de creer des tables dans votre base de donnée comme ceci :

• Table User : clé primaire id, Pseudo, etc.
• Table Certificat : clé primaire x500uid, clé étrangere id_certificat.

Les certificats des utilisateurs seront générés au format P12. C'est un format pratique qui contient le certificat et la clé privé en un seul fichier, le tout protéger par un mot de passe. Le mot de passe s'utilise seulement la première fois au moment d'importer le certificat dans votre navigateur.

Un exemple de code permettant de generer une certificats pour un utilisateur et lancant un téléchargement pour le récuperer :

<?php
// Attention !!! 
// Coller ou inclure ici le code de la classe Config donnée plus haut dans cet article.
// Ca va permettre de récuperer le password du certificat racine pour pouvoir signer le certificat du client.

function generate_user_cert($username, $password, $user_id, $x500uid, $country, $site_CN, $site_OU){
    $cacert = "file://certs/server.pem";
    include("certs/server.key.php");

    $config = new Config();
    $ca_pass = $config->get('cert_pass');

    $ca_private_key = array($privkey, $ca_pass);
    
    

    $subject = array(
        "commonName" => $username,
        "countryName" => $country,
        "organizationalUnitName" => $site_OU,
        "x500UniqueIdentifier" => $x500uid,
        "organizationName" => $site_CN,
        "stateOrProvinceName" => $site_OU,
    );

    // Génère une nouvelle paire de clés privée (et publique)
    $private_key = openssl_pkey_new(array(
       
        "private_key_type" => OPENSSL_KEYTYPE_RSA,
        "private_key_bits" => 2048
    ));

    $csr = openssl_csr_new($subject, $private_key, array('digest_alg' => 'sha256'));
    // Génère une requête de signature de certificat
    $configArgs = array("x509_extensions" => "v3_req",'digest_alg' => 'sha256',	"basicConstraints" => 'critical,CA:FALSE');
    $serial = $user_id;
    // on indique 1000 ans de validié ($days=365000), histoire d'avoir un peu de marge ^_^
    $x509 = openssl_csr_sign($csr, $cacert, $ca_private_key, $days=365000, $configArgs, $serial);
    
    // Génère un certificat PKCS12 contenant la chaine de validation + le certificat x509 + la clé privée
    $p12 = '';
    openssl_pkcs12_export($x509, $p12,$private_key, $password);

    return $p12;
}

# ==================== main =========================

// A vous de creer un utilisateur dans votre base et de fournir les variables suivantes :
// $username et $user_id

// A vous de creer une entrée certificat valide dans votre base et de fournir la variable $x500uid

// A vous de demander a l'utilisateur quel password il veut pour sont certificat et de fournir la variabre $password.
// Attention : $password ne doit pas etre enregistré dans votre base. 
// Il sera intégré dans le certificat et n'est pas necessaire coté serveur pour l'authentification.


$country = 'FR';
$site_CN = 'mon-site-web.net';
$site_OU = 'super-site' ;

$p12 = generate_user_cert($username, $password, $user_id, $x500uid, $country, $site_CN, $site_OU);

// on indique au navigateur client qu'un fichier p12 va lui etre envoyé.
header('Content-Type: application/pkcs-12');
header('Content-Disposition: attachment; filename="'.$username.'.p12";');
// lancement du telechargement du fichier.
echo($p12);	

?>

Une fois ce code executé vous devriez avoir récupéré un fichier P12 au nom de l'utilisateur.

Vous allez pouvoir l'integrer à votre navigateur qui le présentera automatiquement à chaque requete vers votre site. Pour installer le certificat dans votre navigateur, aller dans Paramètres ➡️ confidentialité/vie privée et sécurité ➡️ Sécurité ➡️ Voir/Afficher les certificats. Cliquer sur le bouton Importer et entrer votre password. Une fois l'importation terminée, fermer et réouvrir votre navigateur.

Identifier les certificat des utilisateur dans votre application web

Voici un exemple de classe permettant de réaliser l'authentification des utilisateurs.

En plus d'indiquer si l'utilisateur est connecté, vous pouver également leur attribuer un niveau de droit d'acces à votre site (utilisateur, moderateur, admin, etc). Cette classe va etre chargée de récuperer les données décodées et transmises par nginx. Elle les comparera ensuite avec les données utilisateur enregistées en base de donnée.

Dans le code qui va suivre, les portions de code relatives aux classes Archivist et Archivable sont des abstractions perso que j'utilise pour acceder à la base de donnée. Je ne donne pas le code de ces classes ici pour eviter d'alourdir cet article déja très long. A vous de remplacer ces classes par votre propre systeme d'interrogation de base de donnée (PDO, mysql, etc).

<?php

class Identificator{
	public static $USER_PERM_ADMIN = 3;
	public static $USER_PERM_MODERATOR = 2;
	public static $USER_PERM_BASE = 1;
	public static $USER_PERM_NOTHING = 0;

	


	public static function get_user_profile(){
		$user = [];

		if(self::is_user_certified()){
			
            // Utilisation de hexdec  : les serials sont en hexadecimal dans les certificat, on doit les reconvertir en decimal. 
			$user_id = hexdec($_SERVER['SSL_CLIENT_M_SERIAL']);
			$dn_list = self::load_user_distinguished_name();
			
			if(!isset($dn_list['x500UniqueIdentifier']) OR $dn_list['x500UniqueIdentifier']==''){
				$user['connected']= false;
			}else{
				$user_found = self::get_user_from_database($user_id);
				
				if($user_found){
					$x500uid_list =  self::get_user_certificate_x500uid_list_from_database($user_id);
					if(in_array($dn_list['x500UniqueIdentifier'], $x500uid_list)){
						$user['connected']= true;
						$user['id']=(int)$user_id ;					
						$user['name']=$dn_list['CN'];
						$user['x500uid']=$dn_list['x500UniqueIdentifier'];
						$user['permission_level']=$user_found->get('permission_level');
					}else{
						$user['connected']= false;
					}
			
				}else{
					$user['connected']= false;
					
				}
			}
		}else{
			$user['connected']= false;
		}

		return $user;
	}

	private static function is_user_certified(){
		

		if(	isset($_SERVER['SSL_CLIENT_VERIFY']) && 
			isset($_SERVER['SSL_CLIENT_M_SERIAL']) &&
			isset($_SERVER['SSL_CLIENT_S_DN']) &&
			$_SERVER['SSL_CLIENT_VERIFY'] == "SUCCESS"
		){
			return true;
		}

		return false;
	}

	private static function load_user_distinguished_name(){
		$DN = $_SERVER['SSL_CLIENT_S_DN'];

		$dn_pairs = explode(',', $DN);
		$dn_list = [];
		foreach ($dn_pairs as $pair){
			$key_value = explode('=', $pair);
			$dn_list[$key_value[0]] = $key_value[1];
		}

		return $dn_list;
	}
	


	/**
	* Return the user found in database.
	*
	* @return Archivable user or false if not found
	*/
	private static function get_user_from_database($user_id){
		$arch = new Archivist();
		$user = new Archivable('User');
		$user->set('id',  (int)$user_id );
		
		$user_found = $arch->restore_first($user);
		
		return $user_found;
		
	}

	private static function get_user_certificate_x500uid_list_from_database($user_id){
		
		$x500uid_list = [];
		$arch = new Archivist();
		$certif_to_find = new Archivable('Certificate');
		$certif_to_find->set('id_user',  (int)$user_id );
		
		$certifs_found = $arch->restore($certif_to_find);

		foreach($certifs_found as $current_certif){
			$x500uid_list[] = $current_certif->get('x500uid');
		}
		
		return $x500uid_list;
	}



}

# ==================== main =========================
/*
A utiliser dans votre application
Les variables associées à $USER sont :
$USER['connected'] : boolean

=> si connected == true
$USER['name'] : String
$USER['id'] : int
$USER['permission_level'] : int

Permission level possible : 
 - Identifier::$USER_PERM_ADMIN = 3;
 - Identifier::$USER_PERM_MODERATOR = 2;
 - Identifier::$USER_PERM_BASE = 1;
 - Identifier::$USER_PERM_NOTHING = 0;
*/
$USER =Identificator::get_user_profile();

?>

Si vous voulez désactiver le certificat d'un utilisateur, il vous suffit simplement de supprimer en base de donnée l'entrée avec le x500uid et l'id utilisateur correspondant. L'avantage de cette méthode c'est que vous n'aurez pas à gerer des liste de certificats révoqués (CRL).

Conclusion

Et voila, vous venez de créer votre propre infrastructure de gestion des clés, certes rustique, mais autonome et automatisée. Il ne vous reste plus qu'a créer les conditionnelles necessaire pour afficher le bon états de votre application en fonction du niveau d'acces de l'utilisateur.

Actix

Actix est un serveur web capable, entre autre, d'interpreter des requetes HTTP et de les traiter. L'idée ici est d'utiliser actix pour effectuer en Rust les traitement qu'on ferait habituellement en PHP.

Actix fonctionne de manière un peu différente de PHP. Au lieu d'utiliser CGI (ou FastCGI), il va simplement ecouter sur un socket réseau.

La documentation officielle explique comment creer un serveur en Rust avec actix en moins de 5 minutes.

Ce qui m'interesse ici c'est d'etre capable de lancer le binaire du serveur grace à des commandes de systemd, du style systemctl restart ma-super-appli-web.service.

Le truc cool, c'est qu'Actix est deja en mesure d'interpreter les interruptions systemes classique.

Placer le binaire au bon endroit

Une fois le binaire compilé avec un bon cargo build --release il va falloir le copier dans un endroit approprié du systeme.

Admettons que votre projet s'appelle, avec beaucoup d'originalité, serveur-rust il vous faudra récuperer le binaire du meme nom se trouvant dans le dossier target/release/ de votre projet.

On le placera par exemple dans /usr/local/sbin/ de manière à ce qu'il se trouve dans le PATH du systeme.

Creer le fichier Unit pour Systemd

C'est presque le plus simple.

Il suffit de creer un fichier dans /etc/systemd/system/ avec le nom de votre service et le contenu tel que decrit ci dessous.

Exemple avec un service qu'on va nommer serveur-rust. On creer le fichier /etc/systemd/system/serveur-rust.service (en root):

[Unit]
Description=Actix-web rust server app launcher
After=network.target

[Service]
Type=simple

# Ici le chemin du binaire. A remplacer par le votre.
ExecStart=/usr/local/sbin/serveur-rust


[Install]
WantedBy=multi-user.target

Il n'y a plus qu'a activer le service (en root):

systemctl enable serveur-rust.service

Grace a cette commande, le serveur sera lancé au démarrage de la machine

Lancer le service

Pour démarrer le service immediatement :

systemctl start serveur-rust.service

Pour vérifier que le service fonctionne :

systemctl status serveur-rust.service

Et la, magie ! ca fonctionne.

Le contexte

Cela fait deja plusieurs années que j'ai configuré mon serveur mail pour n'accepter les connexion IMAP qu'a condition que le client présente un certificat généré par ma PKI. J'utilise thunderbird pour me connecter à ma boite mailn mais un bug persiste depuis quelques temps.

Lorsque thunderbird s'ouvre et se connecte à la boite mail, il demande quel certificat choisir. On peut donc choisir un certificat et selectionner une option "se souvenir de ce choix" afin de ne plus etre importuné par ce popup a l'ouverture. Le problème c'est que meme en cochant cette option, thunderbird redemande à chaque ouverture de sélectionner le bon certificat.

Quand on a pas mal de comptes et des agenda synchronisés, ca devient vite le clicodrome de l'enfer.

La méthode de contournement

Voici donc une methode de contournement simple, mais efficace.

• Aller dans le menu "Tools|options"
• Puis le sous menu "Advanced"
• Selectionner "General"
• Cliquer sur le bouton "Config Editor"
• Chercher la propriété security.default_personal_cert
• La modifier de "Ask every time" en "Select Automatically" (sans les guillements et en respectant la casse)

Et voila, fin des popups en pagaille au démarrage !

Le cas d'usage

Apres avoir implementé un hack de spf-policyd sur mon serveur de mail, j'ai voulu créé un filtre sur mes fichiers de log me permettant de savoir, en un coup d'oeil, quels sont les domaines rejetés par mon serveur.

La méthode usuelle

En general, on va avoir tendance a utiliser grep pour filter les lignes interessantes :

grep NOQUEUE /var/log/mail.log

Ce qui nous donne quelque chose comme ceci :

Nov  7 05:48:02 raspberrypi postfix/smtpd[22342]: NOQUEUE: reject: RCPT from dynrak234g-10-10-67-105.inwitelecom.net[105.67.10.10]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=dynrak234g-195-129-67-105.inwitelecom.net;ip=105.67.10.10;r=<UNKNOWN>; from=<heike.lindner@manos-immobilien.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<dynrak234g-195-129-67-105.inwitelecom.net>
Nov  7 07:59:24 raspberrypi postfix/smtpd[22972]: NOQUEUE: reject: RCPT from unknown[186.83.41.2]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=dynamic-ip-18683412.cable.net.co;ip=186.83.41.2;r=<UNKNOWN>; from=<riskyesg@paraisodedonquijote.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<dynamic-ip-18683412.cable.net.co>
Nov  7 08:24:35 raspberrypi postfix/smtpd[23097]: NOQUEUE: reject: RCPT from unknown[45.64.236.77]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=node-45-64-236-77.alliancebroadband.in;ip=45.64.236.77;r=<UNKNOWN>; from=<dgyks@sickel.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<node-45-64-236-77.alliancebroadband.in>
Nov  7 08:57:55 raspberrypi postfix/smtpd[23411]: NOQUEUE: reject: RCPT from unknown[176.216.115.26]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[176.216.115.26];ip=176.216.115.26;r=<UNKNOWN>; from=<jose.miguel.covelo.perez@inega.es> to=<moi@mondomaine.fr> proto=ESMTP helo=<[176.216.115.26]>
Nov  7 09:29:19 raspberrypi postfix/smtpd[23601]: NOQUEUE: reject: RCPT from unknown[185.223.216.254]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[185.223.216.254];ip=185.223.216.254;r=<UNKNOWN>; from=<nishimura@jn-design.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<[185.223.216.254]>
Nov  7 10:01:55 raspberrypi postfix/smtpd[23714]: NOQUEUE: reject: RCPT from unknown[61.9.108.122]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[61.9.108.122];ip=61.9.108.122;r=<UNKNOWN>; from=<robin@fuchs5.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<[61.9.108.122]>
Nov  7 10:57:46 raspberrypi postfix/smtpd[24007]: NOQUEUE: reject: RCPT from unknown[59.91.247.194]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[59.91.247.194];ip=59.91.247.194;r=<UNKNOWN>; from=<lukasz@pakunova.pl> to=<moi@mondomaine.fr> proto=ESMTP helo=<[59.91.247.194]>
Nov  7 11:32:26 raspberrypi postfix/smtpd[24233]: NOQUEUE: reject: RCPT from unknown[197.3.10.37]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[197.3.10.37];ip=197.3.10.37;r=<UNKNOWN>; from=<annadias@carbotrade-spa.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<[197.3.10.37]>
Nov  7 12:29:09 raspberrypi postfix/smtpd[24500]: NOQUEUE: reject: RCPT from unknown[182.186.12.201]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[182.186.12.201];ip=182.186.12.201;r=<UNKNOWN>; from=<eli@ifcship.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<[182.186.12.201]>
Nov  7 13:15:28 raspberrypi postfix/smtpd[24844]: NOQUEUE: reject: RCPT from unknown[190.244.85.167]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=167-85-244-190.fibertel.com.ar;ip=190.244.85.167;r=<UNKNOWN>; from=<ricerx@punkass.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<167-85-244-190.fibertel.com.ar>
Nov  7 13:49:11 raspberrypi postfix/smtpd[24979]: NOQUEUE: reject: RCPT from adsl-73.37.6.210.tellas.gr[37.6.210.73]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=adsl-73.37.6.210.tellas.gr;ip=37.6.210.73;r=<UNKNOWN>; from=<lyxbi@excite.fr> to=<moi@mondomaine.fr> proto=ESMTP helo=<adsl-73.37.6.210.tellas.gr>
Nov  7 14:17:05 raspberrypi postfix/smtpd[25090]: NOQUEUE: reject: RCPT from unknown[154.160.11.112]: 550 5.7.23 <moi@mondomaine.fr>: Recipient address rejected: Votre message est en etat "rejected" car la configuration SPF (Sender Policy Framework) de votre serveur mail est incorrecte. Votre message est donc considere comme un SPAM. Details technique : Message rejected due to: no SPF record. Please see http://www.open-spf.org/Why?s=helo;id=[154.160.11.112];ip=154.160.11.112;r=<UNKNOWN>; from=<prenault@lenko.com> to=<moi@mondomaine.fr> proto=ESMTP helo=<[154.160.11.112]>
etc...

Le résultat est pertinent, mais sa lecture est désagréable.
C'est la que sed intervient.

Faire du menage

On va utiliser sed en mode substitution et avec la fonction de capture.

La syntaxe de base de la substitution est la suivante :

sed 's/phrase a chercher/phrase de remplacement/'

La phrase a chercher peut etre une expression regulière, aussi appelée regex.

La capture permet de récuperer une partie de la phrase a chercher. Il est possible d'afficher le résultat de la capture dans la phrase de remplacement avec la notation \<numéro de la capture>.
Ex : \1 ou \2

la capture s'effectue avec les parenthèses ( et ). Il faut cependant les echapper avec le symbole "\" pour indiquer à sed qu'on veut faire une capture et non chercher les caracteres "(" et ")".

Ex :

sed 's/expression \(mot\) reste de l expression/capturé : \1/'

Affichera :

capturé : mot

T'en a trop pris gros !

Le probleme c'est que les regex de sed sont gloutonnes. Sed ne reconnait pas la notation +? ou *?.

Un exemple avec le fichier de log précédent. On souhaite extraire la valeur "annadias@carbotrade-spa.com" contenu dans les chevrons de "from=<annadias@carbotrade-spa.com>"

La commande :

grep  NOQUEUE /var/log/mail.log | sed 's/.*from=<\(.*\)>.*/\1/'

Donne comme résultat :

annadias@carbotrade-spa.com> to=<moi@mondomaine.fr

Le soucis vient du fait que <.*> prend tous les caractères jusqu'au dernier ">" rencontré, même si d'autres se trouvent sur le chemin.

La négation et la solution

L'astuce est donc d'utiliser la négation du caractere délimiteur pour etre certain de s'arreter au premier rencontré.

Ex :

[^>]

Signifie : n'importe quel caractère qui n'est pas ">". On va donc pouvoir l'utiliser à la place du "." de la manière suivante :

[^>]*

L'expression a utiliser est donc la suivante :

grep  NOQUEUE /var/log/mail.log | sed 's/.*from=<\([^>]*\)>.*/\1/'

Qui nous donnera comme résultat :

heike.lindner@manos-immobilien.com
riskyesg@paraisodedonquijote.com
dgyks@sickel.com
jose.miguel.covelo.perez@inega.es
nishimura@jn-design.com
robin@fuchs5.com
lukasz@pakunova.pl
annadias@carbotrade-spa.com
eli@ifcship.com
ricerx@punkass.com
lyxbi@excite.fr
prenault@lenko.com

Bonus : un peu plus de détail

En reprenant cette expression et en ajoutant une deuxieme capture, on peut egalement récupérer la date :

grep  NOQUEUE /var/log/mail.log | sed 's/\(.*\)raspberrypi.*from=<\([^>]*\)>.*/\1: \2/'

Résultat :

Nov  7 05:48:02 : heike.lindner@manos-immobilien.com
Nov  7 07:59:24 : riskyesg@paraisodedonquijote.com
Nov  7 08:24:35 : dgyks@sickel.com
Nov  7 08:57:55 : jose.miguel.covelo.perez@inega.es
Nov  7 09:29:19 : nishimura@jn-design.com
Nov  7 10:01:55 : robin@fuchs5.com
Nov  7 10:57:46 : lukasz@pakunova.pl
Nov  7 11:32:26 : annadias@carbotrade-spa.com
Nov  7 12:29:09 : eli@ifcship.com
Nov  7 13:15:28 : ricerx@punkass.com
Nov  7 13:49:11 : lyxbi@excite.fr
Nov  7 14:17:05 : prenault@lenko.com

En version hardcore avec mise en forme avec la commande column :

grep NOQUEUE /var/log/mail.log | sed 's/\(.*\)raspberrypi.*from=<\([^>]*\)>.*to=<\([^>]*\)>.*helo=<\([^>]*\)>.*/\1#\2#\4#\3/' | column -t -s '#'

Ce qui va afficher les données de la manière suivant :

date expediteur serveur_emetteur destinataire

Grâce à cette ligne de commande, je peux avoir un rapport de tous les domaines pourris qui m'envoient des mail.
Le cas échéant, je peux alors ajouter une exception dans mon filtrage SPF pour laisser passer un domaine mal configuré mais avec lequel j'ai besoin de communiquer par mail.

Le contexte

Configurer un systeme anti-spam sous postfix est une vrai misère. Même s'il existe des tres bons tutos, ils impliquent tous de nombreuses étapes de configurations complexes. De plus, il est souvent nécessaire d'utiliser des services tiers pour qualifier le niveau de confiance du serveur émetteur.

La methode usuelle

L'idée est de se concentrer sur le SPF. Je pars du principe que si quelqu'un administre un serveur de mail il DOIT avoir correctement configuré au moins le champ SPF du DNS lié à son domaine. C'est ultra basique et indispensable pour envoyer des mail vers des adresses gmail ou outlook.

La verification du SPF consiste à dire à votre serveur mail que lorsqu'il reçoit un mail, il doit verifier si l'IP du serveur émetteur correspond à l'IP du serveur officiellement déclaré de ce domaine.

Cette vérification peut être effectuée par un utilitaire nommé spf-policyd. Le problème c'est que cet utilitaire fonctionne uniquement si le domaine indiqué comme etant celui de l'émetteur déclare effectivement un champ SPF dans son DNS. Dans le cas ou rien ne serait déclaré, spf-policyd laisse passer le mail. Un peu embettant non ?

Du coup il est normalement necessaire de coupler spf-policyd avec DKIM, DMARC et spamassasin pour etre certain de couvrir tous les cas possibles.

Le hack

L'idée simple est de modifier spf-policyd pour qu'il rejette les mails si le SPF de l'emetteur n'existe pas (résultat "None"). La fonction de base, qui rejette le mail si le SPF ne correspond pas (résultat "Fail") continuera de fonctionner normalement. On va simplement rendre spf-policyd un peut plus aggressif.

Sous Débian 10 et ubuntu 20.04, apres avoir installé et configuré le paquet postfix-policyd-spf-python, il faut éditer le fichier /usr/lib/python3/dist-packages/spf_engine/__init__.py

A la ligne 159, sous le bloc suivant :

        if mfrom_policy == 'SPF_Not_Pass':
            try:
                unused_results.remove('Fail')
                actions['reject'].append('Fail')
                unused_results.remove('Softfail')
                actions['reject'].append('Softfail')
                unused_results.remove('Neutral')
                actions['reject'].append('Neutral')
            except:
                if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')

Ajouter ces lignes suivantes apres "exept :, if debug...":

        # Hack de selenith
        elif mfrom_policy == 'Cerbere':
            try:
                unused_results.remove('Fail')
                actions['reject'].append('Fail')
                unused_results.remove('Softfail')
                actions['reject'].append('Softfail')
                unused_results.remove('None')
                actions['reject'].append('None')
            except:
                if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')

La section devrait donc ressembler à ceci :

 if scope == 'mfrom':
        mfrom_policy = configData.get('Mail_From_reject')
        if "@" in sender:
            sender_domain = sender.split('@', 1)[1]
        else:
            sender_domain = ''
        if spf.domainmatch(reject_domain_list, sender_domain):
            mfrom_policy = 'SPF_Not_Pass'
            local['local_mfrom'] = True
        if mfrom_policy == 'SPF_Not_Pass':
            try:
                unused_results.remove('Fail')
                actions['reject'].append('Fail')
                unused_results.remove('Softfail')
                actions['reject'].append('Softfail')
                unused_results.remove('Neutral')
                actions['reject'].append('Neutral')
            except:
                if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')
        # Hack de selenith
        elif mfrom_policy == 'Cerbere':
            try:
                unused_results.remove('Fail')
                actions['reject'].append('Fail')
                unused_results.remove('Softfail')
                actions['reject'].append('Softfail')
                unused_results.remove('None')
                actions['reject'].append('None')
            except:
                if debugLevel >= 2: syslog.syslog('Configuration File parsing error: Mail_From_reject')
        elif mfrom_policy == 'Softfail':
            try:
                unused_results.remove('Fail')

Avec ce petit patch, il va être necessaire de mettre en liste blanche les domaines des serveurs mail émetteurs qu'on peut considérer comme sûrs, mais dont les champs SPF sont mal ou non configurés.

Pour cela on va éditer le fichier de config /etc/postfix-policyd-spf-python/policyd-spf.conf

Ajouter en fin de fichier les lignes suivantes :

# Domaines des adresses emails emetteurs autorisés (mfrom) 
# Valide seulement si le SPF du domaine est configuré. Si SPF : None => utiliser HELO_Whitelist
Domain_Whitelist = freetelecom.fr,linuxfr.org,outlook.com,sfr.fr,orange.fr,google.com
# Domaines des serveurs emetteurs autorisé (HELO)
HELO_Whitelist =   free.fr,freetelecom.fr,amazonses.com,gouv.fr,outlook.com,sfr.fr,orange.fr,google.com,linkedin.com

Et pour finir on active notre patch en modifiant la valeur Mail_From_reject comme ceci :

# Mail_From_reject = Fail
Mail_From_reject = Cerbere

En ayant appliqué le patch dans la section qu'on a nommé "Cerbere", on peut l'activer ou le désactiver à la volée en changeant la valeur de Mail_From_reject de Fail à Cerbere.

J'ai mis les principaux domaines avec lesquels j'ai déja rencontrés des soucis.

A vous de compléter ou de modifier avec les domaines que vous trouvez pertinent et dont les champs SPF sont mal configurés (oui c'est toi que je regarde, le site des impots).

Aller plus loin

Une technique avec de la regexp savoureuse pour surveiller les domaines bloqués par notre spf-policyd cerbère sous stéroides.

Le point de départ : les commentaires

En voulant retaper un peu l'aspect graphique de mon site, je me suis fait la reflexion suivante : Il n'y a quasiment aucun commentaire sous mes articles. C'etait pourtant la raison principale pour laquelle j'avais choisi de maintenir un site dynamique. Pour offrir une tribune aux visiteurs et ainsi permettre critique (constructive) et échanges autour des choses que je partage. La raison de cette absence de commentaire est plutot simple, c'est dû à la centralisation des communication sur des plates formes dédiées.

S'enfermer pour partager

Lorsqu'on veut partage une publication à des gens qu'on sait etre intéréssés pas le sujet, on a assez peu d'options.

La première, décentralisée, est aussi la moins pratique pour discuter à plusieurs. Il s'agit du bon vieux mail. C'est un support qui est parfait pour un dialogue entre deux personnes. Mais dès qu'on commence à augmenter le nombres de participants, ca devient vite fouilli. Sans compter qu'on a pas forcement envie d'avoir son adresse mail partagée, de maniere aléatoire avec 150 personnes, des qu'on veut faire un simple commentaire publique.

La deuxieme, décentralisée elle aussi, est le Flux Atom/RSS. Mais il ne permet en aucun cas le dialogue.

La troisième, centralisée, mais surtout la solution la plus utilisée, est le partage sur les réseaux sociaux. Pratique, rapide, non intrusif, ça parait être la solution idéale. Mais il n'en est rien. Les discutions se font alors sous les posts de partage créés dans les réseaux sociaux, à l'endroit ou le lecteur est déja présent et connecté. Et on ne peut pas le blamer, cela lui demande moins d'energie et de temps que d'aller sur le site d'origine, de taper son commentaire, un pseudo, ainsi que de valider un captcha à la con sans lequel ton site se fait spammer par des bots de script kiddies. Le fossé se creuse d'autant plus s'il faut indiquer des infos supplémentaires, tel qu'une adresse mail, ou pire, devoir créer un compte.

Et c'est comme ça qu'on se retrouve avec un site usine à gaz permettant d'avoir des sections commentaires. Vides.

La dure réalité

Partant de ce constat, cela vaut il la peine de maintenir un site dynamique avec toute la gestion que ca implique derriere : La mise à jour du CMS lui même, des modules CGI (php, python ou que sais-je), de la base de donnée, etc. Sans compter que tous ces services augmentent la surface d'attaque et donc la vulnérabilité votre serveur, qui ne manque pas de se faire scanner à longueur de journée.

Apres avoir passé des années à essayer de sensibiliser mon entourage aux dangers des services centralisés collecteurs de données, ainsi qu'aux vertus d'un internet décentralisé et fédéré, j'ai pu constaté avec bonheur que tout le monde s'en fout. Ou en tout cas, que meme lorsque le sujet eveil un interet, les alternatives sont toujours moins sexy qu'un beau service gratuit, avec tout plein de fonctionnalité chatoyantes en échange de seulement toutes vos données. Et franchement, meme chez les connaisseurs, peu ont envi de s'embeter la vie à monter sa propre instance mastodon, son blog perso auto hebergé, son serveur de mail et son serveur XMPP. Et c'est normal. Cela demande du temps et des connaissances que tout le monde n'a pas.

La solution

J'en suis donc arriver à cette conclusion. Un site pour blogguer oui, mais dynamique, aucun interet. De plus, il existe aujourd'hui des tonnes de générateurs de sites statiques bien fichus et open source. La plupart proposent même deja une palanquée de templates prets à l'emploi. Pour ma part, celui qui m'a le plus séduit est Zola. On maitrise tout de A à Z, la génération du site est ultra rapide et la création d'articles est super intuitive, à partir de pages écrites en markdown.

Et pour les commentaires ? C'est simple : une expression régulière dans postfix. Il est possible de rediriger une infinité d'adresses mail vers une seule boite. Ca permet de créer des liens de commentaires sous chaque article. Un commentaire posté de cette facon aterrit proprement dans un dossier dédié de ma boite mail. Si le commentaire est pertinent, je mets à jour l'article lié en citant l'auteur du commentaire, s'il le souhaite.

Ce systeme hybride me simplifie la gestion du site, sa maintenance, ainsi que la modération des commentaires.

J'ai trouvé sa solution tellement simple et elegante, que je me suis dit que j'allais la partager.

L'idée est de faire un simple script, en bash, qui affiche une notification au bout de 25 minutes, pour indiquer qu'il est temps de faire une pause. J'ai amélioré un peu l'idée pour en faire une commande directement accessible depuis un terminal.

Voici donc les etapes.

Creer, si'l n'existe pas, le dossier /home//.local/bin/

mkdir -p ~/.local/bin

Creer le fichier de script contenant la commande. 1500 secondes correspondent à 25 minutes.

cat > ~/.local/bin/pomodoro.sh <<EOF
notify-send "Début de session Pomodoro."
sleep 1500 && notify-send "Votre session de pomodoro est terminée. Faites une pause." &
EOF

Rendez le executable.

chmod +x ~/.local/bin/pomodoro.sh

Vous n'avez plus qu'a executer la commande suivante depuis un terminal ouvert.

pomodoro.sh

Note : Comme le script se trouve dans .local/bin/ de votre /home, pas besoin d'utiliser le chemin complet pour l'appeler. Il est inclu dans votre PATH par défaut.

Plus de détails sur les fonctionnalité sur le site de présentation.

La génèse du projet

Etant un gros joueur de RPG et de MMORPG, je n'ai découvert que tardivement les FPS. Je suis tombé dedans avec Skyrim, puis, plus tard, avec Overwatch. Et je dois dire qu'apres quelques heures de jeux, notamment sur Overwatch, une pensée me trottait dans la tete :

Pourquoi je n'arrive pas à toucher ce put*** de Genji alors que je suis juste à deux metres !! Mais bon sang, c'est vraiment trop moisi les FPS au clavier ! Depuis le temps, personne n'a jamais eu l'idée de faire une manette pour la main gauche ?

Apres moulte recherches infructueuses, j'ai fini par me dire que ca ne devait pas etre si compliqué à faire une manette quand meme ! Et bien, à vrai dire, c'est effectivement plutot simple, surtout en utilisant un truc déja existant et bien fichu : un nunchuk. Mais il faut quand meme savoir ou on va.

Mais arrete de causer et dit nous où on peut en acheter un !

Cesse donc d'etre aggressif, vil(e) impatient(e) ! J'ai encore des choses à expliquer.

Jusqu'a il y a quelques mois, j'avais une petite structure légale qui me permettait d'en vendre. Mais, meme si les Nunsticks se vendaient régulierement, le nombre n'etait pas suffisant pour absorber le montant exorbitant des taxes sur les entreprises.

Du coup, la réponse est à la fois simple et compliquée : Si tu en veux un, fabrique le toi meme !

Je m'en sers toujours quotidiennement, et je trouve dommage que le Nunstick meurt par manque de volume de production. J'ai donc décidé de mettre les ressources a disposition pour en fabriquer sous license GPL v3.

Fabriquer un Nunstick ? Ok... mais comment ?

Le materiel

Alors deja il va falloir te procurer un arduino micro atmega32u4. N'achete pas ces mauvaises copies souvent nommées "Micro Pro". Ce sont des versions au rabais, les soudures des composants sont fragiles.

Si tu ne sais pas souder, tu peux utiliser la version avec les headers (broches) déja soudés, ainsi que des connecteurs sans soudure type jumper.

Ensuite il te faudra un connecteur de nunchuck.

J'ai la flemme de faire un shema, voici comment relier les deux :

Le logiciel

Il va te falloir installer le logiciel de developpement de l'arduino (Arduino IDE). Ca prend quelques minutes avec un bon tuto.

Tout d'abord il va falloir décompresser le driver dans le dossier libraries de l'arduino IDE

Puis telecharger et ouvrir le logiciel du Nunstick.

Il ne restera plus qu'a l'uploader dans l'Arduino comme c'est decrit dans le tuto ci dessus.

Peaufiner un peu le tout

Pour faire un joli boitier, voici les fichiers .stl à utiliser avec n'importe quelle imprimante 3D.

Pour info, j'utilise une imprimante type Prusa I3 et le logiciel ultimaker pour le pilotage de l'impression.

Attention, pour que ca rentre dans le boitier, il faut utiliser la version de l'arduino à souder sois meme. Ca ne rentrera pas avec les broches. Il te faudra aussi souder les fils dans les trous de l'adaptateur du Nunchuck et couper les pins au raz de leur support en plastique noir.

Et voila un Nunstick tout neuf !

Mais Je ne sais pas faire tout ca moi et j'en veux un quand meme !

Je t'invite à te rapprocher du Fablab le plus proche de chez toi. Tu y trouveras surement des gens sympa qui pourrons t'aider pour la soudure et l'impression 3D.

J'ai pendant longtemps cherché a changer le mappage par défaut de ma razer Naga Hex. Impossible de faire autre chose, sans les drivers razer, que les deux configuration de la souris activable par le bouton qui se trouve dessous.

J'etais donc condamné à devoir reconfigurer tous mes jeux pour utiliser soit les chiffres 123456 du clavier standard soit ceux clavier numérique.

Mais c'est alors que je suis tombé sur cette page. Je test sur mon PC, un xubuntu 18.04 et la, ô joie, ca fonctionne !

Voila donc un script qui fonctionne sur les nagas Hex et les nagas Epic :

#Récuperation du clavier ID généré par la Naga
remote_id=$(
  xinput list |
  sed -n 's/.*Naga.*id=\([0-9]*\).*keyboard.*/\1/p'
)
[ "$remote_id" ] || exit

#Creation du fichier de configuration des touches
mkdir -p /tmp/xkb/symbols
cat >/tmp/xkb/symbols/custom <<\EOF
xkb_symbols "remote" {
    key <AE01>   { [Alt_L] };
    key <AE02>   { [e, E] };
    key <AE03>   { [a,  A] };
    key <AE04>   { [Control_L] };
    key <AE05>   { [Tab,  ISO_Left_Tab] };
    key <AE06>   { [c, C] };
    key <AE07>   { [F7, F7] };
    key <AE08>   { [F8, F8] };
    key <AE09>   { [F9, F9] };
    key <AE10>   { [F10, F10] };
    key <AE11>   { [F11, F11] };
    key <AE12>   { [F12, F12] };
};
EOF

#Injection de la nouvelle configuration
setxkbmap -device $remote_id -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_id -synch - $DISPLAY 2>/dev/null