La friteuse d’un hacker russe a attaqué le site de François

Accuser des hackers intergalactiques au moindre plantage, c’est devenu un sport national. Votre site web tombe en panne ? Vite, sortez le grand jeu : c’est un pirate russe ou un génie du Dark Web qui vous en veut, forcément. C’est tellement plus commode que d’admettre un bête problème technique. La dernière scène en date se joue autour des déclarations truculentes de François Bayrou, qui a dégainé l’argument de la “cyberattaque massive” pour expliquer la mise hors service de son site internet. Spoiler: il y a fort à parier que dans cette histoire, le seul responsable est un serveur mal configuré – pas la friteuse d’un hacker russe perdue .

Cyberattaque, vraie de vraie : mode d’emploi

Avant de crier au loup (ou plutôt au hacker), remettons les pendules à l’heure : qu’est-ce qu’une véritable cyberattaque ? Il ne s’agit pas d’un vague bug ou d’un trop grand nombre de visiteurs sur votre site. Non, une vraie cyberattaque, ça décoiffe et ça laisse des traces tangibles.

Déni de service distribué (DDoS) de compétition

Imaginez des millions de requêtes qui s’abattent simultanément sur un site, le noyant sous un trafic démesuré jusqu’à le rendre KO. GitHub, la célèbre plateforme de code, en a fait l’expérience en 2018 avec un pic record de 1,35 térabit de données par seconde envoyé vers ses serveurs . Du jamais vu à l’époque : le site est resté inaccessible pendant une dizaine de minutes, malgré les défenses sophistiquées en place, face à un assaut d’une ampleur inédite mené par des acteurs particulièrement déterminés . Voilà ce qu’on peut appeler une cyberattaque massive. On parle ici d’une offensive volontaire, coordonnée, visant à faire tomber un service en saturant ses ressources – bien loin de vos trois péquins qui rafraîchissent une page web en même temps. Quand ce n’est pas un acte délibéré, les plus mauvaises langues (dont je fais parti évidemment) pensent également à la pateforme Parcours Sup qui rappelle qu’il ne fait pas coder avec le cul

Intrusion insidieuse dans la supply chain

Autre niveau de finesse, l’attaque ne vise plus directement votre site, mais un fournisseur de logiciel que vous utilisez. SolarWinds, ça vous dit quelque chose ? Fin 2020, cette société texane spécialisée dans les outils de supervision réseau a été le théâtre d’une des plus grandes opérations de cyberespionnage du siècle . Des attaquants liés à un État (très largement pointé du doigt : la Russie) ont réussi à compromettre la chaîne de mise à jour du logiciel Orion de SolarWinds . En clair, ils ont inséré du code malveillant dans une version légitime du logiciel, déployée ensuite chez des milliers de clients dont des agences fédérales américaines. Résultat : une porte dérobée ouvrant l’accès aux systèmes de toutes ces organisations . On est ici dans la haute voltige de la cyberattaque, avec infiltration furtive, malware sur mesure et des dégâts monumentaux sur la durée. Pas vraiment le genre de choses qui se produisent parce que votre site Symfony a oublié son cache…

Rançongiciel (ou wiper) destructeur

Dans la catégorie bulldozer, NotPetya occupe une place de choix. Ce malware apparu en 2017 s’est propagé à la vitesse grand V, sous couvert d’une demande de rançon, alors que son but réel était de détruire des données et semer le chaos . Propagation via une faille Windows, chiffrement irrémédiable des disques, et au final des dommages colossaux : plus de 10 milliards de dollars de pertes estimées à travers le monde . Des multinationales paralysées pendant des mois, des ports maritimes bloqués, même le site nucléaire de Tchernobyl touché . Là encore, on parle d’une attaque sophistiquée, probablement étatique, visant à déstabiliser un pays (l’Ukraine en l’occurrence) et causant des ravages bien réels . On est aux antipodes d’un simple formulaire qui plante faute de maintenance.

En résumé, une vraie cyberattaque, ça se sent passer : des volumes de trafic hallucinants, des intrusions élaborées, des dégâts financiers ou stratégiques énormes. Ce n’est pas juste votre site perso ou celui d’un homme politique un peu trop confiant qui flanche le jour d’une conférence de presse. Avant d’aller blâmer les hackers du Kremlin ou un obscur groupe de pirates nord-coréens, encore faut-il vérifier si le problème n’est pas tout simplement… de votre propre fait.

La config foireuse : coupable numéro un

La plupart du temps, quand un site web s’écroule, le responsable ne se cache pas dans l’ombre d’un forum pirate, mais dans la glace de la salle des développeurs. Autrement dit, la mauvaise configuration serveur est souvent la véritable cause du désastre. Comparons un peu avec nos cas précédents : pour faire tomber GitHub il a fallu une armée de machines et 1,35 Tbps de trafic malveillant. Pour faire tomber votre site Symfony mal fichu, quelques milliers de visiteurs suffiront – même pas besoin de bots ! Voici quelques joyeusetés techniques qui, bien plus qu’un hacker imaginaire, peuvent exploser un site du jour au lendemain.

Pas de cache, bonjour les dégâts 

Aucune mise en cache HTTP ou applicative ? Chaque requête va alors taper la base de données, exécuter du code PHP lourd, recalculer toujours les mêmes résultats… Évidemment que ça rame, et sous forte charge ça part en fumée. Symfony offre un mécanisme de cache HTTP (via HttpCache ou un reverse proxy) et de cache applicatif, mais si on le laisse de côté, le serveur se prend tout de front. Un site qui recalcule tout à chaque hit, c’est un site prêt à tomber dès qu’il a 100 utilisateurs simultanés. Autant dire qu’avant d’invoquer la CIA, il faudrait peut-être penser à activer l’option “cache” dans le back-office.

Absence de CDN, serveur en sueur

Héberger tous vos fichiers statiques (images, PDF, CSS, JS) sur le même petit serveur web sans aucune aide, c’est comme vouloir servir un banquet seul à 500 invités. Sans Content Delivery Network (CDN) pour prendre le relais, votre serveur unique doit envoyer chaque image et chaque script aux quatre coins du monde. Devinez quoi : il va vite saturer. “En l’absence de CDN, les contenus sont stockés sur un seul serveur” et des sollicitations trop abondantes aboutissent à la saturation dudit serveur, rendant le site illisible . En clair, si Bayrou.fr a publié d’un coup des tonnes de documents PDF et que tout le monde les télécharge directement du même endroit, le serveur a très bien pu tomber tout seul sous la charge. Pas besoin de « cyberattaque massive » – juste d’un pic de trafic mal géré.

Pas de limiteur de rate (limiteur de débit) 

Une config qui n’intègre aucune limitation du nombre de requêtes par IP ou par session ouvre grand la porte aux abus. Par abus, on ne parle même pas d’un hacker : un utilisateur lambda qui appuie frénétiquement sur F5, ou un script automatisé un peu bête qui recharge une page en boucle, et c’est la surchauffe. Un bon rate limiter (par exemple le composant RateLimiter de Symfony) aurait pu freiner les ardeurs et éviter qu’un même client envoie 1000 requêtes par minute. Sans ce garde-fou, votre site peut se faire auto-DDoS par quelques utilisateurs acharnés ou par un robot d’indexation mal configuré. Là encore, ce n’est pas la NSA, c’est vous qui avez oublié de mettre un limiteur de vitesse sur l’autoroute de votre application.

Hébergement au rabais ou mal géré

Mettre en ligne un site sans prévoir de scalabilité, c’est chercher les ennuis. Un hébergement mutualisé poussif, une petite VM sous-dimensionnée sur Azure, aucun système d’autoscaling, et aucune stratégie de montée en charge… Forcément, le jour où l’affluence explose, le serveur suffoque. Rappelons qu’un site web correctement dimensionné, ça s’anticipe : on utilise par exemple plusieurs instances derrière un load balancer, on configure des seuils d’auto-scalage sur le cloud, on surveille les métriques de CPU/RAM. Si rien de tout ça n’a été fait, inutile de blâmer des hackers sortis du chapeau. Le vrai coupable, c’est l’économie de bouts de chandelle sur l’infra. Eh oui, quand on héberge un site critique “à l’économie”, la facture arrive tôt ou tard, sous forme de crash en plein moment critique.

Bugs applicatifs et erreurs de configuration

