Bitcoin w klatce?

Tak się złożyło, że z zawodu jestem administratorem systemów i sieci komputerowych (w skrócie: administrator systemu), a prof. miałem okazję rozmawiać przez nieco ponad 10 lat. działanie szerokiej gamy systemów, w tym tych, które wymagają [skrajnych] środków bezpieczeństwa. Tak się też złożyło, że jakiś czas temu wydało mi się to interesujące bitcoin, i nie tylko go wykorzystałem, ale także uruchomiłem kilka mikrousług, aby nauczyć się samodzielnej pracy z siecią Bitcoin (w końcu p2p) z punktu widzenia programisty (ja jestem oczywiście jednym z tych dev, więc przechodziłem). Ale ja nie mówię o rozwoju, mówię o bezpiecznym i wydajnym środowisku dla aplikacji.

Technologia finansowa (FINTECH) przejdź obok bezpieczeństwa informacji (INFOSEC) i pierwszy może działać bez drugiego, ale nie na długo. Dlatego chcę podzielić się swoim doświadczeniem i zestawem narzędzi, z których korzystam, a który obejmuje jedno i drugie FINTECHI INFOSEC, a jednocześnie można je wykorzystać w szerszym lub zupełnie innym celu. W tym artykule opowiem Wam nie tyle o Bitcoinie, ile o modelu infrastrukturalnym rozwoju i obsługi usług finansowych (i nie tylko) – słowem tych usług, w których liczy się „B”. Dotyczy to zarówno giełdy Bitcoin, jak i najbardziej typowego korporacyjnego zoo usług małej firmy niezwiązanej w żaden sposób z Bitcoinem.

Pragnę zaznaczyć, że jestem zwolennikiem zasad „utrzymuj to głupio proste” и "mniej znaczy więcej"dlatego zarówno artykuł, jak i to, co jest w nim opisane, będą miały właściwości, o których mowa w tych zasadach.

Wyimaginowany scenariusz: Przyjrzyjmy się wszystkiemu na przykładzie wymiennika bitcoin. Postanowiliśmy uruchomić wymianę rubli, dolarów, euro na bitcoiny i z powrotem i mamy już działające rozwiązanie, ale na inne cyfrowe pieniądze, takie jak qiwi i webmoney, czyli tzw. Zamknęliśmy wszelkie kwestie prawne, posiadamy gotową aplikację służącą jako bramka płatnicza dla rubli, dolarów i euro oraz innych systemów płatności. Jest połączony z naszymi kontami bankowymi i posiada pewnego rodzaju API dla naszych aplikacji końcowych. Mamy też aplikację internetową, która pełni funkcję wymiennika dla użytkowników, no cóż, jak typowe konto qiwi czy webmoney – załóż konto, dodaj kartę i tak dalej. Komunikuje się z naszą aplikacją bramy, aczkolwiek lokalnie za pośrednictwem interfejsu API REST. Postanowiliśmy więc połączyć bitcoiny i jednocześnie unowocześnić infrastrukturę, ponieważ... Początkowo wszystko było umieszczane w pośpiechu na wirtualnych skrzynkach w biurze pod stołem... strona zaczęła być używana, a my zaczęliśmy martwić się o czas pracy i wydajność.

Zacznijmy więc od najważniejszej rzeczy - wyboru serwera. Ponieważ firma w naszym przykładzie jest mała i ufamy wybranemu przez nas hosterowi (OVH). opcja budżetowa w którym nie da się zainstalować systemu z oryginalnego obrazu .iso, ale to nie ma znaczenia, dział bezpieczeństwa IT na pewno przeanalizuje zainstalowany obraz. A kiedy dorośniemy, wynajmiemy własną szafę pod kluczem i z ograniczonym fizycznym dostępem, a może zbudujemy własne DC. W każdym razie warto pamiętać, że wynajmując sprzęt i instalując gotowe obrazy, istnieje ryzyko, że w Twoim systemie wisi „Trojan z hostera”, który w większości przypadków nie ma na celu Cię szpiegować ale aby zaoferować wygodniejszy serwer narzędzi do zarządzania.

