Archives de catégorie : Securité

Procédure pour le passage d’un site en HTTPS

Une fois le certificat SSL installé sur votre serveur dédié, il faudra effectuer un certain de paramétrages sur votre site.

Voici une procédure-type pour un site réalisé sous WordPress 4.x.

Dans un premier temps, il faudra forcer le site à n’autoriser que certains utilisateurs à accéder au site dans sa version HTTPS. Pour cela, il faut ouvrir le fichier wp-config et ajouter votre IP publique grâce à ce script :

if($_SERVER[« REMOTE_ADDR »]== »xxx.xxx.xxx.xxx ») {
define(‘WP_HOME’,’https://www.mondomaine.com’);
define(‘WP_SITEURL’,’https://www.mondomaine.com’);
}

Pour connaitre votre IP publique, il vous suffit de suivre ce lien : https://www.icodia.com/fr/solutions/outils/information/connexion-internet.html

Dans le back-office du site (http://mondomaine.com/wp-admin), aller dans « Réglages > Général », puis ajouter un « s » après HTTP (sans espace) à « Adresse web de WordPress » et « Adresse web du site ».
Si vous n’avez pas apporté de modification particulière à votre site, cette modification devrait suffire à passer votre site en en HTTPS.

Il convient tout de même de procéder à des vérifications de toutes les pages.
Pour cela, il faut vérifier dans différents navigateurs que le cadenas vert s’affiche systématiquement.
La suite de la procédure s’appuie sur l’outil Firefox Developer, téléchargeable à l’adresse : https://www.mozilla.org/fr/firefox/developer/
Entrez l’URL de votre site web et sélectionnez l’onglet « Outils de développement – Réseau » à droite de la barre d’adresse, ou « CTRL + MAJ + E ». La colonne « Domaine » doit afficher des cadenas vert sur toutes les lignes.
Si vous ne voyez aucune information apparaître, il peut être nécessaire de recharger votre page en appuyant sur la touche F5.

Idéalement, il faudra passer sur toutes les pages du site avec cet outil pour vérifier qu’il n’y ait pas du contenu HTTP chargé.

Une fois les problèmes repérés sur une page, il faudra réécrire en HTTPS les liens générés dans le code HTML, les feuilles de styles et les scripts.
De même avec les liens stockés en HTTP dans la base de donnée qui sont générés sur la page.
Si du contenu est stocké sur un hébergement externe (des images, par exemple) et que ce site externe ne supporte pas le HTTPS, il faudra rapatrier le contenu sur l’hébergement de votre site.
Dans la base de données, vous pouvez rechercher toutes les occurrences de http://www.mondomaine.com par exemple pour les remplacer par https://www.mondomaine.com de la même façon. Par exemple, tous les GUID des posts sont à adapter. Cela peut être automatisé par une requête, mais attention, il faut bien veiller à ne pas modifier des données sérialisées (dans les options par exemple), car l’ajout d’un caractère dans ce type de donnée la rend inexploitable et elle sera réinitialisée par WordPress. Vous pouvez par exemple exclure du remplacement les chaînes qui contiennent une accolade.
Ensuite on pourra forcer le HTTPS sur tout le site (avec une règle de redirection dans le htaccess par exemple).
Exemple de règle de redirection du .htaccess :
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Pour terminer, on peut à nouveau vérifier avec plusieurs navigateurs que l’on a bien un cadenas vert partout. Il peut y avoir des disparités entre différents navigateurs.

Pensez bien à modifier votre fichier wp-config pour hôter la limitation par IP.

 

NB : Cette procédure est fourni sans aucune garantie de résultats. La responsabilité d’Icodia ne saurait être engagée en cas de dysfonctionnement suite à des opérations réalisées sur votre site.

Tips WordPress – Désactiver l’éditeur de fichiers

Par défaut, l’interface back-office de Worpress propose un éditeur de fichier pour les plugins et les thèmes. Ce dernier permet de modifier les scripts (CSS, JS, mais aussi PHP) au moyen d’un éditeur en ligne. Ce dernier est une autoroute offerte aux hackers à partir du moment où ils parviennent  à s’identifier sur l’interface. Il faut donc désactiver cette fonctionnalité et utiliser plutôt l’accès FTP pour faire les modifications.

Pour désactiver cette option, il faut ajouter dans votre fichier wp-config.php la ligne suivante :

define('DISALLOW_FILE_EDIT',true);

Tips WordPress – Modifier les clés de hash

Par défaut, les clés déployées par l’installation de WordPress sont stockées dans le fichier wp-config.php et ont cette forme :

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Il est donc très important de les personnaliser et de les complexifier au maximum pour éviter la récupération par un hacker d’informations normalement cryptées fortement. Un script de génération automatique de ces chaines est disponible ici :

https://api.wordpress.org/secret-key/1.1/salt/

Il suffit de remplacer les lignes évoquées plus haut par celle que le script à généré.
Le robot d’infogérance WP proposé par ICODIA automatise cette action.

Informations sécurité Firefox / Connexions simultanées

Sur nos serveurs (mutualisés et dédiés) nous activons une règle firewall par défaut, limitant le nombre maximum de connexions simultanées en HTTP vers le serveur web.
Cette règle permet de limiter une attaque par « déni de service », c’est à dire une attaque effectuant des tas de connexions HTTP (web) vers le serveur, pour bloquer toutes les connexions supplémentaires, et rendre donc le site web inaccessible.

La norme HTTP conseille un maximum de 8 connexions simultanées vers un serveur web, et tous les navigateurs (non ‘modifiés’) suivent, de base, cette règle.

Attention, il existe cependant un bug dans Firefox : en cas de « hard refresh », c’est à dire lorsque vous effectuez un « CTRL+F5 » par exemple, Firefox ne suit absolument pas cette règle (c’est un bug), et effectue autant de connexions que de médias à télécharger sur la page web.
Si, par exemple, la page web contient 60 images, 1 css, 2 fichiers JS, et 5 fichiers flash, Firefox va effectuer plus de 68 connexions simultanées vers le serveur web, pouvant donc finalement ralentir l’affichage du site, car une partie de ces connexions seront bloquées par la règle de sécurité anti « déni de service ».

Ce bug est connu par la fondation Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=838502 , il devrait être résolu, nous l’espérons dans les prochaines versions de firefox.

Fichier .htaccess : Erreur SSI, Internal Server Error,…

1) Principe et fonctionnement

Un serveur d’hébergement sans aucune restriction technique et fonctionnelle, exposerait vos sites et services à de nombreuses failles de sécurité.  Il s’exposerait lui même à des failles, également.
De ce fait,  nous avons pré-configuré nos serveurs dédiés ainsi que nos hébergements mutualisés de façon à ce qu’ils soient prémunis de ces failles de sécurité.

Cette pré-configuration empêche la modification des directives sensibles du serveur.
Afin d’utiliser certaines fonctionnalités, vous avez la possibilité d’utiliser des fichiers .htaccess.

Les fichiers .htaccess servent à modifier localement la configuration du serveur Apache.
Il est donc possible d’adapter la configuration du serveur en fonction des différents dossiers de l’hébergement.
De ce fait vous pouvez créer autant de fichier .htaccess que de dossier qu’il y a sur l’hébergement.

Cet article a pour but de parcourir les erreurs fréquentes dues à un fichier .htaccess sur votre hébergement dédié ou mutualisé.

Si vos directives ne figurent pas dans ce tutoriel, vous pourrez les trouver sur le site officiel d’Apache (Site officiel d’Apache).

2) Erreurs .htaccess sur hébergement mutualisé

Lorsque que vous essayez d’agir sur les directives Apache dans un fichier .htaccess, il est possible que le serveur vous retourne un message d’erreur du type :

ERREUR SSI

Erreur SSI dans votre fichier
SSI instruction error in your file.

Cette erreur est courante. Voici les trois cas les plus courants qui peuvent la générer:

2.1 ) Lorsque vous tentez d’exécuter un script php qui demande trop de ressource

