Expiration certificat root Let’s Encrypt’s

Guillaume - ingénieur systèmes 1 octobre 20211 octobre 2021

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 !

Configurer un vrai cron pour WordPress

Guillaume - ingénieur systèmes 3 septembre 20213 septembre 2021

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

define('DISABLE_WP_CRON', true);

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).

http://monsite.com/wp-cron.php?doing_wp_cron

1	http://monsite.com/wp-cron.php?doing_wp_cron

Piqûre de rappel cybersécurité : Pegasus

Guillaume - ingénieur systèmes 23 juillet 202129 juillet 2021

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 :

Exploitation des failles zéro-day :
Il s’agit de failles qui ne sont pas encore documentées ni patchées. La cybersécurité a toujours reposé sur la découverte précoce et la mise à jour des failles par les « gentils » contre les « méchants ».
Logiciels invisibles :
Les keyloggers et autres « joyeusetés » ont toujours existé et existeront toujours. Précisons qu’il est même possible pour des logiciels d’être totalement invisibles du système car hors du système lui-même, et ce depuis des décennies.
Fishing :
il s’agit de l’ancien vecteur d’attaque par envoi de faux mails, sms, etc … et qui ne devrait pas inquiéter un utilisateur averti tel que vous !

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 :

vos sites et applications doivent utiliser les dernières versions supportées et à jours des logiciels et systèmes (Ubuntu, Window server, php, mysql, aspx, wordpress, etc)
les mots de passes doivent être stockés de façon cryptée et il ne doivent pas être décryptable.
vos données doivent être backuppées afin qu’elles soient recouvrables en cas de destruction ou altérations.
l’envoi d’un mot de passe devrait se faire via un formulaire en https pour éviter une interception.

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 :

protégé par un pare-feu physique – doté des dernière technologies d’IPS et de ARBOR –
mis à jour 24h après la parution d’une mise à jour système
sauvegardé sur 7 jours
Nous n’acceptons pas moins !

Win Pro: SSL / Https Rating A+

Guillaume - ingénieur systèmes 18 juin 202110 mars 2022

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.

Comment vérifier vos certificats SSL

Guillaume - ingénieur systèmes 26 mai 20213 juin 2021

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.

Vérifier que le certificat match avec la clef

# 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.

# 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.

Vérifier un certificat pem « fullchain »

#
# 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)

# 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)

Vérifier que les dates sont valides

$ openssl x509 -noout -in {example.com}.pem -dates
notBefore=Apr 12 19:51:31 2021 GMT
notAfter=Jul 11 19:51:31 2021 GMT

$ openssl x509 -noout -in {example.com}.pem -dates

notBefore=Apr 12 19:51:31 2021 GMT

notAfter=Jul 11 19:51:31 2021 GMT

Renforcement sécurité Ubuntu Mutualisés

Guillaume - ingénieur systèmes 17 décembre 201917 décembre 2019

Bonjour,

Afin de lutter plus efficacement contre les bots et réduire de plus de 90% le trafic généré par ceux-ci,

Nous renforçons ce jour la sécurité de nos Ubuntus Mutualisés :

blocage par ip
blocage par referer
blocage par user agent
blocage de la page xmlrpc.php

Ces listes sont mises à jour quotidiennement.

Si toutefois vous constatiez une gêne (erreur 403), merci de faire un support afin d’évaluer la situation.

Migrer votre WordPress en https

Guillaume - ingénieur systèmes 16 avril 201917 avril 2019

Il ne suffit pas d’activer un certificat, voici les actions à faire.

1. Installer le certificat ssl

2. Modifier l’url dans WordPress

Rendez-vous dans l’administration de votre WordPress, section Réglages > Général. Il vous faudra modifier l’url en https.

3. Modifier les urls dans la base de donnée

Nous recommandons l’utilisation de ce script gratuit en license GPLv3 :
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

4. Rediriger en https permanent

Sous Apache, la modification se fait dans le fichier de configuration via l’interface prévue à cet effet ou dans le fichier .htaccess (nous recommandons la première méthode).

Sous IIS, voici une méthode simplifié :
https://blog.rdmedias.com/iis-7-redirect-force-et-fixe-http-https
ou une méthode plus avancée :
https://aboutssl.org/iis-redirection-http-to-https/

5. Mettre à jour le fichier robot.txt

http://robots-txt.com/ressources/robots-txt-https/

