Labs on Zwindler's Reflection

Déploiement de Proxmox VE 5 sur un serveur dédié – part 3

Tue, 25 Jul 2017 11:55:18 +0000

Note : Cette suite d’articles de 2016 écrite par M4vr0x a été remis à jour par Charles et moi. Je vous conseille d’aller lire celui ci plutôt, qui sera plus en phase avec les versions actuelles. Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Cet article fait partie d’une suite de 3 articles sur la mise en place de Proxmox VE et sa sécurisation et dont voici les adresses :

Nous avons donc à présent une belle infrastructure à disposition avec une VM PFSense en frontal et un niveau de sécurité relativement correct. Nous allons donc terminer par :

La configuration d’un accès distant sécurisé grâce à OpenVPN
L’adaptation des règles de filtrage pour que cela fonctionne

Mais avant cela, je vais juste faire un léger aparté pour vous montrer comment autoriser l’accès extérieur à un service d’une machine virtuelle.

Comme pour les parties précédentes, si des paramètres ne sont pas explicités, ils sont à laisser à leur valeur par défaut.

Publication de services sur l’internet du web

Imaginons que vous ayez quelques VMs qui vous fournissent des services de « Prod », et que pour des raisons qui vous sont propres, vous souhaitiez pouvoir y accéder sans passer par votre futur VPN … « Comment faire ? » me demanderiez-vous. « Et bien, vous répondrais-je … C’est très simple mon cher ami, grâce à notre magnifique infrastructure, l’ajout d’UNE SEULE règle suffira ! » (mouahaha)

Donc prenons le cas d’un serveur PLEX , au hasard, hébergé sur un NAS Synology virtualisé … son @IP est 192.168.9.10 et son port d’écoute est, par défaut, le TCP:32400.

Se rendre dans le menu Firewall > NAT puis cliquer sur « ADD »

Interface : WAN Protocol : TCP
Destination : Any
Destination Port Range (From) : Other - 32400
Redirect target IP : 192.168.9.10
Redirect target port : Other - 32400
Description : Choisir un nom pour la règle (ex: Synology - Plex)

Valider avec « Save » puis « Apply Changes » pour recharger la configuration

Voilà, c’est tout !

Vous avez crée une règle de NAT qui renvoie toutes les requêtes arrivant sur le port TCP:32400 de votre interface WAN vers le port TCP:32400 de votre Plex ! Cerise sur le gâteau, vu que PFSense est bien conçu (et que vous n’avez pas modifié le paramètre « Filter rule association ») il vous a généré une règle de FW associée pour autoriser le flux de votre règle NAT.

Comme tous les services publiés sur votre IP public constituent des vecteurs potentiels d’attaque on va y allez « molo sur la mayo » (… vous connaissez cette expression ? Je crois que je viens de l’inventer … truc de fou … une fulgurance … Non sérieux quelqu’un connaît ? … Euh oui pardon … ). Je disais donc que nous privilégierons évidemment un accès via le VPN que nous allons mettre en place …. genre maintenant, tout de suite.

Configuration d’accès distant sécurisé via OpenVPN

Je ne vais pas vous détailler l’action de chaque option, et je ne les connais pas toutes d’ailleurs, par contre si vous êtes intéressé, je vous encourage fortement à vous référer à ces sources :

Documentation officielle d’OpenVPN
Article « OpenVPN Remote Access Server » du Wiki de PFSense
Un très bon tuto francophone qui détaille bien les options … lui ;-)

Création de l’autorité de certification

Naviguer jusqu’à la liste des « CAs » via le menu System > Cert Manager :

Celle-ci est vide, nous allons donc créer une nouvelle entrée.

Cliquer sur le bouton « ADD » en bas à droite, puis renseigner comme suit :

Descriptive name : Nom choisi pour la CA
Method : Create an internal Certificate Authority

Une fois la méthode sélectionnée, l’encadré inférieur va changé

Key length : 2048 (longueur de la clé de chiffrement)
Digest Algorithm : SHA256 (méthode de hachage)
Lifetime : 3650 (durée de validité en jours)
Country Code : FR (Code ISO du pays d’émission du CA)

Les autres champs sont libres et à titre indicatif, évitez toutefois les infos trop personnelles/confidentielles. Choisissez simplement un « Common Name » un peu explicite pour pouvoir l’identifier facilement.

Cliquer sur « Save » et contempler le résultat :

Création du certificat serveur

Cliquer à présent sur l’onglet rouge « Certificates » où un certificat utilisé par la WebUI existe déjà, puis cliquer sur le bouton « ADD » pour en créer un nouveau :

Method : Create an internal Certificate Authority

Et là grosse surprise ! … Une fois la méthode sélectionnée, l’encadré inférieur va changé

Descriptive name : Nom choisi pour la certificat serveur
Certificate authority: Sélectionner la CA crée juste avant (la seule normalement)
Key length : 2048
Digest Algorithm : SHA256
Certificate Type : Server Certificat (Qui a dit pourquoi ? … Toi => [] … tu sors)
Lifetime : 3650 (10 ans ça devrait suffire)

Les champs suivants sont normalement pré-remplis donc conservez les même valeurs que précédemment sauf pour « Common Name » bien sûr (Pourquoi ? … t’étais pas sorti toi ??!)

Valider avec le bouton « Save »

Création du certificat client

Alors là c’est tricky … attention … il va falloir relire le paragraphe précédent (oui y compris les vannes bidons) et refaire la même manip en changeant simplement :

Certificate Type : Client Certificat … \o/

Création du serveur VPN

Se rendre dans le menu VPN > OpenVPN, puis cliquer sur « ADD »

General Information

Server Mode : Remote Access (SSL/TLS + User Auth)

Avec ce mode vous aurez besoin des certificats sur le client mais devrez également saisir le login/password du user crée ci-dessus à chaque connexion du tunnel VPN. C’est une sécurité supplémentaire que vous pouvez désactiver en choisissant « Remote Access (SSL/TLS) »

Local Port : 2294

Rien d’obligatoire ici mais pour les même raison expliquées dans la 2e partie de l’article ça limite drastiquement l’efficacité de nombreux bots qui utilisent les ports standards.

Cryptographic Settings

TLS Authentication : Laisser coché

La TLS est une couche supplémentaire d’authentification/chiffrement qui permet d’ajouter une seconde ligne de défense à SLL et à priori l’impact n’est pas significatif au niveau des performances. Libre à vous de lire la doc et de l’enlever en toute connaissance de cause si vous le souhaitez.

