Raid1 soft avec Asus P5B-VM sous opensuse 10.1

Après avoir realisé une installation de ma suse 10.1 sur un disque configuré en RAID1 soft, j’ai eu la désagreable surprise de trouver un kernel panic au boot du style : VFS: Cannot open root device “…” or unknown-block(…,…)

Il semble qu’a ce moment là du demarrage le disque md0 ne soit pas encore bien monté (problème de module sans doute)… la solution simple pour s’en sortir est de préciser dans les paramètre du boot que root n’est pas sur /dev/md0 mais sur /dev/sda1 par exemple … ce qui ne change pas fondammentalement grand chose si ce n’est qu’en cas de defaillance de sda1, il faudra penser à preciser sdb1 pour que ca boote.

La procédure n’empeche absoluement pas / d’etre monté sur md0 une fois la machine bootée. Il faudra modifier les parametres de grub dans /boot/grub/menu.lst pour ne pas être obligé de réitérer la manip à chaque lancement.

RTL8111b sur P5B-VM sous Opensuse 10.1

Je viens d’acheter un carte mère Asus P5B-VM basée sur un chip réseau gigabit Realtek RTL8111b de la famille des r1000. Ce dernier n’est pas reconnu et mon installation réseau en est un peu compliquée … Je vous livre ici comment je m’en suis sorti …

Il est tout a fait possible de charger un module lors de l’installation, le tout etant de l’avoir. Pour cela, il faut recopiler le driver Realteck sur une suse de même version pour obtenir le module … je vous livre ici mon module pour la suse 10.1 (version 32b) et ici la version SMP pour suse 10.1… ca vous fera toujours gagner une etape ..

Pour ceux qui souhaitent le recompiler par eux-même, il y a deux choses à savoir :

  • Il faut modifier src/Makefile et remplacer $(PWD)/Makefile_linux26x par le chemin complet de ce même fichier
  • Il faut remplacer dans src/r1000_n.c les 3 lignes MODULE_PARM par MODULE_PARM_DESC

Ensuite il faut copier ce module sur une clef USB par exemple. Lancer l’installation et lorsque l’on arrive sur les premières fenetre de YAST
De là il faut :

  • Appuyer sur CTRL+ALT+F9 pour passer sur une console
  • Monter la clef usb : mount -t vfat /dev/sda1 /mnt
  • Ajouter le module : insmod /mnt/r1000.ko

En appuyant sur CTRL+ALT+F1, vous retournez alors sur l’installeur yast et l’installation réseau pourra commencer.

Attention, il faut aussi noter que le chipset G965 n’est pas reconnu avant le 2.6.18 et donc pas avant la suse 10.2. Toutefois ce n’est pas ce chip qui pose des problème mais le Southbridge JMicron qui n’etant pas du tout reconnu empèche la détection des disques dur IDE et même du CDROM une fois l’installation lancée. Cependant pour installer linux sur une SATA via le réseau, ca fonctionne …

Revenons à nos moutons … une fois Linux installé, il faudra se recompiler une nouvelle fois un driver, il ne faut donc surtout pas oublier d’installer le package kernel-source sans quoi, après c’est trop tard ! Au premier redemarage, dès que yast se lance, il est possible de trouver un console pour compiler un nouveau module. Attention, le Makefile ne fait pas de depmod -a lors de l’installation … pensez à l’ajouter !
Enfin, la recompilation sera à faire après les mise à jour de noyau … Au passage, pour forcer l’usage d’un module pour un périphérique reseau, il faut jeter un oeil dans /etc/sysconfig/hardware, c’est à cet endroi que l’association se fait.

Utilisation du Pata JMicron sur P5B-VM sous Opensuse 10.1

