Es ist so gekommen, dass ich von Beruf Systemadministrator für Computer und Netzwerke bin (kurz: Sysadmin) und in meiner mehr als 10-jährigen beruflichen Laufbahn mit den unterschiedlichsten Systemen gearbeitet habe, einschließlich solcher, die [erhöhte|verstärkte] Sicherheitsmaßnahmen erfordern. Zudem habe ich vor einiger Zeit Interesse an , nicht nur als Nutzer, sondern auch als Betreiber mehrerer Mikro-Services entwickelt, um zu lernen, wie man selbstständig im Bitcoin-Netzwerk (es handelt sich schließlich um ein P2P-Netzwerk) aus der Sicht eines Entwicklers (ich bin natürlich nur ein NEBENBEI-Techniker) arbeitet. Aber ich rede nicht von der Entwicklung, sondern von einer sicheren und effektiven Umgebung für Anwendungen. dev, so bin ich vorbeigekommen). Aber ich spreche nicht über die Entwicklung, sondern über eine sichere und effiziente Umgebung für Anwendungen.
Finanztechnologien (Fintech) stehen in enger Verbindung mit Informationssicherheit (Infosec), und das erste kann ohne das zweite funktionieren, aber nicht lange. Deshalb möchte ich meine Erfahrungen und das Set an Werkzeugen teilen, die ich benutze, welches Folgendes umfasst: Fintech, als auch Infosec, wobei es gleichzeitig auch in breiterem oder völlig anderem Kontext verwendet werden kann. In diesem Artikel möchte ich nicht nur über Bitcoin sprechen, sondern über das Infrastrukturmodell zur Entwicklung und den Betrieb von Finanzdienstleistungen (und mehr) – in einem Wort über die Dienstleistungen, bei denen das „B“ von Bedeutung ist. Dies gilt sowohl für eine Bitcoin-Börse als auch für die typische Sammlung von Dienstleistungen eines kleinen Unternehmens, das keinerlei Verbindung zu Bitcoin hat.
Ich möchte betonen, dass ich die Prinzipien unterstütze „keep it stupid simple“ und „less is more“, daher werden sowohl der Artikel als auch das darin Beschriebene Eigenschaften besitzen, die diesen Prinzipien entsprechen.
Hypothetisches Szenario: Lassen Sie uns alles am Beispiel eines Bitcoin-Austauschdienstes erklären. Wir haben beschlossen, den Austausch von Rubel, US-Dollar und Euro zu Bitcoins und umgekehrt zu starten. Wir haben bereits eine funktionierende Lösung, allerdings für andere digitale Währungen wie Qiwi und Webmoney. Alle rechtlichen Aspekte sind geklärt, und wir haben eine Anwendung, die als Zahlungsgateway für Rubel, US-Dollar und Euro sowie andere Zahlungssysteme fungiert. Diese ist mit unseren Bankkonten verbunden und bietet eine API für unsere Endanwendungen. Außerdem haben wir eine Webanwendung, die als Wechselstube für die Nutzer dient – ähnlich wie ein typisches Qiwi- oder Webmoney-Konto. Sie können ein Konto eröffnen, eine Karte hinzufügen und so weiter. Diese kommuniziert mit unserem Gateway über REST API in unserem internen Netzwerk. Nun haben wir uns entschieden, Bitcoins hinzuzufügen und gleichzeitig die Infrastruktur zu verbessern, da ursprünglich alles hastig auf VirtualBox im Büro unter dem Tisch eingerichtet wurde. Die Benutzer haben die Website genutzt, und wir begannen, uns um die Verfügbarkeit und Leistung zu sorgen.
Beginnen wir also mit dem Wesentlichen – der Wahl des Servers. Da das Geschäft in unserem Beispiel klein ist und wir dem Hosting-Anbieter (OVH) vertrauen, wählen wir In diesem Fall können Sie die ursprüngliche .iso-Datei nicht installieren, aber das ist kein Problem. Die IT-Sicherheitsabteilung wird eine Analyse des installierten Images durchführen. Wenn wir wachsen, mieten wir sogar einen eigenen, abgeschlossenen Schrank mit eingeschränktem physischem Zugang oder bauen vielleicht unser eigenes Rechenzentrum. In jedem Fall sollte man berücksichtigen, dass bei der Miete von Hardware und der Installation von fertigen Images die Gefahr besteht, dass ein "Trojaner vom Anbieter" in Ihrem System verbleibt. Dieser dient in den meisten Fällen nicht dazu, Sie auszuspionieren, sondern dazu, Ihnen bequemere Werkzeuge zur Verwaltung des Servers anzubieten.
Serverinstallation
Hier ist alles einfach. Wir wählen die Hardware aus, die unseren Bedürfnissen entspricht. Dann wählen wir das FreeBSD-Image aus. Alternativ können wir uns (im Fall eines anderen Anbieters und eigener Hardware) über IPMI oder ein Monitor anschließen und das .iso FreeBSD-Image starten. Für die orchestrierte Installation benutze ich und . Das einzige, was wir in unserem Fall mit kimsufi gewählt haben, ist eine benutzerdefinierte Installation , damit die beiden Festplatten im Mirror nur die Boot- und /home-Partitionen "offen" haben. Der restliche Speicherplatz der Festplatte wird verschlüsselt, aber dazu später mehr.
Die Installation des Systems erfolgt auf standardisierte Weise. Ich werde nicht weiter darauf eingehen, möchte jedoch darauf hinweisen, dass Sie vor der Inbetriebnahme auf Folgendes achten sollten: Härtung die Optionen, die angeboten werden von bsdinstaller am Ende der Installation (wenn Sie das System selbst installieren):
Es gibt zu diesem Thema; kurz gesagt, ich wiederhole es hier.
Die zuvor genannten Parameter können auch auf einem bereits installierten System aktiviert werden. Dazu müssen Sie die Bootloader-Datei bearbeiten und die Kernel-Parameter aktivieren. *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 die neueste Version des Systems installiert ist und . In unserem Fall beispielsweise ist ein Upgrade auf die neueste Version erforderlich, da die vorinstallierten Images um ein halbes bis ein Jahr veraltet sind. Außerdem ändern wir den SSH-Port auf einen anderen als den Standardport, fügen die Authentifizierung per Schlüssel hinzu und deaktivieren die Passwortauthentifizierung.
Dann konfigurieren wir aide, die Überwachung des Status der Systemkonfigurationsdateien. Ausführlichere Informationen können Sie lesen. .
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 wir
sysrc auditd_enable=YES
# service auditd start
Wie man das hervorragend verwaltet, ist gut beschrieben in .
Jetzt starten wir neu und kümmern uns um die Software auf dem Server. Jeder Server fungiert als Hypervisor für Container oder vollständige virtuelle Maschinen. Daher ist es wichtig, dass der Prozessor VT-x und EPT unterstützt, wenn wir vollständige Virtualisierung planen.
Für das Management von Containern und virtuellen Maschinen verwende ich ab , ich wünsche ihm viel Gesundheit und Wohlstand für dieses wunderbare Tool!
Container? Schon wieder Docker?
Und weit gefehlt. sind ein hervorragendes Werkzeug zur Containerisierung, während das erwähnte cbsd der Orchestrierung dieser Container dient, die den Namen - Zellen tragen.
Container sind eine äußerst effiziente Lösung zum Aufbau von Infrastruktur für vielfältige Zwecke, bei denen letztlich eine vollständige Isolation einzelner Dienste oder Prozesse erforderlich ist. Im Grunde genommen handelt es sich um einen Klon des Hosts, ohne dass eine vollständige Virtualisierung der Hardware erforderlich ist. Dadurch werden die Ressourcen nicht für ein "Gastbetriebssystem" verschwendet, sondern nur für die auszuführende Arbeit. Wenn Container für interne Zwecke verwendet werden, ist dies eine sehr praktische Lösung zur optimalen Ressourcennutzung – viele Container auf einem physischen Server können bei Bedarf jedes einzelne Serverressourcen nutzen. Angesichts dessen, dass unterschiedliche Subdienste oft zu verschiedenen Zeiten zusätzliche Ressourcen benötigen, kann man mit einer durchdachten Planung und Verteilung der Container zwischen Servern die maximale Leistung aus einem Server herausholen. Bei Bedarf können die Container auch hinsichtlich der genutzten Ressourcen beschränkt werden.
Wie sieht es mit der vollständigen Virtualisierung aus?
Soweit ich informiert bin, cbsd unterstützt die Nutzung von bhyve und XEN Hypervisoren. Den zweiten habe ich niemals verwendet, aber der erste ist ein relativ neuer . Wir werden ein Beispiel für die Nutzung betrachten bhyve im folgenden Beispiel.
Installation und Konfiguration der Host-Umgebung
Wir verwenden FS . Es handelt sich um ein äußerst leistungsfähiges Werkzeug zur Verwaltung des Speicherplatzes auf dem Server. Mit ZFS können direkt aus Festplatten Arrays der unterschiedlichsten Konfigurationen erstellt, der Speicherplatz dynamisch „live“ erweitert, defekte Festplatten ausgetauscht, Snapshots verwaltet und noch vieles mehr gemacht 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 Speicherplatz für verschlüsselte Partitionen freigelassen. Warum das? Damit das System automatisch hochfährt und über SSH lauscht.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
Wir fügen eine Partition zum verbleibenden Speicherplatz hinzu
geli init /dev/ada0p4
geben unser Verschlüsselungs-Passwort ein
geli attach /dev/ada0p4
geben Passwort erneut ein und es erscheint das Gerät /dev/ada0p4.eli – das ist unser verschlüsselter Speicherplatz. Dann wiederholen wir dasselbe für /dev/ada1 und die restlichen Festplatten im Array. Und erstellen ein neues .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — Nun, unser grundlegendes Toolkit ist bereit. Ein Spiegel-Array von Festplatten für den Fall, dass eine der drei ausfällt.
Wir erstellen ein Dataset auf dem neuen „Pool“
zfs create vms/jails
pkg install cbsd — Wir haben den Befehl ausgeführt und das Management für unsere Container 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 entschlüsselt haben (in unserem Beispiel erledigt das zabbix)
**Außerdem benutze ich 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 Einrichtung der Firewall-Richtlinien ist ebenfalls ein separates Thema, daher werde ich nicht ins Detail zur BLOCK ALL-Richtlinie und zur Konfiguration der Whitelists eingehen; das kann man lesen in oder in einem der vielen Artikel, die dafür verfügbar sind.
Nun, wir haben cbsd installiert, es ist Zeit, unser erstes Arbeitstier zu schaffen – den Bitcoin-Daemon in einer Jail!
cbsd jconstruct-tui
Hier sehen wir den Dialog zur Erstellung einer Jail. Nachdem wir alle Werte festgelegt haben, erstellen wir!
Bei der Erstellung der ersten Jail müssen wir wählen, was als Basis für die Jails verwendet werden soll. Ich wähle das Release aus dem FreeBSD-Repository mit dem Befehl repo. Diese Auswahl erfolgt nur bei der Erstellung der ersten Jail einer bestimmten Version (Jails älterer Versionen können gehostet werden, solange sie älter sind als die Host-Version).
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 auf die Konsole der Jail zuzugreifen
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
Der Bitcoin in der Jail ist da, aber wir benötigen Anonymität, da wir planen, uns mit einigen Jails über das TOR-Netzwerk zu verbinden. Und generell wollen wir die meisten Jails mit verdächtiger Software nur über Proxys betreiben. 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. So wird selbst wenn ein Schadprogramm in den Kasten gelangt, höchstwahrscheinlich der Kontakt zur Außenwelt unterbrochen, und falls es dennoch einen Kontakt herstellen kann, wird die IP unseres Servers nicht offengelegt. Daher erstellen wir einen weiteren Kasten, um Dienste wie .onion-Services und Proxy-Zugriffe ins Internet für separate Kästen zu ermöglichen.
# 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 setzen den Listenport auf die lokale Adresse (ist für alle Kästen zugänglich)
SOCKSPort 192.168.0.2:9050
Was fehlt uns noch zum vollsten Glück? Ja, wir brauchen einen Service für unser Web, vielleicht sogar mehrere. Wir starten nginx, der 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 so haben wir 150 MB Abhängigkeiten in den Kasten gepackt. Der Host bleibt jedoch sauber.
Wir kehren später zur nginx-Konfiguration zurück; wir müssen noch zwei Kästen für unser Zahlungsgateway auf nodejs und rust sowie eine Webanwendung, die aus unerklärlichen Gründen auf Apache und PHP basiert, aufbauen, und für diese letzte benötigen wir eine MySQL-Datenbank.
# 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
danach ziehen 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 in der Zelle.
hier geben wir dem Entwickler SSH-Zugang direkt in die Zelle, sie machen das selbst.
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — wir ändern den SSH-Port der Zelle auf einen beliebigen anderen
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Nun, der Dienst ist gestartet, es bleibt nur noch, eine Regel in den pf Firewall
Lass uns sehen, welche IPs unsere Zellen haben und wie unsere „lokale Umgebung“ 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
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 Bitcoins
Was haben wir — wir haben eine Webanwendung, die von außen zugänglich ist und lokal mit unserem Zahlungsgateway kommuniziert. Jetzt müssen wir die Arbeitsumgebung für die Interaktion mit dem Bitcoin-Netzwerk — Knoten vorbereiten bitcoind Dies ist nur ein Daemon, der eine lokale Kopie der aktuellen Blockchain unterstützt. Dieser Daemon verfügt über RPC und Wallet-Funktionalität, jedoch gibt es für die Anwendungsentwicklung bequemere „Wrapper“. Zunächst haben wir uns entschieden, electrum — eine CLI-Wallet. wird bei uns als „Cold Storage“ für unsere Bitcoins verwendet — also für die Bitcoins, die „außerhalb“ des für Benutzer zugänglichen Systems und generell von allem entfernt aufbewahrt werden sollen. Sie verfügt auch über eine GUI, deshalb planen wir, eine ähnliche Wallet auf unseren
Laptops zu nutzen. Zunächst werden wir Electrum mit öffentlichen Servern verwenden, und später in einer weiteren Umgebung , um vollkommen unabhängig zu sein.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
noch 700 MB Software in unserer Umgebung
electrum:/@[8:53] # adduser
Benutzername: wallet
Vollständiger Name:
Uid (Für Standard leer lassen):
Anmeldgruppe [wallet]:
Anmeldgruppe ist wallet. Wallet in andere Gruppen einladen? []:
Anmeldklasse [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Home-Verzeichnis [/home/wallet]:
Berechtigungen für das Home-Verzeichnis (Für Standard leer lassen):
Passwortbasierte Authentifizierung verwenden? [yes]: no
Konto nach Erstellung sperren? [no]:
Benutzername : wallet
Passwort :
Vollständiger Name :
Uid : 1001
Klasse :
Gruppen : wallet
Home : /home/wallet
Home-Modus :
Shell : /bin/tcsh
Gesperrt : no
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 Ihre Wallet nicht wiederherstellen.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "eifersüchtig win fleisch material bänder jung 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
Zu unserer on-chain Wallet haben künftig nur eine begrenzte Anzahl von Personen Zugang. Um den externen Zugang zu dieser Zelle nicht zu öffnen, erfolgt die Verbindung über SSH durch TOR (eine dezentrale VPN-Alternative). Wir starten in der Zelle SSH, lassen jedoch unser pf.conf auf dem Host unberührt.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Jetzt trennen wir die Wallet-Zelle vom Internet. Wir werden ihr eine IP-Adresse aus einem anderen Subnetz zuweisen, das nicht nat-ed wird. Zuerst ändern wir /etc/pf.conf auf dem Host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" ändern wir auf JAIL_IP_POOL="192.168.0.0/25", sodass alle Adressen 192.168.0.126-255 keinen direkten Zugang zum Internet haben werden. Eine Art softwarebasierter "air-gap"-Netzwerk. Und die NAT-Regel bleibt wie gehabt
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Regeln neu laden
# pfctl -f /etc/pf.conf
Nun kümmern wir uns um unsere Zelle
# 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.200Hm, aber jetzt wird auch das System selbst nicht mehr funktionieren. Wir können jedoch einen Systemproxy angeben. Aber es gibt einen Haken, auf TOR ist dies ein SOCKS5-Proxy, und zur Bequemlichkeit bräuchten wir auch noch 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
Nun haben wir in unserem System zwei Proxy-Server, und beide leiten über TOR: 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, der Shell wird jetzt über den Proxy arbeiten. Wenn wir Pakete installieren möchten, sollten wir in /usr/local/etc/pkg.conf aus dem Root-Container
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-Container 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 für die Verbindung. Lassen Sie uns von der lokalen Maschine aus ü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 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
Wir verbinden uns (Um dies zum Laufen zu bringen, ist ein lokaler TOR-Dienst notwendig, der auf 9050 hört)
user@local ~$ ssh remotebtc
Die Echtheit des Hosts 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<kein Host-IP für den Proxy-Befehl>)' kann nicht festgestellt werden.
ECDSA-Schlüsselfingerabdruck ist SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein/[Fingerabdruck])? 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 <genesis@istar.ca>
wallet@electrum:~ % logout
Erfolg!
Um mit Instant- und Mikropayments zu arbeiten, benötigen wir ebenfalls einen Node. , dies wird unser Hauptarbeitswerkzeug mit Bitcoin sein. Unser *, das wir als Daemon verwenden möchten, hat , das eine vollständige HTTP (REST)-Schnittstelle bietet und sowohl mit Off-Chain-Transaktionen als auch mit On-Chain-Transaktionen arbeitet. c-lightning für den Betrieb wird benötigt bitcoind ein Node.
*Es gibt verschiedene Implementierungen in verschiedenen Programmiersprachen des Lightning Network-Protokolls. Von den getesteten erschien c-lightning (in C geschrieben) als die 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 wir alles Notwendige kompilieren und installieren, 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 Wechseln zwischen den Zellen ist gar nicht so chaotisch, wenn man das Tool tmux, welches es ermöglicht, innerhalb eines einzelnen Sitzungsfensters mehrere Unter-Sitzungen zu erstellen. Ähnlich wie: screen
Okay, wir wollen die echte IP unserer Node nicht preisgeben und möchten alle finanziellen Transaktionen über TOR abwickeln. Daher benötigen wir noch ein weiteres .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 die 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-Knoten
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) etwa so aussehenlightning@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überprüfen
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]starten wir lightningd
lightning@lightning:~ % lightningd --daemon
Wine lightningd Die Dienstprogramme können verwaltet werden lightning-cli, zum Beispiel:
lightning-cli newaddr eine Adresse für eine neue eingehende Zahlung erhalten
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all alle Gelder des Wallets (von allen On-Chain-Adressen) auf die Adresse senden
Hier sind 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 eine REST-API
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Fassen wir zusammen
# 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 verfügen über eine Reihe von Containern, jeder mit seinem eigenen Zugriffslevel sowohl in als auch aus dem lokalen Netzwerk.
# zfs list
NAME VERBRAUCHT 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 Speicher von 190 GB. Was ist, wenn wir eine weitere Node für Tests benötigen? Hier kommt ZFS ins Spiel. Mit Hilfe von cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com kann ein Snapshot erstellt werden, und die neue Zelle kann an diesem Snapshot angekoppelt werden. Die neue Zelle hat ihren eigenen Speicher, aber im Dateisystem werden nur die Unterschiede zwischen dem aktuellen Zustand und dem Original berücksichtigt (wir sparen mindestens 190 GB).
Jede Zelle ist ein eigenes, separates ZFS-Dataset, und das ist äußerst praktisch. verschiedene andere coole Dinge tun, wie das Versenden von Snapshots über SSH. Wir werden nicht weiter darauf eingehen, es ist bereits viel gesagt worden.
Es ist auch wichtig, die Notwendigkeit der Remote-Überwachung des Hosts zu erwähnen. Für diese Zwecke haben wir .
B — Sicherheit
Was die Sicherheit betrifft, lassen Sie uns von den grundlegenden Prinzipien im Kontext der Infrastruktur ausgehen:
Vertraulichkeit — Standardwerkzeuge von UNIX-ähnlichen Systemen gewährleisten die Umsetzung dieses Prinzips. Wir teilen den Zugang logisch für jedes logisch separate Element des Systems — Zelle. Der Zugang erfolgt durch die standardmäßige Benutzerauthentifizierung mittels persönlicher Benutzer-Schlüssel. Alle Kommunikation zwischen und bis zu den Endzellen erfolgt verschlüsselt. Dank der Festplattverschlüsselung müssen wir uns keine Sorgen um den Schutz der Daten während des Festplattentauschs oder der Migration auf einen anderen Server machen. Der einzige kritische Zugang ist der Zugang zum Host-System, da dieser im Allgemeinen den 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 beachten, dass bei Serverhardware, ECC-RAM und ZFS bereits "out of the box" für die Datenintegrität auf Bit-Ebene gesorgt wird. Sofortige Snapshots ermöglichen eine jederzeitige Backup-Erstellung im laufenden Betrieb. Praktische Werkzeuge zum Exportieren und Importieren von Zellen erleichtern die Replikation von Zellen.
Verfügbarkeit — Dies ist bereits optional. Es hängt von Ihrem Bekanntheitsgrad und der Tatsache ab, ob Sie Feinde haben. In unserem Beispiel haben wir den Zugang zur Geldbörse ausschließlich aus dem TOR-Netzwerk bereitgestellt. Bei Bedarf kann man die Firewall so konfigurieren, dass alles blockiert wird und der Zugang zum Server ausschließlich über Tunnel (TOR oder VPN ist ein anderes Thema) erlaubt ist. Auf diese Weise wird der Server so gut wie möglich vom externen Umfeld abgeschnitten, und nur wir können die Verfügbarkeit beeinflussen.
Unabdingbarkeit — Das hängt von der weiteren Nutzung und der Beachtung der richtigen Richtlinien für Benutzerrechte, Zugriffsrechte usw. ab. Mit dem richtigen Ansatz werden alle Benutzeraktivitäten bei uns auditiert, und dank kryptografischer Lösungen kann eindeutig identifiziert werden, wer welche Aktionen wann durchgeführt hat.
Natürlich ist die beschriebene Konfiguration kein absoluter Beispiel dafür, wie es immer sein sollte. Es ist eher ein Beispiel dafür, wie es sein kann und gleichzeitig sehr flexible Möglichkeiten zur Skalierung und Anpassung bietet.
Und wie sieht es mit der vollständigen Virtualisierung aus?
Zur vollständigen Virtualisierung mit cbsd kann man Ich möchte nur hinzufügen, dass für die Funktionen bhyve einige Kernel-Parameter aktiviert werden müssen.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Wenn es also notwendig ist, Docker zu starten, verwenden wir ein Debian und legen los!
Das ist alles.
Das ist wohl alles, was ich teilen wollte. Wenn Ihnen der Artikel gefallen hat, können Sie mir Bitcoin schicken — . Wenn Sie die Zellen in Aktion ausprobieren möchten und ein wenig Bitcoin haben, können Sie mein .
Quelle: habr.com
