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 , 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 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 et . 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 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=1Il est également important de s'assurer que vous disposez de la dernière version du système et . 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 .
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/$MYFILENAMENous activons
sysrc auditd_enable=YES
# service auditd start
La manière d'administrer cela est très bien décrite dans .
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 à partir de , je souhaite à cet excellent utilitaire beaucoup de santé et de bienfaits !
Des conteneurs ? Encore docker ?
Eh bien non. 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 . 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 . 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 .
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 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/bitcoindjexec 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/webappet 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. 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. , 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 walletelectrum: /@[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.200Hmm, 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 = socks5polipo:/@[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
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:8123Et 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:22tor:/@[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.onionVoici 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@localEt 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 , en fait, cela sera notre principal outil de travail avec Bitcoin. Au *, que nous allons utiliser comme démon, a , 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/32bitcoind:@[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:9735tor:@[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.onionmaintenant, 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 commelightning@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=testvé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-dataComme 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. 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 .
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 . 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 — . Si vous souhaitez essayer des cellules en action et avez un peu de bitcoins, vous pouvez consulter mon .
Source : habr.com
