I. Présentation

Sous Linux, la commande « screen » permet de gérer plusieurs terminaux à la manière des fenêtres dans un environnement graphique. On peut donc créer une nouvelle session (un screen) contenant un terminal, puis un second et nous allons pouvoir passer de l’un à l’autre en nous détachant à l’un puis en nous rattachant à l’autre.

L’intérêt premier de screen dans le monde du sysadmin est le suivant : il est possible de créer un « screen », puis de s’y détacher, et cette opération ne coupe pas les opérations en cours, cela même si l’utilisateur ayant lancé le screen en question se déconnecte.

Cela est également pratique pour gérer les applications qui ne rendent pas la main à l’utilisateur lors de leur exécution. Par exemple des scripts qui mettent du temps à s’exécuter ou des applications plus complexes.

Pour la suite du tutoriel, considérez un « screen » comme un simple shell ou une session lancé et duquel on peut se détacher, puis se rattacher, à la manière dont on change de fenêtre dans un environnement graphique.

Voyons comment installer et utiliser screen dans la suite de cet article

II. Installation de screen

Rien de plus simple, sous CentOS/Fedora :

yum install screen

Sous Debian/Ubuntu :

apt-get install screen

Une fois installée, la commande « screen » est disponible.

III. Utilisation de la commande « screen »

Nous allons donc créer une sorte de « terminal virtuel » qui pourra continuer à tourner même lorsque nous l’aurons quitté, nous pourrons ensuite reprendre la main sur ce terminal.

Depuis notre terminal, créons une session nommée « TEST01 » avec l’option « -S » de la commande screen :

screen -S TEST01

Nous pouvons voir qu’une nouvelle session est apparue, nous pouvons donc réaliser nos exécutions et saisir nos commandes comme d’habitude. Une fois que nous souhaitons laisser l’exécution faire son chemin (par exemple lors d’un téléchargement ou d’une longue installation), il nous suffit de nous détacher de celle-ci pour la reprendre plus tard, pour cela, saisir la combinaison de touche suivante :

Ctrl + a
 puis "d"

Nous sommes donc revenu sur notre terminal initial, mais constatez que notre session « screen » est toujours en vie en listant les sessions disponibles avec la commande suivante :

screen -ls

Voici un retour possible de cette commande :

Dans la capture d’écran faite pour le tutoriel, nous voyons que plusieurs sessions sont actives, deux sessions sont disponibles, celles-ci sont marquées comme « Detached », car personne n’est actif dessus. La session « TEST01 » est elle déjà attachée, un utilisateur est donc actif sur celle-ci.

Pour nous rattacher à une session, il suffit d’utiliser l’option « -r » de la commande screen, puis de saisir l’identifiant ou le nom de la session, par exemple :

screen -r TEST02

ou via l’identifiant

screen -r 2166

Pour fermer une session, comme d’habitude, il suffit d’utiliser la commande « exit » pendant que nous sommes attaché à celle-ci. Dés lors, nous reviendrons à notre terminal initial et la session ne sera plus listée lors de l’affichage des sessions screen actives.

Bien entendu, il est possible de gérer ainsi plusieurs sessions avec la commande screen. Également, je vous encourage à constater par vous même le fait que si l’utilisateur se déconnecte de sa session TTY, il retrouve ses sessions screen une fois qu’il se reconnecte, idéal une fois encore lorsqu’il s’agit de traitements longs qui ne rendent pas la main à l’utilisateur avant la fin de leur exécution.

Également, ce procédé est pratique lorsqu’il s’agit de venir en aide lors d’un dépannage sur une autre machine. Il est possible de se passer une session sans avoir a fermer celles-ci.

La commande « screen » dispose d’autres options que je n’explore pas ici. Quoi qu’il en soit je vous encourage à tester cette commande !

N’hésitez pas à partager vos questions et vos avis dans les commentaires.

I. Présentation

WSUS Package Publisher est une application qui se greffe au service WSUS afin de publier sur des clients vos propres mises à jour, que ce soit des fichiers au format MSI, MSP ou EXE.