Description : Choisir un nom pour le serveur OpenVPN
Certificate authority : Sélectionner la CA créée juste avant (toujours la seule normalement)
Server Certificate : Choisir le certificat serveur créé précédemment

Tunnel Settings

IPv4 Tunnel Network : 10.2.2.0/24

Conformément à notre schéma réseau, visible dans la [2e partie de l’article][2]. Là aussi, libre à vous de choisir votre segment réseau, du moment que vous adaptez la suite à votre plan d’adressage.

Redirect Gateway : Cocher la case

Ce paramètre permet de forcer le client à utiliser le VPN en tant que passerelle par défaut dès qu’il est activé. Ce qui peut faire office de proxy sécurisé pour l’ensemble de votre trafic quand vous vous connectez depuis un Wifi Public par exemple. Si vous utilisez un client qui le permet (ex: TunnelBlick), vous pouvez laisser cette options décochée et l’activer au besoin coté client, en revanche l’ajout d’une option « push « route 192.168.9.0 255.255.255.0 » sera obligatoire.

Concurrent connections : 3

Facultatif, permet de limiter le nombre de client connectés en même temps.

Inter-client communication : Cocher la case

Si vous souhaitez que vos client puissent communiquer entre eux.

Disable IPv6 : Cocher la case

Client Settings

Dynamic IP : Cocher la case

Valider avec le bouton « Save »

Création de l’(unique) utilisateur

Se rendre dans le menu System > User Manager, puis cliquer sur « ADD »

Disabled : A cocher pour empêcher le user d’avoir le droit de se loguer sur la WebUI

En effet, le but est d’avoir un utilisateur dédié sans accès à l’interface. Ensuite choisissez un login, un password, un nom long (facultatif), une date d’expiration (si vous cherchez des ennuis, vu que vous vous demanderez dans quelques mois pourquoi ça ne fonctionne plus). Une fois le user crée, nous allons lui attribuer le certificat client que nous avons généré précédemment :

Cliquer sur le bouton « Edit user » (mais si, le petit crayon bleu à droite … l’autre droite)
Dans le cadre « User Certificates , cliquer sur « Add »

Method : Choose an existing certificate

Existing Certificates : Sélectionner votre certificat client qui doit être le seul non encore utilisé

Il ne vous reste plus qu’à sauvegarder la modification. L’idée est de créer un couple user/certificat client par personne (logique) voir par machine cliente, ça permet notamment pouvoir les révoquer individuellement au besoin. Enfin si vous avez besoin de plusieurs utilisateurs, créez leur un groupe dédié pour les ranger (c’est plus propre, on est pas des sauvages).

Configuration du/des client(s)

Afin de pouvoir accéder à notre tunnel, il faut maintenant récupérer :

La clé privé du certificat client crée précédemment
La clé publique de ce même certificat
Un modèle de configuration client d’OpenVPN et l’adapter

Je suis donc censé vous décliner la marche à suivre pour préparer des « kits » de configuration, en fonction des options sélectionnées pour notre serveur, des spécificités de mise en forme de certificats pour les différents types de clients (Linux, MacOS, iOS, Android … voir Windows) et également pour chaque … ah ouai … mais non en fait.

Nous allons plutôt utiliser un des (nombreux) avantages de PFSense, à savoir son gestionnaire de paquets !

En effet, il existe plus d’une cinquantaine de packages (en release 2.3.4) qui permettent d’ajouter des fonctionnalités à notre Firewall. Pour ne rien gâcher, ils sont installables en un clic depuis l’interface Web et leurs paramètres sont sauvegardés automatique par le mécanisme de backup intégré de PFSense qui est un simple fichier XML.

Enfin, comble du bonheur, il en existe un qui fait exactement tout ce qui nous intéresse : openvpn-client-export !

Se rendre dans le menu System > Package Manager, puis cliquer sur l’onglet « Available Packages »
Taper « export » dans le champ de recherche, puis installer le paquet via le bouton « Install »

Vous pouvez aussi profiter d’une recherche manuelle pour parcourir les différents paquets disponibles.

Lien vers la documentation du package OpenVPN Client Export

Naviguer vers le menu VPN > OpenVPN, puis cliquer sur le nouvel onglet « Client Export »

Remote Access Server : Sélectionner le serveur VPN souhaité (le seul à priori)
Host Name Resolution : Other

Le choix par défaut « Interface IP Address » va renseigner l’@IP locale de votre interface WAN (10.0.0.2) dans le fichier de configuration du client et quand vous essaierez de vous y connecter depuis internet ça marchera beaucoup moins bien. Le mieux est de sélectionner « Other » et de saisir directement votre IP publique ou votre nom de domaine (en cas d’utilisation de DynHost par exemple).

Use Random Local Port : Cocher la case (obligatoire si vous prévoyez plusieurs client en simultanés)

Scroller à présent vers le bas jusqu’au cadre OpenVPN Clients :

Il ne reste plus qu’à télécharger les configs qui vous intéresse !

Pour les utilisateurs de MacOS, je vous conseille le client VPN Tunnelblick. Une fois installé, télécharger la « Standard Configuration » au format « Archive » . Dézipper l’archive, ajouter le suffixe « .tblk » pour transformer le dossier en configuration pour Tunnelblick et enfin l’ouvrir pour la charger automatiquement dans l’application.

Une fois la/les configuration(s) installé(s) sur votre/vos client(s), il ne reste plus qu’à paramétrer les règles PFSense requises.

Configuration des flux

Autoriser l’accès du client au serveur VPN depuis internet

Naviguer vers le menu Firewall > Rules
Sélectionner l’onglet WAN puis ajouter une nouvelle règle avec « ADD »

Action : Pass
Interface : WAN
Protocol : UDP
Source : Any
Destination : WAN address
Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner le nom qui s’affichera pour la règle (ex: OpenVPN nomad access)

Autoriser l’accès du client en provenance du tunnel VPN aux LAN & WAN

Sélectionner l’onglet OpenVPN puis ajouter à nouveau une règle avec « ADD »

Action : Pass
Interface : OpenVPN
Protocol : Any
Source : Network - 10.2.2.0/24
Destination : any

Ici on peut limiter l’accès des clients au seul LAN mais il faudra désactiver l’option « Redirect Gateway » du serveur et le VPN ne pourra plus être utilisé en tant que proxy Web.

Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner un nom pour la règle

Valider les changements via le bouton « Apply Changes »

