NAS : passage au crible du Synology DS-101

Transcription

NAS : passage au crible du Synology DS-101
Ceci est un extrait électronique d'une publication de
Diamond Editions :
http://www.ed-diamond.com
Ce fichier ne peut être distribué que sur le CDROM offert
accompagnant le numéro 100 de GNU/Linux Magazine France.
La reproduction totale ou partielle des articles publiés dans Linux
Magazine France et présents sur ce CDROM est interdite sans accord
écrit de la société Diamond Editions.
Retrouvez sur le site tous les anciens numéros en vente par
correspondance ainsi que les tarifs d'abonnement.
Pour vous tenir au courant de l'actualité du magazine, visitez :
http://www.gnulinuxmag.com
Ainsi que :
http://www.linux-pratique.com
et
http://www.miscmag.com
embarqué
analyse
 NAS : passage au crible
du Synology DS-101
Denis Bodor
EN DEUX MOTS Que vous disposiez de quelques
machines personnelles où que vous soyez en
charge de l’administration d’un LAN dans une
PME, l’utilisation d’un NAS est souvent une bonne
idée. Le coût des solutions « entrée de gamme »
ne cessant de chuter, nous avons essayé et étudié
l’un de ces produits.
e modèle sélectionné est un
DS-101 fabriqué par la société
Synology. Le fabricant présente
le produit comme une solution
SOHO (Small Office/Home Office) et donc
entrant précisément dans le cadre de cet
article.
Le produit testé est relativement populaire
en Europe, mais peu aux États-Unis. En effet,
pour quelques 230 Euros TTC, on dispose
d’un boîtier dans lequel peut s’intégrer un
disque IDE allant jusqu’à 400 Go.
Le DS-101 se connecte ensuite à un réseau
Ethernet 10/100Mbps et permet différentes
utilisations :
Partage disque Windows ;
Partage disque Mac ;
Connexion et partage d’une imprimante
(USB) ;
Copie automatique de données en
provenance de clefs, d’appareils photo ou
disques USB.
Voilà pour ce qui est des caractéristiques pour
monsieur « tout le monde ». En regardant de
plus près, les spécifications données par le
constructeur, on en apprend un peu plus :
Processeur Intel IXP420BB : il s’agit d’un
cœur Intel XScale® auquel s’ajoutent une
interface PCI, un contrôleur USB et deux
interfaces Ethernet 10/100Mbps (une seule
est utilisée avec le DS-101). Rappelons que le
XScale® est le successeur du StrongARM.
64 Mo de mémoire SDRAM. Ici rien
d’étonnant. Comme le montrent les photos
illustrant l’article, la mémoire est directement
soudée sur la carte mère du périphérique. 64
Mo est une quantité de mémoire relativement
importante pour un système embarqué.
16 Mo de mémoire Flash ou plus exactement
un M-system DiskOnChip MD2811-D16V3Q18 utilisant la technologie TrueFFS. Un
tel disque de mémoire flash est très facile
90
d’intégration. Il apparaît en effet comme un disque pour le
système d’exploitation.
Protocoles réseau TCP/IP et Apple Talk, bref, du standard.
Sélection d’IP via DHCP ou configuration manuelle.
Protocoles de partage de fichiers Microsoft Networks CIFS
et Apple File Protocol AFP 3.X. Il manque quelque chose. Si,
si, cherchez bien... En trois lettres, commençant pas un « N »
et finissant par un « S »...
Services réseau divers comme FTP, NTP, HTTP...
Mise en marche
Arrêtons là les spéculations et passons à la pratique. L’intégration
d’un disque 3"1/2 est un jeu d’enfant. Quelques vis, une
connexion à la nappe et à l’alimentation et c’est fini. Le
disque doit être initialisé pour être pris en charge par le
périphérique.
Un appui maintenu de 4 secondes sur le bouton [reset], suivi
d’un nouvel appui après 5 secondes déclenche l’opération.
Après deux signaux sonores, le système embarqué dans le
DS-101 s’en prend au disque. Nous verrons plus loin ce qui
se passe exactement à ce moment. Notons au passage que le
disque, après cette étape, devient inutilisable sans reformatage
(véritablement inutilisable, cf. plus loin).
Une fois le disque initialisé et le produit redémarré, celui-ci
s’empresse d’envoyer des requêtes DHCP. Une machine
préalablement configurée avec le serveur ICS dhcp3 lui
attribue une adresse :
DHCPDISCOVER from 00:11:32:00:4a:d4 via eth0
DHCPOFFER on 192.168.0.11 to 00:11:32:00:4a:d4 via eth0
DHCPREQUEST for 192.168.0.11 (192.168.0.10)
from 00:11:32:00:4a:d4 via eth0
DHCPACK on 192.168.0.11 to 00:11:32:00:4a:d4 via eth0
Dès lors, le serveur web intégré au boîtier peut être utilisé
pour configurer la bête. Un assistant guide l’utilisateur dans
les étapes de configurations minimales.Après paramétrage, en
bon curieux, on peu se pencher sur le partage Windows :
% smbclient -L 192.168.0.11
Password:
Domain=[CASSIS] OS=[Unix] Server=[Samba 3.0.0beta3]
Sharename
--------public
IPC$
ADMIN$
Type
---Disk
IPC
IPC
Comment
------System default share
IPC Service ()
IPC Service ()
Domain=[CASSIS] OS=[Unix] Server=[Samba 3.0.0beta3]
Server
---------
Comment
-------
Workgroup
---------
Master
-------
Le résultat est clair : Samba 3.0 beta. On dirait bien que
nous ayons sous la main un système Linux embarqué pour
 GNU Linux Magazine France
