OVH on Zwindler's Reflection

CIVO : du kubernetes managé à partir de 4$/mois, vraiment ?

Fri, 16 Jul 2021 07:00:00 +0000

Pendant la Kubecon EU 2021, un provider que je ne connaissais pas a mis le paquet pour s’assurer de la visibilité : CIVO. Et avec une promesse plus qu’alléchante : un Kubernetes managé basé sur k3s (que j’adore) et avec un tarif à partir de 4$/mois !

Chez les concurrents, on a rien sous les 15€ / mois (Scaleway), quand ce n’est pas 30 voire 80… De quoi piquer ma curiosité donc.

Un de plus ?

J’ai donc pris un compte d’essai proposé par l’entreprise aux participants de la Kubecon et j’ai créé un compte.

La première chose que j’ai testé, c’est l’interface (il y a aussi une CLI). Forcément, chez un pure player, c’est simple et efficace, on s’y retrouve et l’interface est léchée. On est loin du gloubiboulga visuel de chez Azure (cf mon test d’AKS). Après, c’est un minimum… c’est forcément plus simple quand on commence de zéro et qu’on a pas des centaines de produits ;-p.

On a un dashboard avec les opérations réalisées chronologiquement, un menu pour créer des clusters kube, un menu pour créer du compute et des LB « nus ». Rien de bien révolutionnaire, ça fait le job.

La partie « KubeQuest », c’est de la bête gamification (« Créez un cluster pour passer niveau 2!!! »), je ne m’y attarderai même pas.

Bon, on le créé ce cluster à 4$ ?

Bon, ne vous enflammez pas, l’offre « à partir de 4$/mois » ne sera pas utilisable en prod, pas de miracle. Mais c’est déjà un tour de force qu’ils arrivent à le proposer, notamment grâce à k3s.

Pas de surprise, le pricing des nodes est immédiatement affiché, et voilà à quoi ça ressemble :

Pour 4$ par mois, on vous propose un « cluster » d’un seul node, avec seulement 1 vCPU et 1 Go de RAM. Pas de quoi faire tourner grand chose d’autre que quelques containers nginx… Si ça jamais ça fonctionne ?! (on y reviendra)

Au delà, les prix sont similaires à ce que l’on trouve sur le marché « bon marché » (Scaleway notamment). Si on veut être un peu sérieux et comparer ce qui est comparable, on peut booter des machines avec 2vCPU et 4 Go de RAM à16$/mois l’unité (moins de ~13,5€ en ce moment).

Kubernetes easy to install

La plupart des offres managées de Kubernetes (si ce n’est toutes) viennent avec une certaine quantité de personnalisation préinstallée. Chez Azure, vous pouvez choisir parti 2 CNIs et le dashboard (ou pas). Chez Scaleway si c’est Calico qui est préinstallé ou pas.

Chez CIVO, ils ont poussé le concept beaucoup plus loin, en reprenant l’idée de Rancher ou d’Openshift du « marketplace ».

Avant de boostraper votre cluster, vous avez accès à tout un magasin d’applications (ni plus ni moins que des charts helm avec une icône pour cliquer dessus) et éventuellement une très petite personnalisation avec un dropdown menu (mais vraiment trivial, très peu de choix).

Et là, pour le coup en terme d’UX je trouve ça très très malin. En quelques clics, j’ai (dé)sélectionné les composants qui m’intéressent et ils ont été préinstallés pour moi avec mon cluster.

On peut même préinstaller des produits de sécurité, notamment Kyverno avec un ensemble de règles de sécurité préconfigurées.

Et c’est pas fini !

Pour ce qui est des composants d’infrastructure, je comprend l’incentive. Pour certains devs, l’infra c’est ch***t.

Mon cluster je le veux up and running sans perte de temps, sans pour autant que mes données soient à poil sur Internet

Mais comme tout ce qui « cache » la complexité du métier d’Ops (cf mon article « Au secours, le métier d’Ops va disparaître »), la difficulté n’est pas tant le déploiement que le « day 2 operations ». Et si vous voulez modifier un paramètre, vous êtes marrons.

Tout de même, préconfigurer cette partie dès le bootstrap du cluster est malin. Et ce qui est encore plus malin, c’est qu’ils ont open sourcé leur marketplace.

Qu’est ce qu’ils y gagnent, me direz vous ?