Vous n’avez plus qu’à démarrer votre client VPN, renseigner votre login/pass et c’est parti !

THE END !

Voilà n’hésitez pas à commenter, poser des questions, faire une donation via PayPal si vous voulez supporter le blog avec les quelques euros qui traînent sur votre compte et surtout abonnez-vous à NoLife … ah non c’est pas ça je m’égare … allez see u guys.

Déploiement de Proxmox VE 5 sur un serveur dédié – part 2

Tue, 18 Jul 2017 12:00:32 +0000

Note : Cette suite d’articles de 2016 écrite par M4vr0x a été remis à jour par Charles et moi. Je vous conseille d’aller lire celui ci plutôt, qui sera plus en phase avec les versions actuelles. Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Cet article fait partie d’une suite de 3 articles sur la mise en place de Proxmox VE et sa sécurisation et dont voici les adresses :

Après avoir déployé Proxmox, nous allons poursuivre la mise en œuvre de notre infrastructure de Labs sur notre serveur dédié, en procédant aux étapes suivantes :

Sécuriser l’OS
Paramétrer les interfaces via la WebUI de Proxmox
Installer la VM PFSense
Utiliser l’iptables de l’hyperviseur pour router et sécuriser les flux

Basic hardening

Je vous conseille TRÈS VIVEMENT (non en fait c’est obligatoire) d’appliquer les bonnes pratiques élémentaires en matière de sécurisation listées dans ce très bon article rédigé par OVH et qui détaille tous les points ci-dessous.

Si vous voulez creuser un peu plus, regardez également du coté des outils d’audit du genre de Lynis (ex rkhunter), c’est simple à utiliser et ça vous donnera plein de pistes sur des vulnérabilités potentielles : Doc d’installation officielle

Voilà, pour ma part, ce que j’ai mis en place :

Changement du mot de passe root

Si vous avez utilisé un mot de passe simple pour éviter les risques d’erreurs lors de la configuration (comme évoqué dans la part 1), on se connecte via SSH et on paramètre un VRAI password.

Mise à jour du système

Toujours une bonne habitude à prendre avant de commencer, même si à l’heure où j’écris ces lignes la version 5 de Proxmox est sortie depuis seulement quelques jours. Rien de compliqué, on est sur une Debian :

apt-get update; apt-get upgrade

Création d’utilisateur

La création d’un utilisateur « lambda », autre que root, est fortement recommandée. Par défaut l’authentification du portail de Proxmox se base sur PAM donc vous pourrez vous loguer avec, après l’avoir ajouté dans la WebUI.

Configuration du serveur SSH

Désactivez l’accès root et privilégiez le recours au user évoqué ci-dessus puis utilisez une élévation de privilège de type su ou sudo.

Installation de Fail2ban

Là aussi indispensable, il s’installe en une commande, il est déjà configuré avec un grand nombre de règles par défaut qui parsent vos différents log et bannissent toutes les @IP concernées. D’ailleurs, si vous n’êtes pas convaincu de son utilité, je vous mets un (petit) extrait de mon auth.log juste avant son installation :

Voilà, voilà … contrairement à notre ami de Nanjing qui a effectué 161 tentatives en 32h avec des logins plus ou moins improbables … nous on se marre moins tout de suite !!

Au passage, voilà un article sur la configuration de Fail2ban de l’hébergeur Digital Ocean (Ils en font d’ailleurs beaucoup d’intéressants je vous encourage à écumer leurs tutos)

Changement du port d’écoute du serveur SSH

Alors là attention, aucun doute sur la pertinence de la mesure, cela vous permettra d’éviter la grande majorité des tentatives d’accès non autorisées car la plupart des bots se contentent de scanner les ports par défauts des principaux services. Par contre si vous faites ça, vous allez devoir adapter le port SSH dans le script iptables que je vous fournis pas la suite et les tentatives d’intrusion sur le port 22 seront redirigés directement sur le PFSense, ce qui n’est pas forcément mieux. Bref à vous de voir, pour ma part je reste sur le port par défaut mais avec un Fail2ban bien configuré.

Configuration du réseau

Voici le plan réseau de l’infrastructure que nous allons mettre en place (cliquez pour agrandir) :

Le but est de rediriger la totalité du trafic entrant sur l’adresse IP public du serveur vers l’interface WAN du PFSense. Cela permet de gérer la sécurisation et le routage des flux simplement, directement depuis PFSense et surtout en évitant d’avoir à doubler chaque règles de filtrage sur l’iptables.

Paramétrage des interfaces virtuels

Cela peut se faire directement via la WebUI de Proxmox, Les réglages seront simplement automatiquement retranscrits dans le fichier « /etc/network/interfaces« .

Se connecter à l’interface d’administration

