Un incident interrompu chez Cloudflare mardi a temporairement éteint de nombreux sites Web populaires. Certains clients affectés ont pu basculer provisoirement vers la plateforme afin que les visiteurs puissent toujours accéder à leurs sites Web. Cependant, les experts en sécurité suggèrent que cela pourrait également avoir déclenché une analyse d’intrusion impromptue pour les organisations qui comptent sur Cloudflare pour bloquer de nombreux types de trafic abusif et malveillant.
Détails de l’incident
L’incident a commencé vers 6:30 EST/11:30 UTC le 18 novembre, affectant un grand nombre de sites Web hautement visibles. Bien que les services Cloudflare aient finalement été restaurés, la page d’état de l’entreprise a reconnu une ‘dégradation interne du service’ pendant cette période.
Implications en matière de sécurité
Aaron Turner, membre du personnel à IANS Research, suggère que cet incident offre une opportunité aux clients Cloudflare de réévaluer leurs journaux de pare-feu d’applications Web (WAF). Il note que bien que le WAF de Cloudflare soit efficace pour bloquer de nombreux types d’attaques, il pourrait révéler des vulnérabilités lorsqu’il n’est pas utilisé.
Identification des failles en sécurité
Turner explique que certaines entreprises peuvent avoir été trop dépendantes de Cloudflare pour des fonctionnalités de sécurité telles que la protection contre les injections SQL et le blocage de robots. Durant l’incident, ces fonctionnalités ont été contournées, mettant en évidence des faiblesses potentielles dans les pratiques de sécurité internes.
Analyse du risque
Nicole Scott, responsable marketing produit chez Replica Cyber, appelle cet incident un ‘jeu de rôle gratuit’. Elle souligne l’importance d’examiner à la fois le trafic externe et le comportement interne lors de ces événements.
Questions pour réflexion
- Qu’est-ce qui a été éteint ou contourné (WAF, protections contre les robots, blocages géographiques) et pendant combien de temps ?
- Quelles changements d’infrastructure DNS d’urgence ou de routage ont-ils été apportés, et qui a approuvé ces changements ?
- A-t-on basculé le travail sur des appareils personnels, un Wi-Fi domestique ou des fournisseurs SaaS non autorisés ?
- A-t-on mis en place de nouveaux services, tunnels ou comptes de fournisseurs ‘temporairement’ ?
- Y a-t-il un plan pour annuler ces changements, ou sont-ils maintenant des solutions d’échappatoire permanentes ?
- Pour la prochaine incident, quel est le plan d’intentionnel d’abandon en cas de panne, au lieu de l’improvisation décentralisée ?
Analyse post-mortem
Le vendredi soir, dans un rapport post-mortem, le PDG de Cloudflare, Matthew Prince, a expliqué que l’incident était causé par une modification inattendue des permissions d’un système de base de données. Cela a conduit à la propagation d’un fichier de fonctionnalité plus grand que prévu sur leur réseau.
Impact et leçons apprises
L’incident a affecté environ 20 % des sites Web utilisant les services Cloudflare, mettant en évidence la vulnérabilité de se rélier à un seul fournisseur cloud. Les experts en sécurité conseillent aux organisations de diversifier leur infrastructure en distribuant le WAF et la protection contre les DDoS sur plusieurs zones et d’utiliser une DNS multi-vendeur.
Articles connexes