Contrairement à PDQ Deploy ou System Center Configuration Manager qui sont des outils payants, WSUS Package Publisher – que je vais appeler WPP – est totalement gratuit et disponible sur CodePlex. Cette application incarne la suite de l’outil « Local Update Publisher« , pour ceux qui connaissent.

A. Pourquoi mettre en place WSUS Package Publisher ?

Lorsque vous gérez un parc informatique plus ou moins conséquent, vous déployez vos machines avec une image de référence avec des versions logicielles à un instant t.

Pour la partie Windows et les logiciels Microsoft (Office, par exemple) vous diffusez certainement les mises à jour par le service WSUS (Windows Server Update Service). Mais alors, pour les logiciels comment faites-vous les mises à jour ? Comment gérez-vous les mises à jour à répétition de Java ou encore de Flash Player ? Telle est la problématique bien souvent en entreprise…

C’est là que WPP intervient ! Il va vous permettre de déployer les mises à jour des logiciels que vous avez installés sur vos clients, voire même installer de nouvelles applications.

Avec les mises à jour régulières des applications, qui ont en plus des cycles de mises à jour différents, les solutions de ce type sont indispensables, notamment pour déployer les correctifs qui touchent des failles de sécurité (Java et Flash Player en tête de liste). Et par la même occasion pour bénéficier des corrections de bugs et de nouvelles fonctionnalités.

B. Comment fonctionne WSUS Package Publisher ?

WSUS Package Publisher vient se greffer directement à WSUS. En effet, en s’appuyant sur la base de données et le service WSUS (notamment pour la gestion des groupes d’attribution et la diffusion des mises à jour), vous allez pouvoir diffuser vos mises à jour sur les clients par l’intermédiaire de Windows Update.

Ainsi, les mises à jour Java, Flash Player, Adobe Reader, etc… Seront déployées directement via Windows Update au même titre que les mises à jour Windows. Le tout de manière totalement transparente pour l’utilisateur.

À partir d’un fichier MSI, MSP ou EXE, vous pourrez créer un paquet au sein de WPP et le diffuser sur un ou plusieurs groupes de clients. L’application contient un outil de création des mises à jour, avec une version standard et une version – très – avancée pour les utilisateurs avertis (voire même un peu plus).

Je vous conseille de réaliser l’installation de WSUS Package Publisher sur le même serveur que WSUS, sous Windows Server donc, tout en sachant qu’il dispose de sa propre console de gestion (il pourrait être installé sur une machine cliente Windows).

II. Installation de WSUS Package Publisher

Avant de commencer, sachez que vous devez disposer d’un serveur WSUS actif et opérationnel pour pouvoir mettre en oeuvre WPP, ce serveur devra également comporter au minimum le .NET Framework 4.0.

Commencez par télécharger le ZIP contenant les fichiers d’installation sur CodePlex : Télécharger WPP

Pour ma part, je vais installer WPP sur un serveur nommé « ADDS01 » qui comme son nom l’indique est un contrôleur de domaine (pour le domaine it-connect.local) et il joue aussi le rôle de WSUS, comme son nom l’indique…pas.

En fait, il n’y a pas de setup pour installer WPP, il suffit d’extraire le contenu du ZIP. Je vous conseille de l’extraire dans un dossier nommé « WSUS Package Publisher » directement dans « C:\Program Files ».

Ensuite, ouvrez le fichier « Wsus Package Publisher.exe » pour démarrer l’application. Vous obtiendrez un écran comme ci-dessous :

Comme on installe WPP sur le même serveur que WSUS, les paramètres de configuration sont automatiquement renseignés, sinon il aurait fallu les options en allant dans « Tools » puis « Settings« .

Cliquez sur « Connect/Reload » pour établir la connexion avec votre serveur WSUS.

Oups ! Nous n’avons pas de certificat de sécurité de renseigné dans l’application, il va falloir en générer un pour qu’elle puisse fonctionner.

Dans le menu « Tools » cliquez sur « Certificate« .

Note : Vous pouvez en profiter pour passer l’application en Français en changeant la langue sous le menu « Language« .

 

