Din întâmplare, eu sunt administrator de sisteme și rețele computerizate (pe scurt: sysadmin) și am avut ocazia să lucrez timp de mai bine de 10 ani cu cele mai variate sisteme, inclusiv cele care necesită măsuri de securitate [po|pentru] siguranță. De asemenea, s-a întâmplat că, cu ceva timp în urmă, am descoperit că este interesant , și nu m-am limitat doar la utilizarea lui, ci am lansat câteva micro-servicii pentru a învăța să lucrez singur cu rețeaua bitcoin (dat fiind că este p2p) din perspectiva dezvoltatorului (desigur, nu sunt un începător adevărat dev, ci am trecut pe acolo). Dar nu vorbesc despre dezvoltare, ci despre un mediu sigur și eficient pentru aplicații.
Tehnologiile financiare (fintech) merg mână în mână cu securitatea informațională (infosec) și primul fără al doilea poate funcționa, dar nu pentru mult timp. De aceea vreau să împărtășesc experiența mea și setul de instrumente pe care le folosesc, care include atât fintech, sau infosec, în același timp, cât și poate fi utilizat într-un scop mai larg sau complet diferit. În acest articol nu vreau să vorbesc atât despre bitcoin, cât despre modelul de infrastructură pentru dezvoltarea și operarea serviciilor financiare (și nu numai) - în cuvinte simple, acele servicii unde „B” contează. Acest lucru se aplică atât unei burse de bitcoin, cât și întregului „zoologic” de servicii al unei mici companii care nu are legătură cu bitcoin.
Vreau să subliniez că susțin principiile „keep it stupid simple” și „less is more”, prin urmare atât articolul, cât și ceea ce este descris în el vor avea caracteristici conform acestor principii.
Scenariul imaginar: Să analizăm totul prin exemplul unui schimb de bitcoin. Am decis să lansăm un schimb de ruble, dolari, euro în bitcoin și invers, iar noi deja avem o soluție operațională, dar pentru alte monede digitale precum Qiwi și WebMoney, adică am rezolvat toate problemele juridice, dispunem de o aplicație gata care funcționează ca un gateway de plată pentru ruble, dolari și euro și alte sisteme de plată. Este conectată la conturile noastre bancare și are un API pentru aplicațiile noastre finale. De asemenea, avem o aplicație web care funcționează ca un schimb pentru utilizatori, asemănătoare unui tipic cabinet Qiwi sau WebMoney - creați un cont, adăugați un card și așa mai departe. Aceasta comunică cu aplicația noastră-gateway, să zicem pe REST API în rețeaua locală. Și, astfel, am decis să integrăm bitcoin și în același timp să facem upgrade la infrastructură, deoarece inițial totul a fost ridicat în grabă pe VirtualBox-uri sub birou… site-ul a început să fie utilizat, iar noi am început să ne îngrijorăm pentru uptime și performanță.
Așadar, să începem cu esențialul - alegerea serverului. Deoarece afacerea din exemplul nostru este mică și avem încredere în gazda (OVH), vom alege în care nu se poate instala un sistem dintr-o imagine originală .iso, dar nu e o problemă, echipa de securitate IT va efectua cu siguranță o analiză a imaginii instalate. Iar când ne vom dezvolta, chiar vom închiria un dulap sub control strict și cu acces fizic limitat, sau poate chiar vom construi un centru de date propriu. În orice caz, este important de reținut că, atunci când închiriați hardware și instalați imagini gata făcute, există riscul ca în sistemul dumneavoastră să existe un „troian de la gazdă”, care în cele mai multe cazuri nu este destinat urmăririi dumneavoastră, ci pentru a oferi instrumente mai convenabile de gestionare a serverului.
Instalarea serverului
Aici totul este simplu. Alegem hardware-ul care se potrivește nevoilor noastre. Apoi selectăm imaginea FreeBSD. Sau ne conectăm (în cazul altei gazde și a hardware-ului propriu) prin IPMI sau cu un monitor și furnizăm imaginea .iso FreeBSD pentru încărcare. Pentru instalarea orchestrală eu folosesc și . Singura excepție, în cazul nostru cu Kimsufi, este că am ales instalare personalizată pentru ca cele două discuri din mirror să aibă „deschise” doar partițiile de sistem și /home, restul spațiului pe disc va fi criptat, dar despre asta mai târziu.
Instalarea sistemului se desfășoară în mod standard, nu mă voi opri asupra acestui aspect, ci voi sublinia că înainte de a începe utilizarea, merită să acordați atenție hardenării opțiunilor pe care le oferă bsdinstaller la finalul instalării (dacă instalați sistemul singur):
Există pe această temă; în linii mari, îl voi repeta aici.
Activarea parametrilor menționați anterior este posibilă și pe un sistem deja instalat. Pentru aceasta, trebuie să editați fișierul de boot și să activați parametrii nucleului. *ee este un editor în 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=1De asemenea, este important să vă asigurați că aveți instalată cea mai recentă versiune a sistemului și . În cazul nostru, de exemplu, este necesar un upgrade la cea mai recentă versiune, deoarece imaginile preinstalate sunt cu până la șase luni - un an în spate. Și acolo schimbăm portul SSH cu unul diferit de cel implicit, adăugăm autentificarea pe bază de chei și dezactivăm autentificarea prin parolă.
Apoi configurăm aide, monitorizarea stării fișierelor de configurare ale sistemului. Puteți citi mai detaliat .
pkg install aide
și edităm crontabul nostru
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/$MYFILENAMEActivăm
sysrc auditd_enable=YES
# service auditd start
Cum se administrează acest proces este bine descris în .
Acum repornim și ne apucăm de software pe server. Fiecare server reprezintă un hipervizor pentru containere sau mașini virtuale complete. Prin urmare, este important ca procesorul să suporte VT-x și EPT dacă plănuim să folosim virtualizarea completă.
Ca manager de containere și mașini virtuale, folosesc de la , îi doresc multă sănătate și binecuvântări pentru această utilitate minunată!
Containere? Din nou docker, nu-i așa?
Dar nu. este un instrument excelent pentru containerizare, iar cel menționat cbsd este pentru orchestrarea acestor containere, al cărui nume este - cuști.
Celula este o soluție foarte eficientă pentru construirea infrastructurii pentru diverse scopuri, unde este necesară o izolare completă a serviciilor sau proceselor separate. Practic, este un clon al sistemului gazdă, dar nu necesită virtualizare completă a hardware-ului. Astfel, resursele nu se consumă pe un „OS gazdă”, ci doar pe muncă efectuată. Atunci când celulele sunt utilizate pentru nevoile interne, aceasta reprezintă o soluție foarte convenabilă pentru utilizarea optimă a resurselor — multe celule pe un singur server fizic pot folosi fiecare resursa serverului, atunci când este necesar. Având în vedere că, de obicei, diferitele subservicii au nevoie de resurse suplimentare în momente diferite, se poate obține o performanță maximă dintr-un server, dacă celulele sunt planificate și distribuite corespunzător între servere. Dacă este necesar, celulelor li se pot impune și limite în ceea ce privește resursele utilizate.
Dar ce este cu virtualizarea completă?
Cât știu eu, cbsd susține funcționarea bhyve și hipervizoarele XEN. Nu am folosit niciodată al doilea, dar primul este un hipervizor relativ tânăr . Vom analiza un exemplu de utilizare bhyve în exemplul de mai jos.
Instalarea și configurarea mediului gazdă
Folosim sistemul de fișiere . Acesta este un instrument extrem de puternic pentru gestionarea spațiului pe server. Datorită ZFS, putem construi array-uri de diferite configurații direct din discuri, extinde dinamic spațiul „la cald”, schimba discurile defecte, gestiona instantanee și multe alte lucruri care ar putea fi descrise într-o întreagă serie de articole. Să ne întoarcem la serverul nostru și la discurile sale. La începutul instalării, am lăsat spațiu liber pe discuri pentru partiții criptate. De ce? Pentru ca sistemul să se pornească automat și să asculte prin SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
adăugăm o partiție pe disc pentru spațiul rămas
geli init /dev/ada0p4
introducem parola noastră de criptare
geli attach /dev/ada0p4
introducem din nou parola și ne apare dispozitivul /dev/ada0p4.eli — acesta este spațiul nostru criptat. Apoi repetăm aceeași procedură pentru /dev/ada1 și celelalte discuri din array. Și creăm un nou .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — iată, avem setul minim în funcțiune gata. Un array de discuri mirror în caz de defectare a unuia dintre cele trei.
Creăm un dataset pe un nou „pool”
zfs create vms/jails
pkg install cbsd — am lansat comanda și instalăm managementul pentru celulele noastre.
După ce cbsd este instalat, trebuie să-l inițializăm:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
iar apoi răspundem la o mulțime de întrebări, în principal cu răspunsuri implicite.
*Dacă folosiți criptarea, este important ca demonul cbsdd să nu pornească automat, până când nu decriptați manual sau automat unitățile (în exemplul nostru, acest lucru este realizat de zabbix)
**De asemenea, nu folosesc NAT de la cbsd, ci îl configurez singur în 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 pentru celule
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Port de reținere pentru rețeaua Bitcoin
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
Configurarea politicilor de firewall este, de asemenea, un subiect separat, așa că nu voi aprofunda setările politicii BLOCK ALL și configurările listelor albe, aceste informații pot fi găsite citind sau oricare dintre numeroasele articole disponibile pe Google.
Ei bine… am instalat cbsd, este timpul să creăm prima noastră „caietă de lucru” — demonul Bitcoin într-o celulă!
cbsd jconstruct-tui
Aici vedem dialogul de creare a celulei. După ce am setat toate valorile, creăm!
La crearea primei celule, trebuie să alegem ce să folosim ca bază pentru celule. Eu aleg distribuția din repository-ul FreeBSD cu comanda repo. Această alegere se face doar la crearea primei celule pentru o versiune specifică (putem găzdui celule din orice versiune care este mai recentă decât versiunea gazdelor).
După ce totul este instalat — lansăm celula!
# cbsd jstart bitcoind
Dar trebuie să instalăm software-ul în celulă.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind pentru a accesa consola celulei
și deja în interiorul celulei instalăm software-ul cu dependențele sale (sistemul nostru gazdă rămâne curat)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoinul este în celulă, dar avem nevoie de anonimat, deoarece dorim să ne conectăm la unele celule prin rețeaua TOR. Și de fapt, planificăm să rulăm majoritatea celulelor cu software suspect doar prin proxy. Datorită pf putem dezactiva NAT pentru un anumit interval de adrese IP în rețeaua locală și permite NAT doar pentru nodul nostru TOR. Astfel, chiar dacă un malware ajunge în celulă, este foarte probabil să nu iasă în lume, iar dacă o face, nu își va divulga IP-ul serverului nostru. Prin urmare, creăm o altă celulă pentru „redirecționarea” serviciilor ca serviciu „.onion” și ca un proxy pentru a ieși pe internet pentru celulele separate.
# 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
Setăm să asculte pe adresa locală (disponibil pentru toate celulele)
SOCKSPort 192.168.0.2:9050
Ce ne mai lipsește pentru fericirea completă? Da, avem nevoie de un serviciu pentru web-ul nostru, poate mai multe. Vom lansa nginx, care va juca rolul unui reverse-proxy și se va ocupa de extinderea certificatelor Let’s Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:@[15:47] # pkg install nginx py36-certbot
Și astfel am adăugat 150 MB de dependențe în celulă. Iar gazda rămâne curată.
Vom reveni la configurarea nginx mai târziu, trebuie să ridicăm încă două celule pentru gateway-ul nostru de plăți pe nodejs și rust și aplicația web, care din diverse motive funcționează pe apache și php, iar pentru aceasta avem nevoie și de o bază de date 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 încă 380 MB de pachete sunt izolate
Apoi, vom descărca aplicația noastră cu git și o vom lansa.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB de pachete. în celulă.
aici dăm acces dezvoltatorului prin SSH direct în celulă; ei se vor ocupa de tot:
webapp:@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — schimbăm portul SSH al celulei pe orice port aleatoriu
webapp:@[16:02] # sysrc sshd_enable=YES
webapp:@[16:02] # service sshd start
Așa, serviciul a fost lansat, rămâne să adăugăm o regulă în pf firewall
Să vedem ce IP-uri avem pentru celule și cum arată de fapt rețeaua noastră locală
# 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 vom adăuga o regulă
# 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
având în vedere că suntem aici, să adăugăm și o regulă pentru reverse-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
Acum, puțin despre bitcoin
Ce avem — avem o aplicație web, care este accesibilă din exterior, și aceasta comunică local cu gateway-ul nostru de plăți. Acum trebuie să pregătim un mediu de lucru pentru interacțiunea cu rețeaua bitcoin — nodul bitcoind acesta este doar un demon care menține o copie locală a blockchain-ului actual. Acest demon are RPC și funcționalitate de portofel, totuși pentru dezvoltarea aplicațiilor există „wrapper”-e mai convenabile. Pentru început, am decis să instalăm electrum — este un portofel CLI. va fi folosit ca „stocare la rece” pentru bitcoin-ii noștri — în general, acei bitcoin care trebuie păstrați „în afara” sistemului accesibil utilizatorilor și, în general, departe de toți. De asemenea, are GUI, astfel încât același portofel îl vom folosi pe
laptopurile noastre. Deocamdată vom folosi Electrum cu servere publice, iar mai târziu într-o altă carantină vom ridica , astfel încât să nu depindem de nimeni.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum: /@[8:45] # pkg install py36-electrum
încă 700 MB de software avem în carantină
electrum: /@[8:53] # adduser
Nume utilizator: wallet
Numele complet:
Uid (Lăsați gol pentru implicit):
Grupa de conectare [wallet]:
Grupa de conectare este wallet. Invitați wallet în alte grupuri? []:
Clasa de conectare [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Directoriul home [ /home /wallet]:
Permisiunile directorului home (Lăsați gol pentru implicit):
Folosiți autentificarea bazată pe parolă? [da]: nu
Blochează contul după creare? [nu]:
Nume utilizator : wallet
Parola :
Numele complet :
Uid : 1001
Clasă :
Grupuri : wallet
Home : /home /wallet
Mod home :
Shell : /bin /tcsh
Blocat : nu
OK? (da /nu): da
adduser: INFO: Adăugat cu succes (wallet) în baza de date a utilizatorilor.
Adăugați un alt utilizator? (da /nu): nu
La revedere!
electrum: /@[8:53] # su walletelectrum: /@[8:53] # su wallet
wallet@electrum: / % electrum-3.6 create
{
"msg": "Vă rugăm să păstrați seed-ul într-un loc sigur; dacă îl pierdeți, nu veți putea să vă recuperați portofelul.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "gelos câine material panglică tânăr lovitură vizual bine cactus aleatoriu pasăre"
}Iată că acum avem un portofel creat.
wallet@electrum: / % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum: / % electrum-3.6 help
Către portofelul nostru on-chain vor putea conecta la el doar un cerc restrâns de persoane. Pentru a nu deschide accesul extern în această carantină, conexiunile SSH vor fi realizate prin TOR (o variantă descentralizată de VPN). Activăm SSH în carantină, dar nu atingem pf.conf-ul nostru pe gazdă.
electrum: /@[9:00] # sysrc sshd_enable=YES
electrum: /@[9:00] # service sshd start
Acum vom dezactiva conexiunea la internet pentru carantina cu portofelul. Vom seta o adresă IP dintr-un alt spațiu de subrețea, care nu este NAT-uit. Mai întâi vom schimba /etc/pf.conf pe gazdă
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" vom schimba în JAIL_IP_POOL="192.168.0.0/25", astfel, toate adresele 192.168.0.126-255 nu vor avea acces direct la internet. O rețea de tip „air-gap” software. Iar regula NAT rămâne la fel.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Reîncărcăm regulile
# pfctl -f /etc/pf.conf
Acum ne ocupăm de celula noastră
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Șterge ip-ul vechi: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Setează noul IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, dar acum sistemul nostru va înceta să funcționeze. Totuși, putem specifica un proxy sistemic. Dar este o problemă, pe TOR este un proxy SOCKS5, iar pentru comoditate ar fi util și un 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 = socks5polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Ei bine, acum avem două servere proxy în sistemul nostru, ambele ieșind prin TOR: socks5://192.168.0.2:9050 și
Acum putem să configurăm mediu pentru portofelul nostru
# 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:8123Ei bine, acum shell-ul va funcționa prin proxy. Dacă vrem să instalăm pachete, ar fi bine să adăugăm în /usr/local/etc/pkg.conf din dreptul root-ului celulei
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Acum a venit vremea să adăugăm serviciul ascuns TOR ca adresă pentru serviciul nostru SSH în celula portofelului.
# 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.onionIată adresa noastră pentru conectare. Să verificăm din mașina locală. Dar mai întâi trebuie să adăugăm cheia noastră SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localȘi de pe mașina client Linux
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
Ne conectăm (Pentru ca acest lucru să funcționeze, este necesar un demon local TOR care ascultă pe 9050)
user@local ~$ ssh remotebtc
Autenticitatea gazdei 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' nu poate fi stabilită.
Amprenta cheii ECDSA este SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Ești sigur că dorești să continui conectarea (yes/no/[fingerprint])? yes
Atenție: 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) a fost adăugat permanent la lista gazdelor cunoscute.
FreeBSD 12.1-RELEASE-p1 GENERIC
Pentru a salva spațiu pe disc în directorul tău acasă, comprimă fișierele pe care le folosești rar cu "gzip filename".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Succes!
Pentru a lucra cu plăți instantanee și micro-plăți, avem nevoie și de un nod , acesta va fi instrumentul nostru principal de lucru cu Bitcoin. La *, pe care intenționăm să-l folosim ca demon, are , care este o interfață HTTP (REST) complet funcțională și permite lucrul atât cu tranzacții off-chain, cât și cu tranzacții on-chain. c-lightning pentru funcționare are nevoie de bitcoind nod.
*există diferite implementări ale protocolului Lightning Network în diverse limbaje de programare. Dintre cele pe care le-am testat, c-lightning (scris în C) s-a dovedit a fi cel mai stabil și eficient din punct de vedere al resurselor
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/@[10:23] # adduser
Nume de utilizator: 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
În timp ce se compilează și se instalează tot ce este necesar, vom crea un utilizator RPC pentru lightningd în bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#permitere doar c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Switching-ul meu haotic între celule se dovedește a nu fi chiar atât de haotic dacă marcăm utilitarul , demonul, care permite crearea de multiple sub-sesiuni de terminale într-o singură sesiune. Analog: screen
Deci, nu vrem să expunem IP-ul real al nodului nostru și dorim să efectuăm toate tranzacțiile financiare prin TOR. Așadar, avem nevoie de un alt .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.onionacum să creăm configurația pentru 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
# plugin sparko
# 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
# pentru exemplul de mai sus, logurile de inițializare (amestecate cu logurile lightningd) ar trebui să imprime ceva de genullightning@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 ~
trebuie să creezi și un fișier de configurare pentru bitcoin-cli, un utilitar care comunică cu bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testverificăm
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]pornim lightningd
lightning@lightning:~ % lightningd --daemon
Eu lightningd pot gestiona utilitarul lightning-cli, de exemplu:
lightning-cli newaddr obține o adresă pentru o nouă plată în incoming
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all trimite toate fondurile din portofel (toate adresele on-chain)
De asemenea, comenzi pentru operațiuni off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.
Iar pentru comunicarea cu aplicația, avem API REST
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Să rezumăm
# jls
JID Adresă IP Nume gazdă Cale
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
Avem un set de containere, fiecare cu nivelul său de acces atât în, cât și din rețeaua locală.
# zfs list
NUME UTILIZAT DISPONIBIL REFER PUNTE DE MONTARE
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-dataDupă cum se poate observa, bitcoind consumă tot spațiul de 190 GB. Și ce se întâmplă dacă avem nevoie de un alt nod pentru teste? Aici ZFS este de mare ajutor. Cu ajutorul cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Poți crea un snapshot și să legi o nouă celulă la acest snapshot. Noua celulă va avea complet propriul său spațiu, dar FS va lua în considerare doar diferența dintre starea curentă și original (economisind astfel cel puțin 190 GB).
Fiecare celulă este un set de date ZFS separat, și este extrem de convenabil. să faci diferite alte lucruri interesante, cum ar fi trimiterea snapshot-urilor prin SSH. Nu vom descrie asta, deja am spus destul.
De asemenea, merită menționată necesitatea monitorizării de la distanță a host-ului, pentru aceste scopuri avem .
B — securitate
În ceea ce privește securitatea, să ne bazăm pe principiile de bază în contextul infrastructurii:
Confidențialitate — Instrumentele standard ale sistemelor UNIX-like asigură respectarea acestui principiu. Separăm logic accesul la fiecare element logic distinct al sistemului — celulă. Accesul se face prin autentificarea standard a utilizatorilor cu chei personale. Toată comunicarea între celule se desfășoară în mod criptat. Datorită criptării unităților de stocare, nu trebuie să ne facem griji cu privire la păstrarea datelor în timpul înlocuirii unui disc sau migrarea pe un alt server. Singurul acces critic este accesul la sistemul gazdă, deoarece un astfel de acces oferă, în general, acces la datele din interiorul containerelor.
Integritate — Respectarea acestui principiu se desfășoară pe mai multe niveluri diferite. În primul rând, este important de menționat că în cazul echipamentului server, memoria ECC, ZFS se ocupă deja de integritatea datelor la nivel de biți de informație. Instantaneele permit realizarea copiilor de rezervă în orice moment, pe loc. Instrumentele convenabile de export-import pentru celule fac simplă replicarea celulelor.
Disponibilitate — Aici este deja opțional. Depinde de gradul de notorietate și de existența dușmanilor. În exemplul nostru, am asigurat accesibilitatea portofelului exclusiv prin rețeaua TOR. Dacă este necesar, se poate bloca totul pe firewall și să se permită accesul la server exclusiv prin tuneluri (TOR sau VPN este o altă discuție). Astfel, serverul va fi tăiat de lumea exterioară cât mai mult posibil, și vom putea influența accesibilitatea doar noi înșine.
Nedreptul de a renunța — Aceasta depinde de utilizarea ulterioară și respectarea politicilor corecte privind drepturile utilizatorilor, accesul etc. Dar cu o abordare corectă, toate acțiunile utilizatorilor sunt auditate, iar datorită soluțiilor criptografice este posibilă identificarea exactă a celor care și când au efectuat anumite acțiuni.
Desigur, configurația descrisă nu este un exemplu absolut despre cum ar trebui să fie întotdeauna, ci mai degrabă un exemplu despre cum ar putea fi, păstrând în același timp posibilități foarte flexibile de scalare și personalizare.
Dar ce zici de virtualizarea completă?
Despre virtualizarea completă cu ajutorul cbsd poți . Aș dori doar să adaug că pentru funcționare bhyve este necesar să activezi anumite parametri ai nucleului.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Așa că, dacă ai nevoie să ridici un container Docker, atunci ridică un Debian și la drum!
Asta e tot
Probabil că asta e tot ce am vrut să împărtășesc. Dacă ți-a plăcut articolul, poți să-mi trimiți niște bitcoin — . Dacă vrei să încerci containerele în acțiune și ai câțiva bitcoin, atunci poți vizita proiectul meu .
Sursa: habr.com