Instalacja serwera

Tutaj wszystko jest proste. Wybieramy sprzęt odpowiadający naszym potrzebom. Następnie wybierz obraz FreeBSD. Cóż, albo łączymy się (w przypadku innego hosta i własnego sprzętu) przez IPMI lub z monitorem i pobieramy obraz .iso FreeBSD. Do konfiguracji orkiestrowej, której używam Wiarygodne и mfsbsd. Jedyne, co w naszym przypadku kimsufi wybraliśmy instalacja niestandardowa aby dwa dyski w kopii lustrzanej miały „otwarte” tylko partycje boot i /home, reszta miejsca na dysku zostanie zaszyfrowana, ale o tym później.

Bitcoin w klatce?

Instalacja systemu odbywa się w sposób standardowy, nie będę się nad tym rozwodzić, zaznaczę tylko, że przed rozpoczęciem pracy warto zwrócić uwagę hartowanie opcji, które oferuje bsdinstaller na koniec instalacji (jeśli instalujesz system samodzielnie):

Bitcoin w klatce?

Jest dobry materiał w tym temacie, krótko go tutaj powtórzę.

Możliwe jest także włączenie powyższych parametrów na już zainstalowanym systemie. Aby to zrobić, musisz edytować plik bootloadera i włączyć parametry jądra. *ee jest takim edytorem w 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

Powinieneś także upewnić się, że masz zainstalowaną najnowszą wersję systemu oraz wykonaj wszystkie aktualizacje i uaktualnienia. W naszym przypadku wymagana jest np. aktualizacja do najnowszej wersji, ponieważ... obrazy przed instalacją są opóźnione o sześć miesięcy do roku. Cóż, tam zmieniamy port SSH na inny niż domyślny, dodajemy uwierzytelnianie kluczem i wyłączamy uwierzytelnianie hasłem.

Następnie konfigurujemy aide, monitorowanie stanu plików konfiguracyjnych systemu. Możesz przeczytać więcej szczegółów tutaj.

pkg install aide

i edytuj nasz plik 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

Zawieramy audyt systemu

sysrc auditd_enable=YES

# service auditd start

Sposób zarządzania tą sprawą doskonale opisano w przewodnik.

Teraz uruchamiamy ponownie komputer i przechodzimy do oprogramowania na serwerze. Każdy serwer jest hiperwizorem dla kontenerów lub pełnych maszyn wirtualnych. Dlatego ważne jest, aby procesor obsługiwał VT-x i EPT, jeśli planujemy zastosować pełną wirtualizację.

Do zarządzania kontenerami i maszynami wirtualnymi używam cbsd od olewol, życzę mu więcej zdrowia i błogosławieństw dla tego wspaniałego narzędzia!

Kontenery? Znowu Docker czy co?

Ale nie. Więzienia FreeBSD to doskonałe narzędzie do konteneryzacji, ale wspomniane cbsd do organizowania tych pojemników, zwanych komórkami.

Klatka jest niezwykle efektywnym rozwiązaniem przy budowie infrastruktury o różnorodnym przeznaczeniu, gdzie docelowo wymagana jest całkowita izolacja poszczególnych usług czy procesów. Zasadniczo jest to klon systemu hosta, ale nie wymaga pełnej wirtualizacji sprzętu. Dzięki temu zasoby nie są wydawane na „system operacyjny gościa”, a jedynie na wykonywaną pracę. Gdy komórki wykorzystywane są na potrzeby wewnętrzne, jest to bardzo wygodne rozwiązanie pozwalające na optymalne wykorzystanie zasobów – grupa komórek na jednym serwerze sprzętowym może, każda z osobna, w razie potrzeby korzystać z całego zasobu serwera. Biorąc pod uwagę, że zwykle różne podusługi wymagają dodatkowych. zasobów w różnym czasie, możesz wydobyć maksymalną wydajność z jednego serwera, jeśli odpowiednio zaplanujesz i zrównoważysz komórki pomiędzy serwerami. W razie potrzeby komórkom można również nadać ograniczenia dotyczące wykorzystywanego zasobu.

