Aconteceu que de profesión son administrador de sistemas e redes informáticas (en definitiva: administrador de sistemas), e tiven a oportunidade de contarllo á profe hai algo máis de 10 anos. as actividades dunha gran variedade de sistemas, incluídos aqueles que requiren medidas de seguridade [extremas]. Tamén pasou que hai tempo pareceume interesante , e non só o usou, senón que tamén lanzou varios microservizos para aprender a traballar de forma independente coa rede Bitcoin (p2p despois de todo) desde o punto de vista dun programador (eu son, por suposto, un deses). dev, entón eu estaba de paso). Pero non falo de desenvolvemento, falo dun ambiente seguro e eficiente para aplicacións.
Tecnoloxía financeira (FINTECH) vai xunto á seguridade da información (infosec) e o primeiro pode funcionar sen o segundo, pero non por moito tempo. Por iso quero compartir a miña experiencia e o conxunto de ferramentas que uso, que inclúe ambas FINTECHE infosec, e ao mesmo tempo, e tamén se pode usar para un propósito máis amplo ou completamente diferente. Neste artigo falarei non tanto sobre Bitcoin, senón sobre o modelo de infraestrutura para o desenvolvemento e operación de servizos financeiros (e non só), nunha palabra, aqueles servizos nos que importa "B". Isto aplícase tanto ao intercambio de Bitcoin como ao zoolóxico corporativo máis típico de servizos dunha pequena empresa non conectada con Bitcoin de ningún xeito.
Gustaríame sinalar que son partidario dos principios "sénteo sinxelo" и "menos é máis", polo tanto, tanto o artigo como o que nel se describe terán as propiedades das que tratan estes principios.
Escenario imaxinario: Vexamos todo usando o exemplo dun intercambiador de bitcoins. Decidimos lanzar o intercambio de rublos, dólares, euros por bitcoins e volta, e xa temos unha solución de traballo, pero para outros cartos dixitais como qiwi e webmoney, i.e. Pechamos todos os problemas legais, temos unha aplicación preparada que serve como pasarela de pago para rublos, dólares e euros e outros sistemas de pago. Está conectado ás nosas contas bancarias e ten algún tipo de API para as nosas aplicacións finais. Tamén temos unha aplicación web que actúa como un intercambiador para os usuarios, así como unha conta típica de qiwi ou webmoney: crea unha conta, engade unha tarxeta, etc. Comunícase coa nosa aplicación de pasarela, aínda que a través da API REST na área local. E por iso decidimos conectar bitcoins e ao mesmo tempo actualizar a infraestrutura, porque... Inicialmente, todo estaba apurado nas caixas virtuais da oficina debaixo da mesa... o sitio comezou a ser usado e comezamos a preocuparnos polo tempo de actividade e o rendemento.
Entón, imos comezar co principal - escoller un servidor. Porque o negocio do noso exemplo é pequeno e confiamos no hospedador (OVH) que escolleremos no que é imposible instalar o sistema a partir da imaxe .iso orixinal, pero non importa, o departamento de seguridade informática definitivamente analizará a imaxe instalada. E cando sexamos maiores, alugaremos o noso propio armario baixo chave con acceso físico limitado, e quizais construímos o noso propio DC. En calquera caso, convén lembrar que ao alugar hardware e instalar imaxes xa preparadas, existe a posibilidade de que teña un "troiano do servidor" colgado no seu sistema, que na maioría dos casos non pretende espiarche. senón para ofrecer un servidor de ferramentas de xestión máis cómodo.
Instalación do servidor
Aquí todo é sinxelo. Escollemos o hardware que se adapta ás nosas necesidades. A continuación, seleccione a imaxe FreeBSD. Ben, ou conectamos (no caso doutro hoster e hardware propio) a través de IPMI ou cun monitor e alimentamos a imaxe .iso FreeBSD na descarga. Eu uso para unha configuración orquestral и . O único, no noso caso con kimsufi, escollemos instalación personalizada para que os dous discos do espello teñan só as particións de arranque e /home "abertas", o resto do espazo do disco cifrarase, pero máis adiante máis adiante.
A instalación do sistema prodúcese de forma estándar, non vou determe nisto, só notarei que antes de comezar a funcionar paga a pena prestar atención a endurecemento opcións que ofrece bsdinstaller ao final da instalación (se instala o sistema vostede mesmo):
Ten sobre este tema, repetireino brevemente aquí.
Tamén é posible activar os parámetros mencionados anteriormente nun sistema xa instalado. Para iso, cómpre editar o ficheiro do cargador de arranque e activar os parámetros do núcleo. *ee é un editor coma este en 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=1Tamén debes asegurarte de ter instalada a última versión do sistema e . No noso caso, por exemplo, é necesaria unha actualización á última versión, porque... as imaxes previas á instalación quedan entre seis meses e un ano. Ben, alí cambiamos o porto SSH por algo diferente ao predeterminado, engadimos a autenticación de clave e desactivamos a autenticación de contrasinal.
Despois configuramos aide, supervisando o estado dos ficheiros de configuración do sistema. Podes ler máis en detalle .
pkg install aide
e edita o noso 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/$MYFILENAMEIncluímos
sysrc auditd_enable=YES
# service auditd start
Como administrar este asunto descríbese perfectamente en .
Agora reiniciamos e procedemos ao software no servidor. Cada servidor é un hipervisor para contenedores ou máquinas virtuais completas. Polo tanto, é importante que o procesador admita VT-x e EPT se pensamos usar a virtualización completa.
Para xestionar contedores e máquinas virtuais que uso de , Deséxolle máis saúde e bendicións por esta marabillosa utilidade!
Contedores? Docker de novo ou que?
Pero non. é unha excelente ferramenta para a contenerización, pero o mencionado cbsd para orquestrar estes recipientes, que se denominan células.
A gaiola é unha solución extremadamente eficaz para construír infraestruturas para unha variedade de propósitos, onde se require un illamento completo dos servizos ou procesos individuais. Esencialmente, é un clon do sistema host, pero non require unha virtualización de hardware completa. E grazas a iso, os recursos non se gastan no "SO convidado", senón só no traballo que se está a realizar. Cando as celas se usan para necesidades internas, esta é unha solución moi conveniente para o uso óptimo dos recursos: un grupo de celas nun servidor de hardware poden usar individualmente todo o recurso do servidor se é necesario. Tendo en conta que normalmente diferentes subservizos precisan adicionais. recursos en diferentes momentos, pode extraer o máximo rendemento dun servidor se planifica e equilibra correctamente as celas entre os servidores. Se é necesario, tamén se poden dar restricións ás celas sobre o recurso utilizado.
E a virtualización total?
Polo que sei cbsd apoia o traballo bhyve e hipervisores XEN. Nunca usei o segundo, pero o primeiro é relativamente novo . Veremos un exemplo de uso bhyve no exemplo de abaixo.
Instalación e configuración do ambiente host
Usamos FS . Esta é unha ferramenta moi poderosa para xestionar o espazo do servidor. Grazas a ZFS, podes construír directamente matrices de varias configuracións a partir de discos, expandir dinámicamente o espazo "quente", cambiar discos mortos, xestionar instantáneas e moito, moito máis, que se pode describir en toda unha serie de artigos. Volvamos ao noso servidor e aos seus discos. Ao comezo da instalación, deixamos espazo libre nos discos para particións cifradas. Por que é iso? Isto é para que o sistema esperte automaticamente e escoite a través de SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
engadir unha partición de disco ao espazo restante
geli init /dev/ada0p4
introduza o noso contrasinal de cifrado
geli attach /dev/ada0p4
Introducimos de novo o contrasinal e temos un dispositivo /dev/ada0p4.eli: este é o noso espazo cifrado. Despois repetimos o mesmo para /dev/ada1 e para o resto dos discos da matriz. E creamos un novo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - Ben, temos o kit mínimo de combate preparado. Unha matriz espellada de discos no caso de que falle un dos tres.
Creando un conxunto de datos nun novo "pool"
zfs create vms/jails
pkg install cbsd — Puxemos en marcha un equipo e fixemos a xestión das nosas celas.
Despois cbsd instalado, debe ser inicializado:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Ben, respondemos a unha morea de preguntas, a maioría con respostas predeterminadas.
*Se está a usar cifrado, é importante que o daemon cbsdd non se iniciou automaticamente ata que descifraches os discos manualmente ou automaticamente (no noso exemplo faino zabbix)
**Tampouco uso NAT de cbsd, e eu configuroo en 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
Configurar políticas de firewall tamén é un tema separado, polo que non entrarei en profundidade na configuración da política BLOQUEAR TODO e na configuración das listas brancas. Podes facelo lendo ou calquera dos enormes artigos dispoñibles en Google.
Ben... temos cbsd instalado, é hora de crear o noso primeiro cabalo de batalla: o demo Bitcoin engaiolado!
cbsd jconstruct-tui
Aquí vemos o diálogo de creación de celas. Despois de establecer todos os valores, imos crear!
Cando crees a túa primeira cela, debes escoller o que queres usar como base para as celas. Selecciono unha distribución do repositorio de FreeBSD co comando repo. Esta elección realízase só cando se crea a primeira cela dunha versión específica (pode aloxar celas de calquera versión que sexa máis antiga que a versión anfitrión).
Despois de que todo estea instalado, lanzamos a gaiola!
# cbsd jstart bitcoind
Pero necesitamos instalar software na gaiola.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind para entrar na consola celular
e xa dentro da cela instalamos o software coas súas dependencias (o noso sistema host segue limpo)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Hai Bitcoin na gaiola, pero necesitamos o anonimato porque queremos conectarnos a algunhas gaiolas a través da rede TOP. En xeral, pensamos executar a maioría das celas con software sospeitoso só a través dun proxy. Grazas a pf Podes desactivar o NAT para un determinado rango de enderezos IP na rede local e permitir o NAT só para o noso nodo TOR. Así, aínda que o malware entra na cela, o máis probable é que non se comunique co mundo exterior e, se o fai, non revelará a IP do noso servidor. Polo tanto, creamos outra cela para "reenviar" servizos como un servizo ".onion" e como proxy para acceder a Internet a celas individuais.
# 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
Configurar para escoitar nun enderezo local (dispoñible para todas as celas)
SOCKSPort 192.168.0.2:9050
Que máis necesitamos para a felicidade completa? Si, necesitamos un servizo para a nosa web, quizais máis dun. Imos lanzar nginx, que actuará como un proxy inverso e encargarase de renovar os certificados de Let's Encrypt
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
E así colocamos 150 MB de dependencias nunha gaiola. E o anfitrión aínda está limpo.
Volvamos á configuración de nginx máis tarde, necesitamos crear dúas celas máis para a nosa pasarela de pago en nodejs e rust e unha aplicación web, que por algún motivo está en Apache e PHP, e esta última tamén require unha base de datos 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 outros 380 MB de paquetes illados
A continuación, descargamos a nosa aplicación con git e lanzámola.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
Paquetes de 450 MB. nunha gaiola.
aquí dámoslle ao desenvolvedor acceso a través de SSH directamente á cela, eles mesmos farán todo alí:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — cambia o porto SSH da cela a calquera arbitrario
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Ben, o servizo está funcionando, só queda engadir a regra pf cortalumes
Vexamos que IP teñen as nosas células e como é xeralmente a nosa "á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/webappe engade unha regra
# 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
Ben, xa que estamos aquí, imos tamén engadir unha regra para o 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
Ben, agora un pouco sobre bitcoins
O que temos é que temos unha aplicación web que está exposta externamente e que fala localmente coa nosa pasarela de pago. Agora necesitamos preparar un ambiente de traballo para interactuar coa propia rede Bitcoin: o nodo bitcoind é só un daemon que mantén actualizada a copia local da cadea de bloques. Este daemon ten funcionalidade RPC e carteira, pero hai "envoltorios" máis convenientes para o desenvolvemento de aplicacións. Para comezar, decidimos poñer electrum é unha carteira CLI. usarémolo como "almacenamento en frío" para os nosos bitcoins - en xeral, aqueles bitcoins que terán que ser almacenados "fóra" do sistema accesible para os usuarios e xeralmente lonxe de todos. Tamén ten unha GUI, polo que imos usar a mesma carteira na nosa
portátiles. De momento usaremos Electrum con servidores públicos, e máis adiante subirémolo noutra cela para non depender en absoluto de ninguén.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
outros 700 MB de software na nosa gaiola
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"
}Agora temos unha carteira creada.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
Ao noso en cadea Só un número limitado de persoas poderá conectarse á carteira a partir de agora. Para non abrir o acceso a esta cela desde o exterior, as conexións a través de SSH produciranse a través de TOP (unha versión descentralizada de VPN). Lanzamos SSH na cela, pero non tocamos o noso pf.conf no host.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Agora imos apagar o móbil co acceso a Internet da carteira. Dámoslle un enderezo IP doutro espazo de subrede que non teña NAT. Primeiro imos cambiar /etc/pf.conf no anfitrión
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" cambiámolo por JAIL_IP_POOL="192.168.0.0/25", polo que todos os enderezos 192.168.0.126-255 non terán acceso directo a Internet. Unha especie de rede de software "aire-gap". E a regra NAT segue como estaba
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Sobrecargando as regras
# pfctl -f /etc/pf.conf
Agora imos asumir o noso 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, pero agora o propio sistema deixará de funcionar para nós. Non obstante, podemos especificar un proxy do sistema. Pero hai unha cousa, en TOR é un proxy SOCKS5 e, por comodidade, tamén nos gustaría 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
Ben, agora hai dous servidores proxy no noso sistema, e ambos saen a través de TOR: socks5://192.168.0.2:9050 e
Agora podemos configurar o noso contorno de carteira
# 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:8123Ben, agora o shell funcionará desde un proxy. Se queremos instalar paquetes, deberíamos engadir a /usr/local/etc/pkg.conf de debaixo da raíz da gaiola
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Ben, agora é o momento de engadir o servizo oculto TOR como enderezo do noso servizo SSH na gaiola da carteira.
# 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.onionEste é o noso enderezo de conexión. Comprobamos dende a máquina local. Pero primeiro necesitamos engadir a nosa chave SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localBen, desde unha máquina cliente 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
Imos conectar (Para que isto funcione, necesitas un daemon TOR local que escoite en 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
Éxito!
Para traballar con pagos instantáneos e micropagos, tamén necesitamos un nodo , de feito, esta será a nosa principal ferramenta de traballo con Bitcoin. U*que imos usar como un daemon é , que é unha interface HTTP (REST) completa e permite traballar tanto con transaccións fóra da cadea como dentro da cadea. c-lightning necesarios para o seu funcionamento bitcoind pero si.
*Existen diferentes implementacións do protocolo Lightning Network en diferentes idiomas. Dos que probamos, c-lightning (escrito en C) parecía o máis estable e eficiente en 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
Mentres todo o necesario está compilado e instalado, imos crear un usuario RPC para 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
O meu cambio caótico entre as celas non é tan caótico se observas a utilidade tmux, que lle permite crear varias subsesións de terminal nunha mesma sesión. Analóxico: screen
Polo tanto, non queremos revelar a IP real do noso nodo e queremos realizar todas as transaccións financeiras a través de TOP. Polo tanto, non é necesario outro .cebola.
# 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.onionAgora imos crear unha configuración para 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 ~
tamén cómpre crear un ficheiro de configuración para bitcoin-cli, unha utilidade coa que se comunica bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testcomprobar
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]lanzamento lightningd
lightning@lightning:~ % lightningd --daemon
se lightningd pode controlar a utilidade lightning-cli, por exemplo:
lightning-cli newaddr obter o enderezo para un novo pago entrante
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all enviar todo o diñeiro da carteira ao enderezo (todos os enderezos en cadea)
Tamén comandos para operacións fóra da cadea lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.
Pois ben, para a comunicación coa aplicación temos unha 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
Dispoñemos dun conxunto de contedores, cada un co seu propio nivel de acceso tanto desde e á rede 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-dataComo podes ver, bitcoind ocupa os 190 GB de espazo. E se necesitamos outro nodo para probas? Aquí é onde ZFS é útil. Con axuda cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com pode crear unha instantánea e engadir unha nova cela a esta instantánea. A nova cela terá o seu propio espazo, pero no sistema de ficheiros só se terá en conta a diferenza entre o estado actual e o orixinal (aforraremos polo menos 190 GB)
Cada cela é o seu propio conxunto de datos ZFS separado, e isto é moi cómodo. fai outras cousas interesantes, como enviar instantáneas a través de SSH. Non o imos describir, xa hai moito.
Tamén cabe destacar a necesidade de monitorización remota do host, para estes fins temos .
B - seguridade
En canto á seguridade, partimos dos principios clave no contexto da infraestrutura:
Confidencialidade - As ferramentas estándar de sistemas tipo UNIX aseguran a implementación deste principio. Separamos loxicamente o acceso a cada elemento loxicamente separado do sistema: unha cela. O acceso prodúcese mediante a autenticación de usuario estándar mediante as claves persoais dos usuarios. Toda a comunicación entre e ata as células final ocorre en forma cifrada. Grazas ao cifrado do disco, non temos que preocuparnos pola seguridade dos datos ao substituír un disco ou migrar a outro servidor. O único acceso crítico é o acceso ao sistema host, xa que este acceso xeralmente proporciona acceso a datos dentro dos contedores.
Integridade “A implementación deste principio prodúcese en varios niveis diferentes. En primeiro lugar, é importante ter en conta que no caso do hardware do servidor, a memoria ECC, ZFS xa "fóra da caixa" coida a integridade dos datos a nivel de bits de información. As instantáneas instantáneas permítenche facer copias de seguridade en calquera momento sobre a marcha. As prácticas ferramentas de exportación/importación de células fan que a replicación celular sexa sinxela.
Dispoñibilidade - Isto xa é opcional. Depende do grao da túa fama e do feito de que teñas haters. No noso exemplo, asegurámonos de que a carteira fose accesible exclusivamente desde a rede TOP. Se é necesario, pode bloquear todo o firewall e permitir o acceso ao servidor exclusivamente a través de túneles (TOR ou VPN é outra cousa). Así, o servidor estará separado do mundo exterior na medida do posible e só nós mesmos poderemos influír na súa dispoñibilidade.
Imposibilidade de denegación - E isto depende do posterior funcionamento e do cumprimento das políticas correctas de dereitos de usuario, acceso, etc. Pero co enfoque correcto, todas as accións do usuario son auditadas e grazas ás solucións criptográficas é posible identificar sen ambigüidades quen realizou determinadas accións e cando.
Por suposto, a configuración descrita non é un exemplo absoluto de como debería ser sempre, é máis ben un exemplo de como pode ser, aínda que conserva capacidades de escalado e personalización moi flexibles.
E a virtualización total?
Sobre a virtualización completa usando cbsd podes . Só engadirei iso para traballar bhyve Debe activar algunhas opcións do núcleo.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Entón, se de súpeto necesitas iniciar un docker, instala algún debian e listo!
Iso é todo
Supoño que iso é todo o que quería compartir. Se che gustou o artigo, podes enviarme algúns bitcoins - . Se queres probar as células en acción e ter algúns bitcoins, podes ir ao meu .
Fonte: www.habr.com