Bonsoir Patrice,
Patrice Karatchentzeff a écrit :
> Le 16 mai 2008 17:07, Olivier Allard-Jacquin <olivieraj@???> a écrit :
>> Patrice Karatchentzeff a écrit :
>
> [...]
>
>>> Je dis que la sécurité est souvent le dernier souci des admins (preuve
>>> : la multiplicité des certificats self-signed) donc ils ne sont pas à
>>> cela près.
>> Un certificat self-signed, n'est pas moins bon qu'un certificat signée,
>> tant en terme d'authentification qu'en terme de chiffrement :
>
> Ça n'a rien à voir avec ce que je disais...
>
> Ce n'est pas à toi que j'apprendrai que la sécurité d'un système
> repose sur l'élément le plus faible de la chaîne de sécurité.
Tout à fait
> Si un
> DSI décide de chiffrer un protocole, quel que soit les raisons, c'est
> pour blinder la chose.
Oui
> Que penseront (je sais bien qu'un utilisateur
> ne pense pas à ces choses là) les utilisateurs qui ne pourront même
> pas s'assurer que le certificat est issu d'un site dît de confiance ?
> Le B-A-BA de la chaîne de sécurité n'étant pas respecté, tu peux
> certifier comme tu veux avec autant de bits et d'algorithme matheux
> ton certificat, ton truc ne vaut pas un clou.
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.
C'est le boulot du DSI, et il peut le faire avant de fournir les
machines à ses utilisateurs.
> Or, c'est la majorité des sites sur Internet.
On parle de quel sites là ?
- des sites "importants", ou le chiffrement des données est crucial,
comme les banques en ligne, le site des impôts, etc... Ces sites-là
utilisent déjà des services d'une autorité de certification externe, du
genre de VeriSign
- des entreprises qui fournissent des services à leurs employés via du
HTTPS, comme par exemple un webmail chiffré ? La configuration manuel de
l'entité de certification (comme expliqué plus haut) marchera très bien
- des sites qui fournissent du https "juste pour le fun", comme
"
http://linuxfr.org/" par exemple ? A charge des utilisateurs de ces
sites de décider si, oui ou non, ils veulent échanger des contenus
sensibles avec des sites non signes.
Personnellement, pour les sites que je visite régulièrement, je ne
rencontre pas de site dont le HTTPS se justifie, et qui sont self-signed.
Quand tu dis "c'est (les sites sites self-signed) la majorité des sites
sur Internet", est-ce que tu peux donner des exemples concrets de site
dont le HTTPS soit nécessaire et qui sont self-signed ?
> [...]
>
>>> Si la sécurité avait ne serait-ce qu'un peu d'importance, personne
>>> n'utiliserait Windows en entreprise par exemple.
>> C'est amusant, c'est la 2nd fois que tu ramènes tout de MS/Windows dans
>> cette discussion... ;) Tu veux détourner la conversation ? ;)
>
> humour facile mais totalement inapproprié.
>
> On parle de sécurité donc sérieusement. Même si le sujet n'est PAS
> généralement abordé sérieusement en entreprise.
>
>> <humour mode="facile">
>> Et à la place des Windows, tu mettrais quoi en entreprise ? Des
>> machines sous Debian, qui *ELLES* sont tout à fait irréprochable en
>> terme de sécurité ?
>> </humour>
>>
>> J'avoue, elle était facile celle-là... ;)
>
> 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
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...
Pas mal pour le modèle de sécurité...
>> Dans beaucoup d'entreprises, la sécurité se limite à blinder les
>> connexions vers l'extérieur, et à séparer clairement les divers zones:
>> le LAN, le DMZ (qui gères les services "publiques" comme le serveur
>> web), et le reste du monde.
>
> Oui, dans beaucoup d'entreprises, on se limite sérieusement en effet;
Et pour beaucoup d'entreprises, cela suffit largement.
>> Après, tu évites que les machines ne se tapent trop dessus entre elles,
>> en installant des antivirus sur les postes clients.
>
> Le gilet par balles en effet...
>
>>> La sécurité est la plupart du temps qu'un concept, pas une réalité.
>> La sécurité est un compromis entre un idéal (*) et la réalité (**). De
>> là à dire que tous les gens qui administrent des machines s'en foutent
>> royalement, il y a quand même un pas.
>
> Non. Je ne te ferai pas l'injure de croire que tu ne sais pas que
> l'informatique en entreprise est généralement géré par des gens
> totalement incompétents techniquement, dont la fonction première
> consiste simplement à déployer un parapluie suffisamment large pour
> couvrir leur cul le cas échéant en cas de pépins.
Tu sais comme moi qu'en entreprise, le niveau d'incompétence technique
s'élève avec le niveau hiérarchique... ;)
Pour répondre à ta question, je dirais que ce problème de compétence
technique et de parapluie se retrouve partout en-dehors du milieu
informatique, comme par exemple avec tout ce qui touche les
responsabilités locales, départementales, régionales, nationales, etc...
Bref, c'est dans la nature humaine.
> L'administrateur n'est qu'un maillon dans la chaîne informatique de
> l'entreprise : ce n'est généralement pas lui qui décide d'une
> politique.
Tout à fait d'accord.
Pour en revenir avec la sécurité sous Debian, j'ai lu ceci :
http://linuxfr.org/comments/931785.html#931785
<extrait>
* Une intégration très à la traine (parfois inexistante) des
technologies de fiabilisation modernes, au moins dans la dernière
version dite stable : support SELinux moins que sommaire, pas
d'Exec-Shield, pas encore de version intégralement recompilée avec
-fstack-protector, pas de FORTIFY_SOURCE, pas de compilation intégrale
de l'archive avec -fPIE -pie (Position Independant Executables), pas de
restrictions de l'accès à /dev/mem, pas de ELF Data Hardening
systématique (ld -z relro), pas de support de la glibc pour les mots de
passes chiffré plus sérieusement que DES/MD5, bref, toutes ces bonnes
choses dont Red Hat, SuSE et Gentoo disposent depuis un bon moment
déjà... chez Debian, la sécurité est la 4em roue de la charrette. Si
seulement le suivi des problèmes de sécurité chez Debian était si bon
qu'il permetait de se passer de tout ça...
</extrait>
Je n'ai pas vérifié tout ces propos, mais il y en a quelques uns que
j'ai pu déjà constater.
> [...]
>
>> Mais de la à minimiser l'importance que les 2 dernières années de clefs
>> SSH/SSL générées sur des distributions populaires (Debian, Ubuntu, et
>> autres) soit des failles de sécurité, s'en ait une autre.
>
> 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.
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...
La solution, c'est quand même pas un simple "aptitude update &&
aptitude full-upgrade" quand même !!!
> Contrairement aux fameux logiciels
> closed-sources dont je parlais plus haut par exemple.
>
> Et la sécurité repose avant tout sur la réactivité, pas sur le zéro
> défaut, qui est une impossibilité technique.
Réactivité ?
*Une* ligne de code commenté, et une faille de sécurité sérieuse
injectée dans plusieurs distributions majeures. Et 2, *deux*, ans pour
trouver la faille...
Pas mal...
La réactivité n'est pas utile si tu passes ton temps à injecter des
failles partout, ou à utiliser un modèle de soft non sécurisé. Dans le
cas présent, les gars d'openSSL ont fait un boulot nickel, mais c'est le
packageur Debian qui a tout casser.
Tout ca, afin d'éviter que son débuggeur (Valgrin) ne gueule...
> Normalement, cette faille est du passé sur tous les sites « powered by
> Debian » depuis l'annonce de cette faille si les admin sont un poil
> compétent.
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...
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