taille mémoire: memory_limit, temps d’exécution:max_execution_time,…,

Le script est « tué » par le serveur et renvoie cette erreur.

Les variables php sont modifiables dans votre icoAdmin (avant dernier onglet),
Si vous pensez que le problème vient de là, veuillez  augmenter les valeurs des variables php et relancer votre script.

2.2 ) Lorsque vos données de connexion à votre base de donnée Mysql sont incorrects

Vérifiez la configuration de votre connexion dans le fichier concerné : Serveur, base de données, identifiant, mot de passe

2.3 ) Lorsque vous essayez  d’activer ou de désactiver une option ou une directive dans un fichier .htaccess qui y serait déjà ou qui ne serait pas autorisée, le serveur renvoie une erreur.

Sur tous nos packs mutualisés, nous avons mis en place une configuration de sécurité qui ne permet pas par exemple une intrusion sur le serveur via un compte FTP.
Cela vous semble peut-être bloquant mais cette configuration est nécessaire pour ne pas pénaliser l’ensemble des hébergements mutualisés de la plateforme.

Directives d’Apache les plus courantes qui sont autorisées ou non  par le serveur sur votre hébergement mutualisé :

DirectoryIndex index.php index.html index.htm : Autorisée, elle permet de diriger un utilisateur vers une page web lorsqu’il tape www.domaine.fr dans un navigateur. Le serveur affiche le premier fichier existant de la liste (en partant de la gauche).

