Aconteceu que sou administrador de sistemas e redes de computadores (em resumo: um sysadmin), e ao longo de mais de 10 anos de atividade profissional, trabalhei com os mais diversos sistemas, incluindo aqueles que exigem medidas de segurança [a|para]cidas. Além disso, há algum tempo, encontrei interessante , e não apenas usei, mas também lancei vários microserviços para aprender a trabalhar sozinho com a rede bitcoin (que é p2p, afinal) do ponto de vista do desenvolvedor (claro que sou apenas um amador dev, só passei por aqui). Mas não estou falando sobre desenvolvimento, e sim sobre um ambiente seguro e eficiente para aplicativos.
As tecnologias financeiras (fintech) andam lado a lado com a segurança da informação (infosec), e o primeiro pode funcionar sem o segundo, mas não por muito tempo. Por isso, quero compartilhar minha experiência e o conjunto de ferramentas que utilizo, que inclui fintech, quanto o infosec, e que podem ser usados simultaneamente, podendo também ser aplicados em um contexto mais amplo ou totalmente diferente. Neste artigo, falarei não apenas sobre bitcoin, mas sobre o modelo de infraestrutura para o desenvolvimento e operação de serviços financeiros (e não apenas) — em resumo, aqueles serviços onde o “B” faz a diferença. Isso se aplica tanto a uma exchange de bitcoin quanto ao típico parque corporativo de serviços de uma pequena empresa que não tem nenhuma relação com bitcoin.
Quero ressaltar que sou a favor dos princípios ‘keep it stupid simple’ e ‘less is more’, portanto, tanto o artigo quanto o que nele é descrito terão as características que esses princípios sugerem.
Cenário hipotético: Vamos explorar tudo por meio de um exemplo de uma casa de câmbio de bitcoin. Decidimos lançar a troca de rublos, dólares e euros por bitcoins e vice-versa, e já temos uma solução funcionando, mas para outras moedas digitais como Qiwi e Webmoney, ou seja, todas as questões legais estão resolvidas, temos um aplicativo pronto que atua como um gateway de pagamento para rublos, dólares e euros, além de outros sistemas de pagamento. Isso está vinculado às nossas contas bancárias e possui alguma API para nossos aplicativos finais. Também temos um aplicativo web que funciona como uma casa de câmbio para os usuários, semelhante a uma conta típica do Qiwi ou Webmoney - crie uma conta, adicione um cartão e assim por diante. Ele se comunica com nosso aplicativo-gateway, mesmo que via REST API em uma rede local. E decidimos conectar bitcoins e ao mesmo tempo atualizar a infraestrutura, pois inicialmente tudo foi rapidamente configurado em VirtualBox no escritório, sob a mesa... o site começou a ser utilizado, e começamos a nos preocupar com a disponibilidade e o desempenho.
Então, vamos começar com o principal - a escolha do servidor. Como o negócio no nosso exemplo é pequeno e confiamos no provedor de hospedagem (OVH), vamos escolher na qual não é possível instalar o sistema a partir da imagem original .iso, mas não tem problema, o departamento de segurança da informação realizará uma análise da imagem instalada. E quando crescermos, poderemos alugar nosso próprio armário com fechadura e acesso físico restrito, ou até mesmo construir nosso próprio data center. De qualquer forma, é importante lembrar que ao alugar hardware e instalar imagens prontas existe a chance de que você tenha um “trojan do provedor de hospedagem” em seu sistema, que na maioria dos casos não é destinado a espioná-lo, mas sim para oferecer ferramentas de gerenciamento de servidor mais convenientes.
Instalação do servidor
Aqui é tudo simples. Escolhemos o hardware que atende às nossas necessidades. Em seguida, escolhemos a imagem do FreeBSD. Ou conectamos (no caso de outro provedor de hospedagem e seu próprio hardware) via IPMI ou com um monitor e carregamos a imagem .iso do FreeBSD. Para instalação orquestrada, utilizo e . A única coisa, no nosso caso com Kimsufi, é que escolhemos instalação personalizada para que os dois discos no espelho tivessem apenas as partições de inicialização e /home "abertas", enquanto o restante do espaço em disco seria criptografado, mas isso será discutido mais tarde.
A instalação do sistema acontece de maneira padrão, não vou me alongar sobre isso, apenas destaco que antes de iniciar a exploração é importante atentar para hardening as opções que oferece bsdinstaller no final da instalação (se você estiver instalando o sistema):
Há sobre este tema, em resumo, aqui eu o vou repetir.
É possível ativar os parâmetros mencionados acima também em um sistema já instalado. Para isso, é necessário editar o arquivo do carregador e habilitar os parâmetros do kernel. *ee — é um editor assim no 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ém é importante garantir que você tenha a versão mais recente do sistema e . No nosso caso, por exemplo, é necessário atualizar para a versão mais recente, pois as imagens pré-instaladas estão desatualizadas em seis meses a um ano. E também mudamos a porta SSH para uma diferente da padrão, adicionamos autenticação por chaves e desativamos a autenticação por senha.
Em seguida, configuramos aide, o monitoramento do estado dos arquivos de configuração do sistema. Para mais informações detalhadas, você pode ler .
pkg install aide
e editamos nosso 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/$MYFILENAMEAtivamos
sysrc auditd_enable=YES
# service auditd start
Como administrar isso está bem descrito em .
Agora reiniciamos e começamos a trabalhar com o software no servidor. Cada servidor é um hipervisores para contêineres ou máquinas virtuais completas. Portanto, é importante que o processador suporte VT-x e EPT se planejarmos usar virtualização completa.
Para gerenciamento de contêineres e máquinas virtuais, utilizo de , desejo muita saúde e bênçãos por esta ferramenta maravilhosa!
Contêineres? É de novo o Docker?
Mas não. — é uma ótima ferramenta para contêinerização, e o mencionado cbsd para a orquestração desses contêineres, chamado — células.
A célula é uma solução extremamente eficaz para a construção de infraestrutura para diversos fins, onde é necessário um isolamento completo de serviços ou processos individuais. Na essência, é um clone do sistema de hospedagem, mas não requer uma virtualização completa do hardware. Assim, os recursos não são desperdiçados em um "sistema operacional convidado", mas apenas na tarefa em execução. Quando as células são usadas para fins internos, isso é uma solução muito conveniente para a utilização ótima dos recursos — um monte de células em um único servidor pode usar todo o recurso do servidor individualmente, conforme necessário. Considerando que geralmente diferentes subsistemas precisam de recursos adicionais em momentos diferentes, pode-se tirar o máximo desempenho de um servidor, se as células forem planejadas e balanceadas corretamente entre os servidores. Se necessário, as células também podem ter suas limitações de uso de recursos configuradas.
E quanto à virtualização completa?
Até onde eu sei, cbsd suporta bhyve e hipervisores XEN. Nunca utilizei o segundo, mas o primeiro é um hipervisor relativamente novo . Vamos considerar um exemplo de uso bhyve no exemplo a seguir.
Instalação e configuração do ambiente do host
Estamos usando o sistema de arquivos . Este é um instrumento extremamente poderoso para gerenciar espaço em um servidor. Graças ao ZFS, é possível construir diretamente arrays de diversas configurações a partir dos discos, expandir dinamicamente o espaço "on-the-fly", substituir discos com falhas, gerenciar snapshots e muito, muito mais, que poderia ser descrito em uma série de artigos. Vamos voltar ao nosso servidor e seus discos. No início da instalação, deixamos espaço livre nos discos para as partições criptografadas. Por que assim? Para que o sistema se inicie automaticamente e escute via SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
adicionamos uma partição do disco no espaço restante
geli init /dev/ada0p4
digitamos nossa senha de criptografia
geli attach /dev/ada0p4
novamente inserimos a senha e obtemos o dispositivo /dev/ada0p4.eli — este é o nosso espaço criptografado. Em seguida, repetimos o mesmo para /dev/ada1 e os demais discos no array. E criamos um novo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — então, temos nosso conjunto básico de combate pronto. Um array espelhado de discos caso um dos três falhe.
Criamos um dataset no novo "pool"
zfs create vms/jails
pkg install cbsd — executamos o comando e instalamos o gerenciamento para nossos jails.
Depois que cbsd está instalado, precisa ser inicializado:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
e respondemos a várias perguntas, principalmente com as respostas padrão.
*Se você estiver usando criptografia, é importante que o daemon cbsdd não inicie automaticamente, até que você descriptografe os discos manualmente ou automaticamente (no nosso exemplo, isso é feito pelo zabbix)
**Eu também não uso NAT do cbsd, mas o configuro manualmente em 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
## Encaminhamento de porta da rede Bitcoin
IP_JAIL="192.168.0.1"
PORT_JAIL="{8333}"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL
# service pf start
# pfctl -f /etc/pf.conf
Configurar as políticas do firewall é um tópico separado, então não vou me aprofundar na configuração da política BLOCK ALL e nas listas brancas, isso pode ser feito ao ler ou qualquer um dos inúmeros artigos disponíveis no Google.
Bem… temos o cbsd instalado, é hora de criar nosso primeiro trabalho — o daemon Bitcoin em um jail!
cbsd jconstruct-tui
Aqui vemos o diálogo de criação do jail. Depois de ajustar todos os valores, criamos!
Ao criar o primeiro jail, devemos escolher o que usar como base para os jails. Eu escolho a distribuição do repositório FreeBSD com o comando repo. Esta escolha é feita apenas ao criar o primeiro jail de uma versão específica (é possível hospedar jails de quaisquer versões que sejam superiores à versão do host).
Depois que tudo está instalado — iniciamos o jail!
# cbsd jstart bitcoind
Mas precisamos instalar o software no jail.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind para acessar o console do jail
e já dentro do jail, instalamos o software com suas dependências (o nosso sistema host permanece limpo)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
O Bitcoin está no jail, mas precisamos de anonimato, pois queremos nos conectar a alguns jails pela rede TOR. E, na verdade, temos a intenção de rodar a maioria dos jails com software suspeito apenas através de um proxy. Graças a pf é possível desativar o NAT para um determinado intervalo de endereços IP na rede local e permitir o NAT apenas para nosso nó TOR. Assim, mesmo que um malware entre na cela, é mais provável que ele não se conecte ao mundo externo, e mesmo se fizer isso, não revelará o IP do nosso servidor. Portanto, estamos criando outra cela para "redirecionar" serviços como serviços ".onion" e como proxy para saídas na internet para celas separadas.
# 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
Estamos configurando para escutar em um endereço local (acessível a todas as celas)
SOCKSPort 192.168.0.2:9050
O que mais nos falta para a felicidade completa? Sim, precisamos de um serviço para nossa web, talvez mais de um. Vamos iniciar o nginx, que desempenhará o papel de reverse-proxy e cuidará da renovação dos certificados Let’s Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev: /@[15:47] # pkg install nginx py36-certbot
E assim, 150 MB de dependências foram colocados na cela. E o host continua limpo.
Voltaremos à configuração do nginx mais tarde, precisamos levantar mais duas celas para nosso gateway de pagamento em nodejs e rust e um aplicativo web, que por algum motivo está em apache e php, e além disso, o último precisa de um banco de dados 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 ainda 380 MB de pacotes isolados
Em seguida, nós baixamos nosso aplicativo com git e o iniciamos.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp: /@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB de pacotes. na cela.
Aqui, damos acesso ao desenvolvedor via SSH diretamente na cela, eles se encarregarão de tudo:
webapp: /@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — mudamos a porta SSH da cela para qualquer valor aleatório
webapp: /@[16:02] # sysrc sshd_enable=YES
webapp: /@[16:02] # service sshd start
Agora sim, o serviço está iniciado, só falta adicionar uma regra no pf firewall
Vamos ver quais IPs temos nas celas e como nossa "local" realmente parece
# jls
JID Endereço IP Nome do Host Caminho
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 vamos adicionar uma 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
e já que estamos aqui, vamos também adicionar uma regra para o reverse-proxy:
## web-ports for nginx-rev
IP_JAIL="192.168.0.3"
PORT_JAIL="{ 80, 443 }"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL# pfctl -f /etc/pf.conf
Agora, um pouco sobre bitcoins
O que temos — temos um aplicativo web que é acessível externamente, e que se comunica localmente com nosso gateway de pagamento. Agora precisamos preparar o ambiente de trabalho para interagir com a própria rede bitcoin — o nó bitcoind este é apenas um daemon que suporta uma cópia local da blockchain atual. Este daemon possui RPC e funcionalidades de carteira, mas para o desenvolvimento de aplicativos existem "wrappers" mais convenientes. Para começar, decidimos instalar electrum — é uma carteira CLI. será usada como "armazenamento a frio" para nossos bitcoins — ou seja, aqueles bitcoins que precisarão ser mantidos "fora" do sistema acessível aos usuários e, de modo geral, bem longe de todos. Ele também possui uma GUI, por isso, vamos usar essa mesma carteira em nossos
laptops. Inicialmente, usaremos o electrum com servidores públicos e, mais tarde, levantaremos , para sermos completamente independentes.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:@[8:45] # pkg install py36-electrum
mais 700 MB de software na nossa prisão
electrum:@[8:53] # adduser
Nome de usuário: wallet
Nome completo:
Uid (Deixe vazio para padrão):
Grupo de login [wallet]:
O grupo de login é wallet. Convidar wallet para outros grupos? []:
Classe de login [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Diretório home [/home/wallet]:
Permissões do diretório home (Deixe vazio para padrão):
Usar autenticação baseada em senha? [sim]: não
Bloquear a conta após a criação? [não]:
Nome de usuário : wallet
Senha :
Nome completo :
Uid : 1001
Classe :
Grupos : wallet
Home : /home/wallet
Modo Home :
Shell : /bin/tcsh
Bloqueado : não
Ok? (sim/não): sim
adduser: INFO: Adicionado com sucesso (wallet) ao banco de dados de usuários.
Adicionar outro usuário? (sim/não): não
Adeus!
electrum:@[8:53] # su walletelectrum:@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Por favor, mantenha sua semente em um lugar seguro; se você a perder, não poderá restaurar sua carteira.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}Agora temos uma carteira criada.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
Para nossa on-chain carteira, apenas um número limitado de pessoas poderá se conectar a partir de agora. Para não abrir o acesso externo a esta prisão, as conexões via SSH ocorrerão através do TOR (uma versão descentralizada de VPN). Iniciaremos SSH na prisão, mas não mexeremos no nosso pf.conf no host.
electrum:@[9:00] # sysrc sshd_enable=YES
electrum:@[9:00] # service sshd start
Agora, vamos desligar a prisão com a carteira da internet. Vamos atribuir um endereço IP de um espaço de sub-rede diferente que não seja NAT. Primeiro, mudaremos /etc/pf.conf no host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" para JAIL_IP_POOL="192.168.0.0/25", assim todos os endereços 192.168.0.126-255 não terão acesso direto à internet. Uma espécie de rede "air-gap" de software. E a regra NAT permanece como estava
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Recarregando as regras
# pfctl -f /etc/pf.conf
Agora, vamos trabalhar com a nossa célula
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Remover IP antigo: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Configurar novo IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Humm, mas agora a própria sistema deixará de funcionar. No entanto, podemos especificar um proxy sistêmico. Mas há um porém, no TOR isso é um proxy SOCKS5, e para maior conveniência ainda precisaríamos de um 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
Pronto, agora nossa sistema possui dois servidores proxy, e ambos saem através do TOR: socks5://192.168.0.2:9050 e
Agora podemos configurar o ambiente da nossa 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:8123Agora o shell funcionará por meio do proxy. Se quisermos instalar pacotes, devemos adicionar em /usr/local/etc/pkg.conf sob o root da célula
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Agora é a vez de adicionar o serviço oculto do TOR como o endereço do nosso serviço SSH na célula 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.onionAqui está nosso endereço para conexão. Vamos verificar com a máquina local. Mas primeiro, precisamos adicionar nossa chave SSH:
wallet@electrum:/ % mkdir ~/ .ssh
wallet@electrum:/ % ee ~/ .ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localE agora, com a 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
Conectando-se (Para que isso funcione, um daemon local do TOR que escuta na porta 9050 é necessário)
user@local ~$ ssh remotebtc
A autenticidade do host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion ()' não pode ser estabelecida.
A impressão digital da chave ECDSA é SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Você tem certeza de que deseja continuar a conexão (sim/não/[impressão digital])? sim
Atenção: 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) foi adicionado permanentemente à lista de hosts conhecidos.
FreeBSD 12.1-RELEASE-p1 GENERIC
Para economizar espaço em disco no seu diretório inicial, comprima arquivos que você raramente
usa com "gzip nome_do_arquivo".
-- Dru
wallet@electrum:~ % logout
Sucesso!
Para trabalhar com pagamentos instantâneos e micropagamentos, também precisamos de um nó , na verdade, este será nosso principal instrumento de trabalho com bitcoin. A *, que vamos usar como daemon, tem , que é uma interface HTTP (REST) completa e permite trabalhar com transações off-chain e on-chain. c-lightning para funcionar precisa de bitcoind um nó.
*existem diferentes implementações em diferentes linguagens de programação do protocolo Lightning Network. Das que testamos, o c-lightning (escrito em C) se mostrou o mais estável e eficiente em recursos
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning: /@[10:23] # adduser
Nome de usuário: 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
Enquanto compila e instala tudo o que é necessário, vamos criar um usuário RPC para lightningd em bitcoind
# jexec bitcoind
bitcoind: /@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#permitir apenas c-lightning
rpcallowip=192.168.0.7/32bitcoind: /@[10:39] # service bitcoind restart
Minha troca caótica entre os terminais não é tão caótica se considerarmos a utilidade , demônio, que permite criar várias sub-sessões de terminal dentro de uma única sessão. Análogo a: screen
Bem, não queremos expor o IP real do nosso nó, e queremos realizar todas as operações financeiras através do TOR. Portanto, precisamos de outro .onion.
# jexec tor
tor:/@[9:59] # ee /usr/local/etc/tor/torrc
HiddenServiceDir /var/db/tor/cln/
HiddenServicePort 9735 192.168.0.7:9735tor: /@[10:01] # mkdir /var/db/tor/cln
tor: /@[10:01] # chown -R _tor:_tor /var/db/tor/cln
tor: /@[10:01] # chmod 700 /var/db/tor/cln
tor:/@[10:03] # service tor restart
tor: /@[10:04] # cat /var/db/tor/cln/hostname
en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onionAgora vamos criar a configuração para c-lightning
lightning: /home/lightning/lightning@[10:31] # su lightning
lightning@lightning:~ % mkdir .lightning
lightning@lightning:~ % ee .lightning/config
alias=Meu-Nó-LN
bind-addr=192.168.0.7:9735
rgb=ff0000
announce-addr=en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onion:9735
network=bitcoin
log-level=info
fee-base=0
fee-per-satoshi=1
proxy=192.168.0.2:9050
log-file=/home/lightning/.lightning/c-lightning.log
min-capacity-sat=200000
# plugin sparko
# https://github.com/fiatjaf/lightningd-gjson-rpc/tree/master/cmd/sparko
sparko-host=192.168.0.7
sparko-port=9737
sparko-tls-path=sparko-tls
#sparko-login=mywalletusername:mywalletpassword
#sparko-keys=masterkey;secretread:+listchannels,+listnodes;secretwrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
sparko-keys=masterkey;secretread:+listchannels,+listnodes;ultrawrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
# pelo exemplo acima, os logs de inicialização (misturados com os logs do lightningd) devem imprimir algo comolightning@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 ~/.ightning/sparko-tls
lightning@lightning:~/.lightning/sparko-tls % cd ~/.ightning/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ém é necessário criar um arquivo de configuração para o bitcoin-cli, a ferramenta que se comunica com bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testverificando
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]inicie lightningd
lightning@lightning:~ % lightningd --daemon
O próprio lightningd pode gerenciar a ferramenta lightning-cli, por exemplo:
lightning-cli newaddr obter um endereço para um novo pagamento de entrada
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all enviar todos os fundos da carteira para o endereço (todos os endereços on-chain)
Também existem comandos para operações off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.
E para comunicação com nosso aplicativo, temos a API REST
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Resumindo
# jls
JID Endereço IP Nome do Host Caminho
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
Temos um conjunto de contêineres, cada um com seu nível de acesso tanto de quanto para a rede local.
# zfs list
NOME USADO DISPONÍVEL REFER PONTO DE MONTAGEM
zroot 279G 1.48T 88K /zroot
zroot/ROOT 1.89G 1.48T 88K nenhum
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 podemos ver, o bitcoind ocupa todo o espaço de 190 GB. E se precisarmos de mais um nó para testes? Aqui o ZFS vem a calhar. Usando cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com É possível criar um snapshot e anexar uma nova célula a esse snapshot. A nova célula terá seu próprio espaço, mas na FS será considerada apenas a diferença entre o estado atual e o original (o que economiza pelo menos 190 GB).
Cada célula é um conjunto de dados ZFS separado, o que é extremamente conveniente. fazer várias outras coisas legais, como enviar snapshots por SSH. Não vamos descrever isso, já falamos muito.
É importante também mencionar a necessidade de monitoramento remoto do host, para isso temos .
B — segurança
Quanto à segurança, vamos nos basear nos princípios fundamentais no contexto da infraestrutura:
Confidencialidade — Ferramentas padrão de sistemas UNIX-like garantem a execução deste princípio. Nós dividimos logicamente o acesso a cada elemento separado do sistema — célula. O acesso é feito por meio da autenticação padrão de usuários com chaves pessoais. Toda comunicação entre e até as células finais ocorre de forma criptografada. Graças à criptografia dos discos, podemos ficar tranquilos quanto à integridade dos dados durante a troca de discos ou migração para outro servidor. O único acesso crítico é o acesso ao sistema host, pois esse acesso, em geral, proporciona acesso aos dados dentro dos contêineres.
Integridade — A execução deste princípio ocorre em vários níveis diferentes. Primeiro, é importante notar que, no caso de hardware de servidor, a memória ECC e o ZFS já "de fábrica" cuidam da integridade dos dados no nível dos bits. Snapshots instantâneos permitem backups a qualquer momento de forma dinâmica. Ferramentas convenientes de exportação-importação de células facilitam a replicação das células.
Acessibilidade — Aqui já é opcional. Depende da sua notoriedade e se você tem inimigos. No nosso exemplo, garantimos a acessibilidade da carteira exclusivamente pela rede TOR. Se necessário, pode-se bloquear tudo no firewall e permitir o acesso ao servidor exclusivamente através de túneis (TOR ou VPN é uma outra questão). Assim, o servidor estará isolado do mundo exterior o máximo possível, e somente nós poderemos influenciar sua acessibilidade.
Inoppugnabilidade — Isso depende do uso posterior e da observância das políticas corretas de direitos dos usuários, acesso, etc. Mas com a abordagem certa, todas as ações dos usuários são auditadas e, graças a soluções criptográficas, é possível identificar quem fez o quê e quando.
Claro, a configuração descrita não é um exemplo absoluto de como deve sempre ser, é mais um dos exemplos de como pode ser, mantendo uma grande flexibilidade em termos de escalabilidade e customização.
E a virtualização completa?
Sobre virtualização completa com ferramentas cbsd, é possível. . Só acrescento que para o trabalho bhyve é necessário ativar alguns parâmetros do kernel.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Então, se houver necessidade de rodar o Docker, basta subir um Debian qualquer e seguir em frente!
E é isso.
Acho que é tudo que eu queria compartilhar. Se você gostou do artigo, pode me enviar alguns bitcoins — . Se você quer ver as células em ação e tem alguns bitcoins, pode visitar meu .
Fonte: habr.com
