Renaud Deraison a annoncé sur la liste de Nessus que la future version
majeure du moteur Nessus (la v3) serait toujours gratuite (d'un point de
vue financier) mais plus open-source (ie. distribution de binaires
seulement).
Les modifications techniques apportées par la v3 sont principalement
situées du côté des performances réseau (annoncé comme 2x plus rapide en
LAN) et de la charge du scanneur (RAM, processeur, disque).
La version 2 devrait rester en GPL et être maintenue encore quelques
temps (au moins pour les bug-fixes).
Renaud Deraison a annoncé sur la liste de Nessus que la future version majeure du moteur Nessus (la v3) serait toujours gratuite (d'un point de vue financier) mais plus open-source (ie. distribution de binaires seulement).
Oui, et donc ?
Bien peu de projets ont la chance d'être porté par une << fondation >> qui leur permet de vivre et faire vivre ses programmeurs. Pour les autres ils sont supportés par un groupe qui n'est pas rémunéré. Ce groupe ne tient que par la passion de ceux qui l'anime voire de quelques babioles vendues autour du projet parce que celui-ci a rencontré un tantinet de succès :tee-shirt, mugs, bandeaux de pub, etc.
En clair, AUCUN projet ne peut vivre à moyen terme sans un support renouvelé de développeurs.
TOUT LE MONDE est SUPER content de pouvoir profiter des logiciels open-source phare, les présenter à ses copains (et copines) et les utiliser pour exercer leur métier ! Mais COMBIEN contribuent manuellement ou financièrement aux projets qui les ont aidés à mieux se faire voir de leur hiérarchie, à gagner un job voire à vendre un produit basé sur une solution libre (*) ? 0,001% ? Et très certainement 0% si l'on considère les SSII ! Du reste une histoire semblable est déjà arrivée à Nessus qi ma mémoire est bonne : un vendeur sans scrupule s'est mis à le commercialiser il y a 2 aou 3 ans.
Alors oui, une solution NESSUS est 100 fois, 1000 fois préférable à un ISS pur des raisons de réactivité, d'honnêteté (souvenons-nous de l'affaire Lynn) et de confiance : qui vous dit que le scan ISS détecte TOUTES les failles connues dans les produits édités par ses actionnaires et les grands éditeurs/fabricants de ce monde et n'expédie pas de rapport confidentiel à la maison-mère ? Et oui, la moindre des choses en sécurité c'est de savoir à quoi l'on a affaire et on A TOUTES LES RAISONS d'avoir des scrupules d'utiliser une boîte noire.
N'en doutons pas les solutions propriétaires sont aux aguets au bout du chemin et si nous ne ne voyons, nous utilisateurs que le côté ludique de l'usage des logiciels libres, open-source, GPL, LPGL, etc. Il n'en restera plus beaucoup dans 5 ans. Et tout le monde sera bien forcer de réinstaller un bon vieux windows sur sa machine !
R. Deraison a développé Nessus pour des raisons lié à son travail et, certainement, à une passion technique et d'indépendance. Le moins que l'on puisse faire c'est de lui tirer notre champeau et d'accepter sa décision.
db
(*) Moi-même je suis en porte-à-faux par rapport à cette démarche. Effectivement j'ai et je participe MANUELLEMENT à certains projets, notamment en terme de traducteur. Mais combien en ai-je financé très modestement ? 2 ou 3 et il y a 10 ans !
--
Courriel : usenet blas net
Renaud Deraison a annoncé sur la liste de Nessus que la future version
majeure du moteur Nessus (la v3) serait toujours gratuite (d'un point de
vue financier) mais plus open-source (ie. distribution de binaires
seulement).
Oui, et donc ?
Bien peu de projets ont la chance d'être porté par une << fondation >>
qui leur permet de vivre et faire vivre ses programmeurs.
Pour les autres ils sont supportés par un groupe qui n'est pas rémunéré.
Ce groupe ne tient que par la passion de ceux qui l'anime voire de
quelques babioles vendues autour du projet parce que celui-ci a
rencontré un tantinet de succès :tee-shirt, mugs, bandeaux de pub, etc.
En clair, AUCUN projet ne peut vivre à moyen terme sans un support
renouvelé de développeurs.
TOUT LE MONDE est SUPER content de pouvoir profiter des logiciels
open-source phare, les présenter à ses copains (et copines) et les
utiliser pour exercer leur métier !
Mais COMBIEN contribuent manuellement ou financièrement aux projets qui
les ont aidés à mieux se faire voir de leur hiérarchie, à gagner un job
voire à vendre un produit basé sur une solution libre (*) ? 0,001% ? Et
très certainement 0% si l'on considère les SSII !
Du reste une histoire semblable est déjà arrivée à Nessus qi ma mémoire
est bonne : un vendeur sans scrupule s'est mis à le commercialiser il y
a 2 aou 3 ans.
Alors oui, une solution NESSUS est 100 fois, 1000 fois préférable à un
ISS pur des raisons de réactivité, d'honnêteté (souvenons-nous de
l'affaire Lynn) et de confiance : qui vous dit que le scan ISS détecte
TOUTES les failles connues dans les produits édités par ses actionnaires
et les grands éditeurs/fabricants de ce monde et n'expédie pas de
rapport confidentiel à la maison-mère ? Et oui, la moindre des choses en
sécurité c'est de savoir à quoi l'on a affaire et on A TOUTES LES
RAISONS d'avoir des scrupules d'utiliser une boîte noire.
N'en doutons pas les solutions propriétaires sont aux aguets au bout du
chemin et si nous ne ne voyons, nous utilisateurs que le côté ludique de
l'usage des logiciels libres, open-source, GPL, LPGL, etc. Il n'en
restera plus beaucoup dans 5 ans.
Et tout le monde sera bien forcer de réinstaller un bon vieux windows
sur sa machine !
R. Deraison a développé Nessus pour des raisons lié à son travail et,
certainement, à une passion technique et d'indépendance. Le moins que
l'on puisse faire c'est de lui tirer notre champeau et d'accepter sa
décision.
db
(*) Moi-même je suis en porte-à-faux par rapport à cette démarche.
Effectivement j'ai et je participe MANUELLEMENT à certains projets,
notamment en terme de traducteur. Mais combien en ai-je financé très
modestement ? 2 ou 3 et il y a 10 ans !
Renaud Deraison a annoncé sur la liste de Nessus que la future version majeure du moteur Nessus (la v3) serait toujours gratuite (d'un point de vue financier) mais plus open-source (ie. distribution de binaires seulement).
Oui, et donc ?
Bien peu de projets ont la chance d'être porté par une << fondation >> qui leur permet de vivre et faire vivre ses programmeurs. Pour les autres ils sont supportés par un groupe qui n'est pas rémunéré. Ce groupe ne tient que par la passion de ceux qui l'anime voire de quelques babioles vendues autour du projet parce que celui-ci a rencontré un tantinet de succès :tee-shirt, mugs, bandeaux de pub, etc.
En clair, AUCUN projet ne peut vivre à moyen terme sans un support renouvelé de développeurs.
TOUT LE MONDE est SUPER content de pouvoir profiter des logiciels open-source phare, les présenter à ses copains (et copines) et les utiliser pour exercer leur métier ! Mais COMBIEN contribuent manuellement ou financièrement aux projets qui les ont aidés à mieux se faire voir de leur hiérarchie, à gagner un job voire à vendre un produit basé sur une solution libre (*) ? 0,001% ? Et très certainement 0% si l'on considère les SSII ! Du reste une histoire semblable est déjà arrivée à Nessus qi ma mémoire est bonne : un vendeur sans scrupule s'est mis à le commercialiser il y a 2 aou 3 ans.
Alors oui, une solution NESSUS est 100 fois, 1000 fois préférable à un ISS pur des raisons de réactivité, d'honnêteté (souvenons-nous de l'affaire Lynn) et de confiance : qui vous dit que le scan ISS détecte TOUTES les failles connues dans les produits édités par ses actionnaires et les grands éditeurs/fabricants de ce monde et n'expédie pas de rapport confidentiel à la maison-mère ? Et oui, la moindre des choses en sécurité c'est de savoir à quoi l'on a affaire et on A TOUTES LES RAISONS d'avoir des scrupules d'utiliser une boîte noire.
N'en doutons pas les solutions propriétaires sont aux aguets au bout du chemin et si nous ne ne voyons, nous utilisateurs que le côté ludique de l'usage des logiciels libres, open-source, GPL, LPGL, etc. Il n'en restera plus beaucoup dans 5 ans. Et tout le monde sera bien forcer de réinstaller un bon vieux windows sur sa machine !
R. Deraison a développé Nessus pour des raisons lié à son travail et, certainement, à une passion technique et d'indépendance. Le moins que l'on puisse faire c'est de lui tirer notre champeau et d'accepter sa décision.
db
(*) Moi-même je suis en porte-à-faux par rapport à cette démarche. Effectivement j'ai et je participe MANUELLEMENT à certains projets, notamment en terme de traducteur. Mais combien en ai-je financé très modestement ? 2 ou 3 et il y a 10 ans !
--
Courriel : usenet blas net
Emmanuel Florac
Le Sun, 09 Oct 2005 23:08:38 +0000, Michel Arboi a écrit :
Certes, mais Nessus ne fait pas que de la comparaison de versions de packages ou de bannières. Les scripts "génériques" ont déjà trouvé des failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont que le contrôle d'application en production.
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Sun, 09 Oct 2005 23:08:38 +0000, Michel Arboi a écrit :
Certes, mais Nessus ne fait pas que de la comparaison de versions de
packages ou de bannières. Les scripts "génériques" ont déjà trouvé des
failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont que le
contrôle d'application en production.
--
Les défauts n'apparaissent qu'après que le programme a passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Le Sun, 09 Oct 2005 23:08:38 +0000, Michel Arboi a écrit :
Certes, mais Nessus ne fait pas que de la comparaison de versions de packages ou de bannières. Les scripts "génériques" ont déjà trouvé des failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont que le contrôle d'application en production.
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Michel Arboi
On Mon Oct 10 2005 at 11:15, Emmanuel Florac wrote:
Certes, mais Nessus ne fait pas que de la comparaison de versions de packages ou de bannières. Les scripts "génériques" ont déjà trouvé des failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont
Pas vraiment, puisqu'on ne regarde pas le code ! S'il faut trouver une ressemblance, je chercherais plutôt vers les "fuzzers", mais ce n'est pas exactement la même chose. Ces scripts Nessus passent des attaques classiques, ils ne cherchent pas un dysfonctionnement bizarre en envoyant des kazillons de requêtes mal fichues. Ce serait trop long.
que le contrôle d'application en production.
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch comme ça. Evidemment, comme on risque de le faire tomber, il faut faire ce genre de test sur une machine sans utilisateur (période creuse, config de test, etc)
On Mon Oct 10 2005 at 11:15, Emmanuel Florac wrote:
Certes, mais Nessus ne fait pas que de la comparaison de versions de
packages ou de bannières. Les scripts "génériques" ont déjà trouvé des
failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont
Pas vraiment, puisqu'on ne regarde pas le code !
S'il faut trouver une ressemblance, je chercherais plutôt vers les
"fuzzers", mais ce n'est pas exactement la même chose. Ces scripts
Nessus passent des attaques classiques, ils ne cherchent pas un
dysfonctionnement bizarre en envoyant des kazillons de requêtes mal
fichues. Ce serait trop long.
que le contrôle d'application en production.
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web
n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch
comme ça. Evidemment, comme on risque de le faire tomber, il faut
faire ce genre de test sur une machine sans utilisateur (période
creuse, config de test, etc)
On Mon Oct 10 2005 at 11:15, Emmanuel Florac wrote:
Certes, mais Nessus ne fait pas que de la comparaison de versions de packages ou de bannières. Les scripts "génériques" ont déjà trouvé des failles inconnues, ou du moins non publiées.
Certes, mais là on est plus dans l'audit de code en amont
Pas vraiment, puisqu'on ne regarde pas le code ! S'il faut trouver une ressemblance, je chercherais plutôt vers les "fuzzers", mais ce n'est pas exactement la même chose. Ces scripts Nessus passent des attaques classiques, ils ne cherchent pas un dysfonctionnement bizarre en envoyant des kazillons de requêtes mal fichues. Ce serait trop long.
que le contrôle d'application en production.
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch comme ça. Evidemment, comme on risque de le faire tomber, il faut faire ce genre de test sur une machine sans utilisateur (période creuse, config de test, etc)
Le Tue, 11 Oct 2005 12:25:56 +0000, Michel Arboi a écrit :
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch comme ça.
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée avant de mettre en production. Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
-- Quidquid latine dictum sit, altum sonatur
Le Tue, 11 Oct 2005 12:25:56 +0000, Michel Arboi a écrit :
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web
n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch
comme ça.
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles
versions, les nouveaux scripts, ... sur une machine dédiée avant de
mettre en production. Si la machine de test n'est pas vulnérable, la
machine de prod ne l'est pas...
Le Tue, 11 Oct 2005 12:25:56 +0000, Michel Arboi a écrit :
Je ne vois pas pourquoi on ne contrôlerait pas que le serveur web n'est pas vulnérable à un buffer overflow sur le champ "Host" ou qqch comme ça.
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée avant de mettre en production. Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
-- Quidquid latine dictum sit, altum sonatur
Michel Arboi
On Tue Oct 11 2005 at 16:50, Emmanuel Florac wrote:
parce que ce n'est pas comme ça qu'il faut faire.
Merci, je suis au courant. C'est ce qui se cachait dans mon message derrière "config de test".
On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux d'avoir un environnement de tests séparé. Par exemple, je ne connais pas de sociétés qui se permettent d'avoir un mainframe z/OS en double.
Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
On Tue Oct 11 2005 at 16:50, Emmanuel Florac wrote:
parce que ce n'est pas comme ça qu'il faut faire.
Merci, je suis au courant.
C'est ce qui se cachait dans mon message derrière "config de test".
On teste les nouvelles versions, les nouveaux scripts, ... sur une
machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux
d'avoir un environnement de tests séparé.
Par exemple, je ne connais pas de sociétés qui se permettent d'avoir
un mainframe z/OS en double.
Si la machine de test n'est pas vulnérable, la machine de prod ne
l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive
parfois, hélas.
On Tue Oct 11 2005 at 16:50, Emmanuel Florac wrote:
parce que ce n'est pas comme ça qu'il faut faire.
Merci, je suis au courant. C'est ce qui se cachait dans mon message derrière "config de test".
On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux d'avoir un environnement de tests séparé. Par exemple, je ne connais pas de sociétés qui se permettent d'avoir un mainframe z/OS en double.
Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
Christophe Garault
Dans le message , Cedric Blancher écrivit...
3. Nessus 2 est sous GPL et le restera donc toujours (GPL un jour, GPL toujours), ce qui permet à n'importe qui de forker un nouveau projet
C'est déjà fait:
http://www.gnessus.org/
Par contre il est difficile de prédire combien de temps ça tiendra.
-- Et sous les vieux haubans rongés de lente usure, Poulies aux yeux crevés sur l'infini perdu, Témoins momifiés des hommes disparus, Quel dieu féroce a pétrifié dans vos membrures Les fantômes railleurs de vos orgueils vaincus. - Anita Conti.
Dans le message <pan.2005.10.09.12.50.12.237971@cartel-securite.fr>,
Cedric Blancher écrivit...
3. Nessus 2 est sous GPL et le restera donc toujours (GPL un jour, GPL
toujours), ce qui permet à n'importe qui de forker un nouveau projet
C'est déjà fait:
http://www.gnessus.org/
Par contre il est difficile de prédire combien de temps ça
tiendra.
--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
3. Nessus 2 est sous GPL et le restera donc toujours (GPL un jour, GPL toujours), ce qui permet à n'importe qui de forker un nouveau projet
C'est déjà fait:
http://www.gnessus.org/
Par contre il est difficile de prédire combien de temps ça tiendra.
-- Et sous les vieux haubans rongés de lente usure, Poulies aux yeux crevés sur l'infini perdu, Témoins momifiés des hommes disparus, Quel dieu féroce a pétrifié dans vos membrures Les fantômes railleurs de vos orgueils vaincus. - Anita Conti.
Cedric Blancher
Le Tue, 11 Oct 2005 14:50:29 +0000, Emmanuel Florac a écrit :
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée avant de mettre en production. Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de production, dans la mesure ou comme n'importe quel scanner de vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
-- Il y en a qui ne savent pas déballer leur ordinateur de la boîte d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle fournie avec la boîte, il y a plein de mots et pas beaucoup d'images) -+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Le Tue, 11 Oct 2005 14:50:29 +0000, Emmanuel Florac a écrit :
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles
versions, les nouveaux scripts, ... sur une machine dédiée avant de
mettre en production. Si la machine de test n'est pas vulnérable, la
machine de prod ne l'est pas...
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de
production, dans la mesure ou comme n'importe quel scanner de
vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
--
Il y en a qui ne savent pas déballer leur ordinateur de la boîte
d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle
fournie avec la boîte, il y a plein de mots et pas beaucoup d'images)
-+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Le Tue, 11 Oct 2005 14:50:29 +0000, Emmanuel Florac a écrit :
parce que ce n'est pas comme ça qu'il faut faire. On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée avant de mettre en production. Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de production, dans la mesure ou comme n'importe quel scanner de vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
-- Il y en a qui ne savent pas déballer leur ordinateur de la boîte d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle fournie avec la boîte, il y a plein de mots et pas beaucoup d'images) -+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Emmanuel Florac
Le Wed, 12 Oct 2005 01:24:51 +0000, Michel Arboi a écrit :
Merci, je suis au courant.
Ouf :)
On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux d'avoir un environnement de tests séparé.
Faut pas pousser. Une config de test c'est souvent un PC dans un coin.
Par exemple, je ne connais pas de sociétés qui se permettent d'avoir un mainframe z/OS en double.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir une machine virtuelle réservée pour les tests. d'ailleurs j'utilise maintenant beaucoup QEMU pour certains tests, sur mon PC.
Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
Ce n'est pas à conseiller. Pour tester une config, je fais un backup de la machine de prod que je restaure sur la machine de test, et là je fais les modifs. Ensuite si la config de test est bonne, je backupe la machine de test pour la restaurer sur la machine de prod (en conservant les deux backups....). Ainsi, on est certain que chaque config est identique. C'est la méthode la plus simple (d'autant qu'avec un os unix/linux, il est très facile de faire un miroir d'une config existante et le restaurer).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Le Wed, 12 Oct 2005 01:24:51 +0000, Michel Arboi a écrit :
Merci, je suis au courant.
Ouf :)
On teste les nouvelles versions, les nouveaux scripts, ... sur une
machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux
d'avoir un environnement de tests séparé.
Faut pas pousser. Une config de test c'est souvent un PC dans un coin.
Par exemple, je ne connais pas de sociétés qui se permettent d'avoir
un mainframe z/OS en double.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir
une machine virtuelle réservée pour les tests. d'ailleurs j'utilise
maintenant beaucoup QEMU pour certains tests, sur mon PC.
Si la machine de test n'est pas vulnérable, la machine de prod ne
l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive
parfois, hélas.
Ce n'est pas à conseiller. Pour tester une config, je fais un backup de
la machine de prod que je restaure sur la machine de test, et là je fais
les modifs. Ensuite si la config de test est bonne, je backupe la machine
de test pour la restaurer sur la machine de prod (en conservant les deux
backups....). Ainsi, on est certain que chaque config est identique. C'est
la méthode la plus simple (d'autant qu'avec un os unix/linux, il est
très facile de faire un miroir d'une config existante et le restaurer).
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.
Le Wed, 12 Oct 2005 01:24:51 +0000, Michel Arboi a écrit :
Merci, je suis au courant.
Ouf :)
On teste les nouvelles versions, les nouveaux scripts, ... sur une machine dédiée
Encore faut-il en avoir une. Souvent, on peut s'estimer heureux d'avoir un environnement de tests séparé.
Faut pas pousser. Une config de test c'est souvent un PC dans un coin.
Par exemple, je ne connais pas de sociétés qui se permettent d'avoir un mainframe z/OS en double.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir une machine virtuelle réservée pour les tests. d'ailleurs j'utilise maintenant beaucoup QEMU pour certains tests, sur mon PC.
Si la machine de test n'est pas vulnérable, la machine de prod ne l'est pas...
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
Ce n'est pas à conseiller. Pour tester une config, je fais un backup de la machine de prod que je restaure sur la machine de test, et là je fais les modifs. Ensuite si la config de test est bonne, je backupe la machine de test pour la restaurer sur la machine de prod (en conservant les deux backups....). Ainsi, on est certain que chaque config est identique. C'est la méthode la plus simple (d'autant qu'avec un os unix/linux, il est très facile de faire un miroir d'une config existante et le restaurer).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Emmanuel Florac
Le Wed, 12 Oct 2005 01:24:52 +0000, Cedric Blancher a écrit :
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de production, dans la mesure ou comme n'importe quel scanner de vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
À la limite, oui. Mais si on a une config de test identique à la config de prod et qu'on a valildé que Nessus ne pose pas de problème, pourquoi pas? Le soucis ensuite ce sont les mises à jour : il faut systématiquement faire les mises à jour sur la config de test avant de les passer en production. Et qu'on ne vienne pas me dire que c'est trop de boulot : administrateur système c'est un métier, et il consiste essentiellement à éviter de casser les systèmes de production, pas à réparer les conneries après coup...
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Le Wed, 12 Oct 2005 01:24:52 +0000, Cedric Blancher a écrit :
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de
production, dans la mesure ou comme n'importe quel scanner de
vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
À la limite, oui. Mais si on a une config de test identique à la config
de prod et qu'on a valildé que Nessus ne pose pas de problème, pourquoi
pas? Le soucis ensuite ce sont les mises à jour : il faut
systématiquement faire les mises à jour sur la config de test avant de
les passer en production.
Et qu'on ne vienne pas me dire que c'est trop de boulot : administrateur
système c'est un métier, et il consiste essentiellement à éviter de
casser les systèmes de production, pas à réparer les conneries après
coup...
--
Pluralitas non est ponenda sine necessitate.
Guillaume d'Ockham.
Le Wed, 12 Oct 2005 01:24:52 +0000, Cedric Blancher a écrit :
Si on suit ton raisonnement, on ne lance pas Nessus sur un système de production, dans la mesure ou comme n'importe quel scanner de vulnérabilité, il ne te donnera jamais l'assurance de ne rien casser.
À la limite, oui. Mais si on a une config de test identique à la config de prod et qu'on a valildé que Nessus ne pose pas de problème, pourquoi pas? Le soucis ensuite ce sont les mises à jour : il faut systématiquement faire les mises à jour sur la config de test avant de les passer en production. Et qu'on ne vienne pas me dire que c'est trop de boulot : administrateur système c'est un métier, et il consiste essentiellement à éviter de casser les systèmes de production, pas à réparer les conneries après coup...
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Michel Arboi
On Wed Oct 12 2005 at 14:15, Emmanuel Florac wrote:
Faut pas pousser. Une config de test c'est souvent un PC dans un coin.
Surtout si l'appli tourne sur AIX ou HP/UX. <grin> Visiblement, nous ne fréquentons pas tout à fait les mêmes domaines.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir une machine virtuelle réservée pour les tests.
Et tu t'amuserais à la scanner ? Tu auras l'air fin si c'est tout le mainframe qui se casse la gueule. Je n'ai jamais trouvé de mainframe "disponible" pour faire le test. Par nature, ces bêtes sont utilisées 24h/24.
d'ailleurs j'utilise maintenant beaucoup QEMU pour certains tests, sur mon PC.
Tu m'en vois fort aise, tu iras expliquer ça à mes clients.
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
Ce n'est pas à conseiller.
Je n'ai pas dit que c'était à conseiller, j'ai dit que ça arrivait dans la vraie vie. Tu veux absolument avoir le dernier mot ou tu me prends pour un idiot ?
On Wed Oct 12 2005 at 14:15, Emmanuel Florac wrote:
Faut pas pousser. Une config de test c'est souvent un PC dans un
coin.
Surtout si l'appli tourne sur AIX ou HP/UX. <grin>
Visiblement, nous ne fréquentons pas tout à fait les mêmes domaines.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir
une machine virtuelle réservée pour les tests.
Et tu t'amuserais à la scanner ? Tu auras l'air fin si c'est tout le
mainframe qui se casse la gueule.
Je n'ai jamais trouvé de mainframe "disponible" pour faire le
test. Par nature, ces bêtes sont utilisées 24h/24.
d'ailleurs j'utilise maintenant beaucoup QEMU pour certains tests,
sur mon PC.
Tu m'en vois fort aise, tu iras expliquer ça à mes clients.
Sauf si les environnements sont légèrement différents, ce qui arrive
parfois, hélas.
Ce n'est pas à conseiller.
Je n'ai pas dit que c'était à conseiller, j'ai dit que ça arrivait
dans la vraie vie.
Tu veux absolument avoir le dernier mot ou tu me prends pour un idiot ?
On Wed Oct 12 2005 at 14:15, Emmanuel Florac wrote:
Faut pas pousser. Une config de test c'est souvent un PC dans un coin.
Surtout si l'appli tourne sur AIX ou HP/UX. <grin> Visiblement, nous ne fréquentons pas tout à fait les mêmes domaines.
Un Z/OS permet des machines virtuelles, il est absolument normal d'avoir une machine virtuelle réservée pour les tests.
Et tu t'amuserais à la scanner ? Tu auras l'air fin si c'est tout le mainframe qui se casse la gueule. Je n'ai jamais trouvé de mainframe "disponible" pour faire le test. Par nature, ces bêtes sont utilisées 24h/24.
d'ailleurs j'utilise maintenant beaucoup QEMU pour certains tests, sur mon PC.
Tu m'en vois fort aise, tu iras expliquer ça à mes clients.
Sauf si les environnements sont légèrement différents, ce qui arrive parfois, hélas.
Ce n'est pas à conseiller.
Je n'ai pas dit que c'était à conseiller, j'ai dit que ça arrivait dans la vraie vie. Tu veux absolument avoir le dernier mot ou tu me prends pour un idiot ?
