• STATISTIQUES
  • Il y a eu un total de 1 membres et 4345 visiteurs sur le site dans les dernières 24h pour un total de 4 346 personnes!


    Membres: 2 604
    Discussions: 3 579
    Messages: 32 816
    Tutoriels: 78
    Téléchargements: 38
    Sites dans l'annuaire: 58


  • ANNUAIRE
  • [FR] Le site du zero
    Découvrez gratuitement la programmation (C, C++, PHP, MySQL, XHTML, CSS...), Linux, le Mapping, la modé...
    Programmation
    [EN] Big-Daddy
    Big-Daddy est site internet communautaire avec un effectif diversifié, y compris des artistes, des programmeur...
    Hacking
    [EN] Astalavista
    Un site aux ressources incontournable depuis plusieurs années, Astalavista est réellement devenue un cl...
    Hacking
    [EN] Astalavista
    JavaScript: 1, Exploit: 2, Crypto: 34, CrackIt: 15, Stegano: 8, Programming: 12, Logic: 36, Special: 6, Science: 4, Info...
    Challenges
    [FR] µContest
    µContest est un site de challenges de programmation, c'est à dire qu'il propose des épreu...
    Hacking
    [EN] This is legal
    Basic: 10, Realistic: 5, Programming: 1, Bonus: 11, SQL: 2, Encryption: 6, Application: 4, User Contributed: 3
    Challenges
    [EN] hax.tor
    50 level de challenges mélangés
    Challenges

  • DONATION
  • Si vous avez trouvé ce site internet utile, nous vous invitons à nous faire un don du montant de votre choix via Paypal. Ce don servira à financer notre hébergement.

    MERCI!




Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Monter un container LXC
03-01-2015, 13h50 (Modification du message : 16-01-2015, 20h05 par supersnail.)
Message : #1
supersnail Hors ligne
Éleveur d'ornithorynques
*******



Messages : 1,608
Sujets : 71
Points: 466
Inscription : Jan 2012
Monter un container LXC
Bonjour à tous et bonne année !

Depuis quelques temps je fais joujou avec la virtualisation sur notre gnou/manchot préféré, et je profite de cette section "Administration système" flambant neuve pour faire un petit guide de la galaxie LXC pour les débutants.

I - LXC, kézako et à quoi ça va me servir ?

Tout d'abord, LXC est un projet (heureusement bien avancé) permettant de faire de la "virtualisation légère", c'est-à-dire de créer des machines virtuelles GNU/Linux qui utilisent le noyau de l'hôte. De plus, la virtualisation repose sur les fonctionnalité d'un noyau Linux récent "standard", ainsi contrairement à OpenVZ, pas besoin d'un noyau patché pour s'adonner au plaisirs de la virtualisation ! Big Grin. LXC s'apparente donc aux "jails" de FreeBSD ou encore aux "zones" de Solaris.

Venons-en à la deuxième question qui est "à quoi ça va me servir ?" (je supposerai ici que vous n'êtes pas un un sysadmin vétéran, cc Snorky :þ). Je pourrais répondre que cela peut permettre de tester de nouveaux logiciels sans craindre de péter sa distribution principale, isoler des programmes privateurs (qui a dit Oracle ?) ou qui essaient d'espionner l'utilisateur (qui a dit Skype ? >:]), ou tout simplement séparer environnement de dev/machine de tous les jours (la mise en place/migration d'une VM de production peut même se faire assez facilement grâce à Docker, qui s'appuie justement sur LXC, bien que Docker semble supporter d'autres technos). Cependant je ne recommande pas LXC pour faire des VM de CTF ou pour débugguer des malwares/rootkits, justement à cause du fait que le container et l'hôte partagent le même noyau (un exploit kernel et PAF le système :'))

II - Comment ça s'installe / comment on s'en sert ?

Tout d'abord il va falloir nous munir d'un compte root (étant donné que nous aurons plusieurs commandes à taper, je recommande un "su" et un "sudo -s" pour les ubunteros). Il nous faudra installer le paquet "lxc" de la distribution (via apt-get sur debian/ubuntu/mint, yum pour fedora et pacman pour archlinux).
Pour ceux qui ont une partition "/" assez petite, étant donner que les machines virtuelles vont se placer dans /var/lib/lxc, je vous recommande de symlinker ce répertoire vers une partition plus grande (de toute façon, seul root pourra accéder aux VM Wink).

