alh

Membre des forums
  • Compteur de contenus

    17
  • Inscription

  • Dernière visite

À propos de alh

  • Rang
    Nouvel Inscrit

Visiteurs récents du profil

862 visualisations du profil
  1. 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
  2. Dans ce cas, vous pourriez peut-être faire remonter l'info à qui de droit ? Edit : et quid des serveurs SMTP smtp.web4all.fr (certes, ils proposent le chiffrements, mais faudrait peut-être faire un cleanup des suites supportées : https://tls.imirhil.fr/tls/smtp.web4all.fr:465
  3. Ok, je note, mais gardez l'idée sous le coude quand même...
  4. Ok, merci de l'info
  5. Bonjour, J'ai lu dans le post ci dessous qu'une réflexion semblait lancée sur le support de IPv6. C'est toujours d'actualité ? et si oui, une ETA (même très vague) pour la mise en prod ? Merci.
  6. Ceux qui sont présentés sur cette page fonctionne pas trop mal a ce qui parait sur les pages perso de Free, donc ca devrait pas trop poser de problème chez W4A
  7. Hello, Une idée de la date de disparition de SSLv3 sur les hébergements mutualisés ? Tous les sites mutualisés en HTTPS utilise SNI, cependant SSLv3 ne le supporte pas, donc un client qui ne supporte que SSLv3 ne pourra de toute façon pas se connecter... Dans la même logique, supprimer les ciphers vulnérables (RC4, 3DES &Co) serait aussi un plus, puisse qu'ils ne sont utiles qu'avec les clients qui supportent uniquement des protocoles obsolètes. Idées pour la chaine de ciphers de mod_ssl SSLCipherSuite EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES:!CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES SSLHonorCipherOrder on SSLProtocol all -SSLv2 -SSLv3 SSLStrictSNIVHostCheck On SSLCompression off Merci d'étudier la question.
  8. Je remonte le sujet pour demander une petite évolution de config. J'ai l'impression que smtp_tls_security_level = may n'est pas actif sur les serveurs smtp relais pour l'envoi de mail depuis les sites web. Je me trompe peut être mais c'est ce que j'ai cru lire en regardant les en-têtes des emails envoyés depuis les sites web. Dans main.cf # TLS parameters smtpd_tls_cert_file=/etc/ssl/cert.cert smtpd_tls_key_file=/etc/ssl/private.key # log TLS connection info smtpd_tls_loglevel = 1 smtp_tls_loglevel = 1 # enable opportunistic TLS support in the SMTP server and client smtpd_tls_security_level = may smtp_tls_security_level = may # if you have authentication enabled, only offer it after STARTTLS smtpd_tls_auth_only = yes tls_ssl_options = NO_COMPRESSION # TLS config smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3 lmtp_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_ciphers=high smtpd_tls_eecdh_grade=ultra,strong tls_high_cipherlist=EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:DHE+AESGCM:EECDH+AES:DHE+AES:AESGCM:AES:!CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES:!SEED:!IDEA Dans master.cf submission inet n - n - - smtpd -o smtpd_tls_security_level=may -o tls_preempt_cipherlist=yes Je ne sais pas si lmtp est également utilisé, mais dans ce cas, il faut dupliquer les lignes de code et utiliser lmtpd_ ou lmtp_ (mais faut lire la doc si la communication passe par un socket unix).
  9. Bonjour à toute l'équipe, Je poste 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) : 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.
  10. Il me semble que la fondation de W4A (et les services proposés) sont justement une réponse aux GAFAM : rendre Internet à son origine : un réseau de réseau où tous le monde peu devenir pleinement acteur du réseau... Si je regarde du côté de votre site, je lis ceci dans les buts pourquivi par l'association : Vous permettre d'héberger votre site internet sur une infrastructure de qualité sans publicité ; La création et l'aide à la création de site internet (portails pouvant regrouper sites, galeries photos, forums de discussion, wiki...) ; Promouvoir les logiciels et plates-formes libres ; Ces 3 points me sont très proche de l'idée sous-jacente à la création du collectif CHATONS. Si ce n'est pas pour proposer une offres alternative, robuste et accessible à tous, je suppose que vous ne seriez pas passer à l'action, ceux qui ont les compétence et la bande passante seraient auto hébergés, les autres seraient tributaires des principaux acteurs du marché, pour qui la rentabilité passe souvent en priorité (attention, j'ai pas dit tout le temps). Je n'ai aucun site chez les hébergeurs principaux, je suis soit sur de l'associatif, soit chez des acteurs de moyenne taille de l'hébergement qui disposent de leur propre datacenter pour mes sites perso (idem pour mes sites "pro"), c'est un choix que j'assume pleinement et qui me ravi pour le moment. Sur le temps et l'argent à investir, travaillant bcp dans l'associatif je connais plutôt bien les contraintes en ressources techniques, financières et humaines. Je ne vois pas le collectif CHATONS comme la nécessité de maintenir un service par vos propres soins, mais plutot l'idée d'encourager vos utilisateurs à mettre en place eux mêmes des instances Frama* (par exemple via vos assistants de "publication web) : soit à l'aide d'un script développé par W4A soit via les possible serveurs virtuels (que je n'ai pas encore eu le temps de tester (honte sur moi).
  11. Bonjour à tous, Framasoft souhaite lancer le collectif CHATONS : « Suite à la mise en place de la campagne Dégooglisons Internet, Framasoft souhaite impulser la création d’un Collectif d’Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires (C.H.A.T.O.N.S. ! :-p ). Ce collectif rassemblerait les organisations souhaitant proposer des services alternatifs à ceux de GAFAM (Google, Apple, Facebook, Amazon, Microsoft), respectueux de la vie privée des utilisateurs. Le projet n’en est qu’à ses débuts et ne sera pas ouvert au public avant plusieurs mois, mais ce billet permet d’informer les actuels hébergeurs de services libres de l’initiative. » Il me semble que le concept correspond pas mal à l'idée derrière Web4all... Z'en pensez quoi ?
  12. Pour info : Online automatise maintenant l'utilisation de SSL avec des certificats Let's Encrypt pour les domaines hébergés sur leurs offres mutualisées. Si vous avez un hébergement chez eux, il suffit de vous connecter en HTTPS à votre site et zou... un certificat SSL valide pour les utilisateurs de votre site.
  13. Suite a un ticket de support, je suis aussi partant !
  14. Je me répond à moi même : C'est possible dans Liste des services » Gestion du service <nom_du_service> » Publication web (HTTP) Puis dans "Action" (bouton jaune-orange en bas à droite de la section "Infrastructure publication Web mutualisée (Apache)"), il suffit de cliquer sur "Modifier les points de montage" et d'éditer correctement le champs correspondant.
  15. La config est la suivane : (Service A) Registrar avec NS des domaines pointants vers Service B -> (Service B ) Name Servers indépendants avec Zone DNS avec IP de l'hébergement Web4All -> (Service C) Hébergement Web4all