Re: Trou de securite Debian pour SSH/SSL

トップ ページ

このメッセージに返信
著者: Patrice Karatchentzeff
日付:  
To: guilde
CC: guilde
題目: Re: Trou de securite Debian pour SSH/SSL
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... 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).

>        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). 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.

[...]

>> 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é.

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é.

Et il y en un paquet d'autres de conditions, si l'on veut faire de la
sécurité en entreprise : cela passe par une bonne formation des
utilisateurs à une (très) juste rémunération des salaires par
exemple...

> 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 ?

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.

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.

[...]

>        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...

>        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 ? 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...
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 ?

[...]

>> 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 ?

>        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...

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.

Sinon, pour ceux que cela n'intéresse pas, il existe d'autres boulots
moins stressants.

>        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 !

[...]

>        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.

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.

PK

--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:p.karatchentzeff@free.fr
|,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr
'---''(_/--' `-'\_)