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 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).
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
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):
Jest
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
Następnie konfigurujemy aide
, monitorowanie stanu plików konfiguracyjnych systemu. Możesz przeczytać więcej szczegółów
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
sysrc auditd_enable=YES
# service auditd start
Sposób zarządzania tą sprawą doskonale opisano w
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
Kontenery? Znowu Docker czy co?
Ale nie. 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.
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 bhyve
w poniższym przykładzie.
Instalowanie i konfigurowanie środowiska hosta
Używamy FS
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
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 cbsd
i 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
Cóż... mamy zainstalowane cbsd, czas stworzyć naszego pierwszego konia pociągowego - demona Bitcoina w klatce!
cbsd jconstruct-tui
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.
laptopy. Na razie będziemy używać Electrum z serwerami publicznymi, a później będziemy go podnosić w innej komórce
# 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
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
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 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
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-cli
na 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
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.
Warto również zwrócić uwagę na potrzebę zdalnego monitorowania hosta, do tych celów mamy
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 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!
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 -
Źródło: www.habr.com