Cliquez sur « Generate the certificate » pour qu’un certificat autosigné soit créé. Vous devriez obtenir un message de validation comme celui ci-dessous.

Il va désormais falloir sauvegarder le certificat en tant que fichier puisque l’on devra ensuite le distribuer sur les postes clients via une GPO. Pour réaliser cette action, cliquez sur « Save the certificate » et enregistrez-le par exemple sous le nom « WPP ».

Note : Si le bouton « Save the certificate » est grisé au sein de l’interface WPP, redémarrez les services WSUS (voir la commande ci-dessous) et dans WPP recliquez sur « Connect/Reload » pour actualiser la connexion avec le serveur. Ensuite, retournez dans le gestionnaire de certificat et le bouton doit être accessible.

Pensez à redémarrer les services WSUS, en PowerShell voici la commande adéquate :

Restart-Service WsusService,WsusCertServer

On va s’assurer que le certificat que l’on vient de générer est bien enregistré dans le magasin des certificats local. Pour cela, ouvrez une console MMC vierge dans laquelle on va charger le composant certificat.

Dans le menu « Fichiers » sélectionnez « Ajouter/Supprimer un composant logiciel enfichable« .

Lorsque vous validerez pour ouvrir la console, vous devez choisir « Un compte d’ordinateur » puis « Ordinateur local » afin d’accéder au magasin local du serveur.

Dans l’arborescence de certificats, vous devriez avoir un dossier « WSUS » avec un sous-dossier « Certificats« , et si tout va bien le certificat WPP doit apparaître sur la droite : WPP Self-Signed.

Tout est bon du côté du serveur WSUS/WPP, nous allons pouvoir passer à la suite de la configuration.

III. Créer la GPO de configuration du pare-feu

Pour ne pas faire redondance avec la documentation proposée sur la page WSUS Package Publisher, pour la création de la GPO contenant les règles de pare-feu, je vous oriente vers la documentation très bien faite : Ouvrir les ports du firewall pour WPP

L’ouverture des ports est limitée et très fine, d’où l’intérêt de bien suivre cette documentation. Je noterai seulement que dans la règle du pare-feu, plutôt que d’autoriser tout le réseau ou une plage réseau, autorisez seulement l’adresse IP de votre serveur WSUS.

Ces ouvertures de ports permettent d’utiliser certaines fonctionnalités de WPP notamment le « Detect Now » et le « Report Now » pour déclencher des actions à distance depuis la console de Windows Package Publisher. Vous pouvez aussi consulter logs Windows Update à distance, intéressant en cas de debug.

IV. Créer la GPO pour diffuser le certificat

Sur votre contrôleur de domaine, dans la console de gestion des stratégies de groupe, créez ou éditez une GPO afin que l’on diffuse le certificat WPP auprès des clients. Nous allons utiliser des paramètres ordinateurs.

Parcourez l’arborescence de paramètres comme ceci :

Configuration ordinateur, Stratégies, Paramètres Windows, Paramètres de sécurité, Stratégies de clé publique

Vous devez l’importer dans deux magasins, notamment « Éditeurs approuvés » qui sera utilisé pour signer les paquets de mises à jour et dans « Autorités de certification racines de confiance« .

Pour réaliser l’importation, effectuez un clic droit sur le magasin et choisissez « Importer« , il faudra alors choisir le fichier de certificat que nous avons sauvegardé précédemment.

V. Autoriser les mises à jour en local

Un paramètre au niveau de Windows Update doit être modifié également par GPO pour autoriser le déploiement de mises à jour autres que celles signées par Microsoft, ce qui nous intéresse pour déployer des mises à jour signées par WSUS Package Publisher, et correspondantes à d’autres logiciels : Java, Flash Player, Adobe Reader DC, 7-Zip, Mozilla Firefox…

Dans une GPO, activez le paramètre suivant : Autoriser les mises à jour signées provenant d’un emplacement intranet du service de Mise à jour Microsoft 

Sous l’arborescence : Configuration ordinateur, Stratégies, Modèles d’administration, Composants Windows, Windows Update

