Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

SOPHOS – Retour d’expérience sur la migration des agents antivirus depuis une gestion UTM SG vers Sophos Central

Introduction :

Cette article va vous montrer comment basculer d’un environnement de gestion SG vers un environnement de gestion Sophos Central.

Note : Les boitiers SG (ancienne gamme Sophos) permettent de jouer le rôle de “serveur antivirus”. 

Prérequis :

  • Accès à la console d’administration SOPHOS SG et SOPHOS Central.
  • Avoir créé ou importé vos utilisateurs dans SOPHOS Central.
    • Pour que les utilisateurs remontent dans Sophos Central il faut au préalable mettre en place l’outil de synchronisation Sophos.

Déploiement :

La première étape consiste à s’identifier sur SOPHOS XG et de désactiver la « Tamper protection » sur tous les utilisateurs.

Pour réaliser cette action la méthode la plus simple est de créer un groupe réunissant tous les utilisateurs à migrer et de désactiver la fonction :

clip_image002

La deuxième étape consiste cette fois ci à s’identifier sur SOPHOS Central et d’envoyer email d’installation aux utilisateurs concerné par la migration  :

clip_image004

La dernière étape quant à elle, est de lancer l’exécutable téléchargé à partir du mail reçu :

clip_image006

L’installation doit être lancé en tant qu’administrateur et prend environ 15 minutes. Pendant ce lapse de temps le logiciel va désinstaller l’ancien antivirus, télécharger le nouveau et l’installer.

Une fois l’opération fini vous allez voir un nouveau logo apparaitre :

clip_image007

Configuration

Sophos Central permet comme à l’instar de SOPHOS SG de créer des groupes pour gérer l’administration. Le plus avec SOPHOS central est qu’il distingue deux catégories. La première est « User and Computer Policies » et la seconde « Server Polices ».

Voici la liste des paramètres qui peuvent être modifié pour les deux catégories.

User and Computer Policies

Server Policies

clip_image009

clip_image011

Fonctionnalité Innovante

La nouveauté de Sophos Central est le module Intercept X qui contient plusieurs outils dont CryptoGuard qui empêche les ransomwares et la Root Cause Analysis.

La RCA permet en cas d’attaque subit d’analyser en profondeur et de donner les détails de l’attaque.

Pour accéder à cette l’interface il faut se rendre dans l’onglet « Root Cause Analysis » puis de sélectionner l’attaque souhaité.

clip_image013

Trois Onglet s’offre à vous.

Overview : Regroupant les informations essentielles de l’attaque QUOI, OU, QUAND et QUI.

clip_image015

Artifacts : Liste tous les fichiers, adresses IP, Processus, clé de registre et toutes les connexions que l’attaque ai touché. Que ce soit en lecture, écriture, connexion.

clip_image017

Visualize : Montre graphiquement comment l’attaque c’est propagé.

clip_image019

Il suffit ensuite de cliquer sur la bulle qui nous intéresse pour nous afficher le détail.

clip_image021

Exchange 2013 – Le WinRM Shell client ne peut pas traiter la requête.

Contexte :

Le problème ci-dessous a été rencontré suite à la suppression du certificat auto-signé d’un Serveur Microsoft Exchange 2013 depuis la console MMC :

clip_image002

Problème rencontré :

Après avoir exécuté quelques mises à jour et redémarré le serveur, le message suivant apparaissait à l’ouverture d’une session PowerShell :

clip_image003

Analyse :

L’observateur d’évènement est un bon outil qui permet d’avoir plus d’information sur une erreur rencontrée. Dans notre cas l’observateur a noté l’Event ID : 15021

« An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data. »

clip_image005

Comme il est impossible de vérifier depuis l’environnement de ligne de commande Exchange Management Shell à quel site Web IIS est attribué un certificat Exchange (la cmdlet Get-ExchangeCertificate permet uniquement de voir que le certificat est associé à IIS sans préciser sur quel site Web), nous allons passer par IIS (Internet Information Services).

Pour se faire nous ouvrons IIS Manager depuis Server Manager :

clip_image007

Note :

Lors de l’installation d’Exchange 2013 celui-ci va créer deux sites Web dans IIS qui doivent avoir ce certificat affecté :

– Default Web Site

– Exchange Back End

Par défaut c’est le site Web Exchange Back End qui a une liaison au port 444 pour le HTTPS. Ce qui correspond à l’Event du dessus.

Sur IIS nous sélectionnons Exchange Back End
clip_image008

Dans l’onglet Edit Site clic droit sur “Bindings” :
clip_image010

Double cliquer sur “https”:
clip_image012

Nous nous apercevons qu’il n’y aucun certificat assigné.

Solution :

Pour résoudre le problème, il suffit de régénérer un certificat auto signé soit avec le centre d’administration Exchange soit en PowerShell.

Une fois le certificat en place nous relançons PowerShell et nous pouvons constater que celui-ci arrive à se connecter au serveur.

clip_image013

Migration DHCP Failover de Windows Server 2012 R2 à Windows Server 2016

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

clip_image002

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

clip_image004clip_image006

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

clip_image007

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

clip_image008

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

clip_image009

Choisir les scopes qui vont être répliqués

clip_image011

Sélectionner le second serveur

clip_image013

Configurer le Failover a isopérimètre avec l’ancien Failover.

clip_image015

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

clip_image017

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

clip_image019

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

clip_image020

clip_image022