Et bien, s’il y a un nouveau « shiny composant » qui fait rêver tout le monde, vous pouvez aller faire une PR pour ajouter une tuile dans l’UI de CIVO. Comme ça vous bossez pour eux. Elle est pas belle la vie ? ;-p (je troll, mais je trouve ça cool, en vrai).

Et le cluster, il boote vite ?

C’est un peu la guéguerre entre Kubernetes managés à qui bootstrappera le control plane et les workers le plus vite. Azure met plus de 20 minutes. OVH bootstrappe le control plane en une minute mais met des plombes à sortir les VMs à cause de leur OpenStack. Exoscale fait le tout (control plane + workers) en moins de 2 minutes.

CIVO nous promet 90 secondes et c’était pas loin d’être vrai. Je ne dirai pas que c’est les plus rapides mais ils sont dans le top 3 de tous les kubes managés que j’ai pu tester, sans hésiter.

Une fois le cluster opérationnel, on vous propose évidemment de télécharger votre kubeconfig et roule ma poule

Mais qu’est ce qu’on peut faire tourner dans Kube avec 1 (ou 4) Go de RAM ?

Le souci avec ce genre de « petites machines », c’est que si vous n’avez pas OS et kubernetes optimisés, une part non négligeable de la VM ne sera pas utilisable pour vos workloads et vous n’aurez que (dans le pire des cas) 2 Go de libre.

Et c’est là toute la « malinerie » d’utiliser k3s plutôt qu’un k8s vanilla. k3s est spécialement pensé pour tourner sur des petites machines (en edge notamment). J’avais pu installer un master kubernetes sur un raspberry pi 1 (model B, 1 CPU ridicule et 512 Mo de RAM) tellement l’empreinte mémoire demandée est faible.

Associé à un magasin d’applications maison pré-tuné pour consommer peu (très petites requests pour fit les petites machines sans tout bloquer), on arrive avec des nodes quasiment sans overhead. Dans cet exemple, j’ai cliqué sur plusieurs composants (cert-manager, kyverno, ha-proxy, prometheus+alertmanager+grafana, metrics-server, falco). Je me retrouve avec des nodes (4vCPU 8Go) quasiment vides !

kubectl --kubeconfig civo-zwindler-kubeconfig top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k3s-zwindler-deadbeef-node-pool-31af 230m 5% 945Mi 12%
k3s-zwindler-deadbeef-node-pool-6609 97m 2% 471Mi 6%
k3s-zwindler-deadbeef-node-pool-e07c 141m 3% 874Mi 11%

Du coup, pour du lab perso ou des workloads qui nécessitent très peu de puissance, l’offre de CIVO est plutôt bien positionnée. Je ne suis pas complètement convaincu de l’intérêt de l’offre extra small à 4$ qui est plus là pour la prouesse technique qu’une réelle utilisation. Mais dès small ou medium, on a un service qui fonctionne, moins cher que de nombreux concurrents et surtout bien plus optimisé en terme de ratio overhead/puissance totale.

Au delà de kubernetes, l’offre est quasiment inexistante. Des VMs (plus chères que les workers kubes !!! wtf) et des loadbalancer à 10$/mois (Scaleway le fait à 8€, on est dans les prix « pas cher ») et c’est tout…

Autant dire que c’est kubernetes ou rien. Du coup, est ce qu’il y a un marché pour ce besoin, je ne suis pas certain… mais pourquoi pas ? En tout cas, bonne surprise !

J’ai testé pour vous : l’offre Kubernetes as a service d’OVH

Tue, 09 Jul 2019 11:30:50 +0000

OVH sort son offre Kubernetes managée

Vous avez peut être vu passer l’actualité début février, OVH a lancé (comme d’autres cloud providers) son offre Kubernetes as a service (KaaS).

Cette blague hilarante vous est offerte par zwindler !

Comme beaucoup de techno non triviales, une offre managée, c’est un bon moyen de mettre le pied à l’étrier si vous ne connaissez pas encore Kubernetes. C’est aussi un bon moyen pour OVH pour ne pas trop se laisser distancer par les géants américains.

En avril dernier, j’ai pu participer à un meetup dans les locaux d’OVH et de rencontrer les personnes qui avaient mis en place cette technologie. Du coup, je vous propose un petit article dans lequel on va voir ensemble à quoi ça ressemble.

Côté tarif

C’est le nerf de la guerre. Comme tous les autres (à l’exception notable d’EKS d’Amazon), vous ne payez que pour les workers, pas pour les masters (le control plane donc). Niveau tarif pour les workers, c’est simple, ce sont les tarifs applicables sur l’offre cloud public d’OVH.

