È accaduto che io sia un amministratore di sistemi e reti informatiche di professione (in breve: sysadmin), e ho avuto modo di raccontare, in poco più di dieci anni di attività professionale, di vari sistemi, inclusi quelli che richiedono misure di sicurezza [po|za]vanzate. Inoltre, è successo che qualche tempo fa ho trovato interessante , e non solo l'ho utilizzato, ma ho anche avviato diversi micro-servizi, per imparare a lavorare autonomamente con la rete di bitcoin (che è pur sempre p2p) dal punto di vista dello sviluppatore (sono ovviamente un po’ scarso dev, così, ci passo accanto). Ma non parlo di sviluppo, parlo di un ambiente sicuro ed efficiente per le applicazioni.
Le tecnologie finanziarie (fintech) vanno di pari passo con la sicurezza delle informazioni (infosec), e il primo può funzionare senza il secondo, ma non per molto. Ecco perché voglio condividere la mia esperienza e il set di strumenti che utilizzo, che comprende sia fintech, sia infosec, contemporaneamente, e può anche essere usato in contesti più ampi o completamente diversi. In questo articolo parlerò non tanto di bitcoin, quanto di un modello infrastrutturale per lo sviluppo e l'operatività di servizi finanziari (e non solo) — in una parola, quei servizi dove la «B» ha importanza. Questo si applica sia a un exchange bitcoin che all'ordinario zoo di servizi di una piccola azienda non collegata in alcun modo al bitcoin.
Vorrei sottolineare che sono un sostenitore dei principi «keep it stupid simple» e «less is more», quindi l'articolo e ciò che vi è descritto avrà le caratteristiche che riflettono questi principi.
Scenario ipotetico: Analizziamo tutto con l'esempio di un exchange di bitcoin. Abbiamo deciso di lanciare uno scambio di rubli, dollari ed euro in bitcoin e viceversa, e abbiamo già una soluzione operativa, ma per altre valute digitali come Qiwi e Webmoney, ovvero abbiamo risolto tutte le questioni legali, abbiamo un'applicazione pronta che funge da gateway di pagamento per rubli, dollari ed euro e altri sistemi di pagamento. È collegata ai nostri conti bancari e dispone di un'API per le nostre applicazioni finali. Abbiamo anche un'app web che funge da exchange per gli utenti, simile a un classico profilo di Qiwi o Webmoney: crea un account, aggiungi una carta e così via. Comunica con la nostra applicazione-gateway, idealmente tramite REST API in locale. E abbiamo deciso di integrare i bitcoin e nel contempo aggiornare l'infrastruttura, poiché inizialmente tutto era stato rapidamente impostato su VirtualBox in ufficio, sotto la scrivania... il sito è stato utilizzato, e ora ci preoccupiamo del tempo di attività e delle prestazioni.
Iniziamo con la cosa principale: la scelta del server. Poiché il business nel nostro esempio è piccolo e ci fidiamo dell'hoster (OVH), scegliamo nella quale non è possibile installare il sistema da un'immagine iso originale, ma non è un problema, il dipartimento di sicurezza IT eseguirà sicuramente un'analisi dell'immagine installata. Quando cresceremo, noleggeremo persino il nostro armadietto con lucchetto e accesso fisico limitato, o forse costruiremo il nostro Data Center. In ogni caso, è importante ricordare che quando si noleggia l'hardware e si installano immagini pronte c'è la possibilità che il sistema ospiti un "trojan dall'hoster", che nella maggior parte dei casi è destinato non a monitorarti ma a offrire strumenti di gestione del server più comodi.
Installazione del server
Qui è tutto semplice. Scegliamo l'hardware che soddisfa le nostre esigenze. Poi scegliamo l'immagine FreeBSD. Oppure ci connettiamo (nel caso di un altro hoster e del nostro hardware) tramite IPMI o con un monitor e carichiamo l'immagine .iso di FreeBSD. Per l'installazione orchestrale utilizzo e . L'unica cosa, nel nostro caso con kimsufi, abbiamo scelto l'installazione personalizzata in modo tale che i due dischi in mirror avessero 'aperte' solo le partizioni di avvio e /home, mentre 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 voglio sottolineare che prima di iniziare ad utilizzare il sistema è opportuno prestare attenzione a hardening le opzioni offerte da bsdinstaller alla fine dell'installazione (se installate il sistema autonomamente):
C'è su questo tema, lo ripeterò brevemente qui.
È possibile abilitare i parametri sopra menzionati anche su un sistema già installato. Per questo è necessario modificare il file del bootloader e abilitare i parametri del kernel. *ee è un editor in BSD
# ee /etc/rc.conf
...
#sec hard
clear_tmp_enable="YES"
syslogd_flags="-ss"
sendmail_enable="NONE"
# ee /etc/sysctl.conf
...
#sec hard
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 9999)
security.bsd.stack_guard_page=1È anche importante assicurarsi di avere installata l'ultima versione del sistema, e . Nel nostro caso, ad esempio, è richiesta un'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 disabilitiamo l'accesso tramite password.
Poi configuriamo aide, il monitoraggio dello stato dei file di configurazione del sistema. Puoi leggere in modo più dettagliato .
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/$MYFILENAMEAbilitiamo
sysrc auditd_enable=YES
# service auditd start
Come gestire questa cosa è descritto ottimamente in .
Ora riavviamo e iniziamo a configurare il software sul server. Ogni server funge da hypervisor per contenitori o macchine virtuali complete. Pertantoè importante che il processore supporti VT-x ed EPT se intendiamo utilizzare la virtualizzazione completa.
Come gestione dei contenitori e delle macchine virtuali utilizzo di , auguro a lui molta salute e benedizioni per questo meraviglioso strumento!
Contenitori? Ancora docker?
E invece no. è uno strumento eccellente per la containerizzazione, mentre il già citato cbsd per l'orchestrazione di questi contenitori, il cui nome è celle.
La cella è una soluzione estremamente efficace per costruire infrastrutture per vari scopi, dove alla fine è necessaria un'isolamento completo di singoli servizi o processi. In sostanza, è un clone del sistema host, ma non richiede una virtualizzazione completa dell'hardware. Di conseguenza, le risorse non vengono sprecate su un "OS ospite", ma solo sul lavoro eseguito. Quando le celle vengono utilizzate per esigenze interne, rappresentano una soluzione molto comoda per un utilizzo ottimale delle risorse: un gran numero di celle su un server fisico può utilizzare ciascuna separatamente l'intera risorsa del server, se necessario. Considerando che normalmente servizi diversi necessitano di risorse aggiuntive in tempi diversi, è possibile estrarre la massima prestazione da un server, se si pianifica e si bilancia correttamente le celle tra i server. In caso di necessità, è anche possibile impostare limiti sulle risorse utilizzate dalle celle.
E per quanto riguarda la virtualizzazione completa?
Per quanto ne so, cbsd supporta il funzionamento di bhyve e dei hypervisor XEN. Non ho mai utilizzato il secondo, ma il primo è un hypervisor relativamente giovane . Esamineremo un esempio di utilizzo bhyve nell'esempio successivo.
Installazione e configurazione dell'ambiente host
Utilizziamo FS . Questo è uno strumento estremamente potente per gestire lo spazio sul server. Grazie a ZFS, è possibile costruire direttamente array di varie configurazioni, espandere dinamicamente lo spazio "a caldo", sostituire dischi guasti, gestire snapshot e molto, molto altro, che potrebbe essere descritto in una serie di articoli. Torniamo al nostro server e ai suoi dischi. All'inizio dell'installazione, sui dischi abbiamo lasciato spazio libero per le partizioni crittografate. Perché? È per garantire che il sistema si avvii automaticamente e ascolti via SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
aggiungiamo una partizione del disco nello spazio rimanente
geli init /dev/ada0p4
inseriamo la nostra password di crittografia
geli attach /dev/ada0p4
di nuovo inseriamo la password e ci appare il dispositivo /dev/ada0p4.eli — questo è il nostro spazio crittografato. Poi ripetiamo lo stesso per /dev/ada1 e gli altri dischi dell'array. E creiamo un nuovo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — ecco, abbiamo il nostro set minimo di strumenti pronto. Un array di dischi in mirror nel caso in cui uno dei tre si guasti.
Creiamo un dataset sul 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
e rispondiamo a una serie di domande, principalmente con risposte predefinite.
*Se utilizzi la crittografia, è importante che il demone cbsdd non parta automaticamente, finché non decritti manualmente o automaticamente i dischi (nel nostro esempio lo fa zabbix)
**Non utilizzo NAT da 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 celle
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Port forwarding della 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 è anch'essa un argomento a parte, quindi non approfondirò la configurazione della politica BLOCK ALL e delle liste bianche, questo può essere fatto leggendo o qualsiasi articolo disponibile su Google.
Bene… abbiamo installato cbsd, è tempo di creare il nostro primo cavallo da lavoro: il demone Bitcoin nella cella!
cbsd jconstruct-tui
Qui vediamo il dialogo per la creazione della cella. Dopo aver impostato tutti i valori, creiamo!
Quando crei la prima cella, devi scegliere cosa usare come base per le celle. Io scelgo una distribuzione dal repository FreeBSD con il comando repo. Questa scelta viene effettuata solo durante la creazione della prima cella per una versione specifica (puoi ospitare celle di qualsiasi versione, purché superiore alla versione dell'host).
Dopo che tutto è stato installato, avviamo la cella!
# cbsd jstart bitcoind
Ma dobbiamo installare il software nella cella.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind per accedere alla console della cella
e 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
Il Bitcoin è nella cella, ma abbiamo bisogno di anonimato, perché vogliamo connetterci ad alcune celle attraverso la rete TOR. E in generale, abbiamo in programma di far girare la maggior parte delle celle con software sospetto solo tramite proxy. Grazie pf è possibile disattivare 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, è molto 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" dei servizi come servizio ".onion" e come proxy per l'uscita su Internet a 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 (accessibile a tutte le celle)
SOCKSPort 192.168.0.2:9050
Cosa ci manca ancora per la completa felicità? Sì, abbiamo bisogno di un servizio per il nostro web, forse anche più di uno. Avviamo nginx, che funzionerà come 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 messo 150 MB di dipendenze nella cella. E l'host è ancora pulito.
Torniamo alla configurazione di nginx più tardi, dobbiamo sollevare altre due celle per il nostro gateway di pagamento su nodejs e rust e un'applicazione web che per qualche motivo è su apache e php, e inoltre per quest'ultima abbiamo bisogno di 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, scarichiamo la nostra applicazione con git e la avviamo.
# 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 cella.
Qui diamo accesso allo sviluppatore tramite SSH direttamente nella cella, possono sistemare tutto da soli:
webapp:\/@[16:02] # ee \/etc\/ssh\/sshd_config
Port 2267 — cambiamo la porta SSH della cella in una qualsiasi a piacere
webapp:\/@[16:02] # sysrc sshd_enable=YES
webapp:\/@[16:02] # service sshd start
Ecco, il servizio è avviato, resta solo da aggiungere una regola nel pf firewall
Vediamo quali IP abbiamo nelle celle e come appare la nostra "rete locale"
# 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\/webappe aggiungiamo una 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
dato che siamo qui, aggiungiamo 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
E ora un po' sui bitcoin
Cosa abbiamo — abbiamo un'applicazione web che è accessibile dall'esterno e comunica localmente con il nostro gateway di pagamento. Ora dobbiamo preparare l'ambiente di lavoro per interagire con la rete di bitcoin stessa — nodo bitcoind questo è solo un demone che supporta una copia locale della blockchain attuale. Questo demone ha RPC e funzionalità di wallet, tuttavia per lo sviluppo delle applicazioni ci sono «wrapper» più convenienti. Per cominciare abbiamo deciso di installare electrum — è un wallet CLI. sarà utilizzato da noi come «cold storage» per i nostri bitcoin — in generale, quei bitcoin che dovranno essere conservati «fuori» dal sistema accessibile agli utenti e lontano da tutti. Ha anche un GUI, quindi utilizzeremo lo stesso wallet sui nostri
laptop. Per ora utilizzeremo electrum con server pubblici, e più tardi in un’altra cella installeremo , in modo da non dipendere da nessuno.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:@[8:45] # pkg install py36-electrum
altri 700 MB di software abbiamo nella cella
electrum:@[8:53] # adduser
Nome utente: wallet
Nome completo:
Uid (lasciare vuoto per impostazione predefinita):
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 (lasciare vuoto per impostazione predefinita):
Utilizzare l'autenticazione basata su password? [yes]: no
Bloccarsi l'account dopo la creazione? [no]:
Nome utente : wallet
Password :
Nome completo :
Uid : 1001
Classe :
Gruppi : wallet
Home : /home/wallet
Modalità home :
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": "Si prega di tenere il proprio 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
Al nostro on-chain wallet potrà collegarsi d'ora in poi solo un numero limitato di persone. Per non aprire l'accesso dall'esterno a questa cella, le connessioni SSH avverranno attraverso TOR (un'opzione decentralizzata simile al VPN). Avviamo SSH nella cella, ma non tocchiamo il nostro pf.conf sull'host.
electrum:@[9:00] # sysrc sshd_enable=YES
electrum:@[9:00] # service sshd start
Ora disabiliteremo l'accesso a Internet nella cella con il wallet. Le daremo un indirizzo IP da un'altra subnet, che non verrà NAT-izzata. Iniziamo a modificare /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 come era
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Ricarichiamo 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 il sistema smetterà di funzionare. 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 passano 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 la shell funzionerà sotto il proxy. Se vogliamo installare pacchetti, dovremmo aggiungere in /usr/local/etc/pkg.conf dal root della cella
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Ora è il momento di aggiungere il servizio nascosto TOR come indirizzo del 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 con la macchina 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
Connettersi (Per fare in modo che questo funzioni, è necessario un demone TOR locale che ascolta sulla porta 9050)
user@local ~$ ssh remotebtc
L'autenticità dell'host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion ()' non può essere stabilita.
La chiave ECDSA fingerprint è SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Sei sicuro di voler continuare a connetterti (sì/no/[fingerprint])? sì
Attenzione: Aggiunto permanentemente 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) alla lista degli host conosciuti.
FreeBSD 12.1-RELEASE-p1 GENERIC
Per risparmiare spazio su disco nella tua home directory, comprimi i file che usi raramente con "gzip filename".
-- Dru
wallet@electrum:~ % logout
Successo!
Per lavorare con pagamenti istantanei e micro-pagamenti, abbiamo anche bisogno di un nodo , in realtà questo sarà il nostro principale strumento di lavoro con Bitcoin. U *, 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 in vari linguaggi di programmazione del protocollo Lightning Network. Tra quelle che abbiamo testato, c-lightning (scritto in C) si è dimostrato il più stabile ed 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 vengono compilati e installati tutti i requisiti, creeremo 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 c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Il mio passaggio caotico tra le celle non si rivela poi così caotico se si segnala l'utilità tmux, che permette di creare molteplici sottosessioni del terminale all'interno di una singola sessione. Analogo: screen
Allora, non vogliamo rivelare il vero IP del nostro nodo e vogliamo eseguire tutte le operazioni finanziarie tramite TOR. Quindi ci serve 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 (misti con i log di lightningd) dovrebbero stampare qualcosa di similelightning@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'utilità che comunica con bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testverificiamo
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]avviamo lightningd
lightning@lightning:~ % lightningd --daemon
Il lightningd è possibile gestire l'utilità lightning-cli, per esempio:
lightning-cli newaddr ottenere un indirizzo per un nuovo pagamento in arrivo
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all inviare all'indirizzo tutti i fondi del portafoglio (di tutti gli indirizzi on-chain)
Ci sono anche comandi per operazioni off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay ecc.
E per la comunicazione con l'applicazione abbiamo un'API REST
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Riassumiamo
# 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 container, ognuno con il proprio livello di accesso sia alla rete locale che all'esterno.
# zfs list
NOME UTILIZZATO DISPONIBILE RIFERIMENTO PUNTO DI MONTAGGIO
zroot 279G 1.48T 88K /zroot
zroot/ROOT 1.89G 1.48T 88K nessuno
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 tutto lo spazio di 190 GB. E se avessimo bisogno di un altro nodo per i test? Qui ZFS è davvero utile. Con l'aiuto di cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com È possibile creare uno snapshot e associare una nuova cella a questo snapshot. La nuova cella avrà uno spazio tutto suo, ma verrà presa in considerazione nel FS solo la differenza tra lo stato attuale e l'originale (risparmiamo almeno 190 GB)
Ogni cella è un dataset ZFS separato ed è estremamente comodo. di fare altre cose interessanti, come inviare snapshot tramite SSH. Non lo descriviamo, ci sono già molte informazioni.
È importante anche notare la necessità di monitoraggio remoto dell'host, abbiamo per questi scopi .
B — sicurezza
Per quanto riguarda la sicurezza, partiamo dai principi chiave nel contesto dell'infrastruttura:
Riservatezza — Gli strumenti standard dei sistemi UNIX-like garantiscono il rispetto di questo principio. Separiamo logicamente l'accesso a ogni elemento di sistema logicamente distinto - cella. L'accesso avviene tramite l'autenticazione standard degli utenti con chiavi personali. Tutta la comunicazione tra le celle e fino alle celle finali avviene in forma crittografata. Grazie alla crittografia dei dischi, possiamo non preoccuparci della sicurezza dei dati durante la sostituzione del disco o la migrazione su un altro server. L'unico accesso critico è all'host, poiché tale accesso garantisce, in generale, l'accesso ai dati all'interno dei contenitori.
Integrità — L'attuazione di questo principio avviene a più livelli. Prima di tutto, è 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. Gli snapshot istantanei consentono di eseguire backup in qualsiasi momento in tempo reale. Gli strumenti di importazione/esportazione delle celle semplificano la replicazione delle celle.
Disponibilità — Qui è già facoltativo. Dipende dal grado della tua notorietà e dalla presenza di detrattori. Nel nostro esempio, abbiamo garantito l'accessibilità del portafoglio esclusivamente dalla rete TOR. Se necessario, su firewall è possibile bloccare tutto e consentire l'accesso al server esclusivamente tramite tunnel (TOR o VPN è un'altra questione). In questo modo, il server sarà isolato dal mondo esterno il più possibile, e potremo influenzarne l'accessibilità solo noi.
Impossibilità di rifiuto — Questo dipende dall'ulteriore utilizzo e dal rispetto delle corrette politiche sui diritti degli utenti, accesso e così via. Ma con un approccio corretto tutte le azioni degli utenti vengono auditate e, grazie a soluzioni crittografiche, è possibile identificare senza ambiguità chi e quando ha effettuato determinate azioni.
Certo, la configurazione descritta non è un esempio assoluto di come dovrebbe essere sempre; è piuttosto uno degli esempi di come potrebbe essere, mantenendo molto flessibili possibilità di scalabilità e personalizzazione.
E riguardo alla virtualizzazione completa?
La virtualizzazione completa con strumenti cbsd è possibile . Aggiungo solo che per operare 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 all'improvviso è necessario avviare Docker, basta sollevare un Debian e via!
Ecco tutto
Probabilmente è tutto ciò che volevo condividere. Se ti è piaciuto l'articolo, puoi inviarmi un po' di bitcoin — . Se vuoi provare le celle in azione e hai un po' di bitcoin, puoi visitare il mio .
Fonte: habr.com
