Le registrar de nom de domaine et hébergeur web GoDaddy a corrigé une vulnérabilité CSRF (Cross-Site Request Forgery) dans son système qui permettait à un attaquant d’hijacker les sites internet enregistrés chez ce registrar.

Le pentester Dylan Saccomanni avait remonté l’information auprès de GoDaddy, le but ayant était corrigé en moins de 24 heures par la suite, bien qu’à l’origine ils n’ont pas précisé combien de temps serait nécessaire pour la correction. Il précise également que lorsque l’on gère un domaine enregistré sur GoDaddy depuis quelque temps, il n’y avait aucune protection contre les failles CSRF au niveau de la console de gestion des DNS. Autrement dit, cette faille permet de modifier les paramètres d’un domaine, sans rien savoir du propriétaire du domaine.

D’après le pentester, il y a un problème au niveau des requêtes HTTP car on ne force pas le “Referrer” dans l’en-tête, ce qui permet aux hackers d’injecter du code. Ce n’est d’ailleurs pas la première fois que la notion de Referrer est évoquée lorsqu’il s’agit d’une faille CSRF.

“Go Daddy est une entreprise américaine fondée en 1997 qui est spécialisée dans la gestion de noms de domaine sur Internet et la mise à disposition de services d’hébergement web. En 2010, la société gérait plus de 40 millions de noms de domaines.” Wikipédia

Je ne suis pas sûr que nombreux de nos lecteurs utilisent le service GoDaddy, mais il me semblait intéressant de faire passer l’information.

Source

Pour débuter 2015, Synology annonce la disponibilité de trois nouveaux NAS, deux RackStation (RS815+ et RS815RP+) qui comme la gamme le veut, rackable dans une baie, et un DiskStation (DS2415+).

Synology met l’accent sur le chiffrement et stockage d’envergure

Michael Wang, directeur produit de Synology, déclare : « Les trois modèles RS815+, RS815RP+ et DS2415+ complètent parfaitement notre gamme. Leur évolutivité et leur vitesse de chiffrement permettent à nos clients professionnels de centraliser le partage de fichiers, la sauvegarde de données et la gestion des applications dans un stockage sécurisé, unifié et compatible avec la virtualisation. »

Les caractéristiques techniques

Ces trois modèles disposent d’un module RAM extensible à 6 Go, d’un processeur Quad Core cadencé à 2.4 GHz (avec un moteur de chiffrement AES-NI). Par ailleurs, au niveau des vitesses de lecture, Synology annonce dépasser 389 Mo/s pour le RackStation RS815+/RS815RP+ (388 Mo/s avec du chiffrement) et 451 Mo/s pour le DiskStation DS2415+ (451 Mo/s également avec du chiffrement).

Les performances avec le chiffrement sont plus de dix fois supérieures qu’avec les générations précédentes.

Il est à noter que si vous désirez plus de baies sur ces différents modèles, ils peuvent être couplés avec les unités d’extension Synology RX415 et DX1215.

Au niveau de l’alimentation, seul le modèle RS815RP+ dispose d’une double alimentation afin d’assurer la redondance. Enfin, ils utilisent tous les trois Synology High Availability pour coupler l’utilisation des ports LAN, qui sont au nombre de quatre.

Le prix

Je sais que vous attendez l’information, alors voici les prix annoncés par Synology pour ces trois NAS déjà disponibles :

– RS815+ : 675.00€ HT
– RS815RP+ : 965.00€ HT
– DS2415+ : 1,030.00€ HT

Quelques photos…

 

 

I. Présentation du plugin Fail2ban

Comme je l’avais annoncé dans mon dernier cours Fail2Ban sur la création de filtres et d’actions personnalisés, nous allons maintenant aborder l’intégration de Fail2Ban dans WordPress, nous utiliserons pour cela un plugin prévu à cet effet. Pour suivre ce cours, vous aurez besoin :

• D’un WordPress installé et fonctionnel
• D’avoir la main sur votre OS, notamment pour la gestion de Fail2ban (vous n’aurez pas assez de droits si vous vous situés sur un serveur web mutualisé par exemple)
• D’avoir un Fail2ban installé et fonctionnel (voir mon cours Premiers pas avec Fail2ban)

Pour expliquer le fonctionnement de cette intégration de Fail2ban dans WordPress, il faut savoir que nous allons donc utiliser un plugin écrit par  “invisnet” sur la plate-forme plugin de WordPress (Voici l’URL du plugin : WordPress Fail2ban). Ce plugin intègre donc du code PHP dans le code WordPress qui va faire en sorte d’écrire une ligne de log dans les journaux d’événement Linux (plus précisément /var/log/auth.log) à chaque fois qu’une authentification sera effectuée (succès comme échec). Sachant que Fail2ban est un Log-Based IDS/IPS (Système de détection/Prévention d’intrusion basé sur les journaux d’évènement), on pourra se servir de ces lignes de logs pour faire travailler notre prison (jail) Fail2ban spécifique à WordPress.