Via un navigateur, on se rend en HTTPS sur l’IP public via le port 8006 (https://@IP_PUBLIC_IP:8006). Si vous souhaitez signer vos certificats pour éviter le genre de message que vous allez rencontrer, n’hésitez pas à lire ce superbe article de Zwindler

Sélectionner votre node dans la colonne de gauche, puis naviguer dans System > Network

Vous devriez avoir deux interfaces, en01 et en02 (ou eth0 et eth1 chez Kimsufi), qui correspondent aux deux ports physiques de la carte réseau ainsi qu’une interface virtuel, vmbr0 bridgé sur eno1 qui est l’interface active.

On peut d’ailleurs voir à quoi cela correspond en affichant notre fichier de configuration :

cat /etc/network/interfaces

Qui devrait contenir ceci :

auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx
netmask 255.255.255.0
gateway xx.xx.xx.xx
bridge_ports eno1
bridge_stp off
bridge_fd 0

On voit que l’interface eno1 est configuré en « manual », sans adresse IP puisque elle est « portée » par vmbr0, et qu’eno2 n’est pas utilisée.

Création des bridges Linux

On reprend en configurant conformément au schéma ci-dessus :

Cliquer sur « Create » et sélectionner « Linux Bridge«

Le réseau « VmWanNET » (10.0.0.0/30) sera donc volontairement choisit pour limiter à deux le nombre d’adresses atribuables, celle-ci et le WAN du PFSense. Ici pas de bridge sur une interface réelle pour la vmbr1 puisque « WAN » n’existe pas au niveau de l’hyperviseur, mais cela facilitera la correspondance lors du paramétrage de PFSense.

Cliquer (à nouveau) sur « Create » et sélectionner (encore) « Linux Bridge«

Cette fois on configure l’interface vmbr2 qui fera parti du réseau « PrivNET » (192.168.9.0/24), et qui sera utilisée plus tard par l’interface « LAN » du PFSense :

IP address : 192.168.9.1
Subnet mask : 255.255.255.0
Bridges Ports : LAN

Une fois terminé, cela donne :

Rebooter l’hyperviseur

Il suffit de cliquer sur « Restart » en haut à droite. C’est impératif pour prendre en compte proprement les modifications, c’est pas moi qui le dis, c’est marqué au dessus de l’encadré affichant le log : « Pending changes (Please reboot to activate changes) » … allez promis c’est la seule fois où ce sera nécessaire.

Après le redémarrage, vous pouvez vérifier le contenu du fichier « interfaces » :

auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx
netmask 255.255.255.0
gateway xx.xx.xx.xx
bridge_ports eno1
bridge_stp off
bridge_fd 0
auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
netmask 255.255.255.252
bridge_ports WAN
bridge_stp off
bridge_fd 0
auto vmbr2
iface vmbr2 inet static
address 192.168.9.1
netmask 255.255.255.0
bridge_ports LAN
bridge_stp off
bridge_fd 0

Je vous conseille de le conserver quelques part puisque en cas de réinstallation, un simple copier/coller suivi d’un reboot vous permettra de tout reconfigurer rapidement. Nous poursuivrons le paramétrage et la sécurisation par la suite.

Déploiement de PFSense

Création de la VM

Télécharger l’ISO de PFSense

Rendez-vous sur le site officiel pour récupérer la dernière version stable de la Community Edition, de type « install« , au format ISO et pour archi AMD64 (64bits). On sélectionne ensuite le volume de stockage souhaité, ici « local« , puis on clique sur Content > Upload

Mais on peut également, surtout si votre débit d’upload est poussif, la télécharger directement depuis le serveur dans le répertoire des ISOs :

cd /var/lib/vz/template/iso
wget [lien mort, aller sur https://pfsense.org/]
gunzip pfSense-CE-2.3.4-RELEASE-amd64.iso.gz

Créer la VM pour PFSense

Voilà les paramètres que j’utilise, ceux qui n’y figure pas sont laissés par défaut :

Linux/Other OS types : Other OS types

CD/DVD

Use CD/DVD disc image file (iso)

Storage : local
ISO image : pfSense-CE-2.3.4-RELEASE-amd64.iso

Hard Disk

Bus/Device : VirtIO / 0
Storage : local
Size : 8 GB
Format : QEMU (qcow2)

CPU

Sockets : 1
Cores : 2
Type : Défaut (kvm64)

Memory

Mémoire fixe avec ballooning activé

Taille : 2048 MB

Network

Bridged mode (Accès par pont)

Bridge : vmbr1
Model Intel E1000

/!\ Pour la carte réseau SURTOUT pas de VirtIO sans installer le driver requis /!\
Pour plus détails ici

Créer la seconde interface réseau

Assurez-vous d’être dans la « Server View » dans le menu en haut à gauche, puis sélectionnez votre VM PFSense nouvellement crée. Enfin, cliquez sur Hardaware > Add > Network Device

La configuration est la même que pour la première mais pontée sur vmbr2.

Installation de l’OS

Démarrer la VM via le bouton « Start »
Ouvrir une console VNC avec le bouton « Console »

Laisser le boot se terminer, si ce n’est pas encore fait, jusqu’à voir s’afficher le premier écran de l’installeur :

Libre à vous de choisir les réglages qui vous conviennent, valider avec le dernier choix du menu.

Choisir « Quick/easy Install »

Valider à nouveau et l’installation se lance
Sélectionner le choix par défaut « Standard Kernel«
Autoriser le reboot

Vérifiez le boot order de la VM pour bien démarrer sur le disque local, vous pouvez également éjecter l’ISO.

Configuration des interfaces

Une fois la VM redémarrée, vous arrivez sur le menu principal de la console de PFSense :

Taper « 1 » (pas trop fort) pour assigner les interfaces, puis configurer comme suit :

 - Paramétrage des VLANs : No (n)
 - WAN interface name : em0
 - LAN interface name : em1
 - Optional 1 interface name : Aucun (appuyer sur entrée)
 - Valider (avec y) si :
WAN -> em0
LAN -> em1

De retour dans menu général taper « 2 » pour configurer les @IP des interfaces

Taper "1" pour le WAN (em0 - static)
- DHCP : No (n)
- @IP : 10.0.0.2
- Masque : 30
- Gateway : 10.0.0.1
- DHCP6 : No (n)
- WAN IPv6 address : Aucune (appuyer sur entrée)
- HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 WAN address => 10.0.0.2/30

A nouveau « 2 » pour configurer les @IP des interfaces

Taper "2" pour le LAN (em1 - static)
- @IP : 192.168.9.254
- Masque : 24
- Gateway : Aucune (appuyer sur entrée)
- @IPv6 : Aucune (appuyer sur entrée)
- DHCP server : No (n)
- HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 LAN address => 192.168.9.254/24

Rebooter la VM en tapant « 5 » puis « y »
A l’issue, taper « 7 » pour tester le ping vers 10.0.0.1 (l’adresse de vmbr1) et ainsi vérifier la connectivité au sein du VmWanNET

Finalisation via la WebUI

Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 …

… Quoi ? … Ça ne marche pas ? … Sûr ? … C’est con …

Bon pour ceux qui suivent encore, félicitations ! Pour les autres, l’interface LAN de PFSense n’est pour l’instant pas accessible depuis l’extérieur … et c’est tant mieux car le password et le login sont toujours ceux par défaut. La solution la plus simple est donc de créer une VM avec n’importe quel OS, du moment qu’il possède une interface graphique et un navigateur web (et que ce n’est pas un Windows). Une Ubuntu Desktop, à télécharger sur le site officiel, fera parfaitement l’affaire.

Je ne vais pas revenir sur la création de la VM, sachez juste que 5 Go de disque et 512 Mo de RAM suffisent. N’oubliez pas de bridger la carte réseau sur vmbr2 pour accéder au réseau LAN. Vous pouvez également, une fois la VM crée, modifier le paramètre Hardware > Display en « VMWare compatible » c’est qui vous permettra de disposer d’autres résolutions plus confortable que le minuscule 800×600.

Une fois l’OS installé, il faut tout de même paramétrer le réseau manuellement puisque nous n’avons pas (encore) de serveur DHCP fonctionnel :

- IP : 192.168.9.10 (Peu importe tant qu'on reste dans 192.168.9.0/24)
- Netmask : 255.255.255.0
- Gateway : 192.168.9.254
- DNS : 8.8.8.8

Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 (non mais vraiment cette fois)

Username : admin
Password : pfsense

Suivez le (White) Wizard

Rapport à ma VM PFsense qui se nomme Olorin … pertinent pour un pare-feu …

« You Shall Not Pass ! » … ok si vous l’avez toujours pas j’abandonne.

Choisir un hostname (non pas celui-là, c’est le mien) et le(s) serveur(s) DNS souhaité(s)
Valider ou modifier le FQDN du serveur NTP

Pour la suite rien à modifier en principe puisque nous avons fait les réglages via la console précédemment.

Vérifier la configuration de l’interface WAN

IP Address : 10.0.0.2
Subnet Mask : 30
Upstream Gateway : 10.0.0.1

Vérifier la configuration de l’interface LAN

LAN IP Address : 192.168.9.254
Subnet Mask : 24

Changer le mot de passe administrateur
Recharger la configuration et l’accueil du dashboard s’affiche

Configuration du réseau (suite)

Routage et NAT

Particulièrement pour cette partie, je vous encourage à garder le plan réseau à portée de vue.

Pour l’instant, le WAN du PFSense communique bien avec le vmbr1 ,normal me direz vous, ils sont sur le même segment réseau et WAN est ponté sur vmbr1 dans Proxmox. Maintenant nous allons faire le nécessaire pour pouvoir sortir sur internet depuis la patte WAN du PFSense et donc également depuis le LAN par la suite.

Pour cela, créer un petit script sur le serveur Proxmox

vi /root/kvm-networking-up.sh

Coller les lignes suivantes :

#!/bin/sh
## IP forwarding activation
echo 1 &amp;amp;amp;gt; /proc/sys/net/ipv4/ip_forward
# Point PFSense WAN as route to VMs
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1
# Point PFSense WAN as route to VPN
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Comme indiqué dans les commentaires :

La première ligne active le routage
La deuxième indique au serveur de sortir par vmbr1 puis de passer par le WAN du PFSense pour communiquer avec les VMs. Cela permet d’isoler vmbr2 du reste de « PrivNET », cette sécurité sera renforcée, lors de la configuration d’iptables par un blocage complet des flux sur vmbr2.
Même chose pour la dernière mais pour communiquer avec le(s) client(s) du VPN que nous configurerons dans la suite de l’article.

Puis pour qu’il soit lancé automatiquement au boot, lors du démarrage de vmbr1 :

Lui permettre de s’exécuter

chmod +x /root/kvm-networking-up.sh

Paramétrer son appel dans le fichier « interfaces »

vi /etc/network/interfaces

Ajouter la ligne en gras à la fin du bloc de configuration du bridge vmbr2 :

[...]
auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
[...]
auto vmbr2
iface vmbr2 inet static
[...]
bridge_fd 0

post-up /root/kvm-networking-up.sh

Comme je vous ai promis qu’on ne rebooterait plus au début de cette article, on va simplement l’exécuter manuellement pour cette fois :

/root/kvm-networking-up.sh

[Edit zwindler]M4vr0x a oublié qu’il a déplacé une règle IPtable pour rediriger le traffic de l’IP externe vers le pfsense… La ligne suivante ne marche pas encore, mais à l’étape d’après[/Edit]

Relancer la console VNC du PFSense et taper « 7 » pour vérifier le ping vers l’internet (genre 8.8.8.8)

Sécurisation de l’hyperviseur via iptables

Voilà on a presque terminé mais pendant qu’on s’amusait, et malgré les mesures prises au début de ce tuto, une armée de bots (et pas que des chinois), des hordes de BlackHat ainsi que l’intégralité de la NSA, du GCHQ et de … l’ANSSI ? … se tirent la bourre pour essayer de pénétrer sur votre petit serveur sans défense.

Je n’aurais donc que trois choses à dire :

Si vous ne savez pas ce qu’est le GCHQ, il faut absolument lire ce magnifique article !
Si vous ne savez pas ce qu’est la NSA … là je ne peux plus rien pour vous
Nous n’allons pas mourir sans combattre et nous allons au moins … essayer de les ralentir !

Création des règles

Nous allons créer un script pour exécuter toutes les commandes iptables requises. Je vous encourage à ne pas automatiser son lancement au boot avant d’être totalement sûr que tout fonctionne bien.

Pour ceux qui ont pris iptables en deuxième langue au collège, je vous donne directement le contenu du script (à copier sur le serveur Proxmox) :

Pour les autres, je vous conseille de bien lire (et comprendre tant qu’à faire) ce qui suit jusqu’à la fin avant de vous lancer. J’ai commenté quasiment chaque ligne mon script le plus explicitement possible, donc je vais simplement vous expliquer le rôle de chacune des parties :

_VARIABLES _: On commence par la variabilisation des noms de bridges, des @IP et des réseaux. Cela vous permettra de l’adapter rapidement à votre configuration si elle diffère. Quoi qu’il en soit, il faut absolument définir la variable « PublicIP » avec celle de votre serveur.

CLEAN ALL & DROP IPV6 : Ensuite on supprime toutes les règles existantes.

Petit point d’attention, le script, légèrement bourrin, flush toutes les tables et supprime toutes les chaines personnalisées vides à chaque exécution. Si vous voulez éviter ça, pour garder votre/vos chaines Fail2ban existantes par exemple, je vous conseille de plutôt spécifier les tables et chaines à nettoyer.

DEFAULT POLICY : On positionne les polices par défaut à DROP : tout ce qui ne sera pas explicitement autorisé sera interdit (comme à l’armée … \o/ ça faisait longtemps).

CHAINS : On crée des chaines personnalisées pour éviter la répétition des options.

GLOBAL RULES : Elles permettent les communications from/to l’interface locale, préservent les connections déjà actives et autorisent la réponse au ping.

_RULES FOR PrxPubVBR _: On passe à la configuration des flux pour l’interface bridge vmbr0, c’est ici que tout se joue.

L’idée est simple, on ne va autoriser que les services du Proxmox auxquels on souhaite pouvoir accéder depuis internet via l’IP public (donc le moins possible). TOUS les autres flux seront redirigés sur l’interface WAN du PFSense ce qui nous permettra, comme expliqué au début, d’éviter une pénible gestion de deux firewall chaînés. Une fois que le VPN sera configuré on pourra d’ailleurs désactiver l’accès externe à la WebUI. Pour le SSH on pourra garder un accès de secours en cas de problème avec le futur VPN.

_RULES FOR PrxVmWanVBR _: Pour vmbr1, c’est très simple, on autorise seulement les connexions, en provenance du LAN des VMs et du/des client(s) VPN, à sshd et l’interface web de Proxmox.

RULES FOR PrxVmPrivVBR : Pour vmbr2, encore mieux, on laisse tout fermé !

De plus, comme paramétré précédemment, aucune route ne passe par ce bridge. C’est un moyen simple et assez efficace d’isoler au maximum cette interface du réseau auquel elle appartient. Le mieux aurait été d’utiliser une configuration similaire au mode « promiscuous » des Vswitchs d’ESX mais je n’ai pas trouvé d’équivalent pour KVM. Une autre solution utilisant la seconde interface physique du serveur est à l’étude par mon expert en sécurité et fera peut être l’objet d’un article spécifique ou d’une MAJ future. D’ailleurs j’en profite :

Merci Nico, Merci Zwindler !

La clusterisation de nos cerveaux (non ce n’est pas sale) m’a fait gagner beaucoup de temps :-D

Et voilà ! (avec l’accent américain) Vous avez bien bossé et vous disposez d’une infra totalement fonctionnelle et relativement bien sécurisé, GG !

Il nous restera bien sûr à configurer les règles adéquates sur PFSense pour les services de vos futures VMs auxquels vous souhaiterez accéder depuis l’extérieur et configurer un serveur VPN afin d’y accéder directement au chaud depuis votre nouveau LAN.

Nous allons voir tout ça dans la troisième et dernière partie de cette article par ici.

Déploiement de Proxmox VE 5 sur un serveur dédié – part 1

Tue, 11 Jul 2017 11:30:47 +0000

Note : Cette suite d’articles de 2016 écrite par M4vr0x a été remis à jour par Charles et moi. Je vous conseille d’aller lire celui ci plutôt, qui sera plus en phase avec les versions actuelles : Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Cet article fait partie d’une suite de 3 articles sur la mise en place de Proxmox VE et sa sécurisation et dont voici les adresses :

Comme c’est mon tout premier article, je vais commencer par donner le ton en édictant une vérité universelle qui n’engage que moi :

Tout bon SysAdmin qui se respecte se doit de posséder un environnement de Labs

Une fois cet état de fait accepté, se pose la question du choix entre l’achat d’un serveur hébergé « at home » et la location d’un serveur dédié. Pendant plus de cinq ans, j’ai opté pour la première solution pour les raisons suivantes :

Parce que le coup est moindre sur le long terme : un petit serveur d’entrée de gamme ou « home made » d’une valeur de 500€ se verra rentabilisé au bout d’environ deux ans en comparaison d’une location à 20€/mois pour un hardware équivalent.
Parce que j’ai un accès fibre à domicile : tout le monde n’a évidemment pas cette chance mais lorsque c’est le cas, le confort est largement supérieur à beaucoup d’offre de providers (par ex Kimsufi d’OVH) qui sont limitées à du 100 Mb/s ce qui représente environ 12 Mo/s utile. Cela permet de télécharger des ISOs de distributions Linux gratuites très rapidement … elle marche encore cette vanne ? …
Parce que je garde le contrôle total de mes données : Il est évident qu’en confiant ses données à un fournisseur externe, il faut partir du principe que celui-ci à potentiellement accès à vos données. On peut réduire voir éliminer ce risque en ne déposant que des données non personnelles ou en basculant par exemple en mode « zero-knowledge » et en procédant à un chiffrement ACID SHA-256 de tous ses précieux ISOs Linux (les psychopathes concernés se reconnaîtront).
Parce que je suis un barbu : ce qui au passage est un état d’esprit et pas forcément un syndrome d’hypertrichose (ouai, on apprend des mots aussi). Et donc, en tant que tel, j’aime avoir un accès physique à mes machines au besoin.

Donc tout ça c’est bien sympa sauf que vous pourriez me contredire en m’opposant au moins autant de bons arguments en faveur d’une location … C’était bien la peine ! (… et arrêtez de me contredire).

Identifier l’objectif

Le problème

Je vais donc couper court à toute rébellion, arrêter de digresser et vous expliquer que comme je pars à l’autre bout du monde, j’ai dû complètement adapter mon point vue, mes habitudes ainsi que la totalité de mon infra.

Pour résumer, je dois passer d’un mode « Barbu sédentaire » à « Nerd nomade »

Le but est donc de migrer mes services, du mieux possible, pour faire rentrer ça :

Un desktop en dual boot MacOS Sierra/Win10 avec I5, 3xSSD, GTX 970 et double écran 24";
Un petit hyperviseur en dual core sous Proxmox VE
Un NAS « home made » sous XPEnology avec ~8 To de stockage utile en Raid 5
Un firewall physique sous PFSense
Un Rasberry Pi sous Raspbian faisant office de contrôleur de domaine via samba 4
Un accès fibre 500 Mb/s

dans ça :

Un laptop Dell XPS 13 en triple boot (ElCapitan/Win10/Kali)
Un serveur dédié regroupant l’hyperviseur, le NAS, le firewall
Un accès Wifi ou Tethering 4G

… Et oui, ça pique … mais j’ai décidé de prendre ça comme un challenge avec plein de nouvelles choses à tester, à comparer et à mettre en œuvre ! Le but étant de garder un maximum de performance et de confort d’utilisation pour un prix (relativement) raisonnable. Par contre, faut pas rêver, je fais une croix sur GTA 5 et The Witcher 3.

Je vais vous épargner toutes les différentes solutions que j’ai pu envisager et tester ces derniers mois. Je suis passé en vrac par du DigitalOcean, du Kimsufi, du SeedHost, ~~du OneProvider~~ pour les serveurs, du pCloud, du Amazon Cloud Drive, du Google Drive (via GSuite) pour le stockage et par une bonne dizaines d’architectures et de tarifs différents.

Je ne garde pas un œil permanent sur tous les hébergeurs qui existent. Sachez qu’il existe des comparateurs d’offres d’hébergement (par exemple, ce comparatif des serveurs dédiés de tophebergeur qui possède un comparatif actualisé régulièrement).

[Edit]Suite à des soucis avec OneProvider et notamment le support, je déconseille maintenant ce provider[/Edit]

La solution choisie

Il existe donc plusieurs possibilités pour répondre au besoin, mais pour mettre fin au suspens insoutenable, voilà un schéma simplifié de l’architecture que j’ai validé et qui est en « pré-production » depuis 6 mois maintenant (cliquer pour agrandir) :

Je reviendrais plus en détail dans la seconde partie de l’article sur les choix concernant l’adressage, les bridges/interfaces virtuels et les flux.

Choisir l’armement

La solution de virtualisation Proxmox VE

Proxmox VE est une solution d’hyperviseur Bare-Metal totalement gratuite et OpenSource basée sur Debian. L’éditeur propose également un système de souscription payante pour les entreprises souhaitant bénéficier d’un support personnalisé. Elle utilise KVM le moteur de virtualisation natif de Linux et le format de conteneur LXC qui remplace OpenVZ depuis la version 4. C’est robuste, peu consommateur en ressource et ne nécessite pas d’être installer sur une machine de guerre. Il est toutefois évident que plus le serveur sera costaud plus il pourra faire tourner de VMs en simultané. Pour ne rien gâcher la Webui est belle et ergonomique. Proxmox VE possède toutes les fonctionnalités que l’on peut attendre d’une solution de virtualisation d’entreprise. Il est à noter qu’elle propose la création simplifiée de cluster de stockage CEPH directement depuis son interface Web.

La liste exhaustive des fonctionnalités est disponible sur cette page du site officiel de Proxmox.

Le firewall PFSense

Là encore, une solution gratuite OpenSource, robuste (basée sur du FreeBSD 10.3 pour PFSense 2.3), légère, avec une interface belle et ergonomique. Bref vous avez compris l’idée et tous les détails sont disponibles sur le site officiel de PFSense.

Le hardware

Les choix sont multiples, je vais donc me limiter à deux modèles de serveur dédié, un proposé par Kimsufi et l’autre par OneProvider. Les deux proposent l’installation simplifiée de Proxmox VE 5 directement depuis l’interface d’administration.

La solution Kimsufi

Vous savez probablement que Kimsufi est une marque d’OVH dont le catalogue est composé de serveurs Bare-Metal dédiés reposant sur configurations standards non modifiables et un peu datées, ce qui permet de proposer des prix très intéressants.

Comme je n’ai rien trouvé d’exhaustif sur le site officiel ou sur Google, voilà une liste des modèles proposés au 17 mars 2017 :

J’ai donc sélectionné le KS-6 à 29,99 HT offrant :

Deux CPU Intel Xeon E5530 de 2,4 GHz pour un total de 8c/16t
24 Go de RAM
1 HDD de 2 To
Une interface 100 Mb/s et une (seule) @IP public associée
Hébergé en France

La solution OneProvider

C’est celle que j’utilise actuellement avec un serveur dédié « Storage Series ». Néanmoins je souhaitais présenter les deux possibilités car le KS-6 de Kimsufi est une alternative totalement viable, 50% moins chère et qui peux largement suffire pour ceux qui n’ont pas besoin d’autant de volumétrie, de stockage et de bande passante que moi.

~~J’utilise donc un modèle à 69 € HT avec les caractéristiques suivantes :~~

~~Un cpu Intel Xeon E3-1230v2 (4c/8t) de 3,2 GHz~~
~~16 Go de RAM~~
~~4 x 3To HDD en Raid5~~
~~Une interface 1 Gb/s et une @IP public associée avec possibilité d’en ajouter via option payante~~
~~Une accès à l’iLO via IPMI~~
~~Hébergé en France~~

Donc certes le prix est plus élevé mais c’est un excellent rapport stockage/puissance/prix. Je n’ai pas trouvé mieux surtout avec 9 To de stockage utile en Raid 5 et l’accès console qui est vraiment utile comme on le verra par la suite.

Percevoir les munitions

Pour Kimsufi

Voilà quelques détails pratiques utiles à connaitre afin d’obtenir assez simplement le modèle de son choix :

Tout d’abord, les meilleurs configurations (et les plus grosses) partent vite, très vite … j’ai donc eu recours au site Kimi Checker afin d’être prévenu des disponibilités des différentes « pizza box ». C’est gratuit, ça fonctionne bien et pas de compte à créer : on sélectionne les modèles à surveiller, on rentre une @ email et c’est bon.
Pour éviter de perdre de temps lors de la souscription … ah voilà trop tard ! … il peut s’avérer pertinent de créer son compte Kimsufi et de paramétrer son moyen de paiement en avance de phase. Je précise également que les comptes clients OVH ne sont pas utilisables.
Une fois en possession du précieux, prenez 2 min bien méritées pour apprécier l’instant puis connectez-vous à votre interface de gestion pour passer aux choses sérieuses.

Sauter sur la zone

On y est ! Vous vous êtes entrainé toute votre vie pour ce moment … (ou pas), on serre les dents et on passe la porte de l’avion !

Chez Kimsufi, pas un souffle de vent => R.A.S.

Sur la page d’accueil, il suffit de choisir « VPS Proxmox VE 5 (64 bits) » dans la liste des « Gabarits » disponibles. Ensuite il faut sélectionner la langue voulue pour l’installation de l’OS et surtout, ne pas oublier de cocher « installation personnalisée » afin notamment de pouvoir configurer la répartition de la volumétrie. .

Voilà le schéma de partitionnement que j’ai utilisé :

Il ne reste plus qu’à valider et attendre quelques minutes le temps que Proxmox s’installe.

Chez OneProvider, 10 m/s => on percute la planète mais on se relève

On sélectionne son serveur via le bouton « Server List » dans le menu de gauche et on clique sur « Manage« . Il suffit ensuite de cliquer sur « Reinstall » et de sélectionner Proxmox dans la liste des « Virtualisation distributions« .

Attends … ? WTF ? Non c’est pas … … ben si … NON !! Ah les bât@💀🔪💣 !

Donc trêves de plaisanteries sérieuses, OneProvider nous appâte avec Proxmox sur leur site et au final la distribution n’est pas encore disponible en déploiement automatique.

J’ai donc ouvert un ticket pour avoir plus de renseignements. Le retour fut rapide et clair :

« Nous serons en mesure de faire l’installation de Proxmox de notre côté si vous le désirez. Par contre, je vous invite à noter qu’un utilisateur doit être spécifié et que nous ne sommes pas en mesure de modifier le partitionnement par défaut. Si vous préférez faire l’installation vous-même depuis l’IPMI, vous serez en mesure de procéder directement depuis le portail »

Je vais donc en profiter pour vous montrer une installation classique depuis un ISO sur un Bare-Metal comme si vous aviez un accès physique à la machine grâce à l’IPMI.

Télécharger l’ISO de Proxmox VE 5

Toutes les versions sont disponibles sur cette page.

L’iLO en renfort

Pour obtenir un accès à l’IPMI chez OneProvider, il suffit de cliquer sur le bouton « IPMI Session » dans la section « Manage » de son serveur. On met un petit commentaire pour expliquer et on attends le retour du ticket. Une fois la session activée, on se connecte à l’@IP et on s’authentifie avec les credentials qui sont désormais visibles toujours dans la section « Manage ». Après ça, je vous rassure, plus besoin de créer de ticket, il suffira d’utiliser le bouton « Create Session » pour créer une session temporaire.

Se connecter à l’adresse IP de l’iLO fournie par OneProvider

Ici rien de particulier, une fois sur la page de login, on saisit le login et le password là aussi fourni et on arrive sur l’interface d’administration.

Créer une connexion à distance

Dans la section « Remote Console » du menu du même nom, cliquer sur « Web Start » :

Après avoir validé les (au moins) 62 messages de sécurités liés à Java, une dernière fenêtre de navigateur s’ouvre avec normalement un écran noir puisque aucun OS n’est installé.

Monter l’ISO de Proxmox VE

Via le menu « Virtual Drive« , sélectionner « Image File CD/DVD-ROM » :

Une nouvelle fenêtre s’ouvre pour sélectionner l’emplacement de l’ISO sur votre disque dur. Il ne reste ensuite plus redémarrer le serveur en utilisant « Reset » dans le menu « Power Switch« .

Lors du redémarrage (plus ou moins long), vous devriez voir s’afficher les étapes du POST puis l’interface d’installation de Proxmox.

Si ce n’est pas le cas, vérifier que le lecteur de CD est bien avant le disque local dans la liste des périphérique de démarrage du menu « Virtual Media » > « Boot Order ».

L’installation de Proxmox … enfin

Sélectionner le premier choix « Install Proxmox VE » :

Lire (ou pas) et accepter les termes de la license GNU Affero

Pour information et car on aime apprendre (ou réviser) en s’amusant :

GNU Affero General Public License, abrégée AGPL, est une licence libre copyleft, ayant pour but d’obliger les services accessibles par le réseau de publier leur code source. Basée sur la licence GPL, elle répond à un besoin du projet Affero, qui souhaite que tout opérateur d’un service Web utilisant leur logiciel et l’améliorant publie ces modifications.

Configurer les disques

Une fois sur l’écran suivant, on va configurer la répartition de la volumétrie sur les différents « Logical Volumes » crées par l’installeur. Sélectionner le disque cible voulu, si vous en disposez de plusieurs, puis cliquer sur « Options« . Voilà, à titre d’exemple, les valeurs que j’utilise :

Comme je suis sympa voilà une explication (traduction) des différents paramètres issus du site officiel :

Sur le disque sélectionné ci-dessus va être crée un PV rattaché à un VG appelé « pve » puis au sein de ce VG, 3 LVs : « root », « data » et « swap ».

hdsize : Spécifie la taille qui va être allouée au VG « pve ». Elle correspond à la totalité de la volumétrie du disque (ou de la partition) choisie mais on peut la réduire si on souhaite conserver de l’espace.
swapsize : Ici rien de compliqué, c’est la taille du volume utilisé pour le swap. Sachant que par défaut elle est équivalente à la taille de la mémoire physique avec un maximum 8 Go.
maxroot : Désigne la taille maximum du LV « root » qui sera monté sur / dans la limite du quart de la valeur de hdsize (Ok .. un peu capilotracté mais ça se comprend).
maxvz : (Là en revanche, faut être attentif !) C’est la taille maximum du LV « data » calculé comme suit : datasize = hdsize - rootsize - swapsize - minfree … prenez un peu de temps, je vous laisse méditer si besoin …
minfree : C’est l’espace libre qui doit être conservé dans le VG « pve ». Sa valeur sera de 16 Go si la taille du VG (hdsize pour ceux qui n’ont pas décroché) est supérieure à 128 Go ou de hdsize /8 si hdsize < 128 Go.

Voilà j’ai essayé d’être le plus clair mais n’hésitez pas à consulter le paragraphe « Advanced LVM Configuration Options » de la page source si besoin. Allez on continue …

Paramétrer le pays, le fuseau horaire et l’agencement du clavier, puis valider

Renseigner le mot de passe et le contact mail de l’admin

Pour ceux qui ont l’habitude des console IPMI, rien de spécial, pour les autres, sachez que le mappage clavier est en QWERTY ! Je vous conseille donc d’utiliser un mot de passe simple (qu’on se dépêchera de changer par la suite) pour éviter de devoir faire la correspondance entre ce que vous pensiez avoir écrit en AZERTY et ce que vous avez réellement écrit en QWERTY. Ça parait surement très bête mais imaginez si vous devez faire l’exercice sur un mot de passe complexe de 20 caractères … (on rigole moins tout de suite). On peut aussi utiliser le champ en clair de l’email puis faire un copier/coller via le menu « Keyboard » de la console. Personnellement j’évite cette méthode car l’@ peut être très compliqué à retrouver si vous l’effacez.

Configurer le réseau

Si vous êtes sur un réseau bénéficiant d’un serveur DHCP, ce qui est le cas chez OneProvider et à priori tous les hébergeurs, vous n’avez rien à faire, les champs seront renseignés automatiquement par les données du bail obtenu. Vous pouvez en revanche spécifier un nom d’hôte personnalisé (au format FQDN) si vous disposez d’un nom de domaine. Profitez-en également pour noter votre @IP publique si ce n’est pas déjà fait pour pouvoir accéder à votre serveur en SSH et via la WebUI … ce sera utile pour la suite.

S’auto-congratuler

Rejoindre la ZR

Voilà le parachute est plié (bourré en vrac) dans sa housse et vous avez rejoint la zone de rassemblement au pas de course avec vos 60 kilos sur le dos … la vrai mission va commencer …

En effet vous disposez à présent d’une belle installation toute propre de votre serveur … totalement vulnérable avec son mot de simple à six caractères et son iptables en mode ACCEPT ALL. Il va donc falloir se dépêcher de le sécuriser car pour l’instant il est à la merci de tous les « scripts kiddies » qui écument « l’internet du web ».

Mais ne vous inquiétez pas, on va s’occuper de tout ça dans la deuxième partie de cette article … (c’est bien foutu quand même) … et promis j’arrête les pseudo-analogies militaires !