Voilà, la mise en place de WSUS Package Publisher est terminée ! La prochaine étape c’est d’apprendre à créer son premier paquet de mises à jour pour le diffuser auprès des clients. La prise en main de l’outil de création de paquets utilise une certaine logique, mais une fois que vous l’aurez comprise, l’utilisation est vraiment agréable.

D’autres tutoriels sur le sujet vont arriver, prochainement, notamment pour apprendre à déployer la mise à jour de différents logiciels. Pour ma part, j’ai réalisé le déploiement de diverses applications et mises à jour avec WPP : Java, Flash Player, Mozilla Firefox, Google Chrome, Gimp 2, Adobe Reader DC, LibreOffice ou encore 7-Zip.

Amazon Drive est désormais disponible en France et aura pour objectif de concurrencer les ténors du marché : OneDrive, Google Drive, Dropbox ou encore HuBiC de l’hébergeur français OVH.

Déjà disponible aux États-Unis cette offre vous permet de bénéficier d’un stockage illimité dans le Cloud Amazon pour 70€ par an.

A titre de comparaison et pour montrer que ce tarif est réellement attractif :– 10 To chez HuBiC pour 50€ par an

• 2 To dans le Cloud Apple pour 19.99€ par mois, je vous laisse calculer le montant à l’année….
  
• 1 To chez OneDrive pour 7€ par mois (ou 10€ pour le mode 5 utilisateurs)
  
• 1 To chez Dropbox pour 8.25€ par mois
  
• 1 To sur Google Drive pour 9.99 dollars par mois

Pour Amazon, si l’on fait le calcul c’est moins de 6€ par mois pour un stockage illimité ! Sinon il y a aussi des solutions comme ownCloud pour héberger soi-même ses données et en garder la maîtrise

Il est à noter que les clients Amazon Prime ont le droit d’un stockage de 5 Go ainsi qu’un stockage illimité pour les photos, ce qui correspond à l’offre Amazon Drive Premium Photos.

Pour ce qui est des différents clients, sachez qu’un client Windows sera proposé ainsi qu’un client pour Mac, avec bien entendu la déclinaison iOS et Android pour les appareils mobiles. Il reste à espérer que Amazon prévoit un client pour Linux.

Êtes vous intéressé ?

source

I. Présentation de Set-Service

Dans la suite des tutoriels sur la gestion des services Windows en PowerShell, nous allons aujourd’hui étudier l’utilisation de la commande Set-Service. Nous avons précédemment vue la commande Get-Service qui permet de récupérer des informations à propos des services Windows, Set-service permet de modifier ces informations. Nous pourrons notamment modifier :

• Le mode de démarrage
• Les propriétés du services
• Le status actuel du services

Le tout peut être effectué sur le poste/serveur local (cas par défaut), mais également sur un ou plusieurs serveurs distants.

Note : Pour modifier l’état ou les propriétés d’un service, il faut avoir les droits d’administration sur la machine. Pour un poste/serveur local, pensez donc à ouvrir votre script ou console PowerShell en tant qu’administrateur.

II. Modifier un service

Comme vu précédemment, un service possède plusieurs attributs, nous allons dans cette section voir comment modifier le mode de démarrage et les propriétés du service nommé  « WebClient » :

Changer le mode de démarrage (valeur autorisée : « automatic », « manual » ou « disabled ») :

set-service -name WebClient -startuptype automatic

Pour changer le DisplayName (nom d’affichage)

set-service -name WebClient -DisplayName "DisplayName de WebClient"

Même syntaxe pour la description :

set-service -name WebClient -description "Description de WebClient"

Dans chaque cas, la valeur qui suit « -name » permet d’identifier le service à modifier, ce nom d’usage n’est pas modifiable. Dans la fenêtre graphique « Services » de Windows, c’est le DisplayName qui est contenu dans la colonne « Nom » et non le nom d’usage :

Via l’interface graphique, ce nom d’usage peut être trouvé en faisait un clic droit « Propriétés » sur le service ciblé :

Une petite astuce d’utilisation, l’ajout de l’option « -PassThru » permet d’afficher les attributs du service modifié pour constater le changement opéré :

III. Changer l’état d’un service