Bon … pour accéder au controleur PATA JMicron de la carte mère Asus … c’est pas gagné !!! En tout cas on finit par y arriver avec un peu de patience. Dans la doc c’est possible, et ca l’est en effet, mais ce n’est pas trivial. Je vous donne la liste des manip que j’ai dû faire :(sans pour autant garantir que tout soit utile

  • Dans le bios, configurer le JMicron en mode AHCI
  • Booter l’install de la 10.2 puis dès que possible passer sur un terminal (CTRL+ALT+F9)
  • Charger le module par modprobe pata_jmicron
  • Jeter un oeil avec dmesg pour voir ce qui s’est passé …

Pour ma part le cdrom est sur /dev/sr0 et le disque dur semble etre sur /dev/sdb

Cette manip faite il ets presque possible d’installer suse 10.2 à partir du CD, j’ai toutefois du passer par la case “vérification du support” avant que l’installeur veuille bien me monter le cdrom

Revenir au double click sous KDE

Franchement …. le simple clic c’est chiant !! passer son temps à ouvrir des documents alors qu’on souhaite faire une selection multiple est gavant ! bref, retour aux concepts initiaux : le double clic… problème où est cette foutue option dans KDE !

Après quelques longues recherches : la solution est

  • Panneau de config de KDE
  • Périphérique / Souris
  • Option Simple/Doucle clic

Sauvé !

Propagation de virus au travers de Wifi (anticipation)

Le fait de voir toutes ses AP visibles depuis mon réseau Wifi me font imaginer une nouvelle façon de propager un virus … un système nouveau efficasse et totalement automatique … Bien sure c’est totalement imaginaire, mais peut etre l’avenir ?
Voici quelques idées un peu en vrac…
Les virus que je trouve les plus impressionnant et interressant (disons intellectuellement parlant uniquement) sont ceux qui sont capable de s’auto-répliquer sans action de la part de l’utilisateur : ils sont emis par des machines infectées qui vous attaquent presque au hazard quand vous vous connectez sur Internet par exemple, s’installent puis se répliquent …

Le voie de contamination par l’Internet est connue, est en partie protégée par les systèmes de NAT et firewall intégrées aux routeurs.
Il existe maintenant une nouvelle voie de propagation : nos point d’accès Wifi. En effet, un virus, une fois installé sur une machine pourrait etre capable de scanner l’entourage wifi de votre réseau puis de mettre en oeuvre les technique d’attaque connue pour pénétrer ces réseaux voisins. Il pourra ensuite s’y dubliquer et les copies attaqueront les reseaux voisins… et ainsi de suite.

Avec le maillage Wifi actuel fournit par nos provider hexagonaux, la propagation de la contamination, en ville pourrait etre rapide et très large.

Les applications sont très larges et depassent d’usage classique d’un virus en permettant aussi la creation d’un reseau urbain logique multi-point de sortie / anonymisation …

Tout celà est totalement imaginaire, à ne surtout pas mettre en oeuvre bien sure, mais je trouve l’idée assez interressante.

Pour exister il faut au moins :

  • Une faille exploitable permettant l’auto-réplication des virus
  • Une methode d’attaque Wifi simple et rapide pour le Wep (on l’a) et le WPA
  • Une compatibilité de cette attaque avec le matériel wifi répendu et fonctionnant sous Windows

Avantages :

  • la diffusion du virus est quasiement impossible à tracer
  • La diffusion du virus passera par la voie des airs grace aux machines mobiles, elle penetre de fait une bonne parties de protections de réseaux classique
  • Elle peut s’en prendre à des appareils mobiles pourquoi pas (téléphones, PDA)

Applications :

  • Espionnage et surveillance
  • Constitution d’un reseau anonyme et utilisable de n’importe où en milieu urbain
  • Constitution d’un reseau à très fort maillage et donc très resistant
  • Classique groupe de robots d’attaque…

Cryptage WEP – Comment fonctionne-t-il ?

Quelques lignes pour décrire le fonctionnement d’un cryptage de type wep …
Le WEP (Wired Equivalent Privacy (lol)) repose sur un cryptage simple de type XOR (ou exclusif) entre la chaîne initiale et une clef de même longueur. La dite clef est obtenue par un algorithme RC4 initialisé à partir d’une clef partagée et un IV (Initialization Vector) aléatoire ou tout au moins dynamique.

Le cryptage se fait de la façons suivante :
– L’emetteur choisit un IV de 24 bits qu’il concatène à la clef partagée. De cette façon nous obtenons 2^24 clefs différentes à partir d’une clef partagée statique, elle même de 104 bits (pour un total de 128 bits).
– Le RC4 est initialisé avec cette clef : le but du RC4 est de remplir un tableau de 256 octets avec cette clef, puis de piocher dans ce tableau des valeurs tout en les modifiant au fur et à mesure. Cette methode permet à partir d’un clef d’obtenir une suite unique et pseudo aléatoire de valeurs à sa sortie.
– La sortie du RC4 est ensuite utilisée pour crypter la chaîne à envoyer. Le RC4 genère un flow de bits (ou octets) infini, il est donc tout à fait adapté au cryptage de données de longueur variable comme des trames réseaux.
– La trame est émise vers le destinataire en incluant l’IV de sorte que le destinaitre soit capable de recréer la même suite RC4 pour décrypter le message.
– Le recepteur est donc à même de générer une clef de (dé)cryptage identique à l’emeteur, issue de RC4, il ne lui reste plus qu’à appliquer la même fonction que pour le cryptage puisque (N XOR K) XOR K = N avec N le message initial.

Voila comment celà se passe, comment celà est-il attaqué alors ?
– Tout d’abord, avec une seule clef partagée, il y a 16M de clefs générées, ce qui signifie que la véritable clef de cryptage issue du RC4 change régulièrement, pour ainsi dire à chaque trame ce qui complique la donne.
– Pour attaquer ce type de cryptage, il faut donc tout d’abord s’attaquer à la véritable clef de crytage issue de RC4 et l’identifier ; en identifier un maximum. Pour se faire il est nécessaire de connaitre des données claires et cryptées, récupérer la clef est alors simple, il suffit d’appliquer : (N XOR K) XOR N = K. Cette opération est possible sur certaines trames récurentes dont l’entete est connue des ARP par exemple, ce qui permet de connaitre les premiers octets de la suite.
– Une fois que l’on a collecté de multiples entêtes de clefs issues de RC4 avec leur partie IV associée, il reste à trouver quelles sont les clefs sources ayant le plus probablement conduit à cette génération et ainsi déterminer la clef partagée initiale.
– Cette approche est statistique puisque plusieurs clefs peuvent conduire au même début de suite issu de RC4 (et nous ne connaissons que le début !) Ainsi nous ne pouvons calculer que des suppositions sur le contenu initial du tableau RC4 et eliminer des solutions impossibles.
– De fait pour optimiser la recherche, il est nécessaire, soit d’avoir un maximum de trames et d’IV (de 500.000 à 3 M en général), soit d’avoir des suites plus longues issues du RC4.

Comment fonctionne WEP ?

C’est à grand renfort d’articles sur tout la toile qu’un nouveau POC (Proof Of Concept) vient annoncer que WEP est mort ! rien de bien nouveau en soit puisqu’on l’avait dejà tué depuis des années, mais cette fois la méthode est plus rapide, plus automatique et sans doute bientot à la portée de tous, ou presque.

Est-ce alarmant ? en soit, utiliser Wep est alarmant depuis bien longtemps, donc un peu plus un peu moins ? et si vous dormez sur vos deux oreiles malgré cela et bien continuez ! il n’y a pas de raisons ; le tout c’est d’en être concient, non ?

Qu’est ce que cette nouvelle methode de Bitau, Handley et Joshlack ? Elle repose en fait sur l’utilisation d’un utilitaire existant dans le protocole 802.11 (Wifi) : la fragmentation de trame ou plutot la défragmentation par l’AP. Le rôle de l’AP dans un réseau avec architecture est de recevoir les trames de tout le monde puis de les réémettre : ainsi si tout le monde capte l’AP, tout le monde peut communiquer, y compris si deux postes sont trop distants pour se joindre directement … L’AP etant un périphérique intelligent, lorsqu’il recoit des fragments de trames, il commence par les réunir en trame plus grosses avant de les réémettre. Alors comment cela nous aide-t-il a craquer une clef Wifi, c’est assez simple :
Avec le cryptage WEP, qui n’est autre qu’un simple XOR, il suffit de connaitre une chaine et son equivalent crypté pour connaitre la clef de cryptage, donc puisque nous captons des données cryptées, il nous faut connaitre leur equivalent non crypté pour connaitre la clef associée. Les protocoles de couches basse nous aident en celà : certaines trames LLC/SNAC, ARP ont des parties qui sont constantes et celles-ci sont identifiables par des tailles caractéristiques. En captant ces trames, nous avons des données cryptées et connaissons leur équivalent non crypté. Ainsi il est possible d’obtenir facilement quelques octets de la clef de cryptage (qui n’est cependant pas directment la clef partagée que l’utilisateur configure).
Cette étape accomplie, la nouvelle solution par fragmentation entre en jeu : les morceaux de clef que nous avons sont trop petits, la fragementation va nous permettre de les multiplier : il suffit de renvoyer plusieurs fois la trame reçue en l’indiquant fragmentée : connaissons la cryptée et son équivalent décryptée. L’AP va recevoir ces fragments, les décrypter et les assembler dans une nouvelle trame qu’il va crypter puis, enfin, réémettre cettre trame sur le réseau. Cette trame nous allons pouvoir l’écouter, nous connaissons sa version non cryptée puisqu’il s’agit de la concaténation du message precédent avec lui-même et l’AP vient de nous fournir sa version cryptée. Nous sommes donc à même, comme à l’étape 1 de connaitre la clef associée, mais cette fois nous n’avons plus 8 octets mais n*8 octets (avec n le nombre de framents).

En continuant ainsi il est possible d’obtenir une clef de cryptage valide suffisemment grande pour crypter n’importe quel paquet. Nous allons donc pouvoir emettre sur le réseau n’importe quel paquet, sans connaitre la clef partagée initiale mais simplement la suite issue du RC4. Cette facultée va nous permettre de générer du traffic valide vers le réseau et ainsi collecter un maximum de trames pour, par la suite, lancer une attaque sur ces informations et en déduire la clef partagée (type aircrack).
Cette methode, présentée ainsi est donc une solution plus rapide et encore imparable pour générer du traffic : le principe de defragmentation est à la base du protocole, il est difficile de le bloquer alors que bloquer les réémissions forcée d’une methode aireplay est assez courant. Par ailleurs, il permet de connaitre bcp plus de données de chaque chaînes cryptées (contrairement aux ARP habituels) et ainsi d’etre plus efficasse avec moins de trames.
Cette mehode reste totalement interdite à l’utilisation hors de son propre réseau privé puisqu’elle demande l’emission de données vers le réseau distant, ce qui implique une intrusion dans le dit système, Acte répréhensible par la lois.

Les auteurs de cette methode, proposent une autre alternative à la simple collecte d’informations en vue de connaitre la clef partagée ; en effet, ils proposent d’utiliser cette methode, associée à d’autres pour forcer l’AP à router des paquets cryptés vers l’Internet : dans ce cas, le paquet emis en direction de l’Internet est décrypté par l’AP avant d’etre envoyé sur la ligne (logique on sort du WLAN). Le site distant est alors un site amis du pirate qui va ainsi recevoir les données décryptées issues du réseau WLAN dit “sécurisé” … pas mal ! Le principe en est assez simple, il s’agit de créer une entête IP a destination du serveur sur l’Internet, de l’indiquer fragmenter et de réémettre un paquet crypté que l’on souhaite faire décrypter en l’indiquant comme étant la suite du précédent. L’AP va alors decrypter les deux, concaténer le paquet “secret” à notre entete IP, constater qu’il s’agit d’une trame pour l’extérieur et la router décryptée. Reste que ce type d’attaque est plus facile à tracer qu’un wardriving sauvage, rendu rapide par la methode.

Quid de l’implémentation ? Les auteurs proposent quelques sources de leur POC, la mise en oeuvre demande un contrôle au niveau le plus bas des cartes Wifi, pour, entre autre, gérer les flags permettant la fragmentation au niveau logiciel. Ces possibilités ne sont pas offertes sure toutes les puces ou demandent des workaround un peu touchy .. bref, pour l’instant 2 chips sont supportés dont le PRISM2. Il y a de fortes chances pour que d’autres arrivent.
Point vraiment interressant, ce qu’ils ont mis en oeuvre est totalement automatisé, contrairement à ce qui existe sur aircrack. Les outils aircrack ne peuvent pas etre mis entre toutes les mains, elle doivent toujours être averties : ligne de commandes, options compliquées… Une solution entierement automatisée pourrait etendre la chose aux pirate boutoneux du dimanche …
Il n’en reste pas moins que ca ne marche et ne marchera sans doute jamais que sous Linux et autre BSD ;o)

