3 MAJ avec reboot obligatoire.
Les serveurs infogérés sont traités cette nuit.
3 MAJ avec reboot obligatoire.
Les serveurs infogérés sont traités cette nuit.
De nombreux supports arrivent nous indiquant que le HTTPS ne fonctionne pas et qu’il nous faut mettre à jour le certificat. Cependant, le problème est bien plus complexe et ne dépend pas de notre volonté.
En effet, la vérification d’un certificat est un processus où l’ont remonte une chaine de confiance. Nous livrons un certificat lui même pointant vers un autre certificat d’une plus haute autorité et cela jusqu’à une autorité que le client (Edge, Mozilla, Firefox, Safari, Openssl, etc) saura reconnaitre comme de confiance.
Il faut noter que le client, s’il n’est pas mis à jour ne sera pas à jour des certificats de confiance et ne pourra donc pas identifier les certificats plus « modernes ».
Or, les certificats let’s encrypt pointent vers plusieurs certificats root dont l’un d’eux est obsolète à la date du 30 septembre 2021. Voici une explication de letsencrypt.org eux même :
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
letsencrypt.org nous informe qu’il faut mettre à jour les clients vers une version supportée où alors une alerte de sécurité sera émise par le client. Cela n’est pas un problème pour l’absolue majorité des clients qui tiennent leurs machines et systèmes à jour mais le devient si on utilise de vieux appareils, voici la liste de compatibilité :
https://letsencrypt.org/docs/certificate-compatibility/
Nous invitons tous nos partenaires à mettre à jour leurs systèmes, cela est d’autant plus important qu’ils s’exposent à des risque de sécurité important s’ils utilisent des outils et navigateurs obsolètes !
Bonjour,
Ce petit tutoriel a pour vocation de configurer les crons WordPress manuellement afin d’éviter leur empilement qui peut être du à plusieurs problèmes dont des modifications au niveau des timezones ou tout simplement le code de WordPress qui n’est pas « thread-safe ».
La première étape consiste à supprimer l’automatisation de ce cron dans le fichier wp-config.php
1 |
define('DISABLE_WP_CRON', true); |
L’étape suivante consiste à créer un cron pour l’url dans notre console d’infogérance RD serveur pour lancer automatiquement le cron par URL à la fréquence souhaitée (attention à ne pas lancer le cron par fichier).
1 |
http://monsite.com/wp-cron.php?doing_wp_cron |
Salutations,
Nous profitons de l’actualité pour faire un rappel en matière de cybersécurité.
Tout d’abord, Pegasus n’invente rien en matière de cyberattaque, tout ce que fait Pegasus existe déjà et cela depuis l’aube de l’internet, expliquons :
Cependant, Il faut être rassurant, les attaques zéro-day coûtent très cher. Les failles se négocient parfois pour plusieurs millions et une simple attaque peut coûter des dizaines de milliers d’euros. Vos données en valent-elles ce prix ? Pour un site standard, il est beaucoup plus probable, et certain, de faire face à des attaques concernant des bugs connus et pour lesquelles il suffit d’être à jour.
Dès l’instant où une machine est connectée à internet, la cybersécurité ne repose pas sur l’établissement d’un verrou inviolable – car impossible – mais sur des comportements réduisant les risques et les données volées. L’effort fourni par les parties concernées doit être proportionnel à la valeur des données à protéger. Concernant le détenteur d’un hébergement, nous attendons de celui-ci qu’il respecte des règles élémentaires :
Enfin, il est important d’avoir conscience qu’un site internet vieillit et périme ! Afin d’éviter cela, il vous faut le mettre à jour régulièrement : au moins une fois par an.
Chez RDmédias, la sécurité de nos clients est importante ainsi chaque hébergement est à minima :
Une MAJ importante de sécurité avec reboot obligatoire est à effectuer sur vos Windows.
Tous les serveurs infogérés seront traités cette nuit par nos services.
Pour tester la sécurisation de votre site vous pouvez utiliser ce site :
https://www.ssllabs.com/ssltest/
Afin que vos résultats soient privés, veuillez cocher la case « Do not show the results on the boards » .
Une explication du Rating ce trouve ici (anglais) :
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
Ce qui dépend de votre IIS sera principalement les « protocoles » et les « ciphers ».
Un outil permet de configurer cela simplement (download > gui) :
https://www.nartac.com/Products/IISCrypto/
Concernant les protocoles,
Seul TLS 1.2 et 1.3 ne sont pas obsolètes.
Il est à noter que IIS ne supporte pas TLS 1.3.
Concernant les ciphers,
Diffie-Hellman est obsolète.
Une configuration correcte en 1.2 est la suivante :
Pour obtenir la note de A+, il faudra un certificat en RSA 4096 bits ou plus.
Les certificats « Let’s Encrypt » sont par défaut en RSA 2048 bits ou RSA 3072 bits ce qui limite la note de la clef respectivement à 80% ou 90%.
Plus la clef est grande plus le protocole HTTPS en sera ralenti. Ce qui est gagné en « sécurité » est perdu en rapidité.
Pour obtenir du TLS 1.3 tout en gardant votre site Asp sur du IIS, nous proposons des serveurs de reverse proxy sous Ubuntu + Apache.
Trois MAJ importantes avec reboot obligatoires sont à effectuées sur vos Windows.
Tous les serveurs infogérés seront traités cette nuit par nos services.
Ce tutoriel concerne le système Ubuntu et tous les systèmes utilisant openssl.
Note importante, par défaut les commandes openssl ne traitent que le premier certificat d’une chaine.
1 2 3 4 5 6 7 8 9 10 |
# Executer cette commande avec la clef : $ openssl rsa -noout -modulus -in {example.com}.key | openssl md5 # Executer cette commande avec le csr : $ openssl req -noout -modulus -in {example.com}.csr | openssl md5 # Executer cette commande avec le certificat : $ openssl x509 -noout -modulus -in {example.com}.crt | openssl md5 # Si les 3 resultats sont identiques alors le csr a bien été créer avec cette clef. |
1 2 3 4 5 6 7 8 9 10 11 12 |
# # L'erreur la plus commune viens d'erreur de copier-coller lors d'une fabrication manuelle du pem contenant la chaine et les différents certificats d’autorité. # Exécuter cette commande avec le fichier pem : $ openssl crl2pkcs7 -nocrl -certfile {example.com}.pem | openssl pkcs7 -print_certs -noout subject=CN = blog.rdmedias.com issuer=C = US, O = Let's Encrypt, CN = R3 subject=C = US, O = Let's Encrypt, CN = R3 issuer=O = Digital Signature Trust Co., CN = DST Root CA X3 # Le premier sujet est notre site suivit de son "issuer". # Ensuite nous avons une chaine avec chaque "issuer" égal au "subject" suivant # Enfin, nous finissons avec le certificat ayant un issuer Root (ou proche) |
1 2 3 |
$ openssl x509 -noout -in {example.com}.pem -dates notBefore=Apr 12 19:51:31 2021 GMT notAfter=Jul 11 19:51:31 2021 GMT |
Vous avez pu remarquer que dans notre console d’infogérance certaines fonctions au niveau du serveur de mails sont manquantes.
Suite à la dernière MAJ de Icewarp nous avons pu découvrir que certaines commandes à l’API ont été modifiées ou non fonctionnelles. Après quelques nuits blanches, nous avons pu corriger dans l’urgence le listing et la création des emails.
Une nouvelle section pour la gestion des emails est en cours de finalisation, utilisant les dernières technologies (aspx + jquery + json + html5) elle devient nettement plus fluide avec une ré écriture complète de nos services qui discutent avec l’API de Icewarp et les nouvelles options apportées par les dernières MAJ. Je pense qu’on pourra publier nos travaux semaine prochaine, il nous reste plus qu’à ajouter la couche de sécurité / RD serveur.
Concernant les mots de passe, suite aux normes RGPD européennes ils ne seront désormais plus accessibles aux administrateurs des sites. Aussi pensez désormais à renseigner l’email alternatif qui vous permettra de re générer un nouveau mot de passe en cas de perte de ce dernier. Cet email peut être également renseigné dans les webmails.
Hébergement vôtre.
Trois MAJ importantes avec reboot obligatoires sont à effectuées sur vos Windows.
Tous les serveurs infogérés seront traités cette nuit par nos services.