Bitcoin w klatce?

A co z pełną wirtualizacją?

Jak wiem, cbsd wspiera pracę bhyve i hiperwizory XEN. Tego drugiego nigdy nie używałem, ale pierwszy jest stosunkowo nowy hypervisor z FreeBSD. Przyjrzymy się przykładowi użycia bhyve w poniższym przykładzie.

Instalowanie i konfigurowanie środowiska hosta

Używamy FS ZFS. Jest to niezwykle potężne narzędzie do zarządzania przestrzenią serwerową. Dzięki ZFS można bezpośrednio budować macierze o różnych konfiguracjach z dysków, dynamicznie „na gorąco” rozszerzać przestrzeń, zmieniać martwe dyski, zarządzać migawkami i wiele, wiele więcej, które można opisać w całym cyklu artykułów. Wróćmy do naszego serwera i jego dysków. Na początku instalacji pozostawiliśmy wolne miejsce na dyskach na zaszyfrowane partycje. Dlaczego? Dzieje się tak, aby system automatycznie się wybudzał i nasłuchiwał poprzez SSH.

gpart add -t freebsd-zfs /dev/ada0

/dev/ada0p4 added!

dodaj partycję dysku do pozostałego miejsca

geli init /dev/ada0p4

wprowadź nasze hasło szyfrowania

geli attach /dev/ada0p4

Wpisujemy ponownie hasło i mamy urządzenie /dev/ada0p4.eli - to nasza zaszyfrowana przestrzeń. Następnie powtarzamy to samo dla /dev/ada1 i pozostałych dysków w macierzy. I tworzymy nowy Basen ZFS.

zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - Cóż, mamy gotowy minimalny zestaw bojowy. Lustrzana macierz dysków na wypadek awarii jednego z trzech.

Tworzenie zbioru danych w nowej „puli”

zfs create vms/jails

pkg install cbsd — uruchomiliśmy zespół i ustaliliśmy zarządzanie naszymi komórkami.

Później cbsd zainstalowany, należy go zainicjować:

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

Cóż, odpowiadamy na wiele pytań, głównie z odpowiedziami domyślnymi.

*Jeśli używasz szyfrowania, ważne jest, aby demon cbsdd nie uruchomił się automatycznie, dopóki nie odszyfrujesz dysków ręcznie lub automatycznie (w naszym przykładzie robi to zabbix)

**Ja również nie używam NAT-a cbsdi sam go konfiguruję w 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 for jails
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

## Bitcoin network port forward
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

Konfigurowanie zasad zapory sieciowej to także osobny temat, więc nie będę się zagłębiał w konfigurowanie polityki BLOKUJ WSZYSTKIE i konfigurowanie białych list, możesz to zrobić czytając oficjalna dokumentacja lub którykolwiek z ogromnej liczby artykułów dostępnych w Google.

Cóż... mamy zainstalowane cbsd, czas stworzyć naszego pierwszego konia pociągowego - demona Bitcoina w klatce!

cbsd jconstruct-tui

Bitcoin w klatce?

Tutaj widzimy okno dialogowe tworzenia komórki. Po ustawieniu wszystkich wartości twórzmy!

Tworząc pierwszą komórkę, powinieneś wybrać, co będzie podstawą dla komórek. Za pomocą polecenia wybieram dystrybucję z repozytorium FreeBSD repo. Wyboru tego dokonuje się tylko podczas tworzenia pierwszej komórki określonej wersji (można hostować komórki dowolnej wersji, która jest starsza niż wersja hosta).

Po zamontowaniu wszystkiego odpalamy klatkę!

# cbsd jstart bitcoind

Ale musimy zainstalować oprogramowanie w klatce.

