Nous avons été en relation avec l'ANSSI par la passé.
Mais le coût d'une certification est assez élevé, aux alentours de 50k€ pour une CSPN (Certification de Sécurité de Premier Niveau) (Critères communs) et au-delà des 100K€ pour une certification CC (Critères Communs). Il faut aussi compter ±30 jours/homme.
Il faut que nous regardions s'il est possible d'obtenir une aide pour passer ces certifications.
Installation d'un cluster Vsphere chez un client, je lui propose d'utiliser DynFi pour protéger l'infrastructure que je présente comme une excellente solution. Installation d'une VM sur le cluster.
Résultat : impossible de se connecter à l'interface Web, débit de l'infra plafonné à 10mb/s.
Après 1h de recherches, je décide d'installer à la place OPNSense : plus aucun problème.
Nous n'avons pas directement testé l'installation sous ESXi car nous utilisons Proxmox.
Cependant je vous garantie que cela fonctionne très bien sous KVM.
Par ailleurs nous utilisons Proxmox-VE comme plate-forme pour nos tests unitaire et debug.
Nous allons essayer de monter un PoC sous VMWare ESXi, juste pour pouvoir être précis dans nos réponses. Il serait particulièrement étonnant que cela fonctionne très bien sous KVM et pas sous ESXi…
Tentatives d'installation sur trois types d'appliances différentes que j'utilise régulièrement avec OPNSense sans rencontrer de problèmes. Avec de la patience car j'ai réellement envie de donner une chance à votre projet, je trouve deux modèles qui acceptent l'installation de DynFi. Pour un modèle en revanche impossible (sûrement un problème de matériel non reconnu).
Ok, c'est déjà assez différent de ce que vous exposiez initialement…
Donc deux devices sur trois fonctionnent.
Quel est le hardware de la troisième appliance ?
Quelles sont les erreurs que vous rencontrez ?
Nous avons un forum DynFi ou vous pouvez poser vos questions et sur lequel nous essayons de vous répondre et vous aider.
Bien entendu j'ai utilisé deux clés USB différentes et téléchargé deux fois l'ISO, j'en suis spas à mes premières installations.
Bref, j'ai toujours défendu votre projet et l'ai présenté sous un très bon jour aux personnes autour de moi mais je vous avoue que votre message me donne envie de ralentir franchement.
Euh… Non vous n'avez pas du tout "toujours défendu notre projet", vous avez même fait un gros flame dans lequel vous indiquez que "rien ne fonctionne", sans aucun argumentaire.
On a apparement pas la même notion de ce que c'est de "défendre un projet" Open Source.
Comme indiqué je n'ai pas encore réessayé sur des environnements virtualisés mais là tout de suite j'ai plus envie.
Ah là j'avoue ne plus vous suivre…
Vous indiquez que cela ne "fonctionne pas sous VMWare" et ici vous indiquez que vous n'avez pas encore "réessayé sur des environnements virtualisés" ??
Or il me semble que VMWare ESXi est un "environnement virtualisé"…
Franchement ce n'est pas très sérieux.
Pour une réponse claire, il est nécessaire de préciser :
- quelle version de DynFi Firewall avez-vous installé ?
- à partir de quelle média l'avez-vous installé (installation VGA ou Série) ?
- pour une installation sur un serveur virtualisé il faut utiliser une image VGA
- s'il y a des problèmes à l'installation (ce que nous n'avons pas constaté), remontez-les sur le forum
Le problème de fond vient de votre premier post où vous indiquez que "rien ne fonctionne" et en insistant un peu on s'aperçoit que :
vous n'avez probablement pas fait de tests sur la version 3.00.000 de DynFi Firewall
vous avez partiellement testé cela sous VMWare ESXi dans des versions antérieures, mais ce n'est pas très clair…
il n'y a aucun retour précis d'information concernant les éventuels problèmes que vous avez rencontré
Nous avons spécifiquement travaillé sur l'amélioration de la stabilité à tous les niveaux sur la v.3 qui s'installe très bien, sur les systèmes virtualisés ou sur des appliances i386 ou amd64, sauf exception.
installation toujours impossible (au mieux fastidieuse)
Vous dites "impossible", est-ce que vous pensez que nous publions une troisième version après trois années de développement et que l'installation du système est "impossible" ?
Essayez de donner plus de contexte.
Pour le moment vous n'êtes pas parvenu à installer le logiciel ou vous avez eu du mal à l'installer.
La plupart du temps ces problèmes proviennent de clé USB de mauvaise qualité, de corruption de l'image au niveau du transport ou de problèmes de cette nature.
Je vous garantie que l'installeur fonctionne.
Il vous faut une clé avec 2GO de stockage minimum, je vous recommande les clés Corsair Voyager. Après plusieurs milliers de gravures, ce sont les seules qui tiennent vraiment la route.
Sur des médias lents, vous pouvez avoir un peu de latence au niveau de la détection des disque et des instructions "camcontrol" de FreeBSD.
Enfin si vous avez un retour à nous faire ou des remarques qui peuvent nous être utiles, ou des questions, n'hésitez pas à utiliser notre forum. Nous répondons rapidement et efficacement.
Un point à noter, DynFi Firewall embarque tous les programmes dans son installeur, le volume de données à installer est donc plus important.
D'une façon générale, il faut prévoir un minimum de 2GB (4GB ou + c'est mieux) de RAM et une appliance type APU au minimum (avec un proc dual ou quad core même de petite taille et un min de 1GHz).
Vous aurez de toute façon besoin de puissance pour exploiter pleinement certaines des fonctions du pare-feu (filtrage RPZ, Proxy, Ntop et Nprobe, …).
L'idée est d'utiliser cela pour des lycées, des écoles ou des université et des entreprises. Ils ont depuis des années des problématiques de filtrage des sites pour adultes et avec nos 14 millions d'URL notre solution est assez efficace.
Mais effectivement le RPZ neutralise les requêtes DNS et par conséquent fausse le fonctionnement d'un internet transparent.
C'était d'ailleurs un argument de ceux qui n'apprécient pas ces technologies.
D'un point de vue technique on pourra se reporter à l'article de Stéphane Bortzmeyer une référence en matière de technologies liées aux DNS.
Cela a été un argument pour les grosses sociétés qui ont poussé les technos du type DoH (DNS over HTTPS) comme cloudflare, google… Là on ne voit plus rien, les requêtes DNS sont transmises à Cloudflare ou Google et eux ré-utilisent les données de millions d'utilisateurs pour faire un peu tout et n'importe quoi.
Personnellement je suis favorable à :
un Internet décentralisé qui respecte les protocoles et notamment le DNS dans son modèle standard (= hiérarchique et décentralisé)
la possibilité de contrôler pour des raisons de conformité à des politiques d'entreprise ou de bon sens
la possibilité de comprendre ce qui se passe sur son réseau instantanément
Le problème de toute technologie de filtrage réside dans son bon usage par ceux qui vont l'utiliser.
On voit également "Proxmox" dans les produits : à part fournir des appliances avec Proxmox installé et du service, je ne vois pas en quoi est le "produit"…
Première remarque, l'auteur de la dépêche n'en a posté que deux, sur ce même projet.
Je n'ai posté que deux dépêches sur le sujet car nous sommes une petite structure et que nous n'avons que peu de temps à consacrer à la communication. C'est probablement une faute et nous posterons donc plus régulièrement, c'est promis !
Sur le produit en lui même, cela ressemble plus à une appropriation de projet libre qu'à une participation active.
De ce que je vois, les seules contribution à OpnSense consistent en un patch d'une ligne (voire d'un caractère) et l'ouverture d'un bug: https://github.com/search?q=org%3Aopnsense+dynfi&type=issues
Notre objectif n'est pas de "contribuer au projet OPNsense", nous publions notre code et les équipes d'OPNsense peuvent le consulter et le ré-utiliser si besoin est.
Il y a une équipe de quatre développeurs qui travaille sur le projet à titre d'information, nous avons :
mis au point notre propre système de compilation sous poudriere
développé une interface graphique originale
développé un système original de fitrage DNS basé sur RPZ et Unbound
développé nos propres listes de filtrage DNS (issu d'une cooperation avec Central Paris)
Intégré de nombreux nouveaux packages
Modifié la structure du code et revue le système de log
Intégré Ntop et nprobe de façon plus aboutie
Nous travaillons en ce moment même sur une modification substantielle du package Suricata ainsi que sur un renforcement de l'intégration du filtrage L7 issue d'une coopération avec les équipes de ntop.
Je vous renvoie à un thread assez récent dans lequel j'explique qui nous sommes, d'où nous venons et pourquoi nous avons forké le projet OPNsense. Cela me semble intéressant de préciser cela ici. Sinon tout est mélangé et nous passons pour des imposteurs.
Pour ceux qui ne parle pas Anglais, je vais le traduire:
Bref historique
ToDoo (aujourd'hui DynFi) a été l'un des principaux distributeurs de pfSense en France de 2008 à 2014, à l'époque où OPNsense n'existait pas. Nous avons donc des racines communes avec OPNsense.
DynFi a été l'une des principales sociétés à l'origine de la divulgation de l'escroquerie OPNsense.com organisée par les propriétaires de Netgate. Grâce à notre connaissance approfondie du DNS (nous maintenons le DNS primaire pour un pays) et à notre avocat spécialisé dans les marques et l'OMPI, nous avons aidé Deciso (propriétaire d'OPNsense) à débloquer le verrou "Domain by Proxy" et à récupérer ce nom de domaine. Ce fut une grande victoire pour l'équipe d'OPNsense. Nous avons obtenu deux lignes de crédits dans un obscur billet publié à l'époque.
En 2015 / 2016, alors que nous étions les premiers partenaires (et sponsors) du projet OPNsense, nous sommes venus rendre visite à l'équipe de Deciso en Hollande pour discuter de notre volonté de développer une "solution de gestion centrale" qui n'existait pas à l'époque et nous avons été froidement accueillis avec un "nous ne voulons pas qu'un partenaire développe cela". Pendant les quatre années qui ont suivi la sortie de notre logiciel et dans une certaine mesure jusqu'à aujourd'hui, il n'y a pas de solution de gestion centralisée sur site (On Premise) en dehors de notre propre DynFi Manager.
Compte tenu de cette volonté de ne rien partager avec aucun "partenaire" en ce qui concerne le développement, quels choix s'offraient à nous ?
Développement de DynFi Manager
Ainsi, en 2017, ce qui aurait pu être un beau travail d'équipe, est clairement devenu la fin d'un partenariat.
Nous avons tiré les conséquences du refus de coopération sur le Manager et avons commencé le développement de notre DynFi Manager. La première version a été officiellement lancée en 2018.
Il y a eu plus de 60 versions et correctifs depuis le lancement du DynFi Manager en 2018.
Développement du pare-feu DynFi
Nous avons commencé à développer le DynFi Firewall en 2019 parce que nous pensions qu'il serait intéressant d'avoir une plateforme distincte sans HardenedBSD, mais plutôt directement basée sur le noyau FreeBSD. Il s'avère que nous avions raison car quelques mois après avoir finalisé notre fork, OPNsense est revenu au noyau FreeBSD et a abandonné HardenedBSD.
Je dois ajouter que nous avons notre propre plateforme de compilation et que nous avons fait un peu d'upstream du code d'OPNsense au début (mais Deciso n'a-t-il pas fait exactement la même chose avec pfSense en 2015 ?), plus nous avançons et moins nous faisons d'upstream. […].
Suite de la réponse au flame
D'ailleurs, la page github du projet n'est pas reprise comme un fork, mais un projet à part entière.
L'équipe de DynFi a développé un système de filtrage DNS basé sur le protocole RPZ, directement appliqué grâce à Unbound.
Il me semble que le mérite du système de filtrage reviens plutôt aux équipes de BSD, de pfSense et d'OpnSense. Aussi, je crois que l'inclusion de wireguard dans le noyau BSD est toujours expérimentale, non ? Quelqu'un peut confirmer.
Je vais essayer de rester courtois, mais cela frise le n'importe quoi. Avez-vous été voir le code que nous avons produit avant de vous lancer dans ces envolés lyriques ?
Nous avons passé plus de huit mois à mettre au point un filtrage DNS très efficace qui s'appuie sur Unbound. J'ai effectué une vidéo qui explique comment cela fonctionne ici et 100% du code vient de chez nous.
Le système de filtrage DNS RPZ utilise Unbound et permet un filtrage hyper efficace sur plus de 20 millions de sites Internet classés par thèmes (60 thématique de filtrage). A la différence de OPNsense, nous produisons et offrons gratuitement les listes compilées d'URL issues d'un traitement de plusieurs différentes listes ouvertes disponibles sur le Net.
Nous avons en plus ajouté l'exposition de graphiques qui permettent de se rendre compte en temps réel de l'impact des filtrages sur un réseau.
Enfin, sachez que parmi nos équipes, nous avons compté ou comptons toujours :
Manu aka Emmanuel Vadot (Core Team FreeBSD) qui a passé environ deux années à travailler avec nous, notamment sur la production du système de compilation et qui a cette occasion a pu écrire certain papiers sur pkgbase
Oshogbo grand contributeur et développeur FreeBSD qui contribue à notre projet de façon courante et est un spécialiste de Netmap
Pierre Pronchery développeur NetBSD qui a été mandaté pour développer par un partenaire un driver 4G à notre initiative
Ces personnes qui sont des contributeurs BSD de haut niveau vivent ou ont pu être financés sur des années grâce à notre projet et au financement que DynFi leur a apporté.
Les développements que nous avons effectués sur la mise au point de notre système de paquetage ont pu contribuer au projet pkgbase directement utilisé dans FreeBSD.
Donc oui, nous sommes légitimes pour faire un fork de OPNsense, non nous ne sommes pas des imposteurs et j'espère que ce post vous fera changer d'avis sur notre projet.
C'est la seconde fois que vous tentez de descendre notre projet, je ne vois pas vraiment l'intérêt de faire cela ?
A priori nos packages proviennent de la version 13 de FreeBSD, donc si certaines améliorations ont été apporté aux packages dans la version 13 de FreeBSD, ils le seront dans notre version.
Nous avons souhaité démarrer par l'installer et le build.
Rome ne s'est pas construit en un jour, ni notre projet !
C'est le contrat de licence du gestionnaire centralisé.
Vous pouvez tout de même gérer trois pare-feu gratuitement avec ce logiciel.
Et il est utilisé par des institutions et des grandes entreprises.
C'est un projet Java, qui n'a rien à voir avec DynFi Firewall, sauf que l'un et l'autres sont compatibles.
L'Open Source doit se financer, d'une façon ou d'une autre…
Pardon pardon, nous avons été un peu vite et la documentation qui a été faite pendant le premier confinement ne contient pas des images à jour de l'installer.
Nous avons publié une release qui corrige le bug d'installation constaté.
Super désolé, on a merdouillé, mais c'est corrigé.
Je sais pour la lancement officiel on aurait dû vérifier un peu mieux ce que l'on publiait, mais on était concentré sur des problématique de haut niveau quand l'installer était cassé.
Bon c'est fix.
J'espère que l'on parviendra à se faire pardonner en obtenant une seconde tentative.
Et effectivement, nous comprenons bien le résultat de l'essai => poubelle direct.
C'était la bonne destination pour cette image.
Cela n'est pas une "plaquette publicitaire", sauf à considérer que trois années de développement avec une équipe de quatre développeurs puisse l'être. Tout a été Open Sourcé sous licence FreeBSD.
Vous pouvez regarder sur GitHub les différentes contributions et projet qui constituent notre fork.
Concernant la roadmap, celle-ci n'est pas 100% définie à ce stade.
Nous avons des grands projets comme l'intégration d'un filtrage L7 sur lesquels nous souhaitons orienter nos développements.
Cela va pas mal dépendre des retours que nous aurons de la part des utilisateurs.
Tout d'abord à l'époque ou nous avons décidé de créer le fork (2018), OPNsense fonctionnait sur HardenedBSD et fonctionne toujours avec cette distribution à cette date.
La qualité générale de HardenedBSD, son scope, la façon dont le projet était maintenu, tout nous poussait à créer un fork.
Par ailleurs, nous avions déjà véçu une situation avec pfSense ou nous avons été leur distributeurs en France et ou un changement de politique nous a conduit à ne plus l'être.
Ensuite l'installer DynFi a été intégralement revu et se base sur l'installer FreeBSD.
Enfin et surtout, nous utilisons un mécanisme de compilation totalement original et différent de celui d'OPNsense qui est basé sur Poudriere.
Enfin BIS, nous sommes passés sur FreeBSD 13 depuis déjà un certain temps.
# Guide d'installation DynFi Firewall pour ESXi
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 1.
Certaines personnes dans ce thread mentionnait "l'impossibilité d'installer DynFi Firewall sous VMWare ESXi"—nous avons donc créer un guide qui détaille comment installer DynFi Firewall sous ESXi >> https://dynfi.com/documentations/dynfi-firewall/how-to/guide_deploiement_DynFi_Firewall_ESXi.html
Et cela fonctionne très bien !
;-)
[^] # Re: Sympa :)
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 2.
Bonjour @watchix - merci pour votre message.
Nous avons été en relation avec l'ANSSI par la passé.
Mais le coût d'une certification est assez élevé, aux alentours de 50k€ pour une CSPN (Certification de Sécurité de Premier Niveau) (Critères communs) et au-delà des 100K€ pour une certification CC (Critères Communs). Il faut aussi compter ±30 jours/homme.
Il faut que nous regardions s'il est possible d'obtenir une aide pour passer ces certifications.
Mais oui, cela nous aiderait probablement.
[^] # Re: Dommage...
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 4.
Nous n'avons pas directement testé l'installation sous ESXi car nous utilisons Proxmox.
Cependant je vous garantie que cela fonctionne très bien sous KVM.
Tellement bien que nous avons fait une vidéo qui détaille étape par étape l'installation de DynFi Firewall sur un hyperviseur Open Source, en l'occurence Proxmox v.7.x
Par ailleurs nous utilisons Proxmox-VE comme plate-forme pour nos tests unitaire et debug.
Nous allons essayer de monter un PoC sous VMWare ESXi, juste pour pouvoir être précis dans nos réponses. Il serait particulièrement étonnant que cela fonctionne très bien sous KVM et pas sous ESXi…
Ok, c'est déjà assez différent de ce que vous exposiez initialement…
Donc deux devices sur trois fonctionnent.
Nous avons un forum DynFi ou vous pouvez poser vos questions et sur lequel nous essayons de vous répondre et vous aider.
Euh… Non vous n'avez pas du tout "toujours défendu notre projet", vous avez même fait un gros flame dans lequel vous indiquez que "rien ne fonctionne", sans aucun argumentaire.
On a apparement pas la même notion de ce que c'est de "défendre un projet" Open Source.
Ah là j'avoue ne plus vous suivre…
Vous indiquez que cela ne "fonctionne pas sous VMWare" et ici vous indiquez que vous n'avez pas encore "réessayé sur des environnements virtualisés" ??
Or il me semble que VMWare ESXi est un "environnement virtualisé"…
Franchement ce n'est pas très sérieux.
Pour une réponse claire, il est nécessaire de préciser :
- quelle version de DynFi Firewall avez-vous installé ?
- à partir de quelle média l'avez-vous installé (installation VGA ou Série) ?
- pour une installation sur un serveur virtualisé il faut utiliser une image VGA
- s'il y a des problèmes à l'installation (ce que nous n'avons pas constaté), remontez-les sur le forum
Le problème de fond vient de votre premier post où vous indiquez que "rien ne fonctionne" et en insistant un peu on s'aperçoit que :
Nous avons spécifiquement travaillé sur l'amélioration de la stabilité à tous les niveaux sur la v.3 qui s'installe très bien, sur les systèmes virtualisés ou sur des appliances i386 ou amd64, sauf exception.
[^] # Re: Dommage...
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 4. Dernière modification le 16 avril 2023 à 00:19.
Vous dites "impossible", est-ce que vous pensez que nous publions une troisième version après trois années de développement et que l'installation du système est "impossible" ?
Essayez de donner plus de contexte.
Pour le moment vous n'êtes pas parvenu à installer le logiciel ou vous avez eu du mal à l'installer.
La plupart du temps ces problèmes proviennent de clé USB de mauvaise qualité, de corruption de l'image au niveau du transport ou de problèmes de cette nature.
Je vous garantie que l'installeur fonctionne.
Il vous faut une clé avec 2GO de stockage minimum, je vous recommande les clés Corsair Voyager. Après plusieurs milliers de gravures, ce sont les seules qui tiennent vraiment la route.
Sur des médias lents, vous pouvez avoir un peu de latence au niveau de la détection des disque et des instructions "camcontrol" de FreeBSD.
[^] # Re: Dommage...
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 5. Dernière modification le 15 avril 2023 à 23:55.
Sur quel type d'appliance / ordi avez-vous peiné à l'installer ?
Normalement cela fonctionne très bien.
Plusieurs posts peuvent vous aider dans la phase d'installation :
- notre documentation sur DynFi Firewall qui précise la façon d'installer l'OS
- le tuto Youtube post sur la façon de créer une clé bootable
- ce second tuto YouTube sur la façon d'installer DynFi Firewall sur une VM
Enfin si vous avez un retour à nous faire ou des remarques qui peuvent nous être utiles, ou des questions, n'hésitez pas à utiliser notre forum. Nous répondons rapidement et efficacement.
Un point à noter, DynFi Firewall embarque tous les programmes dans son installeur, le volume de données à installer est donc plus important.
D'une façon générale, il faut prévoir un minimum de 2GB (4GB ou + c'est mieux) de RAM et une appliance type APU au minimum (avec un proc dual ou quad core même de petite taille et un min de 1GHz).
Vous aurez de toute façon besoin de puissance pour exploiter pleinement certaines des fonctions du pare-feu (filtrage RPZ, Proxy, Ntop et Nprobe, …).
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 8.
L'idée est d'utiliser cela pour des lycées, des écoles ou des université et des entreprises. Ils ont depuis des années des problématiques de filtrage des sites pour adultes et avec nos 14 millions d'URL notre solution est assez efficace.
Mais effectivement le RPZ neutralise les requêtes DNS et par conséquent fausse le fonctionnement d'un internet transparent.
C'était d'ailleurs un argument de ceux qui n'apprécient pas ces technologies.
D'un point de vue technique on pourra se reporter à l'article de Stéphane Bortzmeyer une référence en matière de technologies liées aux DNS.
Cela a été un argument pour les grosses sociétés qui ont poussé les technos du type DoH (DNS over HTTPS) comme cloudflare, google… Là on ne voit plus rien, les requêtes DNS sont transmises à Cloudflare ou Google et eux ré-utilisent les données de millions d'utilisateurs pour faire un peu tout et n'importe quoi.
Personnellement je suis favorable à :
Le problème de toute technologie de filtrage réside dans son bon usage par ceux qui vont l'utiliser.
[^] # Re: Quelles sont les diffrences avec OPNSense ?
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 3. Dernière modification le 14 avril 2023 à 16:59.
La plupart des développements sont détaillés ici :
https://dynfi.com/produits-dynfi/firewall/releases-dynfi-firewall/
Et les release de nos produits exposées ici:
https://dynfi.com/forum/viewforum.php?f=3&sid=8c345fffe9466b83429af57abde3807e
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 8.
Nous sommes partenaires silver de Proxmox - revendons les abonnements proxmox-VE prix coûtant et contribuons ainsi au projet que nous connaissons très bien et apprécions particulièrement.
Où est le problème ?
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . En réponse à la dépêche DynFi Firewall lance sa v.3.0 . Évalué à 10.
Sommaire
Je n'ai posté que deux dépêches sur le sujet car nous sommes une petite structure et que nous n'avons que peu de temps à consacrer à la communication. C'est probablement une faute et nous posterons donc plus régulièrement, c'est promis !
Notre objectif n'est pas de "contribuer au projet OPNsense", nous publions notre code et les équipes d'OPNsense peuvent le consulter et le ré-utiliser si besoin est.
Il y a une équipe de quatre développeurs qui travaille sur le projet à titre d'information, nous avons :
Nous travaillons en ce moment même sur une modification substantielle du package Suricata ainsi que sur un renforcement de l'intégration du filtrage L7 issue d'une coopération avec les équipes de ntop.
Je vous renvoie à un thread assez récent dans lequel j'explique qui nous sommes, d'où nous venons et pourquoi nous avons forké le projet OPNsense. Cela me semble intéressant de préciser cela ici. Sinon tout est mélangé et nous passons pour des imposteurs.
https://forum.opnsense.org/index.php?topic=33414.0
Pour ceux qui ne parle pas Anglais, je vais le traduire:
Bref historique
ToDoo (aujourd'hui DynFi) a été l'un des principaux distributeurs de pfSense en France de 2008 à 2014, à l'époque où OPNsense n'existait pas. Nous avons donc des racines communes avec OPNsense.
DynFi a été l'une des principales sociétés à l'origine de la divulgation de l'escroquerie OPNsense.com organisée par les propriétaires de Netgate. Grâce à notre connaissance approfondie du DNS (nous maintenons le DNS primaire pour un pays) et à notre avocat spécialisé dans les marques et l'OMPI, nous avons aidé Deciso (propriétaire d'OPNsense) à débloquer le verrou "Domain by Proxy" et à récupérer ce nom de domaine. Ce fut une grande victoire pour l'équipe d'OPNsense. Nous avons obtenu deux lignes de crédits dans un obscur billet publié à l'époque.
En 2015 / 2016, alors que nous étions les premiers partenaires (et sponsors) du projet OPNsense, nous sommes venus rendre visite à l'équipe de Deciso en Hollande pour discuter de notre volonté de développer une "solution de gestion centrale" qui n'existait pas à l'époque et nous avons été froidement accueillis avec un "nous ne voulons pas qu'un partenaire développe cela". Pendant les quatre années qui ont suivi la sortie de notre logiciel et dans une certaine mesure jusqu'à aujourd'hui, il n'y a pas de solution de gestion centralisée sur site (On Premise) en dehors de notre propre DynFi Manager.
Compte tenu de cette volonté de ne rien partager avec aucun "partenaire" en ce qui concerne le développement, quels choix s'offraient à nous ?
Développement de DynFi Manager
Ainsi, en 2017, ce qui aurait pu être un beau travail d'équipe, est clairement devenu la fin d'un partenariat.
Nous avons tiré les conséquences du refus de coopération sur le Manager et avons commencé le développement de notre DynFi Manager. La première version a été officiellement lancée en 2018.
Il y a eu plus de 60 versions et correctifs depuis le lancement du DynFi Manager en 2018.
Développement du pare-feu DynFi
Nous avons commencé à développer le DynFi Firewall en 2019 parce que nous pensions qu'il serait intéressant d'avoir une plateforme distincte sans HardenedBSD, mais plutôt directement basée sur le noyau FreeBSD. Il s'avère que nous avions raison car quelques mois après avoir finalisé notre fork, OPNsense est revenu au noyau FreeBSD et a abandonné HardenedBSD.
Je dois ajouter que nous avons notre propre plateforme de compilation et que nous avons fait un peu d'upstream du code d'OPNsense au début (mais Deciso n'a-t-il pas fait exactement la même chose avec pfSense en 2015 ?), plus nous avançons et moins nous faisons d'upstream. […].
Suite de la réponse au flame
Je vais essayer de rester courtois, mais cela frise le n'importe quoi. Avez-vous été voir le code que nous avons produit avant de vous lancer dans ces envolés lyriques ?
Nous avons passé plus de huit mois à mettre au point un filtrage DNS très efficace qui s'appuie sur Unbound. J'ai effectué une vidéo qui explique comment cela fonctionne ici et 100% du code vient de chez nous.
Le système de filtrage DNS RPZ utilise Unbound et permet un filtrage hyper efficace sur plus de 20 millions de sites Internet classés par thèmes (60 thématique de filtrage). A la différence de OPNsense, nous produisons et offrons gratuitement les listes compilées d'URL issues d'un traitement de plusieurs différentes listes ouvertes disponibles sur le Net.
Nous avons en plus ajouté l'exposition de graphiques qui permettent de se rendre compte en temps réel de l'impact des filtrages sur un réseau.
Enfin, sachez que parmi nos équipes, nous avons compté ou comptons toujours :
Ces personnes qui sont des contributeurs BSD de haut niveau vivent ou ont pu être financés sur des années grâce à notre projet et au financement que DynFi leur a apporté.
Les développements que nous avons effectués sur la mise au point de notre système de paquetage ont pu contribuer au projet pkgbase directement utilisé dans FreeBSD.
Donc oui, nous sommes légitimes pour faire un fork de OPNsense, non nous ne sommes pas des imposteurs et j'espère que ce post vous fera changer d'avis sur notre projet.
C'est la seconde fois que vous tentez de descendre notre projet, je ne vois pas vraiment l'intérêt de faire cela ?
Last but not least : vous pourrez apprécier notref vision de l'Open Source dans un article rédigé et publié dans le revue Télécom des anciens de Télécom Paristech qui se trouve ici.
[^] # Re: Pourquoi forker ?
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 1.
Oui, certainement.
Et nous avons démarré ce projet en 2018.
A l'époque OPNsense n'avait pas envisagé de migrer sur FreeBSD, mais était très attaché à HardenedBSD.
[^] # Re: Liens cassés sur le site DynFI
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 1.
C'est corrigé.
[^] # Re: Quelles sont les diffrences avec OPNSense ?
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 1.
L'analyse est assez bonne.
A priori nos packages proviennent de la version 13 de FreeBSD, donc si certaines améliorations ont été apporté aux packages dans la version 13 de FreeBSD, ils le seront dans notre version.
Nous avons souhaité démarrer par l'installer et le build.
Rome ne s'est pas construit en un jour, ni notre projet !
[^] # Re: dynfi-manager
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 4.
Oui, DynFi Manager est bien propriétaire et n'est pas Open Source.
Mais la dépêche n'essaie pas de faire passer des poires pour des pommes.
C'est le contrat de licence du gestionnaire centralisé.
Vous pouvez tout de même gérer trois pare-feu gratuitement avec ce logiciel.
Et il est utilisé par des institutions et des grandes entreprises.
C'est un projet Java, qui n'a rien à voir avec DynFi Firewall, sauf que l'un et l'autres sont compatibles.
L'Open Source doit se financer, d'une façon ou d'une autre…
[^] # Re: ça fait un peu pub?
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 4.
Pardon pardon, nous avons été un peu vite et la documentation qui a été faite pendant le premier confinement ne contient pas des images à jour de l'installer.
Nous avons publié une release qui corrige le bug d'installation constaté.
Super désolé, on a merdouillé, mais c'est corrigé.
https://dynfi.com/telecharger/dynfi-firewall/
Je sais pour la lancement officiel on aurait dû vérifier un peu mieux ce que l'on publiait, mais on était concentré sur des problématique de haut niveau quand l'installer était cassé.
Bon c'est fix.
J'espère que l'on parviendra à se faire pardonner en obtenant une seconde tentative.
Et effectivement, nous comprenons bien le résultat de l'essai => poubelle direct.
C'était la bonne destination pour cette image.
[^] # Re: Traduction d'OpenOffice
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 0. Dernière modification le 15 novembre 2021 à 14:53.
Encore une fois, prenez le temps de regarder les milliers de lignes de code qui distinguent notre projet de celui d'OPNsense.
La traduction de l'interface graphique à 100% n'est qu'une des partie des travaux que nous avons effectués.
https://github.com/DynFi
Nous sommes par exemple entrain de produire une documentation en Français qui se trouve ici et à laquelle je vous invite à contribuer.
C'est incomplet, ce n'est pas parfait, mais cela représente tout de même plusieurs milliers d'heure de travail.
[^] # Re: Roadmap et différences
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 0.
Cela n'est pas une "plaquette publicitaire", sauf à considérer que trois années de développement avec une équipe de quatre développeurs puisse l'être. Tout a été Open Sourcé sous licence FreeBSD.
Vous pouvez regarder sur GitHub les différentes contributions et projet qui constituent notre fork.
Concernant la roadmap, celle-ci n'est pas 100% définie à ce stade.
Nous avons des grands projets comme l'intégration d'un filtrage L7 sur lesquels nous souhaitons orienter nos développements.
Cela va pas mal dépendre des retours que nous aurons de la part des utilisateurs.
[^] # Re: Equipe et plus
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 2.
Nous allons tout faire pour essayer d'avoir des utilisateurs heureux !
Des contributeurs sympas et un projet ambitieux.
N'hésitez pas à nous remonter vos envies.
[^] # Re: Pourquoi forker ?
Posté par gregober . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 7.
Bonjour André,
Nous avons plusieurs bonnes raisons pour forker.
Tout d'abord à l'époque ou nous avons décidé de créer le fork (2018), OPNsense fonctionnait sur HardenedBSD et fonctionne toujours avec cette distribution à cette date.
La qualité générale de HardenedBSD, son scope, la façon dont le projet était maintenu, tout nous poussait à créer un fork.
Par ailleurs, nous avions déjà véçu une situation avec pfSense ou nous avons été leur distributeurs en France et ou un changement de politique nous a conduit à ne plus l'être.
Ensuite l'installer DynFi a été intégralement revu et se base sur l'installer FreeBSD.
Enfin et surtout, nous utilisons un mécanisme de compilation totalement original et différent de celui d'OPNsense qui est basé sur Poudriere.
Enfin BIS, nous sommes passés sur FreeBSD 13 depuis déjà un certain temps.
Pour plus d'information sur le sujet, tu peux consulter notre documentation ici : https://dynfi.com/documentations/dynfi-firewall/historique_dynfi_firewall.html#un-nouveau-fork-opnsense-2015-2019
J'ai aussi donné un talk au Paris Open Source summit sur les firewalls Open Source ou j'évoquais le sujet en long en large et en travers ;-)
L'équipe DynFi.