La plus petite machine que vous pouvez sélectionner est un machine Linux de type B2-7, avec 2 vCPUs, 7 Go de RAM et 50 Go de SSD local.

C’est suffisant pour faire des tests, mais en production on en voudra au minimum 3, ce qui à 22€HT/mois pièce vous fera quand même environ 75€ / mois.

Au final, on est objectivement moins cher que ce que j’avais pu tester sur AKS. Car pour rappel, j’avais monté un cluster de machines de type B2ms avec 2 vCPU et 8 Go de RAM pour 30€ / mois, donc identique. SAUF que ces machines sont des machines dites “burstable” (vous n’avez qu’une portion d’un vCPU, que vous ne pouvez dépasser que pour une durée réduite avant de subir un throttling). Des machines équivalentes reviendraient sur Azure à utiliser des D2, pour un tarif de 83€TTC / mois… par machine !!!

Le fait que le control plane (les masters) ne soient pas payant est à la fois un avantage et un inconvénient. Pour OVH, je n’ai pas encore la réponse, mais lorsque j’avais testé AKS d’Azure, j’avais demandé au commercial ce qui se passait si mon control plane était HS (vu que c’est eux qui gèrent, je ne peux pas prendre la main pour le fixer). Il m’avait répondu texto : “comme c’est un produit gratuit, on ne s’engage sur aucune SLA (seulement un SLO de 2h)”. De quoi refroidir quand on est habitué à avoir la main sur son cluster Kubernetes.

Et si on testait ?

Assez parlé ! Dans mon manager d’OVH, j’ai créé un nouveau projet, que j’ai nommé de manière originale “Kubernetes Project”. Puis, j’ai créé un cluster Kubernetes en cliquant sur “Créer un cluster Kubernetes”

Actuellement, seul le DC “Graveline 5” semble capable d’accueillir l’offre KaaS d’OVH. Un point qu’il faudra améliorer dans le futur pour pouvoir se construire une infrastructure réellement résiliente.

Edit: Une deuxième région sera disponible dans le mois (cf Maxime Hurtrel, PM K8s chez OVH)

Niveau version de Kubernetes, bonne nouvelle, OVH s’est donné les moyens de proposer des versions très à jour de Kubernetes. Toutes les versions depuis la 1.11 jusqu’à la version 1.14 sont disponibles. La 1.14, qui n’a que quelques mois, est devenue dispo chez OVH assez rapidement. On peut imaginer que la 1.15 de Kubernetes qui vient tout juste de sortir (mi juin) sera probablement assez vite disponible aussi.

A titre de comparaison, chez Azure, ils sont assez bons dans ce domaine, et pourtant ils n’ont la 1.14 qu’en preview. Le mauvais élève Amazon est à la traîne avec seulement la 1.12 (pourtant sortie en septembre 2018).

“Ca va trop vite”

Cette partie là est relativement impressionnante. La création d’un nouveau cluster est extrêmement rapide.

Au total, l’instanciation d’un cluster met moins d’une minute, là où AKS en nécessite une 20aine (en comptant les workers certes, mais bon la moitié du temps le portal ou l’appel à l’API plante !).

Ceci est du à la façon dont le control plane a été créé et conçu par les équipes d’OVH (j’y reviendrais juste après) et est clairement une réussite. Pour avoir déployé à la main Kubernetes un paquet de fois et avec de nombreuses méthodes différentes (cf mes divers articles sur le sujet), c’est la méthode la plus rapide d’installer Kubernetes, et de loin.

L’architecture du control plane

Un des trucs sympas avec OVH, c’est qu’ils n’hésitent pas à communiquer sur les détails techniques. Certes, ils ne sont pas les seuls, mais c’est toujours agréables.

Lors du CNCF Meetup, Kevin Georges, Pierre Peronnet et Sébastien Jardin nous ont donc présenté les entrailles de leur Kubernetes as a service.

L’idée principale est que le control plane doit être le plus léger possible, pour coûter le moins cher possible à OVH (vu que c’est gratuit), tout en restant résilient.

La solution qui a été retenue pour arriver à une solution acceptable a été de déployer les services nécessaires au control plane de Kubernetes (control malanger, api server, scheduler) dans … un Kubernetes ! La seule brique non containerisée est etcd, et il s’agit ici d’un cluster dédié sur des machines physiques (ce qui explique probablement la limitation au DC Graveline).

