Piqûre de rappel cybersécurité : Pegasus

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+

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

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

Vérifier un certificat pem « fullchain »

Vérifier que les dates sont valides

Renforcement sécurité Ubuntu Mutualisés

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

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é

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.

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

    soit dans le fichier Web.config :

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

     
  3. « 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 :

     
  4. Le résultat final est celui-ci :

     

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

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 :

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

Voici comment interpréter une url et la transformer

 

IIS Rewrite : Redirect 301 au lieu d’erreur 404

Cette règle est à placer après les rewriting. Elle vérifie si un répertoire ou un fichier existe et redirige le cas échéant.

 

Alerte météo : recrudescence des bots et crawlers de site.

Bonjour,

Les robots sont légion sur internet et peuvent gêner le fonctionnement de votre site :

  • Certains sont « bienveillants » comme googleBot et bingbot qui ne désirent que vous référencer.
  • D’autres sont malveillants et cherchent sans relâche des sites non mis à jour (WordPress, Joomla, etc) afin de les transformer en esclave pour spammer le net.

Dans le premier cas, nous vous recommandons de ne jamais oublier le fichier robots.txt celui-ci est un incontournable et vous ne pourrez vous en prendre qu’à vous même si votre site, ou pire votre serveur devient indisponible lorsqu’un robot (bien que bienveillant) passe par là.

  1. Plus d’information sur le fichier robots.txt ici
  2. Tous les robots bienveillants respectent les paramètres allow/disallow du robots.txt
  3. Certains sont sensibles au paramètre crawl-delay
  4. Concernant googleBot, celui-ci doit aussi faire l’objet d’une attention particulière car google ignore certains paramètres comme « crawl-delay »
    https://www.google.com/webmasters/tools
  5. Concernant bingbot, il n’ignore pas crawl-delay, mais il faut se rendre ici pour affiner certains paramètres :
    http://www.bing.com/toolbox/webmaster/

Dans le second cas, notre pare-feu dispose de règles (dites IPS) qui vous protègent contre certaines requêtes malveillantes.
Toutefois, certains types d’attaques ne sont pas détectables. Nous pouvons affiner ces règles pour votre serveur (notamment Ubuntu), afin d’empêcher un nombre trop important de connections qui pourraient rendre votre site ou votre serveur inaccessible (DDoS).

Cependant, de bonnes pratiques de programmation peuvent vous aider :

  1. Récupérer le moins possible de données lors d’une requête SQL (en effet SQL traitera plus rapidement une boucle que votre code ASP/PHP/etc).
  2. Mettre en cache les requêtes les plus courantes (exemple: la requête qui récupère le menu de navigation)
  3. Ne faire des jointures SQL que sur des INT ou BIGINT (une jointure sur un champ VARCHAR ou NVARCHAR est extrêmement coûteux en temps et en ressource système)
  4. Mettre des index sur les critères de recherche les plus utilisés, mais ne pas abuser des index.
  5. Testez vos requêtes (par exemple : via phpmyadmin et la fonction EXPLAIN)

Trojan-horse-virus

N’oubliez pas que de la rapidité de vos pages dépend de votre classement sur les moteurs de recherche !

En effet, plus vos pages seront longues à s’afficher ou indisponibles plus votre classement sera affecté !

Le second critère le plus important est la localisation de vos serveurs, vous êtes chez un hébergeur 100% Français !