6. Déclarer votre site en HTTPS sur Google Search et recharger la sitemap

A priori pas besoin car désormais google n’implique pas de modification de HTTP > HTTPS :

https://support.google.com/webmasters/answer/83106?hl=fr

7. Mettre à jour sur Google Analytics

8. Tester sur www.sslabs.com/ssltest/

ASP.NET 4.0+ Request Validation Error et Web.config Ciblé

Guillaume - ingénieur systèmes 9 janvier 20189 janvier 2018

Le problème à résoudre concerne la « Request Validation » qui empêche de recevoir certains caractères comme notamment les balises < … >
Il s’agit d’une requête POST qui sera traitée, analysée puis enregistrée via LINQ, les strings seront donc « parameterized ».
Cependant, cela n’est pas le cas de l’ensemble du site nous devons donc appliquer cela à une zone donnée.

validateRequest= »false »
ce paramètre permet de supprimer la validation en .NET 2.0
Il s’insère soit dans la page ciblée :

<@ Page validateRequest="false" %>

1

<@ Page validateRequest="false" %>

soit dans le fichier Web.config :

<configuration> <system.web> <pages validateRequest="false" /> </system.web> </configuration>

1
2
3
4
5

<configuration>
  <system.web>
    <pages validateRequest="false" />
  </system.web>
</configuration>
<httpRuntime requestValidationMode= »2.0″ />
A partir d’ASP.NET 4 ou plus, cet élément du Web.config est indispensable pour que l’annulation du REQUEST VALIDATION soit prise en compte.
En effet, depuis ASP.NET 4, la validation de la requête se fait plus tôt dans le cycle de vie de la page.

<system.web> <httpRuntime requestValidationMode="2.0" /> </system.web>

1
2
3

<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>

« location » : Ciblage d’une page ou d’un répertoire
La touche finale, il faut impérativement n’affecter que les pages concernées, à cette fin nous utilisons un élement du Web.config qui permet de cibler une location :

<configuration>
  <location path="UploadPage.aspx">
    <system.web>
      <httpRuntime maxRequestLength="128"/>
    </system.web>
  </location>
</configuration>

<system.web>

</system.web>

</location>

</configuration>

Le résultat final est celui-ci :

<location path="DMZdirectory">
  <system.web>
    <httpRuntime requestValidationMode="2.0" />
    <pages validateRequest="false" />
  </system.web>
</location>

<system.web>

</system.web>

</location>

Sources :
https://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/b6x6shw7(v=vs.100).aspx

CRON UNIX: faire un bon script php

Guillaume - ingénieur systèmes 14 mars 2017

En mode « URL », tout CRON UNIX tente de télécharger la page.
Ainsi, si aucune information n’est reçue par l’outil de téléchargement, celui-ci considère qu’une erreur est survenue (time-out) et tente à nouveau le téléchargement.
Cela peut avoir des conséquence extrêmement violente comme l’écroulement de la machine ou des erreurs de données.
Aussi, TOUT script php ayant vocation a être utiliser comme CRON ne peut se prémunir du code suivant :

<?php
ob_end_clean();
header("Connection: close");
ignore_user_abort(); // optionnel
ob_start();
$size = ob_get_length();
header("Content-Length: $size");
ob_end_flush(); // ne fait rien tant que ...
flush(); // les deux sont appellés
// SCRIPT ICI, et ICI seulement !!!! 
?>

<?php

ob_end_clean();

header("Connection: close");

ignore_user_abort(); // optionnel

ob_start();

$size = ob_get_length();

header("Content-Length: $size");

ob_end_flush(); // ne fait rien tant que ...

flush(); // les deux sont appellés

// SCRIPT ICI, et ICI seulement !!!!

Nous ne pourrons être tenu responsables des dommages occasionnés par un script mal écris. Il en est de la responsabilité du client d’informer son développeur.

IIS Rewrite : SEO rewrite language

Guillaume - ingénieur systèmes 12 avril 2016

Voici comment interpréter une url et la transformer

<rule name="Rewrite lang fr" >
    <match url="^(en|it)/([^/]+)/?$" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
    </conditions>
    <action type="Rewrite" url="/{R:2}?lang={R:1}" appendQueryString="true" />
</rule>

</conditions>

</rule>

Actualités, interventions et astuces en hébergement

Author: Guillaume - ingénieur systèmes