Dans tous les cas, ça explique probablement aussi la vitesse de démarrage d’un nouveau cluster : il faut juste lancer 3 containers et zou, un nouveau cluster.

Source : OVH https://www.ovh.com/fr/blog/kubinception-using-kubernetes-to-run-kubernetes/

L’article technique détaillant tout ça est dispo sur le site d’OVH, je n’en dis pas plus, ils l’expliquent mieux que moi.

Les workers

Pour la partie Workers, plutôt que de développer sa propre API et l’intégrer comme module du projet Kubernetes (comme les autres gros cloud providers, qui ont leur code embarqué dans celui de Kubernetes), la team chez OVH en charge du projet s’est appuyée sur de l’existant : leurs propres services OpenStack fournissent déjà l’ensemble des briques dont ils ont besoin pour créer des VMs à la volées et les intégrer à des clusters Kubernetes.

Quand j’ai demandé au Meetup combien de temps il fallait pour “poper” un nouveau worker, un des trois speakers m’a dit, tout désolé “on ne fait pas de miracles, il faut quelques minutes”. Il n’a pas compris le pauvre quand j’ai éclaté de rire (parce que sur Azure, ça prend des plombes).

Ajouter des workers

La procédure est assez simple, mais se fait au travers de l’interface (comme la création du cluster). Je suis quasiment certain que tout doit pouvoir se piloter par API (je vois mal pourquoi ils auraient fait autrement pour un service tout neuf), pour autant, je n’en ai pas trouvé de trace dans la documentation officielle (pas à jour avec la nouvelle interface et encore un peu light)

Bon, alors je suis peut être mal tombé, mais quand j’ai cliqué dans l’interface pour ajouter des nodes, ça a quand même pris énormément de temps (facile 20-30 minutes). Du coup j’étais un peu (très) déçu…

Après investigation, en fait… c’est l’interface qui déconne ! En réalité, mon nœud était UP depuis longtemps déjà.

Je m’en suis rendu compte en faisant un petit kubectl get nodes et j’ai vu que mon node “Ready” depuis 28 minutes était encore marqué “En cours d’installation” …

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
vm1.12-1 Ready <none> 28m v1.12.7 51.77.204.236 <none> Container Linux by CoreOS 2135.4.0 (Rhyolite) 4.19.50-coreos-r1 docker://18.6.3

Se connecter au cluster

D’ailleurs, comment on s’y connecte ? Pas de souci de ce côté, OVH vous simplifie la vie en vous proposant de télécharger directement votre fichier kubeconfig préconfiguré, prêt à utiliser.

Si vous en avez plusieurs, pour rappel, vous pouvez utiliser le flag “–kubeconfig=kubeconfig.yml”

En vrai, un node ne met que 3 minutes à poper

Du coup, j’ai voulu retester le démarrage d’une nouvelle VM, en sachant que le temps indiqué sur l’interface web n’est pas bon.

Après quelques tests, en 3 minutes, le node apparait en “Not Ready”, puis passe “Ready” au bout de quelques secondes. On est donc très proche de ce dont j’avais pu parler avec les gens d’OVH du coup, c’est très bon comme temps de boot.

Ouf, on est rassurés !

Mise à jour

Un point sympa que permettent les solutions de type KaaS est la gestion des mises à jour depuis votre interface de gestion. Mettre à jour Kubernetes, c’est pénible. La moitié du temps, on a peur de tout casser.

Alors je ne dis pas que rien ne va casser avec le Kubernetes d’OVH, mais comme l’infra est cadrée et gérée par eux, j’imagine que c’est suffisamment bien testé dans des conditions similaires aux vôtres pour être un peu plus serein le jour où ça arrive.

A noter, contrairement à AKS, vous n’avez que peu la main sur les mises à jour. Cela se limite à ça, et je n’ai pas trouver comment monter de la 1.12 à la 1.13 par exemple…

Edit: Toujours selon Maxime Hurtrel, ça devrait arriver bientôt

Conclusion : au delà du compute, l’UI

Dans les points qui déchirent : OVH sait fournir un control plane à une vitesse à faire pâlir d’envie tous les concurrents.

Cependant, cela se fait sur un cluster Kubernetes mono DC (DC5 Graveline), avec la partie etcd externalisée à part, sur un cluster mutualisé. Je ne fais pas de jugement de valeur car, contrairement à OVH qui est transparent, je n’ai pas d’info technique sur les versions proposées par la concurrence.