ErrorDocument 404 /pageinexistante.php : Autorisée, elle permet de personnaliser votre page d’erreur 404.
Elle redirige vers une page particulière lorsqu’un utilisateur appelle une page qui n’existe pas .
Dans ce cas, l’utilisateur sera dirigé vers pageinexistante.php .

AddDefaultCharset UTF-8 : Autorisée, elle permet de modifier le décodage de la page.
Cela est utile quand la page a été encodée dans un autre format (dans votre éditeur de code).
Si le décodage ne correspond pas à l’encodage, vous allez voir apparaître des caractères spéciaux à la place des caractères accentués par exemple.

RewriteEngine on : Autorisée, elle permet de pouvoir effectuer des réécriture d’url.

RewriteCond %{HTTP_HOST} ^www.votredomaine.com$ : Autorisée, elle permet d’autoriser la directive RewriteRule qui la suit.
Elle permet par exemple de rediriger dans un sous-dossier en fonction du nom de domaine demandé si une directive RewriteRule la suit.

RewriteRule ^(.*)\.html$ $1.php [L] : Autorisée (si RewriteEngine a été activée), elle permet de réécrire les urls se terminant en .php par des urls en .html

Options +Indexes : Refusée, cette option permet de lister tous les fichiers présents dans un dossier qui n’aurait pas de directive DirectoryIndex. Elle peut être la source de problèmes de sécurité.

Options +FollowSymLinks : Refusée, cette option est déjà activée par défaut sur la configuration du serveur.
Elle permet de garder la hiérarchie des liens dans chaque sous-dossier. Par exemple, elle est nécessaire pour utiliser la directive RewriteRule sans être obligé de répéter ces directives dans chaque .htaccess des sous-dossiers.

AllowOverride All : Refusée pour des raisons de sécurité, elle permet d’autoriser TOUTES les directives du serveur.

Options +Includes : Refusée pour des raisons de sécurité, elle permet de réaliser des inclusions coté serveur.

Options +Multiview : Refusée pour des raisons de sécurité, elle permet , si dans l’url demandée un dossier n’existe pas alors le serveur va rechercher dans le dossier précédent (du chemin de l’url) un fichier qui porterait le même nom.

L’ensemble des directives est disponible sur le site d’Apache (Directives d’Apache).

3)Erreurs .htaccess sur serveur dédié

