Salut Patrice,
je passe en discussion privée, je pense que l'enfilade doit commencer à
lasser sur la ML
Patrice Karatchentzeff a écrit :
> Le 19 mai 2008 20:42, Olivier Allard-Jacquin <olivieraj@???> a écrit :
>> Patrice Karatchentzeff a écrit :
>
> [...]
>
>> Raison pour laquelle je disais dans mon précédent mail que dans le cas
>> d'une entreprise qui self-signait ses sites, il fallait commencer par
>> importer MANUELLEMENT le certificat dans le PC des utilisateurs de
>> l'entreprise. Ou à déclarer le serveur du site comme étant une entité de
>> certification de confiance.
>
> Là, tu rêves si tu crois un instant que cela est fait...
Mauvais admin, changer admin... Ce n'est pas pour autant que cette
technique n'est ni fiable, ni sécurisée.
> et crois-moi,
> des entreprises, j'ai en fait un paquet depuis des années. Seuls les
> postes serveurs sont vaguement configurés. Les postes clients sont
> soit fournis tels quels, soit personnalisés de façon bizarre mais pas
> dans cette optique (cf. une grande entreprise de télécomnunication
> française qui se reconnaitra).
FT pour qui tu bosses(ais ?).
De ce que je comprends, tu parles d'utilisation de HTTPS self-signée au
sein d'un réseau d'entreprise lui-même ? Tant que cela ne sort pas d'un
LAN (même si il fait plusieurs milliers de kms), le risque est quand
même super faible, pour qu'un utilisateur s'amuse à spoofer l'IP d'un
serveur, et à faire une attaque de type "man in the middle", tu ne crois
pas ?
>> C'est le boulot du DSI, et il peut le faire avant de fournir les
>> machines à ses utilisateurs.
>
> Comme la sécurité.
>
>>> Or, c'est la majorité des sites sur Internet.
>> On parle de quel sites là ?
>
> Évidemment pas des sites bancaires, qui représentent un millionnième
> des sites sur Internet ni certainement ceux qui ont les moyens de se
> payer tout cela (comme il doit y avoir les sites de cul dans cette
> catégorie, cela doit faire monter les statistiques).
On est bien d'accord.
> Pour les autres,
> tous les sites associatifs, voire universitaires, c'est la règle.
> Personne ne se payent un certificat chez Verisign pour le plaisir de
> faire du https.
Et pour ces sites-là, tu crois VRAIMENT que la nécessité du HTTPS se
justifie ? Voir, que le fait que les sites self-signed risquent une
attaque de type "man in the middle" ?
Tu crois vraiment que quelqu'un va monter une structure TRES lourde(*)
en amont du site de la Guilde, histoire de piquer mes transaction sur
"gallete" : http://www.guilde.asso.fr/galette/ (**)
(*): Rappel: Pour attaquer un site self-signed, il faut quand même
détourner les requêtes DNS du client, afin de faire passer le faux site
HTTPS pour le vrai. Dans le cas de nos connexions ADSL respectives, cela
revient à spoofer les DNS de Free. Et ca, seul Free peut y arriver...
(**): Zut, ce c... là n'est même pas en HTTPS, je vais me plaindre à
Christian !! :)
> [...]
>
>>> Oui, c'est idiot. Le B-A BA de la sécurité consiste à pouvoir
>>> CONTRÖLER ce qui se passe d'un point A vers un point B. En
>>> authentifiant CERTAINEMENT A et B. Or, c'est une chose pratiquement
>>> impossible à faire avec des logiciels closed-source (que l'on ne peut
>>> compiler). Windows en fait partie. Déployer Windows en entreprise et
>>> ensuite parler de sécurité revient dans ce cas à tirer au FM dans une
>>> foule compacte et demander ensuite aux gens de mettre des gilets
>>> par-balles pour éviter les morts.
>> Sympa ta métaphore ;)
>>
>> D'un autre coté, l'open-source n'est pas un gage de sécurité, quand on
>
> C'est marrant ta manie de rebondire sur un argument que je n'ai pas avancé.
Je rebondis simplement sur l'argument que tu sous-entends.
> J'ai affirmé (en résumé) que le propriétaire closed-sourdce était un
> gage d'insécurité et tu relances comme si j'affirmais que
> l'Open-Source (avec les majuscules, sinon, on n'a pas les garantie ad
> hoc) était un gage de sécurité.
>
> Alors, je l'écris en majuscule si tu n'as pas compris: l'oPEN-sOURCE
> EST UNE CONDITION SINE QUA NON DE SÉCURITÉ, pas un gage de sécurité.
Parce qu'accéder au code source apporte de la sécurité ? Je pense que
tu oublies plusieurs choses, à commencer par le fait que le code doit
être audité régulièrement, par des personnes qualifiés, les binaires
éprouvés par des batteries de tests, etc...
Dans le cas du bug de Debian qui nous préoccupe, le fait que le code
d'OpenSSL soit open-source n'a pas du tout contribuer à la sécurité de
la distribution. Elle l'a même empiré : Si le code n'avait pas été open
source, le packageur n'aurait jamais pu mettre une ligne en commentaire,
et réduite à 2^15 l'initialisation du générateur aléatoire.
Je me fais l'avocat du diable en disant ca (et ca me fait suer), mais
le fait de rejeter en bloc les softs closed-source en disant qu'ils en
sont pas sécurisés, est un peu rapide.
Sur ce coup-là, le contre-exemple de ce bug de Debian ne sert pas ton
propos.
>> voit comment le bug qui nous concerne ici est arrivé. Il a suffit de
>> l'action d'une seule personne, échangeant 3 mails parmi des dizaines de
>> milliers d'une liste de distribution, pour corrompre la sécurité de
>> plusieurs distributions Linux majeurs. Et ce, pendant 2 ans...
>
> Et alors ? Encore une fois, c'est de la poudre aux yeux que tout
> cela... un bogue, c'est toujours une idiotie. Qu'elle soit pointue ou
> bête, la conséquence est toujours importante quand la sécurité est
> touchée. Quelle importance que le bogue se cache dans le tréfond d'une
> fonction inconnue ou bien soit d'une évidence crasse ?
L'importance, c'est que cela montre la limite de la politique de Debian
à patcher lourdement les softs qu'il intègre dans ses paquets. A
t'entendre dans tes différentes mails, Debian c'est mieux que les autres
distributions, parce que tout est "ouvert", tout est publique. Ce bug
montre que cette ouverture ne suffit pas, que ce n'est pas un gage de
qualité, et que des *gros* bugs peuvent intervenir.
Tu te souviens de notre discussion à propos de IceWeasel/IceDove. Tu
disais que grâce à cela, Debian apportait plus de sécurité que
Firefox/Thunderbird.
Et bien si l'équipe qui s'occupe de IceWeasel/IceDove fait les mêmes
boulettes que celui du paquet OpenSSL, cela ne va pas être triste.
Il a fallut 2 ans, DEUX ans !!!, pour que Debian découvre le pot aux
roses pour le problème de OpenSSL. Si un faille similaire a été rajouté
par Debian à IceWeasel/IceDove, il faudra combien de temps pour la
découvrir ?
> La seule garantie dans ce cas que l'on a est que le modèle de
> développement de Debian permet la chose la plus importante dans ce cas
> : COMMUNIQUER. Tous les admins sont au courant, savent de quoi il en
> retourne, et ce qu'ils doivent faire. Ils ont donc une RÉPONSE
> possible.
Super oui !
- Debian: "Les gars, on a introduit un bug majeurs dans tout vos
serveurs qui tournent depuis 2 ans. Mais rassurez-vous, il existe une
solution"
- Admin système: "Ouaip ! Super ! Merci Debian ! Mais à la rigueur, on
aurait préféré qu'il n'y ait pas de bug..."
> Compare maintenant avec les autres modèles et pleure si tu es admin...
> ha, non, tu n'en sais rien en fait et tu ne peux rien en faire donc on
> en parle pas.
J'aurais eu une RedHat ou une Mandriva, je n'aurais pas eu ce bug-là. A
la rigueur, j'aurais préféré...
Que ce soit le développeur du soft/librairie qi fasse une erreur, cela
arrive.
Que ce soit le packageur d'une distrib, qui introduise un bug, surtout
pour une raison aussi peu crutial (éviter que Valgrine de râle), c'est
plus grave.
> [...]
>
>> Et pour beaucoup d'entreprises, cela suffit largement.
>
> MDR. Le modèle choisi est le plus cher et le moins performant... pas
> mal comme suffisance...
Et les modèles complètement sécurisé n'existent pas...
>> Pour en revenir avec la sécurité sous Debian, j'ai lu ceci :
>> http://linuxfr.org/comments/931785.html#931785
>
> Et alors ? T'as un gars pas content qui s'en va ?
Ca, on s'en tape...
> Je lui souhaite bon
> courage... il administre (soit-disant) 100 serveurs sous Debian et
> veut les passer sous RH. Bonne chance. Moi, je n'essaierai même pas
> mais chacun son truc. Personnellement, je n'ai que quelques serveurs
> sous RH et cela suffit à me faire perdre la majorité de mon temps...
Vu le temps que j'ai mis à comprendre les mécanismes particuliers de
Debian, je dirais que la transition d'une distribution Linux à une autre
n'est jamais une chose facile. Tu râles tout le temps à propos de ton
boulot sur des RH, mais est-ce que tu n'essayes pas d'administrer une RH
avec une manière de penser de Debianiste ?
Personnellement, j'ai voulu administrer des Ubuntu et des Debian en me
référant à mes habitudes de Mandrivien, et je dois dire que cela n'a pas
été triste tout les jours.
Debian et les autres distributions font les choses différemment, et
contrairement à ce que tu penses, Debian ne fait pas toujours les
meilleurs choix.
Pour la gestion des paquets par exemple, un élément centrale de la
distribution, et un domaine sur lequel Debian excelle soit-disant (avec
des .deb), ce sont les paquets. Et bien, la présence à la fois d'"apt"
et d'"aptitude" est UNE HONTE. Sachant que les deux ne sont pas
compatibles entre eux à 100% (on ne peut pas gérer sainement une Debian
en utilisant à la fois "apt" et "aptitude"), Debian aurait dûs depuis
longtemps virer apt au profits d'aptitude.
Remarque : Je n'utilise JAMAIS "aptitude" en mode "ncurse", donc mon
discours n'est pas lié à l'interface semi-graphique.
> mais mon employeur préfère me payer à faire un boulot idiot plutôt
> qu'un boulot intelligent : c'est son problème et il est au courant. Il
> assume : j'ai fait mon boulot en le prévénant.
>
> Debian a des défauts ? Sans blague ?
Tu le reconnais, c'est déjà ca... ;)
> [...]
>
>>> Où as-tu vu que je minimisais quoique ce soit ?
>> <extrait de *ton* mail du 16.05.2008 13:56>
>> bof... c'est un n-ième trou de sécurité et ça ne changera rien du tout
>> : 99% (et je suis gentil) des gens n'y comprennent rien.
>> </extrait>
>>
>> <extrait de *ton* mail du 16.05.2008 13:56>
>> Donc, AMHA, à part les geeks qui aiment bien se tirer dessus sur les
>> listes et autres fora, il y a peu de chance que cela ait le moindre
>> impact.
>> </extrait>
>>
>>> Ces failles sont
>>> graves, très graves mêmes mais contrairement à ce qui se fait
>>> ailleurs, il y a une énorme publicité faite autour pour y rémédier,
>>> avec une solution ad hoc.
>
> Voilà, où est la minimisation avec ce dernier paragraphe ?
Tu n'as pas écris ce commentaire dans le même mail que les deux premiers.
>> Solution ad-hoc qui nécessite de reconfigurer toutes les machines
>> clientes et serveurs, afin 1) de générer de nouveau toutes les clefs et
>> 2) de recréer les "authorized_keys" ... Sympa comme solution...
>>
>> A peine pénible à déployer...
>
> Pauvre chou... il faut arrêter de déconner... je sais bien qu'à force
> d'avoir des machines qui s'installent toutes seules, qui se
> configurent toute seules et qui font le café le matin, les sys-admins
> ont un poil dans la main qui a grossi mais il faut arrêté de fumer la
> moquette : la boulot d'un sys-admin, c'est de pallier les problèmes
> quand il se présentent...
Le problème n'est pas le poil dans la main. Le problème, c'est
l'insécurité que le bug a apporté *pendant* 2 ans, et qu'il faut
maintenant fermer en urgence tous les serveurs SSH, et les
identifications par clés. C'est pas l'ampleur du boulot qui est
inquiétant, c'est :
- le fait que ce soit super critique pour la sécurité
- que le bug ne peut pas se résoudre en 5 minutes, en lançant à distance
une commande. Il faut refaire toutes les identifications des
machines/utilisateurs, au risque que les mécanismes automatiques,
transfert de fichiers entre serveurs par exemple, soit interrompus.
Combien est-ce que tu pari que bon nombre de sysadmin ne vont pas
pouvoir corriger ce problème dans la semaine, et que pour des raison de
prod et de risque de régression de fonctionnalité, les clés SSH ne
soient pas modifiées avant xx mois ? Et pendant ce temps là, la faille
reste.
> Et on ne peut même pas dire que le problème est complexe : on sait
> tout de A à Z et ce qu'il fait faire pour les résoudres. Alors,
> franchement, c'est du temps et cela partie du boulot.
Ce n'est pas que la complexité qui pose problème. Le problème, c'est :
- l'ampleur des fonctionnalités impactés (SSL est utilisé à plein de
niveaux, SSH et HTTPS n'en sont que des exemples)
- que c'est un *mécanisme* complet de sécurité qui tombe, un truc sur
lequel on pouvait s'appuyer(*), et qui était réputé pour sa fiabilité.
Accessoirement, l'équipe de SSL doit un peu avoir les boules de voir que
son boulot a été tout "salopé" par Debian...
(*): L'identification par clés a plusieurs avantages par rapport à celle
du mot de passe, et de ce fait, est plus sécurisé :
- la machine serveur, via sa clé, peut être identifiée de manière sûr
- la machine cliente, via sa clé, peut être identifiée de manière sûr
- le compte de l'utilisateur (son "~/.ssh/" en fait) est identifiée de
manière sûr
- l'usage de la clé peut-être restreint à l'utilisateur en lui-même, si
celui-ci l'a générée avec une "passphrase"
- enfin, le chiffrement DSA des clés SSL est plus fiable que la
technique MD5 utilisée dans le /etc/shadow (le chiffrage MD5 a été cassé
il y a quelques années).
> Sinon, pour ceux que cela n'intéresse pas, il existe d'autres boulots
> moins stressants.
Nan, tu crois ? ;)
>> La solution, c'est quand même pas un simple "aptitude update &&
>> aptitude full-upgrade" quand même !!!
>
> C'est à peine plus compliqué : faut arrêter... changer des clés ! mon
> dieu, quelle difficulté... en plus, ce n'est pas scriptable !
Je crois que tu n'as pas une grosse idée de ce que l'on peut faire avec
ces clés...
> [...]
>
>> Dans mon (humble) cas où je suis affecté par ce problème, j'ai dûs
>> fermé le service que je propose (prise en main à distance pour les
>> utilisateurs dont j'assume le support informatique), en attendant de
>> contacter individuellement chacun d'entre eux, afin de restauré le
>> service. Et comme ils n'y connaissent RIEN en informatique, et qu'il est
>> hors de question que je leur fasse taper la moindre commande, je vais
>> pas mal m'amuser...
>
> T'es sys-admin, t'assumes. Fallais pas proposer tes services si tu
> n'es pas capable d'assumer. Cela fait partie du service après-vente.
Accessoirement, je fais cela à titre gracieux, et en-dehors du boulot.
> Et quitte à en remettre une couche, c'est un choix que tu as fait :
> j'administre un certain nombre de postes comme toi et je n'ai pas ces
> soucis. En privé et en entreprise. Tu as fait des choix techniques
> pour le faire, tu assumes.
OK, puisque tu le prends comme cela, je vais te parler de mes choix :
- toi, tu installes des serveurs SSH sur les postes que tu administres,
et tu te loggues dessus avec un mot de passe. N'est-ce pas ?
- 2 problèmes : Tu dois ouvrir un trou dans le firewall, voir dans le
routeur ADSL, et tu laisses un port (disons le 22) ouvert. Ce sont donc
2 failles de sécurité potentielles.
- pour ma part, j'utilise la technique du SSH callback, décrite dans les
pages 37 et + de ma dernière conférence :
http://www.guilde.asso.fr/rencontres/20080409/prise_de_controle_a_distance_avec_linux.odp
- avec cela, chez mes utilisateurs il y a ZERO trou dans les
firewalls/routeurs, et ZERO ports SSH ouverts sur l'interface réseau
Internet. SSH ne tourne que sur le loopback de la machine cliente.
- et enfin, c'est l'utilisateur qui décide de me donner la main sur sa
machine, et non pas l'inverse. Ainsi, il n'a pas à craindre que je me
connecte "discrètement" chez lui.
- mes choix sont donc plus sécurisés que les tiens, et ne présente AUCUN
risque pour l'utilisateur, même dans les pires conditions (le firewall
tombe, ou la Freebox passe brutalement du mode routeur au mode bridge,
comme cela lui arrive parfois)
- le problème, c'est que ce modèle s'appuie fortement sur l'utilisation
de clés SSH. A cause d'une petite ligne de code mise en commentaire par
Debian, ce mécanisme tombe.
- bon, je dramatise un peu, car le seul qui soit réellement impacté en
terme de sécurité, c'est ma machine. Et que j'ai bien évidement
interrompu ce service dès l'annonce du problème sur les ML Debian.
Cordialement;
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