# jls

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

jexec bitcoind aby dostać się do konsoli komórkowej

i już wewnątrz komórki instalujemy oprogramowanie wraz z jego zależnościami (nasz system hosta pozostaje czysty)

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

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

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

W klatce znajduje się Bitcoin, ale potrzebujemy anonimowości, ponieważ chcemy połączyć się z niektórymi klatkami za pośrednictwem sieci TOP. Ogólnie rzecz biorąc, większość komórek z podejrzanym oprogramowaniem planujemy uruchamiać wyłącznie za pośrednictwem serwera proxy. Dzięki pf Możesz wyłączyć NAT dla określonego zakresu adresów IP w sieci lokalnej i zezwolić na NAT tylko dla naszego węzła TOR. Zatem nawet jeśli złośliwe oprogramowanie przedostanie się do komórki, najprawdopodobniej nie będzie komunikować się ze światem zewnętrznym, a jeśli tak się stanie, nie ujawni adresu IP naszego serwera. Dlatego tworzymy kolejną komórkę, aby „przekazywać” usługi jako usługę „.onion” i jako proxy dostępu do Internetu do poszczególnych komórek.

# 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

Ustaw nasłuchiwanie pod adresem lokalnym (dostępne dla wszystkich komórek)

SOCKSPort 192.168.0.2:9050

Czego jeszcze potrzeba do pełnego szczęścia? Tak, potrzebujemy usługi dla naszej sieci, może więcej niż jednej. Uruchommy nginx, który będzie działał jako odwrotne proxy i zajmie się odnawianiem certyfikatów Let's Encrypt

# cbsd jsconstruct-tui

# cbsd jstart nginx-rev

# jexec nginx-rev

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

I tak umieściliśmy 150 MB zależności w klatce. A gospodarz jest nadal czysty.

Wróćmy później do konfigurowania nginxa, musimy podnieść jeszcze dwie komórki dla naszej bramki płatniczej na nodejs i rust oraz aplikację internetową, która z jakiegoś powodu jest w Apache i PHP, a ta ostatnia również wymaga bazy danych MySQL.

# cbsd jsconstruct-tui

# cbsd jstart paygw

# jexec paygw

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

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

...i kolejne 380 MB izolowanych pakietów

Następnie pobieramy naszą aplikację za pomocą gita i uruchamiamy ją.

# cbsd jsconstruct-tui

# cbsd jstart webapp

# jexec webapp

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

Pakiety 450MB. w klatce.

tutaj dajemy programiście dostęp przez SSH bezpośrednio do komórki, oni tam wszystko zrobią sami:

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

Port 2267 — zmień port SSH komórki na dowolny

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

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

Cóż, usługa działa, pozostaje tylko dodać regułę pf zapora

Zobaczmy, jakie IP mają nasze komórki i jak ogólnie wygląda nasz „obszar lokalny”.

# jls

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

i dodaj regułę

# 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

Skoro już tu jesteśmy, dodajmy jeszcze regułę dla odwrotnego proxy:

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

# pfctl -f /etc/pf.conf

Cóż, teraz trochę o bitcoinach

Mamy aplikację internetową, która jest dostępna na zewnątrz i komunikuje się lokalnie z naszą bramką płatniczą. Teraz musimy przygotować środowisko pracy do interakcji z samą siecią Bitcoin – węzłem bitcoind jest to po prostu demon, który aktualizuje lokalną kopię łańcucha bloków. Ten demon ma funkcjonalność RPC i portfela, ale istnieją wygodniejsze „opakowania” do tworzenia aplikacji. Na początek postanowiliśmy umieścić electrum to portfel CLI. Ten portfel użyjemy go jako „zimni” dla naszych bitcoinów – ogólnie rzecz biorąc, tych bitcoinów, które będą musiały być przechowywane „poza” systemem dostępnym dla użytkowników i ogólnie z dala od wszystkich. Ma również GUI, więc będziemy używać tego samego portfela na naszym
laptopy. Na razie będziemy używać Electrum z serwerami publicznymi, a później będziemy go podnosić w innej komórce ElektroXżeby w ogóle nie być od nikogo zależnym.