Sur nos serveurs dédiés nous mettons également en place une configuration du serveur Apache par défaut.
Cette configuration est néanmoins entièrement modifiable selon vos besoins.
Les erreurs rencontrées à cause des .htaccess ou de la configuration d’Apache est l’erreur 500:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, support@icodia.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Cette erreur étant assez générique pour Apache, elle vous permettra simplement d’identifier le type du problème.
Dans ce cas, il viendra d’un fichier .htaccess ou du fichier général de la configuration d’Apache (httpd.conf pour CentOs par exemple).

De la même manière que pour nos serveurs mutualisés, les règles d’Apache les plus sensibles sont désactivés par défaut (dans les fichiers .htaccess) :  AllowOverride All, Options +Includes, Options +Multiview,… .
Vous pouvez analyser les directives qui posent problèmes dans les fichiers de logs d’erreurs de votre site.

Ce genre d’erreur apparaît souvent quand vous essayez d’installer une application comme Magento (par exemple) qui utilise des options sensibles.

mod_security

Mod_security est une couche de sécurité de PHP qui protège votre hébergement en interdisant des actions jugées suspectes. Elles sont générales et spécifiques à certains applicatifs. Par exemple, pour protéger le système e-commerce « OS-Commerce » dont les formulaires sont souvent utilisés pour relayer du spam, nous avons ajouté une directive bloquant tout appel de « tell_a_friend.php » avec passage de la variable products_id en GET. Il semblerait que ce soit la technique de base pour détourner le formulaire et envoyer du spam.

Mot de passe perdu

Généralités :

IdentificationLes mots de passe sont des données confidentielles. En aucun cas Icodia ne les communiquera sans identification du demandeur.

Il existe des protocoles pour récupérer ces informations :


Accès à Espace Client :

Se rendre sur l’espace Client : http://client.icodia.com

Pour en savoir plus : Espace Client

Sur simple demande email au support la dernière facture sera retournée à notre contact comptable. Il y retrouvera le code client ainsi que le code d’accès indispensables pour accéder à l’Espace client.

Accès à l’icoAdmin, au FTP et au Bases de données :

Pour se connecter aux différentes interfaces  : Paramètres de connexion

Sur simple demande email au support la feuille de paramètres de connexion sera retournée sur l’adresse email de l’administrateur de l’hébergement. Icodia ne pourra remplacée l’adresse enregistrée sans une identification approfondie (accompagnée de justificatifs) au préalable.

Accès à un compte email :

Icodia ne communique jamais le mot de passe d’un compte email. Pour retrouver votre mot de passe vous devez contacter l’administrateur de votre hébergement pour lui demander de vous communiquer votre mot de passe. Cette donnée est disponible depuis l’IcoAdmin du pack d’hébergement concerné.

Accès à un compte utilisateur supplémentaire (FTP, IcoAdmin, MySQL) :

Les accès supplémentaires sont ouverts par l’administrateur de l’hébergement ou à sa demande. C’est donc à lui qu’il faut s’adresser pour obtenir les identifiants nécéssaires à la connexion.

Les accès supplémentaires ne disposent généralement pas des mêmes droits que l’administrateur notre support est donc dans l’incapacité de déterminer quels accès l’administrateur souhaite accorder.

Configuration de Outlook Express : IcoSMTP

Généralités :

Icodia vous donne la possibilité de mettre en place un SMTP (SSL) sécurisé (inclus dans certains Packs ou en option), n’hésitez pas à l’utiliser pour envoyer vos email !
Cet outil protègera le contenu de vos emails en encryptant les données envoyées.

Continuer la lecture de Configuration de Outlook Express : IcoSMTP

Recrudescence des keyloggers : La sécurité de vos sites passe avant tout par vos machines !

Icone_virusLes Keyloggers exploitent des failles de sécurité de navigateurs, client FTP, etc. et enregistrent vers des serveurs distants (à destination de hackeurs) vos identifiants en tout genres : Identifiants FTP, login/mots de passe, cartes bancaires…

Une fois vos codes récupérés par les keyloggers, les hackeurs peuvent utiliser ces données comme bon leur semble. Ils peuvent ainsi se connecter en toute facilité en FTP sur votre hébergement et modifier votre site.

