Bon bien déjà toutes mes excuses à NCSA MOSAIC et SPYGLASS pour des raisons malheureusement évidentes ainis qu'à Hummingbird,RSA,Mainsoft,OPEN solutions et au JPEG GROUP; et ensuite aux lecteurs de ce thread que j'ai privé d'une fin de phrase bien mérité.
donc
Le problème des produits MS n'est pas tant un travail de sécurisation a faire à postériori (en d'autres termes une forme perverse de débuggage) mais un problème d'architecture. Pour l'instant en tant qu'admin d'une bécanne on ne se pose pas du tout les même problèmes. Sous OpenBSD on se dit "Je vais installer tel soft comment faire pour que ma machine reste secure ?". Sous Windows la question est plutot "Je vais installer tel soft comment faire pour boucher les failles ?". Le pire c'est *nix permet d'implementer des solutions Microsoft beaucoup plus proprement qu'eux. Un cas extrème étant un serveur NFS sur lequel personne ne peut se loguer en mode terminal avec le demon NFS lancé via script par nobody. Ces disques NFS sont montés par un autre *nix et redistribués en Samba. Ben si je dit sur la première machine ce fichier est en lecture seule je vois mal comment qui que ce soit peut l'effacer ou l'executer. Je cherche encore depuis des années a faire la même chose en pur windows...
Exemple plus simple une machine avec deux cartes réseaux déclarée sous deux noms différents avec deux adresses IP sur le même réseau. Temps mis pour qu'un démon *nix n'écoute que les infos venant d'une des deux cartes : 2 minutes. Sous windows plusieurs heures, des logiciels externes et aucune assurance que ca ne transpirera pas.
(Cas typique : appache n'accepte pas les demandes de login sur certaines pages si elle ne viennent pas de la bonne carte, mais sert les pages "publiques" sur les deux. Sous IIS amusez vous bien les gars, il y a moyen mais c'est assez drole a faire).
Ceci étant promis je ne ferais plus de postes à la va vite depuis mon boulot, un accident est si vite arrivé :).
[^] # Re: OpenBSD et Microsoft pareil sauf que....
Posté par Jerome Herman . En réponse à la dépêche "la prochaine version de notre serveur (.Net) sera sûre par défaut". Évalué à 5.
donc
Le problème des produits MS n'est pas tant un travail de sécurisation a faire à postériori (en d'autres termes une forme perverse de débuggage) mais un problème d'architecture. Pour l'instant en tant qu'admin d'une bécanne on ne se pose pas du tout les même problèmes. Sous OpenBSD on se dit "Je vais installer tel soft comment faire pour que ma machine reste secure ?". Sous Windows la question est plutot "Je vais installer tel soft comment faire pour boucher les failles ?". Le pire c'est *nix permet d'implementer des solutions Microsoft beaucoup plus proprement qu'eux. Un cas extrème étant un serveur NFS sur lequel personne ne peut se loguer en mode terminal avec le demon NFS lancé via script par nobody. Ces disques NFS sont montés par un autre *nix et redistribués en Samba. Ben si je dit sur la première machine ce fichier est en lecture seule je vois mal comment qui que ce soit peut l'effacer ou l'executer. Je cherche encore depuis des années a faire la même chose en pur windows...
Exemple plus simple une machine avec deux cartes réseaux déclarée sous deux noms différents avec deux adresses IP sur le même réseau. Temps mis pour qu'un démon *nix n'écoute que les infos venant d'une des deux cartes : 2 minutes. Sous windows plusieurs heures, des logiciels externes et aucune assurance que ca ne transpirera pas.
(Cas typique : appache n'accepte pas les demandes de login sur certaines pages si elle ne viennent pas de la bonne carte, mais sert les pages "publiques" sur les deux. Sous IIS amusez vous bien les gars, il y a moyen mais c'est assez drole a faire).
Ceci étant promis je ne ferais plus de postes à la va vite depuis mon boulot, un accident est si vite arrivé :).
Kha