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 Nico C. . É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 Denis Dordoigne . É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 ted (site web personnel) . Évalué à 7.
Oui, mais:
Pour les Perso, c'est nada…
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: SSH
Posté par GG (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 Nico C. . É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 Zenitram (site web personnel) . Évalué à 4.
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.
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 Anonyme . Évalué à 3.
Tu peux faire du sftp sur ces offres.
[^] # Re: SSH
Posté par Zenitram (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)
[^] # Re: SSH
Posté par Anonyme . Évalué à 5.
Faut l’activer dans le manager. C’est actif pour tout le monde depuis 1 an environ.
[^] # Re: SSH
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 28 juillet 2017 à 21:09.
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 Anonyme . Évalué à 3.
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 gUI (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
culenvironnement 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 ze0 . É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 ted (site web personnel) . Évalué à 1.
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 Anonyme . Évalué à 2.
https://linuxfr.org/nodes/112381/comments/1708834
[^] # Re: Confidentialité chez un hébergeur tiers
Posté par mahikeulbody . Évalué à 6.
En l'occurrence, il ne se préoccupait pas tant de OVH que de
[^] # Re: Confidentialité chez un hébergeur tiers
Posté par Big Pete . É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 Zenitram (site web personnel) . Évalué à 3.
C'est complètement HS. Pour faire court :
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 EauFroide . Évalué à 2.
+1 !
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# OVH et sécurité
Posté par Prae . É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 GG (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 xcomcmdr . É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 Colin Pitrat (site web personnel) . Évalué à 0.
Mais as tu déjà vérifié qu'une erreur sur le dernier caractère était détectée ?
[^] # Re: OVH et sécurité
Posté par xcomcmdr . Évalué à 3.
Euh…. Oui.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OVH et sécurité
Posté par oinkoink_daotter . Évalué à 8. Dernière modification le 28 juillet 2017 à 13:35.
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.