Journal Let's Encrypt, OVH et la sécurité

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
13
27
juil.
2017

Bonjour Nal,

Depuis quelques temps, OVH permet à tout leurs clients d'avoir des certificats SSL gratuits grâce à Let's Encrypt. C'est automatisé, y'a rien à faire, et c'est bien!

Mais quel est l'intérêt si pour envoyer des fichiers sur mon hébergement, je n'ai aucune sécurité? En effet, depuis toujours, les hébergements Perso n'ont qu'un simple accès FTP, avec mot de passe non chiffré.
Pour Héberger mon blog, je n'ai pas besoin de 250 Go d'espace, ou de 100 comptes mail de 5Go, ou d'une base SQL de 2Go. Mais une connexion sécurisée, c'est juste essentiel, parce que ni mon FAI, ni l'administrateur du MC Donald ou ses clients, ni l’hôtel qui m'héberge, n'ont à connaître mon mot de passe. La sécurité ne devrait pas être une option.

En l'état actuel, n'importe qui pourrait poster n'importe quoi sur mon hébergement, mais ne vous inquiétez pas: la connexion entre le serveur et votre navigateur est chiffrée.

Qu'en pense tu, Nal? Bon trolldi

  • # SSH

    Posté par  . Évalué à 10. Dernière modification le 28 juillet 2017 à 00:55.

    Je crois que Nal en pense qu'il y a du ssh même sur les hébergements mutualisés : https://docs.ovh.com/fr/fr/web/hosting/mutualise-le-ssh-sur-les-hebergements-mutualises/

    Et si Nal se souvient bien, ça fait au moins 5 ou 6 ans que c'est dispo (Nal dirait bien 10 mais il ose pas…)

    • [^] # j'ai honte

      Posté par  . Évalué à 10.

      Merci d'avoir indiqué ce moyen de pénétration à nal.

      Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

    • [^] # Re: SSH

      Posté par  (site web personnel) . Évalué à 7.

      Oui, mais:

      Qu’est-ce que le SSH et comment en bénéficier ?

      L’utilisation de SSH sur votre hébergement est possible à partir de l’offre Pro (sur les anciennes offres c’est à partir des hébergements de la gamme plan).

      Pour les Perso, c'est nada…

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: SSH

        Posté par  (site web personnel) . Évalué à 1.

        Certes, rien pour les "Perso", mais les "Plan" ont du ssh, et la différence de prix+confort en vaut vraiment le coût/coup.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: SSH

        Posté par  . Évalué à 0.

        Ouais effectivement…

        Mais bon, on parle d'une offre à 2 balles par mois vs une offre à 5 balles par mois.
        Voila.

        Si cette problématique de sécurité est si importante pour OP, ça vaut certainement les 30 ou 40€ par AN en plus.

        • [^] # Re: SSH

          Posté par  (site web personnel) . Évalué à 4.

          Si cette problématique de sécurité est si importante pour OP, ça vaut certainement les 30 ou 40€ par AN en plus.

          Sympa de dire que si tu veux de la sécurité de base, ça coûte en plus.
          Heureusement ce qu'il ont créé Let's Encrypt (et autres logiciels libre liés à la sécurité : openSSL, openSSH…) pensent le contraire.

          Mais bon, on parle d'une offre à 2 balles par mois vs une offre à 5 balles par mois.

          Même à 0, ça devrait être la base que de proposer une connexion chiffrée. C'est en tous cas la communication de Mozilla aussi (cf avertissement quand le mot de passe est transmis en clair), va donc leur dire qu'ils faut qu'ils arrêtent de faire chier les mainteneurs de sites qui proposent que du HTTP.

          Note : OVH propose sur ces mêmes offres du HTTPS, quelle logique? L'OP ou les visiteurs devraient pas payer 30 ou 40€ par AN en plus si ils veulent ça, suivant TA logique?

      • [^] # Re: SSH

        Posté par  . Évalué à 3.

        Tu peux faire du sftp sur ces offres.

        • [^] # Re: SSH

          Posté par  (site web personnel) . Évalué à 0.

          J'ai des offres trop vieilles? autre IP pour le SFTP? (j'ai utilisé les mêmes credentials que pour FTP)

          Statut :    Connexion à ftp.60gp.ovh.net...
Réponse :  fzSftp started, protocol_version=8
Commande :  open "********@ftp.60gp.ovh.net" 22
Commande :  Approbation de la nouvelle clé de l'hôte : Une seule fois
Commande :  Pass: ********
Statut :    Connected to ftp.60gp.ovh.net
Erreur :    Received unexpected end-of-file from SFTP server
Erreur :    Impossible d'établir une connexion au serveur

          Statut :    Connexion à ftp.********...
Réponse :  fzSftp started, protocol_version=8
Commande :  open "********@ftp.********" 22
Commande :  Approbation de la nouvelle clé de l'hôte : Une seule fois
Commande :  Pass: ********
Statut :    Connected to ftp.start.ovh.net
Erreur :    Received unexpected end-of-file from SFTP server
Erreur :    Impossible d'établir une connexion au serveur

          • [^] # Re: SSH

            Posté par  . Évalué à 5.

            Faut l’activer dans le manager. C’est actif pour tout le monde depuis 1 an environ.

            • [^] # Re: SSH

              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 28 juillet 2017 à 21:09.

              C’est actif pour tout le monde depuis 1 an environ.

              Même les docs ne sont pas à jour… ("offre pro" mini)
              Mais en effet je le retrouve dans l'interface, merci de l'indication.

              Pour critiquer quand même un peu : je n'ai pas trouvé où mettre ma clé publique donc le MdP se balade toujours un peu quelque part (mais beaucoup moins à poil quand même! Sans doute largement suffisant pour ce qu'on met dessus), et on ne peut pas désactiver FTP pour bloquer les étourdis (la capture d'écran semble laisser la possibilité, mais ce n'est pas ce que j'ai).

              • [^] # Re: SSH

                Posté par  . Évalué à 3.

                Même les docs ne sont pas à jour… ("offre pro" mini)

                Je remonterai (même si on nous lit déjà :) ).

                En attendant, il y a plusieurs canaux de communication qui seront plus suivi que DLFP, genre la ML Web ou OVH Community.

  • # Confidentialité chez un hébergeur tiers

    Posté par  (Mastodon) . Évalué à -2. Dernière modification le 28 juillet 2017 à 07:55.

    Au delà du fait que oui, SSH ça marche très bien et c'est clairement ce qu'il faut utiliser dans ce cas-là, il ne faut pas oublier ce que c'est de faire héberger sa machine par un tiers.

    Pour faire vite : Il a accès au matériel, DONC il a accès aux données.

    C'est un très gros raccourcis, mais faut pas oublier que dès qu'on a accès au matériel, alors le concept de sécurité (confidentialité dans notre cas) s'effondre. Depuis le "Man In The Middle" (OVH voit passer chacun de vos octets sur le réseau) à une backdoor dans le système qu'il vous a mis, ils ont une myriade de possibilités qui toutes, en théorie, sont capables d'accéder à vos données.

    Cela dit, les moyens de contournement sont aujourd'hui assez simples, surtout si on prend en compte le fait que OVH a vraisemblablement autre chose à faire que d'espionner leurs quelques millions d'hébergement.

    MITM : SSH est considéré aujourd'hui techniquement incassable. Mis à part les méta-données (IP source, date/heure, quantité de données), il ne peuvent rien savoir d'autre. Et mis à part l'auteur de ce journal apparemment :), considérons que tout le monde utilise SSH, donc oublions ça.

    Données sur disque : Idem pour le chiffrage du disque, techniquement incassable aujourd'hui, mais là par contre, qui chiffre son disque ? Déjà que sur un périphérique mobile, facilement volable, pas grand monde ne le fait, là dans le cadre d'un serveur hébergé en salle sécurisée, au milieu de milliers/millions d'autres, je doute que ce soit une grande coutume… Donc oui, ils ont accès assez facilement aux données.

    Trucs tordus : ils pourraient mettre une sonde de debug (style LauterBach) directement sur le CPU pour choper en clair tout ce qui transite dans le CPU. Les moyens sont importants, mais si c'est pour attaquer un hébergement précis, pourquoi pas. Et pour les hébergements virtualisés, là c'est encore plus facile vu que le hardware… est logiciel !

    Voilà donc oui, il faut utiliser SSH et HTTPS, la question ne se pose même pas. Mais la paranoïa absolue n'est pas possible dès lors qu'on fait héberger physiquement ses données ailleurs quand dans son cul environnement maîtrisé. C'est comme ça. Comme toujours en matière de sécurité/confidentialité il faut analyser le rapport risque/moyens pour que concrêtement les moyens mis en oeuvre restent en rapport avec les risques encourus.

    Ma conclusion sur ces sujets :
    - SSH et HTTPS : c'est très bien, presque obligatoire
    - Chiffrage des données sur le disque : c'est mieux, donc si ça peut faire plaisir…

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Confidentialité chez un hébergeur tiers

      Posté par  . Évalué à 5.

      L'auteur parle très clairement de l'offre "Hébergement Perso" d'OVH, dont on peut lire les caractéristiques ici https://www.ovh.com/fr/hebergement-web/hebergement-perso.xml

      Cette offre ne propose qu'un accès FTP pour accéder à ces données, rien d'autre, pas de SSH.

      Tu part sur une approche où l'attaquant serait ovh, ce qui parait surréaliste quand même donc oui de la paranoïa absolue comme tu dis. Si on part une une autre approche un attaquant sur le réseau privé de l'auteur, qui me parait plus réaliste, et un peu moins absolue, il est très facile de récupérer les identifiant du ftp pendant la connexion de l'utilisateur.

      Cette offre est comme ça depuis très longtemps, personnellement ça m’embattait mais je me suis pas plains auprès d'OVH. L'offre étant pratique quand même très peu d'utilisateur ont du se plaindre et donc OVH ne se presse pas pour changer la situation. Il pourrai remplacer le ftp par un sftp par exemple. mais ça leur demande aussi de redévelopper des choses dans l'espace client. Ça reste un investissement qui n'est peut être pas rentable pour eux, pour le nombre d'utilisateur.

      J'invite l'auteur à ouvrir la conversation avec OVH sur le sujet, ça peut pas faire de mal de leur en parler.

      • [^] # Re: Confidentialité chez un hébergeur tiers

        Posté par  (site web personnel) . Évalué à 1.

        J'invite l'auteur à ouvrir la conversation avec OVH sur le sujet, ça peut pas faire de mal de leur en parler.

        Oui, c'est ce que j'ai fait depuis un certain temps déjà (au moins 3 ans, je ne saurais plus dire exactement), mais on m'a juste confirmé que le chiffrement n'existait pas pour les offre Perso. Aujourd'hui OVH propose le chiffrement HTTPS pour les visiteurs, mais toujours rien pour les éditeurs de sites. Peut être devrais-je le refaire, mais je doute vraiment que ça change quelque chose.

        Ils proposent déjà le chiffrement pour les offres Pro, je ne crois pas que l'investissement soit important pour faire de même pour les Perso (qui n'est pas la moins chère d'ailleurs, il y a une offre kimsufi web encore moins chère).
        Ah, il y a bien une option "Sécurisation FTP": ça permet de désactiver l'accès FTP depuis l'interface de gestion du compte OVH. lol -_-

        Au niveau de la confidentialité je ne veux pas faire le paranoïaque, je n'héberge pas de données si sensibles que je dois les cacher à mon hébergeur (ou sinon, je peux chiffrer avant d'héberger). Le chiffrement de la connexion, c'est quand même problème qui vient bien avant, pour pas que n’importe qui écoutant les airs puisse voler mes identifiants.

        Je ne vois pas pourquoi on doit pouvoir voler mes identifiants, simplement parce que je ne suis pas "Pro", la protection de ses clients c'est quelque chose qui devrait être naturel, quels qu'ils soient…

        Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Confidentialité chez un hébergeur tiers

      Posté par  . Évalué à 6.

      En l'occurrence, il ne se préoccupait pas tant de OVH que de

      ni mon FAI, ni l'administrateur du MC Donald ou ses clients, ni l’hôtel qui m'héberge, n'ont à connaître mon mot de passe.

    • [^] # Re: Confidentialité chez un hébergeur tiers

      Posté par  . Évalué à 2.

      Openssh pour le transfert de gros fichiers sur des liaisons qui ont un peu de latence ou un gros débit, ça ne marche pas très bien. Il y a une limitation dans la taille des buffers qui fait que la connexion TCP ne peux pas ajuster sa fenêtre de transmission pour remplir le BDP de ces liaison. Il y a un patch non-officiel pour corrigé ça : hpn-ssh.

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: Confidentialité chez un hébergeur tiers

      Posté par  (site web personnel) . Évalué à 3.

      C'est complètement HS. Pour faire court :

      Pour faire vite : Il a accès au matériel, DONC il a accès aux données.

      Il a un contrat avec OVH, parlant de la confidentialité.
      Pas avec MacDo ni avec les autres personnes dans le MacDo.

      On parle de sécurité de base la (ne pas faire transiter ses mots de passe en clair sur le réseau), pas de sécurité de données classées top défense. Chaque niveau doit avoir sa protection appropriée (non, le FTP n'est pas une protection appropriée de nos jours avec du Wifi partout, mas non se protéger d'un hébergeur n'est pas non plus une protection appropriée pour du contenu perso).

    • [^] # Re: Confidentialité chez un hébergeur tiers

      Posté par  . Évalué à 2.

      Mais la paranoïa absolue n'est pas possible dès lors qu'on fait héberger physiquement ses données ailleurs que dans son environnement maîtrisé.

      +1 !

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # OVH et sécurité

    Posté par  . Évalué à 3.

    L'autre jour, j'auditais un problème de sécurité dans une société, son site avait été hacké et ils étaient hébergés chez OVH. Je découvre que l'attaquant était passé par la base de données et par quelques failles venant du site. Je colmate le tout et je décide de changer tous les mots de passe.

    Stupeur, les mots de passe de base de données mutualisées étaient limitées à 8-12 caractères avec des règles de nomenclatures stupides et totalement pas sécurisées (et probablement sauvegarder le mot de passe en clair). Il a fallu un petit débat avec le support qui ne comprenait pas le problème. On m'a dit que depuis, ils avaient modifié cette règle sur les DBs mutualisées: A confirmer, je n'ai aucun compte chez eux.

    • [^] # Re: OVH et sécurité

      Posté par  (site web personnel) . Évalué à -1.

      Et tu vas découvrir que les mots de passes de connexion à ton compte sont tronquées à 14 caractères (constaté avec stupeur il y a pas mal d'années).
      Et, c'est logique.

      J'avais vu cette contrainte il y a plus de 15 ans, dans SME-server. C'était pour rester compatible avec le réseau Windows. (c'était indiqué comme ça dans la doc).

      Je suppose que cette contrainte existe encore malheureusement aujourd'hui.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: OVH et sécurité

        Posté par  . Évalué à 5.

        Cette contrainte date de Windows 95/98.

        Ça fait 20 ans qu'elle est obsolète.

        Source : je suis sur un domaine, et j'ai un mdp bien plus large que ça.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: OVH et sécurité

        Posté par  . Évalué à 8. Dernière modification le 28 juillet 2017 à 13:35.

        Et tu vas découvrir que les mots de passes de connexion à ton compte sont tronquées à 14 caractères (constaté avec stupeur il y a pas mal d'années).

        Ce sont les "hash" Lan Manager. Ce n'est pas la seule horreur de ce truc.
        Parce qu'en fait, ce n'est pas 14 caractères, mais deux fois 7 (donc deux mots de passes vérifiés indépendamment de 7 caractères).
        Et mis en uppercase.
        Et y a pas de sel (note que c'est toujours vrai dans les bases de hashs windows, même si l'algo a changé, y compris sur l'AD lui même, #yolo)

        C'était utilisé avec les windows 9x et obsolète avec NT4.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.