Our new platform is already available at v5.gandi.net

Go to the new Gandi



Nous sommes heureux d'annoncer que nous ne procéderons pas à l'arrêt puis démarrage de vos serveurs ce Mercredi 21 décembre, entre 6:00 et 9:00 UTC.

Notre opération de maintenance avait pour but de pallier à une vulnérabilité dans le logiciel de virtualisation Xen. Pour y répondre, nous avions décidé de mettre à jour le logiciel Xen et de profiter des fonctionnalités de la nouvelle version pour vous permettre de gagner des performances et éviter de nouvelles opérations de la sorte.

Cependant, beaucoup d'entre vous nous ont contacté pour nous demander de changer notre approche. Nous avons commencé par ajuster la plage horaire de l'opération, mais cela n'a pas suffit à nombre d'entre vous.

Par conséquent, après l'étude de solutions alternatives, nous vous confirmons que nous ne procéderons pas à l'arrêt puis démarrage de vos serveurs, et de ce fait annulons la maintenance initialement prévue. 

Tous les clients concernés ont été contactés par email directement. Nous vous remercions d'avoir été si nombreux à nous avoir fait des retours.


Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le mardi 22 novembre 2016. Les correctifs ont d'ores et déjà été communiqués à Gandi par l'équipe de Xen.

Suite à cette annonce, nous avons déployé un correctif venant s'ajouter aux mesures de sécurité mises en place au préalable. Une veille a été ménée sur cette faille de sécurité et nous avons pris la décision de procéder au redémarrage des VMs Xen concernées; assurant ainsi une suppression totale des vecteurs d'attaque potentiels.

Nous avons contacté par email tous les clients impactés pour leur permettre de réagir et d'anticiper cette opération. Dans le cas où vous n'avez pas reçu de communication par email, c'est que vous n'êtes pas concernés par cette maintenance.

Dans un soucis de maîtrise du temps d'interruption de service, mais également de gestion des services hébergés sur ces serveurs, nous recommandons grandement à tous les clients concernés de procéder à l'arrêt puis au démarrage leur plate-forme par eux-mêmes et ce, avant la date butoir du 22 novembre 2016.

 Attention, un simple redémarrage, ou "reboot", des serveurs concernés ne suffit pas à l'application des dites mesures de sécurité.

Dans le cas où les serveurs des clients notifiés par email n'ont pas été stoppée puis démarrés, ceux-ci seront automatiquement mis en maintenances par nos équipes le mardi 22 novembre à 11h00 UTC. Veuillez noter qu'une indisponibilité estimée à 30 minutes est à prévoir sur les VMs concernées lors de cette opération.

 Si vous avez des questions à ce sujet, ou rencontrez des difficultés, n'hésitez pas à contacter nos équipes Support .

 


Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le mardi 26 juillet. L'équipe de Xen a d'ores et déjà communiqué les correctifs à Gandi.

Suite à cette annonce, nous avons déployé un correctif venant s'ajouter aux mesures de sécurité mises en place au préalable. Une veille a été ménée sur cette faille de sécurité et nous avons pris la décision de procéder au redémarrage des VMs Xen concernées; assurant ainsi une suppression totale des vecteurs d'attaque potentiels. 

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services nous allons les contacter directement par email. Les clients n'ayant pas reçus de communication ne sont pas concernés.

Dans un souci de maîtrise du temps d'interruption de service, mais également de gestion des services hébergés sur ces VMs, nous recommandons grandement à tous les clients concernés de procéder au redémarrage leurs plates-formes par eux-mêmes dès maintenant et avant la date butoir du 26 Juillet 2016. Dans le cas où les VMs des clients notifiés par email n'ont pas été redémarrées, celles-ci seront redémarrées automatiquement par nos équipes entre le mardi 26 juillet 7h00 UTC et le jeudi 28 juillet 16h00 UTC. À noter qu'une indisponibilité d'un maximum de 30 minutes par VM redémarrée est à prévoir lors de cette opération. 

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Les fabuleux progrès des 80 dernières années en matière d'informatique, de réseaux et de chiffrement ont bien souvent été le fruit de la collaboration entre les militaires, le milieu universitaire et occasionnellement des entreprises du secteur privé. Ces technologies, qui ont permis de changer la manière dont l'humanité interagit, ont également créé de nombreux points de friction entre les autorités militaires, souhaitant en limiter l'utilisation à des fins sécuritaires, et les défenseurs des droits de l'homme qui en ont vite compris l'intérêt.

Lorsque Whitfield Diffie et Martin Hellman publient “New Directions in Cryptography” en 1976, ils soulignent en préambule que les communications numériques qui permettront à tous d'échanger, et pas uniquement militaires ou financiers, devront être sécurisées. Ils introduisent la notion de cryptographie à clé publique, qui permet à deux personnes qui ne se sont jamais rencontrées en face à face de communiquer confidentiellement.

Cette solution prévoit la création d'une paire de clés, l'une publique, l'autre privée, en utilisant des fonctions mathématiques. Une clé publique visible permet de chiffrer un message que seule la clé privée peut décoder. Diffie et Hellman résolvent un problème fondamental en cryptographie : la distribution des clés, mais pas leur implémentation dans un usage à sens unique.

Trois chercheurs du MIT, Ron Rivest, Adi Shamir et Leonard Adleman, se penchent alors sur la question. En avril 1977, alors qu'ils sont en vacances ensemble, Ron Rivest est victime d'une insomnie et passe une nuit entière à formaliser ce qui deviendra l'algorithme RSA, pour Rivest, Shamir et Adleman.

Les 3 amis publient leur invention en août 1977 et en déposent le brevet, au travers du MIT, en décembre. En 1982, Rivest, Shamir et Adleman créent l'entreprise RSA Security et se lancent dans la distribution de leur algorithme, au grand dam des autorités militaires.

Les outils de cryptographie ayant été longtemps inscrit à la « U.S. Munitions List », la NSA affirme dès juillet 77 que le développement privé d’outils de cryptographie tels que le chiffrement à clé publique et l’algorithme RSA constitue une menace pour la sécurité nationale.

Tandis que les années 80 voient l’outil informatique sortir des laboratoires de recherche universitaires et des bureaux du gouvernement, pour arriver dans les entreprises et chez les particuliers, un projet de loi est soumis au Parlement américain afin de restreindre l’usage public des outils de cryptographie. Phil Zimmerman, un activiste anti-nucléaire du Colorado, décide de se lancer dans un projet qu’il définira plus tard comme relatif aux droits de l’Homme : appliquer le chiffrement à clé publique aux communications par email.

En juin 1991, il lance la première version de « Pretty Good Privacy », ou PGP, qui utilise la fonction Bass-O-Matic pour chiffrer les emails. Dans la documentation, où il décrit le chiffrement comme une forme de solidarité, il écrit « Si tout le monde prenait l’habitude d’utiliser le chiffrement pour l’ensemble des emails, innocents ou pas, son usage ne serait plus suspicieux ».

Quelques heures seulement après sa mise à disposition en téléchargement, PGP est utilisé par des internautes du monde entier. Malheureusement, cette mise à disposition vaut à Zimmerman les foudres des douanes américaines et de RSA Security. Tandis que les premiers l’accusent de trafic d’armes, puisque PGP est distribué hors des frontières américaines, RSA Security le poursuit pour violation de son brevet.

Zimmerman, pour contrer les attaques gouvernementales, décide de faire imprimer le code source de PGP via les éditions presse du MIT, et peut ainsi le distribuer en bénéficiant de la protection du Premier Amendement. Il rencontre plus de difficultés dans sa défense contre RSA Security et finit par abandonner RSA au profit des algorithmes libres DSA et ElGamal pour la version 3 de PGP.