Vient ensuite le grand moment de notre vie, l'installation de notre container \o/. Il suffit de taper la commande magique:
Code :
# lxc-create -n <nom_de_votre_vm> -t download
Ici, le "-t download" indique qu'on utilise le template "download", qui comme son nom l'indique va télécharger une image système depuis linuxcontainers.org afin de permettre un déploiment rapide (si vous êtes paranos, vous pouvez toujours installer les outils nécessaires pour construire une image vous-même et utiliser un template listé dans /usr/share/lxc/templates).
Vous devrez ensuite sélectionner la distribution, sa version ainsi que l'architecture (i386 pour du 32 bits et amd64 pour du 64bits), puis après un temps plus ou moins long, le temps de télécharger l'image du système, vous vous retrouvez face à votre container lxc tout brillant Big Grin.

Cependant, avant de lancer la VM, il vous faudra définir un mot de passe root, celui-ci n'ayant pas été défini dans les images de VM téléchargées. Vous pouvez pour le faire soit chrooter directement dans le dossier du container, soit la méthode plus "classe" qui est de démarrer le container (via un
Code :
lxc-start -n <le_nom_du_template>
) puis dans un autre terminal, obtenir un shell via un
Code :
lxc-attach -n <le_nom_du_template>
, puis lancer un "passwd".

Normalement, vous devriez avoir un container fonctionnel, mais sans accès au réseau cependant, ce que nous allons corriger dans la section suivante.

III - Configuration du réseau