En revanche, je peux comparer avec un cluster que j’installe moi même, et là clairement, je suis un cran en dessous en terme de ce qui peut être fait en terme de sécurisation de mon cluster.

Pour ce qui est de l’interface, elle souffre un peu de sa jeunesse. Il n’y a rien de plus que les onglets pour créer un cluster et pour ajouter ou supprimer des nœuds (et encore, pas plus d’info sur ces nœuds que leur nom et leur taille !).

Un dernier onglet existe pour “visualiser” ses containers et ses services, mais il est pour l’instant vide et sera de toute façon probablement moins utile que le dashboard ou tout autre outil existant (sauf à fournir un énorme effort de dev sur ce point).

Encore un exemple de la jeunesse de la solution et particulièrement de son interface : OVH pope des VMs (workers) très vite, ce qui devrait être super cool et soulever les foules… mais si on teste la solution rapidement, comme l’interface ne l’indique pas, on pourrait penser que ce n’est pas le cas ! Dommage !

Edit: Le problème est connu et en cours de fix

[Le tweet n’est plus disponible]

Et pour ce qui est des mises à jour, c’est le flou total. On vous explique que tout est maintenu à jour, mais les montées de versions majeurs sur un cluster ne semble pas disponible pour l’instant.

Dans les points pas glop : aucune trace dans la doc d’API pour créer des clusters à la volée ou les gérer de manière automatisée via Ansible ou autre…

Edit: l’API est là

[Le tweet n’est plus disponible]

Bref, vous l’aurez compris, techniquement c’est une réussite. Chez OVH, ils savent gérer des VMs et des containers et ça se voit. Mais l’offre KaaS d’OVH manque peut être encore d’un petit coup de polish pour qu’on se sente bien chez soi, et pleinement en confiance. Et c’est d’autant plus rageant que la solution a plein de bons points, que le travail abattu (en peu de temps) est colossal.

Je voudrais donc tenter de terminer sur une note positive, car c’est mon ressenti au global. Pour avoir rencontré des membres de l’équipes (de vrais passionnés), j’ai envie de croire que ce produit est amené à grandir, et ses petits défauts de jeunesse à disparaître.

A suivre donc !

Bonus GPU

Dans les petits “trucs” qui m’ont fait sourire, j’ai vu passer un tweet indiquant qu’OVH se lançait également (en alpha par contre pour l’instant) dans Kubernetes managé avec des instances baremetal avec GPU.

Je n’ai pas forcément de workload en tête, mais pour ceux qui veulent lancer des containers avec des calculs GPU, c’est une option qui peut faire sens.

Si vous voulez en savoir plus, c’est par ici :

Labs OVH GPU baremetal k8s nodes

Sécuriser l’émission de vos certificats avec un CAA (Azure)

Tue, 12 Jun 2018 11:45:10 +0000

CAA ? Azure ?!?

Et oui, je travaille sur Azure ! Je crois bien que c’est le premier article que je vais faire à ce sujet donc je commence par quelque chose de léger, créer un CAA.

Au-delà de toute considération purement dogmatique, le cloud de Microsoft fait quand même partie des plus grands, avec une richesse fonctionnelle et une API aussi riche que ce qu’on trouve chez les autres. J’aurai l’occasion de faire d’autres articles sur Azure car j’utilise énormément les modules Ansible développés par les équipes de Microsoft (qui s’appuient sur l’API d’Azure).

Et donc, le CAA ?

Mais cet article parle de CAA. Pour ceux qui ne connaitraient pas, un CAA est un « nouveau » (2017) type d’enregistrement DNS :

La CAA est une mesure de sécurité qui permet aux propriétaires d’un nom de domaine de préciser dans leur DNS (Domain Name System) les autorités de certification (AC) qui sont autorisées à émettre des certificats pour leur nom de domaine.

Global Sign (lien mort, pas disponible sur Internet Archive)

Concrètement, si je possède un domaine avec un grand nombre de sites web signés, que je n’utilise qu’une ou deux (ou un nombre fini) autorités de certifications, je peux maintenant spécifier lesquelles (parmi la centaine des AC existantes) sont autorisées à émettre un certificat pour mon domaine. Cela permettra d’éviter que des personnes mal intentionnées génèrent un certificat pour une URL dans un de vos sous domaines.

Comment ça fonctionne ?

Il existe donc un nouveau type d’entrée dans votre DNS qui devrait ressembler à ça :

