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).
Le Wed, 12 Oct 2005 12:15:07 +0000, Emmanuel Florac a écrit : [Architecture de test _et_ de 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...
Souvent, c'est juste une question de moyens...
-- BOFH excuse #165:
Backbone Scoliosis
Le Wed, 12 Oct 2005 12:15:07 +0000, Emmanuel Florac a écrit :
[Architecture de test _et_ de 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...
Le Wed, 12 Oct 2005 12:15:07 +0000, Emmanuel Florac a écrit : [Architecture de test _et_ de 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...
Souvent, c'est juste une question de moyens...
-- BOFH excuse #165:
Backbone Scoliosis
Mehdi BENKIR
Emmanuel Florac wrote:
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...
ça, c'est la théorie. En pratique, le patron du sysadmin aime garder la liberté de faire les choix stratégiques qui lui semblent bon, lesquels incluent souvent des "compromis", parmi lesquels, celui de mettre à contribution la légendaire virtuosité en freestyle de son sysadmin, ne serait-ce que pour s'assurer qu'il a réellement besoin d'un informaticien en interne plutôt que de se contenter d'une hotline.
Emmanuel Florac wrote:
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...
ça, c'est la théorie. En pratique, le patron du sysadmin aime garder la
liberté de faire les choix stratégiques qui lui semblent bon, lesquels
incluent souvent des "compromis", parmi lesquels, celui de mettre à
contribution la légendaire virtuosité en freestyle de son sysadmin, ne
serait-ce que pour s'assurer qu'il a réellement besoin d'un
informaticien en interne plutôt que de se contenter d'une hotline.
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...
ça, c'est la théorie. En pratique, le patron du sysadmin aime garder la liberté de faire les choix stratégiques qui lui semblent bon, lesquels incluent souvent des "compromis", parmi lesquels, celui de mettre à contribution la légendaire virtuosité en freestyle de son sysadmin, ne serait-ce que pour s'assurer qu'il a réellement besoin d'un informaticien en interne plutôt que de se contenter d'une hotline.
Emmanuel Florac
Le Wed, 12 Oct 2005 17:25:40 +0000, Cedric Blancher a écrit :
Souvent, c'est juste une question de moyens...
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la possibilité d'avoir un vieux PC pour tester une config serveur. Dans la réalité on voit assez souvent des gens pas très malins ou incompétents, qui font de l'administration système comme ils font l'optimisation de leur PC de jeu. En gros, "tu es geek, tiens, soit administrateur système".
-- Si non confectus non reficiat.
Le Wed, 12 Oct 2005 17:25:40 +0000, Cedric Blancher a écrit :
Souvent, c'est juste une question de moyens...
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la
possibilité d'avoir un vieux PC pour tester une config serveur. Dans la
réalité on voit assez souvent des gens pas très malins ou
incompétents, qui font de l'administration système comme ils font
l'optimisation de leur PC de jeu. En gros, "tu es geek, tiens, soit
administrateur système".
Le Wed, 12 Oct 2005 17:25:40 +0000, Cedric Blancher a écrit :
Souvent, c'est juste une question de moyens...
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la possibilité d'avoir un vieux PC pour tester une config serveur. Dans la réalité on voit assez souvent des gens pas très malins ou incompétents, qui font de l'administration système comme ils font l'optimisation de leur PC de jeu. En gros, "tu es geek, tiens, soit administrateur système".
-- Si non confectus non reficiat.
Emmanuel Florac
Le Wed, 12 Oct 2005 16:34:33 +0000, Michel Arboi a écrit :
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.
Que tu crois. J'ai des Sun, des SGI et une Bull Estrella en plus des PC de test. Ça ne change rien : une vieille machine (plus de 5 ans) ne peut plus servir en production mais est très utile pour les tests en labo.
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.
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons sérieux.
Je n'ai jamais trouvé de mainframe "disponible" pour faire le test. Par nature, ces bêtes sont utilisées 24h/24.
D'où la machine virtuelle... qui est l'utilisation la plus courante de z/OS, non? Il y a forcément des périodes creuses où on ne risque pas de surcharger le système en faisant un scan d'une VM.
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 ?
Tu sembles dire qu'il y a des cas où on ne peut pas avoir de config de test, et moi je te dis que ces cas peuvent bien sûr exister, mais sont relativement rares. Je tiens effectivement à avoir le dernier mot sur un point : on ne met pas en production sans avoir validé sur une config de test, et si par hasard on le fait parfois quand on est vraiment très très pris par le temps, il faut bien être conscient qu'on est en train de travailler comme un salaud et que ce n'est certainement pas une chose à refaire.
Ensuite on peut mettre Nessus ou pas sur une machine de production, pas de problème si on a d'abord validé sur une config de test, bien entendu :)
-- Si non confectus non reficiat.
Le Wed, 12 Oct 2005 16:34:33 +0000, Michel Arboi a écrit :
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.
Que tu crois. J'ai des Sun, des SGI et une Bull Estrella en plus des PC de
test. Ça ne change rien : une vieille machine (plus de 5 ans) ne peut
plus servir en production mais est très utile pour les tests en labo.
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.
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons
sérieux.
Je n'ai jamais trouvé de mainframe "disponible" pour faire le
test. Par nature, ces bêtes sont utilisées 24h/24.
D'où la machine virtuelle... qui est l'utilisation la plus courante de
z/OS, non? Il y a forcément des périodes creuses où on ne risque pas de
surcharger le système en faisant un scan d'une VM.
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 ?
Tu sembles dire qu'il y a des cas où on ne peut pas avoir de config de
test, et moi je te dis que ces cas peuvent bien sûr exister, mais sont
relativement rares.
Je tiens effectivement à avoir le dernier mot sur un point : on ne met
pas en production sans avoir validé sur une config de test, et si par
hasard on le fait parfois quand on est vraiment très très pris par le
temps, il faut bien être conscient qu'on est en train de travailler comme
un salaud et que ce n'est certainement pas une chose à refaire.
Ensuite on peut mettre Nessus ou pas sur une machine de production, pas de
problème si on a d'abord validé sur une config de test, bien entendu :)
Le Wed, 12 Oct 2005 16:34:33 +0000, Michel Arboi a écrit :
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.
Que tu crois. J'ai des Sun, des SGI et une Bull Estrella en plus des PC de test. Ça ne change rien : une vieille machine (plus de 5 ans) ne peut plus servir en production mais est très utile pour les tests en labo.
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.
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons sérieux.
Je n'ai jamais trouvé de mainframe "disponible" pour faire le test. Par nature, ces bêtes sont utilisées 24h/24.
D'où la machine virtuelle... qui est l'utilisation la plus courante de z/OS, non? Il y a forcément des périodes creuses où on ne risque pas de surcharger le système en faisant un scan d'une VM.
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 ?
Tu sembles dire qu'il y a des cas où on ne peut pas avoir de config de test, et moi je te dis que ces cas peuvent bien sûr exister, mais sont relativement rares. Je tiens effectivement à avoir le dernier mot sur un point : on ne met pas en production sans avoir validé sur une config de test, et si par hasard on le fait parfois quand on est vraiment très très pris par le temps, il faut bien être conscient qu'on est en train de travailler comme un salaud et que ce n'est certainement pas une chose à refaire.
Ensuite on peut mettre Nessus ou pas sur une machine de production, pas de problème si on a d'abord validé sur une config de test, bien entendu :)
-- Si non confectus non reficiat.
Nicob
On Wed, 12 Oct 2005 21:32:04 +0000, Emmanuel Florac wrote:
Je tiens effectivement à avoir le dernier mot sur un point : on ne met pas en production sans avoir validé sur une config de test, et si par hasard on le fait parfois quand on est vraiment très très pris par le temps, il faut bien être conscient qu'on est en train de travailler comme un salaud et que ce n'est certainement pas une chose à refaire.
Ca, c'est une vision idéale du processus de mise en production d'applications importantes. Mais dans la vraie vie, on est loin de rencontrer ce cas là à tous les coups. Par exemple, même quand il existe des environnements de recette, on est souvent assez loin de la config de prod (par exemple l'absence de hardenning).
Et les copies montées en labo pour faire les audits et/ou tests intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des applis Web un peu plus complexes (LDAP, load-balancing, Oracle, reverse-proxy, ...) et c'est impossible pour des très grosses applications ayant vu le jour il y a plus de 15 ans (typiquement chez les banques et très grands comptes) et reposant sur une tonne de hard/soft très hétérogène.
Nicob
On Wed, 12 Oct 2005 21:32:04 +0000, Emmanuel Florac wrote:
Je tiens effectivement à avoir le dernier mot sur un point : on ne met
pas en production sans avoir validé sur une config de test, et si par
hasard on le fait parfois quand on est vraiment très très pris par le
temps, il faut bien être conscient qu'on est en train de travailler comme
un salaud et que ce n'est certainement pas une chose à refaire.
Ca, c'est une vision idéale du processus de mise en production
d'applications importantes. Mais dans la vraie vie, on est loin de
rencontrer ce cas là à tous les coups. Par exemple, même quand il
existe des environnements de recette, on est souvent assez loin de la
config de prod (par exemple l'absence de hardenning).
Et les copies montées en labo pour faire les audits et/ou tests
intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des
applis Web un peu plus complexes (LDAP, load-balancing, Oracle,
reverse-proxy, ...) et c'est impossible pour des très grosses
applications ayant vu le jour il y a plus de 15 ans (typiquement chez les
banques et très grands comptes) et reposant sur une tonne de hard/soft
très hétérogène.
On Wed, 12 Oct 2005 21:32:04 +0000, Emmanuel Florac wrote:
Je tiens effectivement à avoir le dernier mot sur un point : on ne met pas en production sans avoir validé sur une config de test, et si par hasard on le fait parfois quand on est vraiment très très pris par le temps, il faut bien être conscient qu'on est en train de travailler comme un salaud et que ce n'est certainement pas une chose à refaire.
Ca, c'est une vision idéale du processus de mise en production d'applications importantes. Mais dans la vraie vie, on est loin de rencontrer ce cas là à tous les coups. Par exemple, même quand il existe des environnements de recette, on est souvent assez loin de la config de prod (par exemple l'absence de hardenning).
Et les copies montées en labo pour faire les audits et/ou tests intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des applis Web un peu plus complexes (LDAP, load-balancing, Oracle, reverse-proxy, ...) et c'est impossible pour des très grosses applications ayant vu le jour il y a plus de 15 ans (typiquement chez les banques et très grands comptes) et reposant sur une tonne de hard/soft très hétérogène.
Nicob
Emmanuel Florac
Le Wed, 12 Oct 2005 23:01:09 +0000, Nicob a écrit :
Ca, c'est une vision idéale du processus de mise en production d'applications importantes. Mais dans la vraie vie, on est loin de rencontrer ce cas là à tous les coups. Par exemple, même quand il existe des environnements de recette, on est souvent assez loin de la config de prod (par exemple l'absence de hardenning).
Ah ça, on peut faire des compromis, mais de là à utiliser le système de prod pour les tests, il y a un monde!
Et les copies montées en labo pour faire les audits et/ou tests intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des applis Web un peu plus complexes (LDAP, load-balancing, Oracle, reverse-proxy, ...) et c'est impossible pour des très grosses applications ayant vu le jour il y a plus de 15 ans (typiquement chez les banques et très grands comptes) et reposant sur une tonne de hard/soft très hétérogène.
Je suis d'accord. Mais aujourd'hui quand on fait de la mise en place d'applications, le cas que tu mentionnes est très minoritaire, n'est ce pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Wed, 12 Oct 2005 23:01:09 +0000, Nicob a écrit :
Ca, c'est une vision idéale du processus de mise en production
d'applications importantes. Mais dans la vraie vie, on est loin de
rencontrer ce cas là à tous les coups. Par exemple, même quand il
existe des environnements de recette, on est souvent assez loin de la
config de prod (par exemple l'absence de hardenning).
Ah ça, on peut faire des compromis, mais de là à utiliser le système
de prod pour les tests, il y a un monde!
Et les copies montées en labo pour faire les audits et/ou tests
intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des
applis Web un peu plus complexes (LDAP, load-balancing, Oracle,
reverse-proxy, ...) et c'est impossible pour des très grosses
applications ayant vu le jour il y a plus de 15 ans (typiquement chez les
banques et très grands comptes) et reposant sur une tonne de hard/soft
très hétérogène.
Je suis d'accord. Mais aujourd'hui quand on fait de la mise en place
d'applications, le cas que tu mentionnes est très minoritaire, n'est ce
pas?
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Wed, 12 Oct 2005 23:01:09 +0000, Nicob a écrit :
Ca, c'est une vision idéale du processus de mise en production d'applications importantes. Mais dans la vraie vie, on est loin de rencontrer ce cas là à tous les coups. Par exemple, même quand il existe des environnements de recette, on est souvent assez loin de la config de prod (par exemple l'absence de hardenning).
Ah ça, on peut faire des compromis, mais de là à utiliser le système de prod pour les tests, il y a un monde!
Et les copies montées en labo pour faire les audits et/ou tests intrusifs, ça marche impeccable pour des LAMP, ça se complique pour des applis Web un peu plus complexes (LDAP, load-balancing, Oracle, reverse-proxy, ...) et c'est impossible pour des très grosses applications ayant vu le jour il y a plus de 15 ans (typiquement chez les banques et très grands comptes) et reposant sur une tonne de hard/soft très hétérogène.
Je suis d'accord. Mais aujourd'hui quand on fait de la mise en place d'applications, le cas que tu mentionnes est très minoritaire, n'est ce pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Simon Marechal
Emmanuel Florac wrote:
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons sérieux.
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Emmanuel Florac wrote:
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons
sérieux.
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le
genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Mais bien sûr. Un z/OS ça se casse la gueule si facilement? soyons sérieux.
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Emmanuel Florac
Le Thu, 13 Oct 2005 09:44:40 +0000, Simon Marechal a écrit :
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que c'était des machines ultra-fiables, avec une qualité de service sans faille, redondantes, et tout et tout. Et après on planterait toute la babasse avec un nmap sur une VM? Même un windows95 supporte un nmap. J'aimerais des détails...
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Thu, 13 Oct 2005 09:44:40 +0000, Simon Marechal a écrit :
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le
genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que
c'était des machines ultra-fiables, avec une qualité de service sans
faille, redondantes, et tout et tout. Et après on planterait toute la
babasse avec un nmap sur une VM? Même un windows95 supporte un nmap.
J'aimerais des détails...
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Thu, 13 Oct 2005 09:44:40 +0000, Simon Marechal a écrit :
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que c'était des machines ultra-fiables, avec une qualité de service sans faille, redondantes, et tout et tout. Et après on planterait toute la babasse avec un nmap sur une VM? Même un windows95 supporte un nmap. J'aimerais des détails...
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Kevin Denis
Le 12-10-2005, Emmanuel Florac a écrit :
Souvent, c'est juste une question de moyens...
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la possibilité d'avoir un vieux PC pour tester une config serveur.
et si le test consiste a connaitre la reaction en charge de la machine, un vieux tromblon ne fera _pas_ l'affaire. Exemple sur les bases de donnees: si tu cherches a modifier des parametres du moteur de la BDD, il vaut mieux reproduire a l'exact le cas reel. Un quadruple jointure n'a rien a voir entre trois et un million d'enregistrements.
Le tromblon, c'est bon pour decouvrir les softs; pour regarder les differences entre samba3 et samba2, ca va le faire. Pour apprecier un gain en performance, le banc test commence a se complexifier enormement. On retombe dans une problematique de moyens (temps, argent, personnes).
-- Kevin
Le 12-10-2005, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
Souvent, c'est juste une question de moyens...
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la
possibilité d'avoir un vieux PC pour tester une config serveur.
et si le test consiste a connaitre la reaction en charge de la
machine, un vieux tromblon ne fera _pas_ l'affaire.
Exemple sur les bases de donnees: si tu cherches a modifier des
parametres du moteur de la BDD, il vaut mieux reproduire a l'exact
le cas reel. Un quadruple jointure n'a rien a voir entre trois
et un million d'enregistrements.
Le tromblon, c'est bon pour decouvrir les softs; pour regarder
les differences entre samba3 et samba2, ca va le faire. Pour
apprecier un gain en performance, le banc test commence a se
complexifier enormement. On retombe dans une problematique de
moyens (temps, argent, personnes).
Oui, bof bof. Les PMEs qui ont peu de moyen ont quand même la possibilité d'avoir un vieux PC pour tester une config serveur.
et si le test consiste a connaitre la reaction en charge de la machine, un vieux tromblon ne fera _pas_ l'affaire. Exemple sur les bases de donnees: si tu cherches a modifier des parametres du moteur de la BDD, il vaut mieux reproduire a l'exact le cas reel. Un quadruple jointure n'a rien a voir entre trois et un million d'enregistrements.
Le tromblon, c'est bon pour decouvrir les softs; pour regarder les differences entre samba3 et samba2, ca va le faire. Pour apprecier un gain en performance, le banc test commence a se complexifier enormement. On retombe dans une problematique de moyens (temps, argent, personnes).
-- Kevin
Simon Marechal
Emmanuel Florac wrote:
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que c'était des machines ultra-fiables, avec une qualité de service sans faille, redondantes, et tout et tout. Et après on planterait toute la babasse avec un nmap sur une VM? Même un windows95 supporte un nmap. J'aimerais des détails...
Que je ne peux donner, puisque c'était en mission. En plus je ne connaissais pas la version exacte de l'os, seulement que c'était du z/os (et donc pas du os390, l'ancetre). Le nmap était un -sS -T Aggressive. La mainframe était derriere un firewall qui bloquait genre 4 ports.
Les mainframes ne plantent jamais quand on les laisse tourner bien tranquille dans leur coin. Mais c'est le cas de beaucoup d'os.
Mais leur pile tcp/ip sent le truc à l'arrache, les admins connaissant vraiment bien cet os sont rares, et les configurations rencontrées sont loin des standards de sécurité (par exemple accès via telnet, couplé avec un serveur snmp qui donne le netstat par exemple).
J'en déduis donc que dans un environnement réseau hostile, le z/os doit planter bien souvent.
Perso, je ne risque pas de lancer à nouveau un nmap et encore moins un nessus sur une mainframe, sauf si le client me fait une authorisation écrite.
Emmanuel Florac wrote:
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le
genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que
c'était des machines ultra-fiables, avec une qualité de service sans
faille, redondantes, et tout et tout. Et après on planterait toute la
babasse avec un nmap sur une VM? Même un windows95 supporte un nmap.
J'aimerais des détails...
Que je ne peux donner, puisque c'était en mission. En plus je ne
connaissais pas la version exacte de l'os, seulement que c'était du z/os
(et donc pas du os390, l'ancetre). Le nmap était un -sS -T Aggressive.
La mainframe était derriere un firewall qui bloquait genre 4 ports.
Les mainframes ne plantent jamais quand on les laisse tourner bien
tranquille dans leur coin. Mais c'est le cas de beaucoup d'os.
Mais leur pile tcp/ip sent le truc à l'arrache, les admins connaissant
vraiment bien cet os sont rares, et les configurations rencontrées sont
loin des standards de sécurité (par exemple accès via telnet, couplé
avec un serveur snmp qui donne le netstat par exemple).
J'en déduis donc que dans un environnement réseau hostile, le z/os doit
planter bien souvent.
Perso, je ne risque pas de lancer à nouveau un nmap et encore moins un
nessus sur une mainframe, sauf si le client me fait une authorisation
écrite.
Selon l'age du mainframe un nmap suffit. Et comme c'est typiquement le genre de truc qui pourri dans son coin sans jamais être mis à jour ...
Je ne pratique pas le z/OS, mais j'ai été élevé dans la croyance que c'était des machines ultra-fiables, avec une qualité de service sans faille, redondantes, et tout et tout. Et après on planterait toute la babasse avec un nmap sur une VM? Même un windows95 supporte un nmap. J'aimerais des détails...
Que je ne peux donner, puisque c'était en mission. En plus je ne connaissais pas la version exacte de l'os, seulement que c'était du z/os (et donc pas du os390, l'ancetre). Le nmap était un -sS -T Aggressive. La mainframe était derriere un firewall qui bloquait genre 4 ports.
Les mainframes ne plantent jamais quand on les laisse tourner bien tranquille dans leur coin. Mais c'est le cas de beaucoup d'os.
Mais leur pile tcp/ip sent le truc à l'arrache, les admins connaissant vraiment bien cet os sont rares, et les configurations rencontrées sont loin des standards de sécurité (par exemple accès via telnet, couplé avec un serveur snmp qui donne le netstat par exemple).
J'en déduis donc que dans un environnement réseau hostile, le z/os doit planter bien souvent.
Perso, je ne risque pas de lancer à nouveau un nmap et encore moins un nessus sur une mainframe, sauf si le client me fait une authorisation écrite.
