È successo che di professione sono amministratore di sistemi e reti informatiche (in breve: amministratore di sistema), e ho avuto modo di raccontarlo al prof.per poco più di 10 anni. le attività di un’ampia varietà di sistemi, compresi quelli che richiedono misure di sicurezza [estreme]. È anche successo che qualche tempo fa l'ho trovato interessante , e non solo l'ha utilizzato, ma ha anche lanciato diversi microservizi per imparare a lavorare in modo indipendente con la rete Bitcoin (dopotutto anche p2p) dal punto di vista di uno sviluppatore (io ovviamente sono uno di quelli dev, quindi, passavo di lì). Ma non sto parlando di sviluppo, sto parlando di un ambiente sicuro ed efficiente per le applicazioni.
Tecnologia finanziaria (Fintech) vai accanto a Sicurezza delle informazioni (INFOSEC) e il primo può funzionare senza il secondo, ma non per molto. Ecco perché voglio condividere la mia esperienza e l'insieme di strumenti che utilizzo, che li include entrambi FintechE INFOSEC, e allo stesso tempo, e può essere utilizzato anche per uno scopo più ampio o completamente diverso. In questo articolo ti parlerò non tanto di Bitcoin, ma del modello di infrastruttura per lo sviluppo e il funzionamento dei servizi finanziari (e non solo), in una parola, quei servizi in cui conta la “B”. Ciò vale sia per lo scambio Bitcoin che per il più tipico zoo aziendale di servizi di una piccola azienda non collegata in alcun modo a Bitcoin.
Vorrei sottolineare che sono un sostenitore dei principi "mantienilo stupido e semplice" и "meno è meglio", pertanto, sia l'articolo che quanto in esso descritto avranno le proprietà di cui trattano questi principi.
Scenario immaginario: Diamo un'occhiata a tutto usando l'esempio di uno scambiatore di bitcoin. Abbiamo deciso di lanciare lo scambio di rubli, dollari, euro con bitcoin e viceversa, e abbiamo già una soluzione funzionante, ma per altri soldi digitali come qiwi e webmoney, ad es. Abbiamo chiuso tutte le questioni legali, abbiamo un'applicazione già pronta che funge da gateway di pagamento per rubli, dollari ed euro e altri sistemi di pagamento. È collegato ai nostri conti bancari e dispone di una sorta di API per le nostre applicazioni finali. Abbiamo anche un'applicazione web che funge da scambiatore per gli utenti, beh, come un tipico account qiwi o webmoney: crea un account, aggiungi una carta e così via. Comunica con la nostra applicazione gateway, anche se tramite l'API REST in ambito locale. E così abbiamo deciso di connettere i bitcoin e allo stesso tempo aggiornare l'infrastruttura, perché... Inizialmente tutto veniva montato in fretta e furia su virtualbox in ufficio sotto il tavolo... il sito cominciò ad essere utilizzato e cominciammo a preoccuparci dei tempi di attività e delle prestazioni.
Quindi iniziamo con la cosa principale: scegliere un server. Perché l'attività nel nostro esempio è piccola e ci fidiamo dell'hoster (OVH) che sceglieremo in cui è impossibile installare il sistema dall'immagine .iso originale, ma non importa, il dipartimento di sicurezza IT analizzerà sicuramente l'immagine installata. E quando saremo grandi, affitteremo il nostro armadio sotto chiave con accesso fisico limitato, e forse costruiremo il nostro DC. In ogni caso, vale la pena ricordare che quando si noleggia l'hardware e si installano immagini già pronte, c'è la possibilità che sul sistema sia appeso un "Trojan dell'hoster", che nella maggior parte dei casi non ha lo scopo di spiarti ma per offrire server di strumenti di gestione più convenienti.
Installazione del server
Tutto è semplice qui. Scegliamo l'hardware adatto alle nostre esigenze. Quindi seleziona l'immagine di FreeBSD. Bene, oppure ci colleghiamo (nel caso di un altro hoster e del nostro hardware) tramite IPMI o con un monitor e inseriamo l'immagine .iso di FreeBSD nel download. Per un setup orchestrale utilizzo и . L'unica cosa, nel nostro caso con kimsufi, abbiamo scelto installazione personalizzata affinché i due dischi nel mirror abbiano solo le partizioni boot e /home “aperte”, il resto dello spazio su disco verrà crittografato, ma ne parleremo più avanti.
L'installazione del sistema avviene in modo standard, non mi soffermerò su questo, noterò solo che prima di iniziare l'operazione vale la pena prestare attenzione tempra opzioni che offre bsdinstaller al termine dell'installazione (se installi il sistema da solo):
C'è su questo argomento lo ripeterò brevemente qui.
È possibile abilitare i parametri sopra indicati anche su un impianto già installato. Per fare ciò, è necessario modificare il file del bootloader e abilitare i parametri del kernel. *ee è un editor come questo 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=1Dovresti anche assicurarti di avere installata la versione più recente del sistema e . Nel nostro caso, ad esempio, è necessario un aggiornamento all'ultima versione, perché... le immagini pre-installazione restano indietro da sei mesi a un anno. Bene, lì cambiamo la porta SSH in qualcosa di diverso da quella predefinita, aggiungiamo l'autenticazione con chiave e disabilitiamo l'autenticazione con password.
Quindi configuriamo aide, monitorando lo stato dei file di configurazione del sistema. Puoi leggere più in dettaglio .
pkg install aide
e modifica 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/$MYFILENAMEIncludiamo
sysrc auditd_enable=YES
# service auditd start
Come amministrare questa materia è perfettamente descritto in .
Ora riavviamo e procediamo al software sul server. Ogni server è un hypervisor per contenitori o macchine virtuali complete. Pertanto, è importante che il processore supporti VT-x ed EPT se intendiamo utilizzare la virtualizzazione completa.
Per gestire contenitori e macchine virtuali utilizzo от , Gli auguro più salute e benedizioni per questa meravigliosa utilità!
Contenitori? Di nuovo Docker o cosa?
E qui no. è uno strumento eccellente per la containerizzazione, ma il menzionato cbsd per orchestrare questi contenitori, che sono chiamati celle.
La gabbia è una soluzione estremamente efficace per costruire infrastrutture per una varietà di scopi, dove in definitiva è richiesto il completo isolamento dei singoli servizi o processi. Essenzialmente è un clone del sistema host, ma non richiede la virtualizzazione completa dell'hardware. E grazie a ciò, le risorse non vengono spese per il "sistema operativo guest", ma solo per il lavoro svolto. Quando le celle vengono utilizzate per esigenze interne, questa è una soluzione molto conveniente per un utilizzo ottimale delle risorse: un gruppo di celle su un server hardware può utilizzare ciascuna individualmente l'intera risorsa del server, se necessario. Considerando che solitamente diversi sottoservizi necessitano di ulteriori. risorse in momenti diversi, è possibile ottenere le massime prestazioni da un server se si pianifica e bilancia adeguatamente le celle tra i server. Se necessario, alle celle possono essere assegnate anche restrizioni sulla risorsa utilizzata.
E la virtualizzazione completa?
Per quanto ne so cbsd sostiene il lavoro bhyve e hypervisor XEN. Non ho mai usato il secondo, ma il primo è relativamente nuovo . Vedremo un esempio di utilizzo bhyve nell'esempio seguente.
Installazione e configurazione dell'ambiente host
Usiamo FS . Questo è uno strumento estremamente potente per la gestione dello spazio del server. Grazie a ZFS, puoi creare direttamente array di varie configurazioni dai dischi, espandere dinamicamente lo spazio "a caldo", cambiare dischi morti, gestire istantanee e molto altro ancora, che può essere descritto in tutta una serie di articoli. Torniamo al nostro server e ai suoi dischi. All'inizio dell'installazione, abbiamo lasciato spazio libero sui dischi per le partizioni crittografate. Perché? In questo modo il sistema si attiva automaticamente e ascolta tramite SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
aggiungere una partizione del disco allo spazio rimanente
geli init /dev/ada0p4
inserisci la nostra password di crittografia
geli attach /dev/ada0p4
Inseriamo nuovamente la password e abbiamo un dispositivo /dev/ada0p4.eli: questo è il nostro spazio crittografato. Quindi ripetiamo lo stesso per /dev/ada1 e il resto dei dischi nell'array. E ne creiamo uno nuovo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - Bene, abbiamo pronto il kit di combattimento minimo. Un array di dischi con mirroring nel caso in cui uno dei tre fallisca.
Creazione di un dataset su un nuovo “pool”
zfs create vms/jails
pkg install cbsd — abbiamo creato un team e istituito la gestione delle nostre cellule.
Dopo cbsd installato, deve essere inizializzato:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Bene, rispondiamo a una serie di domande, per lo più con risposte predefinite.
*Se stai utilizzando la crittografia, è importante che il daemon cbsdd non si avvia automaticamente finché non decidi i dischi manualmente o automaticamente (nel nostro esempio questo viene fatto da zabbix)
**Inoltre non utilizzo NAT from cbsd, e lo configuro da solo pf.
# sysrc pf_enable=YES
# ee /etc/pf.conf
IF_PUBLIC="em0"
IP_PUBLIC="1.23.34.56"
JAIL_IP_POOL="192.168.0.0/24"
#WHITE_CL="{ 127.0.0.1 }"
icmp_types="echoreq"
set limit { states 20000, frags 20000, src-nodes 20000 }
set skip on lo0
scrub in all
#NAT for jails
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Bitcoin network port forward
IP_JAIL="192.168.0.1"
PORT_JAIL="{8333}"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL
# service pf start
# pfctl -f /etc/pf.conf
Anche l'impostazione delle policy del firewall è un argomento separato, quindi non approfondirò l'impostazione della policy BLOCK ALL e dell'impostazione delle whitelist, puoi farlo leggendo o uno qualsiasi degli enormi numeri di articoli disponibili su Google.
Bene... abbiamo installato CBD, è ora di creare il nostro primo cavallo di battaglia: il demone Bitcoin in gabbia!
cbsd jconstruct-tui
Qui vediamo la finestra di dialogo per la creazione della cella. Dopo che tutti i valori sono stati impostati, creiamo!
Quando crei la tua prima cella, dovresti scegliere cosa usare come base per le celle. Seleziono una distribuzione dal repository di FreeBSD con il comando repo. Questa scelta viene effettuata solo quando si crea la prima cella di una versione specifica (è possibile ospitare celle di qualsiasi versione precedente a quella host).
Dopo aver installato tutto, lanciamo la gabbia!
# cbsd jstart bitcoind
Ma dobbiamo installare il software nella gabbia.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind per entrare nella console cellulare
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
C'è Bitcoin nella gabbia, ma abbiamo bisogno dell'anonimato perché vogliamo connetterci ad alcune gabbie tramite la rete TOP. In generale, prevediamo di eseguire la maggior parte delle celle con software sospetto solo tramite un proxy. Grazie a pf Puoi disabilitare il NAT per un certo intervallo di indirizzi IP sulla rete locale e consentire il NAT solo per il nostro nodo TOR. Pertanto, anche se il malware entra nella cella, molto probabilmente non comunicherà con il mondo esterno e, in tal caso, non rivelerà l'IP del nostro server. Pertanto, creiamo un'altra cella per "inoltrare" i servizi come servizio ".onion" e come proxy per l'accesso a Internet alle singole celle.
# 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
Imposta per ascoltare su un indirizzo locale (disponibile per tutte le celle)
SOCKSPort 192.168.0.2:9050
Di cos’altro abbiamo bisogno per la completa felicità? Sì, abbiamo bisogno di un servizio per il nostro web, forse più di uno. Lanciamo nginx, che fungerà da reverse-proxy e si occuperà di rinnovare i certificati Let's Encrypt
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
E così abbiamo messo 150 MB di dipendenze in una gabbia. E l'host è ancora pulito.
Torniamo più tardi alla configurazione di nginx, dobbiamo creare altre due celle per il nostro gateway di pagamento su nodejs e ruggine e un'applicazione web, che per qualche motivo è in Apache e PHP, e quest'ultima richiede anche 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
Successivamente scarichiamo la nostra applicazione con git e la lanciamo.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
Pacchetti da 450 MB. in una gabbia.
qui diamo allo sviluppatore l'accesso tramite SSH direttamente al cellulare, lì faranno tutto da soli:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 - cambia la porta SSH della cella con una qualsiasi
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Bene, il servizio è in esecuzione, non resta che aggiungere la regola pf firewall
Vediamo che IP hanno le nostre cellule e come si presenta in generale la nostra “zona 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 aggiungi 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
Bene, visto che siamo qui, aggiungiamo anche una regola per il proxy inverso:
## 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
Bene, ora parliamo un po’ dei bitcoin
Quello che abbiamo è un'applicazione web esposta esternamente e che comunica localmente con il nostro gateway di pagamento. Ora dobbiamo preparare un ambiente di lavoro per interagire con la rete Bitcoin stessa: il nodo bitcoind è solo un demone che mantiene aggiornata la copia locale della blockchain. Questo demone ha funzionalità RPC e portafoglio, ma esistono "wrapper" più convenienti per lo sviluppo di applicazioni. Per cominciare, abbiamo deciso di mettere electrum è un portafoglio CLI. lo useremo come “cold storage” per i nostri bitcoin - in generale, quei bitcoin che dovranno essere conservati “fuori” dal sistema accessibile agli utenti e generalmente lontano da tutti. Ha anche una GUI, quindi utilizzeremo lo stesso portafoglio sul nostro
computer portatili. Per ora utilizzeremo Electrum con server pubblici e in seguito lo solleveremo in un'altra cella per non dipendere affatto da nessuno.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
altri 700 MB di software nella nostra gabbia
electrum:/@[8:53] # adduser
Username: wallet
Full name:
Uid (Leave empty for default):
Login group [wallet]:
Login group is wallet. Invite wallet into other groups? []:
Login class [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Home directory [/home/wallet]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]:
Username : wallet
Password : <disabled>
Full Name :
Uid : 1001
Class :
Groups : wallet
Home : /home/wallet
Home Mode :
Shell : /bin/tcsh
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (wallet) to the user database.
Add another user? (yes/no): no
Goodbye!
electrum:/@[8:53] # su walletelectrum:/@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Please keep your seed in a safe place; if you lose it, you will not be able to restore your wallet.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}Ora abbiamo creato un portafoglio.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
A noi on-catena D'ora in poi solo un numero limitato di persone potrà connettersi al portafoglio. Per non aprire l'accesso a questa cella dall'esterno, le connessioni tramite SSH avverranno tramite TOP (una versione decentralizzata della VPN). Lanciamo 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
Adesso spegniamo il cellulare con l’accesso a Internet del portafoglio. Diamogli un indirizzo IP da un altro spazio di sottorete che non è NAT. Per prima cosa cambiamo /etc/pf.conf sull'ospite
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" cambiamolo in JAIL_IP_POOL="192.168.0.0/25", quindi tutti gli indirizzi 192.168.0.126-255 non avranno accesso diretto a Internet. Una sorta di rete software “air-gap”. E la regola NAT rimane la stessa
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Sovraccaricare le regole
# pfctl -f /etc/pf.conf
Ora prendiamo il nostro cellulare
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Remove old IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Setup new IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, ma ora il sistema stesso smetterà di funzionare per noi. Tuttavia, possiamo specificare un proxy di sistema. Ma c'è una cosa, su TOR è un proxy SOCKS5, e per comodità vorremmo anche 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
Bene, ora ci sono due server proxy nel nostro sistema ed entrambi restituiscono tramite TOR: calzini5://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:8123Bene, ora la shell funzionerà da un proxy. Se vogliamo installare pacchetti, allora dovremmo aggiungere a /usr/local/etc/pkg.conf da sotto la radice della gabbia
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Bene, ora è il momento di aggiungere il servizio nascosto TOR come indirizzo del nostro servizio SSH nella gabbia 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.onionQuesto è il nostro indirizzo di connessione. Controlliamo dal computer 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@localBene, da una 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
attaccare (Affinché funzioni, è necessario un demone TOR locale in ascolto su 9050)
user@local ~$ ssh remotebtc
The authenticity of host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) to the list of known hosts.
FreeBSD 12.1-RELEASE-p1 GENERIC
To save disk space in your home directory, compress files you rarely
use with "gzip filename".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Успех!
Per lavorare con pagamenti istantanei e micropagamenti, abbiamo bisogno anche di un nodo , infatti, questo sarà il nostro principale strumento di lavoro con Bitcoin. U*che useremo come demone , che è un'interfaccia HTTP (REST) a tutti gli effetti e ti consente di lavorare sia con transazioni off-chain che on-chain. c-lightning necessari per il funzionamento bitcoind ma si.
*Esistono diverse implementazioni del protocollo Lightning Network in diverse lingue. Di quelli che abbiamo testato, c-lightning (scritto in C) sembrava il più stabile ed efficiente in termini di risorse
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/@[10:23] # adduser
Username: lightning
...lightning:/@[10:24] # pkg install git
lightning:/@[10:23] # su lightning
cd ~ && git clone https://github.com/ElementsProject/lightning
lightning@lightning:~ % exit
lightning:/@[10:30] # cd /home/lightning/lightning/
lightning:/home/lightning/lightning@[10:31] # pkg install autoconf automake gettext git gmp gmake libtool python python3 sqlite3 libsodium py36-mako bash bitcoin-utils
lightning:/home/lightning/lightning@[10:34] # ./configure && gmake && gmake install
Mentre tutto il necessario viene compilato e installato, creiamo un utente RPC per lightningd в bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#allow only c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Il mio passaggio caotico tra le celle risulta non essere così caotico se si nota l'utilità tmux, che consente di creare più sottosessioni del terminale all'interno di una sessione. Analogico: screen
Quindi, non vogliamo rivelare il vero IP del nostro nodo e vogliamo condurre tutte le transazioni finanziarie tramite TOP. Pertanto non è necessaria un'altra cipolla.
# 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 una 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
# sparko plugin
# https://github.com/fiatjaf/lightningd-gjson-rpc/tree/master/cmd/sparko
sparko-host=192.168.0.7
sparko-port=9737
sparko-tls-path=sparko-tls
#sparko-login=mywalletusername:mywalletpassword
#sparko-keys=masterkey;secretread:+listchannels,+listnodes;secretwrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
sparko-keys=masterkey;secretread:+listchannels,+listnodes;ultrawrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
# for the example above the initialization logs (mixed with lightningd logs) should print something likelightning@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 ~
devi anche creare un file di configurazione per bitcoin-cli, un'utilità con cui comunica bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testdai un'occhiata
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]lancio lightningd
lightning@lightning:~ % lightningd --daemon
Se stesso lightningd puoi controllare l'utilità lightning-cli, ad esempio:
lightning-cli newaddr ottenere l'indirizzo per un nuovo pagamento in entrata
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all invia tutto il denaro nel portafoglio all'indirizzo (tutti gli indirizzi on-chain)
Comandi anche per operazioni fuori catena lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay e così via
Bene, 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'
Riassumere
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoind
2 192.168.0.2 tor.space.com /zroot/jails/jails/tor
3 192.168.0.3 nginx-rev.space.com /zroot/jails/jails/nginx-rev
4 192.168.0.4 paygw.space.com /zroot/jails/jails/paygw
5 192.168.0.5 webapp.my.domain /zroot/jails/jails/webapp
7 192.168.0.200 electrum.space.com /zroot/jails/jails/electrum
8 192.168.0.6 polipo.space.com /zroot/jails/jails/polipo
9 192.168.0.7 lightning.space.com /zroot/jails/jails/cln
Disponiamo di una serie di contenitori, ciascuno con il proprio livello di accesso sia da che verso la rete locale.
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 279G 1.48T 88K /zroot
zroot/ROOT 1.89G 1.48T 88K none
zroot/ROOT/default 1.89G 17.6G 1.89G /
zroot/home 88K 1.48T 88K /home
zroot/jails 277G 1.48T 404M /zroot/jails
zroot/jails/bitcoind 190G 1.48T 190G /zroot/jails/jails-data/bitcoind-data
zroot/jails/cln 653M 1.48T 653M /zroot/jails/jails-data/cln-data
zroot/jails/electrum 703M 1.48T 703M /zroot/jails/jails-data/electrum-data
zroot/jails/nginx-rev 190M 1.48T 190M /zroot/jails/jails-data/nginx-rev-data
zroot/jails/paygw 82.4G 1.48T 82.4G /zroot/jails/jails-data/paygw-data
zroot/jails/polipo 57.6M 1.48T 57.6M /zroot/jails/jails-data/polipo-data
zroot/jails/tor 81.5M 1.48T 81.5M /zroot/jails/jails-data/tor-data
zroot/jails/webapp 360M 1.48T 360M /zroot/jails/jails-data/webapp-dataCome puoi vedere, bitcoind occupa tutti i 190 GB di spazio. Cosa succede se abbiamo bisogno di un altro nodo per i test? È qui che ZFS torna utile. Con aiuto cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com puoi creare un'istantanea e allegare una nuova cella a questa istantanea. La nuova cella avrà un suo spazio, ma nel file system verrà presa in considerazione solo la differenza tra lo stato attuale e quello originale (salveremo almeno 190 GB)
Ogni cella ha il proprio set di dati ZFS separato e questo è estremamente conveniente. fai varie altre cose interessanti, come inviare istantanee tramite SSH. Non lo descriveremo, c’è già molto.
Vale anche la pena notare la necessità del monitoraggio remoto dell'host, di cui disponiamo per questi scopi .
B-sicurezza
Per quanto riguarda la sicurezza, partiamo dai principi chiave in ambito infrastrutturale:
Riservatezza - Gli strumenti standard dei sistemi simili a UNIX garantiscono l'attuazione di questo principio. Separiamo logicamente l'accesso a ciascun elemento logicamente separato del sistema: una cella. L'accesso viene fornito tramite l'autenticazione utente standard utilizzando le chiavi personali degli utenti. Tutte le comunicazioni tra e verso le celle terminali avvengono in forma crittografata. Grazie alla crittografia del disco non dobbiamo preoccuparci della sicurezza dei dati durante la sostituzione del disco o la migrazione su un altro server. L'unico accesso critico è l'accesso al sistema host, poiché tale accesso generalmente fornisce l'accesso ai dati all'interno dei contenitori.
integrità “L’attuazione di questo principio avviene a diversi livelli. In primo luogo, è importante notare che nel caso dell'hardware del server, della memoria ECC, ZFS già “pronto all'uso” si prende cura dell'integrità dei dati a livello di bit di informazione. Le istantanee istantanee ti consentono di eseguire backup in qualsiasi momento al volo. I pratici strumenti di esportazione/importazione delle cellule semplificano la replicazione delle cellule.
Disponibilità - Questo è già facoltativo. Dipende dal grado della tua fama e dal fatto che hai degli haters. Nel nostro esempio ci siamo assicurati che il portafoglio fosse accessibile esclusivamente dalla rete TOP. Se necessario, puoi bloccare tutto sul firewall e consentire l'accesso al server esclusivamente tramite tunnel (TOR o VPN è un'altra questione). In questo modo il server sarà il più possibile isolato dal mondo esterno e solo noi stessi potremo influenzarne la disponibilità.
Impossibilità di rifiuto - E questo dipende dall'ulteriore funzionamento e dal rispetto delle politiche corrette per i diritti utente, l'accesso, ecc. Ma con il giusto approccio, tutte le azioni dell'utente vengono controllate e grazie a soluzioni crittografiche è possibile identificare in modo inequivocabile chi ha eseguito determinate azioni e quando.
Naturalmente, la configurazione descritta non è un esempio assoluto di come dovrebbe essere sempre, è piuttosto un esempio di come può essere, pur mantenendo capacità di scalabilità e personalizzazione molto flessibili.
E la virtualizzazione completa?
Puoi farlo sulla virtualizzazione completa utilizzando CBD . Lo aggiungerò solo per lavoro bhyve È necessario abilitare alcune opzioni del kernel.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Quindi, se improvvisamente c'è bisogno di avviare un docker, allora solleviamo alcuni debian e vai!
Tutto qui
Immagino che fosse tutto ciò che volevo condividere. Se ti è piaciuto l'articolo, puoi inviarmi dei bitcoin - . Se vuoi provare le celle in azione e avere dei bitcoin, puoi andare sul mio .
Fonte: habr.com