Name	Type	Value
zwindler.fr.	CAA	0 issue « letsencrypt.org »
zwindler.fr.	CAA	0 iodef « mailto:zwindler@zwindler.fr »

Pour l’entrée zwindler.fr., j’ai donc un CAA qui dispose de 2 variables (issue et iodef) :

La première indiquant que seul letsencrypt.org peut générer des certificats pour mon domaine. On peut en avoir plusieurs si on a plusieurs autorités de certification.
La seconde indiquant qu’il faut m’envoyer un email si jamais quelqu’un qui n’a pas les droits essaye de générer un certificat.

A noter : iodef n’est pas respecté par toutes les autorités de certifications, donc vous n’aurez potentiellement pas d’emails en cas de tentative de génération de certificat chez une AC non autorisé.

Ok, comment je créé un CAA ?

Normalement, c’est trivial. Il s’agit d’un enregistrement DNS comme un autre. Par exemple chez OVH, vous pouvez directement le créer depuis l’interface :

Et sur Azure ?

Il faut bien que ce soit rigolo. Dans le portail d’Azure, il n’est pas possible de créer (ni même de voir !!!) les champs de types CAA, pourtant disponibles depuis mi 2017.

La seule solution est d’utiliser l’API REST, la CLI azure, ou Powershell :

Page de documentation azure cli (record-set)
Gérer les enregistrements DNS avec Powershell

Avec Azure cli

Du coup je suis parti de la doc pour faire ça :

En partant du principe que vous avez un compte sur Azure, que vous gérez les DNS de la zone zwindler.fr depuis Azure DNS (dans un resource group appelé dns-rg), voilà ce qu’il faut faire pour créer une protection pour le sous domaine *.test.zwindler.fr.

az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "issue" --value "letsencrypt.org"
az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "iodef" --value "zwindl3r@zwindler.fr"
az network dns record-set caa list --resource-group dns-rg --zone-name zwindler.fr
{
"caaRecords": [
{
"flags": 0,
"tag": "iodef",
"value": "zwindl3r@zwindler.fr"
},
{
"flags": 0,
"tag": "issue",
"value": "letsencrypt.org"
}
],
"etag": "aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa",
"fqdn": "test.zwindler.fr.",
"id": "/subscriptions/aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa/resourceGroups/dns-rg/providers/Microsoft.Network/dnszones/zwindler.fr/CAA/test",
"metadata": null,
"name": "test",
"resourceGroup": "dns-rg",
"ttl": 3600,
"type": "Microsoft.Network/dnszones/CAA"
}

Et si je veux le domaine entier ?

Et là c’est la blague !

Si vous créez un record-set « test« , il va vous créer un CAA pour test.zwindler.fr (voire le champ fqdn dans la réponse du list). Vous n’avez pas la main sur le fqdn directement (que ce soit en création ou en mise à jour), il est créé à partir du nom.

Or, vous avez très probablement envie de protéger zwindler.fr, pas seulement test.zwindler.fr, car ça n’aurait pas vraiment de sens (on rappelle que le but de la manœuvre et d’empêcher des gens de générer des certificats pour des sous domaine de votre domaine) sinon.

Créer une liste exhaustive de tous les sous domaines possibles me semble complexe ;-).

L’astuce, que vous ne trouverez pas dans la documentation (en tout cas dans les pages que j’ai lues), est de créer un recordset avec comme nom « @ » (j’avais testé, vide, « * », « . », mais pas « @ »…).

Et là, un recordset sera créé pour l’ensemble de votre zone DNS (zwindler.fr dans mon exemple).

Magie-magie…

Liens utiles

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 !

100ème article ! 5 ans de « Zwindler’s Reflection »

Tue, 27 Oct 2015 20:49:18 +0000

5 ans (et demi)

Non ce n’est pas mon age ! Dur d’imaginer que cela fait déjà plus de 5 ans que j’écris sur ce blog.

Et il en a vécu des changements ! D’abord hébergé sur une page perso Free, ensuite hébergé sur un compte wordpress.com, et enfin de nouveau sous mon contrôle via un hébergement OVH mutualisé.

Qui sait, peut être que dans quelques années je déciderai d’installer chez moi un rack 42U contenant une ferme de serveurs dans laquelle sera auto-hébergé -entre autres geekeries indispensables- mon site web ?
Pas sûr d’obtenir le Wife Acceptance Factor cela dit ;-)

A hundred

Si nous étions dans un jeu vidéo, j’aurai débloqué samedi dernier un succès pour avoir atteint la barre symbolique du 100ème article posté !