CPU ARM/XScale®. Confirmons le soupçon avec un scan
de port :
% nmap -O 192.168.0.11
Starting nmap 3.75 ( http://www.insecure.org/nmap/ )
Interesting ports on 192.168.0.11:
(The 1657 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE
21/tcp open ftp
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
515/tcp open printer
548/tcp open afpovertcp
MAC Address: 00:11:32:00:4A:D4 (Synology Incorporated)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 0.002 days (since Wed Aug 24 14:26:11 2005)
Cette fois, plus de doute, il s’agit bien d’un noyau Linux 2.4.
Mais pourquoi donc limiter les partages à SMB, AFP et FTP ?
Un système embarqué GNU/Linux sur 16Mo de mémoire
flash et disposant de 64Mo de SDRAM peut faire bien mieux
que cela. Qu’à cela ne tienne, si le constructeur oublie des
choses, nous allons les ajouter.
Creusons un peu
Les pages web de support sur le site officiel proposent divers
téléchargements parmi lesquels une image du firmware et les
sources en GPL du système Linux embarqué. A ce moment
là, on se croit sauvé... mais on déchante rapidement. Après
un téléchargement pénible à 16Ko/s depuis un site FTP
poussif, on récupère une archive ds101-157.tgz de quelques
157 Mo (je vous laisse le plaisir de faire le calcul du temps
nécessaire).
Trépignant d’impatience, on désarchive le fichier et... déception.
On obtient quelques 25 répertoires contenant les sources
plus ou moins modifiées de chaque composant. Apache,
BusyBox, IPtables, HotPlug, PHP, uCLinux, uClibC... Pas de
README, pas de documentation incluse, rien.Après une petite
promenade dans les quelques 627 Mo de fichiers, on en
apprend un peu plus.
Quelques répertoires debian traînent de-ci,
de-là. Les sources d’uCLinux sont quelque peu
modifiées et la compilation automatisée via
un script. Un répertoire lnxsdk contient du
code GPL spécifique au fabricant. Cependant,
rien ne permet de construire simplement
le système tel qu’il est présent dans le
produit final.
Laissons de coté les sources pour le moment.
Avec beaucoup de courage, de chance et
de temps, il doit être possible d’obtenir
un firmware fonctionnel. Ceci, à condition
de savoir à quoi ressemble le système en
question.
Pariant sur les bruits, des plus suspects, lors
de l’initialisation du disque et de l’allumage
du produit, on en arrive à soupçonner le
système de ne pas démarrer sur la mémoire
flash directement. Si c’est le cas, le système
GNU/Linux est donc installé sur le disque
intégré au produit.
Il nous est donc peut-être possible d’accéder
aux données et de modifier directement le
système en place. Cette approche, en plus
d’être simple, présente un net avantage : elle
permet de laisser le firmware du fabricant
dans l’état.
En effet, en construisant un firmware
personnalisé et en le téléchargeant dans
le périphérique, nous annulons la garantie.
De plus, si le firmware en question n’est pas
fonctionnel, une fois en place, nous n’avons
plus de solution de rattrapage, puisque la
mise à jour se fait via l’interface web.
Il doit certainement exister des procédures
de secours et de restauration du firmware
(un mode debug ?), mais nous n’avons pas
accès à ces informations.
Le disque sorti de son logement et placé
dans une machine se révèle effectivement
aussi bavard que prévu :
Device Start
End Blocks Id
/dev/hdd1
1
271 136521
/dev/hdd2
271 1052 393592+
/dev/hdd3 1323 3140 915705
/dev/hdd4 1052 1182
65536
Fig. 1 : La carte du DS-101 semble être relativement générique.
On remarque qu’une partie des emplacements sont vides comme
sur la droite pour un chip réseau Kendin et au centre ce qui
pourrait bien être une extension de bus.
Numéro 76 / Octobre 2005
System
83 Linux
82 Linux swap
83 Linux
83 Linux
Quatre partitions, dont un swap de quelques
400 Mo !!! On suppose que la première
partition est réservée au système ou aux
données « variables » du système comme
les journaux, etc.
La troisième partition, au vu de sa taille,
correspond à l’espace de stockage partageable
en réseau. Le disque utilisé ici pour le test
est un très modeste Western Digital Caviar
de 1,6 Go.
91
embarqué
Analyse
Malheureusement, toute tentative de montage
de l’une de ces partitions est un échec. Il ne
semble s’agir d’aucun système de fichiers
connu de Linux. Les partitions sont pourtant
bien marquées d’un type correspondant, mais
rien n’y fait. En désespoir de cause, on finit
par utiliser hexdump directement sur l’une
des partitions :
00010000
00010010
00010020
00010030
00010040
00010050
52
00
84
12
03
01
85
00
03
00
00
00
00
00
00
01
00
00
00
00
00
00
00
00
1b
00
1e
53
03
4d
57
20
00
79
00
04
00
00
00
4e
02
59
00
00
00
6f
00
9a
81
00
00
52
02
b8
22
04
00
73
00
1e
00
00
00
32
00
4e
00
00
00
46
00
b2
12
30
00
73
71
a1
00
51
10
00
00
a8
00
c1
cc
00
00
56
00
40
03
00
00
2d
|R....W...»......|
|..... ......0QÁ@|
|..............Ì.|
|....SyNoRs2Fs...|
|............q...|
|....M.Y.¸.N²¡¨V-|
La présence d’un répertoire reiserfs362
aidant, on remarque dans les premières
données de la partition, la chaîne SyNoRs2Fs :
Synology ReiserFS ? Pour en avoir le cœur
net, nous avons les sources et, après un
rgrep, on finit par trouver la cause du
problème dans le fichier reiserfs362/
include/reiserfs_fs.h :
#ifdef SYNO_REISERFS
#define REISERFS_SUPER_MAGIC 0x25521814
#define REISERFS_3_5_SUPER_MAGIC_STRING «SyNoRsFs»
#define REISERFS_3_6_SUPER_MAGIC_STRING «SyNoRs2Fs»
#define REISERFS_JR_SUPER_MAGIC_STRING «SyNoRs3Fs»
#else
#define REISERFS_SUPER_MAGIC 0x52654973
[...]
#define REISERFS_3_5_SUPER_MAGIC_STRING «ReIsErFs»
#define REISERFS_3_6_SUPER_MAGIC_STRING «ReIsEr2Fs»
#define REISERFS_JR_SUPER_MAGIC_STRING «ReIsEr3Fs»
#endif
Les sources du support ReiserFS ont été
modifiées de manière à supporter un
identifiant de système de fichiers différent.
Mais la modification va plus loin. En effet,
en recompilant un module reiserfs.ko
légèrement modifié de manière à utiliser
un identifiant correspondant aux partitions, nous pouvons
monter le système de fichiers.
Cependant, les données ne sont pas lisibles, ni même la hiérarchie
des répertoires. Le fabricant semble donc effectivement
avoir modifié le support ReiserFS au-delà de la simple chaîne
d’identification. Chose confirmée par un coup d’œil dans les
sources et le fichier /uclinux2422/linux-2.4.x/include/
linux/syno.h et synobios.h.
La question qu’on se pose tout naturellement est « Pourquoi ? ».
Linux dispose de suffisamment de souplesse et de fonctionnalité
pour se passer d’une telle manipulation. Savoir si cette
modification est légitime ou non nécessiterait une étude plus
approfondie des sources. On y parle effectivement d’« Archive
bit support on our ReiserFS ».
Bien sûr, il vous reste une solution : comprendre et développer
un support GNU/Linux pour votre ordinateur de bureau afin
de lire et d’accéder aux données contenues sur les partitions
utilisant un système de fichiers ReiserFS modifié.
Sachez que les sources reiserfs362 présentes dans l’archive
du fabricant se compilent sous GNU/Linux. Mais ce n’est là
qu’une partie de la solution. Il vous faudra adapter le code
uCLinux à votre système pour obtenir un module noyau. Bonne
chance, bon courage ou bon amusement... c’est selon...
Une autre voie
La solution du disque dur est un échec.Voyons si nous pouvons
trouver un autre chemin en regardant du côté du firmware
mis à disposition par le constructeur. Nous récupérons donc
la « Mise à jour du progiciel pour DS-101 v.2.0.1-3.0200 »
sous la forme d’un fichier synology_ixp420_1hd.pat.
Comme c’est souvent le cas pour les firmwares, l’extension
ne révèle en rien la nature des données, bien au contraire. Il
n’est cependant pas difficile de voir de quoi il retourne :
% file synology_ixp420_1hd.pat
synology_ixp420_1hd.pat: POSIX tar archive
Ce qui nous fait embrayer directement sur :
% tar xvf synology_ixp420_1hd.pat
AllLib.tgz
checksum.syno
rd.gz
updater
VERSION
zImage
Les petits fichiers checksum.syno et VERSION ne sont pas
forcément intéressants. On remarque toutefois que le
fichier contenant les sommes de contrôle n’est pas standard.
Une ligne mentionnant un binaire Synocksum est d’ailleurs
commentée.
C’est sans doute ce binaire qui est chargé de calculer les
sommes de contrôle et il aura été exécuté dans le répertoire,
d’où la ligne dans le fichier. Nous n’avons pas trouvé trace de
ce type d’outil dans les sources GPL téléchargées.
Le fichier updater est un exécutable, on en profite pour
vérifier la plate-forme sur laquelle il doit s’exécuter :
Fig. 2 : On reconnaît ici le processeur Intel
et la SDRAM sur la gauche
92
% file updater
updater: ELF 32-bit MSB executable, ARM,
 GNU Linux Magazine France
NAS : passage au crible du Synology DS-101
version 1 (ARM), for GNU/Linux 2.0.0,
statically linked, stripped
Intéressons-nous maintenant à ce qui semble, d’après son
nom, être une image de RAMdisk :
% gunzip rd.gz
% mount -oro,loop rd /mnt/loop
Pas de râlement, il s’agit bien de cela. Le système de fichier ext2
est monté via le périphérique loop0. Pour en apprendre un
peu plus, commençons par vérifier notre théorie concernant
ReiserFS :
% cat /mnt/loop/etc/fstab
/dev/ram0 / ext2 defaults 1 1
none /proc proc defaults 0 0
/dev/hda3 /volume1 reiserfs defaults 0 0
La troisième partition du disque est donc bien celle censée
contenir les données de l’utilisateur. De plus, elle est effectivement
du type attendu. Seul problème, pour le système embarqué
dans le DS-101, un système de fichiers ReiserFS n’est pas la
même chose que pour une installation GNU/Linux standard.
Autre point intéressant qui risque de venir contredire
l’hypothèse du système installé sur la première partition, la
racine du système est /dev/ram0.
Normal, me direz-vous, puisqu’il s’agit d’un RAMdisk et non
d’une image initrd. On s’éloigne donc de la théorie de copie
du système sur la première partition... mais gardons-la sous
le bras tout de même.
En poursuivant plus loin l’exploration, tout en gardant dans
l’idée d’ajouter ce qui manque au système, nous pouvons
remarquer la présence de plusieurs choses.
Tout d’abord, nous avons des fichiers de configuration PPPoE
qui semblent indiquer qu’un système très proche doit être
utilisé dans un produit de partage de connexion (la carte
dans le DS-101 dispose d’un second connecteur LAN/WAN
non soudé).
D’autant plus que des scripts adsl-start ou adsl-status sont
également présents dans l’image.
Dans le /etc/rc, nous apprenons que la première partition est
également en pseudo-ReiserFS et montée en /mnt. Un fichier
configs est copié depuis là vers un répertoire /writeable
où est monté un tmpfs.
Plus intéressant que la lecture du /etc/rc, nous avons la présence
d’un lien symbolique vers un démon Telnet BusyBox.
% ls -l /mnt/loop/usr/sbin/telnetd
/mnt/loop/usr/sbin/telnetd -> ../../bin/busybox
utilisateurs par défaut du système sont admin
et guest. Serait-il possible que l’utilisateur
root soit pleinement configuré ?
% cat /mnt/loop/etc/shadow
root:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:10933:0:99999:7:::
smmsp:*:10933:0:99999:7:::
lp:*:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::
admin:$1$synergy$O31nVEgYyKUdmjDRPUq8p.:10933:0:99999:7:::
guest:$1$synergy$O31nVEgYyKUdmjDRPUq8p.:10933:0:99999:7:::
% cat /mnt/loop/etc/passwd
root:x:0:0:root:/root:/bin/ash
[...]
Par correction pour le fabricant, nous n’avons
pas souhaité imprimer la chaîne chiffrée
dans le magazine, mais sachez qu’elle est
présente dans le fichier. On en conclura
qu’avec un peu de patience et de puissance
processeur, retrouver le mot de passe n’est
qu’une affaire de temps.
On peut donc imaginer qu’un accès root sur
le serveur FTP permettrait d’avoir un accès
en lecture/écriture sur le système. Mieux
encore un shell minimal semble avoir été
prévu pour ce compte. Malheureusement,
on ne peut que le supposer puisque les
sources du serveur ne semblent pas présentes
dans l’archive mise à disposition par le
constructeur.
Sur le point de jeter l’éponge, on découvre
qu’une partie de la configuration se trouve
dans /usr/syno/etc et en particulier des
scripts d’init. La plupart semblent se baser
sur le contenu d’un fichier /etc/synoinfo.
conf, présent dans l’image RAMdisk.
Mais ce fichier est illisible et très certainement
chiffré d’une manière ou d’une autre (simple
XOR ?). Las, on jette un dernier coup d’œil à
la racine du système de fichiers et au contenu
du fichier /linuxrc.syno. Les premières lignes
nous fournissent l’information manquante
pour la quatrième partition. C’est la racine
du système :
RootDevice=/dev/hda4
MountType=»-n -t reiserfs»
% cat /mnt/loop/etc/inetd.conf
#telnet stream tcp nowait root /usr/sbin/telnetd telnetd
Malheureusement, celui-ci doit être présent à des fins de
débogage, puisque la ligne correspondante est commentée
dans la configuration du super-démon inetd. Il nous reste
le serveur FTP.
Bien entendu, celui-ci semble « chrooté » et ne permet pas
de remonter à la racine du système. Chose surprenante,
l’utilisateur root est présent dans /etc/ftpusers. Les deux
Numéro 76 / Octobre 2005
Fig. 3 : Le DiskOnChip de M-System, de plus en plus présent
dans les périphériques dits « intelligents ». Une solution
idéale pour les systèmes embarqués face aux simples
mémoires flash sans logique interne.
93
embarqué
Analyse
Plus loin dans le script qui semble être
exécuté pour l’installation du firmware, on a la
confirmation concernant le chiffrement :
# copy the crypted version to etc.
/bin/cp -f /tmp/synoinfo.conf /mnt/etc
Plus loin encore, les lignes semblent confirmer
que le disque dur est bien utilisé pour
booter :
# New created or updated root partition
[...]
# Check partitions failed, boot from ram disk
[...]
# Else part, already have root partition, boot normally.
Abandon et conclusion
La lecture de ce dernier fichier est très
intéressante, mais aussi très décevante. Il
s’avère que le DS-101 démarre effectivement
depuis un système GNU/Linux placé sur la
quatrième partition du disque et qu’il doit
donc être possible de personnaliser cette
installation.
Ce n’est qu’en cas de problème ou de disque
« vierge » que le système est, semble-t-il,
chargé de la mémoire flash et exécuté en
RAMdisk.
Mais cette information ne nous sert plus
à grand-chose. Le seul moyen de monter
et de personnaliser cette partition est de
modifier le support ReiserFS d’un système
« normal » en se basant sur les sources
modifiées fournies par Synology.
L’utilisation d’un firmware personnalisé est
une mauvaise voie puisque nous ne pouvons
calculer les sommes de contrôle sans doute
vérifiées par le système déjà embarqué. De
plus, ceci est très risqué et annulera à coup
sûr la garantie constructeur.
Mais le vrai risque n’est pas là. Un système de
fichiers standard modifié et une configuration
stockée dans un fichier chiffré, voilà le
problème.
Le DS-101 pourrait être, de par son
architecture, une petite merveille d’ouverture
comme les produits de certains autres
fabricants.
Pire encore, en tant que simple utilisateur,
on constate que les données confiées au
DS-101 sont très difficiles d’accès en cas
de défaillance dudit DS-101.
Le périphérique est vendu comme un NAS
d’entrée de gamme et une solution de
sauvegarde. Au vu des performances en
proportion avec le prix du matériel et des
protocoles utilisés, le DS-101 ne permet
94
Fig. 4 : Le boîtier DS-101 : un design très élégant et un
silence presque parfait en raison de l’absence de ventilation.
Fig. 5 : L’interface de configuration du DS-101 est simple
d’utilisation et représente la seule manière de configurer le produit.
pas de travailler directement sur les données qu’il contient.
Il est donc fait pour la sauvegarde ou le stockage.
Comment se convaincre de confier ses données à un
périphérique qui semble tout faire pour les « verrouiller » ? Il
s’agit là de quelque chose de très pénalisant pour le produit :
si votre DS-101 venait à rendre l’âme, la seule manière de
récupérer vos données serait d’acquérir un autre DS-101
ou un produit compatible (s’il existe).
Cela sera-t-il encore possible d’ici un an ? Que se passera-t-il
pour vos données placées là sans doute par souci de sécurité,
si ce n’est pas le cas ?
La durée de vie de vos données est directement liée, non
pas à celle du disque dur, mais à celle du produit et/ou du
fabricant du boîtier assurant le partage en réseau.
 GNU Linux Magazine France
NAS : passage au crible du Synology DS-101
Voulant améliorer le produit en lui ajoutant un support
NFS, nous avons pu constater ses limitations et les risques
importants découlant de son utilisation.
Un travail qui s’est avéré long, mais finalement payant. Le
produit est retourné chez son distributeur...
L’avis du fabricant
Nous n’avons pas manqué de demander au constructeur du
DS-101 la raison pour laquelle un système de fichiers ReiserFS
a été utilisé. La réponse fut rapide et parfaitement claire.
C’est un point qu’il est important de relever, beaucoup de
fabricants nous auraient sans doute demandé si le firewall
de Windows XP est activé et si les voyants du boîtier sont
allumés ou clignotent avant même de comprendre notre
demande.
La très étonnante raison avancée par Synology concerne la
confidentialité des données que l’utilisateur place dans le DS101. Grâce à l’utilisation d’un ReiserFS modifié, l’utilisateur
2
n’a pas à s’inquiéter de la protection de ses
fichiers en cas de vol du périphérique.
Victor Chiang de Synology ajoute cependant
que la société projette d’ajouter un support
Ext3 dans le DS via une mise à jour du
firmware.
Je vous laisse juge de cette explication
en notant toutefois qu’elle a le mérite de
mettre l’accent sur un élément important
concernant les disques « transportables »
quel qu’ils soient : on peut les voler très
facilement.
Pensez donc à chiffrer les données sensibles
et/ou privées qu’ils contiennent.
Denis Bodor,
sites
incontournables
/
p
t
/
:
Toute l’actualité du magazine sur :
t
www.gnulinuxmag.com
H w
www.ed-diamond.com
w
Abonnements et anciens numéros en vente sur :
w