Le Bitcoin en cage ?

Il se trouve que je suis administrateur de systèmes et de réseaux informatiques (en abrégé : sysadmin), et j'ai eu l'opportunité de travailler pendant un peu plus de 10 ans dans diverses systèmes, y compris ceux nécessitant des mesures de sécurité [po|za]vyschennykh. Et aussi, il s'est avéré qu'il y a quelque temps, j'ai trouvé intéressant bitcoin, et je n'ai pas seulement utilisé cette technologie, mais j'ai également lancé plusieurs microservices afin d'apprendre à travailler moi-même avec le réseau Bitcoin (qui est en fait p2p) du point de vue d'un développeur (je suis bien sûr un développeur modeste dev, juste un passant). Mais je ne parle pas de développement, je parle d'un environnement sûr et efficace pour les applications.

Les technologies financières (fintech) vont de pair avec la sécurité de l'information (infosec), et l'un ne peut pas vraiment fonctionner sans l'autre, mais pas pour longtemps. C'est pourquoi je souhaite partager mon expérience et une série d'outils que j'utilise, qui incluent à la fois fintech, et via infosec, et qui peuvent également être utilisés dans un but plus large ou complètement différent. Dans cet article, je ne parlerai pas tant de Bitcoin que du modèle d'infrastructure pour le développement et l'exploitation de services financiers (et pas seulement) — en d'autres termes, des services où le « B » a de l'importance. Cela s'applique aussi bien à une bourse de Bitcoin qu'à un typique zoo corporate de services d'une petite entreprise non liée au Bitcoin.

Je tiens à souligner que je soutiens les principes de « keep it stupid simple » et « less is more », donc l'article ainsi que ce qui y est décrit auront les caractéristiques de ces principes.

Scénario imaginaire : Prenons l'exemple d'un échange de bitcoins. Nous avons décidé de lancer un échange de roubles, dollars, euros contre des bitcoins et vice versa, et nous avons déjà une solution opérationnelle, mais pour d'autres monnaies numériques comme Qiwi et WebMoney, c'est-à-dire que toutes les questions juridiques sont réglées, nous avons une application prête qui fait office de passerelle de paiement pour les roubles, dollars et euros ainsi que pour d'autres systèmes de paiement. Elle est liée à nos comptes bancaires et dispose d'une API pour nos applications finales. Nous avons également une application web qui sert d'échange pour les utilisateurs, semblable à un cabinet typique de Qiwi ou WebMoney — créez un compte, ajoutez une carte, etc. Elle communique avec notre application passerelle, via REST API en local. Nous avons donc décidé d'intégrer les bitcoins et de mettre à niveau l'infrastructure, car initialement tout a été rapidement mis en place sur des VirtualBox dans le bureau sous la table… le site est utilisé, et nous nous soucions maintenant de la disponibilité et des performances.

Alors, commençons par l'essentiel — le choix du serveur. Puisque l'entreprise dans notre exemple est petite et que nous faisons confiance à notre hébergeur (OVH), nous allons choisir une option économique qui ne permet pas d'installer le système à partir d'une image originale .iso, mais ce n'est pas grave, le département de la sécurité informatique effectuera nécessairement une analyse de l'image installée. Et lorsque nous grandirons, nous louerons même notre propre armoire sous clé avec un accès physique limité, ou peut-être construirons-nous notre propre centre de données. Dans tous les cas, il est important de se rappeler que lors de la location de matériel et de l'installation d'images prêtes à l'emploi, il y a une possibilité que votre système contienne un « cheval de Troie de l'hébergeur », qui dans la plupart des cas est destiné non pas à vous surveiller, mais à vous proposer des outils de gestion de serveur plus pratiques.

Installation du serveur

Ici, c'est simple. Nous choisissons le matériel qui convient à nos besoins. Ensuite, nous choisissons une image FreeBSD. Ou bien nous nous connectons (dans le cas d'un autre hébergeur ou de notre propre matériel) via IPMI ou avec un moniteur et nous lançons l'image .iso de FreeBSD. Pour l'installation orchestrée, j'utilise Ansible et mfsbsd. La seule chose, dans notre cas avec Kimsufi, nous avons choisi l'installation personnalisée afin que les deux disques en miroir aient « ouverts » uniquement les partitions de démarrage et /home, le reste de l'espace disque sera chiffré, mais nous en reparlerons plus tard.

L'installation du système se fait de manière standard, je ne vais pas m'attarder là-dessus, je tiens juste à souligner qu'avant de commencer à l'utiliser, il vaut mieux prêter attention à le renforcement des options proposées par bsdinstaller à la fin de l'installation (si vous installez vous-même le système) :