Last but not least, il y a les boulettes maison. Le framework Symfony est robuste, mais mal utilisé il peut devenir votre pire ennemi. Laisser l’application en mode debug en production, par exemple, c’est s’assurer un sérieux ralentissement – l’environnement de développement ajoute un surcoût important dû à la collecte de données pour la toolbar et le profiler Symfony . De même, déployer sans passer en APP_ENV=prod (en oubliant de mettre à jour la variable d’environnement) signifie que votre code n’est pas optimisé du tout pour la prod. L’application va charger et recomplier des ressources à tout va, ce qui est parfait pour faire tomber les performances.

Les bonnes pratiques qui évitent le ridicule

Passons à la checklist des bonnes pratiques. Car oui, il existe tout un tas de mesures techniques pour qu’un site Symfony (ou tout autre site) tienne la route et ne se transforme pas en excuse « cyberattaque » dès qu’il y a du monde dessus. Voici quelques conseils, à la fois sérieux et un brin moqueurs, pour nos amis admins système et devs web – et peut-être pour certain(e)s responsables politiques un peu trop prompts à dégainer le mot en C.

Config Symfony en mode prod béton

La base de chez base. On déploie en environnement de production, avec APP_ENV=prod et APP_DEBUG=0. On génère le cache de production, on utilise un autoloader optimisé avec Composer, et on s’assure que les bundles de debug ne sont pas chargés. En un mot, on enlève les petites roues du vélo avant d’aller sur l’autoroute. En mode prod, Symfony est fait pour encaisser bien plus de charge qu’en mode dev (ce dernier est 2 à 3 fois plus lent à cause des outils de debug ). Autant s’en souvenir avant de publier le site.

Mise en cache et CDN

On active le cache HTTP (pages marquées publiques, utilisation du HttpCache de Symfony ou, mieux, d’un reverse proxy/Varnish en frontal). On configure aussi un système de cache applicatif (par exemple un cache OPcode PHP, un cache de requêtes Doctrine, etc.). Tout ce qui peut éviter de refaire 100 fois le même calcul, on le met en place. Ensuite, on déporte les contenus statiques sur un CDN global (Cloudflare, Azure Front Door, AWS CloudFront, peu importe) pour soulager le serveur origin . Le CDN distribuera les fichiers lourds depuis des nœuds locaux aux utilisateurs, évitant que notre pauvre serveur Azure ne doive envoyer 1000 fois le même fichier PDF en simultané. En bonus, le CDN apporte souvent une protection DDoS de base et un cache des pages statiques : double bouclier.

Limitation des requêtes et sécurité applicative

On intègre un rate limiter pour éviter qu’une même IP ou un même utilisateur ne spamme l’application. Symfony propose nativement de configurer des limiteurs de taux (par ex, limiter à 10 requêtes par minute certaines routes sensibles). Voici à quoi peut ressembler une config YAML pour limiter, par exemple, les tentatives de connexion :

framework:
  rate_limiter:
      login:
          policy: 'sliding_window'
          limit: 5
          interval: '1 minute'

Dans cet exemple, on n’autorise pas plus de 5 tentatives par minute sur l’action login (typiquement pour éviter un bombardement de formulaires de login). On pourrait ajuster ce genre de limiteur sur d’autres pages si nécessaire, ou utiliser un outil externe (un module Nginx, Cloudflare, etc.) pour couper court à des rafales de requêtes inhabituelles. L’idée, c’est de filtrer et calmer le jeu avant que le serveur ne parte en vrille. Par ailleurs, on pense à sécuriser l’appli Symfony elle-même : paramétrer correctement le firewall Symfony (pour les routes admin, etc.), appliquer les correctifs de sécurité des bundles, désactiver les profiler en prod, nettoyer les données sensibles du code (pas de mots de passe en dur, pas d’endpoint /dev.php accessible publiquement, etc.). Autant de petits gestes qui renforcent la sécurité et la stabilité, et vous éviteront de passer pour un clown en conférence de presse.

Surveillance, logs et anticipation 

Un bon admin anticipe les problèmes avant qu’ils ne virent à la catastrophe. Ça veut dire mettre en place des watchdogs et des outils de monitoring. Sur Azure par exemple, on disposera d’Application Insights ou Cloud Watch pour surveiller les performances et repérer tout pic inhabituel. On configure des alertes : si la charge CPU dépasse 80%, si le nombre de requêtes explose, si la latence s’envole, on est prévenu en temps réel. Et surtout, on regarde les logs ! Les journaux applicatifs et serveurs sont une mine d’or. Ils vous diront si le site a planté à cause d’une erreur 500 bien ordinaire, d’un out of memory, d’une requête SQL trop lente… ou s’il y a réellement eu des motifs suspects (par exemple des milliers de tentatives sur /wp-login.php alors que vous n’utilisez pas WordPress – ce qui pourrait indiquer un bot malveillant). Dans 90% des cas, les logs pointeront un souci interne plutôt qu’une attaque externe. Mais encore faut-il les lire, ces logs, au lieu de partir en live à la télé.

Firewall et réseau

On n’hésite pas à déployer un Web Application Firewall (WAF) en amont du site. Les fournisseurs cloud comme Azure proposent des WAF intégrés ou on peut passer par un CDN/WAF tier (Cloudflare, F5, etc.). Un WAF correctement configuré filtrera bon nombre de requêtes malicieuses (SQL injection, XSS, scans de vulnérabilité) et pourra aussi atténuer des tentatives de DDoS applicatif basiques. De plus, on s’assure que le pare-feu réseau (celui du serveur ou du cloud) n’ouvre que le strict nécessaire – par exemple, fermer l’accès direct à la base de données depuis l’extérieur, limiter les ports, etc. Ça ne rendra pas votre site plus rapide, mais ça évitera qu’une vraie attaque ne soit trop facile. Et puis au moins, si un jour vous subissez vraiment une attaque, vous aurez la conscience tranquille d’avoir tout verrouillé en amont. En bonus, pensez aux bonnes pratiques HTTP niveau sécurité : activer HTTPS (évidemment), ajouter des en-têtes de sécurité (HSTS, CSP, etc.), configurer correctement les cookies de session. Certes, ça ne joue pas sur la disponibilité du site, mais ça renforce la crédibilité globale de votre démarche sécurité. Parce que décréter “cyberattaque” en ayant un site non-chiffré en HTTP sans la moindre protection, ça ferait un peu désordre, non ?

En appliquant tout ou partie de ces bonnes pratiques, vous vous épargnerez sans doute le ridicule de la situation Bayrouesque. La prochaine fois qu’un site tombe en panne pile au mauvais moment, rappelez-vous que dans la majorité des cas le coupable est côté serveur, pas derrière un clavier pirate à Pyongyang. C’est plus facile d’accuser un ennemi invisible, mais la vérité est souvent beaucoup plus terre-à-terre : un admin/dev à la bourre sur les correctifs, un budget infra à la diète, et hop, ça flanche.

Le mot de la fin

Cherchons un instant l’ironie dans cette affaire : on a un responsable politique qui, face à l’inaccessibilité de son site, y voit immédiatement la main d’un adversaire malveillant. C’est vrai quoi, comment imaginer que sa propre équipe ou lui-même aient pu commettre une erreur technique ? Impossible, mieux vaut évoquer des hackers fantômes. Pourtant, comme on l’a vu, il n’y a souvent pas besoin de cyber-ninjas pour mettre un site à genoux – quelques configurations douteuses suffisent amplement.

La morale de cette histoire satirico-technique : “Cyberattaque” est le nouveau “chien a mangé mes devoirs”. C’est l’excuse fourre-tout pour éviter de dire “nos serveurs ne tiennent pas la charge” ou “on a déployé en prod un truc pas prêt”. Alors bien sûr, de vraies cyberattaques, il y en a tous les jours et elles font des ravages. Mais avant de clamer à qui veut l’entendre que des hackers internationaux s’acharnent sur votre pauvre site Symfony, commencez par faire un tour dans vos fichiers de config, vos logs et votre console Azure. Il y a de fortes chances que le fantôme dans la machine, ce soit vous.

En attendant, la prochaine fois qu’on nous parle de “cyberattaque massive” parce qu’un site web politique est tombé, on saura lire entre les lignes : mauvais code, mauvais config, mauvais admin. Les véritables experts en sécurité, eux, continuent de traquer les vraies attaques – pendant que d’autres jouent les intéressés avec des pannes faites maison.