È interessante notare che per professione sono un amministratore di sistemi e reti informatiche (in breve: sistemista), e ho avuto l'opportunità di lavorare per oltre 10 anni con vari sistemi, compresi quelli che richiedono misure di sicurezza [alte|particolari]. Inoltre, è successo che un po' di tempo fa ho trovato interessante , e non solo lo ho utilizzato, ma ho anche avviato diversi microservizi per imparare a lavorare autonomamente con la rete bitcoin (è pur sempre p2p) dal punto di vista dello sviluppatore (io, ovviamente, non sono un esperto dev, solo un curioso). Ma non parlo di sviluppo, parlo di un ambiente sicuro ed efficace per le applicazioni.
Le tecnologie finanziarie (fintech) vanno di pari passo con la sicurezza informatica (infosec) e la prima può funzionare senza la seconda, ma non a lungo. Ecco perché voglio condividere la mia esperienza e l'insieme di strumenti che utilizzo, che comprende sia fintech, sia infosec, e può essere utilizzato anche in un contesto più ampio o completamente diverso. In questo articolo non parlerò tanto di bitcoin, quanto del modello infrastrutturale per lo sviluppo e l'operatività di servizi finanziari (e non solo) — insomma, quei servizi dove la "B" ha importanza. Questo è valido sia per un exchange di bitcoin che per un tipico zootecnico di servizi di una piccola azienda non collegata al bitcoin.
Voglio sottolineare che sono sostenitore dei principi "keep it stupid simple" e "less is more", quindi sia l'articolo che quanto descritto in esso avranno caratteristiche coerenti con questi principi.
Scenari ipotetici: Affrontiamo il tutto con l'esempio di uno scambiatore di bitcoin. Abbiamo deciso di avviare uno scambio di rubli, dollari ed euro per bitcoin e viceversa, e abbiamo già una soluzione operativa. Ci occupiamo anche di altre valute digitali come QIWI e WebMoney; insomma, abbiamo risolto tutte le questioni legali. Dispone di un'applicazione pronta che funge da gateway di pagamento per rubli, dollari, euro e altri sistemi di pagamento. È collegata ai nostri conti bancari e integra un'API per le nostre applicazioni finali. Inoltre, abbiamo un'app web che svolge il ruolo di scambiatore per gli utenti, simile a un tipico portale QIWI o WebMoney: registrate un account, aggiungete una carta, ecc. Essa comunica con la nostra applicazione gateway, sempre tramite REST API in locale. E così, abbiamo deciso di collegare i bitcoin e nel contempo aggiornare l'infrastruttura, poiché inizialmente tutto era stato allestito in fretta su VirtualBox sotto la scrivania in ufficio... il sito ha iniziato a essere utilizzato, e ora ci preoccupiamo dell'uptime e delle prestazioni.
Iniziamo quindi con l'essenziale: la scelta del server. Poiché l'attività del nostro esempio è piccola e ci fidiamo dell'hosting (OVH), sceglieremo in cui non è possibile installare il sistema da un'immagine .iso originale, ma non preoccuparti, il dipartimento IT della sicurezza effettuerà sicuramente un'analisi dell'immagine installata. E quando cresceremo, affitteremo addirittura il nostro armadio con lucchetto e accesso fisico limitato, o forse costruiremo il nostro data center. In ogni caso, è importante ricordare che quando si affitta l'hardware e si installano immagini pronte all'uso, c'è la possibilità che nel sistema ci sia un "trojan dell'hoster", che nella maggior parte dei casi non è destinato a spiarti, ma per offrirti strumenti di gestione del server più comodi.
Installazione del server
Qui è tutto semplice. Scegliamo l'hardware che soddisfa le nostre esigenze. Poi selezioniamo l'immagine di FreeBSD. Oppure ci colleghiamo (nel caso di un altro hoster e del nostro hardware) tramite IPMI o con un monitor e avviamo il caricamento dell'immagine .iso di FreeBSD. Per l'installazione orchestrata utilizzo e . L'unica cosa, nel nostro caso con kimsufi, abbiamo scelto installazione personalizzata affinché i due dischi in mirror avessero "aperti" solo le partizioni di avvio e /home, il resto dello spazio del disco sarà crittografato, ma ne parleremo più avanti.
L'installazione del sistema avviene in modo standard, non mi soffermerò su questo, ma vorrei sottolineare che prima di iniziare a utilizzare il sistema, è importante prestare attenzione a hardening alle opzioni offerte da bsdinstaller alla fine dell'installazione (se installate il sistema da soli):
Sì su questo argomento, lo riassumerò qui brevemente.
È possibile attivare i parametri sopra citati anche su un sistema già installato. Per farlo, è necessario modificare il file di avvio e abilitare i parametri del kernel. *ee — è un editor presente in BSD
# ee /etc/rc.conf
...
#sec hard
clear_tmp_enable="YES"
syslogd_flags="-ss"
sendmail_enable="NONE"
# ee /etc/sysctl.conf
...
#sec hard
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 9999)
security.bsd.stack_guard_page=1È anche importante assicurarsi di avere installato l'ultima versione del sistema e . Nel nostro caso, ad esempio, è necessario eseguire l'upgrade all'ultima versione, poiché le immagini preinstallate sono indietro di sei mesi o un anno. E poi cambiamo la porta SSH in una diversa da quella predefinita, aggiungiamo l'autenticazione tramite chiavi e disattiviamo l'accesso con password.
Dopodiché, configuriamo aide, il monitoraggio dello stato dei file di configurazione del sistema. Maggiori dettagli possono essere letti. .
pkg install aide
e modifichiamo il nostro 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/$MYFILENAMEAttiviamo
sysrc auditd_enable=YES
# service auditd start
Come amministrare questo è descritto molto bene in .
Ora riavviamo e iniziamo a configurare il software sul server. Ogni server funge da hypervisor per i container o macchine virtuali complete. È quindi importante che il processore supporti VT-x e EPT se pianifichiamo di utilizzare la virtualizzazione completa.
Come gestione di container e macchine virtuali utilizzo da , gli auguro buona salute e benedizioni per questo fantastico strumento!
Container? Di nuovo Docker?
E invece no. — è uno strumento eccellente per la containerizzazione, mentre il citato cbsd per l'orchestrazione di questi container, il cui nome è — celle.
La cella è una soluzione estremamente efficace per la costruzione di infrastrutture per vari scopi, dove è necessaria la completa isolamento di servizi o processi distinti. Fondamentalmente, è un clone del sistema di hosting, ma non richiede una virtualizzazione completa dell'hardware. In questo modo, le risorse non vengono sprecate per un 'sistema operativo ospite', ma sono utilizzate solo per il lavoro effettivo. Quando le celle vengono utilizzate per scopi interni, rappresentano una soluzione molto comoda per un utilizzo ottimale delle risorse: un gran numero di celle su un singolo server fisico può utilizzare ogni cella separatamente l'intera risorsa del server, se necessario. Considerando che di solito diversi sottoservizi richiedono risorse aggiuntive in momenti diversi, si può estrarre la massima prestazione da un server se si pianificano e bilanciano correttamente le celle tra i server. Se necessario, le celle possono anche essere dotate di limiti sulle risorse utilizzate.
E per quanto riguarda la virtualizzazione completa?
Per quanto ne so, cbsd supporta i bhyve e i hypervisor XEN. Non ho mai usato il secondo, mentre il primo è un hypervisor relativamente nuovo . Esamineremo un esempio di utilizzo bhyve nell'esempio seguente.
Installazione e configurazione dell'ambiente host
Utilizziamo FS . È uno strumento estremamente potente per la gestione dello spazio sul server. Grazie a ZFS, è possibile costruire array di configurazioni diverse direttamente dai dischi, ampliare dinamicamente lo spazio 'a caldo', sostituire dischi guasti, gestire snapshot e molto, molto altro che si potrebbe descrivere in una serie di articoli. Torniamo al nostro server e ai suoi dischi. All'inizio dell'installazione, abbiamo lasciato dello spazio libero sui dischi per le partizioni crittografate. Perché? In modo che il sistema possa avviarsi automaticamente e ascoltare tramite SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
aggiungiamo la partizione del disco sullo spazio rimanente
geli init /dev/ada0p4
inseriamo la nostra password di crittografia
geli attach /dev/ada0p4
inseriamo di nuovo la password e otteniamo il dispositivo /dev/ada0p4.eli — questo è il nostro spazio crittografato. Poi ripetiamo lo stesso per /dev/ada1 e gli altri dischi nell'array. E creiamo un nuovo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — ecco, il nostro set di base è pronto. Un array di dischi per eventualità di guasto di uno dei tre.
Creiamo un dataset su un nuovo "pool"
zfs create vms/jails
pkg install cbsd — abbiamo lanciato il comando, e stiamo installando il gestore per le nostre celle.
Dopo che cbsd è stato installato, deve essere inizializzato:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
dobbiamo rispondere a molte domande, principalmente con le risposte predefinite.
*Se stai usando la crittografia, è importante che il demone cbsdd non parta automaticamente, finché non decritti i dischi manualmente o automaticamente (nel nostro esempio, questo viene fatto da zabbix)
**Inoltre, non uso il NAT di cbsd, ma lo configuro io stesso in pf.
# sysrc pf_enable=YES
# ee /etc/pf.conf
IF_PUBLIC="em0"
IP_PUBLIC="1.23.34.56"
JAIL_IP_POOL="192.168.0.0/24"
#WHITE_CL="{ 127.0.0.1 }"
icmp_types="echoreq"
set limit { states 20000, frags 20000, src-nodes 20000 }
set skip on lo0
scrub in all
#NAT per le prigioni
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Port forwarding per la rete 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
La configurazione delle politiche del firewall è un argomento a parte, quindi non approfondirò la configurazione della politica BLOCK ALL e le impostazioni delle liste bianche, questo può essere fatto leggendo o uno qualsiasi dei numerosi articoli disponibili su Google.
Bene... abbiamo installato cbsd, è ora di creare il nostro primo cavallo da lavoro: un demone Bitcoin in una cella!
cbsd jconstruct-tui
Qui vediamo il dialogo di creazione della cella. Una volta impostati tutti i valori, creiamo!
Quando creiamo la prima cella, dobbiamo scegliere cosa usare come base per le celle. Io scelgo il pacchetto dal repository FreeBSD con il comando repo. Questa scelta viene effettuata solo durante la creazione della prima cella di una versione specifica (è possibile ospitare celle di qualsiasi versione superiore a quella dell'host).
Una volta che tutto è installato, avviamo la cella!
# cbsd jstart bitcoind
Ma dobbiamo installare il software nella cella.
# jls
JID Indirizzo IP Nome host Percorso
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind per accedere alla console della cella
e già all'interno della cella installiamo il software con le sue dipendenze (il nostro sistema host rimane pulito)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoin nella cella è attivo, ma abbiamo bisogno di anonimato, poiché vogliamo connetterci ad alcune celle tramite la rete TOR. In generale, abbiamo in programma di eseguire la maggior parte delle celle con software sospetto solo tramite proxy. Grazie pf è possibile disabilitare il NAT per un determinato intervallo di indirizzi IP nella rete locale e consentire il NAT solo per il nostro nodo TOR. In questo modo, anche se un malware entra nella cella, è probabile che non riesca a connettersi con il mondo esterno, e se lo fa, non rivelerà l'IP del nostro server. Pertanto, creiamo un'altra cella per il 'forwarding' di servizi come i servizi '.onion' e come proxy per l'accesso a Internet per celle 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
Impostiamo l'ascolto su un indirizzo locale (disponibile per tutte le celle)
SOCKSPort 192.168.0.2:9050
Cosa ci manca per la felicità completa? Sì, abbiamo bisogno di un servizio per il nostro web, forse anche più di uno. Avviamo nginx, che fungerà da reverse-proxy e si occuperà del rinnovo dei certificati Let’s Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
Ecco, abbiamo inserito 150 MB di dipendenze nella cella. E l'host è ancora pulito.
Torniamo alla configurazione di nginx più tardi; dobbiamo alzare altre due celle per il nostro gateway di pagamento in nodejs e rust e per l'applicazione web, che per qualche motivo utilizza Apache e PHP, e per quest'ultima è necessaria un database 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
… e altri 380 MB di pacchetti isolati
dopo di che utilizzeremo Git per caricare la nostra applicazione e avviarla.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB di pacchetti. nella gabbia.
qui diamo accesso allo sviluppatore via SSH direttamente nella gabbia, faranno tutto da soli:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — cambiamo la porta SSH della gabbia a una qualsiasi a piacere
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Ecco, il servizio è avviato, resta da aggiungere una regola nel pf firewall
Vediamo quali IP abbiamo nelle gabbie e come appare la nostra "località"
# jls
JID Indirizzo IP Nome host Percorso
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/webappe aggiungeremo la regola
# 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
e dato che siamo qui, aggiungeremo anche una regola per il 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
Ora un po' sui bitcoin
Cosa abbiamo — abbiamo un'app web accessibile esternamente, e comunica localmente con il nostro gateway di pagamento. Ora dobbiamo preparare l'ambiente di lavoro per l'interazione con la rete Bitcoin stessa — nodo bitcoind questo è solo un demonio che supporta una copia locale della blockchain attuale. Questo demonio ha RPC e funzionalità di portafoglio, ma per lo sviluppo di applicazioni ci sono «wrapper» più convenienti. Per iniziare, abbiamo deciso di installare electrum — è un portafoglio CLI. sarà utilizzato come «cold storage» per i nostri bitcoin — in sostanza, quei bitcoin che devono essere conservati «al di fuori» del sistema accessibile agli utenti e, in generale, lontano da tutti. Ha anche un'interfaccia grafica, quindi intendiamo utilizzare lo stesso portafoglio sui nostri
laptop. Per ora useremo Electrum con server pubblici, e più tardi installeremo , in modo da non essere dipendenti da nessuno.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
ancora 700 MB di software nella cella
electrum:/@[8:53] # adduser
Nome utente: wallet
Nome completo:
Uid (Lascia vuoto per predefinito):
Gruppo di accesso [wallet]:
Il gruppo di accesso è wallet. Vuoi invitare wallet in altri gruppi? []:
Classe di accesso [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Directory home [/home/wallet]:
Permessi della directory home (Lascia vuoto per predefinito):
Utilizzare l'autenticazione basata su password? [yes]: no
Bloccare l'account dopo la creazione? [no]:
Nome utente : wallet
Password :
Nome completo :
Uid : 1001
Classe :
Gruppi : wallet
Home : /home/wallet
Home Mode :
Shell : /bin/tcsh
Bloccato : no
OK? (yes/no): yes
adduser: INFO: Aggiunto con successo (wallet) al database utenti.
Aggiungere un altro utente? (yes/no): no
Arrivederci!
electrum:/@[8:53] # su walletelectrum:/@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Ti preghiamo di tenere il tuo seed in un luogo sicuro; se lo perdi, non sarai in grado di ripristinare il tuo wallet.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}Ora abbiamo creato un wallet.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
Per il nostro on-chain wallet potrà essere collegato solo a un numero limitato di persone. Per non aprire l'accesso esterno a questa cella, le connessioni SSH avverranno tramite TOR (una versione decentralizzata del VPN). Avviamo SSH nella cella, ma non tocchiamo il nostro pf.conf dell'host.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # servizio sshd start
Ora scollegheremo la cella con il portafoglio da Internet. Imposteremo un indirizzo IP da un altro spazio di sottorete che non verrà tradotto. Prima cambiamo /etc/pf.conf sull'host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" cambiamo in JAIL_IP_POOL="192.168.0.0/25", in questo modo tutti gli indirizzi 192.168.0.126-255 non avranno accesso diretto a Internet. Una sorta di rete "air-gap" software. E la regola NAT rimane com'è
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Riavviamo le regole
# pfctl -f /etc/pf.conf
Ora ci occupiamo della nostra cella
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Rimuovi vecchio IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Imposta nuovo IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, ma ora smetterà di funzionare anche il sistema stesso. Tuttavia, possiamo specificare un proxy di sistema. Ma c'è un problema: su TOR è un proxy SOCKS5, e per comodità avremmo bisogno anche di 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
Ecco, ora nel nostro sistema ci sono due server proxy, entrambi che portano attraverso TOR: socks5://192.168.0.2:9050 e
Ora possiamo configurare l'ambiente del nostro portafoglio
# 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:8123Ecco, ora il shell funzionerà tramite proxy. Se vogliamo installare pacchetti, è consigliabile aggiungere in /usr/local/etc/pkg.conf sotto root cella
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}È ora di aggiungere il servizio nascosto TOR come indirizzo per il nostro servizio SSH nella cella del portafoglio.
# 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.onionEcco il nostro indirizzo per la connessione. Controlliamo dalla macchina locale. Ma prima dobbiamo aggiungere la nostra chiave SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localE dalla macchina Linux client
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
Connettiamoci (Per far funzionare questo è necessario un demone TOR locale che ascolti sulla porta 9050)
user@local ~$ ssh remotebtc
L'autenticità dell'host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<nessun hostip per il comando proxy>)' non può essere stabilita.
La chiave fingerprint ECDSA è SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Sei sicuro di voler continuare a connetterti (sì/no/[fingerprint])? sì
Attenzione: 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) è stato aggiunto in modo permanente all'elenco degli host conosciuti.
FreeBSD 12.1-RELEASE-p1 GENERIC
Per salvare spazio su disco nella tua directory home, comprimi i file che usi raramente con "gzip nomefile".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Successo!
Per lavorare con pagamenti istantanei e micro-pagamenti abbiamo bisogno anche di un nodo , questo sarà il nostro principale strumento di lavoro con Bitcoin. A *, che intendiamo utilizzare come demone, ha , che è un'interfaccia HTTP (REST) completa e consente di lavorare sia con transazioni off-chain che on-chain. c-lightning per funzionare ha bisogno di bitcoind un nodo.
*ci sono diverse implementazioni del protocollo Lightning Network in vari linguaggi di programmazione. Tra quelle che abbiamo testato, c-lightning (scritto in C) si è dimostrato il più stabile e efficiente in termini di risorse
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/@[10:23] # adduser
Nome utente: 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
Mentre si compilano e installano tutto il necessario, creiamo un utente RPC per lightningd in bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
# consenti solo a c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Il mio passaggio caotico tra le celle non sembra poi così caotico se si considera l'utilità tmux, che permette di creare molte sotto-sessioni di terminale all'interno di una singola sessione. Analogo: schermo
D'accordo, non vogliamo esporre il vero IP del nostro nodo e vogliamo effettuare tutte le operazioni finanziarie tramite TOR. Quindi abbiamo bisogno di un altro .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.onionora creiamo la configurazione per 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
# per l'esempio sopra i log di inizializzazione (mescolati con i log di lightningd) dovrebbero stampare qualcosa comelightning@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 ~
è necessario anche creare un file di configurazione per bitcoin-cli, l'utility che comunica con bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testverifichiamo
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]avviamo lightningd
lightning@lightning:~ % lightningd --daemon
Io lightningd puoi gestire l'utilità lightning-cli, ad esempio:
lightning-cli newaddr ottenere un indirizzo per un nuovo pagamento in entrata
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all inviare a indirizzo tutti i fondi del wallet (tutti gli indirizzi on-chain)
Ci sono anche comandi per operazioni off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay ecc.
Per comunicare con l'applicazione abbiamo una REST Api
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Ricapitoliamo
# jls
JID Indirizzo IP Nome Host Percorso
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
Abbiamo un insieme di contenitori, ognuno con il proprio livello di accesso sia alla rete locale che ad essa.
# zfs list
NOME UTILIZZATO DISPONIBILE RIFERIMENTO PUNTODIMONTAGGIO
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-dataCome si vede, bitcoind occupa tutti i 190 GB di spazio. E se avessimo bisogno di un'altra nodo per i test? Qui entra in gioco ZFS. cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com è possibile creare uno snapshot e collegare una nuova cella a questo snapshot. La nuova cella avrà completamente il proprio spazio, ma nella FS verrà considerata solo la differenza tra lo stato attuale e l'originale (risparmieremo almeno 190 GB).
Ogni cella è un proprio dataset ZFS separato, ed è estremamente comodo. fare altre cose interessanti, come inviare snapshot tramite SSH. Non ci dilungheremo su questo, ce n'è già abbastanza.
È importante anche sottolineare la necessità di monitorare il server da remoto; per questi scopi abbiamo .
B — sicurezza
Per quanto riguarda la sicurezza, partiamo dai principi fondamentali nel contesto dell'infrastruttura:
Riservatezza — Gli strumenti standard dei sistemi basati su UNIX garantiscono l'implementazione di questo principio. Separiamo logicamente l'accesso a ciascun elemento del sistema — cella. L'accesso avviene tramite autenticazione utente standard con chiavi personali. Tutta la comunicazione tra e fino alle celle finali avviene in forma crittografata. Grazie alla crittografia dei dischi, possiamo stare tranquilli riguardo alla sicurezza dei dati durante la sostituzione di un disco o la migrazione a un altro server. L'unico accesso critico è l'accesso al sistema host, poiché tale accesso in generale consente l'accesso ai dati all'interno dei contenitori.
Integrità — L'attuazione di questo principio avviene su più livelli. In primo luogo, è importante notare che nel caso di hardware server, la memoria ECC e ZFS si prendono già cura dell'integrità dei dati a livello di bit. Le istantanee consentono di effettuare backup in qualsiasi momento in tempo reale. Strumenti di esportazione e importazione delle celle rendono semplice la replicazione di queste ultime.
Disponibilità — Qui è già facoltativa. Dipende dal grado di notorietà e dal fatto che si abbia qualcuno che non ci apprezza. Nel nostro esempio, abbiamo garantito l'accesso al portafoglio esclusivamente dalla rete TOR. Se necessario, si può bloccare tutto nel firewall e consentire l'accesso al server esclusivamente tramite tunnel (TOR o VPN sono un'altra questione). In questo modo, il server sarà isolato dal mondo esterno il più possibile, e la sua disponibilità potremo influenzarla solo noi stessi.
Impossibilità di rifiuto — Questo dipende dall'uso futuro e dal rispetto delle corrette politiche sui diritti degli utenti, accesso, ecc. Ma con l'approccio giusto, tutte le azioni degli utenti sono auditate e grazie a soluzioni crittografiche è possibile identificare in modo univoco chi e quando ha eseguito certe azioni.
Certo, la configurazione descritta non è un esempio assoluto di come debba sempre essere, è piuttosto uno dei modi in cui può essere, mantenendo molto elastiche possibilità di scalabilità e personalizzazione.
E per quanto riguarda la virtualizzazione completa?
Puoi leggere della virtualizzazione completa usando cbsd . Aggiungo solo che per funzionare bhyve è necessario attivare alcuni parametri del kernel.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Quindi se hai bisogno di usare Docker, alziamo un qualche Debian e via!
E questo è tutto
Penso che sia tutto ciò che volevo condividere. Se ti è piaciuto l'articolo, puoi inviarmi dei bitcoin — . Se vuoi provare le celle in azione e hai un po' di bitcoin, puoi visitare il mio .
Fonte: habr.com
