logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 18-07-2019 21:31:10

fab34080
Membre
Inscription : 18-07-2019

Mise en place d'un pare feu

Bonjour

Je découvre debian et je souhaite donc sécuriser mon serveur.
Je débute et ne maitrise pas toutes les notions et principes.

Si j'ai bien compris le pare feu permet dans une premier temps de gérer les ports.

On ouvre quelques ports HTTP et HTTPS + SSH
et on  ferme les autres

Mon serveur est derrière une box (internet et routeur)
et je me connecte en SSH depuis un autre ordi qui est aussi derrière la même box (routeur)

Je suppose que le connexion entre l'ordi et le serveur reste dans le réseau local... puis je autorise SSH uniquement sur le réseau local et l'interdire de l'extérieur...

J'ai plein de questions alors j’espère pouvoir échanger avec vous...

L'idée étant d'utiliser NFtables... mais avant je voulais arriver a définir mes besoins, possibilités

Dernière modification par fab34080 (18-07-2019 21:32:31)

Hors ligne

#2 18-07-2019 21:37:01

Debian Alain
Membre
Lieu : Bretagne
Distrib. : sid (unstable) / bullseye (stable)
Noyau : Linux sid 6.4.0-3-amd64
(G)UI : Gnome X.org (X11) / GDM3
Inscription : 11-03-2017
Site Web

Re : Mise en place d'un pare feu

salut fab34080 big_smile

pour les pare feux , il y en a essentiellement 2 :

iptables / nftables (pour les  connaisseurs)

ufw / gufw (pour les amateurs)

il y en a surement d'autres mais je les connais pas .
voilà les plus connus / courants .

Hors ligne

#3 19-07-2019 09:06:44

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

L'idée est d'utiliser NFtables, mais avant je voudrais comprendre les Possibilités par rapport a mes besoins.

Si j'ai bien compris un pare feu sert à TOUT interdire SAUF ce que l'on a besoin.

Si j'ai un serveur pour héberger un site, je dois donc ouvrir le port HTTP ?
Si j'ai un site sécurisé, je dois ouvrir le port HTTPS ?

C'est bien cela ?

Hors ligne

#4 19-07-2019 23:25:38

raleur
Membre
Inscription : 03-10-2014

Re : Mise en place d'un pare feu

fab34080 a écrit :

Si j'ai bien compris un pare feu sert à TOUT interdire SAUF ce que l'on a besoin.


Non, pas forcément. Pour commencer, "pare-feu" est une notion assez vague qui peut recouvrir des choses différentes. Nftables et son prédécesseur iptables sont des filtres de paquets. Ufw n'est qu'un enrobage d'iptables. Il existe d'autre méthodes pour contrôler les communications réseau, par exemple au niveau socket (ça doit être faisable avec SELinux), ou par TCP wrapper pour les services TCP.

fab34080 a écrit :


Si j'ai un serveur pour héberger un site, je dois donc ouvrir le port HTTP ?
Si j'ai un site sécurisé, je dois ouvrir le port HTTPS ?


"Ouvrir un port", ça ne veut rien dire de concret, notamment pour un filtre de paquets qui se borne à accepter ou bloquer des paquets. Il faut raisonner en terme de flux puis de paquets.

Dernière modification par raleur (19-07-2019 23:26:12)


Il vaut mieux montrer que raconter.

Hors ligne

#5 20-07-2019 12:06:52

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

Merci pour ta réponse, comme je suis débutant c'est des notions un peu compliqué... mais je te rassure je ne veux pas devenir administrateur de réseau lol... je suis juste un mec qui a passé 43 ans sous windows et qui découvre le monde de lunix. Je suis urbaniste donc aucun rapport avec l'informatique.

Je veux juste arriver a monter un petit serveur perso... pas a pas... mais en me posant certaines questions et en tentant de comprendre certaines notions... pas devenir un spécialiste, mais juste comprendre vaguement ce que je fais.

Je n'ai jamais utilisé IPtables... et comme je debute je souhaite commencer directement sur NFtables puisque il semble que bebian migrera vers NFtables.

J'ai compris que NFtables est juste une interface et pas un pare feu.

Si vous l'acceptez j'aimerais poser des questions de débutant.... pour avancer pas a pas... petit a petit...

La première question est que peut (ou doit) bloquer un pare feu :
des IP, des Ports, des protocoles, des programmes...

Hors ligne

#6 20-07-2019 13:03:27

raleur
Membre
Inscription : 03-10-2014

Re : Mise en place d'un pare feu

fab34080 a écrit :

