IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 Firebird Discussion :

Sécuriser les Métadata IB en utilisation mono ?


Sujet :

Firebird

  1. #1
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut Sécuriser les Métadata IB en utilisation mono ?
    Bonjour à tous

    Nouveau venu dans le monde d'InterBase, je me pose des questions concernant la sécurité d'accès aux données de ce gestionnaire. En effet, j'ai cru comprendre que n'importe qui "récupérant" un fichier GDB pouvait accèder aux données (et à la structure de la BDD) à partir du moment où il dispose des droits d'admnistration sur une machine exécutant un serveur IB. Existe t'il des solutions ? Comment protéger ses données ?
    Merci de vos infos/avis sur cette question.

  2. #2
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    D'où sort tu cette information ??
    et quel est la manipulation qui permettrait de le faire ?
    Moi quand j'essaye de me connecter sur la base il me réclame un mot de passe et ce même si je suis sur le serveur et que j'ai les droits administrateurs windows...

  3. #3
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut Interbase et Sécurité
    Je m'explique....
    Admettons que je t'envoie un fichier GDB où j'ai défini des utilisateurs avec des mots de passe, des privilèges, etc... Malgré cela, sachant que tu es administrateur Interbase sur ta machine, en recopiant le GDB en local et en te connectant en local avec ton SYSDBA, tu devrais pouvoir ouvrir ma base de données... sans connaître aucun des user/password que j'ai défini...
    Ma question était donc de savoir si ceci est évitable ? En d'autres termes, comment gérer la sécurité ?

    Merci d'avance !

  4. #4
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    Oui je crois que tu as raison mais c'est à essayer....

    Mais bon celà limite quand meme il faut connaitre le mot de passe du SYSDBA (tu peux le changer) mais il me semble qu'il est stocké dans la base ISC4.GDB.

    Mais si tu créé une base comme ca :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CREATE DATABASE "mabase.gdb" USER "ADMINDB" PASSWORD "database";
    qu'est ce que ca fait ? Il me semble que ADMINDB devient le propriétaire de la base mais je ne sais pas si SYSDBA a quand meme des droits dessus.

    C'est un sujet interessant... A creuser

  5. #5
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Tu n'as pas à connaitre MON password de SYSDBA, puisque tu vas te connecter avec le tien... et que tu le connais, à priori !
    Concernant les droits du SYSDBA, voilà ce que j'ai trouvé : "The SYSDBA user always assumes total control over a database. SYSDBA is the superuser, there is no way to deny access from the SYSDBA user. The GRANT and REVOKE statements have no effect on the SYSDBA user."
    Alors.... comment peut-on éviter de se faire "pirater" sa BDD? IB7 apporte t'il des améliorations à ce sujet ??

    Merci d'avance

  6. #6
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Il n'y à aucun probleme de sécurité avec interbase, et d'ailleurs interbase est utilisé par l'armée américaine et différentes bourses et salles de marché et banques dans le monde.

    Je t'invite à commencer par lire la doc sur ce sujet, que tu trouvera ici :

    http://sgbd.developpez.com/cours/#interbase
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  7. #7
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    Ce que je vois dans la documentation ftp://212.73.230.16/borland/doc/inte...ide_FR_pdf.zip dans les pages 85 concerne la sécurité en effet et précise que SYSDBA a tous les droits et qu'il est préférable de changer son mot de passe dès l'installation terminée.

    Mais il est marqué également que si l'on supprime le SYSDBA on ne peux plus ajouter et modifier la liste des utilisateur et qu'il faut réinstaller InterBase pour restaurer la base de données de sécurité isc4.gdb.

    Ce qui appuit les dires d' ADN75018, une personne copiant une base de donnée pourra facilement accéder à sa structure en la copiant sur son poste en y installant Interbase (du coup le mot de passe de SYSDBA est masterkey).

    Donc je dirais que une des solutions serait de proteger le fichier de la base (le .gdb).
    Mais ce n'est pas toujours possible : exemple une personne ayant développé un logiciel qu'il commercialise. Il suffirait que la personne l'ayant acheté installe Interbase pour avoir accés aux sources (structures des tables, procédures stoquées) et n'a plus qu'à le plagier pour pouvoir le vendre à son tour (oui je sais il faut développé également la partie cliente mais bon l'analyse des données est une partie tres importante d'un développement qui mériterait de pouvoir être protégé...)

    Donc voilà la question reste entière : quel est le moyen de proteger efficacement sa base en cas de copie du .gdb ?? S'il n'y a pas de moyen, pour la version 6 d'interbase, la Version 7 a t'elle palié à ce problème ?

  8. #8
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Cher Epictète

    Je te remercie de me confirmer ce que je savais déjà, à savoir que je connais peu ou pas InterBase. C'est même d'ailleurs pour cela que je consulte ce forum....
    J'ai lu attentivement la documentation à laquelle tu fais référence, et notamment le chapitre 6 - Sécurité des Bases de Données. Les thèmes abordés sont certes intéressants, mais ils ne me semblent pas répondre à ma question.... il n'est en effet question que d'un fonctionnement C/S pour lequel InterBase me semble parfaitement sécurisé.
    Ma question est de savoir comment empêcher quelqu'un ayant copié un fichier GDB sur son PC, de faire une connexion (Login / Local Engine) en tant que SYSDBA sur sa machine, et donc d'avoir accès à l'ensemble de la BDD. Pour moi, ce n'est pas un gros délire sans intérêt que d'essayer de comprendre comment protéger ses informations...

    Merci d'avance

  9. #9
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Citation Envoyé par ADN75018
    Cher Epictète

    Ma question est de savoir comment empêcher quelqu'un ayant copié un fichier GDB sur son PC, de faire une connexion (Login / Local Engine) en tant que SYSDBA sur sa machine, et donc d'avoir accès à l'ensemble de la BDD.
    S'il n'est pas le sysdba, avec le nouveau password, et qu'il n'à pas les droits il ne peux pas accèder au gdb.
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  10. #10
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Citation Envoyé par Barbibulle
    Ce qui appuit les dires d' ADN75018, une personne copiant une base de donnée pourra facilement accéder à sa structure en la copiant sur son poste en y installant Interbase (du coup le mot de passe de SYSDBA est masterkey).
    Pas du tout. si tu reprends un gdb, c'est un autre sysdba, celui qui à été défini.
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  11. #11
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Ca, je l'avais bien compris. Je doit mal m'exprimer, je vais essayer d'illustrer mon propos.
    Admettons que je récupère (peu importe ici le moyen) le fichier PAYE.GDB de mon entreprise (qui est super-protégé par un DBA hyper compétent, et tout, et tout). Le soir, chez moi, je recopie ce fichier sur ma machine où je suis bien sûr administrateur IB (c'est ma machine, j'ai mon compte SYSDBA, etc...). Et bien là, je peux me connecter sur le GDB et voir combien touche mon patron, non ????
    C'est cela que je voudrais éviter !

  12. #12
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    Je crois que tu n'as pas compris le problème soulevé par ADN75018.

    Le password et la liste des users n'est pas dans le .gdb mais dans le isc4.gdb du poste... Donc toi sur ton serveur tu peux bien mettre le password que tu veux pour le SYSDBA si quelqu'un copie le fichier Mabase.Gdb pour la mettre chez lui. et installe interbase (donc nouveau fichier isc4.gdb avec un mot de passe pour le SYSDBA égale à masterkey)

    Voilà le travail.

  13. #13
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Citation Envoyé par Barbibulle
    Le password et la liste des users n'est pas dans le .gdb mais dans le isc4.gdb du poste... Donc toi sur ton serveur tu peux bien mettre le password que tu veux pour le SYSDBA si quelqu'un copie le fichier Mabase.Gdb pour la mettre chez lui. et installe interbase (donc nouveau fichier isc4.gdb avec un mot de passe pour le SYSDBA égale à masterkey)

    Voilà le travail.
    Ca marchera pas parce qu'il vérifie. Il faut que cela soit cohérent.
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  14. #14
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Si je me suis permis d'évoquer ce problème c'est parce que j'ai justement fait cette manip et qu'elle a très bien marchée.... Alors, il y a certainement une configuration/propriété du fichier GDB qui permet d'éviter cela, je n'en doute pas. Ce que j'aimerais connaître, c'est ce qu'il faut faire pour l'éviter...
    Merci d'avance

  15. #15
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Si tu fait cela tu peux voir les metadata mais pas les datas normalement.
    pour protéger les metadata voila le tip :

    start ibconsole, log in as sysdba and create a new user,
    let's say 'test', password 'xxx'.

    Leave ibConsole, start ibconsole again and log in as test / xxx
    (the new user you created)

    Then create your database (so TEST is the owner!) and open it
    now do this sql-command:
    "insert into rdb$roles values ( 'SYSDBA', 'TEST' )
    ... now sysdba is a role for your database and not longer a user.
    so if you try to connect to your db using sysdba you will fail!
    (can only be removed from TEST by "drop role ..".)
    Un autre :


    Security is a slippery slope, one where you have to balance return on
    investment with paranoia.

    Many developers will design a database system, implement it, then try to
    secure it. I will begin by saying that this is the most flawed approach you
    can have. When you design a system with security in mind, you approach every
    step in the process differently.

    So, the first question is, how do I begin ?

    Well, connect to your database server as SYSDBA and create a new user
    'DEVELOPER' (you can use your own name but for example purposes, developer
    will be fine).

    Now, connect to the isc4.gdb file with ISQL or some other interactive tool
    and grant full security access to 'DEVELOPER'.

    Now, disconnect from the server and reconnect as 'DEVELOPER'.
    From this point on, never, ever, ever, connect as SYSDBA unless you absolutly
    have to.

    Next step, as DEVELOPER, create your database and create three roles

    IB_DESIGNER
    IB_BACKUP
    IB_OPERATOR

    Now, create a table we will refer to as 'IB_USERS' although the name you use
    will not be that.
    We also need two other tables refered to as 'IB_GROUPS' and 'IB_RIGHTS'
    respectively.
    Together, these three tables will be the backbone for your security system,
    they are beginning of a secure database.

    Now, create a series of custom exceptions
    for example
    'CONNECTION FROM UNAUTHORISED PC'
    'CONNECTION FROM UNAUTHORISED CLIENT'
    'CONNECTION OUTSIDE OF AUTHORISED HOURS'
    etc
    You can create as many as you can think of.

    The concept being, when someone does somthing against the security rules you
    setup, an exception is raised, and the current work gets rolled back,
    regardless of the client being used. You can get away with a single
    exception, but, when it comes down to support and debugging issues, the more
    differentiation, the better.

    Ok, you have some tables, some exceptions, some roles, what now?

    Well, now you need to make sure that only proper users can modify the
    database. This includes SYSDBA. You see, once you create a GDB, and you add
    a user to the system, that user, who may or may not have any rights to any of
    your system tables, that user can create thier own procedures and tables
    etc., that can cause problems with your nicely laid out system.

    We start this process by creating a stored procedure that for reference, we
    will call PRC$SEC_PERMCHECK() and we pass it a unique number that identifies
    the item and action we are now doing, more on this later.
    PRC$SEC_PERMCHECK() is called by triggers placed on every table in the
    database, including system tables. Each of these triggers is given a unique
    number that is sent to the procedure when it is called. The stored procedure
    can get the current time and current user from the global variables that IB
    provides. By cross referencing the user and the unique trigger identifier in
    the security tables, you can find out whether you should raise an exception
    or not. So, after creating a trigger on the system tables, that calls this
    procedure, if any user, including SYSDBA, attempts to create, modify or
    delete, any metadata, an exception will be raised, unless that user is
    specifically put into the security tables.

    But, how do we prevent SYSDBA from reading all of our private
    procedure/trigger language source code? We update the system tables,
    replacing the source code (not the BLR code) with a blob the only containes
    three spaces. The reason we use three spaces instead of a null is because of
    a known bug that sometimes will cause a trigger to fire twice if the source
    is deleted.

    Ok, we have now set it up so that SYSDBA cannot modify the tables, but we
    want to make sure they can not even connect, so we create a role called
    SYSDBA by directly inserting values into the system tables.

    Sysdba now can not even connect to our database. Users who can extract
    metadata cannot see the source of the triggers/procedures.

    Ok, but how do you prevent a authorised user from connecting to the database
    using some tool other than the programs you are providing?

    First you never give your users thier real login names or passwords.

    Your program goes through a series of steps when loging onto the database.

    It prompts the user for a username and password.
    It connects to the database as the 'SEC_LOGIN' user.
    The SEC_LOGIN user only has the right to run the 'PRC$SEC_LOGINIB_USERS()'
    procedure.
    The PRC$SEC_LOGIN() procedure is passed the ip_address of the calling
    machine, the user supplied username and the user supplied password.
    It then looks up the appropriate information from the IB_USERS table and
    calls a UDF that adds a new user to the system with a random user name and
    password. The stored procedure grants the appropriate rights to the newly
    created user via directly inserting values into the system tables.
    The stored procedure then returns to the calling application the real
    (random) user name and password, as well as the role for the user to use.

    This means that every time the user logs in, they are logging in via a
    different user name and password. This means that all triggers and
    procedures that rely upon the USER variable, will need to resolve the real
    user name from the random name that is returned.
    The PRC$SEC_PERMCHECK() that is called for every insert/update/delete checks
    to see if the login time has expired for the user and calls a UDF that cleans
    up the isc4.gdb and removes the random name from the database (and any other
    random users who have not logged out properly).

    As each user gets a unique name, even if they think they are logging in with
    the same login name. This gives you a unique identifier for this login and
    helps with logging and replication.

    Since the users inside the system are constantly changing, no other
    application except for yours will know how to connect to your database.

    You can move the GDB around from machine to machine and still be assured some
    security.

    On top of the above security measures, you do not give your tables intuitive
    names, nor do you make your stored procedures, thier names or thier
    parameters should always be kept secret. Any knowledge of your database
    structure is a direct tool for cracking your security.

    This is a beginning 10000' overview on securing your database.

    I am sure I have prompted more questions than I have given answers, so feel
    free to ask.
    Voir aussi :
    http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm

    Mais pour finir c'est pas spécialement un probleme lié à interbase, tu aura des problemes similaires globalement avec tous les sgbd que tu veux utiliser en stand alone.

    En client/Serveur pas de probleme, c'est vrai qu'il y à une différence entre les 2 utilisations.

    Pour finir refaites le test avec la version d'éval InterBase 7, je me demande ce que borland veux dire avec metadata sécurité, si c'est pas ce sujet justement.

    Voir sur InterBase 7 :
    http://www.borland.com/interbase/pdf/ib7_feaben.pdf


    PS : pour ceux qui se servent de la version <= 6.01 open source, ne pas oublier le patch sécurité : http://info.borland.com/devsupport/interbase/security_patches.html
    Ce patch n'est pas nécessaire pour les versions Borland certifiées 6.5 et 7
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  16. #16
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Je te remercie pour ces conseils éclairés.

  17. #17
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    Et en effet j'ai lu que une des améliorations de la version 7 concernait la protection des méta-data.... Ce qui veux bien dire qu'il y a un problème avec la version 6.01 open source...

  18. #18
    Membre averti Avatar de Epictète
    Inscrit en
    mars 2002
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Je te signale que la question initiale ne précise pas la version d'interbase, open source ou certifiée.

    Je ne te donne pas tord , mais je trouve qu'il y à une énorme différence entre :

    - sujet initial : "sécurité et interbase" (probleme pas clair, version interbase pas précisé)

    et le

    - nouveau sujet édité :"protéger (la lecture) les métatada dans le cas d'une utilisation mono poste (et avec interbase open source 6).

    C'est quand meme pas tout à fait le meme sujet, c'est plus spécialisé disons....

    Donc on en revien aux regles du forum :
    http://www.developpez.net/forums/viewtopic.php?t=334

    C'est plus efficace de donner le max de précisions dès le départ dans la question inituale, et au minimum la version d'interbase utilisée. ...
    -> Consultez les cours et tutoriels
    -> Consultez la F.A.Q du forum que vous utilisez
    -> Lisez les règles du forum

  19. #19
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    2 043
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 2 043
    Points : 3 328
    Points
    3 328
    Par défaut
    Je te l'accorde... ceci dit ce n'est pas mon sujet....
    et j'ai fait la même erreur que toi c'est a dire de ne pas demander la version d'interbase qu'il utilise... et j'ai supposé qu'il parlait de la même version que la mienne.... (Que j'ai précisé dans mes messages puisque je parle d'interbase 6 et demande si la version 7 résoud ce problème....)

  20. #20
    Candidat au Club
    Profil pro
    Inscrit en
    janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 12
    Points : 4
    Points
    4
    Par défaut
    Je ne sais pas d'où il sort que j'utilise IB OpenSource??? En l'occurence le "problème" évoqué a été reproduit sur IB version 5.5 et 6.5.
    De plus, je confirme que les metadata ET les données sont accessibles selon la manip évoquée....
    Et pour répondre à Epictète qui dit
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    tu aura des problemes similaires globalement avec tous les sgbd que tu veux utiliser en stand alone
    ,je ne pense pas qu'il existe de problème similaire avec MySQL par exemple (attention : je ne compare pas..... c'est juste pour l'exemple !)
    Sinon, et pour info, la manip avec le "insert into rdb$roles values ( 'SYSDBA', 'TEST' )' à l'air de bien résoudre le problème.
    Donc merci pour les infos

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Important : Les règles incontournables d'utilisation de ce forum
    Par Community Management dans le forum Général Conception Web
    Réponses: 0
    Dernier message: 20/05/2009, 11h36
  2. [C#] Questions sur les webmethodes et leur utilisation
    Par NoiBe dans le forum Services Web
    Réponses: 10
    Dernier message: 14/12/2006, 09h40
  3. Réponses: 3
    Dernier message: 28/11/2006, 13h58
  4. [Sécurité] sécuriser les données d'un site
    Par lodan dans le forum Langage
    Réponses: 10
    Dernier message: 20/07/2006, 13h26
  5. [FB1.5] Sécuriser les transmissions
    Par nycolas dans le forum Outils
    Réponses: 6
    Dernier message: 29/11/2005, 12h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo