Dio la casualidad de que de profesión soy administrador de sistemas y redes informáticas (en resumen: administrador de sistemas), y tuve la oportunidad de decírselo al profesor desde hace poco más de 10 años. las actividades de una amplia variedad de sistemas, incluidos aquellos que requieren medidas de seguridad [extremas]. También pasó que hace un tiempo me pareció interesante. dev
, entonces, estaba de paso). Pero no me refiero al desarrollo, me refiero a un entorno seguro y eficiente para las aplicaciones.
Tecnología financiera (Fintech) vaya al lado de seguridad de la información (infosec) y el primero puede funcionar sin el segundo, pero no por mucho tiempo. Por eso quiero compartir mi experiencia y el conjunto de herramientas que utilizo, que incluye tanto FintechY infosec, y al mismo tiempo, y también se puede utilizar para un propósito más amplio o completamente diferente. En este artículo no les contaré tanto sobre Bitcoin, sino sobre el modelo de infraestructura para el desarrollo y operación de servicios financieros (y no solo), en una palabra, aquellos servicios donde "B" importa. Esto se aplica tanto al intercambio de Bitcoin como al típico zoológico corporativo de servicios de una pequeña empresa que no tiene ninguna relación con Bitcoin.
Me gustaría señalar que soy partidario de los principios. "Hazlo estúpidamente simple" и "menos es más", por lo tanto, tanto el artículo como lo que en él se describe tendrán las propiedades de que tratan estos principios.
Escenario imaginario: Veamos todo usando el ejemplo de un intercambiador de bitcoins. Decidimos iniciar el intercambio de rublos, dólares, euros por bitcoins y viceversa, y ya tenemos una solución que funciona, pero para otras monedas digitales como qiwi y webmoney, es decir. Hemos cerrado todos los problemas legales, tenemos una aplicación lista para usar que sirve como pasarela de pago para rublos, dólares y euros y otros sistemas de pago. Está conectado a nuestras cuentas bancarias y tiene algún tipo de API para nuestras aplicaciones finales. También tenemos una aplicación web que actúa como un intercambiador para los usuarios, bueno, como una cuenta típica de qiwi o webmoney: cree una cuenta, agregue una tarjeta, etc. Se comunica con nuestra aplicación de puerta de enlace, aunque a través de la API REST en el área local. Y entonces decidimos conectar bitcoins y al mismo tiempo actualizar la infraestructura, porque... Al principio, todo se montó rápidamente en cajas virtuales en la oficina debajo de la mesa... el sitio comenzó a usarse y empezamos a preocuparnos por el tiempo de actividad y el rendimiento.
Entonces, comencemos con lo principal: elegir un servidor. Porque El negocio en nuestro ejemplo es pequeño y confiamos en el hosting (OVH) que elegiremos.
Instalación del servidor
Aquí todo es sencillo. Elegimos el hardware que se adapta a nuestras necesidades. Luego seleccione la imagen de FreeBSD. Bueno, o nos conectamos (en el caso de otro proveedor de alojamiento y nuestro propio hardware) a través de IPMI o con un monitor e introducimos la imagen .iso de FreeBSD en la descarga. Para una configuración orquestal utilizo
La instalación del sistema se realiza de forma estándar, no me detendré en esto, solo señalaré que antes de comenzar a operar vale la pena prestar atención a endurecimiento opciones que ofrece bsdinstaller
al final de la instalación (si instala el sistema usted mismo):
Hay
También es posible habilitar los parámetros mencionados anteriormente en un sistema ya instalado. Para hacer esto, necesita editar el archivo del gestor de arranque y habilitar los parámetros del kernel. *ee es un editor como 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=1
También debe asegurarse de tener instalada la última versión del sistema y
Luego configuramos aide
, monitoreando el estado de los archivos de configuración del sistema. Puedes leer más en detalle.
pkg install aide
y editar nuestro 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
Encender
sysrc auditd_enable=YES
# service auditd start
Cómo administrar este asunto está perfectamente descrito en
Ahora reiniciamos y procedemos al software en el servidor. Cada servidor es un hipervisor para contenedores o máquinas virtuales completas. Por tanto, es importante que el procesador admita VT-x y EPT si planeamos utilizar la virtualización completa.
Para gestionar contenedores y máquinas virtuales utilizo
¿Contenedores? ¿Docker otra vez o qué?
Y aquí no. cbsd
para orquestar estos contenedores, que se llaman células.
La jaula es una solución extremadamente efectiva para construir infraestructura para una variedad de propósitos, donde en última instancia se requiere un aislamiento completo de servicios o procesos individuales. Básicamente, es un clon del sistema host, pero no requiere una virtualización completa del hardware. Y gracias a esto, los recursos no se gastan en el "SO invitado", sino sólo en el trabajo que se está realizando. Cuando las celdas se utilizan para necesidades internas, esta es una solución muy conveniente para un uso óptimo de los recursos: un grupo de celdas en un servidor de hardware puede usar cada una individualmente todo el recurso del servidor si es necesario. Teniendo en cuenta que normalmente los diferentes subservicios necesitan servicios adicionales. recursos en diferentes momentos, puede extraer el máximo rendimiento de un servidor si planifica y equilibra adecuadamente las celdas entre servidores. Si es necesario, a las células también se les pueden imponer restricciones sobre el recurso utilizado.
¿Qué pasa con la virtualización completa?
Que yo sepa cbsd
apoya el trabajo bhyve
e hipervisores XEN. Nunca he usado el segundo, pero el primero es relativamente nuevo. bhyve
en el siguiente ejemplo.
Instalación y configuración del entorno host
Usamos FS
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
agregue una partición de disco al espacio restante
geli init /dev/ada0p4
ingrese nuestra contraseña de cifrado
geli attach /dev/ada0p4
Ingresamos la contraseña nuevamente y tenemos un dispositivo /dev/ada0p4.eli: este es nuestro espacio cifrado. Luego repetimos lo mismo para /dev/ada1 y el resto de discos del array. Y creamos uno nuevo.
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli
- Bueno, ya tenemos listo el equipo mínimo de combate. Una matriz de discos reflejada en caso de que uno de los tres falle.
Crear un conjunto de datos en un nuevo "grupo"
zfs create vms/jails
pkg install cbsd
— Creamos un equipo y establecimos la gestión de nuestras células.
Después cbsd
instalado, es necesario inicializarlo:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Bueno, respondemos un montón de preguntas, la mayoría con respuestas predeterminadas.
*Si estás usando cifrado, es importante que el demonio cbsdd
no se inició automáticamente hasta que descifró los discos de forma manual o automática (en nuestro ejemplo, esto lo hace zabbix)
**Tampoco uso NAT de cbsd
, y lo configuro yo mismo 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
La configuración de políticas de firewall también es un tema aparte, por lo que no profundizaré en la configuración de la política BLOQUEAR TODO ni en la configuración de listas blancas; puede hacerlo leyendo
Bueno... tenemos cbsd instalado, es hora de crear nuestro primer caballo de batalla: ¡el demonio Bitcoin enjaulado!
cbsd jconstruct-tui
Aquí vemos el cuadro de diálogo de creación de celda. Una vez establecidos todos los valores, ¡vamos a crear!
Al crear su primera celda, debe elegir qué usar como base para las celdas. Selecciono una distribución del repositorio de FreeBSD con el comando repo
. Esta elección se realiza solo al crear la primera celda de una versión específica (puede alojar celdas de cualquier versión que sea anterior a la versión del host).
Después de que todo esté instalado, ¡lanzamos la jaula!
# cbsd jstart bitcoind
Pero necesitamos instalar software en la jaula.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoind
jexec bitcoind
para entrar a la consola del celular
y ya dentro del celular instalamos el software con sus dependencias (nuestro sistema host queda limpio)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Hay Bitcoin en la jaula, pero necesitamos el anonimato porque queremos conectarnos a algunas jaulas a través de la red TOP. En general, planeamos ejecutar la mayoría de las células con software sospechoso sólo a través de un proxy. Gracias a pf
Puede deshabilitar NAT para un cierto rango de direcciones IP en la red local y permitir NAT solo para nuestro nodo TOR. Así, aunque el malware entre en el móvil, lo más probable es que no se comunique con el mundo exterior, y si lo hace, no revelará la IP de nuestro servidor. Por lo tanto, creamos otra celda para "reenviar" servicios como un servicio ".onion" y como proxy para acceder a Internet a celdas individuales.
# 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
Configurado para escuchar en una dirección local (disponible para todas las celdas)
SOCKSPort 192.168.0.2:9050
¿Qué más necesitamos para la felicidad completa? Sí, necesitamos un servicio para nuestra web, quizá más de uno. Lancemos nginx, que actuará como proxy inverso y se encargará de renovar los certificados de Let's Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
Y entonces colocamos 150 MB de dependencias en una jaula. Y el anfitrión todavía está limpio.
Volvamos a configurar nginx más adelante, necesitamos crear dos celdas más para nuestra pasarela de pago en Nodejs y Rust y una aplicación web, que por alguna razón está en Apache y PHP, y esta última también requiere una 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
...y otros 380 MB de paquetes aislados
A continuación, descargamos nuestra aplicación con git y la ejecutamos.
# 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. en una jaula.
aquí le damos al desarrollador acceso vía SSH directamente al celular, ellos mismos harán todo allí:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267
— cambiar el puerto SSH del celular por uno arbitrario
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Bueno, el servicio está funcionando, solo queda agregar la regla a pf
cortafuegos
Veamos qué IP tienen nuestras células y cómo es nuestra “área local” en general.
# 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
y agrega 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
Bueno, ya que estamos aquí, agreguemos también una regla para el 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
Bueno, ahora un poco sobre bitcoins.
Lo que tenemos es una aplicación web que está expuesta externamente y se comunica localmente con nuestra pasarela de pago. Ahora necesitamos preparar un entorno de trabajo para interactuar con la propia red Bitcoin: el nodo. bitcoind
es solo un demonio que mantiene actualizada la copia local de la cadena de bloques. Este demonio tiene RPC y funcionalidad de billetera, pero existen "envoltorios" más convenientes para el desarrollo de aplicaciones. Para empezar decidimos poner electrum
es una billetera CLI.
portátiles. Por ahora usaremos Electrum con servidores públicos, y luego lo subiremos en otro celular.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
Otros 700 MB de software en nuestra jaula.
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"
}
Ahora tenemos una billetera creada.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]
wallet@electrum:/ % electrum-3.6 help
Para nuestro en cadena A partir de ahora, solo un número limitado de personas podrá conectarse a la billetera. Para no abrir el acceso a esta celda desde el exterior, las conexiones vía SSH se realizarán a través de TOP (una versión descentralizada de VPN). Lanzamos SSH en el celular, pero no tocamos nuestro pf.conf en el host.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Ahora apaguemos el celular con acceso a Internet de la billetera. Démosle una dirección IP de otro espacio de subred que no sea NAT. primero cambiemos /etc/pf.conf
en el anfitrión
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24"
vamos a cambiarlo a JAIL_IP_POOL="192.168.0.0/25"
, por lo tanto, todas las direcciones 192.168.0.126-255 no tendrán acceso directo a Internet. Una especie de red de software “air-gap”. Y la regla NAT sigue como estaba.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Sobrecargar las reglas
# pfctl -f /etc/pf.conf
Ahora tomemos nuestro celular.
# 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, pero ahora el sistema en sí dejará de funcionar para nosotros. Sin embargo, podemos especificar un proxy del sistema. Pero hay una cosa: en TOR es un proxy SOCKS5 y, por conveniencia, tambié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 = socks5
polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Bueno, ahora hay dos servidores proxy en nuestro sistema, y ambos salen a través de TOR: calcetines5://192.168.0.2:9050 y
Ahora podemos configurar nuestro entorno de billetera.
# 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
Bueno, ahora el shell funcionará desde un proxy. Si queremos instalar paquetes, entonces debemos agregar a /usr/local/etc/pkg.conf
desde debajo de la raíz de la jaula
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}
Bueno, ahora es el momento de agregar el servicio oculto TOR como la dirección de nuestro servicio SSH en la celda de la billetera.
# 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
Esta es nuestra dirección de conexión. Comprobemos desde la máquina local. Pero primero necesitamos agregar nuestra clave SSH:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@local
Bueno, desde una 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
conectemos (Para que esto funcione, necesita un demonio TOR local que escuche 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
Успех!
Para trabajar con pagos instantáneos y micropagos, también necesitamos un nodo c-lightning
requerido para el funcionamiento bitcoind
pero si.
*Existen diferentes implementaciones del protocolo Lightning Network en diferentes idiomas. De los que probamos, c-lightning (escrito en C) parecía el más estable y 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
Mientras todo lo necesario está compilado e instalado, creemos 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/32
bitcoind:/@[10:39] # service bitcoind restart
Mi cambio caótico entre celdas resulta no tan caótico si notas la utilidad tmux
, que le permite crear múltiples subsesiones de terminal dentro de una sesión. Término análogo: screen
Por lo tanto, no queremos revelar la IP real de nuestro nodo y queremos realizar todas las transacciones financieras a través de TOP. Por tanto, no se necesita otra cebolla.
# 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
Ahora creemos una 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 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 ~
También necesita crear un archivo de configuración para bitcoin-cli, una utilidad que se comunica con bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test
comprobar
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]
lanzamiento lightningd
lightning@lightning:~ % lightningd --daemon
Sí mismo lightningd
puedes controlar la utilidad lightning-cli
, Por ejemplo:
lightning-cli newaddr
obtener la dirección para un nuevo pago entrante
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}
lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all
enviar todo el dinero en la billetera a la dirección (todas las direcciones en cadena)
También comandos para operaciones fuera de la cadena. lightning-cli invoice
, lightning-cli listinvoices
, lightning-cli pay
y así sucesivamente
Bueno, para la comunicación con la aplicación tenemos una Api REST.
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
para 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
Disponemos de un conjunto de contenedores, cada uno con su propio nivel de acceso tanto desde como hacia la red 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-data
Como puedes ver, bitcoind ocupa los 190 GB de espacio. ¿Qué pasa si necesitamos otro nodo para realizar pruebas? Aquí es donde ZFS resulta útil. Con ayuda cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com
puede crear una instantánea y adjuntar una nueva celda a esta instantánea. La nueva celda tendrá su propio espacio, pero en el sistema de archivos solo se tendrá en cuenta la diferencia entre el estado actual y el original (ahorraremos al menos 190 GB)
Cada celda es su propio conjunto de datos ZFS independiente, lo cual es extremadamente conveniente.
También cabe destacar la necesidad de realizar un seguimiento remoto del host, para estos fines disponemos
B-seguridad
En cuanto a la seguridad, partamos de los principios clave en el contexto de la infraestructura:
Confidencialidad - Las herramientas estándar de los sistemas tipo UNIX garantizan la implementación de este principio. Separamos lógicamente el acceso a cada elemento del sistema lógicamente separado: una celda. El acceso se proporciona mediante autenticación de usuario estándar utilizando las claves personales de los usuarios. Toda la comunicación entre y hacia las células finales se produce de forma cifrada. Gracias al cifrado de disco, no tenemos que preocuparnos por la seguridad de los datos al reemplazar un disco o migrar a otro servidor. El único acceso crítico es el acceso al sistema host, ya que dicho acceso generalmente proporciona acceso a los datos dentro de los contenedores.
Integridad “La implementación de este principio ocurre en varios niveles diferentes. En primer lugar, es importante tener en cuenta que en el caso del hardware del servidor, la memoria ECC, ZFS ya está "listo para usar" y se encarga de la integridad de los datos a nivel de bits de información. Las instantáneas instantáneas le permiten realizar copias de seguridad en cualquier momento sobre la marcha. Las prácticas herramientas de exportación/importación de células simplifican la replicación celular.
Disponibilidad - Esto ya es opcional. Depende del grado de tu fama y del hecho de que tengas enemigos. En nuestro ejemplo, nos aseguramos de que se pudiera acceder a la billetera exclusivamente desde la red TOP. Si es necesario, puedes bloquear todo en el firewall y permitir el acceso al servidor exclusivamente a través de túneles (TOR o VPN es otro asunto). De este modo, el servidor estará lo más aislado posible del mundo exterior y sólo nosotros podremos influir en su disponibilidad.
Imposibilidad de rechazo - Y esto depende del funcionamiento posterior y del cumplimiento de las políticas correctas de derechos de usuario, acceso, etc. Pero con el enfoque correcto, todas las acciones del usuario son auditadas y gracias a las soluciones criptográficas es posible identificar inequívocamente quién realizó determinadas acciones y cuándo.
Por supuesto, la configuración descrita no es un ejemplo absoluto de cómo debería ser siempre, sino más bien un ejemplo de cómo puede ser, manteniendo al mismo tiempo capacidades de personalización y escalamiento muy flexibles.
¿Qué pasa con la virtualización completa?
Acerca de la virtualización completa usando cbsd puedes bhyve
Debe habilitar algunas opciones del kernel.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...
# cat /boot/loader.conf
...
vmm_load="YES"
...
Entonces, si de repente necesitas iniciar una ventana acoplable, ¡instala Debian y listo!
Eso es todo
Supongo que eso es todo lo que quería compartir. Si te gustó el artículo, puedes enviarme algunos bitcoins.
Fuente: habr.com