Je n'ai jamais utilisé IPtables... et comme je debute je souhaite commencer directement sur NFtables puisque il semble que bebian migrera vers NFtables.


Sache néanmoins qu'iptables ne sera pas retiré dans un avenir proche, et qu'il y a beaucoup plus de personnes connaissant iptables et susceptibles de t'aider  à l'utilser que nftables.

fab34080 a écrit :

J'ai compris que NFtables est juste une interface et pas un pare feu.


Non, nftables n'est pas une interface mais un filtre de paquet, un type de pare-feu.

fab34080 a écrit :

La première question est que peut (ou doit) bloquer un pare feu :
des IP, des Ports, des protocoles, des programmes


Encore une fois, bloquer une adresse ou un port est une notion vague qui peut se faire de différentes façons à différents niveaux de la pile réseau.

Un filtre de paquets comme nftables ne peut bloquer que des paquets en fonction de leurs caractéristiques (protocole, adresses IP source et destination, ports source et destination si applicable au protocole... et bien d'autres). Ce n'est pas toujours suffisant pour déterminer si un paquet est légitime ou pas, notamment quand il répond à un autre paquet. On doit alors utiliser d'autres informations liées aux paquets comme le suivi des "connexions" auxquelles les paquets appartiennent.

Quant à savoir ce qu'un pare-feu doit bloquer, ça dépend de tes besoins. Et donc de ta capacité à définir clairement tes besoins.
Par exemple si tu veux interdire à un programme spécifique de communiquer avec l'extérieur, un filtre de paquets n'est pas le bon outil.

Dernière modification par raleur (20-07-2019 13:04:49)


Il vaut mieux montrer que raconter.

Hors ligne

#7 20-07-2019 17:37:37

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

Waouw c'est plus complexe que ce que j'imaginais...

Pour définir mes besoins pour le moment, je vais rester modeste.

- Un serveur WEB Debian + Nginx (pour héberger 3 sites en PHP).
- Une connexion Internet (HTTP + HTTPS) sans SMTP (sans mails).
- Une connexion réseau (SSH) entre le serveur et mon ordi (pour passer les lignes de commandes et alimenter déposer des fichiers).
- PHP-FPM pour la partie PHP.
- Une box pour la connexion internet qui sert aussi de routeur entre le serveur et l'ordi me servant pour passer les commandes.

Voila rien de trop complexe (enfin j'espère).

L'idée étant maintenant de venir y mettre une 1èere couche de sécurité... avec NFtables

Sur cette base l'idée est d'arriver a me poser les bonnes questions pour paramétrer NFtables... pas en appliquant des recettes, mais en essayant de comprendre les problématiques et les réponses a y apporter (sans non plus tomber dans l’excès inverse qui consisterait a rentrer dans trop de théorie...).

Hors ligne

#8 20-07-2019 17:45:44

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

La question est donc pour une configuration basique, qu'elles sont les principes a mettre en place, vu que je n'ai besoin que de HTTP, HTTPS et SSH

A mon niveau tout va se passer uniquement sur ses 3 ports :
HTTP et HTTPS j'utilise les ports normaux
et pour SSH j'ai modifié le port (sans rentrer dans le débat si c'est bien ou pas bien de modifier le port, cela ne sécurise rien, mais cela évite déjà de surcharger les logs inuites).

Donc on bloque tout sauf les 3 ports, ou déjà la je fais fausse route ???
Après viendra la question de savoir ce qu'on doit laisser passer et comment wink

Hors ligne

#9 20-07-2019 19:48:52

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

fab34080 a écrit :

Donc on bloque tout sauf les 3 ports, ou déjà la je fais fausse route ???


Il faudra aussi le suivi de connexion rien que pour faire les mises à jour (appelé contrack).
Donc il  te faut autoriser le trafic entrant sur les ports http et https, sur le port ssh
que tu as choisi uniquement pour l'adresse de ton pc (à condition d'avoir une ip fixe).
Autoriser les connexion sortantes et autoriser les connexions relatives à ces connexions
(contrack). Faire une redirection des ports http et https de ta boxe sur le serveur (où
le traffic entrant sur ces ports est autorisé.
Il faut aussi autorisé certains paquets icmp (au moins les ping depuis ta machine).
Si ton serveur obtiens  son adresse via dhcp, il faut bien penser à autoriser les traffic depuis
le routeur sur le port 68 (si je ne me trompe pas).

Avec tout ça, tu as un filtre de paquets minimal. Mais cela ne veut pas dire que tu sois
à l'abri des ennuis pour autant. Ce qu'il faire aussi, c'est éviter d'avoir des daemons qui écoutent
(listen) sur ton interface réseau. Il faut bien comprendre que la redirection des ports http et https
depuis le routeur vers ton serveur fait que c'est comme si ta machine était exposé directement
au moins pour ces deux ports. Le plus fragile  dans ce genre de configuration ça sera le serveur
web, et surtout php, et ça, le filtre de paquets ne peut rien y faire.

Hors ligne

#10 21-07-2019 09:13:24

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

Si j'ai bien compris NFtables une fois installé ne fait rien...

Il faut donc créer des règles que l'on peut enregistrer dans le fichier

/etc/nftables.conf



sous la forme


table inet filter {

    chain input {

        type filter hook input priority 0; policy accept;
...

drop
    }

}



1°) table inet filter -> indique que l'on utilise un FILTRE applicable au IPv4 et IPv6