# cbsd jsconstruct-tui

# cbsd jstart electrum

# jexec electrum

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

kolejne 700 MB oprogramowania w naszej klatce

electrum:/@[8:53] # adduser

Username: wallet
Full name: 
Uid (Leave empty for default): 
Login group [wallet]: 
Login group is wallet. Invite wallet into other groups? []: 
Login class [default]: 
Shell (sh csh tcsh nologin) [sh]: tcsh
Home directory [/home/wallet]: 
Home directory permissions (Leave empty for default): 
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]: 
Username   : wallet
Password   : <disabled>
Full Name  : 
Uid        : 1001
Class      : 
Groups     : wallet 
Home       : /home/wallet
Home Mode  : 
Shell      : /bin/tcsh
Locked     : no
OK? (yes/no): yes
adduser: INFO: Successfully added (wallet) to the user database.
Add another user? (yes/no): no
Goodbye!
electrum:/@[8:53] # su wallet

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

wallet@electrum:/ % electrum-3.6 create

{
    "msg": "Please keep your seed in a safe place; if you lose it, you will not be able to restore your wallet.",
    "path": "/usr/home/wallet/.electrum/wallets/default_wallet",
    "seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}

Teraz mamy utworzony portfel.

wallet@electrum:/ % electrum-3.6 listaddresses

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

wallet@electrum:/ % electrum-3.6 help

Do naszego na łańcuchu Od tej chwili z portfelem będzie mogła połączyć się tylko ograniczona liczba osób. Aby nie otwierać dostępu do tej komórki z zewnątrz, połączenia przez SSH będą odbywać się poprzez TOP (zdecentralizowaną wersję VPN). Uruchamiamy SSH w komórce, ale nie dotykamy naszego pf.conf na hoście.

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

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

Wyłączmy teraz komórkę z dostępem portfela do Internetu. Nadajmy mu adres IP z innej przestrzeni podsieci, która nie jest NATowana. Najpierw się zmieńmy /etc/pf.conf na gospodarzu

# ee /etc/pf.conf

JAIL_IP_POOL="192.168.0.0/24" zmieńmy to na JAIL_IP_POOL="192.168.0.0/25", tym samym wszystkie adresy 192.168.0.126-255 nie będą miały bezpośredniego dostępu do Internetu. Rodzaj programowej sieci „szczeliny powietrznej”. A zasada NAT pozostaje taka, jaka była

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

Przeciążanie reguł

# pfctl -f /etc/pf.conf

Zajmijmy się teraz naszą komórką

# cbsd jconfig jname=electrum

Bitcoin w klatce?

Bitcoin w klatce?

jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Remove old IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Setup new IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200

Hmm, ale teraz sam system przestanie nam działać. Możemy jednak określić systemowy serwer proxy. Ale jest jedno, na TOR jest to proxy SOCKS5, a dla wygody chcielibyśmy też proxy HTTP.

# cbsd jsconstruct-tui

# cbsd jstart polipo

# jexec polipo

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

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

socksParentProxy = "192.168.0.2:9050"
socksProxyType = socks5

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

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

Cóż, teraz w naszym systemie są dwa serwery proxy i oba wysyłają dane przez TOR: skarpetki5://192.168.0.2:9050 i http://192.168.0.6:8123

Teraz możemy skonfigurować środowisko naszego portfela

# 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

Cóż, teraz powłoka będzie działać z poziomu serwera proxy. Jeżeli chcemy zainstalować pakiety to powinniśmy dodać do /usr/local/etc/pkg.conf spod korzenia klatki

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

Cóż, teraz czas dodać ukrytą usługę TOR jako adres naszej usługi SSH w klatce portfela.

# 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

To jest nasz adres połączenia. Sprawdźmy na komputerze lokalnym. Ale najpierw musimy dodać nasz klucz SSH:

wallet@electrum:/ % mkdir ~/.ssh

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

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

Cóż, z komputera klienckiego z Linuksem

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

Połączmy się (Aby to zadziałało, potrzebujesz lokalnego demona TOR, który nasłuchuje na 9050)

user@local ~$ ssh remotebtc

The authenticity of host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) to the list of known hosts.
FreeBSD 12.1-RELEASE-p1 GENERIC 
To save disk space in your home directory, compress files you rarely
use with "gzip filename".
        -- Dru <[email protected]>
