Aconteceu que eu sou um administrador profissional de sistemas e redes de computadores (em resumo: sysadmin) e, por acaso, contei ao prof. a atividade de uma ampla variedade de sistemas, incluindo aqueles que exigem [por causa] das medidas de segurança acima. E aconteceu que, há algum tempo, achei o Bitcoin interessante para mim, e não apenas o usei, mas também lançou vários microsserviços para aprender a trabalhar independentemente com a rede Bitcoin (afinal, é p2p) do ponto de vista do desenvolvimento. (Eu, é claro, sou um desenvolvedor, então, deixei passar). Mas não estou falando de desenvolvimento, mas de um ambiente seguro e eficaz para aplicativos.
As tecnologias financeiras ( fintech ) acompanham a segurança da informação ( infosec ) e a primeira pode funcionar sem a segunda, mas não por muito tempo. É por isso que quero compartilhar minha experiência e o conjunto de ferramentas que eu uso, que inclui fintech e infosec , e, ao mesmo tempo, também pode ser usado para um propósito mais amplo ou completamente diferente. Neste artigo, falarei pouco sobre Bitcoin, mas sobre o modelo de infraestrutura para desenvolver e operar serviços financeiros (e não apenas) - em uma palavra, os serviços em que "B" é importante. Isso se aplica tanto à troca de Bitcoin quanto ao zoológico corporativo mais típico dos serviços de uma pequena empresa sem bitcoin de forma alguma.
Quero observar que sou um defensor dos princípios de "mantenha as coisas estúpidas simples" e "menos é mais" ; portanto, tanto o artigo como o descrito nele terão as propriedades sobre as quais esses princípios são.
Cenário imaginário: vamos dar uma olhada em um exemplo de trocador de bitcoin. Decidimos começar a trocar rublos, dólares, euros por bitcoins e vice-versa, e já temos uma solução funcional, mas por outro dinheiro digital como kiwi e webmoney, ou seja, encerramos todas as questões legais, existe um aplicativo pronto que funciona como um gateway de pagamento para rublos, dólares e euros e outros sistemas de pagamento. Ele está vinculado às nossas contas bancárias e possui algum tipo de API para nossos aplicativos finais. Também temos um aplicativo da web que atua como um trocador de usuários, como uma conta típica de kiwi ou webmoney - abra uma conta, adicione um cartão e assim por diante. Ele se comunica com nosso aplicativo de gateway, embora use a API REST na LAN. Por isso, decidimos conectar bitcoins e, ao mesmo tempo, atualizar a infraestrutura, porque inicialmente tudo foi levado às caixas virtuais no escritório embaixo da mesa ... eles começaram a usar o site e começamos a nos preocupar com tempo de atividade e desempenho.
Então, vamos começar com a seleção principal de um servidor. Porque como a empresa em nosso exemplo é pequena e confiamos no hoster (OVH), escolheremos uma opção de orçamento na qual você não pode instalar o sistema a partir da imagem .iso original, mas isso não importa, o departamento de segurança de TI analisará definitivamente a imagem instalada. E quando crescermos, geralmente alugamos nosso armário com chave e acesso físico limitado, ou talvez construamos nosso próprio CD. De qualquer forma, vale lembrar que, ao alugar ferro e instalar imagens prontas, é possível que seu sistema tenha um “cavalo de troia do host”, que na maioria dos casos não se destina a rastrear você, mas a oferecer ferramentas de gerenciamento mais convenientes servidor.
Instalação do servidor
Tudo é simples aqui. Nós escolhemos o ferro que se adapte às nossas necessidades. Depois selecione a imagem do FreeBSD. Bem, nós nos conectamos (no caso de outro hoster e nosso próprio hardware) via IPMI ou com um monitor e alimentamos a imagem .iso FreeBSD para o download. Para instalações orquestrais, uso Ansible e mfsbsd . A única coisa, no nosso caso com o kimsufi, escolhemos a instalação personalizada para que os dois discos no espelho tivessem apenas as "partições de inicialização" e / home "abertas", o restante do espaço em disco será criptografado, mas mais sobre isso posteriormente.
O sistema é instalado da maneira padrão, não vou parar por aí, só observo que, antes de iniciar a operação, vale a pena prestar atenção nas opções de proteção que o bsdinstaller oferece no final da instalação (se você mesmo instalar o sistema):
Há um bom material sobre esse tópico, resumindo, repetirei aqui.
É possível ativar os parâmetros acima da mesma maneira em um sistema já instalado. Para fazer isso, edite o arquivo do carregador de inicialização e ative os parâmetros do kernel. * ee é um editor como este 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=1
Também vale a pena garantir que você tenha a versão mais recente do sistema instalada e concluir todas as atualizações e atualizações . No nosso caso, por exemplo, é necessária uma atualização para a versão mais recente, porque as imagens de pré-instalação ficam seis meses a um ano atrasadas. Bem, lá mudamos a porta SSH para outra por padrão, adicionamos autenticação de chave e desabilitamos com uma senha.
Em seguida, configuramos o aide , monitorando o estado dos arquivos de configuração do sistema. Mais mastigado pode ser lido aqui .
pkg install aide
e edite 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/$MYFILENAME
Ativar a auditoria do sistema
sysrc auditd_enable=YES
# service auditd start
Como administrar esse negócio está bem descrito no manual .
Agora reinicializamos e prosseguimos com o software no servidor. Cada servidor é um hypervisor para contêineres ou máquinas virtuais completas. Portanto, é importante que o processador ofereça suporte a VT-x e EPT se planejamos usar a virtualização completa.
Como um gerenciamento de contêiner e máquina virtual, eu uso o clevd da olevole , desejo a ele mais saúde e benefícios por esse maravilhoso utilitário!
Containers? Novamente janela de encaixe ou o quê?
Mas não. O FreeBSD Jails é uma ótima ferramenta de contêiner, mas o cbsd mencionado cbsd para orquestrar esses contêineres, cujo nome é células.
Uma célula é uma solução extremamente eficaz para a construção de infraestrutura para uma variedade de propósitos, o que requer o isolamento completo de serviços ou processos individuais. Este é essencialmente um clone do sistema host, mas não requer virtualização completa do hardware. E os recursos resultantes disso não são gastos em um "SO convidado", mas apenas no trabalho realizado. Quando as células são usadas para necessidades internas, essa é uma solução muito conveniente para o uso ideal do recurso - várias células em um servidor de ferro podem usar individualmente todo o recurso do servidor, se necessário. Dado que sub-serviços geralmente diferentes precisam de mais. recursos em momentos diferentes, você pode extrair o desempenho máximo de um servidor, se planejar e desequilibrar as células entre os servidores corretamente. Se necessário, as células também podem definir limites para o recurso usado.
E a virtualização completa?
Até onde eu sei, o cbsd apóia o trabalho dos hipervisores bhyve e XEN. Eu nunca usei o segundo, mas o primeiro é um hypervisor relativamente jovem do FreeBSD . Veremos um exemplo de uso de bhyve no exemplo abaixo.
Instale e configure o ambiente do host
Nós usamos o FS ZFS . Esta é uma ferramenta extremamente poderosa para gerenciar o espaço no servidor. Graças ao ZFS, você pode criar diretamente matrizes de várias configurações diretamente de discos, expandir dinamicamente o espaço "quente", alterar discos mortos, gerenciar instantâneos e muito, muito mais, que pode ser descrito em uma série de artigos. Vamos voltar ao nosso servidor e seus discos. No início da instalação em discos, deixamos espaço livre para partições criptografadas. Porque Isso é para que o sistema suba automaticamente e ouça no SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
adicione a partição do disco ao espaço restante
geli init /dev/ada0p4
dirigir nossa senha de criptografia
geli attach /dev/ada0p4
digite novamente a senha e temos o dispositivo /dev/ada0p4.eli - este é o nosso espaço criptografado. Em seguida, repetimos o mesmo para / dev / ada1 e outros discos na matriz. E crie um novo pool do ZFS .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - bem, agora temos o conjunto mínimo de combate pronto. Uma matriz de disco espelhada no caso de uma das três falhar.
Crie um conjunto de dados no novo "pool"
zfs create vms/jails
pkg install cbsd - execute o comando e instale o gerenciamento para nossas células.
Após a instalação do cbsd , ele precisa ser inicializado:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Bem, respondemos a várias perguntas, principalmente respostas por padrão.
* Se você usar criptografia, é importante que o daemon cbsdd seja iniciado automaticamente até que você descriptografe os discos manual ou automaticamente (em nosso exemplo, o zabbix faz isso)
** Além disso, eu não uso o NAT do cbsd , mas configuro-o pessoalmente no 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
A configuração de políticas de firewall também é um tópico separado, por isso não vou me aprofundar na configuração de políticas de BLOCK ALL e na definição de listas de permissões; você pode fazer isso lendo a documentação oficial ou qualquer grande número de artigos disponíveis no Google.
Bem ... temos o cbsd instalado, é hora de criar nosso primeiro cavalo de trabalho - um demônio bitcoin em uma gaiola!
cbsd jconstruct-tui
Aqui vemos o diálogo de criação de células. Depois que todos os valores estiverem definidos, crie!
Ao criar a primeira célula, você deve escolher o que usar como base para as células. Eu seleciono o kit de distribuição no repositório do FreeBSD com o comando repo . Essa escolha é feita apenas ao criar a primeira célula de uma versão específica (você pode hospedar células de qualquer versão anterior à versão do host).
Depois que tudo estiver instalado - execute a célula!
# cbsd jstart bitcoind
Mas precisamos instalar o software na gaiola.
# jls
JID IP Address Hostname Path 1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoind
jexec bitcoind para entrar no console da célula
e já dentro da célula, instalamos o software com suas dependências (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
Há bitcoin na célula, mas precisamos de anonimato, porque queremos conectar-se a algumas células através da rede TOP. Em geral, temos planos de transformar a maioria das células com software suspeito apenas por meio de um proxy. Graças ao pf você pode desativar o NAT para um intervalo específico de endereços IP na rede local e permitir o NAT apenas para o nosso nó TOR. Portanto, mesmo que o malware entre na célula, ele provavelmente não entrará em contato com o mundo exterior e, se o fizer, não revelará o IP do nosso servidor. portanto, criamos mais uma célula, para serviços de "encaminhamento" como um serviço ".onion" e como um proxy para acessar a Internet em células 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
Colocamos listen no endereço local (disponível para todas as células)
SOCKSPort 192.168.0.2:9050
O que ainda falta para a felicidade completa. Sim, precisamos de um serviço para a nossa web, talvez não um. Execute o nginx, que atuará como proxy reverso 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 agora colocamos 150 MB de dependências em uma gaiola. E o anfitrião ainda está limpo.
voltemos a configurar o nginx posteriormente, precisamos criar mais duas células para o nosso gateway de pagamento para nodejs e rust e um aplicativo da web, que por algum motivo está no apache e no pkhp, e o banco de dados MySQL também é necessário para o último.
# 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 pacotes isolados
Em seguida, aumentamos nosso aplicativo com git e o executamos.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
Pacotes de 450 MB. na gaiola.
aqui, damos ao desenvolvedor acesso via SSH diretamente à célula, eles farão tudo sozinhos:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 - altere a porta da célula SSH para qualquer
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Bem, o serviço está em execução, resta adicionar uma regra no firewall pf
Vamos ver qual IP temos nas células e como é o nosso "lokalka"
# 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
e adicione 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
Bem, como estamos aqui, adicionaremos a mesma regra no proxy reverso:
## 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
Bem, agora um pouco sobre bitcoins
O que temos - temos um aplicativo da web que é acessível de fora e se comunica localmente com nosso gateway de pagamento. Agora precisamos preparar um ambiente de trabalho para interação com a própria rede bitcoin - o nó bitcoind é apenas um daemon que suporta uma cópia local da blockchain atual. Este daemon possui funcionalidade RPC e carteira, mas existem "wrappers" mais convenientes para o desenvolvimento de aplicativos. Para começar, decidimos colocar electrum - esta é uma carteira CLI. Usaremos essa carteira como um "armazenamento a frio" para nossos bitcoins - em geral, aqueles que precisarão ser armazenados "fora" do sistema, acessíveis aos usuários e geralmente afastados de todos. Ele também tem uma interface gráfica, então vamos usar a mesma carteira no nosso
laptops. Enquanto usaremos o electrum com servidores públicos, e posteriormente em outra célula, criaremos o ElectrumX , para que não dependa de ninguém.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
outros 700 MB de software em nossa 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 wallet
electrum:/@[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 criamos uma carteira.
wallet@electrum:/ % electrum-3.6 listaddresses
[ "18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE", "14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU", "1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas", ... "1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw", "18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk" ]
wallet@electrum:/ % electrum-3.6 help
A partir de agora, apenas um círculo limitado de pessoas poderá se conectar à nossa carteira na cadeia . Para não abrir o acesso externo a esta célula, as conexões SSH ocorrerão através do TOR (uma versão descentralizada da VPN). Iniciamos o SSH na célula, mas não tocamos em nosso pf.conf no host.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Agora desligue o acesso à Internet da célula com a carteira. Daremos a ele um endereço IP de outro espaço de sub-rede que não seja baseado em NAT. Primeiro, altere /etc/pf.conf no host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" mude para JAIL_IP_POOL="192.168.0.0/25" , portanto, todos os endereços 192.168.0.126-255 não terão acesso direto à Internet. Uma espécie de software "air-gap" da rede. E a regra da NAT permanece como era
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Sobrecarregando as regras
# pfctl -f /etc/pf.conf
Agora pegue nossa gaiola
# 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.200
Hmm, mas agora o sistema em si vai parar de funcionar para nós. No entanto, podemos especificar um proxy do sistema. Mas há uma coisa, mas, no TOR, é um proxy SOCKS5 e, por conveniência, também teríamos 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 = socks5
polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Bem, agora em nosso sistema existem dois proxies, e ambos saem via TOR: socks5: //192.168.0.2: 9050 e http://192.168.0.6:8123
Agora você pode personalizar 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:8123
Bem, agora o shell funcionará sob um proxy. Se você deseja instalar pacotes, adicione /usr/local/etc/pkg.conf abaixo da raiz
pkg_env: { http_proxy: "http://my_proxy_ip:8123", }
Bem, agora é hora de adicionar o serviço oculto 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:22
tor:/@[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.onion
Aqui está o nosso endereço de conexão. Vamos verificar na máquina local. Mas primeiro você precisa adicionar nossa chave SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@local
Bem, a partir da máquina Linux cliente
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
Conectar (Para que isso funcione, você precisa de um daemon TOR local que escute no 9050)
user@local ~$ ssh remotebtc
The authenticity of host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' can't be established. ECDSA key fingerprint is SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) to the list of known hosts. FreeBSD 12.1-RELEASE-p1 GENERIC To save disk space in your home directory, compress files you rarely use with "gzip filename". -- Dru <genesis@istar.ca> wallet@electrum:~ % logout
Sucesso!
Para trabalhar com pagamentos instantâneos e micropagamentos, também precisamos do nó Lightning Network ; de fato, essa será nossa principal ferramenta de trabalho com bitcoin. * O C-lightning , que vamos usar como daemon, possui um plugin Sparko , que é uma interface HTTP (REST) completa e permite trabalhar com transações fora da cadeia e transações na cadeia. c-lightning requer um nó bitcoind para funcionar.
* Existem implementações diferentes em diferentes PLs do protocolo Lightning Network. Aqueles que testamos o c-lightning (escrito em C) pareciam os mais estáveis e eficientes em termos de 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
Enquanto tudo o que você precisa é compilado e instalado, crie o usuário RPC para lightningd no 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/32
bitcoind:/@[10:39] # service bitcoind restart
Minha troca caótica entre células não é tão caótica se você observar o utilitário tmux , que permite criar muitas sub-sessões de terminais dentro de uma sessão. Analógico: screen
Dachshunds, não queremos exibir o IP real de nosso nó e queremos realizar todas as transações financeiras através do TOP. Portanto, você precisa de mais um .onion.
# jexec tor
tor:/@[9:59] # ee /usr/local/etc/tor/torrc
HiddenServiceDir /var/db/tor/cln/ HiddenServicePort 9735 192.168.0.7:9735
tor:/@[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.onion
agora crie uma configuração para o 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 like
lightning@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 ~
você também precisa criar um arquivo de configuração para o bitcoin-cli, um utilitário que se comunica com o bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1 rpcuser=test rpcpassword=test
verificar
lightning@lightning:~ % bitcoin-cli echo "test"
[ "test" ]
correr lightningd
lightning@lightning:~ % lightningd --daemon
lightning-cli próprio lightning-cli pode ser controlado pelo lightning-cli , por exemplo:
lightning-cli newaddr obter endereço para nova entrada de pagamento
{ "address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv", "bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv" }
lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all enviam para o endereço todo o dinheiro da carteira (todos os endereços na cadeia)
Além disso, comandos para operações fora da cadeia de lightning-cli invoice lightning-cli listinvoices , lightning-cli invoice lightning-cli listinvoices , lightning-cli listinvoices lightning-cli pay etc.
Bem, para comunicação com o aplicativo, temos o REST Api
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
, .
# 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-data
, bitcoind 190 . ? ZFS . cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com . , ( 190 )
ZFS, . ZFS , SSH. , .
, Zabbix .
—
, :
— UNIX- . — . . . . -, .
— . - , ECC , ZFS " " . . - .
— . . . ( ). , .
— , . , .
, , , .
?
cbsd . , bhyve .
# cat /etc/rc.conf
... kld_list="vmm if_tap if_bridge nmdm" ...
# cat /boot/loader.conf
... vmm_load="YES" ...
, - debian !
. — bc1qu7lhf45xw83ddll5mnzte6ahju8ktkeu6qhttc . , pet-project .