Bitmessage/Soucis : Différence entre versions

Version du 16 février 2018 à 09:36

Attaque du 13/02/2018

Semblait surtout viser les machines windows. Néanmoins, ça révèle d'assez grosses failles dans le code, et des précautions assez classiques qui n'ont pas été prises.

Ce sont un ou des portefeuilles cryptos qui étaient visés.

Certains suspectent même des zerodays volontairement introduites par les devs ... ça craint.

Correctifs / précautions :

• firejail,
• archivage quotidien par cron,
• noyer ce qui compte dans des centaines de GB de fake data
• torchat

NB : Ma machine remote, sous Debian, ne montre aucune trace d'attaque. C'est une illustration de l'intérêt de faire tourner ces programmes/noeuds de manière cloisonnée, sur des machines qui ne font que ça, et où il n'y a rien d'autre.

Communauté

... c'est un peu le bronx. :-(

Scalabilité

Si je comprends bien, la prise en compte de ce souci devrait être gérée par les streams. La GUI 2018 affiche déjà le stream 1, et a priori il n'y a pas encore de stream 2, donc on ne sait pas vraiment si l'implémentation actuelle fonctionnerait réellement.

Forward du port 8444

• a yellow light would mean that you only have outgoing connections, but no incoming.
  • ce qui signifie aussi que BM fonctionne uniquement en mode client, ie n'est de facto pas un noeud

• you may have to configure port-forwarding on your router, to forward port 8444 from wan to port 8444 on the computer running the bitmessage-client.

• voir Ouverture de port

• J'ai paramétré le routeur censément comme il faut pour le port 8444 (et uniquement celui-là), http://www.portchecktool.com/ me dit cependant :
  • Problem! I could not see your service on monip on port (8444). Reason: Connection timed out.
  • Problem! I could not see your service on monip on port (8555). Reason: Connection timed out.
  • a priori, cela semble signifier que le paramétrage du routeur pour le port 8444 est sans effet ?

• http://ping.eu/port-chk/ plus précis, me dit que 8444, 8445 sont closed
  • voir aussi les autres outils, dont http://ping.eu/traceroute/ qui dit atteindre un firewall avant de toucher mon IP

cela expliquerait peut-être aussi :

• pourquoi, quasi systématiquement, le nombre de connexions BM monte au lancement ... puis décroit doucement jusqu'à 0, alors même que le fichier knownnodes.dat ne cesse de grossir.
• les soucis analogues avec transmission/bitorrent

• bref -> voir : VPS ou autres soluces en remote

• à noter que, après avoir réalisé le forward du port 8444 sur le routeur, cela n'apparaît pas sur le RPI avec netstat -a. Je dois lancer le service (ie python bitmessagemain.py) pour que les lignes suivantes apparaissent :

# netstat -a | grep 8444
tcp        0      0 0.0.0.0:8444            0.0.0.0:*               LISTEN     
...
udp        0      0 0.0.0.0:8444            0.0.0.0:*                          

... de fait, c'est le lancement de BM qui provoque l'affichage de ces lignes, et lui seul.

• est-ce que les ports sont fermés par défaut sur raspberry ?
  • j'ai lu qq part que Debian/raspbian ferme par défaut les ports < 1000.

• si oui, comment ?
• Vous pouvez vous servir de gufw pour configurer vos ports (transmission). https://packages.debian.org/fr/stretch/gufw gufw pourrait-il être utile ?

• https://doc.ubuntu-fr.org/iptables
  • semble dire qu'il faut encore maniper sur le raspberry pour autoriser le trafic

• uPnP coché ou pas, ça ne change rien
• lancer bitmessagemain.py en su ne change rien
• même passer, via les paramètres du routeur, l'adresse IP du raspberry concerné en DMZ (https://fr.wikipedia.org/wiki/Zone_d%C3%A9militaris%C3%A9e_(informatique)), ne change rien
• https://bitmessage.org/forum/index.php?topic=3658.msg7636#msg7636 suggère de vider et/ou recopier knownnodes.dat
• de facto, toute manip en aval d'un robinet fermé est forcément sans effet sur l'écoulement de l'eau

Fausse piste :

• a priori, IP fixe ou dynamique, BM s'en fout
• a priori, avant de vouloir faire du port forwarding, il faudrait (à vérifier ?) déjà que la machine concernée ait une adresse IP fixe, et a priori ce n'est pas le cas
• https://raspberrypi.stackexchange.com/questions/37920/how-do-i-set-up-networking-wifi-static-ip-address/74428#74428
• https://www.modmypi.com/blog/how-to-give-your-raspberry-pi-a-static-ip-address-update
• https://thepihut.com/blogs/raspberry-pi-tutorials/16683276-how-to-setup-a-static-ip-address-on-your-raspberry-pi

Mode portable

Je fais tourner BM sur clé USB. Et j'ai bien coché le mode portable dans les paramètres. Tous les fichiers de travail vont bien dans /PyBitmessage/src, sauf pybitmessage.conf qui persiste à rester dans ~/.config/pybitmessage

Messages au lancement

• Gtk-Message: Failed to load module "canberra-gtk-module"
  • dans mon cas libcanberra-gtk3-module est installé, mais pas libcanberra-gtk-module
  • a priori, il faut donc installer libcanberra-gtk-module soit via apt-get install soit via synaptic
  • NB : c'est un petit paquet

IPs en clair dans le code source

• il y a des IPs en clair dans le code source, dans src/defaultKnownNodes.py. a priori il s'agirait des noeuds de bootstrap. Un attaquant du réseau Bitmessage pourrait cibler ces IPs (attaque DoS ou autre).
• NB : Les IPs 2017 ne sont pas les mêmes qu'en 2013.
• on ne peut pas exclure que (certaines de) ces IPs soient des honey pots ? Et/ou des canaris.
• Il faut noter que ces noeuds de bootstrap ne servent normalement qu'une seule fois, lors du 1° lancement de bitmessage. Dès ce 1° lancement, un fichier knownnodes.dat est créé et copieusement garni, et c'est lui qui fournira des noeuds. Ce fichier peut aussi s'échanger entre mainteneurs.

• https://bitmessage.org/forum/index.php?topic=3884.msg8149#msg8149

There are three mechanisms Bitmessage uses to learn of nodes.

1. about 10 are hardcoded. These are only used when you run the client the first time or when you delete your knownNodes.dat file.

2. DNS bootstrapping. On startup, Bitmessage looks up the DNS A-records for bootstrap8080.bitmessage.org and bootstrap8444.bitmessage.org and adds those to its list. This is very much like method #1 except that I don't have to update the source code to update the list of peers.

3. After the client is connected to another peer, peers share nodes using addr messages. This is continuously updated. At this point the first two methods really aren't important at all; the knownNodes list will grow plenty big using this third method. (Max 20K peers in the list).

If your client doesn't hear that a peer is active and cannot connect to it for two days then it removes it from the list until you have less than 1000 peers in your list at which point it stops removing them.

Pages connexes

• Bitmessage/Contribute