wallet@electrum:~ % logout

Powodzenie!

Do pracy z płatnościami natychmiastowymi i mikropłatnościami potrzebujemy również węzła Błyskawica sieciw rzeczywistości będzie to nasze główne narzędzie pracy z Bitcoinem. Ty*c-piorunktórego będziemy używać jako demona Wtyczka Sparko, który jest pełnoprawnym interfejsem HTTP (REST) ​​​​i pozwala na pracę zarówno z transakcjami poza łańcuchem, jak i w łańcuchu. c-lightning wymagane do funkcjonowania bitcoind ale tak.

*Istnieją różne implementacje protokołu Lightning Network w różnych językach. Spośród tych, które przetestowaliśmy, c-lightning (napisany w C) wydawał się najbardziej stabilny i zasobooszczędny

# cbsd jsconstruct-tui

# cbsd jstart cln

# jexec cln

lightning:/@[10:23] # adduser

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

Gdy wszystko, co niezbędne, zostało skompilowane i zainstalowane, utwórzmy użytkownika RPC dla lightningd в bitcoind

# jexec bitcoind

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

rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#allow only c-lightning
rpcallowip=192.168.0.7/32

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

Moje chaotyczne przełączanie między komórkami okazuje się nie tak chaotyczne, jeśli zwrócisz uwagę na narzędzie tmux, co pozwala na utworzenie wielu podsesji terminala w ramach jednej sesji. Analog: screen

Bitcoin w klatce?

Nie chcemy więc ujawniać prawdziwego adresu IP naszego węzła, a wszystkie transakcje finansowe chcemy przeprowadzać poprzez TOP. Dlatego kolejna cebula nie jest potrzebna.

# 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

Stwórzmy teraz konfigurację dla c-lightning

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

lightning@lightning:~ % mkdir .lightning

lightning@lightning:~ % ee .lightning/config

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

# 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
# for the example above the initialization logs (mixed with lightningd logs) should print something like

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 ~

musisz także utworzyć plik konfiguracyjny dla bitcoin-cli, narzędzia, z którym się komunikuje bitcoind

lightning@lightning:~ % mkdir .bitcoin

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

rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test

kontrola

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

[
  "test"
]

początek lightningd

lightning@lightning:~ % lightningd --daemon

Strona lightningd możesz kontrolować narzędzie lightning-clina przykład:

lightning-cli newaddr uzyskać adres nowej płatności przychodzącej

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

lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all wyślij wszystkie pieniądze z portfela na adres (wszystkie adresy w łańcuchu)

Również polecenia dotyczące operacji poza łańcuchem lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay itd.

Otóż ​​do komunikacji z aplikacją mamy API REST

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

Zsumować

# jls

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

Bitcoin w klatce?

Mamy zestaw kontenerów, każdy z własnym poziomem dostępu zarówno z, jak i do sieci lokalnej.

# zfs list

NAME                    USED  AVAIL  REFER  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

Jak widać, bitcoind zajmuje całe 190 GB miejsca. A co jeśli będziemy potrzebować kolejnego węzła do testów? Tutaj z pomocą przychodzi ZFS. Z pomocą cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com możesz utworzyć migawkę i dołączyć do niej nową komórkę. Nowa komórka będzie miała własne miejsce, ale w systemie plików uwzględniona zostanie jedynie różnica pomiędzy stanem bieżącym a oryginałem (zaoszczędzimy co najmniej 190 GB)