Alors c’est sûr, le style d’écriture a forcément un peu évolué avec le temps vers un registre un peu moins décontracté, mais les objectifs du blogs eux n’ont pas changés :

Essayer de donner quelques tuyaux à mes pairs, de préférence sur des sujets pour lesquels j’ai eu du mal à trouver l’information autre part. Le but n’est pas de faire de l’audience à tout prix, juste de donner un coup de main en remerciement pour tout les blogueurs qui m’ont aidés moi.
Un choix délibéré du Français plutôt qu’un énième blog en anglais. Tout le monde ne maîtrise pas la langue de Shakespeare et même si mon niveau d’anglais est correct, mes explications sont forcement plus précises dans ma langue maternelle (et la précision, c’est la vie)
Faire partager mes petites expériences de passionné, mes retours d’expérience du boulot… et parfois mes grognements de SysAdmin !

Vous, mes lecteurs

Pour l’occasion, je vais me permettre de donner quelques informations sur mes lecteurs et ce qu’ils recherchent sur mon blog.

VMware, incontournable

Les articles qui intéressent le plus sont ceux qui traitent de VMware. J’écris sur le sujet depuis le début, je suis revenu dessus à plusieurs reprises et soyons honnête, dur de passer à côté dans le monde de l’IT. Ce qui est un peu étonnant c’est que le sujet est déjà traité par beaucoup de blogs bien plus connus et dont les auteurs sont plus pointus que moi sur le sujet. Peut être que le côté Francophone joue en ma faveur face à un yellow-bricks ou vladan ?

Des niches

Je peux me targuer fièrement d’être un des seuls bloguer IT Français à donner des astuces et des retours sur Vulture WebSSO !

Ahah ! Ça vous épate ?

Bon, ok. C’est un peu comme jouer à un sport avec 1000 licenciés dans tout un pays. On arrive beaucoup plus vite au sommet ;-). Et ça ne change en rien la qualité du soft Vulture. C’est juste … peu courant (pour l’instant) !

Dans un registre un peu moins confidentiel, mes articles sur Shinken sont généralement bien classés, notamment mon tutoriel sur l’installation et la configuration de la version 2.4 sur CentOS.

Mais des surprises

Étant tout sauf un fan de la marque à la pomme, je ne pensais vraiment pas, en écrivant un article sur un message d’erreur RDP sous Mac (dont je ne connais pratiquement rien) qu’il aurait autant de succès !

De même, mes articles qui traitent de mes bidouillages avec la Livebox Orange, le VDSL2, les Freebox V5 et Mini 4K sont généralement assez bien référencés (on m’a même cité dans des forums à plusieurs reprises). Il est toujours agréable de voir qu’on est pas le seul à galérer sur ces problématiques de routeurs opérateurs !

Last but not least

Mais de tous mes articles, la palme revient sans conteste à celui où je détaille ce script, réécrit à partir d’un script non fonctionnel fourni par OVH (sur leur site officiel) et qui permet de modifier automatiquement un DynHost dans le cas où votre IP n’est pas dynamique.

J’ai pu le retrouver à divers endroit du net, amélioré, modifié, adapté. On m’a aidé à en faire une version encore meilleure.

Cet aspect communautaire, c’est un peu ça que je cherchais lorsque j’ai commencé à écrire. Je suis content d’y être parvenu.

L’enfer des blogs conseils en référencement : sortir de la jungle du clickbait et de l’enfoncement des portes ouvertes

Mon, 20 Jul 2015 10:30:53 +0000

Il y a 6 mois, j’ai pris la décision d’être un peu plus sérieux avec ce blog et avec, de bonnes résolutions : un rythme de publication plus soutenu et surtout plus régulier, un contenu un peu plus large (comprenez « moins de sujets niche ») et un vrai hébergement.

Migration depuis wordpress.com vers un hébergement tiers

Ça impliquait forcément de perdre une partie de l’audience car -je le savais bien depuis le début- wordpress.com est relativement bridé dans sa partie gratuite, et n’autorise pas les mécanismes de redirection pour migrer votre audience vers un blog externe.

Sauf si vous payez 13USD/an bien sûr ! Notez que même si je suis un peu ironique, ce n’est pas forcément un mauvais choix si vous avez déjà une petite communauté à faire suivre. Le tarif est salé mais pas prohibitif.