2°) chain input -> indique que la règle s'applique aux entrées

3°) type filter hook input priority 0; policy accept; -> le filtre entrée sera de priorité maximale (s'appliquera avant d'autre filtre annexe).

4°) ... -> on définira les règles qui laisse passer les paquets

5°) drop -> on bloque tout le reste (tout pour le moment)

Voila le début de la réflexion, dans l'attente de vos précisions et rectifications

Hors ligne

#11 21-07-2019 20:15:35

raleur
Membre
Inscription : 03-10-2014

Re : Mise en place d'un pare feu

fab34080 a écrit :

Donc on bloque tout sauf les 3 ports, ou déjà la je fais fausse route ?


Tu fais fausse route en parlant de bloquer des ports, je l'ai déjà écrit. Il faut raisonner en flux.

Un exemple : si tu ne vas te connecter en SSH que depuis une adresse ou une plage d'adresses particulière (ex : le réseau local) alors tu ne devrais autoriser les connexions SSH entrantes que depuis cette source. Du coup on ne peut plus simplement parler de port ouvert ou bloqué. Mais on peut raisonner en flux, par exemple :
- autoriser les connexions SSH entrantes depuis telle adresse
- autoriser les connexions HTTP et HTTPS entrantes depuis n'importe quelle adresse
et ainsi de suite.

enicar a écrit :

Il faudra aussi le suivi de connexion rien que pour faire les mises à jour (appelé contrack).


Quelles mises à jour ?

enicar a écrit :

Autoriser les connexion sortantes et autoriser les connexions relatives à ces connexions (contrack).


Le suivi de connexion ne concerne pas que les connexions relatives, mais tous les paquets émis et reçus appartenant ou liés aux connexions autorisées entrantes et sortantes.

enicar a écrit :

Il faut aussi autorisé certains paquets icmp (au moins les ping depuis ta machine).


Le ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.


Il vaut mieux montrer que raconter.

Hors ligne

#12 23-07-2019 07:22:16

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Quelles mises à jour ?


À ton avis ?

raleur a écrit :

e ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.