Versions utilisées :

• WordPress 4.0.1
• Fail2ban v0.8.6

A nos claviers !

II. Installation du plugin WP_Fail2ban

La première chose à faire est bien sûr l’installation du plugin qui permet l’intégration du code nécessaire dans WordPress, on va pour cela passer par l’ajout d’extension sur BackOffice de notre cher WordPress :

On va donc aller dans notre BackOffice WordPress dans “Extensions” puis “Ajouter”. On va ensuite saisir “Fail2ban” dans l’espace de recherche puis valider. Parmi les plugin proposés, on trouvera “WP fail2ban” sur lequel on sélectionnera “Installer Maintenant”. Notre plugin va alors s’installer comme un plugin standard de WordPress, jusque là, rien d’insurmontable

Il faut savoir qu’aucune configuration spécifique n’est à faire du côté WordPress mise à part l’installation du plugin la suite de la procédure portera donc du côté de Fail2ban.

III. Intégration du filtre WordPress dans Fail2ban

Passons du côté de la configuration Fail2ban, le plugin WordPress WP-Fail2ban comporte un nouveau filtre pour notre Fail2ban, on va le trouver dans le répertoire du plugin dans WordPress chemin_wordpress/wp-content/plugins/wp-fail2ban :

On va donc tout simplement récupérer ce nouveau filtre pour le mettre au bon endroit de la configuration Fail2ban, à savoir le dossier /etc/fail2ban/filter.d qui contient tous les filtres utilisables dans les prisons (jail) Fail2ban :

cp  chemin_wordpress/wp-content/plugins/wp-fail2ban/wordpress.conf /etc/fail2ban/filter.d/

Pour les curieux, on pourra aller ouvrir ce filtre pour comprendre comment il détectera les événements qui nous intéressent, à savoir la détection des tentatives d’authentification WordPress. On remarque alors surtout le failregex, champ dans lequel on spécifie l’expression régulière qui nous servira à filtrer ce que l’on veut surveiller :

On remarque donc que plusieurs types de message de log peuvent servir dans ce filtre, nous verrons en détails leur différences un peu plus tard.

Nous venons donc d’ajouter un nouveau filtre à notre Fail2ban, cela vous rappellera sans doute les manipulations faites dans le cours précédent, il nous faut maintenant l’utiliser dans une jail.

IV. Création d’une jail WordPress

Une fois que nous avons le filtre permettant de surveiller ce qui nous intéresse, à savoir les erreurs d’authentifications dans WordPress, il nous faut maintenant créer une nouvelle jail (prison) dans Fail2ban. Un début de jail est donné sur la page WordPress du plugin mais celle-ci n’est pas complète. On commence par se rendre dans le fichier de configuration des jails Fail2ban, /etc/fail2ban/jail.conf

On va ajouter à la suite des lignes suivantes :

#
# JAILS
#

La configuration de notre nouvelle prison :

[wordpress]

enabled = true
port = http, https
filter = wordpress
maxretry = 3
banaction = iptables-multiport
logpath = /var/log/auth.log

Pour détailler un peu cette configuration, même si vous devez déjà être à l’aise avec la création de jail si vous avez bien suivi les cours précédents sur Fail2ban :

• On commence par spécifier que cette prison va être active avec “enabled = true” puis on indique les ports sur lesquels les flux produisant ces logs sont susceptibles d’arriver,  à savoir les ports HTTP (80) et HTTPS (443), cela est utile notamment pour Fail2ban lorsqu’il manipule le bannissement des IP suspectes avec iptables.

• On indique ensuite le filtre à utiliser, à savoir notre nouveau filtre “wordpress.conf” et le nombre d’essais permis, au delà de ce nombre d’essai, l’IP sera bannie.

• On va ensuite indiquer l’action de ban, j’utilise ici une action présente par défaut “iptables-multuiport” qui permet le bannissement via l’IP source part iptables et on fini par spécifier le fichier de logs dans lesquels les logs susceptibles de nous intéresser seront écrit, à savoir /var/log/auth.log pour le plugin WP Fail2ban.

On va ensuite redémarrer Fail2ban pour que ces changements soient effectifs :

service fail2ban restart

On pourra ensuite faire quelques tests pour vérifier le bon fonctionnement de notre protection.