Une Faille de sécurité très connue sur Fillezilla est souvent exploitée par les Keylogger :

Les sessions sont stockées (mots de passes et identifiants en claire) sur votre machine dans un fichier xml. Bilan si vous avez un Keylogger sur votre machine et que vous utilisez Filezilla, le Keylogger aura accès à sa guise à vos identifiants FTP…

Le Hacker n’aura plus qu’à utiliser ces informations pour pirater votre site internet.

Nous vous conseillons donc :

D’utiliser un ou plusieurs bons antivirus (Microsoft Security Essentials, Comodo antivirus ) pour nettoyer vos machines. Si un Keylogger s’y loge, il sera détecté et supprimé. Ces antivirus disposent généralement d’une version d’essai 30 jours.

Si vous le pouvez, le mieux est de connecter le disque dur de la machine infectée sur une machine « propre » avec un tiroir USB par exemple ,afin d’effectuer le nettoyage.

Si vous avez détecté un virus ou une intrusion sur votre site internet :

  • Il est impératif de scanner toutes les machines ayant pu se connecter en FTP ou sur votre base de données. N’importe laquelle peut être responsable.

Nous rappelons que les OS sont tous concernés! Les Hackeurs n’épargnent personne même les Mac ! Nous avons vu des propriétaires de Mac victimes de Keyloggers.

  • Si un Keylogger est détecté, notez son nom, et contactez le support Icodia en précisant le/les lien(s )où nous pourrons constater le problème. Le nom du Virus nous donnera des informations complémentaires (ce problème est assez commun en ce moment).
  • Une fois vos machines « propres », changez vos mots de passe ftp, IcoAdmin et si possible MySQL (le hackeur ayant pu conserver ces informations, il pourrait utiliser phpMyAdmin pour se connecter sur votre site en mode web et refaire des modifications). Attention néanmoins, le changement du mot de passe MySQL oblige la mise à jour de la configuration MySQL d’éventuels scripts php sur votre hébergement.
  • Vérifiez tous les fichiers de votre site web, supprimer les dossiers contenant des virus et traces de hacking.

Chers professionnels et dilettantes du net, il y a une morale à tout cela ! Veillez à la sécurité de vos machines en leur offrant un antivirus fiable et bien à jour ! vous verrez, vos sites vous le rendront. Ou plutôt vous ne verrez rien si ce n’est un site qui tourne !

Bien à vous!
Le support Icodia

osCommerce : paramétrer un certificat SSL

Icone_SSL

Etape 1 : Activer le SSL mutualisé

Etape 2 : Modifier les fichiers « configure.php »

  • Pour : catalog/includes/configure.php

Trouvez la ligne —-> define(‘HTTPS_SERVER’, ‘ ‘);
Remplacez par —-> define(‘HTTPS_SERVER’, ‘ http://monnomdedomaine.icodia.info ‘);

Trouvez la ligne —->define(‘ENABLE_SSL’, false);
Remplacez par —-> define(‘ENABLE_SSL’, true);

  • Pour : catalog/admin/includes/configure.php

Trouvez la ligne —->define(‘ENABLE_SSL’, false);
Remplacez par —-> define(‘ENABLE_SSL’, true);

Trouvez la ligne —->define(‘HTTPS_CATALOG_SERVER’, ‘ ‘);
Remplacez par —-> define(‘HTTPS_CATALOG_SERVER’, ‘http://monnomdedomaine.icodia.info ‘);


Etape 3 : Si après avoir effectué ces modifications, un message d’erreur s’affiche pour vous indiquer un problème avec le certificat, ou bien que le cadenas qui s’affiche dans votre navigateur est barré, il faudra vérifier les liens vers vos images. Pour obtenir une validation SSL complète, il faut que tous les liens vers vos médias, images, etc. soit en https, le mieux étant donc de travailler en « relatif ».

Exemple de lien en relatif : <img src= »images/test.jpg »> au lieu de  <img src= »http://www.domaine.com/images/test.jpg>