Une fois que c’est réglé et que votre hébergement (voir ici si ce n’est pas encore fait), encore faut il trouver des lecteurs. Mais comment faire ?

Simple, demandons à l’Internet son avis sur la question !

Note : pour ceux qui ne veulent pas saigner des yeux, vous pouvez tout de suite aller lire la fin de l’article pour les liens vers deux sites sérieux (ou cliquer [ici][3])

Faire de l’argent en faisant miroiter aux autres qu’ils peuvent en faire aussi

Mettez les termes « référencement », « blog », « gratuit », « wordpress » dans un ordre aléatoire dans votre moteur de recherche préféré et vous tomberez d’abord sur une multitude de sites payants pour vous aider à vous faire connaitre. Ils sont suivis par des articles de blogs avec plus ou moins les mêmes conseils pour réussir.

Vous y apprendrez qu’il faut -selon eux- impérativement poster plusieurs fois par semaine. Il faudrait écrire des articles sur le blog d’un autre blogueur plus connu, sur des forums à forte affluence… Il faudrait écrire des tutoriels simples pour toucher le public le plus large, illustrés avec des images et des vidéos Youtube. Tout ceci est vrai, un peu obvious parfois et probablement efficace. Vous finirez par « attirer des visites », même si dans la pratique je ne vois pas comment trouver de la matière intéressante plusieurs fois par semaine sans dégrader la qualité. Je ne vois pas trop l’intérêt d’un vidéo tutoriel pour apprendre à utiliser la commande « reboot ».

On y apprend également qu’il existe des outils pour optimiser le rendement des moteurs de recherche, notamment via des plugins comme « WordPress SEO by Yoast », « Google XML Sitemaps ». Il faut également utiliser les outils des webmasters fournis par les grands moteurs de recherche, … Là on commence à toucher du doigt le vrai principe du référencement, mais sans aller jusqu’au bout de la démarche au delà de leur simple paramétrage. Dommage.

AHAHAHAHA ! Tu as vraiment cru que j’allais cliquer ?

Clickbaiiiiiiiit : Click click click je veux des clics!

C’est le genre de site pour vous aider à référencer gratuitement votre site le plus courant. Et celui là est juste fantastique.

J’en connais un qui s’est dit après coup que 10 étapes c’était mieux en terme de marketing

Le premier conseil donne le ton :

Remplissez soigneusement le titre de votre blog en y insérant vos mots clés, mais au travers d’une phrase qui donnera envie de cliquer aux internautes

Et après ça, on a droit à la totale. Une grosse image moche en plein milieu pour « illustrer », des ebook gratuits avec des liens partout. Pratiquement pas de mise en page ou alors elle n’est pas respectée dans tout l’article. Et une vidéo Youtube pour finir. Ça ne s’invente pas ;-).

Pardon, je vais vomir, et je reviens

Hum ! Cet ebook TOP SECRET m’a l’air particulièrement passionnant !

APPRENEZ A BLOGUER COMME UN PRO EN 2008 §§§§ (désolé la touche verr. maj. était bloquée)

Alors oui, il est très probable que ce blog soit un succès en terme de visites. On tombe facilement sur ce blog (ou d’autres), malgré son contenu mal présenté et ses ebooks envahissants. Et si ce que vous cherchez est du clic (je ne parle pas d’audience) à tout prix, ces conseils sont probablement bons.

On arrive quand même à trouver quelques conseils valables en tout début d’article (déjà vus dans le paragraphe précédent), notamment l’utilisation des outils SEO et moteurs de recherche.

Des sites un peu plus sérieux

Heureusement, à force de recherches, vous finirez par tomber sur des sites un peu plus sérieux qui vous expliqueront de manière claire les bonnes pratiques lorsqu’on se lance dans la rédaction de contenu. C’est particulièrement intéressant car ces sites introduisent d’abord les principes du référencement pour vous aider à comprendre comment fonctionnent les moteurs de recherche, ce qui selon moi est la meilleur façon d’introduire un sujet.

Je citerai les sites suivants mais il y en a surement beaucoup d’autres :

Un petit dernier pour la route car j’ai échangé un peu avec Mehdi de blogbooster. Si je ne suis pas forcément en phase avec le style d’écriture, Mehdi donne quelques astuces qui sont rarement mise en avant par d’autres site. Ça peut valoir le coup d’aller y jeter un œil :

blogbooster.fr/comment-referencer-son-blog

Courage, c’est plus long mais c’est la bonne marche à suivre pour réussir :-).
Bon référencement !