Un service peut avoir trois états :

• Running : en cours de fonctionnement
• Stopped : Arrêté
• Paused : En pause

Nous pouvons donc modifier l’état d’un service grâce à la cmdlet Set-service, par exemple pour le service nommé « WebClient » qui est en « Running », il faut exécuter la commande suivante pour l’arrêter :

set-service -name WebClient -Status "Stopped"

A l’inverse, pour le démarrer :

set-service -name WebClient -Status "Running"

A noter que la même opération et faisable sur un serveur distant :

set-service -name WebClient -Status "Running"  -computerName server01

Dans ce cas, il faut bien entendu que « server01 » soit un nom DNS resolvable.

Des commandes dédiées à l’arrêt, démarrage et redémarrage des services existent également :

# Redémarrer le service
restart-service WebClient
# Démarrer le service
start-service WebClient
# Arrêter le service
stop-service WebClient
# Mettre le service en pause
suspend-service WebClient
# Reprendre le service après une mise en pause
resume-service WebClient

J’espère que ce tutoriel vous aura été utile. La commande set-service est très souvent utilisée dans le cadre de scripting PowerShell, notamment lorsque l’on peut l’appliquer à plusieurs serveurs en une seule exécution via « -ComputerName« . N’hésitez pas à poser vos questions et vos avis dans les commentaires ou sur notre forum !

I. Présentation

La norme de sécurité de l’industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d’information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d’être compatible avec cette norme. Parmi celles-ci, l’enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

Il s’agit en effet du point 10.2.2 de la version 3 de la norme PCI-DSS :

Vérifier que toutes les actions exécutées par tout utilisateur avec des droits racine ou administrateur sont consignées.

Comme l’indique ce point de la norme PCI-DSS, les comptes à privilèges sont des cibles prioritaires pour les attaquants car leur compromission accroît considérablement les possibilités de vol ou de destruction. Ainsi, avoir une trace des commandes exécutées par un compte administrateur permet, lors d’une compromission, de récupérer les actions effectuées par l’attaquant. Ne pas posséder ces informations pourrait rendre très complexe, voir impossible, la remise en état d’un système compromis.

Note : Pour plus d’informations, je vous oriente vers la dernière version en date de la norme PCI-DSS (conditions 10.2.2 à la page 98) : Industrie des cartes de paiement (PCI) Norme de sécurité des données

Hors de la norme PCI-DSS. Sauvegarder ces informations peut être très utile, en plus de la sécurité en cas d’attaque, cela permet également de retracer d’éventuelles erreurs lors de l’administration d’un système.

Vous l’aurez compris, nous allons dans ce tutoriel mettre en place une sauvegarde de toutes les commandes saisies par les utilisateurs sur un système Linux. Pour ce faire, nous utiliserons l’outil « auditd » pour l’enregistrement sur les machines. Également, nous utiliserons « rsyslog » afin d’envoyer les commandes sur un serveur distant.

Note : La configuration rsyslog sera indiquée mais non expliquée en détail, ayant déjà écrit un tutoriel à ce sujet, je vous orienterai vers celui-ci pour plus d’explication

Passons maintenant à la mise en place de cet enregistrement des commandes saisies !

II. Installation et configuration d’auditd

Nous allons donc utiliser « auditd« , un outil de sécurité sur les distributions Linux. Il permet d’effectuer une monitoring des accès aux données et au système et notamment d’effectuer un audit des logs. Un tutoriel incluant auditd a déjà été présenté sur IT-Connect, il s’agissait alors de surveiller les accès au fichier /etc/passwd. Pour l’installation sur Debian/Ubuntu, saisir la commande suivante :

apt-get install auditd

De souvenir, auditd est présent sur certaines distributions de l’univers CentOS/Fedora. Dans le doute, voici la commande d’installation :

yum install auditd

Il est possible d’avoir à ajouter les dépôts EPEL. Suite à cette installation, un répertoire « /etc/audit » permettant la configuration d’auditd est créé. Nous allons ajouter les lignes suivantes dans  /etc/auditd/audit.rules » :