Oui un bon matériel sur ce sujet, que je vais résumer brièvement ici.

Il est également possible d'activer les paramètres mentionnés ci-dessus sur un système déjà installé. Pour ce faire, il faut modifier le fichier de démarrage et activer les paramètres du noyau. *ee est un éditeur dans BSD

# ee /etc/rc.conf

...
#sec hard
clear_tmp_enable="YES"
syslogd_flags="-ss"    
sendmail_enable="NONE"

# ee /etc/sysctl.conf

...
#sec hard
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 9999)
security.bsd.stack_guard_page=1

Il est également important de s'assurer que vous disposez de la dernière version du système et d'effectuer toutes les mises à jour et upgrades. Dans notre cas, par exemple, une mise à jour vers la dernière version est nécessaire, car les images préinstallées ont du retard de six mois à un an. Et là, nous changeons le port SSH pour un autre que par défaut, ajoutons l'authentification par clés et désactivons l'accès par mot de passe.

Ensuite, nous configurons aide, la surveillance de l'état des fichiers de configuration du système. On peut lire plus en détail ici.

pkg install aide

et nous modifions notre crontab

crontab -e

06 01 * * 0-6 /root/chkaide.sh

#! /bin/sh
#chkaide.sh
MYDATE=`date +%Y-%m-%d`
MYFILENAME="Aide-"$MYDATE.txt
/bin/echo "Aide check !! `date`" > /tmp/$MYFILENAME
/usr/local/bin/aide --check > /tmp/myAide.txt
/bin/cat /tmp/myAide.txt|/usr/bin/grep -v failed >> /tmp/$MYFILENAME
/bin/echo "**************************************" >> /tmp/$MYFILENAME
/usr/bin/tail -20 /tmp/myAide.txt >> /tmp/$MYFILENAME
/bin/echo "****************DONE******************" >> /tmp/$MYFILENAME

Nous activons audit système

sysrc auditd_enable=YES

# service auditd start

La manière d'administrer cela est très bien décrite dans guide.

Maintenant, nous redémarrons et commençons avec le logiciel sur le serveur. Chaque serveur est comme un hyperviseur pour des conteneurs ou des machines virtuelles complètes. Il est donc important que le processeur prenne en charge VT-x et EPT si nous prévoyons d'utiliser la virtualisation complète.

Pour la gestion des conteneurs et des machines virtuelles, j'utilise cbsd à partir de olevole, je souhaite à cet excellent utilitaire beaucoup de santé et de bienfaits !

Des conteneurs ? Encore docker ?

Eh bien non. FreeBSD Jails est un excellent outil pour la conteneurisation, et le mentionné cbsd est pour l'orchestration de ces conteneurs, qui s'appelle des cellules.

La cage est une solution extrêmement efficace pour construire une infrastructure pour divers objectifs, où à la fin une isolation totale des services ou processus individuels est requise. En essence, c'est un clone du système hôte, mais il ne nécessite pas de virtualisation complète du matériel. Ainsi, les ressources ne sont pas gaspillées sur un « système d'exploitation invité », mais uniquement sur le travail exécuté. Lorsque les cages sont utilisées pour des besoins internes, c'est une solution très pratique pour une utilisation optimale des ressources — plusieurs cages sur un même serveur physique peuvent chacune utiliser l'ensemble des ressources du serveur si nécessaire. Étant donné que différents sous-services ont souvent besoin de ressources supplémentaires à différents moments, il est possible d’extraire la performance maximale d’un serveur s’il est correctement planifié et équilibré entre les serveurs. En cas de besoin, des limites peuvent également être imposées aux ressources utilisées par les cages.

Et qu'en est-il de la virtualisation complète ?

À ma connaissance, cbsd supporte le fonctionnement des bhyve et des hyperviseurs XEN. Je n'ai jamais utilisé le second, mais le premier est un hyperviseur relativement jeune de FreeBSD. Nous examinerons un exemple d'utilisation bhyve dans l'exemple suivant.

Installation et configuration de l'environnement hôte

Nous utilisons le système de fichiers ZFS. C'est un outil extrêmement puissant pour gérer l'espace sur le serveur. Grâce à ZFS, il est possible de créer directement à partir de disques des ensembles de diverses configurations, d'augmenter l'espace de manière dynamique « à chaud », de remplacer des disques défectueux, de gérer des instantanés et bien d'autres choses que l'on pourrait décrire dans toute une série d'articles. Revenons à notre serveur et à ses disques. Au début de l'installation sur les disques, nous avons laissé de l'espace libre pour les partitions chiffrées. Pourquoi cela ? C'est pour que le système se lance automatiquement et écoute via SSH.

