Classement


Contenu populaire

Affichage du contenu avec la meilleure réputation depuis le 17/04/2017 dans Messages

  1. 4 points
    Petite pointe de nostalgie en buvant mon café ce matin, premier mug attrapé, bam!
  2. 4 points
    Je tenais à remercier toute l'équipe pour l'intégration efficace des certificats Let's Encrypt. Enfin le SSL gratuit pour tout le monde. Cordialement, Manu
  3. 3 points
    Bonjour à tous !!! Je découvre la nouvelle maison, je fais le tour et je dois dire que la bâtisse a l'air sympa Après Jean-Emile.com, EG-Hosting et Web4all, l'aventure continue avec yulPa Au plaisir de se croiser sur ce forum Bon courage à l'équipe pour les dernières finitions. Bonne soirée.
  4. 2 points
    C'était attendu depuis longtemps et c'est en effet très appréciable. Merci! :-)
  5. 2 points
    Il faut l'avouer et le reconnaitre le travail fait par l'équipe est remarquable. Bravo en ce qui concerne le passage à Yulpa cela valait le coût d'attendre quelque jours de plus !
  6. 2 points
    Bonjour à toute l'équipe, Je reposte ici une demande d'évolution concernant la config SSH (côté serveur) de ssh.web4all.fr (et qui concerne aussi sans doute tous les serveurs w4a utilisant SSH) qui était sur l'ancien forum. Première chose le bout de code à ajouter à /etc/ssh/sshd_config : HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_rsa_key KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com UsePrivilegeSeparation sandbox AuthenticationMethods publickey,keyboard-interactive:pam UsePAM yes Seconde, le constat : https://tls.imirhil.fr/ssh/ssh.web4all.fr:22 Comme le montre très bien CryptCheck, la config SSH est un peu faiblarde (particulièrement au niveau chiffrement et MAC). Maintenant le pourquoi du bout de code : pour renforcer sensiblement la sécurité et l'intégrité des données échangées avec les clients modernes qui supportent des chiffrements forts et laisser cependant les clients obsolètes se connecter tout de même sans souci. L'utilisation de clefs serveurs ed25519 et ecdsa ne devrait pas trop surcharger les serveurs, alors que RSA reste présent pour la compatibilité. Edit : c'est également dans les recommandations de Mozilla concernant la sécurité : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Merci d'étudier la demande a l'occasion. Et je rajoute -- pour ceux que cela intéresse -- le pendant pour la config SSH client (Protocol 2 uniquement, évidement) : # Pour chaque Host, des règlages spécifiques, qui peuvent écrasés ceux défini de manière générale (cf. section Host *) : Host 10.0.0.1 IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host myvnc.example.org User root IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host ssh.example.net User xxx-w4a IdentityFile ~/.ssh/id_ecdsa_key_ssh.example.net IdentitiesOnly yes Host www.example.net User web IdentityFile ~/.ssh/id_ecdsa_key_web.example.net IdentitiesOnly yes Host xyz.example.com User username IdentityFile ~/.ssh/id_ed25519_example.com IdentitiesOnly yes Host 192.168.* IdentityFile ~/.ssh/id_ed25519_local_lan IdentitiesOnly yes Host *.biz User username IdentityFile ~/.ssh/id_ed25519_local_business_lan ForwardAgent yes IdentitiesOnly yes Host github.com User username MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-128-etm@openssh.com,hmac-sha2-512 IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes # Config général pour tous les hosts et ceux non définis ci-dessus : Host * Protocol 2 # SSH v1 est à éviter absolument ! SendEnv LANG LC_* IdentitiesOnly yes HashKnownHosts yes StrictHostKeyChecking ask CheckHostIP yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes X11Forwarding no ConnectTimeout 30 HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com # Cipher ... est commenté puisse que ne concerne que SSH v1 # IdentityFile ~/.ssh/id_rsa aucune clef n'est proposée par défaut, elle doit être définie spécifiquement pour chaque serveur. Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr ServerAliveInterval 10 ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p L'utilisation de IdentitiesOnly yes permet de limiter les clefs SSH envoyées pour l'identification aux seules clefs spécifiées pour le serveur en question. Cela évite à un serveur de récupérer le fingerprint de toutes les clefs (coucou le tracking des utilisateurs) alors qu'il existe une clef spécifiquement dédiée pour celui-ci
  7. 2 points
    Même si j'ai eu l'opportunité de vous féliciter en privé, je renouvelle ici mes félicitations pour le travail réalisé et le grand bon en avant du manager Je souhaite à :YulPa une longue vie pleine de succès !
  8. 2 points
    Salut les gens, Une migration en douceur, de nouvelles fonctionnalités au rendez vous. Vraiment bravo à l'équipe
  9. 2 points
    Bonjour les gens, Comme déjà dit sur Twitter, bienvenue à :yuLpa ! Félicitations pour ce lancement, la migration et le nouveau iWal v2. Du bon boulot !
  10. 2 points
    Holla Yulpa Bravo pour cette migration sans encombres et merde pour la suite
  11. 2 points
    Bonjour, Merci à vous pour tout le travail effectué et la qualité de votre service. On attend à chaque fois chacune des améliorations avec impatience. Je suis là depuis Eg-hosting et je n'ai jamais été déçu.
  12. 1 point
  13. 1 point
    Bonjour, Très bien fait, on s'y retrouve assez facilement. Par contre, j'ai procédé au renouvellement d'un site et au moment de payer par carte bleue, je me suis retrouvé sur la page avec les statuts et le règlement intérieur de Web4all. A supprimer je pense Bon courage à tous. Pascal
  14. 1 point
    Bonjour, vous indiquez utiliser Apache en version 2.2 pour les hébergements; est-ce que vous pensez à passer prochainement en version 2.4 ? Jérôme
  15. 1 point
    Bonjour, c'est en cours de travail. Malheureusement, cette modification impose pour nous de travailler sur la création de nouveaux pool HTTP en apache2.4 Le monde de l'hébergement mutualisé est difficile en cas de changement majeur comme cette version de apache (htacces principalement) Dans le CMS à jour, on retrouve la prise en charge des deux règles de nommage pour certaines instruction qui permet d'assurer une compatibilité 2.2 et 2.4 + Mais de ce que j'ai vu, la grand majorité des .htacces seront non fonctionnels pour niveau gestion d'accès à une ressource. La question se pose donc . Basculer sur 2.4, et imposer aux clients de modifier leur .htaccess (sachant qu'il n'y à pas de risque d'exposer des données protégées par htaccess) une erreur 500 certainement sera affichée. Où mettre en place ce que nous voulons faire depuis 3 ans, diviser notre infrastructure HTTP en plusieurs pools . Des pools pourront rester en 2.2 et des nouveaux en 2.4 Donc, oui nous souhaitons passer en 2.4+ , prochainement oui, mais c'est quand même l'affaire de quelques mois.
  16. 1 point
    Le dieu google dit : Donc effectivement on devrait faire du 301 au lieu du 302 Sachant que l'impact qu'il peut y avoir niveau SEO c'est quand un client qui à un site en HTTP indexé décide de le passer un HTTPS . Le 302 n'est la meilleure chose. A modifier
  17. 1 point
    Et mieux vaut passer directement par iWal pour ce redirect si tout sur le site a bien été passé en https (appel des images, js et css notamment). Rappelons ce script vraiment facile à utiliser pour les modifs dans la base de donnée : https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
  18. 1 point
    Bonjour, je ne comprends pas l'intérêt Soit vous effectuez la redirection avec iWal soit avec un .htaccess Mais si la redirection est effectuée avec iWal, le .htaccess ne sert à rien
  19. 1 point
    A ben vous avez pensé à tout Bon, ben je vous laisse bosser alors
  20. 1 point
    Le programme partenaire et le programme revendeur seront là pour cela
  21. 1 point
    Une option dans les paramètres utilisateurs sera parfait et c'est le plus simple à déployer
  22. 1 point
    toutafé Si on parle de pack, mon idée était bien de les multiplier pour éviter de tout centraliser sur le mien. Autre idée si l'assistance est pour vous un problème : mon client commande un pack "start sans assistance" qui serait rattaché au mien. Les demandes d'assistance ne peuvent alors que passer par le compte principal, donc moi. Le jour ou ce client décide de ne plus travailler avec moi, ce pack start est "libéré", cad détaché du mien, je perds la petite réduction correspondante et le client restera probablement chez vous puisque tout fonctionne déjà. La seule différence sera pour lui la possibilité d'ouverture de tickets.
  23. 1 point
    Ca va devenir un object de collection
  24. 1 point
    Un htacces que je trouve bien foutu et dont il est facile de s'inspirer : https://gist.github.com/ludo237/5857215
  25. 1 point
  26. 1 point
    On ne permettra pas d'importer sa CSR pour Let's Encrypt. Celui qui veut utiliser sa CSR dans ce cas doit générer le certificat LE et l'importer dans le magasin SSL comme un certificat normal.
  27. 1 point
    c'est pourtant juste à côté dans le manager...
  28. 1 point
    Ca en parle d'ailleurs sur le compte Twitter de :yuLpa :
  29. 1 point
    Je ne sais pas vraiment où tu veux en venir car mes connaissances sont assez limitées à ce sujet mais il me semble que pour l'importation des clefs est possibles et disponibles : Services / (Hébergement) / Publications web / Dépôts certificats SSL / Importer un certificat
  30. 1 point
    Ca se passe sur l'iWal : Services / (Hébergement) / Publications web / Générateur Let’s Encrypt Tu peux aussi procéder ainsi : Services / (Hébergement) / Publications web / Domaines web Tu cliques sur le domaine de ton choix et ça se passe en bas à droite : Configuration SSL.
  31. 1 point
  32. 1 point
    Bonne nouvelle. J'ai hâte de pouvoir tester ce service.
  33. 1 point
    Suite à la mise en production de iWal v2, nous allons proposer le service tâches planifiées (cron). Nous avons encore des tests de validation à effectuer et pour le moment nous priorisons les corrections liées à la reprise des clients de Web4all. Le module de cron devrait être pleinement opérationnel d’ici fin avril. Afficher l’article complet
  34. 1 point
    On peu aussi faire du 2 facteurs avec SSH, mais c'est peut-être un poil trop geek ? https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-Factor_Authentication_.28OpenSSH_6.3.2B.29
  35. 1 point
    Bonjour plow Essaye ceci : # REDIRECT HTTP to HTTPS RewriteCond %{HTTPS} on RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  36. 1 point
    Bonjour, je vous remercie d'avoir (de nouveau) posté cette demande. Je vais l'étudier et valider sur les serveurs SSH publique pour l'accès client. C'est effectivement très pertinent . Merci !
  37. 1 point
    Bon, je ne sais pas si il est très pertinent d'ouvrir une discussion par idée, mais bon, je continue le déroulé de mes envies Un outil de gestion de listes de diffusion (modération, contribution réservée au membres)
  38. 1 point
    Hum cela fait bien deux ans
  39. 1 point
    Bonjour, vous pouvez modifier cela dans vos préférences