Note : Outre les tentatives infructueuses d’authentification, WP Fail2ban peut également surveiller les pingbacks ou les tentatives d’énumération des utilisateurs. Pour le premier cas, il faut ajouter cette ligne dans le fichier “wp-config.php “define(‘WP_FAIL2BAN_LOG_PINGBACKS’,true);” . Pour les tentatives d’énumération des utilisateurs, il faut y ajouter cette ligne : “define(‘WP_FAIL2BAN_BLOCK_USER_ENUMERATION’,true);”. Cela permettra l’inscription des lignes de logs dans le fichier /var/log/auth.log

V. Test de la sécurité WordPress avec Fail2ban

Pour tester notre protection, rien de plus simple. Il nous suffit d’effectuer plusieurs authentifications ratées sur notre page de login WordPress.

Note : Attention, s’il s’agit d’un serveur distant sur lequel vous n’avez un accès que par Internet. L’action de bannissement que nous utilisons va en effet bannir l’IP source sur tous les ports, pas juste sur le port 80. Pour information, le temps de bannissement par défaut est de 10 minutes.

Une fois nos tentatives effectuées, on pourra ouvrir un terminal et effectuer la commande montrant le statut de notre prison Fail2ban “wordpress” :

fail2ban-client status wordpress

Voici ce que l’on pourra voir si notre IP a bien été bannie  :

On voit donc qu’en ce moment, une IP est bannit et qu’il s’agit de l’IP “192.168.1.39”. Dans le fichier /var/log/auth.log, on pourra voir notre tentative d’authentification :

Ce sont précisément ces lignes de logs que le filtre Fail2ban “wordpress” a remarqué et il a alors déclenché l’action de bannissement de l’IP indiquée dans les logs.

C’est tout pour ce cours, nous avons donc vu comment protéger un site web WordPress d’un trop grand nombre de tentative d’authentification via un plugin permettant l’intégration à Fail2ban. N’hésitez pas à partager vos avis dans les commentaires ou à poser des questions sur notre forum !

I. Présentation des profils itinérants

En entreprise, ce n’est pas rare que les utilisateurs changent de bureaux, utilisent l’ordinateur du collègue, changent de service, etc. Bref, les utilisateurs sont amenés à utiliser différentes machines. De ce fait, la disposition sur une machine à l’autre ne sera pas la même (personnalisation de l’espace de travail) et les données ne seront pas les mêmes si l’utilisateur stocke du contenu sur sa machine (ce qui n’est pas recommandé, il vaut mieux centraliser les données sur un serveur).

Par défaut, lorsqu’un utilisateur ouvre une session sur une machine, son profil est stocké dans “C:/Users” ou “C:/Utilisateurs“, avec à chaque fois un sous-dossier par utilisateur.

C’est là qu’interviennent les profils itinérants, qui fonctionnent différemment puisque les profils sont stockés sur un serveur. En fait :

– Ouverture de session : S’il s’agit de la première connexion de l’utilisateur sur la machine, les données de profil de l’utilisateur sont téléchargées sur la machine où il s’est connecté (Bureau, paramètres, documents, etc.)

– Fermeture de session : Les fichiers modifiés sont envoyés vers le serveur afin d’y être stockés et que l’utilisateur puisse retrouver son environnement sur une autre machine.

Les profils itinérants améliorent la mobilité des utilisateurs et permettent la centralisation des données de profils utilisateurs. Bien sûr, il requiert la mise en place d’un annuaire Active Directory puisque c’est dans cet annuaire que s’effectue la configuration.

II. Configurer les profils itinérants

La première étape consiste à créer un répertoire que nous allons partager et qui servira à stocker les données des profils. Par exemple, pour ma part je crée répertoire nommé “Profils_itinérants” que je partage sous le même nom.

Dans la configuration du partage, cliquez sur “Autorisations”

Supprimez “Tout le monde” et préférez à la place “Utilisateurs“, un groupe qui englobe vos utilisateurs de l’Active Directory. Au niveau des droits, la lecture et l’écriture vont suffire, comme ceci :

Validez, la création du partage est désormais terminée. Passons maintenant à la configuration au sein de l’annuaire Active Directory.

Effectuez un clic droit sur un utilisateur qui doit disposer d’un profil itinérant, cliquez sur “Propriétés“. Accédez à l’onglet “Profil” et au niveau du champ “Chemin du profil“, indiquez :

\\SRV-AD01.it-connect.fr\Profils_itinérants\%username%

On indique simplement le chemin UNC vers le serveur, suivi du partage et à la fin %username% qui prendra pour valeur le login de l’utilisateur.

Note : Pour être plus efficace, vous pouvez sélectionner plusieurs utilisateurs et indiquer le chemin avec la variable %username%. Ainsi, le chemin s’adaptera à chaque utilisateur.

Lorsque le chemin est renseigné, validez.

Depuis une machine cliente, connectez-vous avec un compte pour lequel le profil itinérant est configuré. Sur le serveur, dans le répertoire partagé, vous verrez apparaître un dossier de profil pour cet utilisateur :