Każda komórka stanowi odrębny zbiór danych ZFS, co jest niezwykle wygodne. ZFS również pozwala rób różne inne fajne rzeczy, takie jak wysyłanie migawek przez SSH. Nie będziemy tego opisywać, jest tego już sporo.

Warto również zwrócić uwagę na potrzebę zdalnego monitorowania hosta, do tych celów mamy Zabbix.

B - bezpieczeństwo

Jeśli chodzi o bezpieczeństwo, zacznijmy od kluczowych zasad w kontekście infrastruktury:

Prywatność - Standardowe narzędzia systemów typu UNIX zapewniają realizację tej zasady. Logicznie oddzielamy dostęp do każdego logicznie wyodrębnionego elementu systemu – komórki. Dostęp zapewniany jest poprzez standardową autoryzację użytkownika przy użyciu kluczy osobistych użytkownika. Cała komunikacja między komórkami końcowymi i do nich odbywa się w formie zaszyfrowanej. Dzięki szyfrowaniu dysku nie musimy martwić się o bezpieczeństwo danych podczas wymiany dysku lub migracji na inny serwer. Jedynym krytycznym dostępem jest dostęp do systemu hosta, ponieważ taki dostęp zazwyczaj zapewnia dostęp do danych znajdujących się w kontenerach.

Uczciwość „Realizacja tej zasady odbywa się na kilku różnych poziomach. Na początek warto zaznaczyć, że w przypadku sprzętu serwerowego, pamięci ECC, ZFS już „od razu po wyjęciu z pudełka” dba o integralność danych na poziomie bitów informacyjnych. Natychmiastowe migawki umożliwiają tworzenie kopii zapasowych w dowolnym momencie na bieżąco. Wygodne narzędzia do eksportu/importu komórek ułatwiają replikację komórek.

Dostępność - To jest już opcjonalne. Zależy od stopnia twojej sławy i tego, że masz hejterów. W naszym przykładzie zadbaliśmy o to, aby portfel był dostępny wyłącznie z sieci TOP. W razie potrzeby możesz zablokować wszystko na zaporze i zezwolić na dostęp do serwera wyłącznie przez tunele (TOR lub VPN to inna sprawa). Tym samym serwer zostanie maksymalnie odcięty od świata zewnętrznego i tylko my sami będziemy mogli wpłynąć na jego dostępność.

Niemożność odmowy - A to zależy od dalszego działania i przestrzegania odpowiednich polityk dotyczących praw użytkowników, dostępu itp. Jednak przy właściwym podejściu wszystkie działania użytkownika podlegają audytowi, a dzięki rozwiązaniom kryptograficznym można jednoznacznie zidentyfikować, kto i kiedy wykonał określone czynności.

Oczywiście opisana konfiguracja nie jest absolutnym przykładem tego, jak zawsze powinno być, jest raczej przykładem tego, jak może być, zachowując jednocześnie bardzo elastyczne możliwości skalowania i dostosowywania.

A co z pełną wirtualizacją?

O pełnej wirtualizacji za pomocą cbsd można przeczytaj tutaj. Dodam to tylko do pracy bhyve Musisz włączyć niektóre opcje jądra.

# cat /etc/rc.conf

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

# cat /boot/loader.conf

...
vmm_load="YES"
...

Jeśli więc nagle zajdzie potrzeba uruchomienia okna dokowanego, zainstaluj Debiana i śmiało!

Bitcoin w klatce?

To wszystko

To chyba wszystko, czym chciałem się podzielić. Jeśli spodobał Ci się ten artykuł, możesz wysłać mi trochę bitcoinów - bc1qu7lhf45xw83ddll5mnzte6ahju8ktkeu6qhttc. Jeśli chcesz wypróbować komórki w akcji i mieć trochę bitcoinów, możesz przejść do mojego projekt zwierzaka.

Źródło: www.habr.com