Nous allons ici créer un réseau de type "veth" pour LXC (que l'on pourra aussi réutiliser pour des VM Qemu/KVM et ainsi avoir un joli LAN de machines virtuelles Big Grin) à l'aide d'un bridge.

Pour les ubunteros, le bridge est déjà préconfiguré (l'installation de lxc a créé un périphérique "lxcbr0" directement disponible). Sinon, je vous laisse vous référer à la documentation de votre distribution pour la création d'un bridge car je suis flemmard et j'ai pas envie de traiter la configuration du bridge pour chaque distribution existante. Dans ce tutoriel, on ne se limite qu'à la création d'un réseau privé virtuel, que vous pourrez éventuellement NATer. Dans la suite du tutoriel, je considèrerai que tout le monde a défini l'adresse IP de br0 (ou lxcbr0) à 10.0.1.1/24 (sans passerelle par défaut).

Une fois votre bridge créé, il suffit de modifier la configuration de la VM (dans /var/lib/lxc/<nom_de_la_vm>/config) et y rajouter/remplacer ceci:

Code :
lxc.network.type = veth
lxc.network.link = br0 # à remplacer par lxcbr0 pour les ubunteros ;)
lxc.network.ipv4 = 10.0.1.xx/24
lxc.network.ipv4.gateway = 10.0.1.1

Du côté de l'hyperviseur, un petit
Code :
iptables -t nat -F POSTROUTING -s 10.0.1.0/24 -j MASQUERADE
vous permettera de NATer en toute tranquilité Wink
Vous pouvez arrêtez le container, si vous l'avez déjà lancé via un petit "lxc-stop -n <nom_de_la_VM>". Au prochain démarrage vous devriez avoir un réseau fonctionnel ! (modulo le DNS à rajouter dans /etc/resolv.conf).

Ce sera tout ici, si vous avez des questions/difficultés de configuration n'hésitez pas à les poser Wink
Mon blog

Code :
push esp ; dec eax ; inc ebp ; and [edi+0x41],al ; dec ebp ; inc ebp

"VIM est merveilleux" © supersnail
+1 (7) -1 (0) Répondre
04-01-2015, 22h41
Message : #2
Atlas Hors ligne
Membre actif
*



Messages : 69
Sujets : 7
Points: 3
Inscription : Aug 2012
RE: Monter un container LXC
Bonsoir,
merci beaucoup pour ce guide !
J'aurais une question (probablement idiote) : quels sont les avantages de lxc par rapport à une machine virtuelle "classique" comme virtualbox ?
La différence si j'ai bien compris est lxc utilise le noyau Linux de notre OS , mais quels en sont les avantage?

Merci
+1 (0) -1 (0) Répondre
04-01-2015, 23h01
Message : #3
supersnail Hors ligne
Éleveur d'ornithorynques
*******



Messages : 1,608
Sujets : 71
Points: 466
Inscription : Jan 2012
RE: Monter un container LXC
Ben les avantages c'est déjà que ça bouffe beaucoup moins de mémoire; et les performances sont meilleures que du virtualisé: déjà on s'épargne de charger un noyau supplémentaire, puis on a pas d'émulation/virtualisation d'instructions, les processus s'exécutent réellement sur le processeur hôte.
Mon blog

Code :
push esp ; dec eax ; inc ebp ; and [edi+0x41],al ; dec ebp ; inc ebp

"VIM est merveilleux" © supersnail
+1 (0) -1 (0) Répondre
07-01-2015, 01h07 (Modification du message : 07-01-2015, 01h27 par otherflow.)
Message : #4
otherflow Hors ligne
Newbie
*



Messages : 20
Sujets : 2
Points: 18
Inscription : Aug 2014
RE: Monter un container LXC
(04-01-2015, 23h01)supersnail a écrit : Ben les avantages c'est déjà que ça bouffe beaucoup moins de mémoire; et les performances sont meilleures que du virtualisé: déjà on s'épargne de charger un noyau supplémentaire, puis on a pas d'émulation/virtualisation d'instructions, les processus s'exécutent réellement sur le processeur hôte.

Si vous voulez des informations supplémentaires au sujet de ce type de virtualisation, il y a un article dessus sur Wikipedia : Operating-system-level virtualization

otherflow

Le tutoriel lu je peux me permettre de remercier supersnail.

Merci joli tutoriel !

otherflow

PS pour les modo et admin : Je n'ai pas trouvé de moyen éditer mon message précédant.
+1 (3) -1 (0) Répondre
08-01-2015, 20h13
Message : #5
0pc0deFR
Non-enregistré



 
RE: Monter un container LXC
Petite question: d'un point de vu sécu ça donne quoi, est-ce qu'il y a un risque, en attaquant lxc d'atteindre le machine hôte ou de corrompre le noyau puisque c'est le même pour les deux machines?
positive (0) negative (0) Répondre
08-01-2015, 20h21
Message : #6
supersnail Hors ligne
Éleveur d'ornithorynques
*******



Messages : 1,608
Sujets : 71
Points: 466
Inscription : Jan 2012
RE: Monter un container LXC
Oui, un sploit kernel peut affecter la machine hôte d'où ma mise en garde Wink.

Par contre un shutdown de lxc n'éteindra que le container et non l'hôte Wink (de ce que j'ai compris, shutdown ne fait qu'envoyer un signal à init qui va se charger d'éteindre proprement le système, corrigez-moi si je me suis planté comme une grosse buse Tongue)
Mon blog

Code :
push esp ; dec eax ; inc ebp ; and [edi+0x41],al ; dec ebp ; inc ebp

"VIM est merveilleux" © supersnail
+1 (0) -1 (0) Répondre
28-01-2015, 18h06
Message : #7
T1loc Hors ligne
Newbie
*



Messages : 13
Sujets : 1
Points: 6
Inscription : Jun 2013
RE: Monter un container LXC
Salut, \o

Tu as raison pour ce qui est du shutdown.
Ce que je trouve dommage c'est que certain outils ne sont pas portés sur des distrib grand public (et quand je dis grand public je parle pas d'ubuntu Smile)

J'utilise depuis quelques moi lxc étant donné que je suis dans la virtualisation sur Gnu/Linux.

Je vous partage un petit code qui me donne quelques info utiles.
Uniquement testé sur CentOS mais devrait être compatabile à 90% je pense :-)

Code :
#!/bin/bash
# Description : Script d'info des conteneur lxc
# Auteur : T1loc
# Date : 24.10.2014

# On recupere le nom des CT
declare -A CT_name

# Compteur d'indice du tableau
cpt=0

i=''; for i in $(lxc-ls); do
  # On recupere l'etat de la machine
  j=$(lxc-info -s -n $i|awk '{print $NF}')
  # On recupere les ip
  k=$(lxc-info -i -n $i|awk '{print $NF}'|paste -sd '+' -)
  # Info supplementaire avec l'option -a
  if [ "$1" == "-a" ]; then
    # On recupere l'interface de l'hote physique
    l=$(lxc-info -S -n $i|grep Link | awk '{print $NF}')
    # On recupere si l'autostart est active
    m=$(awk '/lxc.start.auto/{print $NF}' /var/lib/lxc/$i/config)
    # On recupere la memoire utilise
    n=$(lxc-info -n $i -S|grep Memory|awk '{print $(NF-1) $NF}')
  fi
  # On fout tous dans un tableau
  CT_name+=([$cpt]="$i;$j;$k;$l;$m;$n;")
  # On incremente (pour le fun ? :p)
  ((cpt++))
done

# Variable pour la couleur et les colonnes
RESETCOLOR="$(tput sgr0)"
VERT="$(tput bold ; tput setaf 2)"
BLEU="$(tput bold ; tput setaf 4)"

clear #Obligatoire..
COLUMNS=`tput cols`
column=`expr \( $COLUMNS - 20 \) / 2`
tput cup 0 $column
tput rev
# On affiche les entetes de colonne
echo -e "${BLEU}Info globale sur les CT"
tput sgr0
tput rc

tput cup 0 0
echo "${VERT}"
echo  "Conteneur"

tput cup 1 30
echo "Etat"

tput cup 1 42
echo "IP ${RESETCOLOR}"
# On affiche plus avec -a
if [ "$1" == "-a" ]; then
  tput cup 1 51
  echo "${VERT}Interface"

  tput cup 1 63
  echo "AutoStart"

  tput cup 1 74
  echo "Mémoire utilisé ${RESETCOLOR}"
fi

line=2
# On parse notre tableau pour le joli rendu :)
x=''; for x in ${CT_name[@]}; do
  # On affiche le conteneur
  awk -F';' '{print $1}' <<< "$x"
  tput cup $line 30
  # On affiche l'etat
  awk -F';' '{print $2}' <<< "$x"
  tput cup $line 39
  # On affiche l'ip principal (eth0)
  awk -F';' '{print $3}' <<< "$x" | awk -F'+' '{print $1}'
  tput cup $line 51
  # On affiche l'interface
  awk -F';' '{print $4}' <<< "$x"
  tput cup $line 66
  # On affiche l'autostart 1 = enable alors on affiche oui
  awk -F';' ' $5 == "1" {print "Oui"}' <<< "$x"
  tput cup $line 75
  # On affiche la memoire
  awk -F';' '{print $6}' <<< "$x"
  ((line++))
done

# Tchao
exit 0
+1 (2) -1 (0) Répondre
03-09-2015, 18h45
Message : #8
Xpl0ze Hors ligne
Newbie
*



Messages : 6
Sujets : 2
Points: 3
Inscription : Apr 2012
RE: Monter un container LXC
Salut à tous,

juste pour apporter ma petite pierre à l'édifice pour parler de la sécu dans LXC.

Je pense qu'LXC ne répond pas à tout les cas d'utilisations, notamment dans le cas d'une infra critique, et je vais expliquer pourquoi.

Quand on parle de conteneurisation , à la base il faut savoir qu'il y a plusieurs technos qui lead le game : Docker, LXC et Rocket.
Tout le monde a déjà entendu parlé de Docker, et on le compare souvent à LXC, oui mais voilà : si se sont bien tout deux des solutions de conteneurisations, ces deux solutions fonctionnent de manière bien différente. je vais pas m'étaler sur les différences de rootfs, montage, namespaces etc.
Le fait est que Docker nécessite un Daemon exécuté exclusivement avec les droits superuser (soit en root) tandis que LXC permet d’exécuter des conteneurs en root ou non.
L’Intérêt d’exécuter un conteneur en non root est que dans le cas ou un vilain arrive à se connecter sur un conteneur, et s’échapper de celui-ci pour toucher l'host, il ne sera "que" user , et non pas superuser. Oui mais voilà : le problème principal de LXC est aussi ce qui fait sa force : un seul et meme kernel est utilisé par tout les conteneurs.
La plus part des vulnérabilités qui permettront d'échapper le conteneur viendront du kernel. Il y a de très très très grandes chances qu'une vulnérabilité dans le kernel qui permette de s’échapper d'un conteneur permette également de devenir root.

On met donc en avant le fait que cela utilise moins de ram, que cela permet d’exécuter un seul noyau etc etc. C'est vrai, mais il faut prendre en compte le fait que tout ces points forts sont aussi des points faibles dans une infrastructure sécurisée.
Je m'explique : dans un environnement sécurisé là ou il y a 10 VM, on pourrait penser qu'il y aura 10 conteneurs sur une vm (ou même un poste lourd) . Le problème c'est qu'en fonction des middleware qui tournent sur les différents conteneur, on aura besoin d'activer des modules du kernel (ip_vs_rr par exemple...) . Si le premier conteneur a besoin de ce module , et que le deuxième conteneur n'en a pas besoin, tant pis pour vous ce module sera accessible depuis les 2 conteneurs; ce qui -1- ne sera pas le cas avec des VM correctement paramétrés et -2- accroit le nombre de vulnérabilités possible sur les deux machines.
Dans le cas d'un exploit lié à une vulnérabilité du kernel , tout les containers sont automatiquement touchés . Admettons que sur cette même VM , en tant qu'attaquant, vous n'ayez les logins que d'un conteneur. Cela mets quand même en péril les 9 autres.
Exemple avec un kernel panic, l'host et les 10 conteneurs seront freeze même si ceux-la ne font pas partie du même réseau logique, ou ne sont même pas connectés à internet (testé et approuvé sur ubuntu 14.04 j'ai plus la CVE en tête).