gpart add -t freebsd-zfs /dev/ada0

/dev/ada0p4 added!

ajoutons une partition de disque dans l'espace restant

geli init /dev/ada0p4

entrons notre mot de passe de chiffrement

geli attach /dev/ada0p4

nous saisissons à nouveau le mot de passe et nous obtenons le device /dev/ada0p4.eli — c'est notre espace chiffré. Ensuite, nous répétons la même opération pour /dev/ada1 et pour les autres disques dans l'ensemble. Et créons un nouveau pool ZFS.

zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — voilà, nous avons un ensemble minimal opérationnel prêt. Un ensemble de disques en miroir au cas où l'un des trois tomberait en panne.

Créons un dataset sur un nouveau « pool »

zfs create vms/jails

pkg install cbsd — nous avons lancé la commande et installons le gestionnaire pour nos cellules.

Après que cbsd soit installé, il faut l'initialiser :

# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv

et nous répondons à une multitude de questions, principalement avec des réponses par défaut.

*Si vous utilisez le chiffrement, il est important que le démon cbsdd ne démarre pas automatiquement tant que vous n'avez pas déchiffré les disques manuellement ou automatiquement (dans notre exemple, c'est fait par zabbix)

**Je n'utilise également pas de NAT de cbsd, mais je le configure moi-même dans pf.

# sysrc pf_enable=YES

# ee /etc/pf.conf

IF_PUBLIC="em0"
IP_PUBLIC="1.23.34.56"
JAIL_IP_POOL="192.168.0.0/24"

#WHITE_CL="{ 127.0.0.1 }"

icmp_types="echoreq"

set limit { states 20000, frags 20000, src-nodes 20000 }
set skip on lo0
scrub in all

#NAT pour les cellules
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

## Redirection de port pour le réseau Bitcoin
IP_JAIL="192.168.0.1"
PORT_JAIL="{8333}"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

# service pf start

# pfctl -f /etc/pf.conf

La configuration des politiques de pare-feu est également un sujet à part, donc je ne vais pas approfondir la configuration de la politique BLOCK ALL et les réglages des listes blanches, cela peut être fait en consultant la documentation officielle ou n'importe lequel des nombreux articles disponibles sur Google.

Eh bien… nous avons installé cbsd, il est temps de créer notre premier cheval de travail — le démon Bitcoin dans une cellule !

cbsd jconstruct-tui

Ici, nous voyons le dialogue de création de cellule. Une fois que toutes les valeurs sont définies, créons !