-a exit,always -F arch=b64 -S execve -k root-commands
-a exit,always -F arch=b32 -S execve -k root-commands

L’option « -a » permet d’indiquer au système d’ajouter une règle.

• « -F » : permet de spécifier l’architecture et plus généralement les règles de matching avec ce que l’on veut auditer.
• « -S » : Permet de cibler certains appels systèmes. execve est l’instruction système qui permet d’exécuter un programme ou un script, par exemple « echo » qui pointe vers « /bin/echo ».
• « -k » : Permet d’ajouter un filtre à la règle d’audit. Ici nous ciblons, les données enregistrées dans les logs pourront être recherchée à l’aide du tag indiqué.

Nous pourrons ensuite redémarrer le service auditd avec la commande suivante :

service auditd restart

Pour confirmer que les règles sont bien chargées, nous pouvons utiliser la commande « auditctl -l« . Voici la sortie attendue :

Bien maintenant, nous pouvons constater que les commandes saisies sont ajoutées dans le fichier de log /var/log/audit/audit.log, voici ce que l’on peut voir après l’exécution de quelques commandes :

Ici, nous pouvons voir trois commandes saisies. Beaucoup d’informations sont affichées, nous avons ici les détails sur le contexte d’exécution, l’utilisateur, la commande exécutée, etc.

En bleu, nous pouvons voir que l’utilisateur root a exécuté la commande « ls », en vert la commande « cat » avec comme argument « /etc/passwd » et enfin en orange la commande « cat » sur « /var/log/audit/audit.log« .

auditd est un outil complet qui permet de grande customisation et de nombreuses possibilités. J’en reste néanmoins ici car mon objectif est rempli, les commandes saisies par tous les utilisateurs de mon système sont enregistrées.

III. Envoyer les logs sur un serveur distant via rsyslog

L’enregistrement des commandes, c’est fait. Que ce passe-t-il à présent si un attaquant arrive à prendre le contrôle de votre serveur (notamment les droits root) et à effacer les logs enregistrés sur votre machine ?

Il faut savoir que l’effacement des traces est une étape que les attaquant oublient rarement, la suppression des logs est à prévoir dans le cas ou votre serveur est compromis. Ainsi, il est important d’exporter vos logs en temps réel vers une autre machine à laquelle l’attaquant n’aura pas accès. Voir à plusieurs machines en fonction de la taille et de l’importance de votre système d’information.

Dans cette partie, je vous présente quelques commandes pour envoyer vos logs auditd vers un serveur rsyslog. Comme je l’ai indiqué précédemment, je ne détail que peu les commandes, un tutoriel plus détaillé est déjà présent sur IT-Connect : Centralisez vos logs avec Rsyslog

Bien, sur notre serveur rsyslog, qui est la machine destinée à recevoir les logs auditd générés, modifier le fichier /etc/rsyslog.conf en dé-commentant les lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

Pour la machine cliente, les modifications suivantes sont à effectuer dans le fichier /etc/rsyslog.conf :

# auditd audit.log
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

local6.* @192.168.1.22:514

Pensez à remplacer « 192.168.1.22 » par l’IP de votre serveur rsyslog.

Après redémarrage des deux services rsyslog via la commande « service rsyslog restart« , les logs auditd devraient arriver dans le fichier /etc/syslog de votre serveur rsyslog ! Vous pourrez les remarquer facilement car ils comporteront le nom de votre machine distante et non celui de votre machine locale comme habituellement.

C’est tout pour cet article, nos logs sont maintenant envoyés sur un serveur distant. Bien entendu, si un attaquant arrive à prendre le contrôle total de votre serveur, il arrivera toujours à couper l’écriture des logs ou l’envoie de données à des serveurs distant, sous conditions qu’il ai remarqué que les commandes qu’il tape sont enregistrées… Néanmoins, il est toujours possible de retracer ses premières actions et ainsi d’en savoir plus sur son mode opératoire.

Il existe d’autres outils sous Linux permettant de remplir ce rôle mais auditd me parait être l’outil libre le plus intéressant. N’hésitez pas à partager vos avis et questions dans les commentaires.