Dell L400 et configuration ACPI

Autant sur une machine de bureau, l’acpi on vit bien sans, autant sur un portable on frole de danger si ca ne marche pas correctement ; à mettre en rapport avec mes remarques sur la suse 10 et 10.1 qui m’on values quelques arrets pour surchauffe ! Une solution qui semble bien fonctionner : couper l’acpi au démarrage (acpi=off) lors du prompt de sorte à laisser le bios se débrouiller…

Pour faire plus propre, il est toutefois possible de “débugger son acpi” : en fait, dans les distro classiques, on va avoir une configuration acpi générique : elle fontionne bien dans beaucoup de cas, mais pas toujours (un portable standard ca existe ?). Il est alors possible de mettre à jour l’acpi pour qu’il supporte correctement la machine… En voici la recette, appliquée sur mon L400.

  • Se procurer le fichier DSDT adapté au portable. (Tout est dans ce fichier de description de l’acpi !). Pour se faire, il faut télécharger le fichier sur cette adresse en précisant le constructeur et la marque.
  • Il faut ensuite compiler se fichier à l’aide de l’utilitaire fournit par Intel ici en choisissant la version source unix. Il faudra d’abord compiler le compilateur (nécessite bison et flex) en lançant make dans le répertoire compiler. Il faudra ensuite compiler la DSDT précedemment télécharger avec la commande suivante :
    iasl -tc dsdt.asl ce qui devrait générer un fichier de type dsdt.hex qui n’est d’autre en fait qu’un fichier de type “.h”
  • L’etape suivante consiste à recompiler son noyau pour ce celà soit pris en compte. Tout d’abord preparrons un noyau : make clean ; make mprpoper; make cloneconfig puis lancer la configuration via X make xconfig
  • La configuration de la nouvelle DSDT est, sur les noyaux 2.6.13 plus simple que ce qui est décrit sur les HOWTO classiques : dans la rubrique Power management options/acpi/ il faut cocher Include Custom DSDT puis double clicker sur Custom DSDT Table file to include et entrez le chemin complet jusqu’au fichier .hex.
  • Il reste à compiler le noyau :make
  • Enfin, il faut recopier le noyau ainsi obtenu dans le répertoire /boot. le noyau se trouve dans le répertoire /usr/src/linux/arch/i386/boot sous le nom de bzImage, il sera compié dans /boot sous le nom de vmlinuz-xxxx-version-xxx-acpi par exemple (voir le format de celui existant) et il faudra alors mettre à jour le lien symbolique de vmlinuz.
  • Pour terminer… on reboote