Lorsque vous démarrez sur une machine ayant comme système d’exploitation GNU/Linux, il y a de très fortes chances que le chargeur d’amorçage (bootloader) soit Grub. Si c’est le cas, il vous suffit d’appuyer sur la toucher e pour éditer les paramètres de lancement, et pouvoir réaliser toute une série d’actions.
Bien souvent, cela peut être utile pour obtenir un shell root et dépanner sa machine personnelle, mais en entreprise (sur desktops comme serveurs), on préférerait bloquer les modifications d’entrées Grub, pour éviter certaines mésaventures.
C’est ce que nous allons voir ici, comment protéger la modification d’entrées Grub sur une Debian, mais sans pour autant exiger un mot de passe pour démarre l’OS (ce sont deux choses bien distinctes).
Sans plus attendre, allons-y !
I) Créer les users et passwords correspondants
La première étape est donc de créer les couples user/passwords qui permettront de déverrouiller ces dites entrées. Bien-entendu, libre à vous d’en créer un seul, ou une dizaine, c’est au choix !
La première étape est donc de générer le hash pour nos différents passwords, ici je ne créerai qu’un utilisateur, mais le principe est le même, il suffit de le faire autant de fois que l’on a de users :
sudo grub-mkpasswd-pbkdf2
Cette commande va nous permettre d’obtenir un hash de notre password une fois encodé.
On modifie ensuite le fichier /etc/grub.d/40_custom, pour y définir le ou les utilisateurs avec le hash de leur mot de passe :
# Si vous désirez spécifier plusieurs users
set superusers="root utilisateur02 utilisateur03 utilisateur04"
# On rajout le hash correspondant ensuite à chaque user
password_pbkdf2 root grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur02 grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur03 grub.pbkdf2.sha512.10000~
password_pbkdf2 utilisateur04 grub.pbkdf2.sha512.10000~
Ici je n’ai mis que l’utilisateur root, mais libre à vous de mettre l’utilisateur système de votre choix !
On peut ensuite enregistrer le fichier. puis mettre à jour la configuration de grub via un classique update-grub.
Si vous redémarrez votre machine maintenant, vous verrez que le mot de passe est bien demandé (et avec un agencement de clavier en qwerty au passage !), mais pas seulement pour l’édition, aussi pour le simple boot… et ce n’est pas ce que l’on souhaite ici.
II) Empêcher les modifications, pas le démarrage de l’OS
Rien de très sorcier ici, il nous suffit d’éditer cette fois le fichier /etc/grub/10_linux et de rajouter le flag –unrestricted aux entrées désirées :
Ici, on modifie directement la commande echo « menuentry … » de sorte que lorsque votre kernel sera mis à jour, ces modifications resteront intactes. Bien-entendu, il est aussi possible de ne bloquer l’édition ou le boot que pour une entrée Grub bien particulière.
N’oubliez pas une fois cette modification effectuée de bien exécuter la commande update-grub à nouveau !
Et c’est tout ! Vous savez désormais comment protéger vos entrées Grub, voir même proposer un mot de passe supplémentaire pour le démarrage de votre OS !
Comme d’habitude, j’espère vous avoir appris quelques bricoles, et vous souhaite une bonne journée/soirée !
Initialement, je voulais présenter le logiciel Ping Castle, qui est un logiciel permettant d’auditer les domaines Active Directory, qui est Open Source, gratuit pour un usage personnel, et qui plus est est français ! #Cocorico.
Cependant, j’ai vu qu’il y a quelques mois le site IT-Connect avait d’ores et déjà publié un article à ce sujet, et voulant tout de même parler d’audit d’AD je me suis rabattu sur un soft propriétaire mais tout aussi performant, voir plus complet : Purple Knight… Second bémol, Florian Brunel toujours d’IT-Connect a aussi posté un article sur ce soft…
Mais bref, ce n’est ni le premier et je ne serai ni le dernier à parler de ce genre de logiciel donc autant se lancer ! Au passage je vous conseille vivement d’aller voir ses articles à lui, même si vous les avez déjà sûrement déjà parcouru
Bref, allons-y !
I) Auditer un Active Directory ?
En entreprise, c’est bien joli d’avoir un pare-feu dernière génération, de sensibiliser ses utilisateurs sur les dangers du phishing, de maintenir son parc à jour en temps réel, mais on oublie trop souvent les misconfigurations, les oublis, les « je ferai ça plus tard« , ou encore les « c’est déjà assez secure comme çanon ?« .
Ce n’est clairement pas un reproche, Active Directory est si complet que connaître toutes les best-practices, surtout en terme de sécurité, ça demande un temps considérable et ce n’est même pas humainement faisable.
Heureusement pour nous, il existe pléthore d’outils permettant d’auditer notre domaine. Que ce soit dans le monde Open Source (PingCastle), ou propriétaire (Purple Knight), et tant d’autres.
II) Here comes Purple Knight
Purple Knight est donc un soft édité par la société Semperis, très connue pour ses solutions de sécurité directement liées à AD/Azure AD.
Pour le télécharger, rien de plus simple, on se rend ici. Au niveau de ce lab, j’aurais une simple VM Active Directory avec quelques OUs et quelques users, rien de transcendant, et j’aurais une seconde VM qui hébergera justement l’outil d’audit.
Concernant l’installation à proprement parler, il n’y en a pas réellement, c’est un simple .exe qui exécutera ensuite une série de scripts Powershell. Libre à vous donc de l’utiliser directement sur votre machine et non sur un serveur dédié forcément prévu pour ça.
III) Démarrage et premier audit
Une fois le soft lancé, c’est du « Suivant suivant ». On accepte en premier lieu les CGU :
Si votre ordinateur/serveur fait déjà parti du domaine, celui-ci sera détecté automatiquement, sinon vous devrez modifier vos DNS et l’encoder manuellement :
On peut ensuite choisir quel groupe de tests va être exécuter, on peut bien-entendu adapter au besoin, le tout est assez bien fichu :
Et c’est tout ! La série de tests se lancent :
Vous obtenez ensuite un « score de sécurité globale », ainsi qu’un fichier report au format HTML ou CSV, voir PDF :
Voici un exemple du dit rapport, bien-entendu selon le domaine en question il va de soit que le score et les points seront différents… le tout est en anglais (forcément ?), mais très bien détaillé !
On notera qu’il s’agissait ici d’un domaine « fraîchement installé », comme quoi même avec une installation basique, impossible d’attendre le St Graal. Si vous avez un minimum peuplé votre AD, votre score en pâtira clairement, mais comme vous pourrez le constater avec les différentes explications et ressources, il est très facile de corriger le tir.
IV) Conclusion
Ceci clôture donc déjà cet article sur la présentation de Purple Knight. Il existe comme dit en début bien d’autres outils d’audit, que ce soit pour Active Directory mais pour beaucoup d’autres services aussi.
J’espère comme d’habitude vous avoir appris quelques bricoles, voir plus, et vous donne rendez-vous bientôt pour un article où nous nous attaquerons très sûrement à une box TryHackMe, histoire d’avoir un peu plus de pratique !
Petit article expliquant comment installer Wireguard en tant que serveur sur une Debian 10, et comment ensuite installer son client Windows 10 sur une machine en dehors de ce réseau, de sorte à tester le VPN en mode Client-to-Site.
Sans plus attendre, allons-y !
I) Présentation du lab
Une fois n’est pas coutume, c’est armé de mon petit VMWare Workstation que je ferai ce lab. Et comme toujours, rien de compliqué !
fw-brussels-01, en 192.168.0.20/24 pour le WAN, et 192.168.1.1/24 pour le LAN ;
fw-paris-01, en 192.168.0.30/24 pour le WAN, et 192.168.2.1/24 pour le LAN ;
hoster-vpn-01, en 192.168.2.50/24, sur le réseau LAN de Paris ;
client-w10, en DHCP et sur le réseau LAN de Bruxelles ;
Le but ici était donc de mimer deux réseaux distincts, avec un serveur VPN présent à Paris, et un client présent à Bruxelles souhaitant s’y connecter.
Côté Firewall –ce n’est pas important– mais il s’agit de simples pfSenses. Fortigate, Sophos, ou même votre simple modem personnel peut suffire, il faudra simplement réaliser du Port Forwarding vers votre serveur VPN.
I) Installation de Wireguard sur Debian 10
Je ne vais pas vous faire l’affront de vous ré-expliquer ce qu’est Wireguard (un protocole ET un software, comme pour OpenVPN), je vous renvois sur un ancien article en lieu et place :
Donc, une fois connecté en SSH sur votre joli petit serveur, installons donc le package (on ajoute le dépôt buster-backports, un petit refresh, et le tour est joué) :
sh -c "echo 'deb http://deb.debian.org/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/buster-backports.list"
apt update && apt install wireguard -y
Une fois installé, place à la configuration du serveur !
II) Configuration du serveur Wireguard
La première étape est donc de générer notre paire de clefs publique/privée :
cd /etc/wireguard
# Les fichiers créés dans ce répertoire auront ces permissions de base
umask 077
# Création de la paire de clefs
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickey
Une fois notre paire de clefs générée, on créer le fichier de configuration :
touch /etc/wireguard/wg0.conf
L’interface par défaut sera donc nommée wg0, mais rien ne vous empêche de la nommer vpntest ou encore wg17 si vous avez plusieurs VPN.
Maintenant, place à la configuration :
Dans ce fichier on renseignera donc :
L’IP de notre interface réseau ;
Le fait de ne pas sauvegarder automatiquement l’état de la carte réseau lors de son arrêt ;
Le port sur lequel Wireguard va écouter ;
Notre Private Key ;
Le PostUp/PostDown, qui sont des commandes IPtables permettant de réaliser du forward ainsi que du NAT ;
Nos peers, c’est-à-dire nos clients (voir plus bas) ;
A noter que si votre interface réseau physique se dénomme par ex. eth0, renseignez donc eth0 et non pas ens33 comme dans l’exemple !
### Configuration du serveur
[Interface]
Address = 192.168.2.50/24
ListenPort = 51820
PrivateKey = VotrePrivateKey
SaveConfig = false
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens33-j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE
### Configuration des clients
[Peer]
# Windows 10 test client
PublicKey = CléPubliqueDuClient
AllowedIPs = 10.0.0.1/28
On peut ensuite démarrer le service, et l’activer à chaque démarrage :
Comme on peut le voir ici, le service est bien démarré !
Il nous reste encore à activer l’IP Forwarding, pour ce faire, rien de plus simple :
nano /etc/sysctl.conf
# Décommentez ensuite la ligne suivante
net.ipv4.ip_forward=1
Côté serveur, tout est bon ! Il vous faudra simplement modifier la section Peers pour renseigner la clef publique ainsi que l’IP qu’aura votre/vos client(s).
IV) Installation du client Windows
Rien de plus facile ! On télécharge le client, au format exe ou msi depuis ce site, et on l’installe (Suivant, Suivant… rien de sorcier).
Ensuite, il nous faudra générer la paire de clefs pour ce client, et la rajouter sur notre serveur Wireguard (voir fichier wg0.conf plus haut). Pour ce faire, on retourne sur notre petite Debian :
wg genkey | tee /etc/wireguard/privatekey_w10_client01 | wg pubkey | tee /etc/wireguard/publickey_w10_client01
Comme vous pouvez le voir, c’est exactement la même commande que pour la paire des clefs générée pour le serveur lui-même en début d’article, mais ici bien-entendu on change le nom de fichier pour la pub/private key :
Prenez donc cette clef publique, et décrivez le client dans votre fichier wg0.conf, voir plus haut.
Une fois ceci fait, on peut créer le fichier de config sur notre client :
Le tout dans un petit fichier de type « maconfig.conf » par exemple, et c’est tout ! Importez-le sur le client Wireguard and here we go.
On renseigne donc :
Sa Private Key ;
Son adresse pour le tunnel ;
Le ou les serveurs DNS à utiliser ;
La Public Key du serveur WIreguard ;
Concernant le champ AllowedIPs, soit vous pouvez rajouter le réseau distant, pour ne router que le trafic à destination de ce réseau via le VPN, soit si vous désirez router la totalité de votre trafic, vous pouvez mettre « 0.0.0.0/0, ::/0 » pour l’IPv4 et IPv6 respectivement ;
Et enfin concernant l’Endpoint, il s’agit ni plus ni moins que l’IP/L’hostname du serveur distant. Ici il s’agit donc de l’IP WAN de mon pfSense, où j’ai réalisé un simple port forwarding sur le port 51820 en UDP, à destination de mon serveur Wireguard ;
Une fois ceci fait, on peut tester notre connexion !
V) Test et conclusion
Des images valent mieux que mille mots, voici donc ! A noter que je me suis même permis d’installer rapidement un simple serveur Apache sur le LAN distant pour bien vérifier que notre client à accès au réseau.
La connexion VPN est bien établie, on le voit notamment au niveau du trafic envoyé/reçu.La connectivité est bien là.
Vous avez donc réussi à mettre en place un serveur Wireguard sous une Debian, ainsi qu’à connecter un client sous Windows 10, félicitations !
Je ferai sûrement un prochain article dans le cadre de la mise en place d’un VPN de type Site-to-Site.
Comme à mon habitude, j’espère que ce rapide article vous aura plus, et je vous souhaite une bonne journée/soirée !
Aujourd’hui, et pour recommencer en douceur, nous allons découvrir le paquet unattended-upgrades qui permet comme son nom l’indique de de pouvoir obtenir les mises à jour de sécurité/mises à jour classiques de manière automatique.
Idéal si vous désirez automatiser un tant soit peu les mises à jour de vos différents serveurs persos donc.
I) Installation du package
Disponible de base dans les dépôts, un simple apt install suffit :
Et le tour est joué ! A noter que ce package est naturellement disponible pour Ubuntu, Mint, et autres dérivés.
II) Configuration
Rien de très sorcier, le fichier de configuration se situe ici : /etc/apt/apt.conf.d/50unattended-upgrades.
La première section concerne les différents dépôts qui vont être utilisés. Par défaut, sur une Debian 10 classique, il n’y aura que les dépôts Debian et Debian-Security d’activés. Libre à vous bien-entendu d’ajouter d’autres dépôts personnels si vous le désirez.
La seconde section concernant les paquets que l’on ne souhaite pas mettre à jour automatiquement via cet outil, c’est-à-dire les paquets à blacklister :
Comme on peut le voir, il suffit d’écrire le nom du package, en rajoutant bien le « $ » pour signifier la fin de son nom.
Enfin, les autres sections restantes sont orientées bidouillage :
On peut par exemple faire en sorte d’installer les mises à jour seulement lorsque la machine s’éteint, on peut activer les notifications par mail (en cas de réussite ou non), on peut supprimer automatiquement les anciens kernels non-utilisés… la liste est longue.
Une fois votre configuration aux petits oignons terminée, on peut passer à son activation. Pour cela on copie le template et on l’édite :
Concernant la modification de ce fichier, rien d’insurmontable ici :
Rajoutez simplement la première ligne, permettant d’activer l’outil, et concernant les deux autres lignes elles indiquent simplement la fréquence à la quelle mettre à jour la liste des paquets dans les dépôts, et à quelle fréquence upgrade les paquets présents sur le système (0 pour désactiver, et X pour tout les X jours, ici j’ai mis chaque semaine).
III) Exécution de l’outil
Pour tester sa bonne mise en place, on peut démarrer l’outil manuellement. Comme on peut le voir sur la capture d’écran ci-dessous, aucun paquets n’est à blacklister, et aucune whitelist n’a été fournie.
sudo unattended-upgrade -d
Et c’est tout ! Désormais vos systèmes se mettront à jour de manière automatique.
C’est tout pour ce rapide article, d’autres plus conséquents arriveront très vite !
Le dernier article où je parlais de nouveautés autour du blog, c’était il y a déjà deux ans ! Ici pour les plus curieux.
Pas mal de chemin parcouru en deux ans… mais là n’est pas le sujet ! Si j’écris ce rapide article c’est pour vous dire que non, ce blog n’est pas tombé aux oubliettes ! En effet, j’ai eut diverses choses à régler au niveau de ma vie perso/pro, et je pense maintenant que tout semble rouler à nouveau, je vais donc pouvoir me remettre vraiment à la rédaction d’articles.
En parlant de vie pro, j’ai justement eut un nouveau job, cette fois je ne suis plus Sysadmin mais bien Ingénieur Cybersécurité junior ! Un sacré pas en avant ici aussi, avec moultes choses à découvrir et à apprendre. Pour ceux qui sont intéressés par la Cybersécu’, pas mal d’articles autour de ce sujet devraient donc arriver au fil du temps
Cependant rassurez-vous, ce blog continuera de parler d’installs réseaux et serveurs, de distributions Linux ou autre, comme je l’ai toujours fait avant.
Après plus d’une centaine de posts, il faut aussi savoir que j’ai acquis beaucoup de connaissances certes, mais que désormais (et je pense que vous l’aurez vu, en comparant mes premiers articles aux plus récents), j’essaie de m’attaquer à des sujets plus complexes, plus pointus. Le bémol, c’est que pour écrire sur ces sujets, il faut que je me forme de manière plus pointue aussi, en lisant des ouvrages, prenant des formations… choses que je faisais déjà avant, mais de manière plus soft.
C’est un chouilla plus compliqué d’expliquer en détails comment fonctionne un cluster K8S sur une infra’ hybride plutôt qu’expliquer comment installer Proxmox
Il faut aussi savoir que j’ai encore énormément de brouillons dans mes tiroirs, mais soit il me manque du matos physique (compliqué de faire un lab Fortigate sans pare-feux), soit comme dit plus haut je n’ai pas encore les connaissances suffisantes selon moi pour en faire un article. J’essaie toujours de maîtriser un maximum ce dont je vais parler, ça tombe p’tet sous le sens mais voilà. D’autant plus que comme souvent sur ce blog, je définis et explique en amont quelle est telle solution, tel protocole, avant de me lancer dans le lab.
Cela m’amène donc au prochain point, et vous l’aurez sans doute remarqué sur les tout derniers articles, mais je compte proposer des articles plus lights, histoire de pouvoir garder une pseudo « cadence de publication » un peu correcte. Imaginons que je veuille faire un article sur un élément bien précis de K8S par exemple, je pense qu’il n’est pas obligatoire que j’explicite en long et en large ce qu’est Kubernetes en introduction de l’article. Alors certes je le ferai le plus souvent possible, car j’aime moi-même tomber sur un article où la personne explique bien de quoi l’on va parler, mais si le temps me manque, ou que j’estime que ce n’est pas nécessaire, je passerai outre.
Et je pense que c’est à peu près tout… je n’ai pas encore de date précise sur la sortie du prochain post, surtout que je vais démarrer mon nouveau job d’ici quelques jours, et que quelques semaines après arrivent les fêtes de fin d’année. Mais au moins voilà, vous aurez eut une petite update du pourquoi ce blog était en standby.
Sur ce, portez-vous bien et passez une bonne journée/soirée !
Très court article expliquant comment résoudre le bug OpenVPN C2S.
Netgate a annoncé il y a quelques semaines la sortie de pfSense+ 22.05. Cependant, après cette mise à jour, plusieurs utilisateurs se sont rendus compte qu’OpenVPN –particulièrement les serveurs Site-to-Site de ce que j’ai pu lire– ne fonctionnaient plus… la connexion s’affiche bien comme établie, mais impossible pour le client d’accéder au LAN du serveur distant.
Après quelques rapides recherches, je suis tombé sur plusieurs posts où les utilisateurs s’en sont plaint (ici par exemple), avec une réponse qui revenait assez souvent: ré-installer la dernière version, qui visiblement n’updatait pas correctement le package OpenVPN, puis ré-importer un backup et le tour est joué… ou bien update le paquet OpenVPN en SSH…
Ou alors simplement modifier les paramètres du client ?
Le soucis, c’est qu’en production, c’est toujours un peu casse-pieds de réinstaller un routeur/firewall à la volée, encore plus pour un site distant, et étant un tantinet flemmard (mais paraît-il qu’un bon Sysadmin est fainéant?Puis c’est lundi matin…), je me suis un peu plus documenté et j’ai testé une solution apportée par l’utilisateur Neverstopdreaming, et il s’avère que celle-ci fonctionne à merveille ! Bon, selon d’autres sa solution ne fonctionnait pas chez eux, mais je planche plutôt pour d’autres soucis de configuration.
Bref, voici la solution: Sur le client, aller dans les paramètres OpenVPN, et ne pas renseigner le champ IPv4 Tunnel Network, ni le champ IPv4 Remote Network. Car à première vue, avec cette nouvelle mouture d’OpenVPN, le serveur push ces informations là directement au client… Il ne vous reste plus qu’à redémarrer le service, et le tour est joué !
Bien-entendu, à l’heure où j’écris ces lignes je ne suis pas sûr et certain que ce soucis ne vienne pas d’autre part, ou tout dû moins qu’il faille obligatoirement modifier sa config, j’effectue encore plusieurs tests sur le côté, mais visiblement cela a solutionné mon problème, donc je me permets de vous la partager ici aussi, sait-on jamais
Sur ce, passez une bonne journée/soirée, et comme d’habitude, faites des backups !
Il m’est arrivé de me rendre compte sur l’un de mes serveurs Windows, que ce dernier affichait « Batterie en charge »… sauf qu’il s’agit d’un serveur au format rackable. Un peu étrange non ? Vérifiez par vous-même, vous risquez d’être surpris !
Bon pour ceux connaissant la réponse (mais au vu des nombreux posts dans les forums, ça ne semblait pas forcément tomber sous le sens), pas de magie noire ou de bug ici, simplement le fait que WS détecte l’UPS branché comme étant une batterie, et vous affiche donc sa charge et le pourcentage correspondant…
D’ailleurs, il existe une petite commande Powershell permettant de voir quelle(s) batterie(s) Windows détecte au juste :
wmic path Win32_Battery get Caption,Description,DeviceID,Name
Bref, rien d’incroyable mais j’avoue que cela avait piqué ma curiosité !
Sur ce, à bientôt pour des articles (je vous rassure) plus fournis que celui-ci !
Installation du logiciel de gestion de parc informatique Open Source.
GLPI, pour Gestionnaire Libre de Parc Informatique, est… et bien son nom l’indique ! Un logiciel qui va nous permettre d’inventoriser notre parc informatique, le tout de manière gratuite et libre.
Je ne vais pas le détailler de fond en comble tant celui-ci est connu dans le monde Open Source, mais ce dernier va nous permettre de :
Gérer un inventaire de nos différentes machines et équipements, des laptops aux écrans, en passant par les serveurs, les dockings… ;
Obtenir une vue de nos différents racks informatiques, avec la possibilité de voir le nombre de baies encore disponibles ;
Encoder les différentes factures d’achats, et les relier aux différents équipements ;
Gérer l’aspect Helpdesk via un système de ticketing, même si personnellement je préfère la solution Hesk à cet égard ;
. . .
La liste est encore longue, d’autant plus avec les nombreux plugins mis à disposition !
Courant avril la version 10.0 est sortie, et pour ceux connaissant déjà GLPI, voilà à quoi l’interface ressemblait il y a plusieurs années…
Tiré de https://forum.glpi-project.org
Pas forcément très séduisant n’est-ce pas ? Et bien désormais, c’est une véritable refonte graphique qui a eut lieu ! Regardez ce changement ! (En plus de plusieurs optimisations et fonctionnalités majeures rajoutées!)
Tiré de https://glpi10.fr
Quand même un sacré changement non ? Je comptais depuis plusieurs mois voir années faire un article sur son installation, et avec cette mise à jour majeure récemment sortie, je m’y suis donc enfin mis.
Sans plus attendre, allons-y !
I) Installation de GLPI
Nous partirons sur une classique debian 10, et une fois celle-ci installée et configurée de manière basique, nous allons pouvoir commencer à nous atteler à l’installation de notre soft.
Tout d’abord, les prérequis :
Un serveur web, dans notre cas ce sera un classique apache ;
Une base données, ici ce sera mariadb ;
PHP 7.4 à 8.1, concernant la version 10.0 que nous allons installer. Au passage, en voulant installer la version 8.0 j’ai obtenu un joli « PHP 7.4.0 – 8.2.0 (exclusive) required« , donc nous allons installer la version 7.4 spécifiquement… ;
Sous Debian 10, en installant simplement le package « php« , la version 7.1 sera installée, nous allons donc installer manuellement la version 7.4.
# Serveur web et SGBD
apt update && apt install apache2 mariadb-server -y
Passons ensuite à la configuration de notre base de données !
# Pour définir un mot de passe root, et faire les réglages de base
mysql_secure_installation
# On se connecte en CLI
mysql -u root -p
# On créé notre base de données et son utilisateur
create database glpi ;
create user 'glpi-user'@'localhost' identified by 'Pa$$W0Rd' ;
grant all privileges on glpi.* to 'glpi-user'@'localhost' ;
flush privileges ;
Bien-entendu, libre à vous de choisir un nom spécifique pour votre base de données, votre utilisateur, ainsi qu’un mot de passe.
On peut ensuite télécharge l’archive contenant la dernière version stable de GLPI (à l’heure où j’écris ces lignes) :
On décompresse le tout, et on set les droits pour le serveur web :
gunzip glpi-10.0.1.tgz
rm glpi-10.0.1.tgz
rm -r /var/www/html/
cp glpi-10.0.1.tar /var/www/ && cd /var/www/
tar xvf glpi-10.0.1.tar
mv glpi html
chown -R www-data:www-data html/
Une fois le tout installé, on peut passer directement à l’interface web pour la finalisation !
Je vous conseille cependant d’aller lire la documentation, qui stipule de ne pas directement se ruer sur l’interface web, mais d’effectuer diverses configurations supplémentaires au niveau sécurité. Ici cela reste un lab/une présentation, mais toujours bon de le mentionner !Surtout que leur doc’ est plutôt bien fournie.
II) Configuration de l’instance GLPI via la WebUI
Une fois notre langue choisie, on peut choisir l’option Install ou Update, ici ce sera donc Install :
Nous avons ensuite droit à un récapitulatif des extensions éventuelles manquantes, soit obligatoires, soit facultatives :
On renseigne ensuite les informations concernant notre base de données, ici elle est installée en local donc nous utiliserons 127.0.0.1 bien-entendu :
On choisi notre base de données sur laquelle notre utilisateur a les droits :
Et le tour est joué !
On peut ensuite éventuellement envoyer les statistiques d’usage, s’inscrire, expliquer comment nous avons connu GLPI… classique.
Puis un petit récap’ sur les identifiants et mots de passe par défaut, à changer une fois connecté bien-sûr :
III) Connexion à l’interface web
Le login par défaut pour le compte admin étant donc glpi/glpi, nous pouvons nous connecter et tadaaaa :
On notera les deux petits warnings, un concernant le changement de mot de passe par défaut (logique), et l’autre concernant la suppression du fichier d’installation.
IV) Conclusion
Vous avez donc terminé d’installer votre instance GLPI ! Bien-entendu, diverses optimisations sont possibles, et je n’ai pas parlé des plugins, cet article était avant tout une découverte et un tuto sur son installation.
Comme d’habitude, j’espère vous avoir appris quelques bricoles, et essayez de toujours privilégiez l’Open Source, ça en vaut la peine
Aujourd’hui nous allons voir comment migrer une machine virtuelle Windows Server 2012 R2 depuis un Hyper-V (version 2019) vers un Proxmox en version 6.4.4.
I) Le lab et rapides explications~
Rien de très sorcier ici :
PVE 6.4.4 : 192.168.0.100/24 ;
Hyper-V 2019 : 192.168.0.110/24 ;
VM ActiveDirectorysous WS2012 R2: 192.168.0.150/24 ;
Côté AD, je n’ai créé qu’un ou deux utilisateurs, ainsi que deux OUs. L’important est vraiment de s’assurer qu’après la migration les users soient toujours là, mais en pratique aucun soucis. D’ailleurs, nous verrons une commande pour vérifier si le disque virtuel ne présente pas de corruptions (toujours utile à savoir, surtout qu’en production ce ne sera pas de simples disques de 30Go que vous allez migrer, mais des disques faisant plusieurs Téraoctets…).
II) Copie du disque VM vers le nœud Proxmox
Bien, une fois votre VM installée et votre AD un peu peuplé, on peut stopper la machine virtuelle, puis copier son disque.
Deux OUs, et deux users, classique.
Pour copier le disque il n’y a pas de manipulations particulières, simplement copier le .vhdx, car même si la documentation de Proxmox ne parle que de .vhd, ce dernier supporte tout à fait les .vhdx. Aucun soucis donc.
Sachez cependant qu’une applet Powershell existe pour convertir un .vhdx en .vhd, si vraiment le besoin s’en fait sentir.
Si vous devez copier un disque de gros volume, le plus simple est encore de le copier sur un volume partagé, avec une liaison Gigabit voir 10-Gigabit. Sinon, dans le cadre de ce lab, un simple scp suffit :
Ici je copie directement le disque depuis mon hôte Hyper-V, à destination de mon nœud Proxmox, dans le dossier root.
Si vous vous posez la question « quid si la VM possède plusieurs disques ?« , et bien en théorie pas de soucis, la marche à suivre sera sensiblement la même, mais ne l’ayant pas encore pleinement testé à l’heure où j’écris ces lignes, je ne peux vous le garantir. Sûrement un prochain article !
III) Re-création de la VM côté Proxmox
La première étape est donc de re-créer une VM, en essayant dans la mesure du possible de reprendre les mêmes configurations hardware (si votre VM avait 4Go de ram, ne pas lui en mettre 2, ou même 8, en tout cas au départ, etc.)
On créer donc notre VM, de sorte que :
L’OS Invité choisi soit de type Windows (ou Linux si votre VM était une Linux, cela tombe sous le sens) ;
Pas encore d’image ISO à attacher ;
Au niveau de la carte graphique, j’ai lu que SPICE était assez souvent utilisé, mais ici je garderai le standard sous peine d’avoir un curseur qui n’en fait qu’a sa tête… ;
Concernant le Contrôleur SCSI, bien choisir VirtIO SCSI ;
Concernant le BIOS, opter plutôt pour l’OVMF/UEFI ;
Concernant le disque, ce n’est pas important car une fois notre VM créée celui-ci sera supprimée pour être remplacée par notre .vhdx fraîchement copié ;
Concernant le driver réseau, privilégiez Virtio(paravirtualisé) ;
Terminer, sans démarrer d’ores et déjà la VM ;
Je ne l’ai pas dit plus haut pour ne pas vous embrouiller, mais dans l’état, si l’on démarre notre VM, Windows ne détectera pas le disque ni la carte réseau. La raison est que nativement, les drivers VirtIO ne sont pas inclus dans Windows. Nous avons donc deux choix :
Installer les drivers VirtIO sur la VM avant de copier son disque ;
Démarrer tout de même la VM, puis installer les drivers par la suite ;
Je n’ai pas encore testé la première option, nous partirons donc sur la seconde. Mais avant de vouloir démarrer le tout et installer tel ou tel driver, nous devons rattacher notre ancien disque !
Bien, la première étape est de supprimer le disque de notre VM actuelle :
On le détache, puis on le supprime.
Une fois fait, on se connecte en CLI sur notre nœud Proxmox pour rattacher notre disque « Hyper-V » sur notre nouvelle VM :
qm importdisk 100 /root/srv-ad-01.vhdx local-lvm
On utilise donc l’utilitaire qemu pour importer notre disque sur la VM ayant l’ID 100, à adapter selon votre VM donc. Ensuite, on renseigne le chemin vers ce disque, et en dernier lieu on indique le datastore sur lequel il va être stocké. Ici il s’agit du datastore de base, local-lvm. Mais si vous utilisiez Ceph par exemple, cela aurait pu être rbd-datastore-24, ou que sais-je.
On patiente pendant l’import (qui peut parfois durer très longtemps !), et une fois fait, nous pourrons le rattacher à notre VM.
Au passage, voici la commande pour vérifier l’intégrité d’un disque, toujours pratique à effectuer avant de l’importer sur notre datastore :
qemu-img check srv-ad-01.vhdx
Extrêmement simple à réaliser, mais toujours important !
Bien, retournons donc sur les paramètres de notre machine virtuelle :
On clique donc sur Éditer, puis on choisi bien le contrôleur VirtIO SCSI. On peut éventuellement activer l’émulation SSD, le caching, ou autre.
On touche désormais presque à la fin !
IV) Démarrage de la VM et installation des drivers OpenSource VirtIO
Comme dit précédemment, il vous faudra des drivers à installer, tout dû moins pour le disque, et éventuellement pour la carte réseau si vous avez aussi choisi VirtIO. Rien de compliqué je vous rassure !
On télécharge l’ISO contenant les différents drivers VirtIO ici : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
*Pour ma part, j’ai choisi la version 215-2, car la dernière en date ne fonctionnait pas.
Une fois l’ISO téléchargé, on l’upload sur notre Proxmox, et on le rattache à notre machine virtuelle. On peut enfin modifier l’ordre de boot, et nous pourrons démarrer !
Ici j’ai désactivé le boot via PXE mais pas via CD, car nous voulons que notre VM boot sur notre disque, mais si on ne sélectionne pas notre lecteur CD, l’ISO ne montera pas au boot…
Au démarrage, votre Windows plantera. Puis encore une fois, et même éventuellement une troisième fois.
C’est normal ! Rappelez-vous, il n’a pas encore les drivers adéquats… cela nous permettra d’afficher le mode Rescue de Windows, et d’accéder à une invite de commandes :
Au passage, il se peut que votre curseur n’en fasse qu’à sa tête… cela peut venir du fameux pilote SPICE choisi pour la carte graphique, si vous n’avez pas choisi le standard.
Bien, on va donc maintenant installer le driver concernant notre disque SCSI VirtIO :
drvload D:\vioscsi\2k12R2\amd64\vioscsi.inf
A noter que la commande sera identique peut importe la version de Windows utilisée :
Et le tour est joué ! Ni plus, ni moins. On peut clôturer ce terminal et poursuivre le boot de manière normale :
Et voilà, votre VM Windows Server 2012 R2 migrée depuis votre Hyper-V s’allume sous vos yeux !
Cependant, comme pour le disque, il n’y a pas encore le driver correspondant à la carte réseau. Mais étant donné que notre ISO VirtIO est toujours rattaché à notre machine, rien de plus simple :
Il nous suffit d’exécuter le binaire virtio-win-gt-x64, et de choisir les drivers souhaités ! Selon plusieurs forums, il vaut mieux éviter d’installer le driver concernant le Ballooning, et de mémoire lorsque j’avais installé Proxmox sur un serveur dédié avec pfSense et autre (il y a de ça presque trois ans), j’avais aussi des soucis avec, donc autant prendre des précautions et ne pas l’installer, beaucoup se plaignant de dégradations de performances.
Comme on peut le voir, la carte réseau est désormais bien reconnue est fonctionnelle :
Et concernant notre AD lui-même, nos OU et users sont toujours bien là :
V) Conclusion
Et bien voilà, vous avez réussi à migrer un DC depuis Hyper-V vers Proxmox. Félicitations ! Comme vous le voyez, il n’y a rien de très sorcier, et plus encore si les drivers VirtIO sont installés avant la copie du disque de la VM (je n’avais pas testé avant de conclure cet article, mais je confirme que cela fonctionne).
Bref, au moins vous aurez les deux façons de faire !
Bien-entendu, c’était une première pour moi, et cela a été fait dans le cadre d’un lab. Impossible de dire si les performances seront équivalentes à Hyper-V, si certaines options peuvent être poussées plus loin en terme d’optimisation… libre à vous de donner votre grain de sel en commentaire ! J’y répondrais avec plaisir comme d’habitude.
Sur ce, je vous souhaite une bonne journée/soirée, et n’arrêtez pas d’expérimenter~
Aujourd’hui un petit article qui parlera de l’installation de PacketFence, un NAC OpenSource et gratuit permettant d’augmenter grandement la sécurité de son réseau ! Comme d’habitude, nous verrons ensemble ce qu’est un NAC, son utilité, et nous décrirons rapidement l’outil, puis nous passerons à son installation.
Sans plus attendre, allons-y !
I) NAC, NUC… kézako ?
Un NAC, pour Network Access Control, est un élément réseau regroupant diverses fonctionnalités permettant de protéger l’accès à son réseau, que ce soit filaire ou wi-fi. A la différence d’un serveur Radius unique par exemple, il permet d’aller plus loin en permettant du profiling notamment (voir plus), de sorte que :
Si l’OS de la machine est de type X, la placer dans le VLAN X ;
Si la base virale de la machine est dépassée, la placer dans le VLAN Y ;
L’on peut vérifier en temps réel les différentes machines autorisées ou non sur chaque portion de réseau ;
L’on peut créer un portail captif avec authentification par SMS, OpenLDAP, ActiveDirectory, et plus encore ;
Si la machine n’a pas le couple MAC Adress/Certificat TLS requis, celle-ci est bloquée ou placer dans un VLAN X (assignation dynamique de VLANs, comme pour RADIUS) ;
L’on peut l’utiliser en tant qu’IDS, voir le coupler avec un IPS en lui faisant remonter divers logs ;
. . .
A ne pas confondre avec un NUC donc, qui n’est rien d’autre qu’un PC small-factor de chez Intel.
II) PacketFence, le NAC OpenSource
PacketFence est un des NAC OpenSource les plus utilisés. Il est très souvent mis à jour, fiable, et stable (sorti aux alentours de 2009) et regorge de fonctionnalités et ait doté d’un grand support de fabricants (Ubiquiti, Cisco, HP, et plus encore). Il permet d’être utilisé comme serveur RADIUS, comme IDS, comme Portail Captif, et beaucoup d’autres services encore…
III) Installation
Concernant l’installation, trois choix majeurs s’offrent à vous :
Vous pouvez utiliser le template OVF fourni directement ;
Vous pouvez installer PacketFence directement sur une Debian/RedHat ;
Vous pouvez utiliser l’ISO Debian qui va se charger de tout vous installer ;
J’ai personnellement opté pour la troisième solution, donc allons-y !
Après avoir booté sur l’ISO, on peut démarrer l’installateur qui se charge illico d’installer les différentes dépendances, et en quelques secondes on nous demande de renseigner le nom d’hôte de notre VM :
On renseigne ce que l’on souhaite, et ensuite on renseigne notre domaine.
On renseigne ensuite le mot de passe root, et ici attention car comme vous l’aurez sûrement remarqué en tapant le hostname, le clavier par défaut est en qwerty !
Et c’est tout ! L’installation se termine tranquillement d’elle-même :
Une fois l’installation terminée, vos différentes interfaces sont en théorie en DHCP, ici j’en ai deux, une qui servira de management, et l’autre pour tout ce qui est services. Le root login est disponible par défaut en SSH (à modifier avant mise en production !), mais cela nous permet de rapidement setup une IP statique. Nous aurons donc ceci :
Management : 192.168.0.100/24 ;
Services : 192.168.10.50/24 ;
En nous rendant donc sur notre interface de management, sur le port 1443 nous obtenons notre interface web :
Comme on peut le voir ici, l’interface de management sera eth0, on peut éventuellement cliquer sur le wizard Détecter l’interface Management, et éventuellement d’ores et déjà configurer notre seconde interface mais je préfère réaliser cela une fois la configuration initiale terminée, histoire d’éviter d’éventuels soucis.
On clique donc sur Étape suivante !
Ici on re-renseigne le domaine ainsi que le nom d’hôte de la machine, puis le fuseau horaire, on peut éventuellement utiliser le service tracking-config qui –à première vue– permet de garder une trace des changements effectués sur la configuration, puis on peut configurer tout ce qui est SMTP pour l’envoi de mail, et enfin renseigner un mot de passe administrateur. Concernant la partie base de données, les mots de passe sont générés aléatoirement.
Une fois validé, et après avoir bien sauvegardé les passwords par défaut, on peut éventuellement renseigner un proxy ainsi qu’une clé d’API :
Et heureuse surprise pour ceux qui n’ont pas sauvegardé le password par défaut (on vous voit), on a droit à un petit résumé avec les mots de passes utilisés :
On clique ensuite sur Démarrer PacketFence, et le tour est joué !
Et tadaaaa, après s’être connecté sur notre jolie interface web, on peut commencer à s’amuser !
Et c’est ici que ça devient intéressant ! Place au RADIUS, aux VLANs, aux scans IDS et plus encore !
Sauf que nous en resterons là pour le moment… j’ai de nouveau une période assez (sur)chargée ces derniers temps, preuve en est avec mon dernier article datant d’un mois, mais sachez que plusieurs articles sur PacketFence arrivent, c’est promis ! :p
Sur ce, j’espère au minimum avoir su attisé votre curiosité pour ce soft qui s’annonce vraiment pratique, et au mieux vous avoir aidé pour son installation, même si celle-ci n’est clairement pas des plus complexes.
Connexion