Vos utilisateurs stockent désormais leur profil sur votre serveur directement au sein du partage créé précédemment, avec un répertoire par utilisateur. On peut – après être devenu propriétaire du dossier de profil – voir le contenu du profil utilisateur :

Nous allons maintenant parler GPO (Stratégie de groupe) et voir les quelques paramètres qui concernent les profils.

III. Profils itinérants et GPO

Comme pour toute stratégie de groupe, commencez par ouvrir l’éditeur de stratégie de groupe sur votre contrôleur de domaine (gpedit.msc). Ensuite, éditez la GPO concernée et parcourez-la ainsi :

Configuration utilisateur, Modèles d’administration, Système, Profils utilisateur

Quatre paramètres sont alors disponibles :

• Connecter le répertoire de base à la racine du partage

Permet de restaurer les définitions des variables d’environnement %HOMESHARE% et %HOMEPATH% sur celles utilisées dans Windows NT 4.0. Si vous ne configurez pas ce paramètre ou que vous le désactivez, le système utilisera les définitions introduites depuis Windows 2000.

• Spécifier les répertoires réseau à synchroniser seulement au moment de l’ouverture/fermeture de session

Répertoire à synchroniser dans le cadre d’une stratégie de fichiers hors connexion

• Exclure des répertoires dans les profils itinérants

Permets d’exclure des répertoires des profils itinérants, c’est-à-dire des dossiers qui ne seront pas stockés sur le serveur. Cela peut permettre de ne pas synchroniser des dossiers conséquents que les utilisateurs pourraient avoir sur leurs machines, et qui ne contiennent pas de données importantes.

Sachez que, par défaut, les dossiers Appdata\Local et Appdata\LocalLow ainsi que les sous-dossiers de ces deux dossiers, sont exclus. Cela comprend notamment les répertoires Temp et Temporary Internet Files. L’objectif étant d’alléger le stockage au niveau du serveur et de stocker les fichiers temporaires uniquement sur la machine dont ils proviennent.

• Limiter la taille du profil

Ce paramètre permet de déterminer une taille maximale pour le profil d’un utilisateur et, comment le système doit se comporter lorsque cette limite est atteinte.

Vous pouvez indiquer une taille en Ko, indiquer si les fichiers du Registre sont comptabilisés dans la taille, mais aussi, indiquer si vous souhaitez ou non avertir l’utilisateur lorsque la taille est dépassée.

Ce paramètre s’applique aussi bien pour un profil local que pour un profil itinérant.

Vous avez les clés en main pour gérer les profils itinérants pour vos utilisateurs ! Ah oui, avant de se laisser, un mot tout de même sur la redirection de dossier.

IV. Redirection de dossiers

La redirection de dossiers peut être utilisée en plus des profils itinérants. Elle permet de rediriger (stocker) sur le serveur uniquement certains dossiers du profil d’un utilisateur, comme par exemple, le Bureau et les Documents,  sans systématiquement tout rediriger comme c’est le cas avec les profils itinérants. Les avantages :

– Moins d’espace disque utilisé

– Moins de bande passante nécessaire pour charger le profil

– Configurable via les stratégies de groupe (et non par les propriétés du compte comme pour un profil itinérant)

– Couplage possible avec les fichiers hors connexion pour synchroniser uniquement les fichiers modifiés

– Le chemin de la redirection de dossiers est prioritaire sur le chemin du profil itinérant

Il faut savoir que si vous redirigez le Bureau sur un emplacement réseau, l’utilisateur ne rapatriera pas le contenu en local sur la machine, mais accédera aux données de son Bureau directement par le réseau. Pour obtenir les meilleures performances, il faudra coupler l’utilisation des profils itinérants ainsi que de la redirection des dossiers. Un prochain article traitera justement de la configuration de la redirection de dossiers.

Pour ceux qui souhaitent acheter le smartphone OnePlus One sans même disposer d’une invitation, sachez que cela va devenir possible !

En effet, pour fêter la nouvelle année, OnePlus permettra le 20 Janvier 2015 de 19:00 à 21:00 GMT pour l’Europe d’acquérir le modèle One. Une nouvelle occasion d’acquérir ce smartphone se présentera donc demain, mais à mon avis, il faudra – comme à chaque fois – être rapide !

Voici un rappel des caractéristiques du smartphone :

– Android Cyanogen 11S (basé sur Android 4.4)
– Taille de l’écran : 5.5 pouces
– Résolution : 1920 x 1080
– Appareil photo : 13 Mégapixels
– Processeur : Qualcomm Snapdragon 801 – 2.5 GHz – Quad Core
– RAM : 3 Go
– GPU : Adreno 330
– 4G : Oui
– Stockage : 16 Go (non extensible)