En 1996, l’entreprise PGP Inc. fusionne avec Viacrypt, titulaire d’une licence RSA, tandis que Netscape poursuit le développement d’une nouvelle technologie basée sur RSA pour sécuriser son navigateur, Secure Socket Layer ou SSL, dont la version 2 est lancée depuis 1995. Les ingénieurs Phil Karlton et Alan Freier travaillent avec le cryptographe Paul Kocher, diplômé en biologie à l’université de Stanford ayant longuement travaillé avec Martin Hellman, pour lancer rapidement la version 3 de SSL.

Zimmerman présente PGP à l’IETF (Internet Engineering Task Force) en 1997 pour y proposer un standard OpenPGP.

Le brevet sur l’algorithme ayant été levé, OpenPGP est aujourd’hui un standard officiel en matière de chiffrement. Le protocole SSL est quant à lui devenu un standard depuis 1999, ainsi que son évolution, le protocole TLS.

Les prédictions de Diffie et Hellman sur l’avenir des communications ont inspiré RSA, dont l’invention a suscité une véritable levée de boucliers des autorités militaires. Pour autant, tandis que TLS/SSL est devenu un protocole universel, l’utilisation de PGP est loin d’avoir été adoptée par tous. C’est pourtant un outil inestimable en matière de liberté d'expression, qui continue à susciter partout dans le monde une bataille acharnée entre gouvernements (totalitaires ou pas) et défenseurs des Droits de l’Homme.


ImageMagick a annoncé une faille de sécurité, CVE-2016-3714 (lien en anglais), qui pourrait permettre à des utilisateurs mal-intentionnés d'éxecuter des commandes à distance à travers des noms de fichiers spécialement conçus pour ce faire.

Nous avons mis à jour les instances Simple Hosting avec la routine officielle pour protégér les sites web de nos clients. Si vous êtes utilisateur d'ImageMagick, assurez-vous de redémarrer vos instances à partir du 4 Mai 2016 à 18h00 pour que la routine soit prise en compte.

Vous pouvez redémarrer vos instances à partir du site web de Gandi ou depuis la ligne de commandes avec Gandi CLI : $ gandi paas restart {nom_de_l'instance}

N'hésitez pas à contacter le Support en cas de souci, ou si vous avez des questions concernant ce sujet.


Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs KVM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Les VM des clients concernés (sauf si elles l'ont été entre temps) seront redemarrées le jeudi 19 novembre. Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.

Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le jeudi 29 octobre. L'équipe de Xen nous a d'ores et déjà communiqué les correctifs.

Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs Xen pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services, nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Nous conseillons vivement aux clients impactés de redémarrer eux-mêmes leurs serveurs afin de s'assurer que tous les services repartiront correctement. Les VM des clients concernés qui n'auront pas été redémarrées, le seront de façon automatique entre le jeudi 22 et le mercredi 28 octobre.
Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Une nouvelle release de WordPress, la version 4.3.1, vient corriger 2 vulnérabilités de XSS (Cross Site Scripting) et une vulnérabilité au niveau de la gestion des privilèges permettant, par exemple, à un utilisateur non-autorisé de créer des articles privés.

Il est temps de vérifier si les mises-à-jour automatiques de votre WordPress sont au point, ou de lancer une mise-à-jour manuellement. Vous avez en effet tout intérêt à boucher les 3 vulnérabilités et les 26 bugs que la version 4.3.1 de WordPress vient corriger.

Deux sont des vulnérabilités de XSS (Cross Site Scripting) et concernent le traitement des balises "shortcode" dans les versions 4.3 et antérieures, ainsi que la page de la liste des utilisateurs. Le dernier est un problème de gestion des privilèges où, dans certains cas, un utilisateur non-autorisé pouvait publier des articles privés et les marquer comme "sticky".

Même si cette version n'apporte pas de nouvelles fonctionnalités, elle vient tout de même corriger 26 autres bugs de la version 4.3. En tout, se sont 64 fichiers qui ont été modifiés pour améliorer différents aspects du CMS le plus populaire au monde, de l'interface à son fonctionnement interne.

À vos consoles d'administration, donc ! Ou rendez-vous sur le changelog officiel pour avoir de détails (en Anglais): https://codex.wordpress.org/Version_4.3.1


Page 1 2
Change the news ticker size