Va succeir que de professió sóc administrador de sistemes informàtics i xarxes (en resum: administrador de sistemes), i vaig tenir l'oportunitat de dir-ho al professor durant una mica més de 10 anys. les activitats d'una gran varietat de sistemes, inclosos els que requereixen mesures de seguretat [extremes]. També va passar que fa un temps ho vaig trobar interessant , i no només el va utilitzar, sinó que també va llançar diversos microserveis per tal d'aprendre a treballar de manera independent amb la xarxa Bitcoin (p2p després de tot) des del punt de vista d'un desenvolupador (per descomptat sóc un d'aquests dev, doncs, jo passava). Però no parlo de desenvolupament, parlo d'un entorn segur i eficient per a les aplicacions.
Tecnologia financera (Fintech) anar al costat de la seguretat de la informació (infosec) i el primer pot funcionar sense el segon, però no durant molt de temps. Per això vull compartir la meva experiència i el conjunt d'eines que faig servir, que inclou totes dues FintechI infosec, i al mateix temps, i també es pot utilitzar per a un propòsit més ampli o completament diferent. En aquest article us parlaré no tant sobre Bitcoin, sinó sobre el model d'infraestructura per al desenvolupament i l'operació de serveis financers (i no només), en una paraula, aquells serveis on la "B" importa. Això s'aplica tant a l'intercanvi de Bitcoin com al zoo corporatiu més típic de serveis d'una petita empresa no connectada amb Bitcoin de cap manera.
M'agradaria assenyalar que sóc partidari dels principis "Fes-ho estúpid simple" и "menys és més", per tant, tant l'article com el que s'hi descriu tindran les propietats de què tracten aquests principis.
Escenari imaginari: Vegem-ho tot utilitzant l'exemple d'un intercanviador de bitcoins. Vam decidir llançar l'intercanvi de rubles, dòlars, euros per bitcoins i tornar, i ja tenim una solució que funciona, però per a altres diners digitals com qiwi i webmoney, és a dir. Hem tancat tots els problemes legals, tenim una aplicació ja feta que serveix com a passarel·la de pagament per a rubles, dòlars i euros i altres sistemes de pagament. Està connectat als nostres comptes bancaris i té algun tipus d'API per a les nostres aplicacions finals. També tenim una aplicació web que actua com a intercanviador per als usuaris, bé, com un compte típic de qiwi o webmoney: creeu un compte, afegiu una targeta, etc. Es comunica amb la nostra aplicació de passarel·la, encara que a través de l'API REST a l'àrea local. I així vam decidir connectar bitcoins i alhora actualitzar la infraestructura, perquè... Inicialment, tot es va posar de pressa en virtualboxes a l'oficina sota la taula... el lloc es va començar a utilitzar i ens vam començar a preocupar pel temps i el rendiment.
Per tant, comencem amb el més important: triar un servidor. Perquè el negoci del nostre exemple és petit i confiem en l'hoster (OVH) que triarem en què és impossible instal·lar el sistema a partir de la imatge .iso original, però no importa, el departament de seguretat informàtica definitivament analitzarà la imatge instal·lada. I quan siguem grans, llogarem el nostre propi armari amb clau i accés físic limitat, i potser construirem el nostre propi DC. En qualsevol cas, val la pena recordar que quan llogueu maquinari i instal·leu imatges ja fetes, hi ha la possibilitat que tingueu un "troià de l'hoster" penjat al vostre sistema, que en la majoria dels casos no pretén espiar-vos. sinó per oferir un servidor d'eines de gestió més convenient.
Instal·lació del servidor
Aquí tot és senzill. Triem el maquinari que s'adapti a les nostres necessitats. A continuació, seleccioneu la imatge de FreeBSD. Bé, o ens connectem (en el cas d'un altre hoster i el nostre propi maquinari) mitjançant IPMI o amb un monitor i introduïm la imatge .iso FreeBSD a la descàrrega. Per a una configuració orquestral que faig servir и . L'únic, en el nostre cas amb kimsufi, vam triar instal · lació personalitzada perquè els dos discs de la rèplica només tinguin "obertes" les particions d'arrencada i /home, la resta de l'espai del disc s'encriptarà, però en parlarem més endavant.
La instal·lació del sistema es fa d'una manera estàndard, no em detendré en això, només notaré que abans de començar a funcionar val la pena parar atenció a enduriment opcions que ofereix bsdinstaller al final de la instal·lació (si instal·leu el sistema vosaltres mateixos):
Hi sobre aquest tema, ho repetiré breument aquí.
També és possible habilitar els paràmetres esmentats anteriorment en un sistema ja instal·lat. Per fer-ho, heu d'editar el fitxer del carregador d'arrencada i habilitar els paràmetres del nucli. *ee és un editor com aquest a 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=1També hauríeu d'assegurar-vos que teniu instal·lada la darrera versió del sistema i . En el nostre cas, per exemple, cal una actualització a la darrera versió, perquè... les imatges prèvies a la instal·lació es queden entre sis mesos i un any. Bé, allà canviem el port SSH per una cosa diferent del predeterminat, afegim l'autenticació de clau i desactivem l'autenticació de contrasenya.
Després configurem aide, supervisant l'estat dels fitxers de configuració del sistema. Podeu llegir més detalladament .
pkg install aide
i editeu el nostre 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/$MYFILENAMEIncloem
sysrc auditd_enable=YES
# service auditd start
Com administrar aquest assumpte es descriu perfectament a .
Ara reiniciem i passem al programari del servidor. Cada servidor és un hipervisor per a contenidors o màquines virtuals completes. Per tant, és important que el processador admeti VT-x i EPT si pensem utilitzar la virtualització completa.
Per gestionar contenidors i màquines virtuals que faig servir d' , li desitjo més salut i benediccions per aquesta meravellosa utilitat!
Contenidors? Docker de nou o què?
Però no. és una excel·lent eina per a la contenidorització, però l'esmentada cbsd per orquestrar aquests contenidors, que s'anomenen cèl·lules.
La gàbia és una solució extremadament eficaç per a la construcció d'infraestructures per a diversos propòsits, on finalment es requereix un aïllament complet dels serveis o processos individuals. Essencialment, és un clon del sistema amfitrió, però no requereix una virtualització completa del maquinari. I gràcies a això, els recursos no es gasten en el "SO convidat", sinó només en el treball que s'està realitzant. Quan les cel·les s'utilitzen per a necessitats internes, aquesta és una solució molt convenient per a un ús òptim dels recursos: un munt de cel·les en un servidor de maquinari poden utilitzar individualment tot el recurs del servidor si cal. Tenint en compte que normalment els diferents subserveis necessiten addicionals. recursos en diferents moments, podeu extreure el màxim rendiment d'un servidor si planifiqueu i equilibreu correctament les cel·les entre servidors. Si cal, les cel·les també poden tenir restriccions sobre el recurs utilitzat.
Què passa amb la virtualització completa?
Pel que jo sé cbsd dóna suport a la feina bhyve i hipervisors XEN. No he utilitzat mai el segon, però el primer és relativament nou . Veurem un exemple d'ús bhyve a l'exemple següent.
Instal·lació i configuració de l'entorn amfitrió
Utilitzem FS . Aquesta és una eina extremadament potent per gestionar l'espai del servidor. Gràcies a ZFS, podeu crear directament matrius de diverses configuracions des de discs, ampliar l'espai dinàmicament "calent", canviar discs morts, gestionar instantànies i molt, molt més, que es pot descriure en tota una sèrie d'articles. Tornem al nostre servidor i als seus discs. Al començament de la instal·lació, vam deixar espai lliure als discs per a les particions xifrades. Per què això? Això és perquè el sistema es desperti automàticament i escolti mitjançant SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
afegir una partició de disc a l'espai restant
geli init /dev/ada0p4
introduïu la nostra contrasenya de xifratge
geli attach /dev/ada0p4
Tornem a introduir la contrasenya i tenim un dispositiu /dev/ada0p4.eli: aquest és el nostre espai xifrat. A continuació, repetim el mateix per a /dev/ada1 i la resta de discs de la matriu. I en creem un de nou .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - Bé, tenim el kit de combat mínim preparat. Una matriu reflectida de discs en cas que un dels tres falla.
Creació d'un conjunt de dades en un nou "pool"
zfs create vms/jails
pkg install cbsd — vam posar en marxa un equip i vam muntar la gestió de les nostres cèl·lules.
Després cbsd instal·lat, cal inicialitzar-lo:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Bé, responem un munt de preguntes, la majoria amb respostes predeterminades.
*Si utilitzeu xifratge, és important que el dimoni cbsdd no es va iniciar automàticament fins que desxifrau els discs manualment o automàticament (al nostre exemple ho fa zabbix)
**Tampoc faig servir NAT de cbsd, i el configure jo mateix 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
La configuració de polítiques de tallafoc també és un tema a part, així que no aprofundiré en la configuració de la política BLOQUEA TOT i en la configuració de llistes blanques, podeu fer-ho llegint o qualsevol dels enormes articles disponibles a Google.
Bé... tenim cbsd instal·lat, és hora de crear el nostre primer cavall de batalla: el dimoni Bitcoin engabiat!
cbsd jconstruct-tui
Aquí veiem el diàleg de creació de cel·les. Després d'haver establert tots els valors, creem!
Quan creeu la vostra primera cel·la, heu de triar què utilitzar com a base per a les cel·les. Selecciono una distribució del dipòsit de FreeBSD amb l'ordre repo. Aquesta elecció només es fa quan es crea la primera cel·la d'una versió específica (podeu allotjar cel·les de qualsevol versió que sigui més antiga que la versió de l'amfitrió).
Després que tot estigui instal·lat, posem en marxa la gàbia!
# cbsd jstart bitcoind
Però hem d'instal·lar programari a la gàbia.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind per entrar a la consola cel·lular
i ja dins de la cel·la instal·lem el programari amb les seves dependències (el nostre sistema host roman net)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Hi ha Bitcoin a la gàbia, però necessitem l'anonimat perquè volem connectar-nos a algunes gàbies mitjançant la xarxa TOP. En general, tenim previst executar la majoria de cel·les amb programari sospitós només mitjançant un servidor intermediari. Gràcies a pf Podeu desactivar NAT per a un determinat rang d'adreces IP a la xarxa local i permetre NAT només per al nostre node TOR. Així, fins i tot si el programari maliciós entra a la cèl·lula, el més probable és que no es comuniqui amb el món exterior i, si ho fa, no revelarà la IP del nostre servidor. Per tant, creem una altra cel·la per "enviar" serveis com a servei ".onion" i com a proxy per accedir a Internet a cèl·lules individuals.
# 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
Establir per escoltar a una adreça local (disponible per a totes les cel·les)
SOCKSPort 192.168.0.2:9050
Què més necessitem per a la felicitat completa? Sí, necessitem un servei per a la nostra web, potser més d'un. Llencem nginx, que actuarà com a servidor intermediari invers i s'encarregarà de renovar els certificats de Let's Encrypt
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
I així vam col·locar 150 MB de dependències en una gàbia. I l'amfitrió encara està net.
Tornem a configurar nginx més tard, hem d'aixecar dues cel·les més per a la nostra passarel·la de pagament a nodejs i rust i una aplicació web, que per alguna raó està en Apache i PHP, i aquesta última també requereix una base de dades MySQL.
# cbsd jsconstruct-tui
# cbsd jstart paygw
# jexec paygw
paygw:/@[15:55] # pkg install git node npm
paygw:/@[15:55] # curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
...i altres 380 MB de paquets aïllats
A continuació, descarreguem la nostra aplicació amb git i l'iniciem.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
Paquets de 450 MB. en una gàbia.
aquí donem al desenvolupador accés mitjançant SSH directament a la cel·la, ells mateixos ho faran tot:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — Canvieu el port SSH de la cel·la a qualsevol altre arbitrari
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Bé, el servei s'està executant, només queda afegir-hi la regla pf firewall
Vegem quina IP tenen les nostres cèl·lules i com és generalment la nostra "àrea local".
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoind
2 192.168.0.2 tor.space.com /zroot/jails/jails/tor
3 192.168.0.3 nginx-rev.space.com /zroot/jails/jails/nginx-rev
4 192.168.0.4 paygw.space.com /zroot/jails/jails/paygw
5 192.168.0.5 webapp.my.domain /zroot/jails/jails/webappi afegir una regla
# 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
Bé, com que som aquí, també afegim una regla per al proxy invers:
## 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
Bé, ara una mica sobre els bitcoins
El que tenim és que tenim una aplicació web que està exposada externament i que parla localment amb la nostra passarel·la de pagament. Ara hem de preparar un entorn de treball per interactuar amb la pròpia xarxa Bitcoin: el node bitcoind només és un dimoni que manté actualitzada la còpia local de la cadena de blocs. Aquest dimoni té funcionalitat RPC i cartera, però hi ha "embolcalls" més convenients per al desenvolupament d'aplicacions. Per començar, vam decidir posar electrum és una cartera CLI. l'utilitzarem com a "emmagatzematge en fred" per als nostres bitcoins: en general, aquells bitcoins que caldrà emmagatzemar "fora" del sistema accessible als usuaris i, en general, lluny de tothom. També té una GUI, de manera que utilitzarem la mateixa cartera al nostre
portàtils. De moment utilitzarem Electrum amb servidors públics, i més endavant el pujarem en una altra cel·la per no dependre gens de ningú.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
700 MB més de programari a la nostra gàbia
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"
}Ara tenim una cartera creada.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
Al nostre en cadena Només un nombre limitat de persones es podrà connectar a la cartera a partir d'ara. Per tal de no obrir l'accés a aquesta cèl·lula des de l'exterior, les connexions mitjançant SSH es produiran a través de TOP (una versió descentralitzada de VPN). Llencem SSH a la cel·la, però no toqueu el nostre pf.conf a l'amfitrió.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Ara apaguem la cel·la amb accés a Internet de la cartera. Donem-li una adreça IP d'un altre espai de subxarxa que no tingui NAT. Primer canviem /etc/pf.conf a l'amfitrió
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" canviem-ho per JAIL_IP_POOL="192.168.0.0/25", per tant, totes les adreces 192.168.0.126-255 no tindran accés directe a Internet. Una mena de xarxa de programari "aire-gap". I la norma NAT segueix com era
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Sobrecàrrega de les regles
# pfctl -f /etc/pf.conf
Ara agafem el nostre mòbil
# 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, però ara el sistema ens deixarà de funcionar. Tanmateix, podem especificar un servidor intermediari del sistema. Però hi ha una cosa, a TOR és un proxy SOCKS5, i per comoditat també ens agradaria 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
Bé, ara hi ha dos servidors proxy al nostre sistema, i tots dos surten mitjançant TOR: socks5://192.168.0.2:9050 i
Ara podem configurar el nostre entorn de cartera
# 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:8123Bé, ara el shell funcionarà des d'un proxy. Si volem instal·lar paquets, hauríem d'afegir a /usr/local/etc/pkg.conf de sota l'arrel de la gàbia
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Bé, ara és el moment d'afegir el servei ocult TOR com a adreça del nostre servei SSH a la cel·la de la cartera.
# 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.onionAquesta és la nostra adreça de connexió. Comprovem des de la màquina local. Però primer hem d'afegir la nostra clau SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localBé, des d'una màquina 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
Connectem-nos (Per tal que això funcioni, necessiteu un dimoni TOR local que escolti al 9050)
user@local ~$ ssh remotebtc
The authenticity of host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) to the list of known hosts.
FreeBSD 12.1-RELEASE-p1 GENERIC
To save disk space in your home directory, compress files you rarely
use with "gzip filename".
-- Dru <[email protected]>
wallet@electrum:~ % logout
Èxit!
Per treballar amb pagaments instantanis i micro, també necessitem un node , de fet, aquesta serà la nostra principal eina de treball amb Bitcoin. U*que farem servir com a dimoni , que és una interfície HTTP (REST) completa i us permet treballar amb transaccions fora de la cadena i dins de la cadena. c-lightning necessàries per al funcionament bitcoind però sí.
*Hi ha diferents implementacions del protocol Lightning Network en diferents idiomes. Dels que vam provar, c-lightning (escrit en C) semblava el més estable i eficient amb els recursos.
# 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
Tot i que tot el necessari està compilat i instal·lat, creem un usuari 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
El meu canvi caòtic entre cel·les resulta que no és tan caòtic si observeu la utilitat tmux, que us permet crear múltiples subsessions de terminal dins d'una sessió. Analògic: screen
Per tant, no volem revelar la IP real del nostre node i volem realitzar totes les transaccions financeres a través de TOP. Per tant, no cal una altra ceba.
# 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.onionAra creem una configuració per a 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 ~
també heu de crear un fitxer de configuració per a bitcoin-cli, una utilitat amb la qual es comunica bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testcomprovar
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]llançament lightningd
lightning@lightning:~ % lightningd --daemon
Ell mateix lightningd podeu controlar la utilitat lightning-cli, per exemple:
lightning-cli newaddr obtenir l'adreça per a un nou pagament entrant
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all envia tots els diners de la cartera a l'adreça (totes les adreces en cadena)
També ordres per a operacions fora de cadena lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.
Bé, per a la comunicació amb l'aplicació tenim una API REST
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Resumir
# 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
Disposem d'un conjunt de contenidors, cadascun amb el seu propi nivell d'accés tant des de com a la xarxa local.
# 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-dataCom podeu veure, bitcoind ocupa els 190 GB d'espai. Què passa si necessitem un altre node per fer proves? Aquí és on ZFS és útil. Amb ajuda cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com podeu crear una instantània i adjuntar una nova cel·la a aquesta instantània. La nova cel·la tindrà el seu propi espai, però en el sistema de fitxers només es tindrà en compte la diferència entre l'estat actual i l'original (estalviarem almenys 190 GB)
Cada cel·la és el seu propi conjunt de dades ZFS independent, i això és molt convenient. Feu altres coses interessants, com ara enviar instantànies mitjançant SSH. No ho descriurem, ja n'hi ha molt.
També val la pena destacar la necessitat de la monitorització remota de l'amfitrió, a aquests efectes que tenim .
B - seguretat
Pel que fa a la seguretat, partim dels principis clau en el context de la infraestructura:
Confidencialitat - Les eines estàndard de sistemes semblants a UNIX asseguren la implementació d'aquest principi. Separem lògicament l'accés a cada element lògicament separat del sistema: una cel·la. L'accés es proporciona mitjançant l'autenticació d'usuari estàndard mitjançant les claus personals dels usuaris. Tota la comunicació entre i fins al final de les cel·les es produeix en forma xifrada. Gràcies al xifratge de disc, no ens hem de preocupar per la seguretat de les dades quan substituïm un disc o migrem a un altre servidor. L'únic accés crític és l'accés al sistema amfitrió, ja que aquest accés generalment proporciona accés a les dades dins dels contenidors.
Integritat "La implementació d'aquest principi es produeix a diversos nivells diferents. En primer lloc, és important tenir en compte que en el cas del maquinari del servidor, la memòria ECC, ZFS ja "fora de la caixa" té cura de la integritat de les dades a nivell de bits d'informació. Les instantànies instantànies us permeten fer còpies de seguretat en qualsevol moment sobre la marxa. Les pràctiques eines d'exportació/importació de cèl·lules fan que la replicació cel·lular sigui senzilla.
Disponibilitat - Això ja és opcional. Depèn del grau de la teva fama i del fet que tinguis odiadors. En el nostre exemple, ens vam assegurar que la cartera fos accessible exclusivament des de la xarxa TOP. Si cal, podeu bloquejar-ho tot al tallafoc i permetre l'accés al servidor exclusivament a través de túnels (TOR o VPN és una altra qüestió). Així, el servidor es tallarà tant com sigui possible del món exterior i només nosaltres mateixos podrem influir en la seva disponibilitat.
Impossibilitat de denegació - I això depèn del funcionament posterior i del compliment de les polítiques correctes de drets d'usuari, accés, etc. Però amb l'enfocament correcte, totes les accions dels usuaris s'auditen i, gràcies a les solucions criptogràfiques, és possible identificar sense ambigüitats qui ha realitzat determinades accions i quan.
Per descomptat, la configuració descrita no és un exemple absolut de com hauria de ser sempre, sinó més aviat un exemple de com pot ser, tot i que conserva capacitats d'escalat i personalització molt flexibles.
Què passa amb la virtualització completa?
Sobre la virtualització completa amb cbsd podeu . Només ho afegiré per feina bhyve Heu d'habilitar algunes opcions del nucli.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Per tant, si de sobte necessiteu iniciar un docker, instal·leu algun debian i va!
Això és tot
Suposo que això és tot el que volia compartir. Si t'ha agradat l'article, pots enviar-me alguns bitcoins - . Si voleu provar les cèl·lules en acció i tenir alguns bitcoins, podeu anar al meu .
Font: www.habr.com