Bitcoin im Käfig?

Ich habe das Glück, als Administrator für Computersysteme und Netzwerke (kurz: Sysadmin) zu arbeiten und kann auf etwas mehr als 10 Jahre professionelle Erfahrung mit den unterschiedlichsten Systemen zurückblicken, einschließlich solcher, die [sicherheits]technische Maßnahmen erfordern. Außerdem habe ich vor einiger Zeit für mich selbst entdeckt, dass Bitcoin, und ich habe nicht nur damit gearbeitet, sondern auch mehrere Mikrodienste gestartet, um zu lernen, wie ich selbstständig im Bitcoin-Netzwerk (es ist schließlich p2p) aus der Sicht eines Entwicklers arbeiten kann (ich bin zwar kein besonders erfahrener Entwickler, nur ein Gelegenheitsnutzer). Aber ich will über die Entwicklung sprechen, nicht über ein sicheres und effektives Umfeld für Anwendungen. devFinanztechnologien (

fintech) stehen in engem Zusammenhang mit Informationssicherheit (infosec), und das erste kann ohne das zweite funktionieren, aber nicht lange. Daher möchte ich meine Erfahrungen und das Set an Werkzeugen, die ich benutze, teilen, welches sowohl für, gleichzeitig, als auch in einem breiteren oder ganz anderen Kontext verwendet werden kann. In diesem Artikel werde ich nicht so sehr über Bitcoin sprechen, sondern vielmehr über die Infrastrukturmodelle für die Entwicklung und den Betrieb von Finanzdiensten (und nicht nur) – mit einem Wort über jene Dienste, bei denen „B“ von Bedeutung ist. Dies gilt sowohl für eine Bitcoin-Börse als auch für einen typischen Unternehmenszoo von Dienstleistungen eines kleinen Unternehmens, das mit Bitcoin nichts zu tun hat. ) stehen in engem Zusammenhang mit Informationssicherheit (, als auch ), und das erste kann ohne das zweite funktionieren, aber nicht lange. Daher möchte ich meine Erfahrungen und das Set an Werkzeugen, die ich benutze, teilen, welches sowohl fürIch möchte betonen, dass ich ein Befürworter der Prinzipien

„keep it stupid simple“ „less is more“ und , daher wird sowohl der Artikel als auch der darin beschriebene Inhalt die Eigenschaften aufweisen, die diese Prinzipien reflektieren.Fiktives Szenario:

Fiktives Szenario: Lassen Sie uns alles am Beispiel eines Bitcoin-Wechselkurses erklären. Wir haben beschlossen, den Wechsel von Rubel, Dollar, Euro in Bitcoin und zurück zu starten, und wir haben bereits eine funktionierende Lösung, aber für andere digitale Währungen wie Qiwi und WebMoney. Das heißt, wir haben alle rechtlichen Fragen geklärt, haben eine fertige Anwendung, die als Zahlungsgateway für Rubel, Dollar und Euro sowie andere Zahlungssysteme fungiert. Sie ist mit unseren Bankkonten verbunden und verfügt über ein gewisses API für unsere Endanwendungen. Außerdem haben wir eine Webanwendung, die als Wechselkurs für Benutzer fungiert, ähnlich wie ein typisches Qiwi- oder WebMoney-Konto — erstellen Sie ein Konto, fügen Sie eine Karte hinzu und so weiter. Sie kommuniziert mit unserer Gateway-Anwendung, lassen Sie es über REST API in der lokalen Umgebung geschehen. Und jetzt haben wir beschlossen, Bitcoin zu integrieren und gleichzeitig die Infrastruktur aufzurüsten, da anfangs alles hastig auf VirtualBoxen im Büro unter dem Tisch eingerichtet wurde… die Website wird genutzt, und wir haben uns um die Betriebszeit und Leistung gesorgt.

Also, fangen wir mit dem Wesentlichen an — der Wahl des Servers. Da das Geschäft in unserem Beispiel klein ist und wir dem Hosting-Anbieter (OVH) vertrauen, wählen wir eine budgetfreundliche Option bei der man das System nicht aus dem Original-Image .iso installieren kann, aber das ist kein Problem, die IT-Sicherheitsabteilung wird das installierte Image auf jeden Fall analysieren. Wenn wir wachsen, mieten wir vielleicht sogar einen eigenen Schrank mit Sicherheitsschloss und eingeschränktem physischem Zugang, vielleicht bauen wir sogar unser eigenes Rechenzentrum. In jedem Fall sollte man im Hinterkopf behalten, dass bei der Miete von Hardware und der Installation von fertigen Images die Gefahr besteht, dass ein „Trojaner vom Hosting-Anbieter“ in Ihrem System hängen bleibt, der in den meisten Fällen nicht dazu dient, Sie auszuspionieren, sondern um bequemere Serververwaltungswerkzeuge anzubieten.

Serverinstallation

Hier ist alles einfach. Wir wählen die Hardware, die unseren Bedürfnissen entspricht. Dann wählen wir das FreeBSD-Image aus. Oder wir verbinden uns (im Falle eines anderen Hosters und unserer eigenen Hardware) über IPMI oder mit einem Monitor und laden das .iso-Image von FreeBSD. Für die orchestrierte Installation benutze ich Ansible und mfsbsd. Das einzige ist, dass wir in unserem Fall mit kimsufi die benutzerdefinierte Installation ausgewählt haben, damit die beiden Festplatten im Spiegel nur die Boot- und /home-Partitionen „offen“ haben, der Rest des Speicherplatzes wird verschlüsselt, aber dazu später mehr.

Die Installation des Systems erfolgt auf die übliche Weise, ich werde nicht weiter darauf eingehen, sondern lediglich darauf hinweisen, dass man vor der Nutzung auf folgende Punkte achten sollte: hardening Optionen, die angeboten werden von bsdinstaller am Ende der Installation (wenn Sie das System selbst installieren):

Ja gutes Material zu diesem Thema, ich werde es hier kurz wiederholen.

Die oben genannten Parameter können auch auf einem bereits installierten System aktiviert werden. Dazu muss die Bootloader-Datei bearbeitet und die Kernel-Parameter aktiviert werden. *ee – das ist ein Editor in 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

Es ist auch wichtig sicherzustellen, dass Sie die neueste Version des Systems installiert haben, und alle Updates und Upgrades auszuführen.In unserem Fall ist beispielsweise ein Upgrade auf die neueste Version erforderlich, da die vorinstallierten Images um sechs Monate bis ein Jahr hinterherhinken. Außerdem ändern wir den SSH-Port auf einen anderen als den Standardport, fügen die Authentifizierung über Schlüssel hinzu und deaktivieren die Passwortanmeldung.

Dann konfigurieren wir aide, die Überwachung des Zustands der Konfigurationsdateien des Systems. Ausführlicheres kann man hier.

pkg install aide

und wir bearbeiten unseren 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

Aktivieren von systematische Auditierung

sysrc auditd_enable=YES

# service auditd start

Wie man das verwaltet, ist hervorragend beschrieben in Handbuch.

Jetzt starten wir neu und beginnen mit der Software auf dem Server. Jeder Server fungiert als Hypervisor für Container oder vollständige virtuelle Maschinen. Deshalb ist es wichtig, dass der Prozessor VT-x und EPT unterstützt, wenn wir vollständige Virtualisierung nutzen wollen.

Als Verwaltung für Container und virtuelle Maschinen benutze ich cbsd ab olevole, ich wünsche ihm viel Gesundheit und Segen für dieses hervorragende Tool!

Container? Ist das wieder Docker?

Aber nein. FreeBSD Jails sind ein hervorragendes Werkzeug zur Containerisierung, und das erwähnte cbsd zur Orchestrierung dieser Container, die Zellen heißen.

Ein Container ist eine äußerst effektive Lösung zum Aufbau einer Infrastruktur für die unterschiedlichsten Zwecke, bei denen letztlich eine vollständige Isolation einzelner Dienste oder Prozesse erforderlich ist. Im Grunde genommen ist dies ein Klon des Host-Systems, jedoch ohne die Notwendigkeit vollständiger Virtualisierung der Hardware. Dadurch werden keine Ressourcen für das 'Gastsystem' aufgewendet, sondern nur für die tatsächlich geleistete Arbeit. Wenn Container für interne Zwecke verwendet werden, ist es eine sehr bequeme Lösung für eine optimale Ressourcennutzung – viele Container auf einem physischen Server können jeweils die gesamten Serverressourcen nach Bedarf nutzen. Da in der Regel verschiedene Subdienste zu unterschiedlichen Zeiten zusätzliche Ressourcen benötigen, kann man von einem Server die maximale Leistung herausziehen, wenn man die Container richtig plant und balanciert. Bei Bedarf können Container auch Einschränkungen bezüglich der genutzten Ressourcen erhalten.

Und wie steht es um die vollständige Virtualisierung?

Soweit ich weiß, cbsd unterstützt die Nutzung von bhyve und XEN Hypervisoren. Den zweiten habe ich nie verwendet, aber der erste ist ein relativ junger Hypervisor von FreeBSD. Wir werden ein Beispiel für die Nutzung bhyve im folgenden Beispiel betrachten.

Installation und Konfiguration der Host-Umgebung

Wir verwenden das FS ZFS. Dies ist ein äußerst leistungsfähiges Tool für die Verwaltung des Speichers auf dem Server. Mit ZFS können aus den Festplatten Arrays in den unterschiedlichsten Konfigurationen erstellt, der Speicher dynamisch 'im laufenden Betrieb' erweitert, defekte Festplatten ausgetauscht, Snapshots verwaltet und vieles, vieles mehr umgesetzt werden, was in einer ganzen Reihe von Artikeln beschrieben werden könnte. Kehren wir zu unserem Server und seinen Festplatten zurück. Zu Beginn der Installation haben wir auf den Festplatten freien Speicher für verschlüsselte Partitionen gelassen. Warum? Damit das System automatisch hochfährt und über SSH lauscht.

gpart add -t freebsd-zfs /dev/ada0

/dev/ada0p4 added!

wir fügen die Partition des Festplattenspeichers zum verbleibenden Platz hinzu

geli init /dev/ada0p4

wir geben unser Verschlüsselungskennwort ein

geli attach /dev/ada0p4

wir geben erneut das Kennwort ein und erhalten das Gerät /dev/ada0p4.eli — das ist unser verschlüsselter Speicher. Dann wiederholen wir das Gleiche für /dev/ada1 und die restlichen Festplatten im Array. Und wir erstellen einen neuen ZFS Pool.

zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — nun, unser minimales Einsatz-Setup ist bereit. Ein gespiegeltes Festplattenarray für den Fall, dass eine der drei ausfällt.

Wir erstellen ein Dataset auf einem neuen „Pool“

zfs create vms/jails

pkg install cbsd — Wir haben den Befehl ausgeführt und das Management für unsere Jail-Umgebungen installiert.

Nachdem cbsd es installiert ist, muss es initialisiert werden:

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

und wir beantworten eine Menge Fragen, hauptsächlich mit den Standardantworten.

*Wenn Sie Verschlüsselung verwenden, ist es wichtig, dass der Daemon cbsdd nicht automatisch startet, bis Sie die Festplatten manuell oder automatisch (in unserem Beispiel macht das zabbix) entschlüsseln.

**Ich verwende auch kein NAT von cbsd, sondern konfiguriere es selbst in 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 für Jails
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

## Bitcoin Netzwerk Portweiterleitung
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

Die Konfiguration der Firewall-Politiken ist ein eigenes Thema, deshalb werde ich nicht näher auf die Konfiguration der BLOCK ALL-Politik und der Whitelists eingehen, das kann man nachlesen offizielle Dokumentation oder in einem der zahlreichen Artikel, die bei Google verfügbar sind.

Nun, wir haben cbsd installiert, es ist Zeit, unser erstes Arbeitstier zu schaffen – den Bitcoin-Daemon in der Jail!

cbsd jconstruct-tui

Hier sehen wir einen Dialog zur Erstellung einer Jail. Nachdem wir alle Werte eingestellt haben, erstellen wir sie!

Bei der Erstellung der ersten Jail sollten wir wählen, was als Grundlage für die Jails verwendet werden soll. Ich wähle das Release aus dem FreeBSD-Repository mit dem Befehl repo. Diese Wahl wird nur bei der Erstellung der ersten Jail einer bestimmten Version getroffen (es können Jails aller Versionen, die älter sind als die Hostversion, gehostet werden).

Nachdem alles installiert ist – starten wir die Jail!

# cbsd jstart bitcoind

Aber wir müssen Software in die Jail installieren.

# jls

   JID  IP Adresse      Hostname                      Pfad
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind

jexec bitcoind um in die Konsole der Jail zu gelangen

und bereits innerhalb der Jail installieren wir die Software mit ihren Abhängigkeiten (unseres Hostsystems bleibt sauber)

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

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

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

Die Bitcoin-Jail ist da, aber wir brauchen Anonymität, da wir planen, uns mit einigen Jails über das TOR-Netzwerk zu verbinden. Und generell haben wir vor, die meisten Jails mit verdächtiger Software nur über einen Proxy laufen zu lassen. Dank pf Es ist möglich, NAT für einen bestimmten IP-Bereich im lokalen Netzwerk zu deaktivieren und NAT nur für unseren TOR-Knoten zuzulassen. Auf diese Weise wird selbst wenn ein schädlicher Akteur in den Kasten eindringt, er wahrscheinlich keine Verbindung zur Außenwelt herstellen, und selbst wenn er es tut, wird er die IP unseres Servers nicht offenbaren. Daher erstellen wir einen weiteren Kasten, um Dienste wie den '.onion'-Dienst und einen Proxy für den Internetzugang für separate Kästen bereitzustellen.

# 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

Wir lassen auf der lokalen Adresse (für alle Kästen zugänglich) hören

SOCKSPort 192.168.0.2:9050

Was fehlt uns noch zum vollkommenen Glück? Ja, wir brauchen einen Dienst für unser Web, vielleicht sogar mehrere. Lasst uns Nginx starten, das als Reverse-Proxy fungiert und sich um die Verlängerung der Let's Encrypt-Zertifikate kümmert.

# cbsd jsconstruct-tui

# cbsd jstart nginx-rev

# jexec nginx-rev

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

Und nun haben wir 150 MB Abhängigkeiten im Kasten untergebracht. Und der Host bleibt weiterhin sauber.

Wir werden die Nginx-Konfiguration später wieder aufgreifen. Zuerst müssen wir noch zwei Kästen für unser Zahlungsgateway auf Node.js und Rust sowie eine Webanwendung, die aus irgendeinem Grund auf Apache und PHP basiert, einrichten. Außerdem benötigen wir eine MySQL-Datenbank für Letzteres.

# 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

… und zusätzlich 380 MB Pakete isoliert

Dann laden wir unsere Anwendung mit Git und starten sie.

# cbsd jsconstruct-tui

# cbsd jstart webapp

# jexec webapp

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

450 MB Pakete. Im Kasten.

Hier gewähren wir den Entwicklern direkten SSH-Zugang in den Kasten, sie werden dort alles selbst erledigen:

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

Port 2267 — wir ändern den SSH-Port des Kastens auf einen beliebigen willkürlichen

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

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

So, der Dienst läuft, wir müssen nur noch eine Regel in die pf Firewall hinzufügen

Schauen wir uns an, welche IPs unsere Kästen haben und wie unser „lokales Netzwerk“ aussieht.

# jls

   JID  IP-Adresse      Hostname                      Pfad
     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

Und wir fügen eine Regel hinzu

# 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

Nun, da wir hier sind, fügen wir auch eine Regel für den Reverse-Proxy hinzu:

## 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

Nun ein wenig über Bitcoin

Was haben wir — wir haben eine Webanwendung, die von außen zugänglich ist, und die lokal mit unserem Zahlungsgateway kommuniziert. Jetzt müssen wir eine Arbeitsumgebung für die Interaktion mit dem Bitcoin-Netzwerk selbst vorbereiten — einem Knoten. bitcoind Das ist nur ein Dämon, der eine lokale Kopie der aktuellen Blockchain unterstützt. Dieser Dämon hat RPC und Wallet-Funktionalität, jedoch gibt es für die Anwendungsentwicklung bequemere "Wrapper". Zuerst haben wir uns entschieden, electrum — das ist eine CLI-Wallet. Diese Wallet wird als „Cold Storage“ für unsere Bitcoins verwendet — das sind die Bitcoins, die „außerhalb“ des für Benutzer zugänglichen Systems und allgemein weit entfernt von allen aufbewahrt werden müssen. Sie hat auch eine GUI, daher werden wir dieselbe Wallet auf unseren
Laptops verwenden. Zunächst werden wir Electrum mit öffentlichen Servern nutzen, und später in einem weiteren Jail werden wir ElectrumX, um von niemandem abhängig zu sein.

# cbsd jsconstruct-tui

# cbsd jstart electrum

# jexec electrum

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

noch 700 MB Software haben wir in unserem Jail

electrum: /@[8:53] # adduser

Benutzername: wallet
Vollständiger Name: 
Uid (Leer lassen für Standard): 
Login-Gruppe [wallet]: 
Login-Gruppe ist wallet. Wallet in andere Gruppen einladen? []: 
Login-Klasse [default]: 
Shell (sh csh tcsh nologin) [sh]: tcsh
Home-Verzeichnis [ /home/wallet]: 
Berechtigungen des Home-Verzeichnisses (Leer lassen für Standard): 
Passwortbasierte Authentifizierung verwenden? [ja]: nein
Konto nach Erstellung sperren? [nein]: 
Benutzername   : wallet
Passwort   : 
Vollständiger Name  : 
Uid        : 1001
Klasse      : 
Gruppen     : wallet 
Home       : /home/wallet
Home-Modus  : 
Shell      : /bin/tcsh
Gesperrt     : nein
OK? (ja/nein): ja
adduser: INFO: Erfolgreich (wallet) zur Benutzerdatenbank hinzugefügt.
Einen weiteren Benutzer hinzufügen? (ja/nein): nein
Auf Wiedersehen!
electrum: /@[8:53] # su wallet

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

wallet@electrum: / % electrum-3.6 create

{
    "msg": "Bitte bewahren Sie Ihren Seed an einem sicheren Ort auf; wenn Sie ihn verlieren, können Sie Ihr Wallet nicht wiederherstellen.",
    "path": "/usr/home/wallet/.electrum/wallets/default_wallet",
    "seed": "eifersüchtiger Schwein Material Band Junge Schlag visuell okay Kaktus zufällig Vogel"
}

Jetzt haben wir eine Wallet erstellt.

wallet@electrum: / % electrum-3.6 listaddresses

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

wallet@electrum: / % electrum-3.6 help

Für unsere on-chain Wallet kann in Zukunft nur eine begrenzte Anzahl von Personen eine Verbindung herstellen. Um den Zugriff von außen auf dieses Jail nicht zu öffnen, werden die Verbindungen über SSH über TOR (eine dezentrale VPN-Alternative) erfolgen. Wir starten SSH im Jail, aber berühren unsere pf.conf auf dem Host nicht.

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

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

Jetzt werden wir das Jail mit der Wallet vom Internet trennen. Wir vergeben ihm eine IP-Adresse aus einem anderen Subnetz, das nicht NAT wird. Zuerst ändern wir /etc/pf.conf auf dem Host

# ee /etc/pf.conf

JAIL_IP_POOL="192.168.0.0/24" ändern wir zu JAIL_IP_POOL="192.168.0.0/25", somit haben alle Adressen 192.168.0.126-255 keinen direkten Internetzugang. Eine Art softwarebasiertes „Air-Gap“-Netzwerk. Und die NAT-Regel bleibt wie sie war.

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

Wir laden die Regeln neu.

# pfctl -f /etc/pf.conf

Jetzt kümmern wir uns um unser Käfig.

# cbsd jconfig jname=electrum

jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Alte IP entfernen: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Neue IP einrichten: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200

Hmm, aber jetzt wird auch das System selbst nicht mehr funktionieren. Wir können jedoch einen systemweiten Proxy angeben. Es gibt jedoch ein Aber: Auf TOR ist das ein SOCKS5-Proxy und zu unserem Komfort bräuchten wir außerdem einen HTTP-Proxy.

# 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

So, jetzt gibt es zwei Proxy-Server in unserem System, die beide über TOR leiten: socks5://192.168.0.2:9050 und http://192.168.0.6:8123

Jetzt können wir die Umgebung unserer Wallet einrichten.

# 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

Nun, jetzt wird die Shell unter dem Proxy arbeiten. Wenn wir Pakete installieren möchten, sollten wir das in /usr/local/etc/pkg.conf unter dem Root-Konto des Käfigs.

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

Jetzt ist es an der Zeit, den TOR-Hidden-Service als Adresse unseres SSH-Dienstes im Wallet-Käfig hinzuzufügen.

# 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

Hier ist unsere Adresse zum Verbinden. Lass uns das von einem lokalen Rechner überprüfen. Aber zuerst müssen wir unseren SSH-Schlüssel hinzufügen:

wallet@electrum:/ % mkdir ~/ .ssh

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

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

Und dann von der Client-Linux-Maschine.

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

Verbinden (Damit das funktioniert, ist ein lokaler TOR-Daemon erforderlich, der auf 9050 lauscht.)

