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 , 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 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 und . 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 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=1Es ist auch wichtig sicherzustellen, dass Sie die neueste Version des Systems installiert haben, und 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 .
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/$MYFILENAMEAktivieren von
sysrc auditd_enable=YES
# service auditd start
Wie man das verwaltet, ist hervorragend beschrieben in .
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 ab , ich wünsche ihm viel Gesundheit und Segen für dieses hervorragende Tool!
Container? Ist das wieder Docker?
Aber nein. 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 . Wir werden ein Beispiel für die Nutzung bhyve im folgenden Beispiel betrachten.
Installation und Konfiguration der Host-Umgebung
Wir verwenden das FS . 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 .
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 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/bitcoindjexec 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/webappUnd 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. 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 , 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 walletelectrum: /@[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.200Hmm, 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 = socks5polipo:/@[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
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:8123Nun, 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: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.onionHier 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@localUnd 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. , das wird unser hauptsächliches Arbeitsinstrument mit Bitcoin sein. Zu *, das wir als Daemon verwenden werden, gibt es , 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/32bitcoind:@[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: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.onionJetzt 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 ausgebenlightning@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=testwir ü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-dataWie 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. 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 .
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 . 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 — . Wenn Sie die Zellen in Aktion ausprobieren möchten und ein wenig Bitcoin haben, können Sie mein .
Quelle: habr.com
