Sécurité, phishing
Résolu/Ferméheliconius Messages postés 539 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 19 août 2022 à 16:31
- La base de données de sécurité du serveur n'a pas de compte d'ordinateur pour la relation
- Ordinateur qui rame - Guide
- Créer un compte gmail - Guide
- Formules excel de base - Guide
- Supprimer compte instagram - Guide
- Impossible de récupérer mon compte gmail - Guide
1 réponse
18 août 2022 à 19:26
Bonjour,
Un hébergeur du web a signalé au mien que le site web que je maintenais avait été utilisé pour faire du phishing. Réaction de mon hébergeur : il a désactivé la visibilité du site, m'a immédiatement prévenu et m'a demandé de vérifier complètement mon site avant d'en réactiver la visibilité. Cela a été fait.
Était-ce le cas, as-tu constaté ledit contenu frauduleux ? d'ailleurs tu parles de phishing et de courriels, ce n'est pas clair s'il s'agit d'un problème concernant l'envoi de spams depuis ton compte, ou l'hébergement d'un site d'hameçonnage sur ton domaine.
Avant de rechercher une solution, il faut tout d'abord comprendre comment cela a pu arriver.
Ce type de problème se pose souvent lorsque l'application PHP du client (l'abonné au service d'hébergement) contient des vulnérabilités. Il s'agit d'une faille au niveau utilisateur et non une faille au niveau serveur.
Je ne vois pas de quelle façon la solution que tu proposes permet de résoudre l'origine du problème. Le fait que tu fournisses une signature pour tes pages ou les courriels que tu envoies n'empêche pas d'exploiter une vulnérabilité qui serait présente dans le script PHP afin d'altérer tes pages, en ajouter d'autres, ou envoyer des courriels (non signés) vers d'autres destinataires au hasard qui ne connaissent pas ton site.
Le site d'hameçonnage placé par la hacker n'a généralement pas pour cible tes propres visiteurs. Le site de phishing est souvent publié dans un sous-dossier et n'altère pas nécessairement le fonctionnement du site légitime. Le hacker peut transmettre le lien du site frauduleux, dans un sous-dossier, par courriel. Les gens qui recevront le lien n'ayant pas connaissance de ton mécanisme de chiffrement, ils n'y verront que du feux. Sauf s'ils prennent la peine de regarder l'URL, en 2022, ça devrait être un réflexe depuis le temps que le problème est connu (mais des gens se font encore avoir avec les PCS...). Ta méthode nécessite aussi que le visiteur ait déjà visité / utilisé ton site. Comment un visiteur qui viendrait pour la première fois pourrait connaître ta clé publique ?
Une solution qui vient de me traverse la tête serait de publier la clé publique via les DNS, l'authenticité (mais pas le chiffrement) des réponses DNS pouvant déjà être assurée par DNSSEC, c'est donc désormais un moyen sûr de communiquer une information (l'information est authentifiée mais pas chiffrée, j'insiste là-dessus). Chaque page https://example.com/page.html pourrait avoir sa signature à l'adresse https://example.com/page.html.sig et le navigateur pourrait automatiser la vérification :
- Le visiteur demande https://example.com/page.html
- Le visiteur télécharge
- https://example.com/page.html
- https://example.com/page.html.sig
- L'entrée TXT pour __sig.https.example.com = la clé publique
- Compare page.html avec page.html.sig et la clé publique
- Fait de même pour chaque élément (image, css, js, ...)
Les avantages :
- Automatique : le visiteur ne doit rien faire
- Il s'agit d'une solution « E2E », un peu comme Signal mais sans le chiffrement, entre le visiteur et le webmaster, qui ne dépend pas du serveur Web, et qui permet de s'assurer que le contenu demandé correspond bien à celui émit par le titulaire du domaine. À l'inverse du chiffrement de transport (TLS) qui dépend de la confiance que tu accordes au serveur.
- La clé privée peut rester sur l'ordinateur du webmaster, personne d'autre que lui ne peut signer une page.
- En cas de serveur compromis, par des hackers (faille niveau serveur), par une vulnérabilité au niveau du script PHP, volontairement par l'administrateur du serveur, ... toute altération au contenu du site sera détectable. Admettons que quelqu'un publie son site via un proxy inversé comme CloudFlare, alors ce mécanisme empêcherait de proxy inversé d'injecter du contenu dans le site (script JS ...). Cela n'empêchera toujours pas la lecture du trafic HTTP par ce proxy car c'est une authentification, pas un chiffrement, et dans le cas de CloudFlare, c'est lui qui gère la couche TLS entre le visiteur et ses serveurs (oui oui, CloudFlare peut lire les mots de passe de tes visiteurs). Le hacker devrait donc pirater le serveur, mais aussi le DNS, qui peut (et devrait) être indépendant du serveur Web.
Désavantages :
- Les requêtes DNS et HTTP supplémentaires pourraient ralentir le chargement des sites.
- DNS permet de joindre des informations non demandées (champ "additional"), on pourrait donc "pousser" la clé publique lors de la résolution DNS de example.com.
- Les versions récentes de HTTP (HTTP/2) permettent aussi de joindre des ressources supplémentaires avec la page demandée avant même que ces ressources soient demandées.
Malgré cela, la quantité de données à transférer sera augmenté, et la validation de la signature peut aussi entraîner une charge CPU côté utilisateur. - Valable uniquement pour les sites statiques. En effet, les pages dynamiques étant générées côté serveur, il faudrait que la clé privée soit donnée à l'application PHP afin qu'elle génère la signature, ce qui détruit tout l'intérêt de la solution dans le cas où le problème est justement causé par une faille dans le code PHP.
Je ré-insiste sur le fait qu'on parle d'authenticité et pas de chiffrement, le chiffrement de bout en bout des pages Web entre le visiteur et le créateur de la page nécessiterait que le créateur de la page connaisse la clé de chiffrement publique du visiteur, or le but du site est qu'il soit accessible par tout le monde.
18 août 2022 à 22:57
Bonsoir et merci beaucoup pour ta réponse ayant un contenu certain. Voici le mail que j'ai reçu de mon hébergeur :
-----
Cher UNTEL,
On nous a signalé la présence des fichiers de phishing sur l'espace d'hébergement du domaine "xxxxxxxx.fr".
Le phishing est un phénomène par lequel une personne tente de mettre la main sur des informations et/ou des informations personnelles pour les utiliser comme trompeur.
Malheureusement, ces fichiers abusifs présents sur l'espace d'hébergement de votre site pourraient faire figurer sur la liste noire les serveurs de "mon-hebergeur.fr" et empêcher d'autres utilisateurs de profiter correctement de nos services.
Pour éviter ce type de problème, nous avons suspendu momentanément la visibilité du site tout en vous laissant l'accès FTP afin de vous permettre de nettoyez le fichier du script malveillant.
Veuillez nous recontacter dès que vous aurez pris les mesures suivantes :
Nous vous invitons à vérifier dès qu'il a satisfait aux conditions suivantes:
- Vérifier et nettoyer tous les fichiers frauduleux;
- Changement de codes d'accès FTP ;
- Hébergement de tous les bugs sur le site;
Fournir une assurance sur les problèmes de vérification précises, vous pouvez donc réactiver la visibilité de votre site.
Nous souhaitons vous rappeler que "mon-hebergeur.fr", dans le cadre de son engagement pour la sécurité, met à disposition de ses clients SiteLock, un outil conçu pour la sécurité en ligne, capable de faire face aux logiciels malveillants, aux attaques de pirates informatiques, à la cyber criminalité et autres menaces, grâce à son intervention ciblée et approfondie.
Si vous êtes intéressé par SiteLock veuillez répondre à ce message!
Merci
Abuse team - "mon-hebergeur.fr"
-----
.
NB: Je suis sur un VPS (OS: GNU/Linux Debian 7) et non un hébergement mutualisé.
.
-- J'ai initialement pensé que c'était une astuce de "mon-hebergeur.fr" pour me vendre SiteLock. Mais je suis chez lui depuis près de 20 ans il ne s'est jamais comporté comme cela. L'idée a donc été écartée.
-- J'ai d'abord fait une sauvegarde complète du site sur mon PC ;
-- J'ai changé login et password de l'utilisateur déposant les pages du site par FTP ;
-- J'ai ensuite supprimé TOUS les fichiers du site (contenu complet de httpdocs, error_docs et logs. Ces trois répertoires ont été vidés). Il n'y avait aucun répertoire (sous-dossier) suspect ;
-- J'ai revérifié TOUS les fichiers (du site, initialement sauvegardés) contenus dans le répertoire httpdocs et sous-répertoires. Je n'ai rien trouvé de suspect ;
-- Au fur et à mesure de la vérification, j'ai re-uploadé tous les fichiers vérifiés. Je me retrouve comme avant sauf que :
a) les fichiers ont été vérifiés ;
b) certains, obsolètes mais non altérés, ont été supprimés ;
c) les login et password ont été changés ;
d) la zone DNS du domaine (pas sur le VPS mais dans mon compte client) a été nettoyée J'y avais trouvé des IP étrangers aux IPs de "mon-hebergeur.fr" et des champs MX bizarre aussi.
.
C'est maintenant clean et je me demande ce que je peux chercher et faire d'autre.
.
L'idée que j'avais eue avec PGP et qui laissera peut-être une trace aussi indélébile qu'un coup de doigt dans l'eau, n'est pas de comparer toutes les pages du site avec leurs signatures respectives. Le site effectue des démos de tests en ligne et le visiteur, s'il souhaite avoir les réponses au test qu'il aura bien voulu faire (en fournissant son adresse mail) recevra par courriel son résultat (éventuellement avec graphique) et la correction mais le mail serait signé avec PGP. Ces mails-réponse sont absolument les *SEULS* qui sont expédiés par le site. La clef publique GPG du site se trouve sur celui-ci. Je me disais que si l'envie ou un doute le prenait, il pourrait très bien vérifier si le mail reçu provient bien ou non du site sur lequel il aurait effectué le test.
.
Par ailleurs, pour avertir les visiteurs (et éventuellement dissuader les éventuels crackers de s'en servir comme base de "travail"), l'alerte suivante est affichée à l'arrivée sur le site :
-----
Ce site :
-- n'envoie AUCUN mail en dehors des mails-résultat aux tests ;
-- ne demandera JAMAIS de mise à jour de vos infomations ;
-- ne sollicitera JAMAIS d'inscription ou toute action de votre part.
Si vous recevez un mail autre qu'un résultat à vos tests, vous
êtes victime d'une tentative de phishing. Ne répondez pas et
supprimez sans aucune crainte ce mail qui tente de vous abuser !
Prochainement les tests seront signés avec GPG et vous pourrez
en vérifier l'origine en utilisant la clef publique GPG du site.
Pour obtenir la clef cliquez sur le lien Key-ID (0x057CDCB5E97FB471),
présent sur la page d'accueil.
-----
.
Possible que ça ne serve à rien mais je ne vois pas ce que je peux faire et ne vois pas d'éventuelles vulnérabilités dans les pages PHP. Evidemment, le niveau de sécurité est dépendant du niveau de connaissances du codeur. Mais après les avoir vérifiées avec mes connaissances, et à moins d'étudier encore de nombreuses années pour atteindre un niveau hors classe ès sécurité, je n'ai rien vu qui serait susceptible de présenter une faille propre à laisser passer un boeuf.
.
Je ne sais plus où il faut chercher. Par ailleurs, à te lire, je me rends compte que je manque de connaissances : je ne sais pas ce que sont E2E, PCS, TLS... Mais bon, je fais d'abord ce que je peux en me documentant et quand je ne peux plus, je demande de l'aide... D'où ma question.
.
Je ne sais si j'ai été plus clair. Je suis parti sur l'idée PGP mais je ne fais pas une fixation sur cette solution qui ne sert peut-être à rien ; mais bon, je cherche...
.
Merci. Si tu as des idées (voire des solutions)...
19 août 2022 à 16:31
Bonjour,
1. La moindre des choses serait de vérifier la véracité d'un signalement avant de suspendre le site d'un client.
Je suis d'accord avec toi, mais j'ai été mis devant le fait accompli.
3. Ton VPS utilise une version dépassée de Debian
Je sais mais sur ce VPS j'ai 7 sites et je ne suis pas chaud pour tout virer et installer la 11, d'autant plus qu'il y a le site professionnel de ma nièce.
4. Je recommande plutôt la solution "redémarrage depuis zéro". Il vaut mieux ... des scripts Bash ou des solutions comme Ansible.
je prends note de ta recommandation mais il faudrait que je me perfectionne en scripts Bash (je ne connais pas Ansible)
5. Il ne devrait pas y avoir besoin de sauvegarder ton application PHP dans le sens serveur -> PC. En théorie, tu développes sur le PC ou tout autre environnement de développement, et tu "push" vers le serveur...
Vrai. Mais quand on m'a annoncé ça, j'étais à l'hôpital avec mon portable et non à la maisn avec mon PC. Par sécurité et par souci de réactivité, j'ai tout copié de suite et supprimé sur le serveur en me disant que j'aurai le temps de vérifier tous les fichiers récupérés.
Pour ce qui concerne les courriels, je vais reprendre ta réponse point par point car il y a là de la matière à apprendre (genre DKIM et autres). je pense qu'il faudra d'abord faire en sorte que Postfix me paraisse facile à configurer et à mettre en oeuvre de façon sécurisée. Il y a donc du travail... ;-) Comme je ne peux pas passer mon temps à demander "Au secours !", (les gens ont autre chose à faire). Je suis plutôt maintenant demandeur de liens où je pourrais peaufiner l'affaire "mail" plutôt qu'espérer des réponses encyclopédiques complètes comme tu fais. J'apprécie beaucoup car tu mets le doigt sur les vrais problèmes et tu passes du temps à expliquer mais je suppose que tu as d'autres choses à faire...
Même si elle n'est pas présentement et complètement résolue, je mets la question comme telle car tu m'as donné les éléments nécessaires pour me mettre sur la voie de la résolution.
Merci infiniment.
(Et bonnes vacances si elles ne sont pas encore prises, sinon, bonne reprise).