Comment les sites sont réellement compromis, et comment ne pas être la cible facile.
En sécurité, la cause supposée est en général « rien ne va mal ». Voici comment les sites sont réellement compromis, pourquoi le haut de cette liste est évitable, et comment prouver depuis l'extérieur qu'un correctif a fermé la porte.
Dans cet article 4 sections
- En sécurité, la cause supposée est « rien ne va mal ». La plupart des gens ne savent pas qu'ils ont été compromis.
- Notre supervision et nos flux de threat intelligence sont câblés pour ouvrir le ticket, donc le premier message est en général le nôtre. L'attraper en premier, c'est le métier.
- Les sites sont compromis de façons ennuyeuses. Les logiciels obsolètes et les choses laissées ouvertes par inadvertance sont en tête de liste, et c'est exactement ce qu'un audit avant la mise en production et l'application continue des correctifs attrapent.
- Trouver la compromission n'est que la moitié du travail. Quand nous en fermons une, nous prouvons que la porte est fermée en réattaquant depuis une adresse à laquelle nous ne faisons pas confiance. Si nous pouvons encore l'atteindre, ce n'est pas corrigé.
Il y a un signe dans chaque appel de sécurité. La cause supposée par le client est en général la pire qui soit : rien ne va mal. Ils n'ont pas appelé parce que quelque chose paraissait anormal. Ils ont appelé parce que nous le leur avons dit. Au moment où une compromission devient visible pour la personne qui possède le site, elle a en général déjà eu lieu.
En sécurité, la cause supposée est « rien ne va mal »
“quote: En sécurité, la cause supposée par le client est en général « rien ne va mal ». Ils ne savaient pas qu'ils avaient été compromis. attribution: EUROVPS SECURITY”
C'est toute la différence. Non pas que les compromissions n'arrivent pas. Elles arrivent, sur chaque plateforme, à chaque type de site. La différence, c'est qui le voit en premier : une couche de détection qui surveille les signatures d'une compromission, ou un flux de threat intelligence qui signale un trafic qui ne devrait pas exister, pendant que le tableau de bord du site lui-même affiche encore du vert. Notre supervision et ces flux sont câblés pour ouvrir le ticket, et c'est pourquoi le premier message est en général le nôtre.
Comment les sites sont réellement compromis
Retirez la version cinéma, et les façons dont les sites sont réellement compromis sont ennuyeuses, et elles se répètent. Voici le classement, du plus fréquent au moins fréquent. Rien en haut de cette liste n'est astucieux.
Logiciel obsolète ou en fin de vie
La voie d'entrée la plus fréquente, de loin. Une application avec une vulnérabilité publiquement connue, exposée à Internet, des années de retard sur les correctifs. Exposée à Internet et des années de retard sur les correctifs, c'est tout ce qu'il faut. L'exploit est sur l'étagère. Aucune astuce requise.
Quelque chose laissé ouvert par inadvertance
Aucun exploit nécessaire. La porte était simplement ouverte. Une base de données liée à toutes les interfaces réseau sans authentification. Un fichier de configuration ou de debug lisible par tous. Un CMS qui laisse fuir ses noms d'utilisateur par une API ouverte. Un sous-domaine de staging oublié qui répond encore. Personne n'est entré par effraction. Ils sont entrés en marchant.
L'origin joignable derrière le CDN
Le site est derrière un CDN, mais le vrai serveur répond encore directement si vous savez le trouver, et son adresse se trouve souvent dans le DNS de messagerie du domaine lui-même. La porte d'entrée est gardée pendant que la porte de derrière est calée ouverte.
Brute-force des identifiants sans défense de couche 7
Une page de connexion sans rien devant elle au niveau applicatif, martelée jusqu'à ce que quelque chose cède. Un firewall de couche 3/4 la laisse passer sans broncher : pour un filtre de ports, cela ressemble à du trafic normal vers un port qui doit rester ouvert.
Identifiants faibles, réutilisés ou exposés, sans MFA
Un mot de passe qui a fuité ailleurs, réutilisé ici, sans second facteur pour le rendre inutile. La serrure était bonne. La clé avait déjà été copiée.
Spam sortant depuis un compte déjà compromis
Souvent le premier signe extérieur d'une compromission déjà survenue. Le compte n'est pas la cible. C'est la rampe de lancement, et le spam est la fumée, pas le feu.
Phishing et ingénierie sociale
La couche humaine. Aucun bug logiciel. Quelqu'un a simplement été convaincu de remettre les clés.
Regardez les deux premiers. Logiciel obsolète et choses laissées ouvertes par inadvertance. Aucun des deux n'est une attaque astucieuse. Les deux sont exactement ce qu'un audit discipliné avant la mise en production et l'application continue des correctifs attrapent avant que quiconque n'essaie la poignée. C'est tout l'argument en faveur de la sécurité infogérée. La plupart des intrusions ne sont pas des effractions. Ce sont des entrées en marchant. Et l'entrée en marchant est évitable.
L'attraper en premier, c'est le métier. Prouver que c'est fermé, c'est la différence.
Trouver la compromission est la moitié du travail. La moitié que presque personne ne fait, c'est prouver que le correctif a réellement tenu. Quand nous fermons une compromission, nous ne prenons pas le tableau de bord au mot quand il dit que le port est fermé. Nous réattaquons l'origin comme le ferait un attaquant : depuis une machine dans un autre de nos datacenters, par une sortie que le firewall n'a jamais été configuré pour croire. Si notre propre scanner peut encore l'atteindre, ce n'est pas corrigé. Ce n'est que quand la porte est fermée depuis l'extérieur, depuis une adresse à laquelle nous ne faisons pas confiance, que nous la déclarons fermée.
“quote: Le travail n'est pas seulement de corriger la compromission. C'est de l'attraper en premier, puis de prouver depuis l'extérieur que la porte est fermée. attribution: EUROVPS SECURITY”
Cette méthode, réattaquer votre propre origin depuis un point de vue non fiable et confirmer ce qu'un attaquant verrait réellement, est une discipline à part entière, et elle a son propre article. Nous prouvons depuis l'extérieur que c'est fermé parcourt tout le playbook.
Sept façons de ne pas être la cible facile
Rien en haut de ce classement ne demande un attaquant de génie. Ce qui signifie que la plupart est évitable en n'étant pas la cible facile. Sept habitudes, dans l'ordre où elles rapportent.
Corriger ou retirer
Si c'est exposé à Internet et non maintenu, c'est un passif. Mettez-le à jour ou retirez-le. Il n'y a pas de troisième option qui finisse bien.
Partir du principe que l'origin sera trouvé
Verrouillez-le sur les plages IP du CDN pour que seul le CDN puisse l'atteindre, et cessez de laisser fuir son adresse dans votre DNS de messagerie. Un origin caché n'est pas caché si votre propre DNS l'annonce.
Un firewall L3/4 n'est pas un WAF
Le filtrage de ports ne lit pas les requêtes. Le brute-force, l'injection et les abus au niveau applicatif passent tous par des ports que vous devez laisser ouverts. Il vous faut une défense qui inspecte la couche 7.
Auditer avant de déclarer que c'est terminé
« Ça marche » n'est pas « c'est fermé ». Vérifiez ce qui est exposé, ce qui est lisible par tous, ce qui est encore lié à l'Internet public, avant la mise en production, pas après l'arrivée de la notification.
Partir du principe que les identifiants fuient. Les rendre inutiles hors liste blanche.
MFA partout, et liez les chemins sensibles à des adresses connues. Un mot de passe volé ne devrait rien ouvrir à lui seul.
Surveiller le surveillant
Une supervision qui devient aveugle et continue d'afficher du vert est pire que pas de supervision du tout, parce qu'elle achète un faux calme. Confirmez que le détecteur peut réellement voir.
Prouver le correctif depuis l'extérieur
Le seul test qui compte est le point de vue de l'attaquant. Réattaquez depuis une adresse à laquelle vous ne faites pas confiance et confirmez que la porte est fermée.
Réponses directes
Comment les sites web sont-ils réellement piratés en hébergement infogéré ?+
Surtout de deux façons ennuyeuses. Un logiciel obsolète ou en fin de vie avec une vulnérabilité publiquement connue, exposé à Internet, et des choses laissées ouvertes par inadvertance : une base de données sans authentification, un fichier de configuration lisible par tous, un sous-domaine de staging oublié. Les exploits astucieux sont loin dans la liste. La plupart des intrusions sont des entrées en marchant.
Comment saurais-je même que mon site a été compromis ?+
Souvent, vous ne le sauriez pas, et c'est bien le problème. Notre supervision et nos flux de threat intelligence sont câblés pour ouvrir le ticket, donc le premier message au sujet d'une compromission est en général le nôtre. La cause supposée côté client est en général « rien ne va mal ». Du spam sortant ou une notification d'un tiers est souvent le premier signe extérieur, et à ce moment-là, c'est déjà arrivé.
Mon serveur est-il sécurisé s'il a un firewall ?+
Un firewall de couche 3/4 filtre des ports. Il ne lit pas les requêtes. Le brute-force d'identifiants, l'injection et les abus au niveau applicatif voyagent tous sur des ports que vous devez laisser ouverts, donc ils lui paraissent du trafic normal. Un firewall n'est pas un WAF. Pour les arrêter, il faut une défense qui inspecte la couche 7.
Les attaquants peuvent-ils trouver mon serveur origin s'il est derrière un CDN ?+
Souvent, oui. Le CDN n'aide que si l'origin ne peut pas être atteint directement, et la vraie adresse de l'origin fuit souvent dans le DNS de messagerie du domaine lui-même. Verrouillez l'origin sur les plages IP du CDN et cessez de l'annoncer dans le DNS, sinon la porte d'entrée gardée a sa porte de derrière calée ouverte.
En hébergement infogéré, qui est responsable des correctifs de mes applications ?+
La plateforme et l'application sont deux métiers différents, et l'écart entre les deux est l'endroit où les sites sont compromis. Nous gardons la plateforme durcie et nous auditons avant la mise en production. Mais une application en fin de vie avec une vulnérabilité connue est un risque partagé. La valeur de l'infogérance, c'est qu'un audit discipliné avant la mise en production et l'application continue des correctifs attrapent l'essentiel avant que quiconque n'essaie la poignée.
Vous ne savez pas ce qui est exposé ? Demandez avant que quelqu'un d'autre ne le découvre.
Apportez-le à un ingénieur, pas à une file de tickets. Nous vérifions ce qui est joignable depuis l'extérieur, nous vous disons clairement quoi fermer, puis nous prouvons que c'est fermé.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur