Es-tu sûr de vouloir de l'open-source ? Tu veux modifier le logiciel pour l'adapter à tes besoins ?
Je pense que par "open source", le posteur a fait un abus de langage... "open source" ne veut pas dire gratuit ! @+
Dominique Blas
bonjour, pour installer un FW sur chaque poste d'une très petite PME, existe t'il un FireWall en Open Source ? merci d'avance.
Y'a parfois des questions qui me sidèrent. Quelle est le type de plate-forme ? Fenêtres, MAcOS/X, MacOS, DOS, *nix, etc ?
Pourquoi open-source ? Parce que c'est synonyme de gratuit ? Pourquoi pas gratuit tout court ? Tu souhaites modifier les sources ?
Et, pourquoi vouloir placer un FW sur chaque poste ? J'ignore le nombre de postse mais cela va induire des coûts de maintenance, de mise à jour importants. S'il s'agit ce postes nomades je comprends mais s'il s'agit e postes fixes là non ! Il faut un FW central, correctement réglé et administré, une bonne politique de sécurité dont TOUT LE MONDE a conscience et cela vaut beacoup mieux !
db
--
Courriel : usenet blas net
bonjour,
pour installer un FW sur chaque poste d'une très petite PME, existe t'il
un FireWall en Open Source ?
merci d'avance.
Y'a parfois des questions qui me sidèrent.
Quelle est le type de plate-forme ? Fenêtres, MAcOS/X, MacOS,
DOS, *nix, etc ?
Pourquoi open-source ? Parce que c'est synonyme de gratuit ?
Pourquoi pas gratuit tout court ? Tu souhaites modifier les
sources ?
Et, pourquoi vouloir placer un FW sur chaque poste ? J'ignore
le nombre de postse mais cela va induire des coûts de
maintenance, de mise à jour importants.
S'il s'agit ce postes nomades je comprends mais s'il s'agit e
postes fixes là non !
Il faut un FW central, correctement réglé et administré, une
bonne politique de sécurité dont TOUT LE MONDE a conscience et
cela vaut beacoup mieux !
bonjour, pour installer un FW sur chaque poste d'une très petite PME, existe t'il un FireWall en Open Source ? merci d'avance.
Y'a parfois des questions qui me sidèrent. Quelle est le type de plate-forme ? Fenêtres, MAcOS/X, MacOS, DOS, *nix, etc ?
Pourquoi open-source ? Parce que c'est synonyme de gratuit ? Pourquoi pas gratuit tout court ? Tu souhaites modifier les sources ?
Et, pourquoi vouloir placer un FW sur chaque poste ? J'ignore le nombre de postse mais cela va induire des coûts de maintenance, de mise à jour importants. S'il s'agit ce postes nomades je comprends mais s'il s'agit e postes fixes là non ! Il faut un FW central, correctement réglé et administré, une bonne politique de sécurité dont TOUT LE MONDE a conscience et cela vaut beacoup mieux !
db
--
Courriel : usenet blas net
A. Caspis
Dominique Blas wrote:
Pourquoi open-source ? Parce que c'est synonyme de gratuit ? Pourquoi pas gratuit tout court ? Tu souhaites modifier les sources ?
C'est censé être aussi synonyme de pérennité, et aussi de sécurité (on ne compte plus les failles dans les firewalls et antivirus commerciaux).
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ?
Il faut un FW central, correctement réglé et administré (...)
En exagérant un peu je dirais que l'idéal, c'est: des langages de programmation intrinsèquement sûrs, des OS durcis et administrés centralement (TCPA ?), et pas de FW du tout (ou à la rigueur, un IDS et un MRTG passifs).
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy, routeur) est potentiellement une cible pour des attaques, et on va s'en apercevoir au fur et à mesure que les industriels de la sécurité feront les mêmes erreurs que les éditeurs d'applications, pour les mêmes raisons (augmenter les parts de marché en privilégiant les features plutôt que la sécurité).
AC
Dominique Blas wrote:
Pourquoi open-source ? Parce que c'est synonyme de gratuit ?
Pourquoi pas gratuit tout court ? Tu souhaites modifier les
sources ?
C'est censé être aussi synonyme de pérennité, et aussi de
sécurité (on ne compte plus les failles dans les firewalls et
antivirus commerciaux).
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ?
Il faut un FW central, correctement réglé et administré (...)
En exagérant un peu je dirais que l'idéal, c'est: des langages
de programmation intrinsèquement sûrs, des OS durcis et
administrés centralement (TCPA ?), et pas de FW du tout (ou à la
rigueur, un IDS et un MRTG passifs).
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy,
routeur) est potentiellement une cible pour des attaques, et on
va s'en apercevoir au fur et à mesure que les industriels de la
sécurité feront les mêmes erreurs que les éditeurs
d'applications, pour les mêmes raisons (augmenter les parts de
marché en privilégiant les features plutôt que la sécurité).
Pourquoi open-source ? Parce que c'est synonyme de gratuit ? Pourquoi pas gratuit tout court ? Tu souhaites modifier les sources ?
C'est censé être aussi synonyme de pérennité, et aussi de sécurité (on ne compte plus les failles dans les firewalls et antivirus commerciaux).
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ?
Il faut un FW central, correctement réglé et administré (...)
En exagérant un peu je dirais que l'idéal, c'est: des langages de programmation intrinsèquement sûrs, des OS durcis et administrés centralement (TCPA ?), et pas de FW du tout (ou à la rigueur, un IDS et un MRTG passifs).
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy, routeur) est potentiellement une cible pour des attaques, et on va s'en apercevoir au fur et à mesure que les industriels de la sécurité feront les mêmes erreurs que les éditeurs d'applications, pour les mêmes raisons (augmenter les parts de marché en privilégiant les features plutôt que la sécurité).
AC
Dominique Blas
[...]
C'est censé être aussi synonyme de pérennité, et aussi de sécurité (on ne compte plus les failles dans les firewalls et antivirus commerciaux). Bonne réponse. C'est pourquoi l'essentiel (surtout dans le domaine de la
sécu) des produits open-source se rencontre sur des plates-formes elles-mêmes open-source. Forcément. Le niveau de sécu ne vaut que par celui de son maillon le plus faible.
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ? Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
: un dispositif au niveau applicatif. On sort déjà du cadre du FW. Qui plus est cela n'empêchera pas l'application de planter, provoquer des débordements de tampon par exemple => impact sur la disponibilité (qui fait partie de la sécu soit dit en passant). Il faut alors un outil de contingentement. Il en existe en open-source mais pas très développé. Encore un produit de plus à gérer multiplié par le nombre de postes de travail => ca fait du boulot tout ça et ça revient cher. Pourquoi ne pas placer tout le monde en terminal X ?
En exagérant un peu je dirais que l'idéal, c'est: des langages de programmation intrinsèquement sûrs, des OS durcis et administrés centralement (TCPA ?), et pas de FW du tout (ou à la rigueur, un IDS et un MRTG passifs). Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
En admettant que le langage de prog soit << blindé >> le développeur ne l'est pas forcément, lui. << Errare humanum est >> c'est bien connu.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la sécurité mais bien davantage avec la finance.
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy, routeur) est potentiellement une cible pour des attaques, et on va s'en apercevoir au fur et à mesure que les industriels de la sécurité feront les mêmes erreurs que les éditeurs d'applications, pour les mêmes raisons (augmenter les parts de marché en privilégiant les features plutôt que la sécurité).
Pourquoi 'vont' ? Ils font les mêmes erreurs, pour les mêmes raisons et depuis longtemps. Cf. Cisco. Et pour les mêmes raisons, ils essayent de retourner les inconvénients que représentent les failles (qu'ils ne souhaitent pas corriger pour des raisons financières) à leur avantage. Voir ma petite histoire sur le prof argentin.
db
--
Courriel : usenet blas net
[...]
C'est censé être aussi synonyme de pérennité, et aussi de
sécurité (on ne compte plus les failles dans les firewalls et
antivirus commerciaux).
Bonne réponse. C'est pourquoi l'essentiel (surtout dans le domaine de la
sécu) des produits open-source se rencontre sur des plates-formes
elles-mêmes open-source.
Forcément. Le niveau de sécu ne vaut que par celui de son maillon le
plus faible.
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ?
Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
: un dispositif au niveau applicatif. On sort déjà du cadre du FW. Qui
plus est cela n'empêchera pas l'application de planter, provoquer des
débordements de tampon par exemple => impact sur la disponibilité (qui
fait partie de la sécu soit dit en passant).
Il faut alors un outil de contingentement. Il en existe en open-source
mais pas très développé. Encore un produit de plus à gérer multiplié par
le nombre de postes de travail => ca fait du boulot tout ça et ça
revient cher.
Pourquoi ne pas placer tout le monde en terminal X ?
En exagérant un peu je dirais que l'idéal, c'est: des langages
de programmation intrinsèquement sûrs, des OS durcis et
administrés centralement (TCPA ?), et pas de FW du tout (ou à la
rigueur, un IDS et un MRTG passifs).
Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
En admettant que le langage de prog soit << blindé >> le développeur ne
l'est pas forcément, lui. << Errare humanum est >> c'est bien connu.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source
n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la
sécurité mais bien davantage avec la finance.
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy,
routeur) est potentiellement une cible pour des attaques, et on
va s'en apercevoir au fur et à mesure que les industriels de la
sécurité feront les mêmes erreurs que les éditeurs
d'applications, pour les mêmes raisons (augmenter les parts de
marché en privilégiant les features plutôt que la sécurité).
Pourquoi 'vont' ? Ils font les mêmes erreurs, pour les mêmes raisons et
depuis longtemps.
Cf. Cisco.
Et pour les mêmes raisons, ils essayent de retourner les inconvénients
que représentent les failles (qu'ils ne souhaitent pas corriger pour des
raisons financières) à leur avantage. Voir ma petite histoire sur le
prof argentin.
C'est censé être aussi synonyme de pérennité, et aussi de sécurité (on ne compte plus les failles dans les firewalls et antivirus commerciaux). Bonne réponse. C'est pourquoi l'essentiel (surtout dans le domaine de la
sécu) des produits open-source se rencontre sur des plates-formes elles-mêmes open-source. Forcément. Le niveau de sécu ne vaut que par celui de son maillon le plus faible.
Et, pourquoi vouloir placer un FW sur chaque poste ?
Pour filtrer les flux en fonction des applications impliquées ? Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
: un dispositif au niveau applicatif. On sort déjà du cadre du FW. Qui plus est cela n'empêchera pas l'application de planter, provoquer des débordements de tampon par exemple => impact sur la disponibilité (qui fait partie de la sécu soit dit en passant). Il faut alors un outil de contingentement. Il en existe en open-source mais pas très développé. Encore un produit de plus à gérer multiplié par le nombre de postes de travail => ca fait du boulot tout ça et ça revient cher. Pourquoi ne pas placer tout le monde en terminal X ?
En exagérant un peu je dirais que l'idéal, c'est: des langages de programmation intrinsèquement sûrs, des OS durcis et administrés centralement (TCPA ?), et pas de FW du tout (ou à la rigueur, un IDS et un MRTG passifs). Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
En admettant que le langage de prog soit << blindé >> le développeur ne l'est pas forcément, lui. << Errare humanum est >> c'est bien connu.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la sécurité mais bien davantage avec la finance.
Car chaque équipement réseau (FW, antivirus, NAT, switch, proxy, routeur) est potentiellement une cible pour des attaques, et on va s'en apercevoir au fur et à mesure que les industriels de la sécurité feront les mêmes erreurs que les éditeurs d'applications, pour les mêmes raisons (augmenter les parts de marché en privilégiant les features plutôt que la sécurité).
Pourquoi 'vont' ? Ils font les mêmes erreurs, pour les mêmes raisons et depuis longtemps. Cf. Cisco. Et pour les mêmes raisons, ils essayent de retourner les inconvénients que représentent les failles (qu'ils ne souhaitent pas corriger pour des raisons financières) à leur avantage. Voir ma petite histoire sur le prof argentin.
db
--
Courriel : usenet blas net
A. Caspis
Dominique Blas wrote:
Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
Certes, "iptables -m owner" n'est pas selinux.
Pourquoi ne pas placer tout le monde en terminal X ?
Le rêve de l'administrateur... mais ça reviendrait cher pour les nomades GPRS.
Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
Un langage tel que je puisse faire confiance au programme même si je ne fais pas confiance au programmeur. Bon, en fait, on en revient un peu aux techniques de contingentement.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la sécurité mais bien davantage avec la finance.
C'est un sujet intéressant, et les avis sont divisés sur les bénéfices de TCPA respectivement pour les utilisateurs, les entreprises, les éditeurs de logiciels et de contenus, et les gouvernements.
Pour le responsable SI d'une entreprise, TCPA devrait être l'outil idéal pour faire respecter la politique de sécurité et les règles d'utilisation des moyens informatiques (forcer le déploiement des patches critiques, interdire les applications non indispensables). Sur le papier, ça donne la même sécurité que la solution à base de terminaux X puisqu'on peut empêcher l'utilisateur de bricoler avec son disque, ses ports USB, etc. Et il n'y a pas de raison que ça ne marche pas aussi pour des postes de travail open-source.
Reste à voir comment l'infrastructure TCPA pourra être sous le contrôle à la fois de l'administrateur, de Microsoft et de Hollywood.
AC
Dominique Blas wrote:
Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
Certes, "iptables -m owner" n'est pas selinux.
Pourquoi ne pas placer tout le monde en terminal X ?
Le rêve de l'administrateur... mais ça reviendrait cher pour
les nomades GPRS.
Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
Un langage tel que je puisse faire confiance au programme même
si je ne fais pas confiance au programmeur. Bon, en fait, on en
revient un peu aux techniques de contingentement.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source
n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la
sécurité mais bien davantage avec la finance.
C'est un sujet intéressant, et les avis sont divisés sur les
bénéfices de TCPA respectivement pour les utilisateurs, les
entreprises, les éditeurs de logiciels et de contenus, et les
gouvernements.
Pour le responsable SI d'une entreprise, TCPA devrait être
l'outil idéal pour faire respecter la politique de sécurité
et les règles d'utilisation des moyens informatiques (forcer
le déploiement des patches critiques, interdire les applications
non indispensables). Sur le papier, ça donne la même sécurité que
la solution à base de terminaux X puisqu'on peut empêcher
l'utilisateur de bricoler avec son disque, ses ports USB, etc.
Et il n'y a pas de raison que ça ne marche pas aussi pour des
postes de travail open-source.
Reste à voir comment l'infrastructure TCPA pourra être sous
le contrôle à la fois de l'administrateur, de Microsoft et
de Hollywood.
Qui dit flux dit déjà quelque chose de plus << farfouilleur >> qu'un FW
Certes, "iptables -m owner" n'est pas selinux.
Pourquoi ne pas placer tout le monde en terminal X ?
Le rêve de l'administrateur... mais ça reviendrait cher pour les nomades GPRS.
Et c'est quoi un langage << sûr >> ? Sûr de lui-même ? :-)
Un langage tel que je puisse faire confiance au programme même si je ne fais pas confiance au programmeur. Bon, en fait, on en revient un peu aux techniques de contingentement.
Et l'évocation de TCPA nous éloigne inévitablement de l'open-source n'est ce pas ? De toute manière TCPA n'a que peut à voir avec la sécurité mais bien davantage avec la finance.
C'est un sujet intéressant, et les avis sont divisés sur les bénéfices de TCPA respectivement pour les utilisateurs, les entreprises, les éditeurs de logiciels et de contenus, et les gouvernements.
Pour le responsable SI d'une entreprise, TCPA devrait être l'outil idéal pour faire respecter la politique de sécurité et les règles d'utilisation des moyens informatiques (forcer le déploiement des patches critiques, interdire les applications non indispensables). Sur le papier, ça donne la même sécurité que la solution à base de terminaux X puisqu'on peut empêcher l'utilisateur de bricoler avec son disque, ses ports USB, etc. Et il n'y a pas de raison que ça ne marche pas aussi pour des postes de travail open-source.
Reste à voir comment l'infrastructure TCPA pourra être sous le contrôle à la fois de l'administrateur, de Microsoft et de Hollywood.
AC
Fabien LE LEZ
On 10 Aug 2005 13:16:20 GMT, Dominique Blas :
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
On 10 Aug 2005 13:16:20 GMT, Dominique Blas <db@internet.invalid>:
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles"
(pilotage automatique d'avion ou de fusée, électronique médicale,
etc.) ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
Patrick 'Zener' Brunet
Bonjour.
On 10 Aug 2005 13:16:20 GMT, Dominique Blas :
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
J'ai vu du FORTH, sinon beaucoup de C et de "Basics" à numéros de ligne. Mais le plus impressionnant est la motivation des stagiaires qui en sont parfois chargés (il y a alors un pro qui passe derrière la nuit pour relire le code). :-)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
On 10 Aug 2005 13:16:20 GMT, Dominique Blas <db@internet.invalid>:
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles"
(pilotage automatique d'avion ou de fusée, électronique médicale,
etc.) ?
J'ai vu du FORTH, sinon beaucoup de C et de "Basics" à numéros de ligne.
Mais le plus impressionnant est la motivation des stagiaires qui en sont
parfois chargés
(il y a alors un pro qui passe derrière la nuit pour relire le code).
:-)
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
J'ai vu du FORTH, sinon beaucoup de C et de "Basics" à numéros de ligne. Mais le plus impressionnant est la motivation des stagiaires qui en sont parfois chargés (il y a alors un pro qui passe derrière la nuit pour relire le code). :-)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
FAb
Fabien LE LEZ writes:
On 10 Aug 2005 13:16:20 GMT, Dominique Blas :
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
Y en a pas mal... dont du "C" ! Alors...
FAbrice
Fabien LE LEZ <gramster@gramster.com> writes:
On 10 Aug 2005 13:16:20 GMT, Dominique Blas <db@internet.invalid>:
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles"
(pilotage automatique d'avion ou de fusée, électronique médicale,
etc.) ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ?
Y en a pas mal... dont du "C" ! Alors...
FAbrice
Dominique Blas
On 10 Aug 2005 13:16:20 GMT, Dominique Blas :
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ? ADA (ADA95 maintenant) est souvent utilisé dans ces domaines. Ce serait
toutefois un peu présompteux de le déclarer sûr pour autant. Un développeur ADA peut très facilement développer une bombe logique (*) au sein d'un logiciel écrit en ADA et l'activer par la suite.
db
(*) Ou un vers, ou un virus, etc.
--
Courriel : usenet blas net
On 10 Aug 2005 13:16:20 GMT, Dominique Blas <db@internet.invalid>:
Et c'est quoi un langage << sûr >> ?
Quels sont les langages utilisés dans les systèmes "sensibles"
(pilotage automatique d'avion ou de fusée, électronique médicale,
etc.) ?
ADA (ADA95 maintenant) est souvent utilisé dans ces domaines. Ce serait
toutefois un peu présompteux de le déclarer sûr pour autant. Un
développeur ADA peut très facilement développer une bombe logique (*) au
sein d'un logiciel écrit en ADA et l'activer par la suite.
Quels sont les langages utilisés dans les systèmes "sensibles" (pilotage automatique d'avion ou de fusée, électronique médicale, etc.) ? ADA (ADA95 maintenant) est souvent utilisé dans ces domaines. Ce serait
toutefois un peu présompteux de le déclarer sûr pour autant. Un développeur ADA peut très facilement développer une bombe logique (*) au sein d'un logiciel écrit en ADA et l'activer par la suite.