LXC supporte aussi le système de capabilities . Pour rappel (ou pas) les capa sont des groupes de droits qui visent à remplacer le suid. Par exemple, Un binaire a uniquement le droit d'utiliser le module du kernel qui permet de créer des sockets (CAP_RAW_IO) mais ne peux pas utiliser les fonctions nécessaire à un mount. on gere les capabilities soit en les attribuant à tout un conteneur via les fichiers de conf (uniquement si c'est un conteneur privilégié = lancé en root) ou directement sur les binaires depuis l'host (si c'est un conteneur non privilégié = lancé en non root) via les outils getcap et setcap
Ce système est censé permettre de gérer au mieux quels fichiers on accès à quels fonctions du kernel. Oui , mais un grand nombre de capabilities permettent à elles seules d'abuser du kernel (CAP_SETUID etc) . Les capa peuvent même rendre un binaire plus vulnérable . Un programme SUID appartient à root, un programme non SUID appartient à l'utilisateur. à partir de là, tout les fichiers générés par ce binaires changent d'owner et il devient possible d'en abuser (cf le POC sur le binaire passwd dispo sur internet).

Bref je trouve qu'LXC est tres bien pour de la préprod ou de la petite prod non critique, mais que ça devient vraiment tricky lorsqu'il s'agit d'intégrer ça dans un système critique. Je ne dis pas qu'il ne faut pas l'utiliser, mais c'est comme une vrai archi réseau , la distribution des conteneurs entre VM doit être très réfléchi si elle est vouée à être mise en prod ( un minimum de sécu dans les reseaux de prod est selon moi indispensable).