Alors il faudrait citer précisément quels sont ces messages ICMP. Et dire pourquoi cela, c'est à dire
le rapport entre TCP, UDP et ICMP et le rapport entre le routage et ICMP avec une explication claire.
(désolé, si ce n'est pas assez précis pour toi, voir le commentaire en dessous).

@raleur et puis tant qu'à faire, tu devrais rédiger une documentation dans le wiki en ce qui concerne
les concepts utilisés pour TCP/IP avec des exemples parlants et précis. Sinon tes interventions
me donnent le sentiment que tu nous prend du haut de ta connaissance, ce n'est vraiment pas
constructif.

Hors ligne

#13 27-07-2019 07:24:45

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

Après une première tentative sur NFtables, je viens de comprendre que je n’arriverais à rien sans comprendre un minimum comment fonctionne les échanges sur les réseaux…
(je semble parfois réfractaire… mais au final j’écoute ce qu’on me donne comme conseil sur le forum smile )

Toujours dans l’idée de ne pas devenir un expert :wink: s’il y avait des gens dispo pour m’expliquer les grandes lignes… style j’explique à un enfant de 10 ans comment cela marche…

Dis papa il passe quoi dans le fin RJ45

J’ai crus comprendre que les informations (données) pas sous forme de flux par parquets petit bout par petit bout… ces paquets sortes de wagons on une sorte de carte d’identité et utilisent différents protocoles TPC UDP, des adresses, des ports…

Et parfois ses petits trains de paquet sifflent avant d’arriver en gare (avec des Ping / Icmp).

Si vous avez l’âme pédagogique et que la caricature ne vous fait pas peur…

Alors je suis a l’écoute du Chef de Gare smile

Je trouve que l’image avec le train, les wagons, les points d’aiguillages, les gares (ports) le tout roulant sur des lignes de chemin de fer (rj45) semble une image explicite

Dernière modification par fab34080 (27-07-2019 08:00:36)

Hors ligne

#14 27-07-2019 09:23:09

Erutluc
Membre
Inscription : 25-12-2017

Re : Mise en place d'un pare feu

Salut.
Le projet YunoHost pourrait vous intéresser.

Hors ligne

#15 27-07-2019 11:46:42

raleur
Membre
Inscription : 03-10-2014

Re : Mise en place d'un pare feu

Je n'écris pas de documentation ni de wiki. Il existe déjà pléthore de documentation au sujet de TCP/IP disponible sur le web, écrite par des gens bien plus qualifiés que moi. Je ne vais pas passer des heures à en écrire une de plus qui sera lue par deux ou trois personnes. Par contre je peux aider à éclaircir des points particuliers qui sembleraient obscurs, donner des conseils, aiguiller dans une direction plutôt qu'une autre, critiquer un choix... A mon avis c'est cela la véritable valeur ajoutée des forums.

Si j'ai un conseil à donner pour qui veut apprendre, c'est de lancer un programme de capture de trafic réseau comme tcpdump ou wireshark pour observer les paquets émis et reçus lors de communications simples comme un ping (ICMP), une requête DNS (UDP), une requête HTTP (TCP)... C'est très concret et instructif.

enicar a écrit :

Quelles mises à jour ?


À ton avis ?


Je ne sais pas, c'est pour cela que je demande. Si tu veux parler des mises à jour de paquets de la distribution, je ne vois pas le rapport particulier avec le suivi de connexion.

fab34080 a écrit :

Je trouve que l’image avec le train, les wagons, les points d’aiguillages, les gares (ports) le tout roulant sur des lignes de chemin de fer (rj45) semble une image explicite


Cette image n'est pas très représentative car chaque paquet voyage indépendamment des autres, il n'y a pas de train avec des wagons accrochés les uns aux autres, et un port TCP ou UDP n'a rien à voir avec une gare.


Il vaut mieux montrer que raconter.

Hors ligne

#16 27-07-2019 18:06:36

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Je ne sais pas, c'est pour cela que je demande. Si tu veux parler des mises à jour de paquets de la distribution, je ne vois pas le rapport particulier avec le suivi de connexion.


Ben essaies donc de mettre une machine à jour pour laquelle seul les connexions sur le port 22
est autorisées (en entrée donc), et aussi pour laquelle toutes les connexions sortantes sont autorisées
mais sans suivis de connexions. Les mises à jour des paquets seront impossibles. C'est un truc que j'ai déjà
vu, c'est pour ça que j'en parle.

Hors ligne

#17 27-07-2019 18:14:16

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Cette image n'est pas très représentative car chaque paquet voyage indépendamment des autres, il n'y a pas de train avec des wagons accrochés les uns aux autres, et un port TCP ou UDP n'a rien à voir avec une gare.


Alors qu'elle est la bonne image ?

Hors ligne

#18 27-07-2019 18:15:50

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Le ping ICMP est optionnel. Il n'est pas nécessaire d'un point de vue opérationnel. En revanche certains types de messages d'erreur ICMP sont indispensables au bon fonctionnement de TCP/IP.


Quelles sont ces messages ICMP absolument indispensables ?

Hors ligne

#19 27-07-2019 18:18:03

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

Erutluc a écrit :

Le projet YunoHost pourrait vous intéresser.


Je ne vois pas le rapport ? J'ai peut-être mal cherché…  ou alors c'est du spam ?

Hors ligne

#20 27-07-2019 19:58:12

raleur
Membre
Inscription : 03-10-2014

Re : Mise en place d'un pare feu

enicar a écrit :

toutes les connexions sortantes sont autorisées mais sans suivis de connexions


Autoriser les connexions sortantes (donc les paquets aller et retour appartenant à ces connexions) sans faire appel au suivi de connexion, c'est quelque peu risqué. Mais néanmoins faisable dans des conditions de sécurité relatives si les adresses des serveurs distants sont identifiées (ce qui peut être le cas des serveurs de mises à jour) : on peut alors filtrer sur l'adresse source, le port source et la plage de ports destination des paquets entrants, c'est mieux que rien.

Toutefois, cela ne répond pas à ma question : en quoi cela concerne-t-il spécifiquement les mises à jour de paquets (je rappelle que tu as écrit "rien que pour faire les mises à jour") ou même n'importe quel type de connexion sortante ? Le suivi de connexion est utile également pour les connexions entrantes. On ne va pas laisser passer n'importe quel paquet entrant sous prétexte qu'il est destiné à un port ouvert en écoute, ni n'importe quel paquet sortant sous prétexte qu'il a comme port source un port ouvert en écoute.

enicar a écrit :

Alors qu'elle est la bonne image ?


Je ne suis pas sûr qu'il existe une analogie satisfaisante. Peut-être des coursiers qui utilisent différents moyens de transport pour livrer des colis à des destinataires (adresse du bâtiment = adresse IP, numéro de porte dans le bâtiment = port).

enicar a écrit :

Quelles sont ces messages ICMP absolument indispensables ?


Les types d'erreur qui signalent un problème ayant empêché qu'un paquet atteigne sa destination :
- destination unreachable
- parameter problem
- time exceeded

J'en profite pour rappeler que la saine gestion de ces paquets par le pare-feu requiert également le suivi de connexion (état RELATED).

En IPv6, il y a un type d'erreur supplémentaire : packet too big. Selon le type de liaison et la méthode de configuration, il peut être aussi nécessaire d'accepter certains types du sous-protocole NDP.

Dernière modification par raleur (27-07-2019 20:06:34)


Il vaut mieux montrer que raconter.

Hors ligne

#21 27-07-2019 21:16:50

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Autoriser les connexions sortantes (donc les paquets aller et retour appartenant à ces connexions) sans faire appel au suivi de connexion, c'est quelque peu risqué. Mais néanmoins faisable dans des conditions de sécurité relatives si les adresses des serveurs distants sont identifiées (ce qui peut être le cas des serveurs de mises à jour) : on peut alors filtrer sur l'adresse source, le port source et la plage de ports destination des paquets entrants, c'est mieux que rien.


Bref, c'est chiant à configurer tout étant peu sûr, je préfère le suivis de connexions.

Hors ligne

#22 27-07-2019 21:21:56

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

raleur a écrit :

Toutefois, cela ne répond pas à ma question : en quoi cela concerne-t-il spécifiquement les mises à jour de paquets (je rappelle que tu as écrit "rien que pour faire les mises à jour")


Dans ma phrase je n'ai pas dit que c'était spécifiquement pour les mises à jour, mais que
pour celles-ci c'était nécessaire, et je sous-entend que ça peut être aussi pour être chose…
Évidemment ce n'est pas très précis, mais comme il est impossible d'énumérer tous les cas
possibles, cela me semblait une bonne formule, que tu n'as pas comprise.

Hors ligne

#23 28-07-2019 08:54:53

Erutluc
Membre
Inscription : 25-12-2017

Re : Mise en place d'un pare feu

Je ne vois pas le rapport ? J'ai peut-être mal cherché…  ou alors c'est du spam ?

Il faut cliquer sur le lien pour savoir qu’est-ce que c’est.

Je découvre debian et je souhaite donc sécuriser mon serveur.
Je débute et ne maitrise pas toutes les notions et principes.

J’en conclus que fab34080 débute

Mon serveur est derrière une box (internet et routeur)

J’en conclus que fab34080 auto-héberge son serveur

Débutant + auto-hébergement =  une distribution Linux pour débutant pour faire ses propres serveurs.
Donc j’en conclus que Yunohost pourrait intéresser cette personne.

Petit extrait du site (au cas où)

YunoHost est un système d’exploitation serveur visant à rendre accessible l’auto-hébergement à autant de personne que possible, sans délaisser la qualité et la fiabilité du logiciel.

-> https://yunohost.org/whatsyunohost_fr

Mais peut-être que j’ai mal compris ce que cherche à faire fab34080.

Hors ligne

#24 28-07-2019 10:13:22

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

Re : Mise en place d'un pare feu

Erutluc a écrit :

Donc j’en conclus que Yunohost pourrait intéresser cette personne.


Ce n'est pas le sujet du post. Mais bon je suppose que ça peut être intéressant.

Hors ligne

#25 29-07-2019 07:17:47

fab34080
Membre
Inscription : 18-07-2019

Re : Mise en place d'un pare feu

Merci pour vos réponses et déductions

Effectivement je débute et je souhaite faire un auto hébergement...

Mais cet auto hébergement n'est pas une fin en soit.... le but 1er n'est pas une obligation d'auto hébergement, rapide et efficace -> Yunohost aurait été parfait.

Cet auto hébergement est le prétexte pour apprendre et comprendre comment cela marche, pour mettre les mains dans le moteur... mon auto hébergement ne servant que de cas pratique... pour le moment wink

Hors ligne

Pied de page des forums