user@local ~$ ssh remotebtc

Die Authentizität des Hosts 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion ()' kann nicht bestätigt werden.
Der ECDSA-Keystempel ist SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein/[Fingerprint])? ja
Warnung: 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) wurde dauerhaft zur Liste der bekannten Hosts hinzugefügt.
FreeBSD 12.1-RELEASE-p1 GENERIC 
Um Speicherplatz in Ihrem Home-Verzeichnis zu sparen, komprimieren Sie Dateien, die Sie selten verwenden, mit "gzip Dateiname".
        -- Dru 
wallet@electrum:~ % logout

Erfolg!

Für die Arbeit mit Instant- und Mikrozahlungen benötigen wir auch einen Node. Lightning Network, das wird unser hauptsächliches Arbeitsinstrument mit Bitcoin sein. Zu *c-lightning, das wir als Daemon verwenden werden, gibt es das Sparko-Plugin, das eine vollständige HTTP (REST) Schnittstelle bietet und sowohl mit Off-Chain- als auch mit On-Chain-Transaktionen arbeitet. c-lightning für die Funktionalität benötigt man bitcoind einen Node.

*Es gibt verschiedene Implementierungen des Lightning Network Protokolls in unterschiedlichen Programmiersprachen. Von denen, die wir getestet haben, erschien c-lightning (geschrieben in C) als das stabilste und ressourcenschonendste.

# cbsd jsconstruct-tui

# cbsd jstart cln

# jexec cln

lightning:‍@[10:23] # adduser

Benutzername: 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

Während alles Notwendige kompiliert und installiert wird, erstellen wir einen RPC-Benutzer für lightningd in bitcoind

# jexec bitcoind

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

rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#nur c-lightning erlauben
rpcallowip=192.168.0.7/32

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

Mein chaotisches Umschalten zwischen den Zellen ist gar nicht so chaotisch, wenn man das Dienstprogramm berücksichtigt tmux, das es ermöglicht, innerhalb einer Sitzung viele Unter-Sitzungen von Terminals zu erstellen. Analog: Nun bleibt nur noch, den Bot zu starten. Um Prozesse auf dem Server zu starten, benutze ich gerne

Okay, wir wollen die echte IP unseres Nodes nicht enthüllen und möchten alle finanziellen Transaktionen über TOR abwickeln. Deshalb benötigen wir noch ein .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

Jetzt erstellen wir eine Konfiguration für c-lightning

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

lightning@lightning:~ % mkdir .lightning

lightning@lightning:~ % ee .lightning/config

alias=Mein-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

# Sparko-Plugin
# 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
# für das obige Beispiel sollten die Initialisierungsprotokolle (gemischt mit lightningd-Protokollen) etwas wie folgt ausgeben

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 ~

Es muss auch eine Konfigurationsdatei für bitcoin-cli erstellt werden, ein Tool, das mit bitcoind

lightning@lightning:~ % mkdir .bitcoin

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

rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test

wir überprüfen

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

[
  "test"
]

die lightningd

lightning@lightning:~ % lightningd --daemon

Wine lightningd man kann das Tool verwalten lightning-cli, zum Beispiel:

lightning-cli newaddr eine Adresse für die neue eingehende Zahlung erhalten

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

lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all alle Gelder aus der Brieftasche (alle On-Chain-Adressen) an die Adresse senden

Es gibt auch Befehle für Off-Chain-Operationen lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay usw.

Für die Kommunikation mit der Anwendung haben wir ein REST-API

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

Lassen Sie uns die Ergebnisse zusammenfassen

# jls

   JID  IP-Adresse      Hostname                      Pfad
     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

Wir haben eine Reihe von Containern, jeder mit seinem eigenen Zugriffslevel, sowohl aus als auch in das lokale Netzwerk.

# zfs list

NAME                    VERWENDUNG  VERFÜGBAR  REFERENZ  MOUNTPOINT
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

Wie zu sehen ist, belegt bitcoind den gesamten Speicherplatz von 190 GB. Was ist, wenn wir einen weiteren Knoten für Tests benötigen? Hier kommt ZFS gerade recht. Mit Hilfe von cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Es ist möglich, einen Snapshot zu erstellen und eine neue Zelle mit diesem Snapshot zu verknüpfen. Die neue Zelle hat ihren eigenen, vollständig separaten Raum, jedoch werden in der FS nur die Unterschiede zwischen dem aktuellen Zustand und dem Original berücksichtigt (wir sparen mindestens 190 GB).