Encore une fois je ne critique pas la techno, j'essaie juste de mettre en perspective les bons et mauvais cotés car on trouve encore peu voir pas de doc sur le sujet.

PS : depuis un conteneur non privilégié, on peut retrouver la vrai racine du conteneur sur l'host et le nom de l'utilisateur qui a lancé le container ...c'est un début d'information disclosure, même si ça vaut ce que ça vaut =).

A+ o/
+1 (2) -1 (0) Répondre
03-09-2015, 19h05 (Modification du message : 03-09-2015, 19h09 par supersnail.)
Message : #9
supersnail Hors ligne
Éleveur d'ornithorynques
*******



Messages : 1,608
Sujets : 71
Points: 466
Inscription : Jan 2012
RE: Monter un container LXC
Bonjour,
En plus les containers non privilégié c'est tout buggué Big Grin, les features du noyau nécessaires pour les containers non privilégiés sont tellement bourrés de failles que les devs d'ArchLinux ont carrément décidé de zigouiller la feature dans le kernel "officiel" Big Grin

Sinon c'est clair que pour une infra critique c'est pas top (je l'ai jamais nié :þ) du fait justement que ça partage le même kernel Wink (et donc les 0day liées au kernel justement). Néanmoins ça me semble être une meilleure alternative qu'OpenVZ qui est à peu près la même chose sauf que c'est des patchs appliqué sur un kernel vieillissant (2.6.32 de mémoire) et maintenu par les développeurs d'OpenVZ exit donc systemd et les distributions l'utilisant :').

Bref ce type de VM sert surtout pour le "cloud" et la facilité de déploiment (ton image de l'OS est la même partout donc pas de risques de mauvaises surprises avec la libmachin qui dépend de la libtruc mais à une version supérieure que celle fournie par la distrib, etc...) j'ai l'impression, ou de labo pour tester un truc à l'arrache sur une distribution.

Après si on tient vraiment à faire un système critique avec du container léger, faut réduire au minimum les modules kernel chargés, voire même inclure les modules directement dans le noyau et virer les modules chargeables du kernel.

Edit: j'en profite pour rappeler une règle élémentaire: toujours faire les mises à jour très régulièrement pour être l'abri des failles découvertes et patchées
Mon blog

Code :
push esp ; dec eax ; inc ebp ; and [edi+0x41],al ; dec ebp ; inc ebp

"VIM est merveilleux" © supersnail
+1 (0) -1 (0) Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)
N-PN
Accueil | Challenges | Tutoriels | Téléchargements | Forum | Retourner en haut