Aller au contenu | Aller au menu | Aller à la recherche
lundi, mai 7 2018
Par Vanhu le lundi, mai 7 2018, 11:36 - Vieux con de hacker old school.....
Aujourd'hui, on va mettre en place un annuaire LDAP, un FusionDirectory en façade pour administrer le contenu du LDAP via une jolie interface Web, on va connecter un serveur mail (SMTP+IMAP+POP), une machine cliente réseau (via PAM) et quelques autres trucs, et on va coller du SSL partout.
mercredi, avril 4 2018
Par Vanhu le mercredi, avril 4 2018, 19:15 - Vieux con de hacker old school.....
Comme pour à peu près n'importe quel billet de la catégorie "Vieux con de hacker old school", ce billet parle de trucs techniques. J'ai glissé des liens ici et là pour que ma sœur puisse presque suivre les très grandes lignes (les autres personnes peuvent aussi cliquer, je suis de bonne humeur aujourd'hui), mais je n'expliquerai pas la plupart des concepts en détails.
Comme pour à peu près n'importe quel billet de la catégorie "Vieux con de hacker old school", tout ceci a été fait par un Vieux con de hacker old school (ah mais c'est donc ça l'explication du nom de la catégorie !!!!!!), dans des conditions de sécurité optimales, sur des machines consentantes, avec un vrai réseau de prod fonctionnel à coté pendant tout le temps de la préparation pour pouvoir aller buller sur facebook chercher les infos au fur et à mesure des problèmes qui se sont posés.
Comme pour à peu près n'importe quel billet de la catégorie "Vieux con de hacker old school", il n'y aura aucune photo de chaton dans ce billet. Il n'y aura d'ailleurs probablement pas du tout de photo, image ou tout autre truc du genre.......
Comme pour à peu près n'importe quel billet de la catégorie "Vieux con de hacker old school", libre à vous de suivre les indications de ce billet pour reproduire la même chose chez vous, je n'essaierai même plus de vous en dissuader, mais ne venez pas vous plaindre en cas de désagrément plus ou moins douloureux pour vos données, voire pour votre intégrité physique (et je ne veux pas savoir comment c'est arrivé dans ce cas !).
Comme pour à peu près n'importe quel billet de la catégorie "Vieux con de hacker old school", il y a très peu de chances pour que le contenu de ce billet vous aide d'une quelconque façon à pecho en boite.......
Comme pour n'importe quel billet de la catégorie "Vieux con de hacker old school", aucun animal mignon n'a été blessé, tué ou mangé pendant la réalisation des opérations.
Jusqu'à présent, j'avais toujours séparé mon NAS et mon hyperviseur Xen. Du coup, d'un coté, j'avais un serveur avec de gros disques (pour l'époque) en RAID miroir dédiés au stockage de mes photos données et peu d'autres contraintes, à coté un autre serveur (aussi avec des disques en RAID miroir, mais nettement plus petits) qui faisait tourner plusieurs machines virtuelles. Les problématiques étaient donc distinctes.
Mais j'ai entre temps récupéré (gratos, du coup ca serait dommage de se priver) un serveur un peu ancien mais cependant tout à fait apte à gérer l'ensemble:
Du coup, même mon NAS va passer en machine virtuelle (après quelques mesures de performances disques qui confirment que les débits depuis une VM sont quasi identiques à ceux depuis le Dom0), et mes anciennes stratégies d'utilisation des disques deviennent difficilement applicables....
En plus, je me retrouve à utiliser de très gros disques (8To) sur un serveur dont le BIOS est un peu ancien, ce qui m'a posé quelques petits problèmes supplémentaires.
Une des questions existentielles qu'on se pose quand on déploie de nouveaux serveurs, c'est le partitionnement des disques.....
Jusqu'à présent, j'avais toujours utilisé des partitionnements assez classiques: un MBR, une partition principale pour le système de base, et une partition étendue qui contient le reste, dont un /usr en lecture seule avec de la marge pour d'éventuelles installations ultérieures d'outils/services/etc...., très souvent un /var séparé, un /tmp soit en RAMFS soit en partition séparée également, et un /home qui occupe tout le reste.
Sur un NAS dédié, ca fonctionne assez bien (on perd quelques Go sur quelques To, pas bien grave.....).
Sur mon ancien serveur de VMs, ca fonctionnait assez bien aussi, vu que toutes les VMs avaient leurs disques stockés en fichiers dans le /home.
Sur mon nouveau précieux serveur unique, c'est plus compliqué. Si j'avais décidé de laisser le /home géré par le Dom0, j'aurais pu rester plus ou moins sur ce modèle, mon /home gigantesque aurait stocké mes données ET les images de mes VMs. Sauf que, pour faire propre, l'hyperviseur ne fera vraiment pratiquement QUE hyperviser (il fera aussi ce qu'il est vraiment le seul à pouvoir faire, comme surveiller les disques, la température, et tant qu'à faire l'onduleur), donc le NAS sera assuré par une VM. Donc le gros /home de plusieurs To ne sera pas directement accessible par l'hyperviseur.
En vrai, là, j'aurais pu faire un truc un peu dégueulasse, genre un /home gigantesque sur le Dom0, et dedans une image presque aussi gigantesque utilisée par la VM qui fera le NAS....... Sauf que je veux un NAS qui dépote, et c'est vraiment une très très mauvaise base pour avoir de bonnes performances disques par la suite ! Accessoirement, j'aurais aussi eu la question de la taille de l'image: trop et je n'ai plus assez de place pour d'autres usages, pas assez et un jour je déborde sur cette partition (même si à priori, j'ai de la marge cette fois ci, mais je croyais déjà que c'était le cas sur les anciens disques de 2To.......).
Du coup, premier élément de solution: je vais (enfin ?) me mettre à utiliser Logical Volume Management, LVM pour les intimes (et on va rapidement devenir assez intimes.....). Dans mon cas, la possibilité d'ajouter des disques/partitions plus tard ne m'intéresse pas vraiment: j'ai déjà de la marge (enfin, pour l'instant), et surtout, parmi les rares contraintes de mon prochain serveur, je n'ai que 2 emplacements propres pour disques durs 3 1/2, qui seront donc d'entrée de jeu utilisés (par mes 2 disques de 8To en RAID miroir, pour les 2 du fond qui ne suivent pas.....).
Ce qui m'intéresse vraiment, c'est avant tout de pouvoir créer un volume logique ("logical volume", que nous appellerons simplement "lv" par la suite, ou "lvs" quand il y en aura plusieurs) avec une quantité d'espace allouée, et de pouvoir augmenter cet espace plus tard. Du coup, je n'alloue pas tout pour l'instant, et je pourrai rajouter un peu au fur et à mesure, là où ça sera nécessaire. Notez que, techniquement parlant, LVM permet aussi de faire l'inverse (réduire la taille d'un lv, et du système de fichiers dedans), mais c'est quand même plus ou moins déconseillé par plein de monde de faire dans ce sens......
Je suis un peu tenté aussi par d'autres fonctionnalités de LVM, comme la possibilité d'utiliser un disque SSD en cache pour le gros lv du /home, ou le fait de pouvoir faire des clichés (que nous appellerons "snaps" par la suite).
Mon plan de partitionnement se simplifie sacrément d'un coup: une énoooooorme partition entièrement dédiée à LVM, et je crée au fur et à mesure de mes besoins de petits lvs, pour le Dom0 comme pour les VMs. Bon, parmi ces "petits lvs", il y en aura un de plusieurs To dès le départ, mais l'idée reste la même, et à la fin de l'installation initiale, il y aura au moins 1 ou 2 TOs non alloués.
Il reste donc juste à organiser le partitionnement de chaque système.....
Le plus simple serait d'avoir une partition par système. Cette approche présente historiquement le gros avantage de ne pas trop se poser de questions de répartition d'espace entre les partitions, mais j'ai donc désormais LVM pour ne plus être coincé de ce coté là. En contrepartie, cette approche présente également au moins 2 problèmes potentiels:
Un /var/log ou un /tmp qui se remplissent trop peuvent saturer tout l'espace disque. Un /home aussi, mais dans mon cas, il est déjà fourni à part.
Comme les mêmes /var, /tmp et /home doivent être en lecture/écriture, tout le système doit l'être aussi. Or, avoir une partie de son système en lecture seule présente des avantages: réduction des risques d'erreurs de manipulation, (un peu) plus difficile pour un attaquant de poser durablement un rootkit ou équivalent, peu/pas de risques de casser le système de fichiers même en cas d'arrêt brutal du serveur. Bien sur, pour les opérations de maintenance (mises à jour, etc.....) on peut/doit repasser temporairement le système de fichiers en lecture/écriture.
Bref, je veux partitionner, et avoir une partie de mon système en lecture seule..... Dans un premier temps, du coup, j'ai envisagé de faire plein de partitions par système, comme d'habitude, dont /usr en lecture seule..... pour le Dom0, pas trop de problèmes, mais pour les VMs, c'est plus lourd: soit je crée un seul lv au niveau du Dom0, et je fais du LVM dans du LVM (le 2eme niveau étant géré au niveau de la VM), niveau perfs ca semble ne pas changer grand chose, mais le redimensionnement des lvs devient plus lourd. Soit je crée plein de lvs au niveau du Dom0, je passe tout ca à la VM, ca fait un fichier de conf Xen un peu compliqué, mais surtout ça va me compliquer la vie le jour où je voudrai faire des snaps de mes VMs !
Donc j'ai fait un état des lieux par répertoire. Je ne tiens pas compte des répertoires particuliers (/sys, /run, /dev, etc...... mais pas /etc !) qui sont de toutes façons gérés dynamiquement.
En gros, /var, /tmp, /root et /home doivent être en lecture/écriture. /root et /home contiendront très peu de données dans mon cas (un .bashrc, un .ssh/authorizedkeys et peut être 2-3 trucs temporaires de temps en temps). A vrai dire, une fois l'installation initiale d'un système terminée, le seul intérêt pour moi de les avoir dans la catégorie "lecture/écriture", c'est pour pouvoir enregistrer le .bashhistory........ du coup, j'ai une solution simple à base de liens symboliques pour regrouper ces répertoires dans un seul système de fichiers:
/var /home -> var/home /root -> var/root /tmp -> var/tmp (ou en tmpfs)
Notez les liens relatifs (il n'y a pas de '/' au début), qui éviteront de mauvaises surprises si je me retrouve à monter les partitions en dehors de leur contexte normal.....
Selon le service fourni par les VMs, je voudrai éventuellement un /srv dédié, dans lequel j'irai stocker sites webs, base LDAP, base SQL, etc....
Idéalement, tout le reste devrait être en lecture seule, dont en particulier:
/ /bin /sbin /etc /usr /lib /boot
En plus, tout ce reste en question représente assez bien le système (l'ensemble des programmes et de la configuration) pour une bonne partie de mes serveurs (hyperviseur inclus), et je serai bien content de pouvoir en faire un snap unique avant une grosse mise à jour des paquets.
Je me retrouve donc avec 3 voire 4 partitions par système (en comptant la partition SWAP), avec un découpage logique tout à fait cohérent pour faire des snaps: root, var, swap et srv.
Il reste juste un petit détail à régler...........
Bah oui, un système avec /usr en lecture seule, c'est un peu trop facile, mais avec carrément / en lecture seule, on a un peu plus de trucs à gérer......
Premier point, /root, /var, /home et /tmp. On a déjà réglé ce problème par un /var dédié en lecture/écriture qui contient tout le reste et des liens symbolique depuis la racine.
Le second gros problème, c'est une partie du contenu de /etc. Et il y a déjà une page debian qui regroupe les questions relatives à un système avec / en lecture seule !
A partir de cette liste, que je pense être basée sur des versions plus anciennes de Debian, on peut déjà faire un peu de tri: la plupart des fichiers de configuration problématiques ne seront pas utilisés sur mes serveurs, d'autres sont déjà des liens tels qu'indiqués sur cette page, et une autre partie ne sont pas présents sur mes installations. Voyons ce qu'il reste:
Sur la plupart de mes serveurs, il n'y aura pas d'IMAP. Sur le serveur de mail, la configuration sera normalement gérée via LDAP, donc pas besoin d'aller triturer dans /etc.
Les guests n'utiliseront pas eux même LVM, comme nous allons le voir un peu après. Pour le Dom0, il faudra remonter temporairement / en lecture/écriture pour certaines opérations LVM.
A tester !
Mes serveurs auront une configuration DNS statique, donc un resolv.conf qui ne bougera pas, tout va bien.
Une fois les systèmes installés, soit les authentifications se feront via LDAP, soit les serveurs auront une configuration très très minimaliste de ce coté là (un compte d'administrateur qui se connecte en SSH par certificats puis qui passe en root), donc les rares changements de mots de passes nécessiteront de remonter temporairement / en lecture/écriture.
Les fichiers indiqués sur la page Debian ne sont plus générés sur Stretch, donc pas de problèmes.
Premier essai sur une VM sur l'ancien hyperviseur (quand je vous dit que tout est fait dans des conditions de sécurité optimales !). Après l'installation (partitions /, /var et swap), on déplace les répertoires nécessaires:
cd / mv root /var/ && ln -s var/root mv home /var/ && ln -s var/home rm -rf /tmp && ln -s var/tmp # /var/tmp existe déjà et doit avoir les mêmes permissions que /tmp
Notez l'absence de "/" pour le ln, comme je l'avais indiqué plus haut. Notez aussi que le "/" final après var pour les mv ne sert pas vraiment, c'est pour bien illustrer le fait qu'on déplace bien les répertoires à l'intérieur de /var.
Ensuite, on édite /etc/fstab:
UUID=[uuid de votre partition ROOT] / ext4 errors=remount-ro 0 1
devient:
UUID=[uuid de votre partition ROOT] / ext4 defaults,ro,noatime 0 1
(je ne suis pas certain que le "noatime" soit vraiment nécessaire)
Reboot, et ......... ça fonctionne ! Limite un peu trop facile, en fait........
Bien sur, pour se simplifier un peu la vie, l'édition de fstab aura lieu quand le système est complètement installé et configuré.
Pour ne pas avoir à faire les manips à la main à chaque installation / mise à jour par apt, on va aller configurer un remontage à la volée, en créant /etc/apt/apt.conf.d/00RWRoot:
DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NOAPTREMOUNT:-no} = yes || mount -o remount,ro / || true"; };
};
Pour savoir d'un coup d'oeil si on a un / en lecture ou en écriture, il suffit de se créer un prompt sympa dans son .bash_profile:
function prompter(){
if [ -z "$(findmnt / |egrep 'ext4\s+rw')" ];then
# Read only
PS1='\[\033[01;36m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='\[\033[01;31m\]\u@\[\033[01;36m\]\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
fi
}
export PROMPT_COMMAND=prompter
J'ai mis un peu de temps à trouver un test fiable pour déterminer si / est en lecture ou lecture/écriture (les tests simples à base de "grep ro" ne fonctionnent pas dans tous les cas). Je ne peux pas garantir que ce test là fonctionne en permanence, on pourrait l'améliorer en vérifiant qu'on a bien soit "ro" soit "rw" (et gérer un 3eme état "sais pas").
Ah, et la notion de joli est subjective, l'important, c'est le principe de prompt dynamique et la technique pour détecter un / en ro ou rw.......
Pour le Dom0, on en restera là, mais pour les VMs, j'aurais aimé pouvoir vraiment bloquer les accès en écriture au niveau de l'hyperviseur, et les débloquer juste quand j'en ai besoin. Une solution simple consiste à déclarer la partition en lecture seule dans la configuration Xen de la VM, sauf que du coup, "débloquer les accès en écriture" implique de rebooter la VM (je n'ai pas trouvé de commande xl pour faire le changement à la volée).
J'ai également trouvé une option "-p r" / "-p rw" de lvchange, qui permet de changer les permissions du lv. Après quelques essais rapides, je constate bien le changement dans lvdisplay, mais ma VM peut toujours écrire sur le lv (et le changement est bien enregistré). Soit il y a un bug, soit les permissions en question sont autre chose (j'ai trouvé très très peu de documentation sur ce point).
Au passage, si j'en étais resté avec des fichiers pour mes disques de VMs, j'aurais peut être pu facilement faire un chmod........
LVM permet une autre possibilité intéressante: avoir une partition de référence (le master), et faire fonctionner la VM sur un snap (un dérivé, dans ce cas). Aucun changement sur le snap n'est durable: il suffit de re-générer le snap à partir du master. Redoutable pour nettoyer un serveur compromis, temps de maintenance record (tout peut être préparé en amont, d'un point de vue de la machine de production, c'est juste un reboot), mais assez complexe à gérer au quotidien. Les mises à jour doivent être faites sur le master (soit en démarrant une autre copie de la VM, soit directement depuis le Dom0 à coup de chroot, par exemple), et j'ai déjà vu passer des mises à jour qui font des manipulations sur les données (base de données, etc.....), ce qui complique le suivi.
Bref, l'idée est jolie, je ferai probablement un test un jour sur un serveur secondaire (ou un serveur critique et super statique), mais pour l'instant, je laisse l'idée de coté.
Le plan de bataille est prêt, il ne reste plus qu'à l'appliquer, à commencer par le Dom0.
Comme je l'avais évoqué au dessus, le BIOS de mon serveur est un peu ancien. Il ne sait donc pas du tout ce que veut dire EFI ou GPT, et c'est déjà bien qu'il détecte mes disques ..... sauf qu'il est à peu près convaincu qu'ils font environ 1.4To chacun.......
Comme le noyau Linux va rapidement lui même tout re-détecter sans se préoccuper du BIOS, y compris les disques (avec leur bonne capacité !), j'ai donc juste besoin que le BIOS réussisse à faire démarrer le noyau. Ma première idée a donc été de réviser légèrement mon plan de partitionnement, avec un petit /boot en début de disque.
Après avoir perdu pas mal de temps à essayer de faire installer GRUB2, j'ai finalement réalisé que l'installeur Debian m'avait créé des tables de partition GPT sur mes disques (alors qu'il m'avait juste demandé si je voulais des tables de partitions, oui/non). Pour que GRUB puisse s'installer sur des disques avec de telles tables, vous devez commencer par créer, au début de chaque disque concerné (les 2 dans mon cas, donc), une petite partition (la littérature sur le net parle de 1Mo comme étant déjà confortable, j'en ai mis 2 pour être installé en VIP.....) de type "BIOS Boot Partition" (disponible dans la liste des types de partitions durant l'installation). Cette partition n'est pas en RAID miroir: GRUB n'ira pratiquement jamais la modifier (il y a juste une partie du code de GRUB, pas de configuration), et si jamais il le fait, nous allons de toutes façons lui indiquer par la suite qu'il doit s'installer sur les 2 disques.
Avec cette petite diversion, j'en ai un peu oublié de créer mon /boot dédié, et je m'en suis rendu compte assez tard dans l'avancement du nouveau serveur.....
En pratique, mon installation démarre. D'après lvdisplay -m, ma partition dom0root est physiquement au début du disque et devrait y rester, en tout cas tant que je ne l'étends pas, donc l'image du noyau et de l'initrd devraient rester accessibles (tant que je n'étends pas dom0root, donc.......). Comme j'ai quand même pris un peu de marge sur la taille de cette partition et que je prévois vraiment de ne pas avoir grand chose du tout d'installé directement sur l'hyperviseur, je prends le risque de rester avec ce découpage. Si ça se trouve, GRUB est peut être assez intelligent pour savoir adresser l'ensemble des disques durs, même s'ils ont mal été détectés par le BIOS..... Si vous vous retrouvez vous aussi à jouer avec des disques partiellement reconnus par votre BIOS...... faites un /boot dédié !
Ce petit problème étant résolu, voici le résumé de ce qu'il faut faire pour préparer ses disques dans l'installeur Debian:
Et c'est parti pour ...... environ 10h de synchro du miroir dans mon cas !
Avec lvm, on peut faire plus subtil: créer un premier md relativement petit (20Go suffisent très très largement pour une install minimaliste d'une Debian serveur), qui va se synchroniser très rapidement durant l'installation (alors que la synchro du mien a plombé très sévèrement la vitesse d'installation de base du système !), et plus tard, à un moment tranquille, on crée un ou plusieurs autres gros md qu'on ajoute à vg0..... En utilisant cette technique, on pourrait aussi forcer dom0_root à être dans md0, qui est au début du disque, ce qui serait une autre façon de s'assurer que l'image du noyau restera dans la partie du disque accessible via le BIOS.
Quitte à détailler l'installation, petit rappel express pour transformer une "install Debian" en "install Debian Dom0":
apt install xen-system-amd64 dpkg-divert --divert /etc/grub.d/08linuxxen --rename /etc/grub.d/20linuxxen
Edition de /etc/default/grub (dans l'exemple, je lui réserve 2Go de RAM, vous ajusterez selon votre cas, j'ai le vague souvenir qu'il ne faut pas lui mettre trop peu):
GRUBCMDLINEXEN="dom0_mem=2048M,max:2048M"
/etc/xen/xend-config.sxp
(dom0-min-mem 2048) (enable-dom0-ballooning no)
Ces 2 changements disent en gros que le Dom0 aura 2Go de mémoire dédiée pour lui, mais qu'il ne touche pas au reste, c'est pour les potes....
On applique les changements de la configuration de grub:
update-grub
Un petit reboot et on est bon !
lvcreate -n guest1_root -L 2G vg0 /dev/md0 lvcreate -n guest1_var -L 2G vg0 /dev/md0 lvcreate -n guest1_swap -L 1G vg0 /dev/md0
A la fin de la ligne, /dev/md1 sert à s'assurer que ces LVs seront bien sur md0 (chez moi, c'est md0, chez vous, ca sera donc peut être md1, voire autre chose), même si plus tard on rajoute d'autres disques, partitions RAID ou je ne sais quoi d'autre.
L'option -n permet d'indiquer le nom du lv.
L'option -L permet de spécifier la taille, ici 2Go pour les partitions root et var (ce qui sera largement suffisant pour la plupart de mes installs serveurs, et il sera toujours temps d'agrandir les lv plus tard si besoin), et 1Go pour le swap.
Et vg0 pour indiquer le vg sur lequel on souhaite créer tout ça (oui, on pourrait avoir plusieurs vgs, et même que ça pourrait être pertinent dans certains cas).
Le fichier de conf Xen de la VM va donc contenir (j'ai viré ce qui ne concerne pas directement les disques):
boot = "pygrub"
# Uniquement pour le boot d'install depuis l'ISO
bootloader_args = [
"--kernel=/install.amd/xen/vmlinuz",
"--ramdisk=/install.amd/xen/initrd.gz"
]
disk = [
# uniquement pour l'install
'file:/home/Xen/debian-9.3.0-amd64-netinst.iso,hdc:cdrom,r',
'phy:/dev/vg0/guest1_root,xvda1,rw',
'phy:/dev/vg0/guest1_var,xvda2,rw',
'phy:/dev/vg0/guest1_swap,xvda3,rw',
]
Et ca ne fonctionne pas: l'installer Debian voit bien qu'il s'agit de partitions, mais ne comprend pas leur type, et veut désespérément leur générer un MBR comme s'il s'agissait de disques....
Il faut donc d'abord créer les filesystem depuis le dom0:
mkfs.ext4 /dev/vg0/guest1_root mkfs.ext4 /dev/vg0/guest1_var mkswap /dev/vg0/guest1_swap
puis recommencer l'installation (ou me croire sur parole, et exécuter ces commandes avant la première installation.......).
Avec cette configuration, grub ne s'installe pas. A vrai dire, ce n'est pas très grave, vu qu'il n'est pas directement utilisé (c'est pygrub qui fait le boulot depuis le Dom0). J'ai trouvé chez Debian une solution, qui consiste à créer le fichier /boot/grub/menu.lst suivant dans la VM:
default 0 timeout 0 title Debian GNU/Linux root (hd0,0) kernel /vmlinuz root=/dev/xvda1 ro initrd /initrd.img
Soit vous montez la partition depuis le Dom0 après l'installation, soit, à la fin de l'installation, vous le créez dans un shell:
mkdir /target/boot/grub cat >/target/boot/grub/menu.lst
(et vous faites un copier/coller du fichier juste au dessus).
Comme le but est de filer les infos à pygrub, on peut aussi s'en sortir avec les paramètres root et bootloader_args du fichier de configuration de la VM:
bootloader_args = [ "--kernel=/vmlinuz", "--ramdisk=/initrd.img" ] root = '/dev/xvda1 ro'
Pour ma VM de firewall, la méthode décrite au dessus ne fonctionne pas: je dispose d'une image de VM au format OVA toute prête, et je ne peux pas faire ce que je veux au niveau des partitions, donc je vais utiliser un lv pour stocker directement cette image:
root@dom0:~ $ tar xf firewall.ova root@dom0:~ $ ls *.vmdk firewall.vmdk root@dom0:~ $ qemu-img convert -O raw firewall.vmdk firewall.img root@dom0:~ $ qemu-img info firewall.img image: firewall.img file format: raw virtual size: 10G (10738466816 bytes) disk size: 843M
Nous disposons maintenant d'une image RAW de la VM (bien sur, selon votre format d'origine, vous adapterez les premières étapes), et de sa taille exacte à l'octet près. Il ne reste plus qu'à créer un lv de cette taille (notez bien le b
à la fin de la taille, par défaut lvcreate considère une autre unité) et à copier l'image:
root@dom0:~ $ lvcreate -n firewall_root -L10738466816b /dev/vg0 root@dom0:~ $ dd if=firewall.img of=/dev/vg0/firewall_root bs=1M
Et voilà !
Ca fait pas mal de temps que je n'ai pas eu besoin de remplacer un disque (mais j'ai déjà eu plusieurs fois à le faire depuis que je stocke mes données en RAID1.....), du coup, pour l'instant, je consigne ici ce que j'ai trouvé comme infos sur le net.
Première chose à faire, repérer le disque qui pose problème:
root@dom0:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[0]
7813892096 blocks super 1.2 [2/1] [U_]
bitmap: 0/59 pages [0KB], 65536KB chunk
Dans ce cas, c'est sda qui serait défaillant, nous partirons de ce principe pour tout le reste de l'exemple.
Maintenant qu'on connaît le disque fautif, nous allons confirmer à mdadm qu'il doit le considérer comme tel:
root@dom0:~$ mdadm --manage /dev/md0 --fail /dev/sda2
Dans mon cas, je n'ai que md0, et il est constitué de sda2 et sdb2. Si vous avez plusieurs md qui utilisent le disque défectueux, l'opération est à recommencer pour chaque partition. Les opérations suivantes aussi.....
Il est maintenant possible de l'enlever du RAID:
root@dom0:~$ mdadm --manage /dev/md0 --remove /dev/sda2
Une fois le disque complètement sorti du RAID, vous pouvez éteindre le serveur, remplacer le disque par un nouveau, et redémarrer (si votre configuration est bonne, vous saurez booter sur le disque encore actif du RAID, ce qui nécessitera peut être quelques manips au niveau du BIOS/EFI dans le cas où c'est justement sda qui a laché).
Commencez par vérifier que vos disques ont toujours les mêmes noms ! Il semblerait que, dans certains cas, votre ancien sdb puisse être votre nouveau sda, et ca serait vraiment vraiment une mauvaise idée d'appliquer les manipulations ci après à l'envers !! Supposons cependant que l'ancien sdb soit toujours sdb, et que le disque tout neuf ait pris le nom de celui qu'il remplace: sda.
Première étape, il faut partitionner le nouveau disque. Plusieurs options sont possibles, y compris une construction manuelle de la table des partitions, mais si votre nouveau disque fait exactement la même taille que l'ancien, le plus rapide est de faire:
root@dom0:~$ sfdisk -d /dev/sdb | sfdisk /dev/sda
Nous pouvons maintenant ajouter la nouvelle partition au RAID1:
root@dom0:~$ mdadm --manage /dev/md0 --add /dev/sda2
A partir d ce moment, vous pouvez aller vérifier que le md a commencé à se synchroniser en faisant un cat /proc/mdstat. Et vous pouvez du coup aussi vous installer pour quelques heures d'angoisse, en attendant que la synchro soit finie (donc que toutes vos données soient à nouveau à l'abri sur 2 disques......).
Et il faudra aussi installer Grub sur le nouveau disque. A priori, ca devrait se faire via la commande suivante:
root@dom0:~$ grub-install /dev/sda
J'espère qu'il se passera plusieurs années avant que je ne puisse venir éditer ce billet et confirmer que cette séquence fonctionne.........
Déjà, on va vérifier qu'il reste de la place dans le vg:
root@dom0:~$ vgdisplay /dev/vg0
[.......]
Free PE / Size xxxxx / Place libre
Ok, disons qu'il reste de la place, ajoutons donc 2Go sur la partition root de guest1:
root@dom0:~$ xl shutdown guest1 Shutting down domain X Waiting for 1 domains Domain X has been shut down, reason code 0 root@dom0:~$ lvresize -r -L +2G /dev/vg0/guest1_root [.......] root@dom0:~$ xl create /etc/xen/guest/guest1.xl
Et ...... c'est ....... tout !!!!! (c'est le -r qui dit à lvresize de faire faire dans la foulée le boulot de redimensionnement du filesystem en dessous). Enfin, presque: si vous avez le / de votre dom0 en lecture seule, il faut le repasser en lecture/écriture pour le lvresize, ce qui donne au final les commandes suivantes:
root@dom0:~$ xl shutdown -w guest1 && mount -o remount -w / && lvresize -r -L +2G /dev/vg0/guest1_root && mount -o remount -r / && xl create /etc/xen/guest/guest1.xl
Avec une bonne politique de nommage des volumes logiques, ca doit même pouvoir se scripter très facilement, en fait....... d'un autre coté, si le script est rentable, c'est que vous passez votre temps à redimensionner vos partitions, et vous pouvez vous poser d'autres questions, dans ce cas !
Un snapshot LVM ne fait pas une véritable copie complète du lv d'origine: il retient son état au moment du snapshot, puis va uniquement stocker les changements (enfin, les anciennes versions avant changement, pour être précis). Nous allons donc allouer au snapshot une taille nettement inférieure à celle du volume d'origine s'il s'agit juste de faire une sauvegarde avant un changement de configuration un peu risqué. Par contre, s'il s'agit d'une sauvegarde juste avant une très très grosse mise à jour de version, par exemple, il faudra prévoir une taille assez conséquente pour le snapshot !
Créons donc un snapshot d'1Go de la partition root de guest1 (la VM est éteinte depuis quelques secondes, je ne sais pas trop s'il est possible/fiable de faire un snap d'une VM en cours de fonctionnement):
root@dom0:~$ lvcreate -L1G -s -n guest1_root_snap1 /dev/vg0/guest1_root
Et voilà..... l'opération ne prend que quelques secondes, on peut redémarrer guest1 de suite.
Si vous voulez faire une bonne vieille sauvegarde à l'ancienne de votre partition, dans un bon vieux fichier que vous pouvez stocker ailleurs, vous pouvez le faire sur le snap pendant que la VM a été redémarrée:
root@dom0:~$ dd if=/dev/vg0/guest1_root_snap1 bs=1M | bzip2 -9 > guest1_root_save.raw.bz2
Ce fichier sera restaurable sur le lv d'origine (VM stoppée) avec la commande suivante:
root@dom0:~$ bunzip2 -c guest1_root_save.raw.bz2 | dd of=/dev/vg0/guest1_root bs=1M
Dans les 2 cas, vous pouvez jouer avec l'option bs de dd (block size), d'autres valeurs pourraient vous permettre de gagner pas mal de temps sur l'opération (ou d'en perdre pas mal.....).
Quand votre snapshot ne sert plus à rien, il est détruit comme n'importe quel autre lv:
root@dom0:~$ lvremove /dev/vg0/guest1_root_snap1
Si par contre vous avez bien fait de faire un snap et que vous avez besoin de le restaurer, l'opération est un peu plus longue, et se fait via la commande suivante (avec la VM stoppée):
root@dom0:~$ lvconvert --merge /dev/vg0/guest1_root_snap1
Inévitablement, j'ai fait des choix à certains moments. Quelques uns méritent un peu plus d'explications.
Au début, on m'avait proposé l'idée de faire une partition LVM au niveau de l'hyperviseur pour chaque guest, et de considérer au niveau du guest cet ensemble comme un disque, donc de faire des partitions dessus, et tant qu'à faire en LVM aussi. Le fait d'empiler 2 niveaux de LVM semblait ne pas poser de gros problèmes de performances, mais c'est quand j'ai regardé comment étendre les partitions des VMs que j'ai décidé de renoncer à cette solution. En gros, il fallait étendre le lv coté hyperviseur (jusque là, ca me parait prévisible......), démarrer la VM, créer une partition sur l'espace supplémentaire désormais disponible, rajouter cette partition au vg du guest, et seulement après on pouvait à nouveau faire un lvextend au niveau du guest...... Pour les éventuelles réductions de taille de partition, même si ca ne devrait pas m'arriver en pratique, je n'ai même pas osé trop réfléchir à la séquence de trucs à faire !
Sur ce point, il semble cependant y avoir une alternative qui réduit un peu les manipulations: au niveau de la VM, ne pas faire de partition, mais embarquer l'ensemble du disque comme un PV, ce qui permettrait semble-t-il de redimensionner directement le vg dessus avec un pvresize après avoir étendu le lv au niveau du Dom0 (si vous avez compris cette phrase du premier coup, ne prenez pas le volant !). Notez que je n'ai pas testé, et qu'il s'agit donc d'une solution théorique à ma connaissance.
Dans tous les cas, ca m'aurait aussi un peu compliqué la vie au moment de faire des snaps: soit j'aurais du faire des snaps complets des VMs (root + var + swap + srv) au niveau de l'hyperviseur, soit ...... euh ..... j'aurais du réfléchir à comment balancer de l'espace en plus à la VM pour qu'elle fasse elle même son snap.
Plusieurs tutoriels font de la création de VMs avec xen-tools. Vu que je ne prévois pas de faire régulièrement de création de nouvelles VMs, je n'ai pas trop cherché à utiliser cette solution.
Il est également possible de créer une VM Debian sans la démarrer via debootstrap. Un peu comme pour les xen-tools, j'ai été plus vite à court terme en créant mes VMs en mode "classique", mais je m'intéresserai clairement à cette possibilité si je me rends compte que j'ai à fabriquer plus ou moins régulièrement de nouvelles VMs à l'avenir.
LVM supporte (depuis peu ?) le principe de thin provisioning. En gros, c'est la même idée que le surbooking, mais pour l'espace disque..... Je suppose que c'est assez pratique dans certains cas, mais dans le mien, je n'aime pas trop l'idée de vivre à crédit sur mon espace disque, surtout que je n'en ai pas besoin.
LVM gère depuis pas mal de temps une option "mirror". Pour le peu que j'en ai lu sur le net, l'objectif de ces mirrors est différent, et nettement moins pertinent que mdadm pour gérer un RAID1 de disques.
Depuis beaucoup moins de temps, LVM gère également un mode RAID1 (entre autres), qui semble lui très très proche d'un point de vue fonctionnel du RAID1 avec mdadm. J'ai repéré cette possibilité alors que j'avais déjà pas mal avancé sur mon installation, et le coté un peu nouveau de la solution a aussi contribué à ce que je laisse cette idée de coté.
Pour une version ultérieure, la question se posera peut être, mais j'avoue que pour l'instant, j'aime bien l'idée d'avoir rapidement une vue purement RAID d'un coté, et une gestion d'un seul "truc" (le md0) de l'autre.
Pour le NAS, à un moment, je me suis posé la question d'utiliser FreeNAS, son fork Nas4Free ou une autre distrib dédiée. Au début, je n'avais pas mes 48Go de RAM, donc j'avais laissé tomber.
En plus, dans mon cas d'usage, les avantages de ZFS ne sont pas flagrants, mon install de VM NFS finale est vraiment réduite au strict nécessaire, et je n'ai pas creusé l'empilage LVM/ZFS.
Là, on sort des problématiques d'organisation de disques, mais si ces infos peuvent servir à des gens plus tard (dont potentiellement moi), alors tant mieux !
Par défaut, lors de l'arrêt de l'hyperviseur, le script /etc/init.d/xendomains est appelé, et stoppe les VMs dans l'ordre inverse de leur création. Tant que vos VMs ne rebootent pas, l'idée peut sembler pertinente......
Une solution absolument propre consisterait à connaître un graphe de dépendance des VMs, et à stopper par lots en fonction de ces dépendances. Par exemple:
Bien évidemment, dans ce monde parfait, les dépendances sont listées dans les fichiers de configuration.....
A défaut de ce monde parfait, voyons quelles solutions nous pouvons mettre en place.
L'idée est de disposer de notre propre script, que j'ai dans mon cas placé en tant que /usr/lib/xen-common/bin/xen-list-domains (pensez à lui donner les droits d'exécution, bien sur !).
Nous allons alors détourner l'appel dans xendomains pour qu'il obtienne sa liste (et donc l'ordre) de notre script:
--- /etc/init.d/xendomains.old
+++ /etc/init.d/xendomains
-185,12 +185,12 dostopshutdown()
logactionbegin_msg "Shutting down Xen domain $name ($id)"
xen shutdown $id 2>&1 1>/dev/null
logactionend_msg $?
- done < <(/usr/lib/xen-common/bin/xen-init-list)
+ done < <(/usr/lib/xen-common/bin/xen-list-domains)
while read id name rest; do
logactionbegin_msg "Waiting for Xen domain $name ($id) to shut down"
timeoutdomain "$name" "$XENDOMAINSSTOP_MAXWAIT"
logactionend_msg $?
- done < <(/usr/lib/xen-common/bin/xen-init-list)
+ done < <(/usr/lib/xen-common/bin/xen-list-domains)
}
do_stop()
Nous avons toujours un arrêt en masse des VMs, mais au moins dans l'ordre qui nous arrange..... un xen shutdown -w serait potentiellement dangereux, vu qu'il n'existe apparemment pas d'option pour dire "attends x secondes maximum".
Il ne nous reste plus qu'à voir ce qui est faisable avec xen-list-domains
Ma première tentative a été de mettre l'ordre en tant que nom des VMs: 01-firewall, 55-client, 99-firewall-slave, etc....
Du coup, xen-list-domains est assez simple:
#!/bin/bash
while read name id mem cpu state time ; do
if [ "$name" != "Name" -a "$name" != "Domain-0" ];then
echo "$id $name"
fi
done < <(xl list|sort -r)
Cette approche présente 2 inconvénients:
xen-init-list se comporte un peu différemment pendant le reboot.Du coup, j'ai fait une 2eme tentative en appelant xen-init-list, mais je ne peux plus trier directement via sort (on doit pouvoir le faire via awk ou un truc du genre, mais je ne suis pas expert). Donc je me suis retrouvé à faire mon nouveau xen-list-domains en perl (là, je sais faire). Et quitte à le faire en perl, je peux embarquer les priorités dans le script:
#!/usr/bin/perl
my %vmorder = (
"firewall" => 99,
"firewall-slave" => 0,
"guest1" => 2,
"srvnfs" => 98,
"guest2" => 3,
"srvlan" => 97,
"srvpub" => 80,
"machin" => 40,
);
my %vmreal;
open(LIST, "/usr/lib/xen-common/bin/xen-init-list|");
while($line=<LIST>){
my $order;
my ($id, $name, @rest) = split(/ /, $line);
chomp $name;
if(defined($vmorder{$name})){
$vmreal{$line}=$vmorder{$name};
}else{
$vmreal{$line}=1;
}
}
close(LIST);
foreach (sort { $vmreal{$a} <=> $vmreal{$b} } keys %vmreal) {
print ;
}
Les VMs non connues ont un poids de 1. Une VM qui a un poids de 0 explicite recevra son signal d'arrêt en premier, puis les VMs non connues, puis les autres connues dans l'ordre de poids (donc dans mon cas, 99 sera la dernière à recevoir son signal).
Dans une version ultérieure, je pourrais stocker les priorités ailleurs (dans les fichers de conf des VMs ?), voire les calculer à partir de dépendances. Vu que mes VMs et leurs dépendances sont assez statiques, je n'ai pas passé plus de temps sur cette partie.
En pratique, quand j'ai besoin de redémarrer l'hyperviseur, je préfère stopper manuellement toutes les VMs, et il est important de faire ca dans un screen, tmux, ou toute autre solution qui permettra que les dernières commandes soient effectivement lancées même quand votre terminal se fera couper le ssh sous le cable !
lundi, avril 2 2018
Par Vanhu le lundi, avril 2 2018, 22:16 - Vieux con de hacker old school.....
Il y a une éternité très très longtemps, dans une galaxie très lointaine quelques temps, nous avions vu comment déployer un firewall en VM sous XEN. Aujourd'hui, nous allons faire la même chose, mais en mieux.......
Si vous êtes particulièrement attentifs, vous aurez peut être remarqué que le dernier billet sur ce blog datait d'il y a environ 4 ans (on ne va pas pinailler pour quelques semaines). Et maintenant que je viens de le dire clairement, même si vous avez le niveau d'attention d'un chaton, il faudra au moins quelques bonnes secondes et une baballe qui passe pour vous faire oublier ce fait..... Vous me croyez si vous voulez, mais il semblerait que des gens (je veux dire, de vrais gens, pas seulement des bots) viennent encore sur ce blog de temps en temps. Ne me demandez pas pourquoi, je n'en ai aucune idée, mais les logs sont formels !
Et comme ces billets techniques me servent avant tout de notes pour le jour où je devrai moi même tout refaire en urgence, ca ne change de toutes façons pas grand chose à ma décision de dépoussiérer un peu et faire de nouveaux billets..... et oui, je viens de parler de nouveaux billets au pluriel.......
Ah, et maintenant que je vais cliquer sur "publier", je me dis que, si je l'avais finalisé un poil plus vite, ça aurait pu être une bonne blague !
Ma soeur a beau avoir fait quelques progrès avec son mac (et je parle bien ici d'un ordinateur), ce billet contient quand même plein de morceaux de trucs techniques plus ou moins dégoulinants qui traînent un peu partout (mais a priori, ni OGMs ni aucune trace de noix). En particulier, il est très nettement préférable d'avoir déjà fait un plan à trois avec une Debian et un Xen au moins une fois dans sa vie.....
Si vous êtes expert pour dézinguer tous les aliens au pied de biche sur Xen, c'est très bien, mais ca ne vous sera d'aucune utilité ici.
Comme toujours sur ce blog, les actions décrites ci après ont été réalisées par un Vieux Con de Hacker Old School (tm) professionnel, dans des conditions de sécurité optimales, et avec un safeword pour rebasculer sur l'ancien hyperviseur+firewall en cas de problème.
Et aucun animal mignon n'a été blessé, tué ou mangé pendant l'intervention.
Oui, c'est bon, j'y arrive, on dirait que certains n'ont pas appris la patience avec le temps !!!
L'idée de base reste la même: une machine physique, une Debian qui fait tourner un hyperviseur Xen (d'où les prérequis......), et parmi les VMs, un firewall (dans mon cas, toujours un Stormshield SNS, bien évidemment, mais je suppose que le principe fonctionnera aussi avec des distribs spécialisées comme pfSense ou une autre distrib firewall|) qui doit pouvoir gérer des interfaces physiques comme s'il était un firewall physique avec ces interfaces, ainsi que d'autres interfaces purement virtuelles pour les autres VMs. Un truc dans cette idée là:
(oui, c'est exactement le même schéma que pour le billet précédent, maintenant que vous l'avez remarqué, vous savez où vous pouvez aller lire les explications un peu plus détaillées..........)
Mais en mieux..............
Premier point, tout utilise des versions plus récentes ! En 4-5 ans, vous imaginez ??? Rien que chez Debian, par exemple, bah il y a ....... 2 versions d'écart...... ok, c'est pas forcément le meilleur exemple.......
La version de Xen, par contre, fait un assez grand saut, puisqu'on était à l'époque en 4.1, et que nous allons cette fois-ci utiliser la 4.9 embarquée dans Stretch. Et là on commence à avoir des différences sérieuses: nous allons enfin utiliser le toolstack xl de Xen, et profiter de toutes les améliorations de performances et de support de fonctionnalités qui ont été faites pendant tout ce temps.
Ensuite, j'ai une nouvelle machine physique pour l'hyperviseur. Entre autres, la façade réseau de l'ancienne ressemble à ça:
alors que la façade de la nouvelle ressemble à ça:
Ne vous méprenez pas, ce n'est ici pas la taille qui compte (les 2 photos ne sont pas à la même échelle, déjà....), mais bien le nombre de trous d'interfaces réseau physiques, à savoir 24 sur le nouvel hyperviseur...... et on va vouloir s'en servir (éventuellement avec un peu de mauvaise foi si nécessaire, comme le nombre de RJ 45 réellement branchés sur la photo le laisse deviner......):
(j'expliquerai l'intérêt de chaque configuration au moment de la mettre en œuvre).
Jusqu'à récemment, je n'arrivais pas à démarrer une VM avec plus de 8 interfaces ethernet déclarées au total, et ma VM de firewall n'en gérait pas plus de 10. J'étais donc obligé de gérer toutes ces configurations directement sur l'hyperviseur.
Aujourd'hui, ces 2 limitations semblent avoir disparues, ou au moins avoir été repoussées: j'ai désormais une configuration fonctionnelle avec 20 interfaces pour la VM du firewall.
Cependant, il me parait plus pertinent de gérer les topologies réseau au plus près des connecteurs, tant d'un point de vue performances que pour la simplicité de la configuration: coté hyperviseur, on gère le câblage, et coté firewall on s'occupe du découpage logique du réseau, de la sécurité, etc.... Mais libre à vous de prendre uniquement la version simple de la configuration que nous allons voir, de relier chaque interface au firewall et de gérer les topologies complexes directement sur le firewall.
Eh oui, ce point n'a pas changé en 4 ans, il y a toujours d'autres solutions possibles ! Au delà du fait que, si j'avais choisi d'autres solutions, je me serais quand même retrouvé à écrire ce paragraphe, passons en revue les alternatives qui méritent un peu plus de détails
Pour mon firewall, je ne pouvais pas partir sur les technos de containers logiciels genre LXC ou Docker, il me fallait un vrai hyperviseur. Du coup, Xen fonctionne bien, je connais et j'ai l'habitude, il est officiellement supporté par les VMs SNS, et je n'ai toujours pas trouvé d'autre hyperviseur qui justifie le changement depuis le temps. Pour être tout à fait exact, je n'ai pas plus que ça cherché non plus.......
On pourrait toujours passer les interfaces réseau directement à la VM du firewall, la techno semble plus mature qu'à l'époque. Cela ne permet pas de brancher entre elles des VMs. Dans mon cas, le firewall n'embarque pas les pilotes nécessaires, donc la solution ne fonctionnerait pas. Et le fait de séparer le câblage de la configuration réseau pure me permet d'avoir une vue plus simple coté firewall.
Je n'ai vu ces technologies que très rapidement, elles semblent être des alternatives potentielles pour le cas des interfaces physiques. Pour le peu que j'en ai vu, ce type d'interfaces n'est pas adapté pour raccorder d'autres VMs à la VM du firewall (si tu as des informations pertinentes qui contredisent cette affirmation, ça m'intéresse !).
Cette fois ci, j'ai vraiment essayé OpenVSwitch.... une version intermédiaire de ce billet expliquait même que j'utilisais au final cette solution en production.... et puis je me suis retrouvé à essayer d'avoir des bridges openvswitch fonctionnels et configurés assez tôt au démarrage de mon hyperviseur pour pouvoir démarrer la VM firewall automatiquement...... et je suis revenu aux bridges classiques.....
Du coup, j'ai assez avancé dans mes tests, et il n'y a finalement pas beaucoup de différences au niveau de la configuration:
Dans le billet précédent, je n'avais pas du tout détaillé l'installation de base de l'hyperviseur, ni le fait de déployer une VM classique. Cette fois ci, il y a assez de subtilités techniques dans mon cas pour non seulement expliquer certains aspects de mon déploiement, mais en plus pour les expliquer dans un billet dédié.
Mais si vous avez fait une installation classique en suivant les consignes avec un hyperviseur Xen dessus (pas la peine de suivre toute la partie configuration réseau), c'est bien aussi.
C'est bon ? Ok, nous pouvons donc passer aux choses sérieuses !
Y'a pas, j'ai beau retourner le billet dans tous les sens, on en revient à la configuration réseau à un moment, vu que c'est un peu Ze point technique qui fait que je m'[CENSURE] à rédiger ce billet......
Avec la nouvelle version de Debian, je me retrouve avec des noms d'interfaces modernes, prédictibles et poétiques comme "ens160" ou "enp11s0f1"...... ok, c'est stable même si on joue au bonneteau avec les interfaces réseau, mais pour s'y retrouver quand on est connecté en ssh sur le serveur pour vérifier un truc sur le réseau, c'est ....... enfin, c'est pas ....... disons que je ne suis pas hyper fan.....
Depuis quelques années sur d'autres installations, j'étais habitué à modifier le quasi magique /etc/udev/rules.d/70-persistent-net.rules...... Sauf que sur mon installation toute fraiche de Debian Stretch, il n'existe plus par défaut, le script tout aussi magique /lib/udev/write_net_rules qui est censé le fabriquer n'existe plus non plus, et les explications à propos de fichiers /etc/systemd/network/xx-nom.link ne fonctionnent pas non plus (je n'ai pas trop creusé pourquoi).
La seule solution qui fonctionne dans mon cas a donc été de recréer manuellement un /etc/udev/rules.d/76-netnames.rules (le numéro et le nom doivent venir du nième lien sur lequel j'ai cliqué pendant mes essais et reboots.......):
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ma:ca:dd:re:ss", NAME="ethlan1"
Vous noterez le nom: autant je ne suis donc vraiment pas fan des nommages prédictibles mais pas pratiques du tout, autant nous allons avoir ici pas mal d'interfaces réseau différentes, du coup, quitte à les renommer, autant utiliser des noms qui me permettront par la suite de facilement m'y retrouver, quitte à avoir des noms un peu plus longs. Donc toutes mes interfaces auront un nom du genre "type" "fonction" "numéro optionnel".
Donc là, c'est une interface ethernet (eth), que j'utiliserai pour mon LAN, et je prévois d'en avoir au moins 2, donc je lui colle le numéro 1.
J'utiliserai cette convention dans tout le reste du billet sans forcément détailler à chaque fois.
Un cycle complet sera une série de 100 La ligne est bien sur à reproduire et à ajuster autant de fois que d'interfaces à renommer. Les adresses MAC sont à priori les identifiants les plus fiables pour correctement repérer les interfaces réseau, jusqu'au jour où on en rajoutera une, bien sur !
Voilà, il ne reste donc plus qu'à brancher un RJ45 sur chaque prise, repérer quelle interface a été détectée comme ayant un link up, noter son adresse MAC et mettre à jour dans le fichier......... Un petit reboot plus tard et j'ai plein de jolies interfaces avec des noms stables ET compréhensibles pour moi !
Fût un temps où je vous aurais donné la conf en 24,359 fois (et la 17eme vous aurait vraiment étonné !) et vraiment vraiment en kit. Sans aller jusqu'à dire qu'il vous suffit ici de copier/coller pour que tout fonctionne, je vais de suite poser une info simple: on va passer le MTU à 9000 partout, vu que le support des Jumbo Frames est désormais annoncé comme fonctionnel dans Xen. Avec un test simple (iperf) entre 2 VMs qui traversent le firewall (configuré en mode "laisse passer, cherche pas à analyser"), le simple fait de passer le mtu à 9000 (sur l'ensemble du chemin !!!) permet d'avoir plus ou moins x2 en performances.....
Voilà, voilà....... et à la fin, le Titanic coule.....
Sur une ancienne version de ma configuration, je me suis retrouvé avec un /etc/network/interfaces difficile à maintenir. Et sur la nouvelle, le nombre total d'interfaces est plus élevé...
Du coup, pour cette nouvelle configuration toute vierge et encore un peu naïve, j'ai décidé de faire propre en utilisant quelques possibilités de ce fichier de configuration:
D'abord, nous allons utiliser les fonctions d'héritage de configuration. Pour prendre un exemple simple qui ne spoile pas trop la suite (parce que c'est pas du tout mon genre, de spoiler la suite):
iface ethtemplate inet static
mtu 9000
iface ethlan1 inet manual inherits ethtemplate
Isolé, cet exemple ne sert pas à grand chose. Mais en rajoutant quelques autres options de configuration au template, et en se souvenant que nous allons avoir plus de 20 interfaces réseau qui vont utiliser ça, si un jour je veux modifier globalement le MTU de toutes mes interfaces (par exemple si je me rends compte à la fin que c'est encore un peu ambitieux d'utiliser les Jumbo Frames sous Xen ?), je serai content d'avoir utilisé un template !
Cet héritage a également grandement simplifié la version openvswitch de ma configuration, surtout quand j'ai découvert qu'il était possible de faire de l'héritage d'héritage. J'avais alors un truc dans le genre:
iface ovs_eth_template inet manual
[de la conf très générique pour toutes mes ethernet]
iface bridgespecial_t template inet manual inherits ovs_eth_template
ovs_bridge bridgespecial
iface ethmembredubridge1 inet manual inherits bridgespecial_t
iface ethmembredubridge2 inet manual inherits bridgespecial_t
iface ethmembredubridge3 inet manual inherits bridgespecial_t
iface ethmembredubridge4 inet manual inherits bridgespecial_t
(parce que forcément, quand il y a une seule interface, c'est un peu moins pertinent.....).
Ensuite, presque tout sera réparti dans de petits fichiers posés dans /etc/network/interfaces.d, à part la configuration du loopback. Les configurations de templates auront des noms de fichiers qui commenceront par 00- (1 fichier par template), et ensuite les autres éléments de configuration seront groupés par bloc logique, également avec des préfixes numérotés pour s'assurer de l'ordre de configuration.
Enfin, plus pour faire joli qu'autre chose, et comme le nommage de mes interfaces me permettra de le faire, il y aura de temps en temps des utilisations d'expressions régulières.
Oui, on peut, et même qu'on va le faire. Bien évidemment, chaque configuration réseau est unique, voyons donc un peu les différents cas de figures possibles, après libre à vous d'assembler comme il vous plaira.
Ne vous plaignez pas du titre approximatif de cette section, avec un peu d'imagination vous pourrez trouver par vous même à quoi de pire vous avez échappé......
Le principe du bonding, également connu en tant que LACP ou IEEE_802.3ad, comme nous l'avons vu au dessus, est de regrouper plusieurs interfaces ethernet pour n'en faire qu'une seule virtuelle. Les avantages sont en particulier d'avoir un lien qui continue de fonctionner en cas de problème sur l'un des liens (câble coupé, interface défectueuse, etc.....), et pouvoir répartir (plus ou moins efficacement) la bande passante entre les interfaces. A ne pas confondre avec le principe du bondage, donc, qui parle de liens aussi, mais dont le but n'est pas le même !
La répartition de charge est cependant surtout efficace sur de multiples petites connexions de nombreuses sources/destinations différentes. Autant dire que dans mon cas, sur 4 liens, si j'arrive de temps en temps à en utiliser un peu 2, c'est déjà magnifique...... Je parle bien à nouveau du bonding.........
Mais nous n'allons pas nous arrêter pour si peux, et nous allons configurer une interface de type bond, dans /etc/network/interfaces/05-bondlink:
auto ethbond0 ethbond1 ethbond2 ethbond3 auto bondlink iface ethbond0 inet manual iface ethbond1 inet manual iface ethbond2 inet manual iface ethbond3 inet manual iface bondlink inet manual slaves ethbond0 ethbond1 ethbond2 ethbond3 bond_mode 802.3ad lacp_rate fast bond_miimon 100 bond_updelay 100 xmi_hash_policy layer2+3 mtu 9000
J'aurais bien aimé mettre une expression régulière pour slaves, vu que j'ai intelligemment nommé mes interfaces, mais je n'ai pas trouvé de syntaxe qui fonctionne (si quelqu'un a, ça m'intéresse !).
Les options suivantes sont là pour paramétrer plus précisément le mode d'agrégation de lien, vous pouvez les copier comme des sauvages ou aller lire la documentation pour déterminer quels paramètres vous voulez utiliser. Il est important d'utiliser les mêmes paramètres (en particulier la policy et le bond_mode) sur l'équipement en face !
Je n'ai pas installé le package "ifenslave" (et d'ailleurs, l'exécutable ifenslave est un script qui fait essentiellement passe-plat vers le binaire ip), et pourtant mon interface bondlink s'active correctement.
C'est peut être les soldes, mais j'ai aussi une interface bond0 qui traîne, alors qu'elle n'existe nulle part dans ma configuration (et le fait d'installer le package ifenslave n'y changera rien) !
Je n'utilise pas le template eth, qui sert pour l'instant seulement à fixer le MTU: c'est du coté de l'interface de bonding qu'il faut mettre le MTU à 9000, et c'est reporté automatiquement à toutes les interfaces.
Je n'ai pas créé non plus de template pour les interfaces de bonding, vu que je vais avoir une seule configuration de ce type sur mon serveur, mais si vous avez prévu d'en avoir plusieurs, vous pouvez bien évidemment regrouper la plupart des paramètres dans un template dédié.
D'après la doc, il y a d'autres possibilités de "bond_mode", pas forcément standardisées, mais qui pourrait être intéressantes si vous avez également un Linux en face (qui connaît ces modes, du coup).
Voilà, nous avons maintenant 4 interfaces agrégées en LACP..... sans IP, voyons tout de suite pourquoi.......
Mais quelle transition magique !!!!
Chaque interface ou groupe d'interface (un LACP, par exemple.....) physique sera mise à disposition séparément de la VM firewall via un bridge (littéralement, un pont, donc) dédié. Les interfaces ou groupes n'auront donc jamais d'IP configurée: c'est ainsi que fonctionne une configuration réseau sous Linux, les IPs sont portées par les interfaces bridge (ce qui me parait assez logique, en fait.....).
La plupart des bridges n'auront pas non plus d'adresse IP pour autant: le Dom0 fait uniquement passe-plat (enfin, passe-paquets) entre des RJ45 (ou d'autres VMs) et les interfaces réseau du firewall. Voyons ca.....
Le cas de figure le plus basique est celui d'un bridge sans interfaces ethernet, qui est créé pour que des interfaces virtuelles (celles des VMs, donc) puissent plus tard y être raccrochées.
Par exemple, mon /etc/network/interfaces.d/80-brvpub (le bridge des VMs publiques) contient:
auto brvpub iface brvpub inet manual inherits brtemplate bridge_ports none
La dernière ligne sert à bien confirmer que non, on est pas de gros boulets qui ont oublié la conf, oui on veut vraiment démarrer un bridge qui pour l'instant n'a aucune interface, merci: que ce soit le firewall ou les serveurs de l'autre coté, c'est dans la configuration des VMs que sera indiqué le fait de raccorder leurs interfaces virtuelle (vif) à ce bridge en particulier, pour une raison bien simple: ces interfaces n'existent pas encore au moment de la création du bridge !
Nous aurons le même cas dans tous les exemples ci-dessous, vous serez du coup bien aimables de revenir à chaque fois relire la ligne ci-dessus pour avoir l'explication, qui est la même.....
A peine plus complexe, un bridge qui relie (pour l'instant, donc) une seule interface ethernet. Voyons le contenu de /etc/network/interfaces.d/50-guest (une interface réseau dédiée chez moi aux équipements "invités", donc):
auto ethguest auto brguest iface ethguest inet manual inherits ethtemplate iface brguest inet manual inherits brtemplate bridge_ports ethguest
Notez que ici, c'est dans le ethtemplate qu'il y a la configuration du MTU: le bridge prendra toujours forcément le plus petit MTU parmi les interfaces qui le composent.
Nous allons également créer le bridge dédié pour le LACP créé juste avant (oui, au début du billet, il devait être regroupé avec des interfaces en switch, mais au final, j'ai décidé de le mettre sur un bridge dédié, il n'y a que les imbéciles qui ne changent pas d'avis, je l'ai toujours dit et je n'en démordrai pas !), en rajoutant à la fin de /etc/network/interfaces/05-bondlink:
auto brbond iface brbond inet manual inherits brtemplate bridge_ports bondlink
Et pour finir, nous allons "exploiter" le bloc de 8 interfaces pour créer un switch au niveau de l'hyperviseur, via /etc/network/interfaces/10-switch:
auto ethsw1 ethsw2 ethsw3 ethsw4 ethsw5 ethsw6 ethsw7 ethsw8 auto brswitch iface ethsw1 inet manual inherits ethtemplate iface ethsw2 inet manual inherits ethtemplate iface ethsw3 inet manual inherits ethtemplate iface ethsw4 inet manual inherits ethtemplate iface ethsw5 inet manual inherits ethtemplate iface ethsw6 inet manual inherits ethtemplate iface ethsw7 inet manual inherits ethtemplate iface ethsw8 inet manual inherits ethtemplate iface brswitch inet manual inherits brtemplate bridge_ports regex ethsw.*
A mon grand regret, le seul endroit où j'ai réussi à trouver une syntaxe de gestion d'expressions régulières, c'est pour le bridge_ports. J'aurais aimé faire un truc genre:
auto ethsw.* iface ethsw.* inet manual inherits ethtemplate
mais ca ne fonctionne pas (en tout cas sur ma version actuelle !), et mes recherches sur le net pour trouver une autre syntaxe permettant ce genre de choses sont restées infructueuses......
Si vous voulez finalement faire quand même un bridge qui regroupe switches et LACP, c'est facile: il suffit de configurer chaque LACP séparément, et vous pourrez finir par:
iface brenorme inet manual inherits brtemplate bridge_ports bondana bondjames ethsw1 ethsw2 ethsw3 ethsw4
On doit même pouvoir faire un truc classouille avec les regex, mais j'ai la flemme de faire des essais pour une configuration que je n'utiliserai finalement pas dans la vraie vie......
Oui, on l'avait à vrai dire déjà vu dans l'épisode précédent, ca met un temps fou à démarrer, à cause du Spanning Tree Protocol, STP, donc... Il suffit de le désactiver en indiquant dans le template de bridge:
iface brtemplate inet manual
bridge_stp 0
bridge_waitport 0
bridge_fd 0
Ah, et donc, assurez vous de ne pas faire de boucles réseau, vu que vous venez de désactiver le truc qui les aurait détectées et plus ou moins gérées pour vous.........
A la création de chaque vif, les scripts Xen rajoutent des entrées de forwarding dans iptables, du genre:
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out vifxx --physdev-is-bridged 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vifxx --physdev-is-bridged
Mais dans notre cas, l'analyse des paquets en transit est le boulot de la VM firewall, donc nous allons nous assurer que la pile IP de l'hyperviseur en fait le moins possible, en rajoutant ces 3 lignes dans /etc/sysctl.conf (ou dans un fichier dédié de /etc/sysctl.d si vous voulez faire propre..... ce qui est mieux......):
net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0
Sur les versions relativement récentes des noyaux Linux, il sera également nécessaire de forcer le chargement du module br_netfilter au démarrage:
echo br_netfilter >> /etc/modules
(là aussi, vous pouvez faire un fichier dédié dans /etc/modules-load.d)
Petit reboot (ou actions équivalentes à la main si vous préférez), et on pourra constater que les paquets qui doivent transiter sur les bridges circulent sans soucis, même avec un ip_forward=0 au niveau de la configuration de l'hyperviseur, même avec une configuration de filtrage en BLOCK/DROP.
On pourrait du coup aller modifier les scripts de Xen pour qu'il ne génère pas les règles de forward.
A ce moment de la configuration, que ca soit avec bridge ou avec openvswitch, j'ai des bridges sans IP qui se permettent de répondre à des requêtes ARP avec leur propre adresse MAC, ce qui fout rapidement un sacré bordel dans le réseau..... Si j'en crois ce que j'ai lu ici, le problème vient du noyau Linux, qui a une notion pas très exclusive des couples Adresse MAC / Adresse IP correspondante. Sur le principe, tant que c'est entre adultes consentants et fait de façon safe, je ne suis pas le genre de gars à critiquer ce genre de relations libres, sauf que là, justement, ca n'est pas safe du tout, il faut donc y remettre un peu d'ordre.
La solution proposée par Vincent (oui, style genre on est potes de longue date, alors que j'ai découvert son blog il y a quelques jours) est d'activer une fonctionnalité relativement récente du noyau Linux, qui est le filtrage des VLANs sur les ports d'un bridge (je ne fais quasiment que recopier.......). Comme je n'aime pas appliquer une commande sans comprendre ce qu'elle active vraiment, j'ai cherché un peu d'autres infos sur cette fonctionnalité, et à peu près à chaque fois, ca parlait de vraiment faire passer des VLANs sur un bridge, ce qui n'est pas du tout mon cas d'usage.
Toujours d'après Vincent, ebtables n'a pas l'air d'être une solution méga fiable, donc j'ai un peu mis de coté.
A un moment je vais arrêter de citer Vincent, mais pas encore là maintenant de suite, il évoque aussi la possibilité de résoudre le truc avec tc(8). Ce truc a l'air bien, faudra que je regarde......
En pratique, j'ai résolu au moins la partie émergée de mon problème avec une commande assez simple:
ip link set <dev> arp off
Et ce, sur toutes mes interfaces qui n'ont pas d'adresse IP. C'est à dire à peu près toutes mes interfaces, donc, sauf celle d'admin et le loopback.
Pour les bridge et les ethernet, il suffit de modifier les templates, qui deviennent:
iface brtemplate inet manual
bridge_stp 0
bridge_waitport 0
bridge_fd 0
post-up ip link set $IFACE arp off
iface ethtemplate inet manual
mtu 9000
post-up ip link set $IFACE arp off
Et donc, on fera attention à bien déshériter l'interface d'admin et le loopback, en espérant qu'ils ne fassent pas de procès.......
Pour les vif, je n'ai pas trouvé mieux que modifier /etc/xen/scripts/xen-network-common.sh, et en particulier _setup_bridge_port():
--- /etc/xen/scripts/xen-network-common.sh
+++ /etc/xen/scripts/xen-network-common.sh
@@ -92,6 +92,8 @@ _setup_bridge_port() {
# stolen by an Ethernet bridge for STP purposes.
# (FE:FF:FF:FF:FF:FF)
ip link set dev ${dev} address fe:ff:ff:ff:ff:ff || true
+ ip link set dev ${dev} arp off mtu 9000 || true
+ ethtool -K ${dev} tx off gso off gro off tso off
fi
# ... and configure it
@@ -133,6 +135,7 @@ add_to_bridge () {
# Usage: set_mtu bridge dev
set_mtu () {
+ return
local bridge=$1
local dev=$2
mtu="`ip link show dev ${bridge}| awk '/mtu/ { print $5 }'`"
Notez que je ne suis pas tout à fait certain que tout ceci soit vraiment nécessaire: il suffit peut être de mettre cette option uniquement sur les bridges. Mais il n'y a vraiment vraiment aucune raison pour que le noyau s'occupe de quoi que ce soit lié à ARP (voire même de quoi que ce soit en général, d'ailleurs) sur ces interfaces, donc autant le lui dire. Et j'en profite pour glisser aussi une MTU à 9000 sur ces interfaces, n'ayant pas trouvé de méthode qui fonctionne via /etc/network/interfaces pour le faire. Et je désactive donc la fonction set_mtu(), qui ne réagit pas correctement dans le cas d'un bridge qui n'a pas déjà un MTU à 9000 (donc un bridge sans interface physique avec un MTU à 9000, soit plus de la moitié de mes bridges.....).
Je désactive aussi des trucs avec ethtool, l'explication est plus bas, et comme je suis un gars cool je vous livre le patch en une seule fois......
A priori, ca ne devrait pas être nécessaire avec toute cette configuration, et c'est le rôle de la VM firewall d'assurer la sécurité réseau, mais un vieux dicton dit Ceinture, bretelles et calecon propre
, donc je vais mettre en place un petit script de filtrage, qui autorise en entrée le ssh, le NTP et le ping:
#!/bin/sh ADMINIF=bradmin IPTABLES=/sbin/iptables # Set filter default policies to "Drop" # Done first for security reasons $IPTABLES -t filter -P INPUT DROP $IPTABLES -t filter -P FORWARD DROP $IPTABLES -t filter -P OUTPUT DROP $IPTABLES -t filter -F INPUT $IPTABLES -t filter -F OUTPUT # Creating table for Established / related packets. # Create Table $IPTABLES -t filter -N stateful $IPTABLES -t filter -F stateful # Accept all related packets $IPTABLES -A stateful -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT $IPTABLES -A stateful -m state --state ESTABLISHED -p udp -j ACCEPT $IPTABLES -A stateful -m state --state ESTABLISHED -p icmp -j ACCEPT $IPTABLES -A stateful -m state --state RELATED -j ACCEPT $IPTABLES -A stateful -m state --state INVALID -j NFLOG --nflog-threshold 20 --nflog-prefix "Fw: invalid state" $IPTABLES -A stateful -m state --state INVALID -j DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A INPUT -j stateful $IPTABLES -A INPUT -p tcp -i $ADMINIF --dport 22 --syn -j sshguard $IPTABLES -A INPUT -m state --state NEW -p tcp -i $ADMINIF --dport 22 --syn -j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p udp -i $ADMINIF --dport 123 -j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p icmp -i $ADMINIF -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT # for the moment, allow all traffic from this host $IPTABLES -A OUTPUT -j stateful $IPTABLES -A OUTPUT -m state --state NEW -j ACCEPT
Ce script sera appelé en post-up dans la configuration du bridge d'admin (et cette version suppose que vous avez sshguard d'installé, mais si ce n'est pas le cas cela générera juste une erreur à la création de la règle qui fait référence à la chaine sshguard, le reste fonctionnera normalement).
Dans le cas décrit par Vincent, probablement pas. Sauf que, dans notre cas, l'hyperviseur ne fait aucun boulot de routage. D'ailleurs, le routage est désactivé: net.ipv4.ip_forward et
net.ipv6.conf.all.forwarding sont à 0.
Du coup, une tentative de routage forcée consommera probablement quelques cycles CPU en trop avant de se faire jeter dehors, mais entre le routage désactivé, le script de filtrage et la désactivation de tout ce qui est ARP presque partout, je n'ai pas réussi à faire passer des paquets en douce en utilisant les techniques décrites par Vincent (ou en tentant quelques autres variantes).
Voilà son fichier de configuration:
name = "Firewall"
builder = 'hvm'
vcpus = 2
maxvcpus = 2
cpu_weight = 256
memory = 1024
maxmem = 1024
#on_poweroff = "restart"
on_watchdog = "restart"
on_crash = "restart"
on_reboot = "restart"
disk = [ 'file:/home/Xen/Firewall.img,hda,w' ]
usb = 0
vif = [
'type=vif,vifname=vfwout,bridge=brout, mac=00:16:3e:xx:yy:0',
'type=vif,vifname=vfwlan,bridge=brlan, mac=00:16:3e:xx:yy:1',
'type=vif,vifname=vfwserver,bridge=brserver, mac=00:16:3e:xx:yy:2',
'type=vif,vifname=vfwswitch,bridge=brswitch, mac=00:16:3e:xx:yy:3',
'type=vif,vifname=vfwpub,bridge=brvpub, mac=00:16:3e:xx:yy:4',
'type=vif,vifname=vfwwifi,bridge=brwifi, mac=00:16:3e:xx:yy:5',
'type=vif,vifname=vfwbond,bridge=brbond, mac=00:16:3e:xx:yy:6',
'type=vif,vifname=vfwadmin,bridge=bradmin, mac=00:16:3e:xx:yy:7',
]
serial = 'pty'
Même avec le passage au toolstack xl, pas beaucoup de différence avec l'ancienne configuration.
Quitte à mettre des noms prédictibles, stables et explicites à toutes les interfaces réseau de la configuration, autant le faire aussi avec les vif créées, via l'argument vifname=.
00:16:3e: est toujours le préfixe MAC (à peu près rien à voir avec l'ordinateur homonyme de ma soeur, sauf que son MAC a une MAC, et même probablement 2......) réservé pour XEN, vous mettez ce que vous voulez pour xx:yy (mais je vous conseille cependant fortement de mettre des valeurs hexadécimales valides..... et je vous conseille aussi de mettre la même valeur xx:yy pour toutes les lignes, ainsi que de numéroter le dernier octet dans l'ordre, mais là c'est plus pour faire joli et s'y retrouver facilement).
Chaque interface est donc reliée à un bridge différent, et avec les jolis noms de bridges utilisés avant, ca en devient assez lisible.
L'ancienne configuration précisait model=e1000, la nouvelle type=vif, pour des raisons de performances: la VM doit tourner en HVM (virtualisation complète), mais embarque les drivers "PV-HVM" de Xen qui sont plus efficaces qu'un mode complètement émulé (type=ioemu, ce qui est le cas par défaut, et model=e1000, qui est un driver assez efficace quand même en mode ioemu).
Là, on est dans du assez simple, la partie réseau de la conf d'une VM classique ressemblera à ça:
vif = [
'vifname=vifnomdemavm,bridge=brnomdemavm,mac=00:16:3e:00:00:00',
]
Vous penserez à mettre autre chose que 00:00:00 à la fin de la MAC, et vous ajusterez le nom de l'interface et du bridge. Notez qu'il est bien sur possible de raccorder plusieurs VMs sur un seul bridge si besoin est.
J'avais déjà eu le problème lors de mes anciennes installations: TCP Segmentation Offload et ses potes ne font pas trop bon ménage avec les interfaces Vif...
Ca semblait mieux sur mes premiers tests, mais mes interfaces étaient à ce moment toutes raccordées à des bridges qui contenaient aussi une interface ethernet (disposant elle d'un support de ces accélérations). Et dans mes premiers tests, laisser le support de ces trucs faisait gagner en performances, du coup, cette fois, j'ai essayé de ne pas être aussi bourrin qu'il y a quelques années, et j'ai fait quelques autres essais pour mieux comprendre...... J'ai cru à un moment pouvoir laisser activé l'accélération matérielle sur les bridges qui incluaient une interface ethernet physique. Si ca peut vous aider, j'avais alors fait cette modification (version openvswitch), qui profite du nommage de mes interfaces pour pouvoir déterminer facilement si une ethernet fait partie du bridge:
--- /etc/xen/scripts/vif-openvswitch.old
+++ /etc/xen/scripts/vif-openvswitch
@@ -79,6 +79,12 @@ add_to_openvswitch () {
local vif_details="$(openvswitch_external_id_all $dev)"
+ # check if a physical ethernet is connected to the bridge
+ local breth="$(ovs-vsctl list-ifaces $bridge |grep '^eth')"
+ if [ -z "$breth" ]; then
+ ethtool -K $dev tx off gso off gro off tso off
+ fi
+
do_or_die ovs-vsctl --timeout=30 \
if-exists del-port $dev \
-- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details
Il y a probablement moyen de l'écrire de façon plus classouille.......
Sauf que ca ne fonctionne toujours pas dans tous les cas: en particulier, chez moi, l'interface d'administration de l'hyperviseur embarque une interface ethernet (pour faire de l'administration réseau urgente avec un portable et un RJ45 si besoin est), mais les paquets émis localement passent par l'interface Vif en fonctionnement normal. Et mon hyperviseur s'est retrouvé joignable en ping, mais ni en TCP, ni en UDP......
J'en suis donc revenu à une désactivation systématique de la fonction sur les vifs, en allant remodifier _setup_bridge_port() dans /etc/xen/scripts/xen-network-common.sh (extrait du patch précédent):
--- /etc/xen/scripts/xen-network-common.sh.old
+++ /etc/xen/scripts/xen-network-common.sh
@@ -92,6 +92,8 @@ _setup_bridge_port() {
# stolen by an Ethernet bridge for STP purposes.
# (FE:FF:FF:FF:FF:FF)
ip link set dev ${dev} address fe:ff:ff:ff:ff:ff || true
+ ip link set dev ${dev} arp off mtu 9000 || true
+ ethtool -K ${dev} tx off gso off gro off tso off
fi
# ... and configure it
Au début, j'avais aussi tenté de désactiver rx (vérification du checksum en réception), mais il ne semble pas désactivable, et ca ne semble pas poser de problèmes...... Sur le coup, je n'ai apparemment même pas besoin de faire les mêmes désactivations dans mes VMs (à part le firewall, mais c'est fait automatiquement), ce qui m'arrangera quand je ferai d'autres installations en vraies conditions de prod (donc en utilisant le réseau dès l'installation).
Après mes premiers vrais benchs, je me suis retrouvé avec des vif désactivées dans le Dom0 et le message suivant dans le dmesg:
vif vif-xxx viftruc: txreq.offset: 18, size: 9014, end: 9032 vif vif-xxx viftruc: fatal error; disabling device
En cherchant une nouvelle fois un peu sur le net, en faisant quelques essais et en redémarrant à chaque fois la VM concernée par l'interface bloquée (je n'ai pas trouvé mieux comme solution pour réactiver ces interfaces), j'ai fini par constater que le problème ne se pose plus si je fais la même commande ethtool sur les interfaces des VMs. Et vu ce que j'ai eu le temps de mesurer avant d'avoir ces désactivations d'interfaces, les différences de performances sont à peu près inexistantes.
Edit: Après quelques mois d'utilisation, en fait, le problème arrive toujours de temps en temps. Les dernières fois où c'est arrivé, c'était lors d'un classique apt install <un truc>. J'ai eu le même problème en installant le même paquet sur 2 VMs différentes, mais le plantage n'a pas eu lieu sur le même paquet de dépendance en cours de téléchargement. En général, il me suffit d'effacer le paquet "partial" (qui avait fait planter) et de relancer le apt install pour que ça fonctionne. Par contre, une fois, je n'ai pas effacé le partial et relancé le apt install, et j'ai eu à nouveau le problème.
Enfin, quand je dis "il suffit de", ce n'est pas tout à fait vrai: je dois d'abord récupérer une interface fonctionnelle coté hyperviseur ! Si j'en crois ce que j'ai dit dans la première version de ce billet, je pouvais apparemment la récupérer juste en redémarrant la VM. Peut être à cause du nommage des interfaces, je me retrouve maintenant à devoir redémarrer l'ensemble de l'hyperviseur pour récupérer l'interface fonctionnelle, ce qui est franchement désagréable !
Même stoppant complètement la VM, en renommant son interface dans le .xl et en la redémarrant, je ne récupère pas l'interface coté hyperviseur.....
En prod, au moins la VM firewall doit démarrer automatiquement. Dans mon cas, la plupart des autres VMs aussi. En plus, certaines VMs peuvent dépendre d'autres au niveau du réseau. Par expérience sur mes anciens hyperviseurs, je réduis au maximum les dépendances réseau de mes VMs au démarrage: pas de DHCP, montages NFS en autofs ou équivalent, etc.... Il est cependant également possible de spécifier l'ordre de démarrage des VMs, en s'assurant de l'ordre des fichiers dans /etc/xen/auto (faites comme tout le monde, mettez des numéros au début des noms de vos fichiers).
Dans ma version actuelle, tout fonctionne, mais pas au boot: les VMs ne démarrent pas, et en creusant un peu, c'est tout simplement parce que les bridges ne sont pas encore prêts au moment où le système veut démarrer les VMs. Après avoir creusé un peu, j'ai trouvé une solution assez simple qui consiste à préciser que le démarrage des domaines Xen nécessite un réseau déjà établi:
--- /etc/init.d/xendomains.old +++ /etc/init.d/xendomains @@ -1,8 +1,8 @@ #!/bin/bash ### BEGIN INIT INFO # Provides: xendomains -# Required-Start: $syslog $remote_fs xen -# Required-Stop: $syslog $remote_fs xen +# Required-Start: $syslog $remote_fs xen $network +# Required-Stop: $syslog $remote_fs xen $network # Should-Start: drbd iscsi openvswitch-switch # Should-Stop: drbd iscsi openvswitch-switch # X-Start-Before: corosync heartbeat libvirtd
A propos de réseau pas disponible et de boot, dans ce genre de configurations, pensez à vérifier le contenu de /etc/network/if-up.d (et if-pre-up.d): dans mon cas, après avoir installé openntpd, je me suis retrouvé avec un script de redémarrage du démon à chaque activation d'interface réseau...... j'ai plus de 80 interfaces réseau, dont 30 activées pendant le démarrage...........
Par défaut, lors de l'arrêt de l'hyperviseur, les scripts (au moins chez Debian ?) stoppent les VMs dans l'ordre inverse de démarrage (la plus récemment démarrée en premier, donc). L'idée n'est pas mauvaise, jusqu'au moment où vous allez vouloir redémarrer une VM, pour une raison ou une autre..... Après quelques bricolages, j'en suis arrivé à la conclusion que le plus simple serait d'intercepter le script /usr/lib/xen-common/bin/xen-init-list (appelé par les scripts d'arrêt des domaines Xen) pour changer l'ordre de son affichage. Pour l'instant, je n'ai pas encore de solution générique propre, du coup il n'y a pas d'intérêt à partager mon bricolage qui ne fonctionne que chez moi.........
vendredi, juin 27 2014
Par Vanhu le vendredi, juin 27 2014, 19:00 - Vieux con de hacker old school.....
Il y a quelques temps, j'ai commencé à faire mumuse avec la virtualisation (sous Xen), y compris pour un cas de figure un poil complexe sur lequel je n'avais trouvé aucune doc sur le net (si vous voulez juste déployer quelques VMs classiques dans un hyperviseur Xen, vous n'êtes pas au bon endroit, il existe plein de tutoriels pour ce cas de figure basique).
Ca tombe bien, vu que je n'avais pas fait de nouveau billet aujourd'hui cette semaine ces derniers temps depuis au moins un an, et comme j'ai quelques potes qui envisagent de faire une conf similaire, c'est un prétexte que je ne pouvais pas louper.
En plus, ca me servira aussi probablement le jour ou mon disque dur va me lâcher et que je vais devoir tout refaire.......
Attention: contrairement à ce que le titre pourrait laisser croire, ce billet contient de nombreux extraits naturels de trucs techniques plus ou moins compliqués. En particulier, des connaissances de base en virtualisation sont à peu près indispensables, et une expérience de Xen en particulier est vivement souhaitée.
En cas de dépressurisation cérébrale suite à la lecture de ce billet, des masques à oxygène ne tomberont probablement pas automatiquement du plafond. Vous êtes invités à repérer à l'avance les issues de secours, qui ne seront probablement pas non plus indiquées par des consignes lumineuses en cas d'incident.
Les actions décrites ci-après ont été réalisées par un Vieux Con de Hacker Old School (tm), qui porte des t-shirts de geek, qui va généralement plus vite en utilisant un shell ou emacs qu'avec une interface graphique, un gars qui a survécu à la Grande Guerre (entre l'Amiga et l'Atari ST), tout ça....
Et bien évidemment, tout a été réalisé dans des conditions optimales de sécurité, avec un bouton rouge, une équipe d'intervention d'urgence prête à réagir à tout moment, 8 litres de coca (note pour moi même: en rester là, j'ai déjà fait la reprise de la blague de Naheulbeuk avec la liste de courses.....), et un vrai réseau de prod à coté pendant toute la durée de l'opération.
Donc les enfants, NE FAITES SURTOUT PAS CA CHEZ VOUS, et si vous le faites quand même (bah oui, on ne va pas se mentir: dire à quelqu'un "ne fais surtout pas ça", c'est quand même un excellent moyen de l'inciter à le faire, juste pour voir.....), vous serez seul(e) responsable de toute conséquence dramatique qui en découlerait, comme une instabilité réseau, la perte de données, la création d'une brêche dans le continuum spatio-temporel, le départ de votre copine, un contrôle fiscal, l'arrivée de votre belle mère, une halitose subite, ou tout autre désagrément non listé ci-dessus.
Notez cependant que, à l'exception d'une légère instabilité réseau lors de la première mise en prod, aucun des autres symptômes cités en exemple n'est survenu lors de ma mise en prod !
Ah, et aucun animal mignon n'a été blessé, tué ou mangé pendant l'intervention.
Ne soyez pas impatients, comme ça, si, effectivement, on voulait faire un vrai truc, que j'ai essayé de transcrire en un (magnifique, je sais) schema (cliquez dessus pour l'agrandir):
En admettant que vous n'ayez pas tout à fait compris la configuration, malgré la profusion de couleurs et mon extraordinaire maîtrise de l'outil de création du truc, l'idée est donc, comme le titre du billet le suggérait quand même déjà relativement clairement, de déployer un firewall virtuel (ais-je vraiment besoin de préciser la marque du firewall dans mon cas ???) dans un hyperviseur Xen.
Ce qui pourrait paraître relativement classique (un hyperviseur, une VM, du réseau) pose cependant une problématique particulière dans mon cas: je veux pouvoir gérer à ma convenance un ou plusieurs bridges au niveau du firewall (donc avec filtrage, IPS, tout ça...), sans devoir faire de modifications de configuration sur le Dom0 à chaque fois, et évidemment sans perturbations par le Dom0, sans paquets qui passent discrètement d'une interface physique une autre en glissant un petit biffeton à l'hyperviseur, ou autres trucs pas recommandables dans un réseau de bonne famille et propre sur lui.
Dit autrement, tout doit réagir exactement comme si les interfaces réseau physiques étaient directement reliées au firewall.
Et, accessoirement, si ça peut fonctionner, c'est mieux, y compris avec d'autres VMs sur le même hyperviseur, également branchées sur des interfaces dédiées du firewall.
Dans tout le reste de l'explication, on considèrera 8 interfaces pour le firewall, dont 4 reliées à des interfaces physiques, si votre configuration est différente, l'idée reste la même, il suffit d'adapter....
Euh, oui, on aurait pu, effectivement..... mais en gros, VMWare n'est pas OpenSource, Xen est officiellement supporté par ma VM de firewall (ok, la version commerciale, mais dans les faits, je sais que ça fonctionne bien), et aucune autre solution de virtualisation ne m'a paru avoir le "truc en plus" qui aurait justifié le changement de techno.
Et j'en vois deux dans le fond qui auraient de toutes façons fait la remarque "mais y'avait d'autres solutions" si j'en avais choisi une autre.....
Pour la configuration réseau au niveau de l'hyperviseur, j'ai utilisé les bridges Linux (brctl, tout ça.....).
On aurait pu également utiliser OpenVSwitch, j'ai le souvenir d'avoir un peu regardé cette solution, et de l'avoir mise de coté pour une bonne raison à l'époque...... bonne raison dont je ne me souviens plus, évidemment....
Il est également possible que cette bonne raison soit devenue obsolète depuis.
Euh, oui, on peut, mais c'est pas écolo, c'est pas tendance (virtualisation, nuages, blabla.....), et c'est un peu trop facile pour être fun.
Accessoirement, ca ne répond pas non plus au cas de figure "autres VMs à filtrer via le firewall", en tout cas pas simplement, si j'ai plusieurs VMs que je veux segmenter entre elles.
Sur le papier (enfin, sur le site web, ne commencez pas à pinailler comme ça), Xen sait faire, ca s'appelle le PCI Passthrough.
Et c'est fort logiquement la première option que j'avais étudié quand j'ai commencé à bricoler ma configuration.
Sauf que, dans les faits, ca n'est pas aussi simple, il faut déjà avoir une carte mère qui supporte l'IOMMU, ce qui n'était pas mon cas.
Si la carte mère de votre Dom0 le supporte, cependant, c'est probablement une possibilité intéressante à tester !
Et cette solution ne gère pas le branchement entre le firewall et d'autres machines virtuelles, donc ne serait applicable que pour les interfaces physiques.
L'installation de base est une procédure relativement simple, et allègrement documentée sur le net.
Dans notre exemple, il s'agira d'une Debian, je ne vous ferai pas l'affront d'expliquer ici comment on installe une Debian de base, et la mise en place de l'hyperviseur Xen est également documentée sur le wiki Debian sur Xen (n'allez pas trop loin dans les manips du wiki, en particulier pour tout ce qui est configuration réseau, c'est pour le cas "classique").
Note: il existe plusieurs facades pour configurer/administrer un Xen. J'étais parti pour une administration avec le toolstack Xl, mais j'ai eu divers problèmes avec, entre autres à cause de la version de Xen fournie par ma Debian. Je me suis donc rabattu sur le toolstack xm, raison pour laquelle les exemples de configuration seront fournis sous ce format.
Cependant, xm/xend est marqué DEPRECATED, il est donc préférable de convertir les configurations au format xl si vous utilisez une version récente de Xen.
Dans mon cas, la VM Firewall fait tourner un dérivé de FreeBSD, ce qui nécessite une configuration un poil différente pour le démarrage:
name = "Firewall" kernel = "/usr/lib/xen-4.1/boot/hvmloader" builder = 'hvm' vcpus = 1 maxvcpus = 1 cpu_weight = 512 memory = 1024 maxmem = 1024 #on_poweroff = "restart" on_watchdog = "restart" on_crash = "restart" on_reboot = "restart" serial = 'pty' disk = [ 'file:/home/Xen/Firewall.img,hda,w' ]
Pour l'essentiel, cependant, cette partie de la configuration est très classique (vous penserez à mettre à jour le chemin de la ligne kernel, si votre version de Xen est différente, évidemment.....), je lui réserve 1 VCPU et 1Go de RAM dans mon cas, et comme c'est un firewall, je décrète que presque tous les cas d'arrêt de la VM nécessitent un redémarrage (sauf un arrêt explicite et volontaire).
Le serial='pty' me permettra également d'avoir un accès facile à la console de ma VM depuis un shell de l'hyperviseur en cas de soucis (note pour moi: KernelMsg=1). Selon votre VM firewall, la méthode sera peut être différente.
A un moment, on veut faire des trucs pour le réseau, il va bien falloir le configurer.....
D'un point de vue Dom0, on va créer plein de bridges à 2 interfaces: un pour chaque interface physique du Dom0 (à chaque fois couplé à une interface du firewall), et un pour chaque autre VM (ou éventuellement groupe de VMs) présente dans l'hyperviseur.
Il faut donc installer le package bridge-utils:
apt-get install bridge-utils
Les interfaces du Dom0 n'auront pas d'adresse IP (les bridges non plus, d'ailleurs), il va donc falloir forcer leur activation manuellement.
Dans /etc/network/interfaces, pour une interface physique ethx donnée, on aura donc:
auto ethx
auto brx
iface ethx inet manual
iface brx inet manual
bridge_ports ethx
Dans le cas d'un bridge non relié à une interface physique, la seule différence est qu'on indiquera:
bridge_ports none
(vous aurez la présence d'esprit de remplacer à chaque fois x par le numéro de l'interface, ça reste valable dans toute la suite de l'explication)
Notez que vous pouvez à priori remplacer "inet" par "inet6", pour faire tendance, ce qui ne devrait absolument rien changer: il ne s'agit pas ici de configurer des interfaces, mais juste de les activer et de les relier à des bridges qu'on crée au passage.
Selon le niveau de support et de configuration d'IPv6 par votre VM firewall, il sera peut être nécessaire de désactiver pas mal de choses au niveau IPv6 sur votre Dom0, y compris (surtout ?) les adresses Lien Local (celles en fe80::), ce qui vous évitera des boucles réseau étranges en IPv6...
Pour pouvoir accéder au Dom0 depuis le réseau, une interface aura un status un peu particulier: elle aura une adresse IP, la veinarde !
Enfin, plus précisément, le bridge sur lequel elle est attachée aura une IP, puisque c'est le fonctionnement normal sous Linux: une interface reliée à un bridge n'est plus utilisable directement.
Par rapport aux autres bridges, tout simplement, on va remplacer "inet manual" par "inet static" (et/ou par inet6 static si vous êtes tendance), et rajouter address, netmask, gateway (l'IP du firewall sur le LAN, en configuration finale, l'IP de votre passerelle actuelle pendant la préparation). Une configuration type DHCP, autoconf en v6 ou autre est à éviter: votre Dom0 démarrera logiquement avant tout le reste, y compris le firewall (bah oui, logique....), et ne saura donc peut être pas accéder à un serveur DHCP...
J'ai également du forcer son adresse MAC (hwaddress, j'ai mis l'adresse MAC de l'interface physique), vous verrez pourquoi après.
Idéalement, si votre niveau de parano est assez élevé (et surtout si vous avez un moyen assez facile d'accéder à votre Dom0 en console en cas de problèmes), dans la configuration finale, ce bridge sera reliée à une interface dédiée de la VM firewall (et donc à aucune interface physique).
Une interface physique dédiée (et toujours reliée à une interface dédiée du firewall) vous permettra de venir brancher en urgence un ordinateur portable pour réparer d'éventuels problèmes, tout en bénéficiant de la même protection par le firewall en usage normal.
A défaut, si vous ne laissez pas n'importe qui se brancher sur votre LAN, et si vous mettez en place un filtrage au niveau du Dom0 n'autorisant que les accès ssh vers celui-ci (en certificats uniquement, évidemment), le niveau de sécurité restera tout à fait correct, et permettra une intervention simplifiée en cas de soucis.
Si vous êtes vraiment cool et partageur, un accès telnet en openbar sur une IP publique (et sans mot de passe pour root, on ne va pas commencer avec des mesquineries du genre) fera probablement plein d'heureux sur le net......
Selon votre topologie réseau, vous serez peut être amenés à configurer ainsi plusieurs interfaces/bridges sur le Dom0 (si vous avez plusieurs plans d'adressages qui peuvent servir à administrer en urgence), il suffira de reproduire la même idée pour chacune de ces interfaces.
Pour notre VM, nous utiliserons donc le script vif-bridge, ce qui donne dans la configuration de la VM firewall, pour la partie réseau:
vif = [
'bridge=br0,model=e1000,mac=00:16:3e:xx:0',
'bridge=br1,model=e1000,mac=00:16:3e:xx:1',
'bridge=br2,model=e1000,mac=00:16:3e:xx:2',
'bridge=br3,model=e1000,mac=00:16:3e:xx:3',
'bridge=br4,model=e1000,mac=00:16:3e:xx:4',
'bridge=br5,model=e1000,mac=00:16:3e:xx:5',
'bridge=br6,model=e1000,mac=00:16:3e:xx:6',
'bridge=br7,model=e1000,mac=00:16:3e:xx:7',
]
Ici, on force le type d'interface à e1000 (le type par défaut était moins performant au niveau de la VM, de mémoire), et on va également forcer les adresses MAC pour éviter d'avoir un bordel ambiant à chaque redémarrage de la VM. Le préfixe 00:16:3e est réservé pour Xen, ce qui évitera des collisions avec d'autres cartes ethernet du réseau, vous mettez ce que vous voulez à la place de :xx: (qui est d'ailleurs :xx:xx:, vu qu'une adresse MAC est codée sur 6 octets), et tant qu'à faire, on va numéroter le dernier octet dans l'ordre pour faire propre.
Si toutes vos interfaces ont des plans d'adressages différents, cette configuration devrait presque suffire à faire fonctionner le truc.
Sauf que, dans mon cas, je veux pouvoir gérer des bridges au niveau du firewall, et c'est là que ca devient poilu, vu que, en l'état, ça ne fonctionnera pas (ou en tout cas pas correctement).
Le premier problème, c'est que les interfaces du Dom0 n'accepteront pas les paquets à destination d'autres adresses MAC (ou en tout cas pas toujours, selon la configuration de plein de trucs). Il faut donc forcer toutes les interfaces avec l'adresse MAC de broadcast.
Nous allons donc rajouter la ligne suivante dans la configuration de toutes les ethx:
up /sbin/ifconfig ethx -arp hw ether fe:ff:ff:ff:ff:ff
Pareil pour les bridges, sauf qu'il est nécessaire de le faire en post-up (en phase "up", apparemment, le bridge n'existe pas encore assez pour l'opération):
post-up /sbin/ifconfig brx -arp hw ether fe:ff:ff:ff:ff:ff
C'est à ce moment que l'intérêt de forcer l'adresse MAC de l'interface d'administration apparaît....
Maintenant que j'y repense, je me rends également compte que, sur cette interface, l'option hwaddress fonctionne très bien, y compris sur une interface de type bridge...... je n'ai pas fait le test (j'étais déjà en prod quand j'y ai pensé), mais l'option devrait aussi logiquement fonctionner ici, pour les eth comme pour les br:
iface <un ethx ou un brx> inet manual
hwaddress fe:ff:ff:ff:ff:ff
bridge_ports ethx # seulement pour les interfaces brx
Le second obstacle, c'est que tous les paquets passent par le Netfilter du Dom0, qui peut donc les bloquer, les router, ou faire d'autres choses avec, que la morale n'approuve pas forcément...
Nous allons donc indiquer au système que les paquets qui passent sur un bridge ont une bouteille à l'intérieur, connaissent bien le patron, et seront gérés par le service de sécurité de la salle VIP s'ils ont des baskets ou une casquette.
Ca se fait en ajoutant à /etc/sysctl.conf:
net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0
Activez à la main ces sysctl si vous voulez économiser un reboot.
A un moment, vous remarquerez que le démarrage du Dom0 est très long, curieusement depuis qu'on a modifié la configuration réseau pour rajouter tous les bridges....
Pour revenir à une vitesse de démarrage normale, il suffit d'ajouter les paramètres suivantes dans chaque section brx du fichier /etc/network/interfaces:
bridge_stp off
bridge_waitport 0
bridge_fd 0
Evidemment, si vous avez un réseau avec plein de boucles, désactiver le protocole STP partout est probablement une très très mauvaise idée.....
A ce moment, votre configuration devrait fonctionner, mais avec des performances réseau complètement pourries dès que ça traverse le firewall, voire des sessions TCP qui ne finissent jamais vraiment.
Une enquête approfondie réalisée conjointement entre Les Experts et NCIS révèle des trucs très étranges sur le réseau, dont par exemple des paquets qui dépassent allègrement la MTU, voire qui arrivent plus gros qu'ils ne sont partis.
Le grand méchant de cette histoire est finalement l'accélération matérielle des cartes réseau, en particulier la segmentation déportée des gros paquets et/ou le déport des sommes de contrôle.
Votre moteur de recherche préféré vous confirmera rapidement que ces trucs là ne font pas forcément bon ménage avec la virtualisation, en tout cas sous Xen, en tout cas aujourd'hui.
Nous allons donc désactiver tout ça sur les interfaces vif (le pendant sur le Dom0 des interfaces des VMs), à l'aide de la commande ethtool (donc oui, apt-get install ethtool).
Au passage, tant qu'on est là et qu'on parle de performances, réseau, on va également augmenter la taille de la file d'attente des interfaces vif, qui est à une valeur très faible par défaut.
Pour que les modifications soient faites automagiquement à chaque création d'interface vif, nous allons donc modifier le script /etc/xen/scripts/vif-bridge:
[....]
case "$command" in
online)
setup_virtual_bridge_port "$dev"
mtu="`ip link show $bridge | awk '/mtu/ { print $5 }'`"
if [ -n "$mtu" ] && [ "$mtu" -gt 0 ]
then
ip link set $dev mtu $mtu || :
fi
add_to_bridge "$bridge" "$dev"
;;
devient:
[....]
case "$command" in
online)
setup_virtual_bridge_port "$dev"
mtu="`ip link show $bridge | awk '/mtu/ { print $5 }'`"
if [ -n "$mtu" ] && [ "$mtu" -gt 0 ]
then
ip link set $dev mtu $mtu || :
fi
ethtool -K "$dev" tso off gso off gro off tx off rx off
ifconfig "$dev" txqueuelen 1024
add_to_bridge "$bridge" "$dev"
;;
Sur ma configuration, ces deux petites lignes permettront de faire passer le débit de "3-4 Mb/s quand ça fonctionne" à "environ 400Mb/s et ça fonctionne tout le temps", ce qui est quand même assez appréciable (c'est apparemment la limite de mon serveur de fichier qui commence à se faire vieux), il faut bien le reconnaître, et sans aucune substance illégale, en plus !
Il sera probablement nécessaire de désactiver les mêmes fonctions au niveau de votre VM firewall, si celle-ci ne le fait pas automatiquement. Dans mon cas, c'est fait nativement.
En théorie, sur un réseau Gb, on gagnerait encore en performances en utilisant des jumbo frames, sauf que, toujours sur ma version actuelle de Xen, le support des jumbo frames est expérimental....
Pour résumer la configuration finale (oui, j'aurais pu directement vous donner cette configuration, mais l'intensité narrative y aurait perdu, et je me trouve à vrai dire déjà assez sympa comme ça de vous faire un résumé) de /etc/network/interfaces va donner, pour une interface ethx (oui, vous ferez à nouveau l'effort de remplacer x par le bon numéro, et de faire la conf pour chaque interface):
auto ethx brx
iface ethx inet manual
hwaddress fe:ff:ff:ff:ff:ff
iface brx inet manual
bridge_ports ethx
bridge_stp off
bridge_waitport 0
bridge_fd 0
hwaddress fe:ff:ff:ff:ff:ff
Et vous mettrez "bridge_ports none" au lieu de "bridge_ports ethx" pour les bridges non reliés à une interface physique, et vous ferez la modification de configuration qui va bien pour le bridge qui aura une adresse IP.
A partir de là, c'est un fonctionnement et une configuration normales au niveau de la VM firewall. Dans mon cas, j'ai une interface externe sur un plan d'adressage dédié (zone encadrée en rouge sur le schéma du début), et toutes les autres interfaces du firewall (chacun encadré en bleu sur le même schéma) sont mises dans un bridge commun (au niveau du firewall, donc).
Il reste à faire la configuration réseau de la VM, les règles de filtrage, la configuration IPS, le NAT, et tout ce qui est à configurer lors d'un déploiement de firewall.
A partir de ce moment, installer d'autres VMs sur l'hyperviseur est une activité classique:
On récupère de quoi faire une install, comme par exemple l'image ISO Debian pour une installation de DomU, on fait "ce qu'il faut" pour avoir un espace disque (dans mon cas, donc, qemu-img create, mais il parait que c'est plus tendance d'utiliser lvm), et on lance l'install en suivant un tutoriel classique d'installation de VM pour Xen.
Pour les archives, je rajoute à la configuration Xen de cette VM:
extra = "console=hvc0"
Cette commande me permettra d'accéder à la console de la VM depuis un shell de l'hyperviseur (il me semble qu'il fallait aussi faire une modif dans la conf grub de la VM......).
La seule subtilité de notre configuration par rapport aux tutoriels standards est fort logiquement au niveau de la configuration réseau. Si on veut relier la VM à l'interface x du firewall (et comme on a fait un numérotage propre et homogène sur toute la ligne), on aura:
vif = [
'bridge=brx,model=e1000,mac=00:16:3e:<de l'hexa>'
]
Bon, ok, du monde, peut être pas, mais de mon hyperviseur et de ma VM firewall, en tout cas, oui, du moins tant que je conserve des mots de passe et une configuration de filtrage corrects.
Ca n'est pas forcément hyper efficace pour pecho en boite, et c'est déjà parfois assez limite comme sujet de discussion quand des amis passent à la maison et demandent naivement "quoi de neuf".
Ca pourrait faire le café, mais comme je n'en bois pas, je n'ai pas testé.
Mais au moins, ca permet d'avoir un firewall/IPS/UTM qui protège le réseau physique ET les machines virtuelles, tout en conservant une quantité de serveurs limitée, et si vous relisez bien le début du post, je n'avais pas promis plus !
lundi, juin 3 2013
Par Vanhu le lundi, juin 3 2013, 14:08 - En direct de la ou je suis
Normalement, ces jours ci, je devais publier une série de billets pour bloguer en direct du SSTIC.
Pour différentes raisons perso et pro, je ne serai cependant pas présent au SSTIC cette année.....
Du coup, pas de photos en quasi live des coulisses et pauses café, pas de commentaires personnels et subjectifs sur les présentations et les conférenciers, pas de sous entendus pourris, pas de lecteurs de flux RSS qui vont chauffer comme des fous, tout ça .....
Pas non plus d’enchaînements de soirées longues et alcoolisées suivies par des lendemains difficiles.....
Bon symposium à ceux qui y seront, et peut être à l'année prochaine ?
samedi, juin 9 2012
Par Vanhu le samedi, juin 9 2012, 14:34 - En direct de la ou je suis
9h30 du mat...... déjà plusieurs personnes à attendre dehors quand on arrive, et le remplissage de l'amphi est très très honnête pour un lendemain matin de social event:
Bon, entre le sujet et le ton de voix du speaker, on s'en sort bien pour attaquer un vendredi matin..... réveil très progressif d'organisé, même, puisque les orgas prendront soin de lui filer un micro qui fonctionne vers la moitié de la conf (ce qui vaudra un "ah, mais y parlait, le gars" dans la salle pas loin de moi :-) ).
Niveau contenu, c'est ...... bah...... un air de déjà vu, sauf qu'à l'époque c'était sur IPv4, et y'avait un peu moins de mécaniques à gérer......
Ou ça parlerait de comparaison entre le filtrage sous Linux et celui des BSDs
Eric commence en fait par présenter le suivi stateful, version simple, puis version moisie, quand on doit par exemple filtrer proprement du FTP. Quand on connaît, c'est chiant à suivre...... mais je me souviens d'un petit détail: environ 50% de sang frais au SSTIC...... dans cette proportion, combien de gens sont en fait en train d'apprendre (ou de se rappeler) comment ça fonctionne ? Probablement plus que ce que je pourrais croire......
La suite devient carrément plus intéressante: une démo bien faite de passage au travers d'un NAT.... dans le sens pas facile, évidemment: de l'extérieur vers une machine NATée..... le genre de cas de figure ou plein de gens croient qu'ils sont protégés.
On ne le répétera donc jamais assez: le NAT n'est PAS une protection !!!!!
Un autre conseil que je retiendrai: "choisissez bien votre prestataire quand vous déployez un Checkpoint"......
Cerise sur le gâteau: l'outil OpenSVP utilisé pour la démo est releasé en direct à la fin de la conf.
BGP, c'est en gros un protocole qui permet aux "gros tuyaux du net" de s'échanger leurs routes...... bref, c'est une des briques de base qui permettent à internet de tourner....
Et quand on voit les exemples de foirages de confs BGP ici et la dans le monde, c'est un miracle qu'internet ne soit pas par terre plus souvent !!!!!!
Première présentation courte de la session de ce matin, faite par une moulasse un salopard de lâcheur de traître un suisse un boulet qui a failli oublier son sac à l’hôtel ce matin Clem1, un petit gars de chez google.... mais qui ne fait PAS une pres en tant que google: y'a le disclaimer dès le premier slide.
Ca c'est de la près de SSTIC: du backtrace de crash kernel (à moitié masqué, la vuln a été récemment reportée chez FreeBSD mais le fix n'est pas encore public), des explications détaillées sur un écrasage de HEAP, tout ça.....
Le fuzzeur de sockets de Clem1 sera (est ?) dispo sais pas ou (mais bon, une recherche google devrait permettre de trouver......).
Faudra que je pense à me faire dédicacer une photo à l'occasion ;-)
Bon, bah voila, on est chauds pour écouter des trucs sur les pointeurs, le stack, tout ca, et c'est reparti !!
La, l'idée est de suivre, dans le code, les pointeurs kernel et les pointeurs userland..... ca a l'air intéressant, mais pas forcément très clair (ou alors c'est moi qui ai pas encore fini de digérer ma salade de fruits d'hier......).
Par contre, une fois de plus, ne faites PAS de démo en live, ca donne juste ca:
Waw, le titre est presque aussi long que le temps imparti pour cette dernière mini présentation....
Faut reconnaitre, réussir à capter son public quand on parle d'entropies et d'autres trucs mathématiques et probabilistes, ca impose le respect.....
Un des slides choppé à l'arrache (on espère tous qu'il pensera à publier !!!! :-) ):
Bon.... en résumé, l'analyse statique, c'est bien, mais ça marche pas vraiment...... voila, voila.....
Les salauds, si on faisait pas attention, ce midi, on pouvait se retrouver à manger une platrée de carottes......
Le temps pour certains de récupérer un peu avant la dernière ligne droite.....
La dernière ligne droite démarre vite, Fabrice a l'air d'avoir beaucoup de choses à dire en peu de temps...... voyons la première partie "torchée à mort".....
Bon, ok, il déconnait pas, ça va très vite (une sorte de Robert "Machinegun" Watson, mais avec l'accent du sud, en fait)..... j'ai juste eu le temps de retenir "cocolasticot" la calculatrice, et le fait qu'un truc se serait perdu au cactus ???
"l'assembleur, c'est un peu velu, ça pique aux yeux"...... la moitié de l'amphi doit être (un peu) rassurée :-)
"le but c'est de comprendre ce qu'on fait"..... c'était bien la peine de les rassurer y'a 5 minutes !
Probablement une des présentations qui aura été comprise par le plus bas taux de personnes, mais paradoxalement suivie par tout le monde (sauf un qui dort, apparemment).
je résumerai donc en une citation: "depuis tout à l'heure je suis en train de vous dire que j'ai refait qemu" (à lire très très vite) et une conclusion: si vous avez vaguement compris le sujet, allez voir miasm, et récupérer les slides !
Ou alors c'est pour pouvoir faire du rap à partir d'une bible dont vous êtes le héros ?
Cool, il commence par répondre à la question que je me posais: un baseband (apparemment à ne pas prononcer comme "serial killer" et, on vient de me le préciser, à ne pas confondre avec un boys band), donc, c'est "la carte mère d'un téléphone portable".....
Et, comparé à la présentation précédente, on va apparemment avoir tout le temps nécessaire pour suivre..... au final, disons que si la sécurité bas niveau des téléphones vous intéresse, bah allez récupérer ses slides et/ou son papier.....
Dernière conférence, par un représentant de l'état major des armées, rien que ça. On peut aussi noter que le SSTIC finit cette année comme il a commencé: par une cravate !
Point de vue intéressant: certaines attaques informatiques sont vues comme de véritables opérations (para?)militaires, organisées, planifiées, lancées sur une longue période.
Autre observation: une attaque a beaucoup plus de chances de réussir si elle repose en partie sur un utilisateur interne du système (conscient ou non de sa participation à l'attaque).
Si le sujet vous tente, lisez les actes les slides.....
A défaut de suivre attentivement la fin de la conférence, j'aurai au moins pu chopper en flag un pourrisseur de bande passante ici:
Et un fan (de mon blog ou de pokemons ?):
Faut décidément que je pense à faire une prochaine année ma rump sur "c'est bien sympa de blinder vos wifis et de dégainer le chiffrement, les gars, mais moi j'ai un gros téléobjectif, un gros capteur et je suis tous les ans au fond de l'amphi..........."
Eh oui, le SSTIC 2012, c'est fini, même si certains traînent visiblement un peu avant de partir:
Le temps de faire une dernière photo des orgas qui ont encore fait un travail de fous pour l'édition de cette année:
Et on se fait des bisous, on verse une petite larme, on se promet de s'envoyer des cartes postales mails tweets, et normalement, on se reverra au moins l'année prochaine.
Par Vanhu le samedi, juin 9 2012, 14:33 - En direct de la ou je suis
Une fois n'est pas coutume (mais si ça peut le devenir, c'est ok pour moi), le social event aura mérité son billet dédié.....
Ah, bah voila, depuis des années que je passe pas loin, je sais enfin à quoi ressemble la devanture du cactus:
Déjà, à l'arrivée, ça déconne pas, contrôle des badges:
Désolé, j'ai pas pu enregistrer le méga effet multimédia qui permettait de savoir que notre badge avait été correctement lu....
Une fois cette formalité passée, on peut aller se ruer sur les premiers amuses gueules dispos:
Et c'est parti pour la soirée:
Et bien sur, ça fait aussi du social:
C'est enfin l'heure de la surprise, et l'équipe d'orga démarre le show:
Pour un anniversaire, logique, on a droit à un gateau:
Et à quelques discours (ouais, forcément, en images, on se rend moins compte de ce qui a été dit, même pour ceux qui savent lire sur les lèvres):
(rahlala, comment j'ai honte de ma photo, la ..... et il me reste peu de temps pour tenter d'en faire une autre qui lui rende honneur !!!!)
La surprise, c'est aussi champagne openbar pour le reste de la soirée !!!!!
C'est à croire que les orgas veulent vraiment faire boire tout le monde, surtout quand on voit les techniques fourbes type "regard presque implorant d'une serveuse sympa et mignonne quand elle vous demande si vous voulez être resservi":
C'est tellement efficace que je me suis même retrouvé à manger une salade de fruits !
Si je suis malade vendredi, ca sera à cause de cette salade de fruits, c'est certain........
Par Vanhu le samedi, juin 9 2012, 14:32 - En direct de la ou je suis
Le matin au SSTIC, c'est pas très fréquent d'avoir tout le monde à l'heure pour la première conf.
Bon, en même temps, cette année, il y a également des travaux sur les routes partout autour du campus, ce qui n'aide pas à arriver à l'heure. Entre ça et la météo pourrie, je me croirais à la maison !
Pour le remplissage de l'amphi, donc, cette année ne déroge pas à la règle:
Faut dire aussi, le premier sujet du matin est un classique du genre ici: une conf sur les javacards. Pour ma sœur, et pour ma blonde préférée, non, on ne va pas parler ici des cartes de vœux en java que n'importe qui peut s'envoyer par mail (en faisant la recherche en français pour le lien, j'ai trouvé que ca, pourtant.....), mais de cartes format "carte de crédit" dans lesquelles on fait tourner des applications en java. Et la, bah on veut de la sécurité, alors qu'on a déjà pas beaucoup de place pour faire tourner les machins......
Donc, disais-je, ce genre de sujets est un classique ici: il y a tout à fait sa place, ca parle de sécurité, c'est technique, tout ca, et pourtant, personne ne vous dira clairement que ca le passionne d'écouter...... certains sous-entendront même que bon, pas de chance, pendant cette conf la, ils avaient piscine, tout ca.....
Du coup, en caler une en première conf un matin, je soupçonne quelques personnes de s'être dit "si j'arrive un peu en retard à celle la, c'est pas très grave......."
Pendant que l'amphi se remplit (plutôt bien, faut reconnaître).....
La conf est finalement assez conforme à ce à quoi je m'attendais: c'est technique, c'est probablement très intéressant pour les gens qui s'intéressent au sujet, et pour les autres, bah on suit vaguement, en se disant "waw, ca à l'air pas mal, faudrait que je regarde le sujet d'un peu plus près un de ces jours", mais on le fera jamais, même un dimanche après midi quand on aura zappé 3 fois l'ensemble des chaînes à la télé pour constater qu'on a le choix entre un épisode de Friends qu'on a déjà vu 0xFFFF fois, Derrick ou un truc de télé réalité (faudra que je regarde un truc de télé-réalité un de ces jours, je suis même pas foutu de citer un exemple)........
La conclusion me fait quand même un peu froid dans le dos: "la carte d'exemple implémente toutes les sécurités de la norme, plus des sécurités complémentaires, mais c'est pas grave, on sait la péter et en faire ce qu'on veut....."
Ah, on parlait de classiques, justement.... celle ci en est un autre: l'attaque par un vecteur matériel.
On a vu il y a quelques années l'attaque par canaux DMA (via Firewire), l'attaque par le bus PCI, cette année, c'est par PCI Express, faut bien se moderniser un peu (est-ce que quelqu'un présent au premier SSTIC peut confirmer qu'il y avait bien une attaque par bus ISA présentée cette année la ?).
Autant la première année, on trouve ca bluffant (surtout l'outil d'exploitation mémoire présenté par l'attaquant Firewire), mais au bout d'un certain temps, on finit par juste écouter d'une oreille distraite en se disant à un moment "ah ouais, en pétant la mémoire comma ça aussi, ça fonctionne..... logique......".
Bah voila, via PCI Express aussi, ça fonctionne....... la démo d'attaque directe du contrôleur clavier est marrante, faut reconnaître.
Sujet qui m'intéresse pas mal à priori, et qui est présenté ce matin par un représentant (ouch, le directeur juridique, qui attaque sans slides....) d'une société que je ne peux plus critiquer depuis quelques jours, pour raisons familiales, dirons-nous.....
Décidément, les subtilités juridiques, c'est pas mon truc..... le sujet reste cependant très intéressant, pour toute personne qui peut un jour se retrouver "hébergeur"..... et vu la définition, rien qu'en autorisant les gens à poster des commentaires sur ce blog, apparemment, je suis hébergeur......
Au moins, la conf sans slides, ca permet de faire une vue du fond de salle:
Pendant ce temps, il y a des orgas de corvée d'accueil qui bossent dur:
Et nous, on peut méditer tranquillement en profitant du jardin "ambiance japonaise"...
Et les fumeurs peuvent s'entasser à l'abri:
Un peu de stats sur le challenge, cette année, il semblerait qu'aucun bourrin n'ait tenté le bruteforce sur les emails (faut vraiment être vicieux pour avoir des idées comme ca..... faudra que je pense à releaser le script sous une licence opensource quelconque un de ces jours......).
Le challenge de cette année était finalement aussi compliqué à créer qu'à attaquer..... c'est déjà ca comme consolation ! Alors que pourtant, il y avait de supers lots à gagner, pour motiver les gens:
La solution présentée est assez dense en "et la ca se complique", "la ça devient vicieux", etc..... et l'auteur mérite vraiment sa salve d'applaudissements !
Pour les plus pressés, en attendant la publication des solutions officielles, une autre solution est déjà en ligne
Nouveau format cette année, plus court qu'une présentation normale, mais plus long qu'une rump..... voyons ce que ça donne.
Bon, honnêtement, entre suivre la conf et pouvoir faire mumuse tester un 5D MkIII sympathiquement prété par l'ANSSI mon voisin, j'ai craqué :-)
(mais non, je ne changerai pas pour l'instant, même si la différence de bruit au déclenchement est impressionnante)
Heureusement qu'il y a des gens sérieux qui blogguent aussi, j'avais même pas eu le temps de recopier le titre de cette présentation jusqu'au bout (et elle n'apparait pas sur le programme du SSTIC, qui dit juste "présentations courtes").
Bon, vu le sujet, et maintenant que vous avez le lien direct n0secure à portée de souris, hein.......... surtout que j'avais pris il y a quelques années déjà la bonne résolution de ne plus jamais parler ici de pots de miel........
Ah, voila un sujet qui devrait nettement plus accrocher mon attention !
L'outil en question fait donc une analyse puis une instrumentation d'un programme (en C, donc) pour vérifier des invariants..... dans l'idée de base, ca me fait un peu penser à PaX présenté hier en keynote, ou j'en tire la même conclusion: j'aimerais bien pouvoir dire que ces outils sont inutiles et qu'il "suffit" de programmer correctement, mais dans la vraie vie, ça ne se passe pas comme ça........
Je suis aussi assez curieux de voir si cette instrumentation est efficace sur tout type de code en C.
On finit sur une démo, en live, ces jeunes qui ne se rendent pas compte des risques énormes de ce genre d'exercice..... heureusement que l'équipe d'orga est rodée:
Ouais, encore un sujet qui me passionne..... et vu le nombre de gens qui sortent de l'amphi avant le début de cette présentation, je suis pas le seul......
En arriver à finir les assiettes des autres au RU, franchement, je commence à me faire flipper, la......
A priori, tout le monde attend cette conf avec beaucoup, beaucoup d'impatience......
En cause, en particulier, l'actualité très récente liée à l'auteur de la pres (merci à Ronan pour le billet très détaillé sur le sujet, ca m'évite de devoir le faire :-) ).
En gros, un blogueur très connu, qui gardait bien son anonymat, se serait fait "péter le blog" (comme on dit pas très courtoisement), hier ou ce matin, et son identité réelle a été révélée par l'attaquant, sur le site même (note pour moi même: j'ai bien fait de pas faire un blog anonyme, comme ça au moins, c'est une raison de l'attaquer en moins......). Sauf que, sur le programme du SSTIC (lien du titre), c'est bien indiqué "Par Mem Zythom"..... mais forcément, j'avais pas fait gaffe avant si c'était déjà indiqué comme ça, ou si ça a été modifié à l'arrache, maintenant qu'on sait, de toutes façons.......
Suspense, donc, pendant encore 20 bonnes minutes avant le début !
Bon, bah voila, c'est pas un fake, donc, comme il le dit lui même: il fait maintenant partie du club des défacés anonymes (lu sur twitter: "Si à 50 ans ton blog n'a pas été défacé, c'est que t'as raté ta vie numérique")....
En exclu intergalactique (et après demande à l'intéressé, Ze photo :
Après un point sur cette actu, la vraie conf commence..... et faut avouer, il sait donner envie de devenir expert judiciaire !!!
Pour les statistiques: ca y est, on aura parlé de Photorec cette année.
Partie intéressante, et je m'étais souvent posé la question: la technique de sécurité la plus "balaise" qu'il a du contourner dans son activité, c'est un truc chiffré avec TrueCrypt, et encore, y'avait le mot de passe correspondant qui trainait sur un fichier du disque......
Autant dire que des gars vicieux capables de concevoir un challenge SSTIC seraient tranquilles pendant des années s'ils voulaient planquer des trucs (ou alors faudrait déclarer les challengers comme experts judiciaires ?).
En conclusion, un métier une activité complémentaire qui a l'air très intéressante, mais aussi pas mal éprouvante selon les dossiers qu'on doit traiter, et pour laquelle on rencontre des problèmes très variés, y compris l'épineux problème de la déclaration de ses revenus d'expert judiciaire pour les impôts !!
Je vous ai déjà parlé de mon allergie notoire aux pommes ? non ? on y reviendra dans le billet sur le social event, alors.......
Pendant ce temps, y'a un pauvre gars devant moi qui perd la moitié de son écran à chaque fois que je fais une photo:
Comme tous les ans, c'est un moment fort du SSTIC, et ça se pousse au portillon pour venir rumper comme des oufs:
En regardant de plus près, on notera que, d'une personne à l'autre, la concentration n'est pas la même:
Comme tous les ans, la règle est simple: 3 minutes 30, cette année, pas une seconde de plus (les applaudissements du public seront la pour couper la présentation), un poil de rab est raccordé au cas ou un rumper toucherait le saint graal (non, rien à voir avec un pot de miel !): un public médusé qui le laisse continuer au dela du temps limite.
Mais revoyons la scène au ralenti (en espérant qu'ils soient bien passés dans l'ordre annoncé, ou en espérant que je me rende compte d'une inversion, ce qui n'est pas gagné d'avance....):
Bah.... on a échappé à des trucs....... originaux.......
Erwan avait présenté l'année dernier un toolkit pour faire mumuse avec du XSS. Depuis, il s'est rendu compte que, en fonction du comportement d'un navigateur par rapport à quelques tests, on pouvait facilement l'identifier, voire le classifier. L'idée a l'air intéressante, quoique j'ai pas bien compris l'intéret des graphes à la fin.
Par contre, le style rappeur, c'est original:
Euh.... j'ai rien compris à l'intéret du truc présenté..... par contre, il a pas précisé si c'était certifié ISO 27001.......
Edit
Depuis mon retour du SSTIC, j'ai été sympathiquement contacté par Florian (l'auteur de la rump), qui m'a envoyé le papier de la rump en question.
La première information que j'en ai déduit, c'est qu'il y a donc de vrais gens qui lisent ce blog..... il va donc falloir que je commence à faire attention à ce que j'écris !
Ou alors je mettrai un plus gros disclaimer au début des billets "live blogging"....... ouais, je vais faire ça, en fait......
Sinon, en lisant l'abstract (ouais, je fais mon gars super occupé qui n'a le temps de lire que les abstracts :-) ), je comprends un peu mieux le "pourquoi" du truc.
Si j'étais le genre de gars à faire des raccourcis à 2 balles (et encore, c'est parce que j'ai pas la monnaie sur moi), je reprendrais un résumé fait par une personne que je ne nommerai pas qui a dit un truc genre "c'est LDAP over DNS".
Il se trouve que je suis effectivement le genre de gars à faire des raccourcis à 2 balles, mais présentement, j'ai choppé une info dans l'abstract qui a attiré mon attention: une partie de la mécanique sert à générer / utiliser des clés de chiffrement/signature utilisateurs, typiquement pour ses mails, sans avoir à sortir l'artillerie lourde d'une PKI.
Et autant ma sœur ou ma blonde préférée peuvent compter sur leur informaticien de service pour monter une PKi et leur signer leur certificat (enfin, une fois que j'aurai réussi à les convaincre que ça sert à quelque chose, forcément....), autant pour le voisin de la grand tante du cousin par Germain de la marâtre de tata Lucette, je vais pas forcément faire l'effort (d'autant plus que, en y réfléchissant bien, je n'ai pas de tata Lucette, de toutes façons.....).
Conclusion: bah va falloir que je trouve du temps pour lire l'article........
Entre temps, les slides et le papier court sont en ligne.
Wireshark est ZE outil utilisé par plein de monde pour observer ce qui se passe sur les réseaux (analyser un problème, etc....). Il sait décoder une quantité monstrueuse de protocoles..... ca représente beaucoup de lignes de code.... donc des bugs potentiels, forcément.
Comme les données arrivent en direct du réseau, et que wireshark tourne souvent avec des privilèges élevés (pour pouvoir écouter tout le réseau, justement), c'est une cible de choix pour une attaque, et c'est donc intéressant de chercher ces éventuels bugs pour les corriger.
En résumé, on voit les choix de fuzzing du rumper, qui lui ont permis de trouver plusieurs crashes.
Y'a des gens qui ont posé des questions, j'en déduis que c'était intéressant pour quelqu'un que ça dérange pas de passer son temps à compter les espaces pour débbuguer.......
Enfin des gens qui bossent sur des trucs utiles, qui vont limite changer la face du monde. Je n'ai pas de mots pour le décrire, le plus simple est de vos montrer le résultat lors d'une partie en live de Pokemon:
Euh.... me souviens plus..... mais ils ont releasé une version spéciale SSTIC !
Coupé un peu vite par les applaudissements du public, ça fait quelques années qu'on voit les évolutions de cette appli, qui a l'air assez puissante pour déployer des réseaux de tests en masse.
Ou comment un gars a repéré, complètement par hasard, que le serveur du SSTIC a laissé trainer pendant environ 15 jours un .htaccess qui laissait l'accès à toutes les confs soumises et pas acceptées des années précédentes, et aux version beta des près de cette année.
On notera la réaction très rapide des admins SSTIC, qui ont corrigé le problème en moins d'1h après l'envoi de l'information.
J'ai déjà pas compris ce que c'était "l'opération", alors de la à vous expliquer les détails.....
Phil nous présente une nouveauté de scapy présente depuis au moins 1 ans dans la version publiée, mais qui était apparemment passée innaperçu: un containeur qui permet de connecter des entrées et des sorties.... ca a l'air de rien comme ca, mais si je vous dis que Phil a tout simplement explosé le temps qui lui était imparti, avec un public silencieux qui voulait voir la suite, vous pourrez en tirer la conclusion évidente: allez voir, en plus y'a une documentation nickel ! ;-)
Et pour ceux qui se poseraient la question, Phil qui fait une démo sur un truc de pipes, ça ressemble à ça:
Ou comment google laisse traîner des fonctions genre:
int check_machin(args){
/* TODO */
return 1;
}
qui permettent de passer n'importe quoi à des fonctions privilégiées.
Annonce d'une conf en fin d'année, à Grenoble, ville qui a l'air d'avoir des arguments qui méritent l'attention.......
Notez qu'on ne nous a pas formellement confirmé qu'elle serait présente à la conférence...... mais ça parlait aussi de bières (ils ont de la vraie bière, à Grenoble ).
Ah, et il est encore temps de soumettre ...... des sujets pour cette conf....
Voila, voila.....
Bon, voila, les RMLLs ont lieu cette année à Genève, mais ils n'auront pas Katsuni, eux......
Nouvelle version du pare-feu officiellement validé par l'Hadopi..... ca rox des ours !
Un outil bluffant pour aller chercher de la data. Une interface, des outils de recherche bien faits, déjà pas mal de formats de fichiers supportés..... allez voir, et contribuez !!!!
On notera aussi les choix vestimentaires d'un des auteurs.... décidément, les rumps sont chaudes, cette année !!!!
Exécuter un truc dans un PDF, en soi, c'est pas folichon, ni très nouveau. La, y'a quand même un aspect technique intéressant: le code est embarqué en tant qu'image JPEG, et avoir une vraie image JPEG (ok, moche) qui est aussi interprétable en tant que code javascript, ca c'est marrant :-)
En gros, l'idée est d'émuler une carte de crédit, et pour être (un peu) plus discrets, on utilise un relai wifi et un dispositif embarqué.... à la photo, j'ai du mal à croire qu'un commerçant lambda n'aura aucun soupçon, mais bon, par rapport aux lasers que les rumpeurs utilisent d'habitude pour faire leurs malversations sur des cartes de crédit, je veux bien croire qu'il y déjà du mieux !
Ou comment hacker un QR Code avec un crayon noir et du typex. Plutôt fun, comme idée, et en plus ca fonctionne (enfin, avec un delta de résultat assez léger, je suis curieux de savoir jusqu'ou on peut aller..... ca dépend probablement du niveau de l'attaquant quand il était en grande section de maternelle, en fait.....).
Par Vanhu le samedi, juin 9 2012, 14:31 - En direct de la ou je suis
Dura vita, sed vita.......
Déjà pas mal de monde à l'inscription:
Nous découvrons rapidement les nouvelles tendances de la mode, cette année. Pour les orgas, c'est...... comment dire...... jaune, y'a pas d'autre mot:
On notera que certains l'assument plus que d'autres, et qu'il y a même eu une tentative curieuse de croisement avec un Tshirt "normal", pour un résultat d'un vert douteux également.
Vous aurez donc brillamment déduit que pour nous, cette année, c'est bleu:
Petite déception de ma part, contrairement aux années précédentes, y'a pas un grand dessin "sécurité" classe et original dans le dos, juste une grosse croix.....
Non, on a pas fait tout ce chemin pour parler des noces de porcelaine de quelqu'un (fallait bien que je fasse une blague pourrie, celle la est la moins pire.... vraiment, croyez moi sur parole), mais pour parler de PaX, en gros un ensemble de patches pour améliorer la sécurité du noyau Linux, et pour rendre plus difficile (impossible ?) l'exploitation de bugs.
Par rapport à pas mal de keynotes d'années précédentes, ça attaque quand même assez rêche, par une présentation en anglais sur ce sujet pointu. Et en cravate, en plus (photo supprimée à la demande (très courtoise) de l'équipe de PaX.... dommage, il faisait partie de ceux qui ont fait l'effort de poser quand j'ai pris la photo !).
J'aimerais bien conclure un truc genre "ces outils, c'est le mal, la vraie solution c'est de coder propre pour ne pas avoir de bugs à exploiter"........ Mais bon, je suis lucide, j'espère juste qu'il n'y a pas trop de développeurs qui se diront "bah, y'a des protections ailleurs, on s'en fout de coder propre, du coup".
Parfois, dans les conférences, c'est pas dans les présentations qu'on voit les trucs les plus hallucinants, mais dans les couloirs. Ce matin, j'ai assisté à un truc que je n'aurais jamais imaginé (garanti sans trucages !!!!):
Tiens, une conférence d'un gars de l'ANSSI...
Premier rappel: les anciennes versions de SSL ont des failles de sécurité connues..... dans la vraie vie, utilisez au moins TLSv1.1 (ca devrait être le cas pour n'importe quel client ou serveur relativement récent).
C'est marrant, si je fais abstraction des mots "SSL" et "TLS", ca ressemble finalement assez aux problèmes qu'on rencontre avec IPsec..... mauvais algos de crypto, mauvaises configuration, comment bien gérer ses autorités de certification, les listes de révocation, etc.......
A un (gros) détail près: l'utilisateur lambda (outre le fait qu'il n'y comprend rien, évidemment) ne maitrise (?) que son client web, et l'administrateur ne maitrise que la configuration de son serveur....
Ah, et je viens de découvrir l'existence d'un moteur d'IPS Opensource "Next Generation", faudra que j'y jette un coup d'oeil au calme un de ces jours.
Pendant qu'on apprend qu'il n'y a plus de papier (quand je vous dit que le SSTIC est une épreuve de survie.......), ca va rétroconcevoir des protocoles de communication, donc......
Ok, je comprends pas trop l'usage du mot "conception", il s'agirait plus d'outils d'aide pour comprendre (voire reverse-engenirer (oui, ca doit pas s'écrire comme ca, moi aussi j'ai le droit de mettre quelques fautes, et mon correcteur automatique propose "reverse-engerber", ca doit pas être ça)) un protocole existant, et/ou pour le modéliser.
C'est vrai que, présenté comme ca, le rétro-engeneering d'un protocole, ca a pas l'air simple:
Note: si quelqu'un peut m'expliquer l'intéret de l'URL encodée en base64 en bas des slides, qui point vers un lien goo.gl, qui pointe lui même vers un compte suspendu sur sarssi-conf.org (ou alors je me suis loutré en recopiant le base64 ? apparemment ça serait ca, mais comme j'ai vu 3 "bonne URL" différentes.....)
Une démo (en vidéo, ils ont pas pris de risques, c'est bien :-) ) plus tard, l'outil est vraiment sympa, quand on a (dans l'exemple) une capture réseau et qu'on veut comprendre le protocole IPv4...... bon, ok, l'exemple de la démo est pas super pertinent, mais au moins ca permet à tout le monde (?) de suivre et de vérifier ce que l'outil fonctionne, et il a l'air vraiment très sympa !
Pour mes lectrices qui se demanderaient ce qu'est RDP, c'est en très très résumé un truc pour se connecter à distance à un bureau Windows.
Et pour les gens qui veulent entrer dans ce genre de comptages mesquins, c'est une présentation faite par des gars de l'ANSSI.... 3, apparemment faut au moins ça vu le protocole (et ça a l'air dangereux, en plus !!!):
Présentation (très très) rapide du protocole par Arnaud, et... euh ..... ok, ca a l'air simple et bien organisé, comme machin........
Coté sécurité, c'est aussi un vrai bonheur...... je retiens en particulier une clé privée en dur dans une DLL, et carrément documentée par Microsoft........
C'est terrible..... au fil des ans, je crois que je commence à me faire au fait de manger au RU ici.......
Le temps pour Fred de lancer un concours, et ça repart !
WinRT, c'est en gros "le truc de base derrière les applications de la nouvelle interface Metro du prochain Windows".... autant dire que mon attention lors de cette conf est quasi absolue.......
Par contre, un speaker qui prend le temps de faire le beau gosse pour la photo, c'est bien :-)
C'est probablement pas très sympa à dire, mais j'ai trouvé cette conférence pas très intéressante......
En y réfléchissant un peu, je me dis que je suis probablement surtout déçu par rapport au niveau des confs "juridiques" des dernières années, qui avaient mis la barre très très haut en terme de qualité de présentation.
Je retiendrai quand même que, d'un point de vue juridique, il y a parfois une grosse différence entre "donnée" et "information", et que, en droit francais, le secret des affaires n'existe pas.
(note: ANSII++)
Vu le sujet, j'ai hésité à rester. Lors de la première partie, ou on a eu le droit à de grandes explications sur l'organisation interne d'un AD, j'ai vraiment du prendre sur moi pour ne pas m'enfuir en courant.
Ensuite, les auteurs sont arrivés sur le cas de figure d'une intrusion: on réinstalle à peu près tout..... sauf une grosse base de ce genre... Or, en mettant les valeurs "qui vont bien", ca suffit largement pour se donner des accès ultérieurs, par exemple.
Or, il n'y a pas d'outil standard pour auditer une base AD à grande échelle (les joies de l'interface graphique qui gère entrée par entrée quand on a un annuaire à plusieurs milliers voire millions d'entrées.......), donc les auteurs ont fait leur outil maison d'audit à grande échelle.
Bah, mis à part le fait que faudrait que je commence par installer un AD pour commencer à réfléchir à envisager de m'en servir, ca avait l'air puissant, leur machin !!!
Super, encore un sujet original et qui va me passionner...... mais bon, c'est finalement assez logique d'avoir ce sujet ici, et à part moi, ca doit probablement intéresser pas mal de gens......
Après rapide vérification de la bio, le speaker est un représentant de Microsoft France, donc inutile d'attendre le moment ou on pourrait entendre "et la on peut contourner le truc à machin"...... bref, aucun intéret pour moi, d'autant plus que j'ai vraiment l'impression d'être devant un discours de vendeur: déroulement d'un cas de figure, peu/pas de détails sur comment ca fonctionne vraiment (UEFI et TPM sont magiques, ils protègent de tout.....), aucune réflexion sur "et comment on pourrait tenter de contourner ce nouveau système" (ou alors j'avais déjà décroché ?)......
Bref, vivement les questions, et la pres suivante !
Par Fred Raynal, Nicolas Fischbach, Philippe Biondi...... bah ouais, forcément, n'importe qui ne peut pas se permettre de faire ce genre de récapitulatif historique..... eux, ils le peuvent:
Fred nous explique comment l'idée est arrivée au début des années 2000 (en résumé, une soirée trop arrosée), et compare SSTIC avec les autres conférences existantes à l'époque.
Nico prend le relai pour comparer ce qui se fait aujourd'hui.
L'équipe enchaîne sur plein de stats, durée de vente des billets par année, poids du président, et le top 5 de ceux qui ont fait des présentations ici.
Viennent ensuite les remerciements, en particulier pour Vero (au cas ou certains n'auraient pas entendu Fred le dire), puis la liste des epic fails (il y a eu un coma éthylique en 2010 ? et il n'y en avait jamais eu avant ?).
Ca finit par un cocktail (en retard à cause du débordement de la dernière pres, mais on leur pardonne volontiers), et pour moi, par une petite crêpe (bah oui, on est en Bretagne, c'est limite obligé) pour ensuite rentrer m'écrouler.....
Au pire, demain, je dirai à Renaud que je l'ai attendu au Cactus..........
Par Vanhu le samedi, juin 9 2012, 14:30 - En direct de la ou je suis
Nettoyage rapide des quelques commentaires spams qui atterrissent ici de temps en temps, relecture rapide des années précédentes pour se souvenir comment ca fonctionne, et c'est reparti pour 4 jours intenses: le ANSSSTIC 2012 est arrivé !
Méthode habituelle: 1 billet par jour, en commençant par l'arrivée la veille au soir, des mises à jour de billets dans tous les sens à faire fumer les lecteurs de flux RSS, un tag pour les billets de l'année, des photos rajoutées plus ou moins au fur et à mesure, et Sid est dans la salle, son portable allumé, donc pour un suivi sérieux et pertinent des confs, c'est à priori par la, voire aussi sur n0secure, avec plus de détails, et des fotes en prime :-)
Ah, et bien sur, les outils modernes, channels #SSTIC, #anSSTIC et #trollSSTIC...... Faudra vraiment que je prenne un jour le temps de trouver un client correct pour ce machin...... ou pas......
Dernière respiration calme, et voila, ce billet est publié (mais va quand même être remodifié dans tous les sens ces jours ci), c'est parti !
Comme depuis quelques années, on est venus en voiture..... Après avoir un peu tiqué en apprenant qu'on aurait une Citroen C4 (j'ai de vieux souvenirs douloureux d'une édition des RMLLs en Citroen C2 Vert pomme......), finalement, ca s'est plutôt bien passé (pas de crevaison, pas de reboot de train pour nous, tout ca......).
Arrivés sur Rennes vers 19h, récupération d'un traitre transfuge CENSURE pote qui est parti apprendre à parler l'allemand suisse, petite bière en terrasse, et repas au désormais traditionnel Wok de Rennes, ou j'avais cette année pris la précaution de réserver (note pour les prochaines années: les numéros de tel de leurs 2 restaurants sont inversés sur le net). Même s'ils ont eu la mauvaise idée de remplacer les serveuses de l'année dernière par des serveurs, le repas était excellent, comme chaque année (oui, on y va quand même surtout parce que c'est bon !).
Depuis plusieurs années, j'ai pris l'habitude de faire une soirée tranquille et pas tard le premier soir, histoire de garder des forces (on rajeunit pas.......).
Donc, après le repas, direction la rue St Michel (la rue de la soif, quoi), pour retourner à la très bonne trouvaille de l'année dernière: le bar qui sert 18 bières pression (dont kwak, chimay, karmeliet triple, etc.....), et qui a des saucissons en prime (ouais, j'ai pas pris de dessert au restau......).
Le temps de siroter une petite bière tranquille, et et c'est l"heure pour les gens raisonnables de rentrer à l'hôtel....
Quand c'est un inconnu, encore, ça se gère bien.....
Quand c'est un pote de SSTIC (oui, y'a les amis, les amis facebook, les potes de bar, etc.... et il y a donc les potes SSTIC), bah on traine 5 minutes, tout ça..... le temps qu'un autre arrive, on repasse une tournée, tout ca.......
Et avant de s'en rendre compte, on s'est fait chopper par une brèche dans le continuum spatio-temporel, pour arriver à l'hotel vers 2h du mat........ ça va être dur, cette année, je le sens........
dimanche, octobre 9 2011
Par Vanhu le dimanche, octobre 9 2011, 15:24 - En direct de la ou je suis
C'est parti pour le (déjà) dernier jour de cette EuroBSDCon.....
Ca commence fort, vu le titre de la keynote qui me semble ambitieux......
Après quelques statistiques sur le nombre de lignes de code de Windows, Linux et BSD au fil des ans, quelques citations dont l'idée est toujours "pour faire efficace, faites simple".....
Suit une présentation d'un modèle qui me semble "classique", à base de microkernel, de protection IOMMU, tout ca....
La conclusion que je retiens, c'est que ca rend effectivement le système plus robuste (si un composant crashe, y'a QUE ce composant qui crashe, et c'est récupérable sans planter tout l'OS), mais que ca se traine lamentablement......
D'après les derniers slides, ca serait juste une question de design des OS actuels, et ca se résoudrait en gardant à l'esprit certaines règles de conception lors de l'écriture du fameux OS en microkernel......
Et il bluffe pas, le monsieur ! Ils ont déjà une implémentation (ca s'appelle "NewtOS" pour l'instant, mais je trouve rien la dessus sur Google, et il semblerait que ca soit un nom temporaire), et leurs benchmarks face à un Linux sont corrects (ca se vaut, quoi). Ou alors ca serait implémenté sur Minix j'ai pas suivi, la......
Hier soir, au social event, on a pas fait QUE jouer au tobogan et se ballader dans un jouet géant, on a aussi tenter de créer des vocations de mainteneur de ports FreeBSD, et on a causé outils pratiques.....
Du coup, ce matin, je me retrouve à tester 2 outils:
TMux, un remplacant à screen qu'il est parait-il vachement mieux.
Pv, un truc qu'on pipe dans un flux de commandes pour avoir un affichage "graphique" de ce qui se passe (ouais, c'est pas super clair, dit comme ca, hein ?).
Bon, un lendemain matin de social event, une conf de Robert "Machine Gun", c'est hard..... heureusement que je suis resté au jus d'orange hier !!!
rwatson@ (ouais, je sais, c'est juste pour faire style de l'appeler comme ca.....) commence par nous expliquer ce qui a changé dans les modèles de sécurité du poste de travail ces dernières années.... maintenant, beaucoup de choses se jouent juste dans le navigateur, qui ne se contente plus de présenter des pages, mais qui fournit des applications complexes (et parfois plein d'applications dans un même navigateur), avec plein de possibilités, donc plein de vecteurs d'attaques possibles.
Réflexion intéressante: la séparation qui n'a finalement pas eu lieu au niveau noyau dans les années 80 (microkernels) pour des raisons de performance a finalement été assez bien acceptée dans les années 2000 au niveau des applications (privilege separation), alors que les problèmes de performance sont les mêmes.
Bon, bah à en croire le tableau récapitulatif, avec Chromium comme exemple, bah capsicum est mieux que SELinux et Sandbox (MacOSX), qui sont déjà mieux que toutes les autres implémentations (je vais même pas vous sortir le résultat de l'implémentation Windows.........).
Bon, normalement, j'aurais du aller à une autre conférence, qui parle de migrer le CVS de NetBSD (donc celui d'ipsec-tools) vers un VCS plus moderne: Fossil, que je connaissais pas, et qui me fait quand même un peu peur quand je lis sur leur page d'accueil qu'ils sont fiers d'utiliser du "bon vieux HTTP" pour la couche de comm.... J'espère au moins qu'ils ont prévu l'option HTTPS, ne serait-ce que pour authentifier les commits.......
Et donc, j'ai finalement choisi (après une réflexion intense) de plutot venir suivre une sorte de visite guidée de FreeNAS 8, vu que je me pose la question de le déployer chez moi depuis quelques semaines.......
Ca commence donc par un (gros) historique du projet (enfin, ca commence vraiment par un bricolage en live d'un Xorg pour pouvoir utiliser le vidéoproj, mais bon...)..... c'est pas que c'est pas intéressant, mais bon, disons que c'est pas ce que j'espérais pour cette pres.........
On a ensuite enfin droit à une présentation des fonctionnalités du truc..... enfin, une démo de l'interface graphique..... tout le monde connait mon point de vue sur ce genre de démos dans une présentation ?
Au final, un peu déçu, du coup, mais uniquement par la pres, pas du tout par le projet qui a l'air vraiment intéressant, et pour lequel il faudra décidément que je monte une machine correcte (comprendre au moins quelques To de disque et 6Go de RAM) pour tester ca !!!
Après une pause déjeunersandwich (j'en ai maaaaare des sandwiches !!!!!), on repart sur ..... euh .... vu le début, apparemment, le fait qu'un OS ne sert plus à rien
En fait, c'est une vision assez intéressante de l'usage des ordinateurs aujourd'hui: le navigateur peut presque être considéré comme un "OS" de plus haut niveau, la tendance est à bouger tout dans "le cloud" de toutes façons, et des trucs comme TCP/IP n'avaient pas au départ été conçus pour un usage dans les résaux modernes (très haute vitesse, nombreuses machines locales, beaucoup de flux réseaux, etc....).
Sur une transition que j'ai à moitié suivi, on en arrive à des conseils sur la gestion d'un parc de machines..... Un seul /etc pour tout le monde (pas con, effectivement), et..... un / dans git
Au final, une vision assez intéressante du management de masse de serveurs UNIX, avec des idées assez proches de ce que je fais déjà pour mes VMs, et d'autres bien bourrin comme j'aime :-D
Bon.... j'aurais pu bouger de salle et aller voir les nouveautés d'OpenSSH.....
Et puis j'ai fait ma feignasse (un dimanche après midi, on peut, quand même, non ???) et je suis resté dans la salle pour suivre ca, donc..... pas certain que le sujet soit passionnant, mais le gars a déjà gagé le prix de la présentation avec le plus d'effets spéciaux !!
Bon, bah HAST c'est un truc qui a l'air sympa, reste plus qu'à attendre qu'il soit intégré dans FreeNAS......
La dernière fois que j'ai suivi une pres d'Alistair, fallait résoudre des rébus compliqués...... voyons si ca va être plus facile à suivre cette fois ci !
Apparemment, in est toujours question d'images, mais cette fois il s'agit d'images JPEG "embarassing"...... ah, donc c'est une conf sur "comment planquer son pr0n" !!!!!!
Point de départ assez intéressant quand vous voulez chiffrer et protéger vos données..... voire carrément un point de départ intéressant si vous voulez implémenter votre propre solution, en fait....
Bah ouais, cette année fera partie des années "séchage de la closing session", histoire d'anticiper le temps qu'on va perdre à la frontière en faisant le trajet "Amsterdam - Lille".......
Et puis, on va s'arréter sur la route pour prendre un petit sandwich......... ou pas.......
samedi, octobre 8 2011
Par Vanhu le samedi, octobre 8 2011, 16:38 - En direct de la ou je suis
Enfin, je crois que c'est le "day 1", si on compte pas la journée de tutoriels d'hier.....
Disons que j'ai pas besoin de vous expliquer qui est (enfin, était) DigiNotar, n'importe quel moteur de recherche vous donnera pléthore de liens vers des explications diverses et variées sur ce qui leur est arrivé.....
Première remarque intéressante: une autre autorité de certification (Comodo) s'est fait hacker cette année..... 3 fois, même.... et est encore la, et est toujours la 2eme CA au monde....
Seconde remarque très intéressante: est-ce normal d'utiliser un "proxy" (une personne/entité tierce, en l'occurence) pour faire confiance à quelqu'un ? Pourtant, c'est exactement le modèle des autorités de certification !
Au passage, j'apprends l'existence de projets intéressants, comme Perspectives Project, qui veut en gros valider autrement les certificats SSL (ca me fait curieusement penser à GPG, avec "les gens en qui j'ai confiance pour valider des trucs"). Très intéressant, comme idée, même si j'ai un curieux doute sur le fait que ca résolve vraiment le problème..... Après tout, on ne fait que déporter le problème: au lieu de faire confiance à des sociétés qui sont finalement la avant tout pour faire des sousous, on fait confiance à "des entités", dont la plupart n'ont probablement aucune vraie connaissance leur permettant de certifier un certificat......
Sinon, note pour plus tard: faire une keynote à une conf un de ces jours, et mettre dans les slides juste quelques titres, et des images psychédéliques qui ont un lien confus avec le sujet.
A peine le temps de réduire un peu mon espérance de vie, et nous voila repartis, pour une conf qui devrait parler d'optimisation de code pour des trucs liés au réseau, ca devrait être intéressant.....
Bon, finalement, c'est une propagande genre "utilisez netmap pour faire votre comm entre le noyau et le userland..... ca reste très intéressant vu les benchs présentés..... enfin, quand on doit remonter les paquets dans le userland......
A comparer éventuellement avec un autre projet qui a l'air d'être dans la même idée (merci Alexis pour l'info): ringmap
Aie, je risque de devoir bientôt expliquer IPv6 à ma soeur, moi.....
Mais bon, j'ai presque pas le choix de la conf cette fois: ca parle FreeBSD, IPv6, et c'est bz@ qui fait la pres, alors..... C'est pas une surprise pour moi, puisque je l'ai vu un peu au fur et à mesure sur ses commits dans le stack IP, mais bz@ a fait un gros boulot pour faire avancer le support d'IPv6 dans FreeBSD..... bien sur, ca fait longtemps qu'on peut avoir une IPv6 sous FreeBSD, mais il a poussé la barre beaucoup plus haut, entre autres jusqu'à avoir un FreeBSD "IPv6 only" (donc sans IPv4 du tout, y compris au niveau des options de compilation du kernel) fonctionnel.
Le pain, c'est bien (enfin, quand y'a pas d'olives dedans....). Le truc en dessert qui a l'air à peine gras (avec du beurre en prime, "au cas ou"), c'est mieux.....
Y'a plus qu'a le digérer..... moi qui avais à peine fini de vider le pipe avec les ribs......
Bon, la, c'est cool: une pres qui est à la fois tagguée "NetBSD" et "firewalling".....
Reste à voir si ce "New PF" est à la hauteur de ce qu'il promet, et s'il valait la peine de bouger tout le monde vers une plus grande salle pour cette pres !
Au final, des idées sympas, mais ca reste désespérément un packet filter de niveau 3/4, même s'il semble possible de l'étendre pour en faire un IPS "moderne".... Ah, et pourquoi ils s'obstinent tous à faire une syntaxe "last match first" par défaut ???
Bah ouais, ca reste un des inconvénients d'avoir 2 sessions en parallèle (sans compter la suite du devsummit FreeBSD): des fois, on est face à un choix terrible (j'en aurai un demain) entre 2 confs qui ont l'air super intéressantes, et d'autres fois..... on a le choix entre un nouveau mode de suspend/resume pour OpenBSD ou un truc qui parle d'un serveur HTTP........
voila, voila.......
Ou on apprend que Linux et PFsense ont tous les deux un truc (pas encore mainstream) qui fait du "Layer 7 packet inspection"....... faudra creuser ca d'un peu plus près......
C'était ca ou un nouveau système d'installation / package management.......
Bah...... si vous avez l'intention de porter un OS quelconque sous Xen, récupérez ses slides, c'est un bon point de départ..... si vous vous demandez pourquoi vos OS virtualisés rament comme pas possible aussi.....
Ah, la grande époque du PDP-11, ou on (ouais, "on" au sens large du terme, j'étais pas encore né.....) avait déjà des trucs géniaux comme Pascal ou un C-Shell.....
Ca me manque pas, curieusement......
Eh oui, comme tous les ans, il y a un social event, cette année tenu très secret jusqu'au bout.
Au final, on a eu droit à un diner et une visite dans le musée du chemin de fer du coin...... ca fait longtemps que j'ai arreté de jouer au train électrique, mais faut reconnaitre que c'est grand, comme truc !!!
vendredi, octobre 7 2011
Par Vanhu le vendredi, octobre 7 2011, 17:07 - En direct de la ou je suis
Au moins pour les petits gars qui auraient du être présents aussi si y'avait pas eu un gros moteur de recherche ailleurs, c'est reparti pour une séance de live blogging (c'est bon, maintenant, vous savez comment ca se prononce, hein ??) à l'EuroBSDCon, édition "10 years", depuis Amsterdam......
En tout cas, on m'a au moins pas exactement dit la vérité, puisque, au final, on est pas à Amsterdam, mais à Maarssen.... c'est pas loin, ok, mais c'est pas pareil.....
Pour simplifier encore la compréhension de la chose, vous aurez noté que je commence également par le "Day 2", et même pas de la BSDCon, mais du DevSummit FreeBSD qui est venu s'organiser juste avant la BSDCon......
Bref, y'a plus qu'a faire des tickets journaliers qui sont édités toutes les 1/2 heures et rangés dans un ordre variable, et la confusion devrait être parfaite !
Pour les gens qui seraient tombé ici par hasard en cherchant des infos pertinentes, objectives, neutres, tout ca sur l'EuroBSDCon de cette année..... bah continuez à chercher, et bonne chance !!!
Contrairement à d'autres évènements/éditions ou on se déplace en mode "A team", ou on loupe notre avion, ou on se tape de la neige de nuit pendant 6 heures de voiture (bah ca devait déjà être l'édition karlsruhe, tiens, si je me souviens bien......), bah la, rien de spécial à signaler.....
Ah si, faudra que je retrouve l'adresse et le nom du petit restau ou on a été manger hier soir, et ou le score final, je dois bien l'avouer, est: Ribs 1 - NETASQ 0 ...... faudra revenir avec une vraie équipe de combat, histoire de sauver l'honneur !!!!!
J'en avais déjà parlé dans le billet de la BSDCon à Strasbourg, les EuroBSDCon suivent (plus ou moins bien) une logique de "1 année c'est bien, 1 année c'est nul".....
Y'a 2 ans, à Cambridge, c'était (très) bien, l'année dernière on a malheureusement loupé l'édition de Karlsruhe (ville charmante ou j'avais commencé à formuler ma théorie des séries appliquée à l'EuroBSDCon, lors de l'édition 2004, juste après la géniale édition de 2002, à Amsterdam......).
Reprenons:
(merci à UKUUG pour l'historique détaillé)
C'est parti pour 3 jours d'anglais intensif, avec des accents aussi divers et variés que parfois carrément improbables.....
L'opening est un point d'avancement de divers projets/groupes..... disons que les premiers reports sont sur des sujets passionnants, mais pour d'autres..... serveurs de diffusions de packages, chaine de compilation des sources, documentation, tout ca......
Et la, carnage un vendredi matin: Robert "machine gun" Watson (oui, rwatson@) nous parle de Capsicum en 15 minutes....... âmes sensibles qui ne savent pas suivre 150 mots anglais à la minute s'abstenir, ca va piquer......
Décidément, c'est plus un continuum, c'est une passoire...... bref, entre les reports des groupes de travail et un truc sur Git, autant dire que ca commence tranquilou pour mes quelques neurones..... enfin, je cherche quand même à résoudre un problème proche de la quadrature du cercle: faire une version condensée de ma présentation de 2007, environ 80 slides et 1 heure (ca avait déjà été juste), pour la faire tenir en 1/4 d'heure environ.... et j'ai jusqu'à ce midi pour ca, le tour de magie ayant lieu un peu avant 13h......
Bon, on va quand même suivre un peu cette pres finalement, vu que notre cher CTO s'est fait hacker pour participer à l'improviste........ Zut, va falloir brainstormer.......
Bon, utilisez git, c'est bien ...... note pour moi même: penser à m'y mettre un de ces jours.......
Donc, la, ca va parler très vite (15 minutes chacun), de PFSense, d'un gars qui n'utilise PAS FreeBSD, de FreeBSD à Cambridge, et ca sera mon tour.... tout va bien, pour l'instant il ne me reste que 40 slides, soit environ 2,6666666666666666666666 slides par minute.........
Au final, faut tasser un peu, mais ca passe.... pour une pres ou j'explique surtout que les principaux problèmes contributeur/commiteur sont des problèmes de temps, c'est même assez cohérent :-)
Comme souvent pour des conférences, on passe plus de temps à discuter qu'à manger pendant ce temps, mais la, ca vallait le coup....
En tout cas, on m'a "vendu" un nouveau Perforce FreeBSD super mieux fait et un nouveau système de mise à jour des packages FreeBSD, les deux pour la fin d'année, j'ai hate de voir ca !!!!
Bon, me suis fait hacker ma fin de pause déjeuner, suis arrivé à la bourre pour cette session.....
D'abord, la virtualisation dans Xen.... Pour résumer en 1 ligne, bah ca marche, mais y'a encore des trucs à améliorer (suspend/resume, etc....)
Ensuite, les Network Jails.... à part rajouter plein de V_ dans le code qui ont bien augmenté mon boulot de migration de patches (mais bon, bz@ a aussi sacrément bien maintenu le patch NAT-T pour FreeBSD 7, ca doit compenser), bah ca permet d'avoir une virtualisation du réseau.....
Toujours très prometteur, depuis la première année ou j'avais vu une démo, mais toujours pas "production ready". Si seulement y'avait pas des salauds qui sortent de nouveaux MMORPG régulièrement, Fabien pourrait trouver du temps pour regarder à ca ;-)
C'est parti pour parler du futur........ et la j'ai un doute: puis-je retranscrire tout ca ici sans devoir ensuite retrouver et tuer tous les lecteurs de ce blog ?
Petite question, essentiellement à moi même, je le crains, et j'ose même pas imaginer le moment ou je vais devoir expliquer ca à ma soeur:
Soit un LAN, disons en 192.168.1.0/24 pour l'exemple, mais ca fonctionne avec n'importe quel LAN en RFC 1918.
Soit un gars (pouf pouf, ah, zut, c'est tombé sur moi......) qui veut monter un tunnel IPsec jusqu'à ce LAN. Normalement, jusque la, c'est plutot facile.....
Sauf que, quand on monte un tunnel comme ca, c'est depuis "n'importe ou"..... la, le n'importe ou en question, c'est derrière un AP Wifi, qui utilise lui aussi un réseau RFC 1918..... en l'occurence, le même que celui que je veux joindre.......
Donc, je me retrouve à essayer de faire une conf ou j'explique que, pour joindre le réseau local, faut passer par un tunnel IPsec.... tant qu'à faire avec une IP source qui n'est PAS l'IP logique (celle du LAN), mais le problème se poserait aussi si la collision était avec MON extrémité de traffic plutot qu'avec celle du LAN distant......
Finalement, arno a raison: NAT is bad, et vive IPv6 pour tout le monde !!!!!!!!
vendredi, juin 10 2011
Par Vanhu le vendredi, juin 10 2011, 12:38 - En direct de la ou je suis
9h30..... lendemain du social event, taux de remplissage de l'amphi estimé à 2/3 alors que la conf vient de commencer.... plutot pas mal, comme score..... surtout quand on voit le remplissage quelques minutes avant le début de la conf:
Et ca repart de suite, donc, je sens que la journée va être longue......
Je sais pas si c'est l'heure ou le sujet (ou surement un mélange des deux), mais je n'ai écouté que d'une oreille très très distraite...... mais ca a l'air d'être un truc intéressant pour quelqu'un qui serait intéressé par des "trucs en Ruby on Rails".......
On enchaine sur des slides à vomir...... littéralement: entre la couleur de fond et les animations de transition entre les slides, j'en ai les crustacés du social event et la bière-saucisson d'après qui me signalent que je n'ai pas encore fini de les digérer.....
Le contenu est intéressant, par contre, alors que ca parle de "XML", terme auquel je suis normalement plus ou moins allergique...... et même si ca reste compliqué d'écouter en faisant bien attention de ne surtout pas regarder les slides, surtout pendant les transitions !
Et pendant ce temps, certains téléphonent encore......
A peine le temps de se mettre un peu de caféine dans le sang, et ca repart..... pour LA conf juridique de cette année, apparemment, puisqu'elle est faite par un avocat. En l'occurence, le même avocat qui avait fait la pres juridique de l'année dernière, voyons si celle de cette année est aussi passionnante (non, c'est vraiment du premier degré !!!).
Petit rappel sur les obligations légales de protection des données, des risques encourus..... du manque flagrant d'application de ces lois pour l'instant, mais ne désespérez pas: il y aura bien une plainte au pénal qui tombera un jour !
Premier point important: la loi parle manifestement d'une obligation de moyens, et pas de résultat.....
On voit ensuite, sur l'exemple de Sony, les conséquences d'une intrusion.... juridiques, financières, sur l'image de marque, etc......
Non, ca n'est pas une nouvelle maladie contagieuse..... je crois.....
Ca veut dire qu'on doit désormais avoir lu les normes (ISO, ANSSI, circulaires, etc.....), et qu'on ne peut plus se défendre derrière un "j'savais pas".
Pareil, c'est contagieux mais pas viral, il faut de plus en plus se faire certifier..... reste à voir le contenu de la certification, à quoi elle correspond, et si le prestataire éventuel certifié n'a pas pipeauté pour avoir sa certification !
Retenez au moins le conseil final:
Encore une année ou, rien que pour la conf juridique, ca valait le détour sur Rennes !!!!
Ah, une conf faite par un des principaux militants de la quadrature du net..... j'aurais pu m'en douter en lisant le sujet, en fait.... ou en lisant le nom de l'intervenant, tiens......
Jeremie nous présente donc Internet comme un "bien commun", à l'ensemble des utilisateurs, qui ont donc une charge commune de gestion de ce bien.
J'accroche pas trop..... honnêtement, c'est essentiellement du au fait que je connais déjà le discours et les actions de la quadrature, via FDN surtout.
Mais c'est une bonne chose d'avoir cette conf ici, présentée assez originalement avec des termes d'attaque informatique.
Et les questions posées à la fin de la présentation (surtout en haut à droite de l'amphi, ça doit être une conspiration contre le porte micro pourtant sportif.....) confirment l'intéret global.
Techniquement parlant, c'est un système bien foutu: quand on stocke des images sur le cloud, ca permet un bon compromis entre confidentialité des images (mais aussi vidéos et audios) et possibilité pour l'hébergeur d'économiser de l'espace disque en détectant les images identiques ou similaires (sans pouvoir les voir, donc).
En pratique, je reste pas du tout convaincu de l'intéret du truc: soit j'ai mes photos, qui vont avoir au mieux quelques copies (en supposant que mes amis et moi on veuille tous stocker nos images dans les nuages, chez le même hébergeur), soit j'ai des images publiques, et j'ai plus vite fait de garder des liens vers les images, ou simplement de les garder sur mon disque local, si je les perds, je les retéléchargerai sur le net.
Enfin, après cogitation commune, on a trouvé un cas ou plein de gens auraient les mêmes photos mais voudraient qu'on ne sache pas qu'ils les ont: une gigantesque collection de pr0n...... et encore, ces photos la, je suppose qu'on les veut ..... comment dire ..... à portée de main......
Courage, dernier déjeuner au RU !!!!!
Je suis pas super passionné par les trucs sur les cartes à puces, et le fuzzing commence à être assez connu pour ne pas être nouveau.... mais la, justement, l'application aux cartes à puces présente des contraintes particulières, et la façon dont ils ont résolu ca est intéressante.
A réserver cependant à un public qui aime vraiment le sujet......
C'est notoirement connu, je suis un grand fan d'Hervé (waaaw, la classe, il a carrément sa page Wikipedia, je suis jaloux !!!).
Et justement, on a droit à une conférence d'Hervé et d'un de ses collaborateurs:
Ah non, Hervé fait sa conférence seul, finalement, il avait juste un boy, lui aussi, pour brancher son portable:
C'est décidément vraiment bien organisé, le SSTIC, cette année !!!!
Malheureusement, la route vers le retour est longue, je n'ai donc eu le temps que de voir son premier slide, probablement le plus important:
Bah oui, ca finit bien à un moment...... et, pour le retour, sans soucis techniques qui auraient pu assombrir une édition du SSTIC très sympa, comme tous les ans, finalement !
jeudi, juin 9 2011
Par Vanhu le jeudi, juin 9 2011, 15:31 - En direct de la ou je suis
Non, le SSTIC, c'est pas la glande, l'amphi est même pas mal rempli pour un 2eme jour à 9h du matin, et c'est reparti !!!!
C'est devenu à la mode depuis quelques années d'attaquer "un truc" via le DMA, on avait déjà vu (l'année dernière ?) une attaque d'un PC Windows via le contrôleur firewire (DMA activé par défaut sous Windows).
Du coup, ma mission ce matin: comprendre l'intéret d'attaquer directement un autre périphérique DMA, vu qu'on sait déjà de toutes façons prendre le contrôle de la machine via DMA........
Quelques slides un peu rébarbatifs (surtout pour un matin, faut reconnaitre que, dans l'absolu, c'est pas mal compréhensible vu le sujet de départ) et une démo en vidéo plus tard, j'ai l'explication: les attaques DMA via Firewire sont bien une nouvelle mode, on va en bouffer tous les ans, avec à chaque fois un truc un peu nouveau qui change un peu l'attaque mais au final c'est pareil, on a pris le controle de la machine d'en face....... bon, bah au moins, je suis psychologiquement prévenu pour les prochaines années......
Au départ, le sujet pourrait m'intéresser pour récupérer l'accès au BIOS de mon portable, sur lequel j'ai mis un mot de passe super balaise quand je l'ai reçu (le portable, pas le mot de passe), mais que j'ai complètement oublié depuis (le mot de passe, pas le portable).....
Qui n'a jamais perdu son mot de passe de BIOS ? à part ma soeur, bien sur, qui a un mac et pas la moindre idée de ce qu'est un "BIOS", bien que j'ai espoir sur le fait qu'elle aie une vague notion de ce qu'est un "mot de passe".....
En plus, y'a des dessins marrants sur les slides de cette présentation :-)
Ca enchaine quand même sur des graphes Metasm, sur du code machine et d'autres joyeusetés du genre..... pas sur que tout le monde dans la salle suive dans le détail..... et ca n'a pas forcément grand chose à voir avec le café qui attend dehors, donc qui n'est pas encore dans nos veines...........
Joueur..... ca reste le qualificatif principal que je retiendrai à propos d'Alexandre, qui s'est quand même amusé à flasher le contrôleur clavier de son portable (oui, toujours pour récupérer son mot de passe BIOS).... le genre de truc ou il faut pas trop se louper quand même !!!!!
Tout ca pour une utilité flagrante, de l'aveu même de l'orateur:
Pendant ce temps, certains téléphonent encore.....
Stéphane nous explique pourquoi/comment lui et ses collègues se sont retrouvés à écrire un hyperviseur from scratch, qui permette d'étudier un OS avec une interaction minimale (pas de code spécifique dans le guest, etc....).
Et manifestement, c'est pas simple, entre autres grâce à nos amis de chez Intel ("c'est une bande de nazes", dixit Stéphane) et de chez AMD, qui aiment bien compliquer les choses...... J'aurai entre autres découvert le mode irréel des processeurs X86 (bah oui, au bon vieux temps des démomakers et de mes premiers essais en ASM, j'étais encore sur Amiga, moi.....), et pas mal d'autres mécaniques intéressantes ..... et compliquées à contourner/émuler.
Heureusement qu'on a eu la pause café avant, même avec ca j'ai encore un doute sur le taux de gens dans la salle qui comprennent vraiment.......
Stéphane présente ensuite Ramooflax, comment ils ont solutionné les problèmes sus-cités, quelles options et fonctionnalités ils ont pu implémenter, etc.....
Fraichement mis à dispo sur le net (pas trouvé d'info sur la licence, mais vu que c'est sur github, ca doit être opensource), pour ceux qui voudraient faire mumuse avec un truc qui a l'air très, très sympa, malgré un discutable choix de départ qui impose le comptage précis d'espaces dans le code source.......
Comme tous les ans (enfin, depuis au moins 2 ans, de mémoire de google), quelques mois avant le SSTIC, on nous fournit un truc (une ROM d'android, une image de disquette bootable qui contient une énigme de pirates, ou cette année, une vidéo), et des gens vont la maltraiter pour en extraire une adresse mail à laquelle répondre "moi, moi, j'ai trouvé, j'ai gagné quoi ".
Voyons ce qu'on trouvé cette année les esprits retors.... je parle aussi de ceux qui ont trouvé, pas seulement de ceux qui ont conçu le challenge........
J'ai bien fait de ne pas gaspiller le peu de neurones qu'il me reste sur le challenge de cette année: ca commence par parler de vidéos Mpeg4 pour enchainer sur une attaque SQL....
Bon, c'est parti pour une conf qui va douloureusement me rappeler que je ne suis qu'un utilisateur de crypto, qui a renoncé il y a très longtemps à se plonger dans les détails techniques et mathématiques.......
Mais au moins, les logos sont jolis :-)
Conclusion: les tokens PKCS#11, c'est quelques centaines de dollars pour un truc qui permet de lire les clés privées, normalement justement protégées et illisibles en dehors du token.....
Autant acheter une clé USB standard, c'est moins cher......
Comme d'habitude, un délicieux déjeuner fourni par le RU........ on s'en remettra...
Et pendant ce temps, il se passe aussi des trucs très torrides au SSTIC....
mais aussi de sympathiques ateliers de tours de magie, faits par des gens du voyage, à en juger par les chaussures du prestidigitateur.......
On va tous mourir !!!
Peut-être même avant fin 2012, c'est terrible:
Enfin, au moins, Internet va s'effondrer, dans quelques mois au plus tard.... c'est sur, c'est annoncé depuis au moins 10 ans, ca va donc très certainement plus tarder, maintenant !
Imaginez un monde sans facebook, sans youtube..... sans accès à mon blog, même !!!
Nous voyons donc comment pourrait faire un génie du mal (ou un groupe de génies du mal), équipés d'un monocle, d'un porte cigare, d'un chat moche (oublié par l'orateur, mais très important), d'un bunker souterrain (ou du garage des parents, selon le budget) ? qu'il soit chinois, russe (on recycle encore les vieux méchants, la.....) ou de n'importe ou ailleurs.
Avec une pelleteuse, un bateau de pêche ou juste une mémé georgienne et une pelle, on peut faire des dégats, l'actualité récente l'a prouvé. Mais on ne coupe pas tout, loin de la... Ok, on ne peut plus passer ses commandes sur carrefour market de l'après midi, ca peut même perturber pas mal de choses jusqu'à assez loin, mais c'est une fin du monde un peu cheap.....
Et puis une attaque physique, c'est cher et compliqué.....
Ca doit bien pouvoir se trouver, une (nouvelle) faille dans IOS (celui de Cisco, pas celui à la pomme), mais ca reste pas simple: plusieurs types de routeurs, plusieurs versions, ne pas couper trop tot (sinon on ne peut plus accéder aux autres routeurs qu'on veut corrompre...), etc....
Très utile pour planter france.fr (non, je ne m'abaisserai pas à faire un hyperlien ici.....), on cherche à TOUT planter.... il faut donc trouver un point central, qui suffit à tout casser....
Facebook est un bon candidat si on demande au quidam moyen, qui a éventuellement une vague notion que "autre chose que facebook" existe, mais n'a jamais été vraiment vérifier....
La racine DNS est également un très bon candidat, en partant du principe que les gens ne se souviennent pas des adresses IP de tous les serveurs du monde (et après on dit qu'IPv6 c'est mieux ? ah ! laissez moi rire !!!!).
Technique vérifiée également ces derniers temps, très efficace quand on est dictateurleader charismatique de certains pays, mais ne fonctionne la encore qu'à un niveau national, et juste le temps que des trouble fête ne mettent en place un accès underground.....
Nous avons maintenant droit au point de vue du défenseur, avec une liste des possibilités de défense.....
C'est pourtant simple: redonder les cables (vraiment, sans les passer dans la même tranchée.....), faire des programmes sans bugs, tout ca.....
Et que les utilisateurs (oui, vous, parfaitement !!!) arrêtent de demander tout le temps plein de nouvelles fonctionnalités dans les programmes: c'est souvent dans les implémentations de ces nouvelles fonctionnalités qu'il y a le plus gros taux de bugs, donc de failles.....
Vous l'aurez sans doute compris vu la quantité de propos que j'ai (plus ou moins) reproduit: j'ai adoré cette conf, intéressante, ludique et drôle à la fois.
En écoutant à moitié (j'avoue, c'est pas le genre de sujet qui m'emballe le plus), j'en retiens que DNSSec c'est en cours depuis longtemps, mais c'est pas forcément méga top pour autant.....
Ah, au temps pour moi, le slide de conclusion dit quand même que DNSSec c'est lourd mais bien, au moins tant qu'on est pas sur le dernier lien (entre le client et son relais DNS).
Ah, ca parle d'une alternative (sur le dernier lien seulement) au DNS à base de LDAP, c'est surement une bonne idée :-D
Ah, et en faisant une analyse sténographique très poussée, j'en arrive à la conclusion que l'ANSSI recrute:
Ah, enfin ZE raison de venir ici tous les ans, les rumps.... le meilleur du pire, l'inverse, et encore d'autres trucs. Dump du programme à l'arrache:
Comme d'hab, temps très limité par présentation, peu/pas de sélection dès que ca rentre à peu près dans le sujet, et probablement des surprises......
Et cette année c'est encore plus moderne, on a un gros compte à rebours visible juste devant les rumpers !!!!
Même si, curieusement, il n'est pas déclenché lors de la première rump, celle des orgas.......
Ah, et comme d'hab, j'ai privilégié les photos et l'écoute en direct, et je vais maintenant devoir faire un effort de mémoire surhumain pour tenter de remplir au moins un peu chaque rump (non, je n'irai pas honteusement pomper sur les blogs des autres, même si certains me devraient bien ca vu la patience avec laquelle je leur ai fourni la lumière nécessaire à leurs photos pendant les rumps.......).
C'est le comité d'orga qui le demande: soumettez !!!!
Ou comment nos badges sont gérés, entre le QR Code, la signature des données, l'infra d'accueil du premier jour, tout ca......
XSS, vous aurez donc deviné que j'ai pas trop suivi le contenu, par contre bon point au rumpeur, qui a la sympathie de poser correctement pour les photographes:
Un format de truc à machin pour faire le chose...... l'important, c'est de retenir que c'est un format pris en charge par PhotoRec !
Derrière un acronyme difficile à digérer, une utilisation de fonctionnalités windows pour faire un keylogger USB..... je crois.....
Euh..... une démo OpenGL ??
Tentative de présentation du fonctionnement d'un service de l'Education Nationale..... mais 4 minutes par rump, c'est 4 minutes.......
Euh...... l'ANSSI recrute ? Ah, et fait de la doc, aussi......
Un détecteur de réseaux Wifi sympa, fait exprès pour la Nintendo DS (et DSi). Un des avantages: le chipset Wifi de la console ne filtre pas selon la qualité du signal, donc on voit beaucoup de réseaux !
Ou comment quand même casser quand on a pas un PC de gamer, parceque 1500€ c'est un joli budget rue St Michel ..... Quelques stats intéressantes sur une base de mots de passe (américaine, essentiellement) diffusée récemment.
J'ai pas trop suivi l'intéret de fond, mais ca fait de jolies oeuvres d'art néo moderne:
Histoire rapide d'un audit qui commence par "c'est la secrétaire la coupable", pour finir par "c'est l'admin sys, en fait"...... y'a plus de moralité........
Euh.........
Cette rump a existé si j'en crois ma liste de photos.... par contre, d'après ma vielle cervelle, c'est une autre histoire........
Euh... un photorec orienté numéros de cartes bleues en clair sur les disques, en très très résumé.....
ou comment mettre un scan NMAP en vrac en ralentissant les paquets en userland...... un vrai IPS qui fait détecteur de scan de ports et qui blackliste l'IP, je suppose que ca fonctionnerait aussi...... je dis ca, je dis rien......
Un projet qui a l'air sympa, sauf que la partie NIDS n'a été qu'évoquée, et que tous les exemples étaient orientés HIDS..... à creuser......
Comment vendre super cher une clé USB avec token de lecture d'empreinte digitale bateau, mais avec une bonne équipe marketing pour vous dire que c'est du chiffrement méga fort, que le lecteur d'empreinte vérifie votre pression sanguine, et qu'il y a même un système d'auto destruction en cas de tentative d'attaque du machin.....
Ils sont forts, parfois, au marketing.......
Et forcément, parceque les slides en pratique ne se sont pas déroulées comme annoncées sur ma photo d'au dessus, j'ai loupé des trucs, je crois....... et j'espère ne pas en avoir inversé.
Par Vanhu le jeudi, juin 9 2011, 09:15 - En direct de la ou je suis
Ca commence fort.... enfin, ca commence en anglais, déjà..... vérification rapide, on est bien à Rennes, le taux de barbus n'est pas assez élevé pour trahir une brèche dans le continuum spatio-temporel qui m'aurait embarqué direct à l'EuroBSDCon de cette année, donc ca doit être normal....
Postulat de départ: si votre station de travail est compromise, c'est grave, puisqu'elle est l'interface parfaite non seulement pour espionner tout ce que vous faites, mais aussi pour éventuellement se faire passer pour vous (quoique certains ont mis au point des algorithmes très complexes à bases de fautes d'orthographe pour rendre la contrefaçon facile à détecter......).
Joanna (oui, ca fait style de présenter les orateurs par leur prénom, même quand on ne les connaissait pas encore hier soir) nous présente donc différents modèles d'isolation des applications, pour ..... bah pour limiter la casse dans le cas ou une application serait compromise (oui, ca arrive encore de nos jours d'avoir des bugs et des vulnérabilités dans les programmes, c'est dingue, non ?).
Mais bon, tout ca, c'est du passé, maintenant, non ? Je veux dire: à part quelques dinosaures néphophobes, tout le monde est passé au 100% cloud, et il suffit juste de lancer plusieurs firefox différents pour chaque application ! Ou alors on m'aurait menti ?
Finalement, l'idée est plus de présenter différents modèles d'isolation, pour ..... montrer que c'est probablement impossible ..... en tout cas pas dans un environnement "moderne", ou on (vous savez bien ..... eux ..... les ...... utilisateurs.....) veut pouvoir faire du copier/coller d'une appli à une autre, pouvoir cliquer partout pour lancer des trucs qui font des machins en interaction avec les choses, etc.......
Joanna nous présente aussi Qubes, un truc qui utilise Xen pour isoler les machins.......
Note pour ma soeur: non, je n'ai pas profité de la pause pour me barrer et rejoindre un salon de l'érotisme, on est toujours en train de parler d'informatique.
On parle donc de BitLocker, un truc qui chiffre toutes les données sur les disques, sous Windows.....
Grand suspense pendant les slides d'explication du fonctionnement du machin: est-ce qu'il est la juste pour nous l'expliquer, pour nous dire que c'est bien, ou juste pour montrer comment on casse ce chiffrement via un salt faible, un hook quelconque ou quelques autres bouts de code ASM ???
Bah ca attaque..... et c'est des attaques très évoluées à base entre autres de scripts VBS et de scénario "evil maid", très en vogue ces temps ci...... enfin, ca attaquouille, quoi, le truc semble quand même assez résistant tant qu'on a pas le password admin.....
Et au moins, une démo sans risque d'effet démo, avec du coup des effets visuels pour bien nous montrer ou qu'on doit regarder parceque c'est la que c'est important....
Rien qu'au sujet, je sens que je vais être hyper concentré.....
C'est ca aussi les conférences de ce genre: on peut faire une conférence qui intéresse mille personnes, mais pas forcément mille conférences qui intéressent une personne......
Bref, 100% des conférences n'intéresseront pas 100% du public.....
Donc voila, .NET et Silverlight c'est tout moisi et on fait plein de trucs vilains avec ca ...... voila voila......
Tout ca pendant que de dangereux hackers tentent de pirater mon portable en faisant croire qu'ils sont au téléphone non stop depuis ce matin et qu'ils ont besoin de recharger sur ma prise USB..... même pas crédible:
Au départ, le sujet m'emballe pas beaucoup plus que le précédent....... mais un gars qui présente "un framework pour rendre les attaques XSS beaucoup plus faciles" ne doit pas être fondamentalement mauvais:
Et en prime, les slides sont sympas:
Petit rappel cependant aux futurs orateurs: l'effet démo existe, on en a encore la preuve ce matin :-)
Sponsorisée par le RU, comme tous les ans.... honnetement, je m'attendais à pire......
En plus, cette année, c'est bien foutu, y'a des Boys pour porter les sacs lourds:
Ca fait 2 minutes que je cherche un jeu de mots pourri genre "je vais probablement pas suivre", mais même pour ca je suis pas super inspiré, en fait..... surement l'effet digestion.
Et puis bon, vu la page d'intro des slides, on va jouer à sortir d'un labyrinthe, ca peut être sympa...
Bon, en résumé, Markov a vraiment bossé sur plein de trucs qui servent, et salez...... vos hashes de mots de passe, je veux dire.....
Ah, et arretez d'utiliser "passw0rd", "toto42" ou "Soleil" comme mot de passe, ca sera déjà pas mal.....
Ah, voila, on est apparemment partis sur une des traditionnelles confs de reverse engineering (euh, excusez moi, rétro-ingénierie en bon français dans le texte), ou ca parle de heap, de stack, de chunks, de threads, tout ca....
Et on devrait en toute logique avoir quelques slides d'ASM, c'est toujours sympa à lire l'après midi....
Ah bah non, finalement, on a droit à une démo haute technologie, qui tourne avec une carte graphique dernier cri, de Dwarf Fortress......
Ouf, ca finit quand même par un truc ou on voit des eax, eip, une liste de chunks, tout ca...... bah tout ca pour avoir un nain qui a le poil brillant sans se fouler......
Ok...... ca reste la première démo de lancer de nain en hexa, ca a le mérite de l'originalité !
"Canaux cachés", ici, c'est carrément ce qu'on peut lire via un oscilloscope, rien que ca.....
Donc, après une petite étude à l'oscilloscope d'un circuit éléctonique en train de chiffrer un truc, et explication d'un truc mathématique ou j'ai rien compris ..... bah .... j'ai rien compris, justement ..... et vu le bruit de fond dans l'amphi, je dois pas être le seul !
C'est dommage, si on avait réussi à comprendre ce que dit ... on va l'appeler "l'orateur" quand même..... bah ca aurait peut être été intéressant.......
Aaaaaahhhhhhh, la, on va avoir droit à une conf intéressante, c'est du garanti, puisqu'elle est faite par le désormais célébrissimmmmme (au moins au SSTIC) Nicolas Ruff.
Nicolas commence par une (très rapide) présentation de l'android, avant d'enchainer sur son opinion du langage le plus utilisé sur android: Java (indice, ca parle de poubelle, à un moment.....).
Quelques minutes plus tard, on retient que les applis android sont pas forcément mieux que celles facebook, et que le modèle de sécurité est ...... disons flexible.....
Sans parler des shells root et autres joyeusetés en clair proposées en standard sur les firmwares de certains constructeurs ou fournisseurs......
Avec un peu de chance, mon (très vieux) nokia 3110 traine encore dans un carton à la cave...........
Ca perturbe un peu la tradition, mais on a quand même pu aller manger ce soir au Wok de Rennes, comme ca je ne suis pas trop perturbé quand même dans mes petites habitudes...... Ca, c'était le coté "réconfort".......
Ensuite, comme la tradition le veut également, nous sommes allés dans la "rue de la soif", ou nous avons fait un superbe échec critique en choix de bar, surtout comparé à hier.....
Au programme, donc, dégustation de Super Bock, de Malouine ou de Breizh cola....... comme on dit avec style, "on boit pas ca n'importe ou"..... et c'est pas plus mal comme ca......
Par Vanhu le jeudi, juin 9 2011, 09:00 - En direct de la ou je suis
Cool, mon blog fonctionne toujours !
Eh oui, cher ami lecteur (cette formulation au singulier est censée être une figure de style pour parler de façon plus intimiste à chaque lecteur, et pas du tout suggérer le fait que je n'aie plus qu'UN lecteur sur ce blog.....), comme tous les ans, c'est le SSTIC, et une bonne occasion pour moi de dépoussiérer ce blog.....
Ah, et accessoirement de faire exploser les stats de visites, pour ceux qui mettraient des liens vers ce blog comme les années précédentes, j'ai mis un tag dédié.
Et donc, conformément à ma tradition de live blogging (toujours à prononcer un peu comme "serial killer"), y'aura un billet par jour, à commencer par le "day 0", celui de notre arrivée sur place, des photos, généralement mises à la bourre, des rééditions de billets dans tous les sens à en faire fondre les lecteurs de flux RSS, des explications rien que pour ma soeur, des commentaires hyper subjectifs sur les présentations (zut, Sid n'arrive sur Rennes que mercredi soir, je peux même pas vous dire d'aller sur son blog pour des commentaires sérieux sur les confs du premier jour.....), tout ca.....
Ouaip, cette année, on est venus en nombre (enfin, 5), dans une ....euh .... un .... un truc.... qui tenait plus du van de l'agence tous risques que de l'audi A3:
Et, au cas ou ca aurait pas été assez drole comme ca de manoeuvrer ce machin, on a aussi eu droit à l'exercice sympathique du pneu crevé en plein sur l'autoroute, qui me permet au moins de savoir désormais répondre à la fameuse énigme de "combien faut-il d'ingénieurs en informatique pour changer un pneu": 5, ca suffit largement, dont celui qui tient le parapluie, celui qui lit la doc pour comprendre ou trouver la roue de secours, celui qui va poser le triange de sécurité loin, tout ca:
Déception, d'abord..... notre désormais traditionnel mardi soir au Wok de Rennes n'a pas été possible, fallait réserver...... mon désarroi a été terrible, comme vous pouvez vous en douter !
Mais bon, on a quand même eu une note d'espoir en trouvant un endroit civilisé rue St Anne: un bar à bières, avec de vraies bières (comprendre Kwak (dans un vrai verre à kwak (ouh, je recommence à bloguer en Lisp, moi.....)), karmeliet triple, Chimay, troll, etc....), et du saucisson !!!
Bref, de quoi me réconforter un peu avant d'attaquer ces trois jours intenses:
mardi, novembre 2 2010
Par Vanhu le mardi, novembre 2 2010, 19:17 - Vieux con de hacker old school.....
Cramé pour cramé, et ayant repris une activité de blogging (oui, j'ai commencé ce billet y'a un bout de temps, juste après le SSTIC :-) ), autant pousser jusqu'au bout.....
En plus du vil et mesquin dépilage de vieux billets en attente (mais oui, ca va venir..... un jour..... surement......), ca fait quelques temps que je cherchais un sujet sympa pour un billet technique, à défaut de petits jeunes au labo pour m'en proposer de temps en temps (Jo, si tu lis cette phrase, tes pinces à tétons certifiées "CE" nous manquent ! :-) )
Le sujet du jour sera donc "enum ou defines dans un source en C", j'aurais bien fait monter le suspense méga grave, mais comme l'info était déjà dans le titre, j'ose espérer que vous vous en doutiez déjà, sinon vous risquez d'avoir du mal à lire la suite.....
Ouaip: au boulot, on se pose régulièrement la question quand on a une liste de valeurs possibles à stocker dans un int: on fait des defines ou un enum ? Et il se trouve qu'on s'est reposé aujourd'hui une question sur les enum......
Un exemple permettra presque à ma soeur de comprendre le problème, pour peu que ca soit concret.... Supposons qu'on veuille stocker dans une variable le jour de la semaine.
La solution à base de define donne ca:
#define DIMANCHE 0 #define LUNDI 1 #define MARDI 2 #define MERCREDI 3 #define JEUDI 4 #define VENDREDI 5 #define SAMEDI 6 int jourdelasemaine;
La solution à base d'enum donne ca:
enum {DIMANCHE, LUNDI, MARDI, MERCREDI, JEUDI, VENDREDI, SAMEDI} jourdelasemaine;
On voit tout de suite que la solution à base de defines a l'indéniable avantage de permettre de facturer plus de lignes de code au client, et qu'en plus elle passe mieux dans la mise en page du blog.....
Ca fait également plus technique, surtout si on se met à déclarer les valeurs en hexadécimal, ce qui donne:
#define DIMANCHE 0x0 #define LUNDI 0x1 #define MARDI 0x2 #define MERCREDI 0x3 #define JEUDI 0x4 #define VENDREDI 0x5 #define SAMEDI 0x6 int jourdelasemaine;
Alors que l'enum nous mache le travail, et va même jusqu'à commencer automatiquement la liste à 0 si on ne précise pas la première valeur.....
Bon, bah voila, je pensais qu'il serait un peu plus long que ca, ce billet, en fait.....
La prochaine fois, on parlera d'autre chose, du coup.....
Bon, je suis chaud bouillant comme une baraque à frites aussi vais-je rajouter l'hypothèse certes peu vraisemblable suivante: l'argent n'a pas d'odeur (en tout cas, pas beaucoup quand on est juste à coté de la baraque à frites susnommée), et on veut surtout faire un truc logique et intelligent.
En plus, par souci d'équité et de neutralité, je me dois de vous signaler qu'on peut aussi faire ca:
enum {
DIMANCHE,
LUNDI,
MARDI,
MERCREDI,
JEUDI,
VENDREDI,
SAMEDI}
jourdelasemaine;
Et donc facturer à peu près aussi cher l'implémentation à base d'enum.....
Une fois ce nouveau contexte établi, la solution à base d'enum pourrait paraitre la plus logique, en tout cas dans des langages de noobs...
Mais en C, il n'en est rien: la norme précise en effet qu'il ne s'agit que d'une facilité à l'édition, et que l'enum en question reste de toutes facons stocké dans un int.
On peut facilement le vérifier, par exemple avec le code suivant:
jourdelasemaine=SAMEDI;
printf("%d\n", jourdelasemaine);
jourdelasemaine++;
printf("%d\n", jourdelasemaine);
jourdelasemaine=42;
printf("%d\n", jourdelasemaine);
Tout ca fonctionne normalement, l'enum ne sert donc à rien par rapport à un define, si ce n'est éventuellement l'affectation automatique des valeurs (on a pas eu besoin de dire que dimanche=0, c'est implicite par défaut).... quand on a des valeurs qui se suivent, évidemment.....
D'un point de vue vérification de cohérence à la compilation, on est donc marrons (marron fricadelle, pour être précis), on peut faire tout et surtout n'importe quoi avec les deux approches, match NULL pour l'instant.....
Peut être à un petit détail près, qui m'a été signalé à l'instant par un stagiaire développeur du labo:
Dans le cas ou on fait un switch sans cas par défaut, si c'est un enum, le compilateur (en tout cas au moins un gcc récent) va signaler s'il manque une valeur de l'enum:
En reprenant notre enum de tout à l'heure, si on fait:
int isWE(jourdelasemaine j){
switch(j){
case lundi:
case mardi:
case jeudi:
case vendredi:
return 0;
break;
case samedi:
case dimanche:
return 1;
break;
}
}
Bah le compilateur va raler parcequ'on a oublié la valeur "mercredi"...... enfin, si on compile en -Wall Werror, mais tout le monde compile tous ses programmes comme ca, pas vrai ?
Ca suppose aussi qu'on n'utilise pas la facilité du target par defaut d'un switch, ce qui est quand même assez fréquent.......
Qu'en est-il de l'utilisation mémoire ?
A priori, léger avantage au define: un enum est systématiquement stocké sur un int (en tout cas, j'ai pas trouvé comment le faire tenir sur moins), alors que, dans le cas du define, on peut déclarer explicitement un short, un u_int8_t ou autre chose dans le genre qui ne prend pas trop de place quand on sait que ca va suffire pour faire tenir toutes nos valeurs possibles (et dans mon exemple, ca va tenir à l'aise), voire carrément un champ de bits si on est dans une struct et qu'on a d'autres champs de bits à poser à coté.......
Bon, je me foule vraiment pas en titres intermédiaires, moi, sur ce coup la......
le dernier aspect, c'est l'épépinage du code....
Et la, faut reconnaitre que l'enum a un avantage: gdb va indiquer la valeur de l'enum, alors que, avec un define, il va afficher la valeur numérique. Donc, dans le cas ou on est pas trop boulet et ou on a mis des noms explicites pour ses enum, faut admettre que ca fera gagner un peu de temps......
D'un autre coté, quand on est pas trop boulet, on n'a pas besoin de gdb, si ? :-D
Si on résume, le define est plus approprié pour grapiller quelques octets, et l'enum est plus facile pour débugguer....... dit autrement: le define, c'est pour les barbus, l'enum, c'est parfait pour les noobs qui codent avec des moufles......
La prochaine fois, on essaiera de trouver un sujet technique un peu plus poilu, quand même.......
vendredi, juin 11 2010
Par Vanhu le vendredi, juin 11 2010, 16:30 - En direct de la ou je suis
Ouch, debouts en plein milieu de la nuit (8h30), check-out de l'hotel, tout ca, pour arriver juste à temps pour la première conf qui vient à peine de commencer (9h45).
Heureusement, curieusement, l'amphi n'est pas tout à fait autant rempli que les jours précédents........
En général, je suis le premier à critiquer les personnes qui présentent une conf sans aucun talent d'orateur (voix monotone, qui donne pas du tout envie d'écouter voire qui est soporifique, tout ca...).
La, un lendemain de social event, je m'abstiendrai d'une telle catégorisation: je ne sais pas à quelle heure et dans quel état il s'est couché, et le public, moi y compris, doit aussi être un peu plus sujet à la somnolence que d'habitude......
JBOSS ? C'est un truc Java, ca, non ?
Bon, j'ai des mails en retard à lire, et un peu d'air frais à prendre, moi, à tout à l'heure !!!
....
Bon, tout ce que j'en retiens, c'est que JBOSS est bourré de "features" qui permettent de venir poser ce qu'on veut dessus quand on est un attaquant maladroit personnage.........
Donc si vous utilisez JBOSS, allez lire les actes !!!!
Bon, la matinée continue avec une conf sur .NET ..... On va écouter, mais c'est vraiment parceque c'est Nico RUFF qui fait la conf !!!
Bah oui, Nico, en conf, c'est de la poésie: il prend un sujet polémique, trollesque, voire chiant (la, en l'occurence, .NET, quand même !), vous raconte ca d'une voix un peu machonnée (ou alors c'est l'effet vendredi matin ???), mais qu'on a quand même envie de suivre, le tout parsemé ici et la de petites phrases assassines et droles......
"5 minutes.... ok, j'suis mort"..... bon, la fin de la conf va s'accélérer fortement, mais Nico cherche des gens qui s'intéressent à .NET (et des lecteurs de PC Impact, aussi, apparemment.....), avis aux amateurs.....
On a droit, pour finir, à un 3L33T H4CK1nG sur SongSmith (un truc qui peut apparemment faire croire que vous chantez bien ?), et une démo musicale....
Ca ne se devinait forcément pas dans le titre, mais on est prévenus dès le début: ca va parler de sécurité des applications WEB, "avec une connotation formelle"...... j'ai peur........
Je reprends cette conf en cours de route, pour suivre avec beaucoup d'intéret (?) une explication sur le principe d'une injection de code SQL..... super !
J'en aurais presque hâte d'être déjà à l'heure d'aller manger au RU.........
J'apprendrai plus tard qu'il y avait un vrai projet potentiellement intéressant dans cette pres, qui a été vaguement abordé dans les dernières minutes......
Entre temps, (curieusement ?), la salle est encore assez pleine:
Mais certains ont cependant préféré aller méditer de leur coté sur les problèmes de cloud et autres....
MMMMMhhhhhh..... un succulent déjeuner à la hauteur de la dernière près de ce matin......
Puis une pause bien méritée avant la reprise des confs:
(que certains soient rassurés, d'autres photos prises ce midi resteront classées SECRET DEFENSE ;-) )
Sur le principe, j'aime pas trop les gens qui se vantent de tirer au bazooka sur les ambulances en panne sur le bas coté de la route......
Mais bon, voyons quand même comment le téléphone prété par le courageux Nico (oui, celui de ce matin.... Nico, pas le téléphone, vous faites exprès, ou quoi ?) va servir à hacker un autre téléphone (ou l'inverse ?).
Ca commence par un rappel du contexte spécifique des smartphonesordiphones pour faire un rootkit, comme par exemple la nécessité d'être discret en utilisation de batterie, pour ne pas éveiller les soupçons de l'utilisateur, ou le fait que l'accès au net est variable, parfois multiple, parfois inexistant, etc....
J'avoue, j'ai écouté d'une oreille seulement (la gauche, pour ceux qui se poseraient la question), mais la près présente bien les problèmes généraux des rootkits sur smartphones, et pourquoi Windows Mobile est pire que les autres (en gros, il est beaucoup plus permissif sur plein de choses, allez lire les actes pour les détails......).
Je note aussi la réponse à la question "comment on se protège ?" : "déjà on utilise pas Windows Mobile" :-)
Seconde présentation en anglais, qui parle aussi de trucs liés aux GSM, et d'ailleurs faite par le même conférencier que la présentation d'hier sur OpenBSC (en anglais aussi, ca se tient, donc).
Bon, petits rappels de ce qui avait déjà été présenté hier sur la (non) sécurité des discussions entre le téléphone et l'opérateur, mais un peu plus orienté "du coté du téléphone".... et pas plus rassurant pour autant......
Ensuite, présentation du projet lui même: faire un téléphone GSM complet en OpenSource. J'ai pas l'impression que ca soit directement le coeur du thème des SSTIC, n'empèche, ca reste intéressant pour une salle de 3I33t hackers, et ca remplira au moins le quota de près avec des photos de hardware "maison" :-D
Non, je suis pas du tout en manque des confs des années précédentes bourrées de dumps ASM :-)
On sera par contre juste un peu déçus par la démo, qu'il fait sans même avoir besoin de faire une injection de code ou un truc dans le genre ;-)
Euh.... bon, ok, le dump de communication téléphonique dans Wireshark, c'est sympa quand même :-)
Et le tout avec une gestion bluffante du problème "mains au clavier Vs tenir le micro":
Bon, bah la, même sur le programme sur le site du SSTIC, pas le moindre indice sur ce que va être cette conf..... Non, je ne cèderai pas à la facilité en suggérant plus ou moins directement que les "confs invitées", y'a de quoi faire peur depuis ce matin.... non......
Surtout en voyant arriver un conférencier en costard-cravatte...... quoique ca, c'est sur que c'est pas un indice, il suffit de se souvenir de la dernière conférence de lundi !
On a finalement droit à une présentation géo-politique de la problématique de sécurité informatique.
Euh, difficile à résumer en quelques phrases, mais c'est intéressant que ce point de vue soit présenté à un public tel que celui du SSTIC.
Ah, bah voila, on sait pourquoi cette conf est la: c'était pour finir comme ca a commencé: par une campagne de recrutement d'une agence gouvernementale :-)
Je note aussi la phrase: "le mec qui vient se vanter d'avoir trouvé une vulnérabilité d'un windows, c'est de la vanité mal placée" (ou un truc comme ca ? quelqu'un peut me confirmer la phrase exacte ?).
Plus sérieusement, la fin du discours me plait beaucoup. En résumé, c'est bien gentil de trouver une nouvelle attaque sur un système, mais c'est nettement plus constructif de trouver comment protéger les systèmes en question......
Voila..... ca y est, c'est la fin des SSTIC 2010.... on se dit au revoir, on s'embrasse (enfin, on essaie de faire la bise aux filles, quoi.....), on retient la petite larme, on se promet de s'écrire d'ici la, et on se dit qu'on se reverra de toutes façons l'année prochaine.......
Et chacun repart dans son coin, prendre son train, récupérer sa voiture, et va rentrer chez lui pour passer la semaine prochaine à raconter tout ce qu'il a vu/entendu cette année........
A l'année prochaine, donc !
Par Vanhu le vendredi, juin 11 2010, 10:01 - En direct de la ou je suis
A ce qu'il parait, "Day 2 pluvieux, Day 2 heureux"....... bah on va être super heureux à en vomir partout, du coup, aujourd'hui, trop de bonheur......
Pour ceux qui se poseraient la question, non, on ne va même pas vomir partout suite à une soirée trop tardive et trop arrosée du coté de la place St Anne hier, même si, pour faire un minimum nos gars sociaux qui causent aux autres, nous avons trainé un peu dans ce quartier hier soir (mais seulement pour manger :-D ).
D'ailleurs, il y a eu plein de gens raisonnables (qui a dit "bah oui, y'a plein de nanas cette année" ? j'ai parfaitement entendu, attention !!!!!), manifestement, puisqu'à a peine 9h du matin, l'amphi tient un honorable 2/3 de taux de remplissage, salué par Céline qui remercie les courageux :-D
Comme tous les ans depuis l'année dernière, il y a un challenge de sécurité proposé aux inscrits quelques mois avant le SSTIC, et un peu de temps pendant les 3 jours du SSTIC pour présenter le challenge et les vainqueurs.
Cette année, c'est une image de ROM d'un smartphone Android qui a subi les derniers outrages.......
D'abord, remise des prix aux différents vainqueurs (vitesse ou qualité de la réponse):
Ensuite, c'est Arno qui présente sa solution:
Jusqu'à Pohlig-Helmann, j'ai à peu près suivi.....malgré l'heure matinale...... l'attaque de la crypto, par contre, je crois que même avec 3 doubles expressos super serrés, mes cours de maths et de crypto sont trop loin....... Mais toutes les solutions seront présentées sur le site du SSTIC, avec plus de détails, en prime, allez voir ca par vous même !!!
Comme à chaque fois que je vois l'explication d'une solution à ce genre de challenges, une question reste en suspens: entre le gars qui a imaginé le truc et celui qui a trouvé la solution (parfois de manière super détournée), lequel est le plus inquiétant ?
Bon...... il est même pas 10 heures, on sort à peine de l'excellente mais très dense explication d'Arno, on arrive sur un truc qui parle de Java...... Vous vous attendez vraiment à ce que je fasse un commentaire pertinent de cette conf ?
Ouf, de retour à temps pour la conclusion, j'en retiens que tout va bien, et que ce langage maintenu par SunOracle a un bon niveau de sécurité, qu'il faut cependant encore améliorer..... me sens mieux, de suite.....
En lisant le résumé sur le site du SSTIC, je comprends qu'on va nous expliquer qu'une IOMMU est une sorte de firewall anti firewire (oui, je schématise méga grave, voire téra grave si ca n'a pas été copyrighté par notre ami avocat d'hier après midi.....).
En pratique..... ca arrive aussi: des gens qui savent manifestement de quoi ils parlent, qui ont des trucs super techniques à dire, mais qui ne sont pas orateurs pour 2 centimes d'euro (pas de panique, les gars, ca se travaille, ca s'améliore !!!).
Du coup, j'essaie de vaguement suivre quand même, mais je reste surtout en attente de la conclusion: est-ce que ces IOMMUs permettent de protéger les machines contre les attaques par le bus DMA (firewire, etc...), ou devons nous toujours nous méfier comme de la peste d'un apparemment anodin périphérique branché sur notre ordi ?
En attendant la conclusion, on a droit à un beau remplissage en attendant que Mr Murphy quitte la salle...... combien de fois faudra-t-il le répéter: la seule précaution efficace pour éviter "l'effet démo", c'est tout simplement de ne SURTOUT PAS faire de démo !!!!!
La conclusion arrive quand même: ne branchez JAMAIS un IPod sur votre PC...... en même temps, j'aurais déjà pas eu cette idée avant......
Le problème de fond est déjà connu: les cartes réseaux font des trucs dans notre dos..... et ces trucs ont été mis en place par des gens qui sont tout, sauf experts en sécurité et en crypto.
Nous avons donc droit à une présentation d'un cas particulier sur des cartes Broadcom, avec présentation des techniques censées assurer la sécurité du système, et, bien sur, comment les auteurs ont décidé d'attaquer ca pour le contourner....... à commencer par un traceur/débuggeur de carte réseau, tout simplement.
Au final, une démo d'attaque qui se conclut par "d'habitude ca marche"..... encore des victimes de Murphy..... vais finir par devoir faire une rump pour militer contre ca !!!!
Leur dernière démo fonctionne bien, cependant, et vient encore confirmer que même le matériel n'est pas forcément digne de confiance.........
Honnêtement, j'ai hésité à passer complètement sous silence cette présentation. Pas que je déteste l'auteur ou qu'elle soit pourrie (elle n'a d'ailleurs pas encore commencé), mais simplement parceque, la dernière fois que ca a parlé de honeypot sur ce blog, ca m'a valu des ....... complications........
En pratique, ca parle.... euh .... de théorie, en fait..... voire de franc-maçonnerie, presque, puisque c'est vraiment une présentation de l'organisation du projet, pour l'instant, avec de sombres histoires de "Chapitres" et de "Gouvernances"......
Miaaaaam :-)
Et on repart,avec une conférence d'un consultant de chez Hervé.
Le sujet est clairement une question de fond, dans une république ou une démocratie (mais curieusement, pas forcément dans une république démocratique.......). En pratique, y'a quand même plus de shémas de fonctionnement logiques que de dumps ASM, juste après déjeuner, ca risque d'inciter à la digestion profonde du repas.....
Après un rapide tour d'horizon des problèmes des solutions actuelles, une proposition de solution est faite, qui permet à chaque electeur de pouvoir vérifier ultérieurement son vote, sans pour autant rendre son vote public.
J'aime beaucoup l'idée, mais les gens citoyens électeurs ont déjà du mal à se motiver pour aller voter, vont-ils en plus se re-motiver ultérieurement pour aller vérifier leur vote ?
Sachant que cette mécanique nécessite, pour être fiable, qu'une forte majorité des électeurs fassent ce genre de vérification (à moins que la peur du contrôle possible ne suffise à dissuader un éventuel candidat fraudeur ?).
En conclusion après les quelques questions qui ont pu être posées (pas de bol, j'ai pas pu faire à l'oral ma remarque du dessus), j'en conclus que ca aura une chance d'être fiable quand ma grand mêre saura récupérer 2 nombres aléatoires (dont le sien) et refaire chez elle le calcul de génération de sa "trace" à partir de ces deux nombres...... pourquoi j'ai comme un méchant doute ?
A priori, ca ne devrait pas parler des risques sur la productivité des employés sur leur temps de travail, mais bel et bien des risques de sécurité via facebook.....
Présentation très intéressante, y compris quelques anecdottes amusantes concernant l'étude, le déploiement de l'application test, etc.....
En résumé, c'est très facile de diffuser une application (surtout si on utilise des profils "de lancement" avec une photo aguichante, qui aide encore un peu plus pour se faire plein d'amis qu'on connait pas), pour peu qu'on ait une idée de "buzzé pour l'appli (le plus difficile, apparemment).... Et à partir de la, on peut facilement collecter des informations sur tous les gens qui auront installé l'appli en question.....
Bref, arrétez d'ajouter n'importe qui en ami, et arrétez de passer votre temps à installer des applications facebook (même si vous ne les utilisez pas, ca ne change rien).... ah, et arrétez de passer vos journées devant l'ordi, tout simplement, ou alors pour bosser, et commencez à vous recréer une vie IRL, tiens, ca vous apprendra !!!!!
Petite anecdote quand même à propos de cette conf.....
Pendant la conf, j'ai mis sur mon mur facebook le message suivant:
"En direct des SSTIC 2010: oubliez de suite la quasi totalité des applications tierces facebook, à commencer par les trucs genre "photo of the day"....."
La première réponse que j'ai eu, dans les 2 minutes (et, pour les personnes présentes dans l'amphi qui m'ont entendu poser la question, je confirme: c'est du vrai !!!), c'était ca:
"bah on fait quoi de nos journées alors ?"
Du coup, pour la solution "sensibiliser les utilisateurs", j'ai un gros doute, même après une discussion off line dans la foulée avec les auteurs de la conf......
Pour cette conf, y'a que le lien vers la pres sur le site du SSTIC qui est en francais, ca va demander un peu plus de concentration, donc..... heureusement qu'elle n'a pas été programmée le lendemain matin du social event ! :-)
Et ca cause GSM, donc (note pour ma soeur: on parle de ton téléphone portable, tu sais, le truc qui a maintenant un mode vibreur.......), en commencant par une présentation du contexte, de l'industrie du GSM, etc..... je sens que je vais me focaliser sur la fin de la conf, ou il va probablement faire plein de trucs méchants sur tout ca :-D
Le monde de la téléphonie GSM est donc une belle ile verte et chaude, habitée par des bisounours..... enfin, c'est la vision qu'en ont les opérateurs et constructeurs du domaine, apparemment..... Ca doit effectivement laisser plein de possibilités à des gens curieux..........
La suite de la présentation explique un peu plus précisément le projet OpenBSC, qui vise à fournir une implémentation OpenSource de tout ce bordel GSM (je vous résume comme j'ai compris :-) ), justement pour pouvoir faire mumuse, comprendre, expérimenter, tout ca, tout ca.....
Ahhhhh.... l'analyse d'un point de vue sécurité....... bah ca fait peur !!!!
Résumons:
Bah voila, je suis rassuré, moi, d'un coup..... ou..... pas ?
Ca finit assez vite, faute de temps... eh oui, le comité de programme du SSTIC ne déconne pas:
Mais allez lire le papier quand il sera en ligne..... vraiment......
Bon... suivre les rumps, blogguer dessus et faire les photos en même temps, par expérience, c'est chaud..... et la petite 1/2 heure de pause est un peu juste pour se préparer psychologiquement à ce délicat exercice......
Bon, j'ai opté pour la solution "photos et récupération de tshirts de l'année dernière", même si la partie "récupération de tshirts" se fait parfois au péril de sa vie, vu la technique utilisée pour les envoyer aux personnes:
..............
Un peu plus tard, donc...... Ouaip, j'ai séché la fin du social event, j'ai fait l'impasse sur la fin de soirée rue St Anne, on vieillit, que voulez vous..... et faut dormir un peu pour assurer la route du retour demain......
4 minutes par Rump, pas une seconde de plus, c'est la règle..... mais au vu des photos à portée de clavier, ma première version de blog "1 ligne par rump" est parfois en fait un peu juste.....
Revoyons donc la scène au ralenti:
Début de la rump session... Fin de suspense, le programme est annoncé (chouette, je peux vérifier que j'ai pompé intelligemment sur le blog de Sid hier pour les noms des rumps....):
Pendant ce temps, les orateurs sont au taquet, prets à bondir pour profiter au maximum de leurs précieuses 4 minutes......
27.... c'est le seul nombre que j'ai retenu de cette rump, faite par le bureau du STIC (non, j'ai pas oublié un "S", je parle de l'asso qui organise le SSTIC)...... 27, donc, le nombre de femmes inscrites (et présentes ?) au SSTIC cette année !!!!
Sujet intéressant, mais pour être franc, j'ai pas accroché à la rump......
Un superbe dégommage en règle d'un Renaud en pleine forme, des rumps comme on aimerait en voire plus souvent :-)
Ou comment avoir un café gratos à la machine à café super moderne qu'on utilise avec une carte et pas avec de la monnaie..... Dommage, j'ai pas repéré la marque de la machine, sinon j'aurais proposé de passer à ce modèle la au taf :-D
Si j'ai bien compris, le but de cette rump était de montrer certaines limites de Photorec, pourtant un outil sympa, d'après les rumps des années précédentes :-D
Présentation super super rapide d'un outil de "data mining", extraction et gestion d'info (faut que j'arrête de pomper aussi directement sur le blog deSid, moi, ca va finir par se voir), avec en prime une interface qui n'a pas grand choseà envier aux meilleurs (?) films américains.....
2 projets de sites webs liés à la sécurité, qui devraient être mis en ligne la semaine prochaine. Ca vaudra le coup d'aller se ballader un peu sur ces sites, manifestement.
Présentation d'un concours de stéganographie qui va avoir lieu cette année.
Euh .... un firewall USB qui permet de s'assurer qu'on ne fait transiter que du texte (limitation des caractères ASCII autorisés), si j'ai bien suivi. Surement super intéressant dans le cadre d'utilisation d'EDF, mais je vais encore attendre un peu avant de m'en acheter un.....
J'ai surtout retenu la phrase "AD, c'est la dechetterie du Système d'Information".....
En gros, c'est de la modification à la volée de tout ce qui est PDF, pour (essentiellement, mais pas seulement) désactiver tout ce qui est Javascript et qui sert à créer la foultitude de PDFs "offensifs" sur les outils Adobe (voire sur d'autres lecteurs PDF).
Euh..... j'arrête de recopier Sid, allez directement voir chez lui, j'ai décroché, sur celui la.......
En gros, l'idée est de ne plus faire QUE du pentest/audit d'intrusion à un instant T, mais de surveiller ca régulièrement..... Forcément, l'idée est pas con (y parait même que des sociétés locales ont existé sur cette idée, y'a longtemps.....), faudra voir ce que ca donne dans la vraie vie......
Ou comment faire passer ce qu'on veut comme flux réseau dès qu'on a un accès RDP sur une machine.
Pour une démo codée à l'arrache, on va pardonner l'effet Murphy en première tentative, surtout qu'ils sont revenus à la charge en fin de rumps pour montrer que ca marche, en fait.
Ou comment transformer un Oracle en proxy HTTP (ou proxy de plein d'autres trucs, apparemment).
Eh, je viens de comprendre le jeu de mots dans le sujet de la rump !!! :-)
Je viens à peine de comprendre ce subtil jeu de mots, pour nommer un outil qui pilote (capitaine) des automatisations de scripts Scapy (quoi ? vous ne connaissez pas Scapy ? dehors !!!).
Mais c'est surement plus clair avec les slides de Phil:
A montrer à l'équipe de qualif dès lundi.....
Au Coq Hardi, comme l'année dernière. Sympa, spacieux, buffet dinatoire très bon.... Mais bon, maintenant qu'on connait la part du social event dans le budget SSTIC, encore heureux !!! :-D
« billets précédents - page 1 de 4