Jede Zelle ist ein eigener separater ZFS-Datensatz, und das ist äußerst praktisch. ZFS ermöglicht es zudem viele andere coole Dinge zu tun, wie das Versenden von Snapshots über SSH. Wir lassen das ausführlich sein, wir haben schon genug gesagt.

Es ist auch wichtig, die Notwendigkeit der Remote-Überwachung des Hosts zu erwähnen, wir haben dafür Zabbix.

B — Sicherheit

Was die Sicherheit betrifft, lassen Sie uns von den grundlegenden Prinzipien im Kontext der Infrastruktur ausgehen:

Vertraulichkeit — Die standardmäßigen Werkzeuge von UNIX-ähnlichen Systemen gewährleisten die Umsetzung dieses Prinzips. Wir trennen den Zugriff auf jedes logisch separate Elemente des Systems — der Zelle. Der Zugriff erfolgt über die standardmäßige Benutzerauthentifizierung mit den persönlichen Schlüsseln der Benutzer. Alle Kommunikation zwischen und zu den Endzellen erfolgt verschlüsselt. Dank der Verschlüsselung der Festplatten müssen wir uns während des Austauschs von Festplatten oder der Migration auf einen anderen Server keine Sorgen um die Datensicherheit machen. Der einzige kritische Zugriff ist der Zugang zum Host-System, da dieser im Allgemeinen Zugang zu den Daten innerhalb der Container ermöglicht.

Integrität — Die Umsetzung dieses Prinzips erfolgt auf mehreren verschiedenen Ebenen. Zunächst ist es wichtig zu erwähnen, dass bei Serverhardware, ECC-Speicher, ZFS bereits „out-of-the-box“ für die Integrität der Daten auf der Bit-Ebene sorgt. Sofortige Snapshots ermöglichen es, jederzeit im laufenden Betrieb Backups zu erstellen. Praktische Export-Import-Werkzeuge für Zellen erleichtern die Replikation von Zellen.

Verfügbarkeit — Hier ist es bereits optional. Es hängt von Ihrem Bekanntheitsgrad und der Tatsache ab, ob Sie Feinde haben oder nicht. In unserem Beispiel haben wir die Verfügbarkeit der Brieftasche ausschließlich aus dem TOR-Netzwerk ermöglicht. Bei Bedarf kann alles in der Firewall blockiert werden, und der Zugang zum Server kann ausschließlich über Tunnel (TOR oder VPN ist eine andere Frage) erlaubt werden. Auf diese Weise wird der Server so weit wie möglich vom externen Umfeld abgeschnitten, und nur wir selbst können auf seine Verfügbarkeit Einfluss nehmen.

Unabweisbarkeit — Das hängt von der weiteren Nutzung und der Einhaltung der richtigen Richtlinien für Benutzerrechte, Zugänglichkeit usw. ab. Bei der richtigen Vorgehensweise werden alle Benutzeraktionen protokolliert, und dank kryptografischer Lösungen ist es möglich, eindeutig zu identifizieren, wer und wann bestimmte Handlungen durchgeführt hat.

Natürlich ist die beschriebene Konfiguration kein absoluter Beispiel dafür, wie es immer sein sollte, sondern eher eines von vielen Beispielen, wie es sein kann, während es sehr flexible Möglichkeiten zur Skalierung und Anpassung beibehält.

Und was ist mit der vollständigen Virtualisierung?

Über die vollständige Virtualisierung mit cbsd kann man hier lesen. Ich möchte nur hinzufügen, dass für die Arbeiten bhyve einige Kernelparameter aktiviert werden müssen.

# cat /etc/rc.conf

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

# cat /boot/loader.conf

...
vmm_load="YES"
...

Falls es notwendig ist, Docker zu starten, können wir irgendein Debian aufsetzen und loslegen!

Das ist alles.

Das wäre alles, was ich teilen wollte. Wenn Ihnen der Artikel gefallen hat, können Sie mir Bitcoins schicken — bc1qu7lhf45xw83ddll5mnzte6ahju8ktkeu6qhttc. Wenn Sie die Zellen in Aktion ausprobieren möchten und ein wenig Bitcoin haben, können Sie mein pet-project.

Quelle: habr.com