Lors de la création de la première cellule, il convient de choisir ce que l'on utilise comme base pour les cellules. Je choisis la distribution du référentiel FreeBSD avec la commande repo. Ce choix est effectué uniquement lors de la création de la première cellule d'une version spécifique (il est possible d'héberger des cellules de n'importe quelle version supérieure à celle de l'hôte).

Une fois tout installé, lançons la cellule !

# cbsd jstart bitcoind

Mais nous devons installer le logiciel dans la cellule.

# jls

   JID  IP Address      Hostname                      Path
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind

jexec bitcoind pour accéder à la console de la cellule

et déjà à l'intérieur de la cellule, nous installons le logiciel avec ses dépendances (notre système hôte reste propre)

bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils

bitcoind:/@[15:30] # sysrc bitcoind_enable=YES

bitcoind:/@[15:30] # service bitcoind start

Bitcoin dans la cellule est là, mais nous avons besoin d'anonymat, car nous voulons nous connecter à certaines cellules via le réseau TOR. Et en général, nous prévoyons de faire tourner la plupart des cellules avec des logiciels suspects uniquement via un proxy. Grâce à pf Il est possible de désactiver le NAT pour une plage d'adresses IP donnée dans le réseau local et d'autoriser le NAT uniquement pour notre nœud TOR. Ainsi, même si un malware pénètre dans la cellule, il ne sera probablement pas capable de communiquer avec le monde extérieur, et même s'il le fait, il ne révélera pas l'adresse IP de notre serveur. Nous créons donc une cellule supplémentaire pour le « passage » des services en tant que service « .onion » et comme proxy pour la sortie vers Internet pour des cellules spécifiques.

# cbsd jsconstruct-tui

# cbsd jstart tor

# jexec tor

tor:/@[15:38] # pkg install tor

tor:/@[15:38] # sysrc tor_enable=YES

tor:/@[15:38] # ee /usr/local/etc/tor/torrc

Nous configurons l'écoute sur l'adresse locale (accessible à toutes les cellules)

SOCKSPort 192.168.0.2:9050

Que nous manque-t-il encore pour un bonheur complet ? Oui, nous avons besoin d'un service pour notre web, peut-être même plusieurs. Nous allons lancer nginx, qui agira comme un reverse-proxy et s'occupera de prolonger les certificats Let’s Encrypt.

# cbsd jsconstruct-tui

# cbsd jstart nginx-rev

# jexec nginx-rev

nginx-rev:/@[15:47] # pkg install nginx py36-certbot

Et voilà, 150 Mo de dépendances mises dans la cellule. Et l'hôte reste toujours propre.

Nous reviendrons à la configuration de nginx plus tard, nous devons créer encore deux cellules pour notre passerelle de paiement sur nodejs et rust, et une application web, qui pour une raison ou une autre est sur apache et php, et pour ça elle a également besoin d'une base de données MySQL.

# cbsd jsconstruct-tui

# cbsd jstart paygw

# jexec paygw

paygw:/@[15:55] # pkg install git node npm

paygw:/@[15:55] # curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

… et encore 380 Mo de paquets isolés

Ensuite, nous téléchargeons notre application avec git et la lançons.

# cbsd jsconstruct-tui

# cbsd jstart webapp

# jexec webapp

webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql

450 Mo de paquets. dans la cellule.

Ici, nous donnons un accès SSH aux développeurs directement dans la cellule, ils feront tout eux-mêmes :

webapp:/@[16:02] # ee /etc/ssh/sshd_config

Port 2267 — nous changeons le port SSH de la cellule à n'importe quel port aléatoire

webapp:/@[16:02] # sysrc sshd_enable=YES

webapp:/@[16:02] # service sshd start

Voilà, le service est lancé, il ne reste plus qu'à ajouter une règle dans pf firewall

Voyons quelles sont les adresses IP de nos cellules et à quoi ressemble notre « local »

# jls

   JID  IP Address      Hostname                      Path
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind
     2  192.168.0.2     tor.space.com                 /zroot/jails/jails/tor
     3  192.168.0.3     nginx-rev.space.com           /zroot/jails/jails/nginx-rev
     4  192.168.0.4     paygw.space.com               /zroot/jails/jails/paygw
     5  192.168.0.5     webapp.my.domain              /zroot/jails/jails/webapp

et ajoutons une règle

# ee /etc/pf.conf

## SSH for web-Devs
IP_JAIL="192.168.0.5"
PORT_JAIL="{ 2267 }"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

et puisque nous y sommes, ajoutons aussi une règle pour le reverse-proxy :

## web-ports for nginx-rev
IP_JAIL="192.168.0.3"
PORT_JAIL="{ 80, 443 }"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

# pfctl -f /etc/pf.conf

Et maintenant, un peu sur les bitcoins

Ce que nous avons — nous avons une application web qui est accessible de l'extérieur et elle communique localement avec notre passerelle de paiement. Maintenant, nous devons préparer un environnement de travail pour interagir avec le réseau bitcoin lui-même — nœud bitcoind C'est juste un démon qui maintient une copie locale de la blockchain actuelle. Ce démon a des fonctions RPC et de portefeuille, mais pour le développement d'applications, il existe des « wrappers » plus pratiques. Pour commencer, nous avons décidé d'installer electrum — c'est un portefeuille CLI. Ce portefeuille sera utilisé par nous comme « stockage à froid » pour nos bitcoins — en gros, ces bitcoins qui doivent être conservés « en dehors » du système accessible aux utilisateurs et loin de tout le monde. Il possède également une interface graphique, donc nous prévoyons d'utiliser le même portefeuille sur nos
ordinateurs portables. Pour l'instant, nous allons utiliser Electrum avec des serveurs publics, et plus tard, nous créerons une autre cellule pour ne dépendre de personne. ElectrumX, pour ne dépendre de personne.

# cbsd jsconstruct-tui

# cbsd jstart electrum

# jexec electrum

electrum: /@[8:45] # pkg install py36-electrum

encore 700 Mo de logiciels dans notre cellule

electrum: /@[8:53] # adduser

Nom d'utilisateur : wallet
Nom complet : 
Uid (laisser vide pour le défaut) : 
Groupe de connexion [wallet] : 
Le groupe de connexion est wallet. Inviter wallet dans d'autres groupes ? [] : 
Classe de connexion [default] : 
Shell (sh csh tcsh nologin) [sh] : tcsh
Répertoire personnel [ /home/wallet] : 
Permissions du répertoire personnel (laisser vide pour le défaut) : 
Utiliser l'authentification par mot de passe ? [yes] : non
Verrouiller le compte après création ? [non] : 
Nom d'utilisateur   : wallet
Mot de passe   : 
Nom complet  : 
Uid        : 1001
Classe      : 
Groupes     : wallet 
Domicile       : /home/wallet
Mode d'accueil  : 
Shell      : /bin/tcsh
Verrouillé     : non
OK ? (oui/non) : oui
adduser : INFO : Ajout réussi de (wallet) à la base de données des utilisateurs.
Ajouter un autre utilisateur ? (oui/non) : non
Au revoir !
electrum: /@[8:53] # su wallet

electrum: /@[8:53] # su wallet

wallet@electrum: / % electrum-3.6 create

{
    "msg": "Veuillez garder votre graine dans un endroit sûr ; si vous la perdez, vous ne pourrez pas restaurer votre portefeuille.",
    "path": "/usr/home/wallet/.electrum/wallets/default_wallet",
    "seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}

Voilà, nous avons maintenant créé un portefeuille.

wallet@electrum: / % electrum-3.6 listaddresses

[
    "18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
    "14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
    "1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
    ...
    "1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
    "18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]

wallet@electrum: / % electrum-3.6 help

Pour notre on-chain portefeuille, seuls un nombre limité de personnes pourront se connecter à l'avenir. Pour ne pas ouvrir l'accès externe à cette cellule, les connexions SSH seront faites via TOR (une sorte de version décentralisée de VPN). Nous lançons SSH dans la cellule, mais nous ne touchons pas à notre pf.conf sur l'hôte.

electrum: /@[9:00] # sysrc sshd_enable=YES

electrum: /@[9:00] # service sshd start

Maintenant, nous allons désactiver la connexion Internet dans la cellule avec le portefeuille. Nous allons lui attribuer une adresse IP d'un autre espace de sous-réseau qui n'est pas NATé. D'abord, nous changerons /etc/pf.conf sur l'hôte

# ee /etc/pf.conf

JAIL_IP_POOL="192.168.0.0/24" changer en JAIL_IP_POOL="192.168.0.0/25", ainsi toutes les adresses 192.168.0.126-255 n'auront pas d'accès direct à Internet. Une sorte de réseau « air-gap » logiciel. Et la règle NAT reste inchangée

nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

Nous rechargeons les règles

# pfctl -f /etc/pf.conf

Nous allons maintenant nous occuper de notre cellule

# cbsd jconfig jname=electrum

jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Supprimer l'ancienne IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Configurer la nouvelle IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200

Hmm, mais maintenant, notre système cessera également de fonctionner. Cependant, nous pouvons spécifier un proxy système. Mais il y a un hic, sur TOR c'est un proxy SOCKS5, et pour plus de commodité, nous aurions également besoin d'un proxy HTTP.

# cbsd jsconstruct-tui

# cbsd jstart polipo

# jexec polipo

polipo:/@[9:28] # pkg install polipo

polipo:/@[9:28] # ee /usr/local/etc/polipo/config

socksParentProxy = "192.168.0.2:9050"
socksProxyType = socks5

polipo:/@[9:42] # sysrc polipo_enable=YES

polipo:/@[9:43] # service polipo start

Voilà, maintenant notre système a deux serveurs proxy, et les deux passent par TOR : socks5://192.168.0.2:9050 et http://192.168.0.6:8123

Nous pouvons maintenant configurer l'environnement de notre portefeuille

# jexec electrum

electrum:/@[9:45] # su wallet

wallet@electrum:/ % ee ~/ .cshrc

#in the end of file proxy config
setenv http_proxy http://192.168.0.6:8123
setenv https_proxy http://192.168.0.6:8123

Et bien, maintenant le shell fonctionnera sous proxy. Si nous voulons installer des paquets, nous devrions ajouter dans /usr/local/etc/pkg.conf sous le root de la cellule

pkg_env: {
               http_proxy: "http://my_proxy_ip:8123",
           }

Et maintenant vient le moment d'ajouter le service caché TOR comme adresse de notre service SSH dans la cellule du portefeuille.

# jexec tor

tor:/@[9:59] # ee /usr/local/etc/tor/torrc

HiddenServiceDir /var/db/tor/electrum/
HiddenServicePort 22 192.168.0.200:22

tor:/@[10:01] # mkdir /var/db/tor/electrum

tor:/@[10:01] # chown -R _tor:_tor /var/db/tor/electrum

tor:/@[10:01] # chmod 700 /var/db/tor/electrum

tor:/@[10:03] # service tor restart

tor:/@[10:04] # cat /var/db/tor/electrum/hostname

mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion

Voici notre adresse de connexion. Vérifions cela depuis la machine locale. Mais d'abord, nous devons ajouter notre clé SSH :

wallet@electrum:/ % mkdir ~/ .ssh

wallet@electrum:/ % ee ~/ .ssh/authorized_keys

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@local

Et depuis la machine Linux cliente

user@local ~$ nano ~/ .ssh/config

#remote electrum wallet
Host remotebtc
        User wallet
        Port 22
        Hostname mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion
        ProxyCommand /bin/ncat --proxy localhost:9050 --proxy-type socks5 %h %p

Nous nous connectons (Pour que cela fonctionne, un démon TOR local écoutant sur 9050 est nécessaire)

user@local ~$ ssh remotebtc

L'authenticité de l'hôte 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion ()' ne peut pas être établie.
L'empreinte de la clé ECDSA est SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Êtes-vous sûr de vouloir continuer la connexion (yes/no/[fingerprint]) ? yes
Avertissement : 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) a été ajoutée de façon permanente à la liste des hôtes connus.
FreeBSD 12.1-RELEASE-p1 GENERIC 
Pour économiser de l'espace disque dans votre répertoire personnel, compressez les fichiers que vous utilisez rarement avec "gzip filename".
        -- Dru 
wallet@electrum:~ % logout

Succès !

Pour travailler avec des paiements instantanés et micros, nous avons également besoin d'un nœud Lightning Network, en fait, cela sera notre principal outil de travail avec Bitcoin. Au *c-lightning, que nous allons utiliser comme démon, a le plugin Sparko, qui est une véritable interface HTTP (REST) et permet de travailler à la fois avec des transactions off-chain et on-chain. c-lightning pour fonctionner nécessite bitcoind un nœud.

*il existe différentes implémentations sur différents langages de programmation du protocole Lightning Network. Parmi celles que nous avons testées, c-lightning (écrit en C) s'est avéré être le plus stable et efficace en ressources.

# cbsd jsconstruct-tui

# cbsd jstart cln

# jexec cln

lightning:‍@[10:23] # adduser

Nom d'utilisateur : lightning
...

lightning:‍@[10:24] # pkg install git

lightning:‍@[10:23] # su lightning

cd ~ && git clone https://github.com/ElementsProject/lightning

lightning@lightning:~ % exit

lightning:‍@[10:30] # cd /home/lightning/lightning/

lightning:/home/lightning/lightning@[10:31] # pkg install autoconf automake gettext git gmp gmake libtool python python3 sqlite3 libsodium py36-mako bash bitcoin-utils

lightning:/home/lightning/lightning@[10:34] # ./configure && gmake && gmake install

Pendant que tout le nécessaire se compile et s'installe, créons un utilisateur RPC pour lightningd dans bitcoind

# jexec bitcoind

bitcoind:‍@[10:36] # ee /usr/local/etc/bitcoin.conf

rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#autoriser uniquement c-lightning
rpcallowip=192.168.0.7/32

bitcoind:‍@[10:39] # service bitcoind restart

Mon passage chaotique entre les cellules ne semble pas si chaotique si l'on considère l'utilitaire tmux, qui permet de créer plusieurs sous-sessions de terminaux au sein d'une seule session. Analogue : screen

Alors, nous ne voulons pas exposer l'IP réelle de notre nœud, et nous souhaitons effectuer toutes les opérations financières via TOR. C'est pourquoi nous avons besoin d'un autre .onion.

# jexec tor

tor:/@[9:59] # ee /usr/local/etc/tor/torrc

HiddenServiceDir /var/db/tor/cln/
HiddenServicePort 9735 192.168.0.7:9735

tor:‍@[10:01] # mkdir /var/db/tor/cln

tor:‍@[10:01] # chown -R _tor:_tor /var/db/tor/cln

tor:‍@[10:01] # chmod 700 /var/db/tor/cln

tor:/@[10:03] # service tor restart

tor:‍@[10:04] # cat /var/db/tor/cln/hostname

en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onion

maintenant, créons la configuration pour c-lightning

lightning:/home/lightning/lightning@[10:31] # su lightning

lightning@lightning:~ % mkdir .lightning

lightning@lightning:~ % ee .lightning/config

alias=My-LN-Node
bind-addr=192.168.0.7:9735
rgb=ff0000
announce-addr=en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onion:9735
network=bitcoin
log-level=info
fee-base=0
fee-per-satoshi=1
proxy=192.168.0.2:9050
log-file=/home/lightning/.lightning/c-lightning.log
min-capacity-sat=200000

# plugin sparko
# https://github.com/fiatjaf/lightningd-gjson-rpc/tree/master/cmd/sparko

sparko-host=192.168.0.7
sparko-port=9737

sparko-tls-path=sparko-tls

#sparko-login=mywalletusername:mywalletpassword

#sparko-keys=masterkey;secretread:+listchannels,+listnodes;secretwrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
sparko-keys=masterkey;secretread:+listchannels,+listnodes;ultrawrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
# pour l'exemple ci-dessus, les journaux d'initialisation (mélangés avec les journaux de lightningd) devraient imprimer quelque chose comme

lightning@lightning:~ % mkdir .lightning/plugins

lightning@lightning:~ % cd .lightning/plugins/

lightning@lightning:~/.lightning/plugins:% fetch https://github.com/fiatjaf/sparko/releases/download/v0.2.1/sparko_full_freebsd_amd64

lightning@lightning:~/.lightning/plugins % mkdir ~/.lightning/sparko-tls

lightning@lightning:~/.lightning/sparko-tls % cd ~/.lightning/sparko-tls

lightning@lightning:~/.lightning/sparko-tls % openssl genrsa -out key.pem 2048

lightning@lightning:~/.lightning/sparko-tls % openssl req -new -x509 -sha256 -key key.pem -out cert.pem -days 3650

lightning@lightning:~/.lightning/plugins % chmod +x sparko_full_freebsd_amd64

lightning@lightning:~/.lightning/plugins % mv sparko_full_freebsd_amd64 sparko

lightning@lightning:~/.lightning/plugins % cd ~

Il faut aussi créer un fichier de configuration pour bitcoin-cli, l'outil qui communique avec bitcoind

lightning@lightning:~ % mkdir .bitcoin

lightning@lightning:~ % ee .bitcoin/bitcoin.conf

rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test

vérifions

lightning@lightning:~ % bitcoin-cli echo "test"

[
  "test"
]

lancez lightningd

lightning@lightning:~ % lightningd --daemon

Moi lightningd on peut gérer l'outil lightning-cli, par exemple :

lightning-cli newaddr obtenir une adresse pour un nouveau paiement entrant

{
   "address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
   "bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}

lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all envoyer tous les fonds du portefeuille (de toutes les adresses on-chain)

Voici également les commandes pour les opérations off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.

Mais pour communiquer avec l'application, nous avons l'API REST

curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'

Pour résumer

# jls

   JID  Adresse IP      Nom d'hôte                      Chemin
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind
     2  192.168.0.2     tor.space.com                 /zroot/jails/jails/tor
     3  192.168.0.3     nginx-rev.space.com           /zroot/jails/jails/nginx-rev
     4  192.168.0.4     paygw.space.com               /zroot/jails/jails/paygw
     5  192.168.0.5     webapp.my.domain              /zroot/jails/jails/webapp
     7  192.168.0.200   electrum.space.com            /zroot/jails/jails/electrum
     8  192.168.0.6     polipo.space.com              /zroot/jails/jails/polipo
     9  192.168.0.7     lightning.space.com           /zroot/jails/jails/cln

Nous avons un ensemble de conteneurs, chacun avec son propre niveau d'accès tant vers qu'à partir du réseau local.

# zfs list

NOM                    UTILISÉ  DISPONIBLE  RÉFÉRENCED  POINT DE MONTAGE
zroot                   279G  1.48T    88K  /zroot
zroot/ROOT             1.89G  1.48T    88K  none
zroot/ROOT/default     1.89G  17.6G  1.89G  /
zroot/home               88K  1.48T    88K  /home
zroot/jails             277G  1.48T   404M  /zroot/jails
zroot/jails/bitcoind    190G  1.48T   190G  /zroot/jails/jails-data/bitcoind-data
zroot/jails/cln         653M  1.48T   653M  /zroot/jails/jails-data/cln-data
zroot/jails/electrum    703M  1.48T   703M  /zroot/jails/jails-data/electrum-data
zroot/jails/nginx-rev   190M  1.48T   190M  /zroot/jails/jails-data/nginx-rev-data
zroot/jails/paygw      82.4G  1.48T  82.4G  /zroot/jails/jails-data/paygw-data
zroot/jails/polipo     57.6M  1.48T  57.6M  /zroot/jails/jails-data/polipo-data
zroot/jails/tor        81.5M  1.48T  81.5M  /zroot/jails/jails-data/tor-data
zroot/jails/webapp      360M  1.48T   360M  /zroot/jails/jails-data/webapp-data

Comme on peut le voir, bitcoind occupe tout l'espace de 190 Go. Que faire si nous avons besoin d'une autre nœud à des fins de test ? C'est ici que ZFS entre en jeu. Grâce à cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com il est possible de créer un snapshot et d'associer une nouvelle cellule à ce snapshot. La nouvelle cellule aura entièrement son propre espace, mais seule la différence entre l'état actuel et l'original sera prise en compte dans le FS (ce qui nous permettra d'économiser au moins 190 Go)

Chaque cellule est son propre ensemble de données ZFS distinct, et c'est extrêmement pratique. ZFS permet également de faire d'autres choses intéressantes, comme l'envoi de snapshots via SSH. Nous ne développerons pas cela, il y a déjà beaucoup à dire.

Il convient également de noter la nécessité de surveiller le serveur à distance, nous avons pour cela Zabbix.

B — sécurité

En ce qui concerne la sécurité, partons des principes clés dans le contexte de l'infrastructure :

Confidentialité — Les outils standard des systèmes de type UNIX assurent l'application de ce principe. Nous séparons logiquement l'accès à chaque élément distinct de la système — cellule. L'accès se fait par le biais d'une authentification utilisateur standard par clés privées des utilisateurs. Toute communication entre et vers les cellules finales se fait de manière chiffrée. Grâce au chiffrement des disques, nous n'avons pas à nous soucier de la sécurité des données lors du remplacement d'un disque ou de la migration vers un autre serveur. Le seul accès critique est l'accès au système hôte, car cet accès permet généralement d'accéder aux données à l'intérieur des conteneurs.

Intégrité — L'application de ce principe se fait à plusieurs niveaux différents. Tout d'abord, il est important de noter qu'en ce qui concerne le matériel serveur, la mémoire ECC, ZFS s'occupe déjà "par défaut" de l'intégrité des données au niveau des bits d'information. Les snapshots instantanés permettent de faire des sauvegardes à tout moment en temps réel. Des outils d'import-export pratiques pour les cellules rendent simple la réplication des cellules.

Disponibilité — Cela dépend ici déjà de votre notoriété et du fait que vous ayez des détracteurs. Dans notre exemple, nous avons assuré l'accès au portefeuille exclusivement à partir du réseau TOR. Si nécessaire, il est possible de bloquer complètement l'accès via le pare-feu et de ne permettre l'accès au serveur que par des tunnels (le TOR ou le VPN est un autre sujet). Ainsi, le serveur sera isolé du monde extérieur autant que possible, et nous serons les seuls à pouvoir influencer son accessibilité.

Impossibilité de refus — Cela dépend de l'exploitation ultérieure et du respect des politiques d'utilisation des droits, d'accès, etc. Mais avec une approche appropriée, toutes les actions des utilisateurs sont auditées, et grâce à des solutions cryptographiques, il est possible d'identifier sans équivoque qui a effectué quelles actions et quand.

Bien sûr, la configuration décrite n'est pas un exemple absolu de ce qu'elle doit toujours être, c'est plutôt un des exemples de ce qu'elle pourrait être, tout en conservant une grande flexibilité en termes de scalabilité et de personnalisation.

Et qu'en est-il de la virtualisation complète ?

Concernant la virtualisation complète avec cbsd, vous pouvez lire ici. Je voudrais juste ajouter que pour cela, bhyve il est nécessaire d'activer certains paramètres du noyau.

# cat /etc/rc.conf

...
kld_list="vmm if_tap if_bridge nmdm"
...

# cat /boot/loader.conf

...
vmm_load="YES"
...

Donc, s'il y a un besoin de faire fonctionner Docker, nous lançons une Debian et c'est parti !

C'est tout.

C'est probablement tout ce que je voulais partager. Si vous avez apprécié l'article, vous pouvez me faire un don en bitcoins — bc1qu7lhf45xw83ddll5mnzte6ahju8ktkeu6qhttc. Si vous souhaitez essayer des cellules en action et avez un peu de bitcoins, vous pouvez consulter mon pet-project.

Source : habr.com