Resulta que soy administrador de sistemas y redes informáticas (en abreviatura: sysadmin), y durante poco más de 10 años he trabajado con diversos sistemas, incluyendo aquellos que requieren [por|para] medidas de seguridad reforzadas. Además, me encontré hace un tiempo que me interesaba , y no solo lo utilicé, sino que también lancé varios microservicios para aprender a trabajar de manera autónoma con la red bitcoin (que es p2p, después de todo) desde la perspectiva del desarrollador (aunque debo decir que soy un principiante en esto dev, solo pasé por allí). Pero no estoy aquí para hablar de desarrollo, sino de un entorno seguro y eficiente para aplicaciones.
Las tecnologías financieras (fintech) van de la mano con la seguridad de la información (infosec), y la primera puede funcionar sin la segunda, pero no por mucho tiempo. Por eso, quiero compartir mi experiencia y el conjunto de herramientas que utilizo, que incluye tanto fintech, como infosec, usándose simultáneamente, y también puede aplicarse en un contexto más amplio o completamente diferente. En este artículo hablaré no tanto sobre bitcoin, sino sobre el modelo de infraestructura para el desarrollo y operación de servicios financieros (y no solo) — es decir, aquellos servicios donde
Quiero señalar que soy un defensor de los principios «keep it stupid simple» y «less is more», por lo que tanto el artículo como lo que se describe en él tendrán las características de estos principios.
Escenario imaginado: Analicemos todo con el ejemplo de un intercambio de bitcoins. Hemos decidido lanzar un intercambio de rublos, dólares y euros por bitcoins y viceversa, y ya tenemos una solución operativa, pero para otras monedas digitales como QIWI y WebMoney, es decir, hemos resuelto todas las cuestiones legales, tenemos una aplicación lista que actúa como un gateway de pago para rublos, dólares y euros, así como otros sistemas de pago. Está vinculado a nuestras cuentas bancarias y cuenta con alguna API para nuestras aplicaciones finales. También tenemos una aplicación web que actúa como un intercambio para los usuarios, similar a un típico gabinete de QIWI o WebMoney: cree una cuenta, agregue una tarjeta, y así sucesivamente. Se comunica con nuestra aplicación de gateway, posiblemente a través de REST API en la red local. Y así decidimos integrar bitcoins y, de paso, actualizar la infraestructura, ya que inicialmente todo estaba apresuradamente levantado en VirtualBox en la oficina, debajo de la mesa... el sitio comenzó a usarse y empezamos a preocuparnos por el tiempo de actividad y el rendimiento.
Así que empecemos con lo básico: la elección del servidor. Dado que el negocio en nuestro ejemplo es pequeño y confiamos en el proveedor de hosting (OVH), elegiremos en la que no se puede instalar un sistema a partir de la imagen original .iso, pero no hay problema, el departamento de seguridad IT realizará un análisis de la imagen instalada. Y cuando crezcamos, alquilaremos un armario privado con cerradura y acceso físico limitado, o incluso construiremos nuestro propio centro de datos. En cualquier caso, es importante recordar que al alquilar hardware y configurar imágenes predefinidas hay una posibilidad de que en su sistema esté presente un "troyano del proveedor de hosting", que en la mayoría de los casos no está diseñado para espiarlo, sino para ofrecer herramientas de gestión del servidor más cómodas.
Instalación del servidor
Aquí todo es simple. Elegimos el hardware que se adapta a nuestras necesidades. Luego elegimos la imagen de FreeBSD. O nos conectamos (en caso de otro proveedor de hosting y nuestro propio hardware) a través de IPMI o con un monitor y cargamos la imagen .iso de FreeBSD. Para la instalación orquestada uso y . Lo único es que, en nuestro caso con Kimsufi, elegimos instalación personalizada para que los dos discos en espejo tengan "abiertos" únicamente las particiones de arranque y /home, el resto del espacio del disco estará cifrado, pero de eso hablaremos más adelante.
La instalación del sistema se realiza de manera estándar, no me detendré en esto, solo señalaré que antes de comenzar a usarlo, vale la pena prestar atención a endurecimiento las opciones que ofrece bsdinstaller al final de la instalación (si estás instalando el sistema tú mismo):
Hay sobre este tema, en resumen, aquí lo repetiré.
Es posible habilitar los parámetros mencionados también en un sistema ya instalado. Para esto, es necesario editar el archivo de arranque e incluir los parámetros del núcleo. *ee es un editor 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=1También es importante asegurarse de que tienes la última versión del sistema, y En nuestro caso, por ejemplo, se requiere actualizar a la última versión, ya que las imágenes predeterminadas están desactualizadas por seis meses a un año. Y allí cambiamos el puerto SSH por uno diferente al predeterminado, agregamos autenticación por claves y desactivamos la autenticación por contraseña.
Luego configuramos aide, monitoreo del estado de los archivos de configuración del sistema. Se puede leer más detalladamente .
pkg install aide
y editamos 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/$MYFILENAMEActivamos
sysrc auditd_enable=YES
# service auditd start
Cómo administrar esto está excelentemente descrito en .
Ahora reiniciamos y comenzamos con el software en el servidor. Cada servidor se convierte en un hipervisor para contenedores o máquinas virtuales completas. Por lo tanto, es importante que el procesador soporte VT-x y EPT si planeamos utilizar virtualización completa.
Como gestión de contenedores y máquinas virtuales utilizo desde , le deseo mucha salud y bendiciones por esta maravillosa utilidad.
¿Contenedores? ¿Otra vez con Docker?
Y no. son una herramienta excelente para la contenedorización, y el mencionado cbsd para la orquestación de estos contenedores, cuyo nombre es — células.
Una celda es una solución extremadamente eficaz para construir infraestructuras para diversos propósitos, donde en última instancia se requiere una completa aislamiento de servicios o procesos individuales. En esencia, es un clon del sistema anfitrión, pero no requiere virtualización completa del hardware. Y gracias a esto, los recursos no se desperdician en un 'sistema operativo huésped', sino solo en el trabajo que se realiza. Cuando las celdas se utilizan para necesidades internas, es una solución muy conveniente para el uso óptimo de recursos: un montón de celdas en un solo servidor físico pueden cada una usar todo el recurso del servidor según sea necesario. Dado que generalmente diferentes subsistemas necesitan recursos adicionales en diferentes momentos, se puede extraer la máxima rendimiento de un servidor si se planifica y balancea correctamente las celdas entre los servidores. Si es necesario, también se pueden imponer límites en los recursos utilizados por las celdas.
¿Y qué hay de la virtualización completa?
Hasta donde sé, cbsd admite el funcionamiento de bhyve y los hipervisor XEN. Nunca he usado el segundo, pero el primero es un hipervisor relativamente joven Vamos a ver un ejemplo de uso bhyve en el siguiente ejemplo.
Instalación y configuración del entorno del host
Utilizamos el sistema de archivos . Esta es una herramienta extremadamente poderosa para gestionar el espacio en el servidor. Gracias a ZFS, se pueden construir directamente arreglos de discos de diversas configuraciones, aumentar el espacio dinámicamente 'en caliente', reemplazar discos que han fallado, gestionar instantáneas y muchas otras cosas que se pueden describir en una serie de artículos. Volvamos a nuestro servidor y a sus discos. Al principio de la instalación, dejamos espacio libre en los discos para las particiones cifradas. ¿Por qué? Esto es para que el sistema se inicie automáticamente y escuche por SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
agregamos la partición del disco en el espacio restante
geli init /dev/ada0p4
introducimos nuestra contraseña de cifrado
geli attach /dev/ada0p4
nuevamente introducimos la contraseña y nos aparece el dispositivo /dev/ada0p4.eli — este es nuestro espacio cifrado. Luego repetimos lo mismo para /dev/ada1 y los demás discos en el arreglo. Y creamos un nuevo .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — bueno, aquí tenemos nuestro conjunto de combate mínimo listo. Un arreglo espejo de discos en caso de que uno de los tres falle.
Creamos un dataset en un nuevo pool
zfs create vms/jails
pkg install cbsd — ejecutamos el comando y estamos instalando la gestión para nuestras celdas.
Después de que cbsd se instale, debe ser inicializado:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
y respondemos a un montón de preguntas, principalmente con las respuestas predeterminadas.
*Si utilizas cifrado, es importante que el demonio cbsdd no se inicie automáticamente hasta que descifres los discos manual o automáticamente (en nuestro ejemplo, esto lo hace zabbix)
**Tampoco uso NAT de cbsd, sino que 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 para celdas
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Red de Bitcoin puerto de reenvío
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 las políticas del cortafuegos es también un tema separado, por lo que no profundizaré en la configuración de la política BLOCK ALL y las configuraciones de listas blancas, se puede hacer leyendo o cualquiera de la gran cantidad de artículos disponibles en Google.
Bueno, tenemos cbsd instalado, es hora de crear nuestro primer caballo de trabajo: el demonio de Bitcoin en una celda.
cbsd jconstruct-tui
Aquí vemos el diálogo de creación de una celda. ¡Después de haber configurado todos los valores, creamos!
Al crear la primera celda, se debe elegir qué usar como base para las celdas. Elijo la distribución del repositorio de FreeBSD con el comando repo. Esta elección se hace solo al crear la primera celda de una versión específica (se pueden alojar celdas de cualquier versión que sea más nueva que la del host).
Una vez que todo está instalado, ¡iniciamos la celda!
# cbsd jstart bitcoind
Pero necesitamos instalar software en la celda.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind para entrar en la consola de la celda
y ya dentro de la celda instalamos el software con sus dependencias (nuestro sistema host permanece limpio)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoin en la celda está presente, pero necesitamos anonimato, porque queremos conectarnos a algunas celdas a través de la red TOR. Y en general, planeamos ejecutar la mayoría de las celdas con software sospechoso solo a través de un proxy. Gracias a pf se puede desactivar NAT para un cierto rango de direcciones IP en la red local y permitir NAT solo para nuestro nodo TOR. Así, incluso si un malware penetra en la celda, es probable que no logre comunicarse con el mundo exterior, y si lo hace, no revelará la IP de nuestro servidor. Por eso creamos otra celda para 'redirigir' servicios como 'servicio .onion' y como proxy para salir a Internet.
# 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 escuchar en la dirección local (disponible para todas las celdas)
SOCKSPort 192.168.0.2:9050
¿Qué más nos falta para la felicidad completa? Sí, necesitamos un servicio para nuestra web, tal vez más de uno. Iniciaremos nginx, que actuará como reverse-proxy 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 aquí hemos colocado 150 MB de dependencias en la celda. Y el host sigue limpio.
Volveremos a la configuración de nginx más tarde, necesitamos levantar otras dos celdas para nuestra pasarela de pagos en nodejs y rust, y una aplicación web, que por alguna razón está en apache y php, y además para esta última necesitamos 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
Luego descargamos nuestra aplicación con git y la 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 paquetes. en la celda.
Aquí damos acceso al desarrollador por SSH directamente a la celda, ellos mismos harán todo:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — cambiamos el puerto SSH de la celda a cualquier número aleatorio
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Bueno, el servicio está en marcha, solo falta agregar una regla en pf firewall
Veamos cuáles son nuestras IP en las celdas y cómo se ve nuestra 'red local'
# jls
JID Dirección IP Nombre de Host Ruta
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/webappy agregaremos 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
y ya que estamos aquí, también agregaremos una regla para el 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
Ahora un poco sobre bitcoin
Lo que tenemos es una aplicación web que es accesible desde afuera, y se comunica localmente con nuestra pasarela de pagos. Ahora necesitamos preparar el entorno de trabajo para interactuar con la red de bitcoin: un nodo bitcoind esto es solo un demonio que mantiene una copia local de la blockchain actual. Este demonio tiene RPC y funcionalidad de billetera, pero para el desarrollo de aplicaciones hay «envoltorios» más convenientes. Para comenzar, decidimos instalar electrum — es una billetera CLI. la utilizaremos como «almacenamiento en frío» para nuestros bitcoins, que en general son aquellos bitcoins que se necesitan guardar «fuera» del sistema accesible para los usuarios y, en general, lejos de todos. También tiene una GUI, por lo que planeamos usar la misma billetera en
nuestros portátiles. Por ahora, utilizaremos electrum con servidores públicos, y más tarde levantaremos , para no depender de nadie.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
otros 700 MB de software tenemos en la celda
electrum:/@[8:53] # adduser
Nombre de usuario: wallet
Nombre completo:
Uid (Dejar vacío para predeterminado):
Grupo de inicio [wallet]:
El grupo de inicio es wallet. ¿Invitar a wallet a otros grupos? []:
Clase de inicio [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Directorio home [\/home\/wallet]:
Permisos del directorio home (Dejar vacío para predeterminado):
¿Usar autenticación basada en contraseña? [yes]: no
¿Bloquear la cuenta después de la creación? [no]:
Nombre de usuario : wallet
Contraseña :
Nombre completo :
Uid : 1001
Clase :
Grupos : wallet
Home : \/home\/wallet
Modo de home :
Shell : \/bin\/tcsh
Bloqueado : no
OK? (yes\/no): yes
adduser: INFO: Añadido correctamente (wallet) a la base de datos de usuarios.
¿Añadir otro usuario? (yes\/no): no
¡Adiós!
electrum:/@[8:53] # su walletelectrum:/@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Guarde su semilla en un lugar seguro; si la pierde, no podrá restaurar su billetera.",
"path": "\/usr\/home\/wallet\/.electrum\/wallets\/default_wallet",
"seed": "celoso cerdo material cinta joven puñetazo visual vale cactus pájaro aleatorio"
}Ahora hemos creado una billetera.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
Para nuestro on-chain billetera solo podrá conectarse un círculo limitado de personas. Para no abrir el acceso desde fuera en esta celda, las conexiones por SSH se realizarán a través de TOR (una versión descentralizada de VPN). Activamos en la celda SSH, pero no tocamos nuestro pf.conf en el host.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Ahora desconectaremos la celda con la billetera del acceso a Internet. Le asignaremos una dirección IP de otro espacio de subred que no esté NATeado. Primero cambiaremos /etc/pf.conf en el host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0\/24" cambiaremos a JAIL_IP_POOL="192.168.0.0\/25", de esta manera, todas las direcciones 192.168.0.126-255 no tendrán acceso directo a Internet. Una especie de red de 'air-gap' por software. Y la regla NAT permanece igual.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Reiniciamos las reglas
# pfctl -f /etc/pf.conf
Ahora nos ocuparemos de nuestra celda
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Eliminar IP antigua: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Configurar nueva IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, pero ahora también dejará de funcionar el sistema. Sin embargo, podemos indicar un proxy del sistema. Pero hay un pero, en TOR este es un proxy SOCKS5, y para mayor comodidad, también necesitaríamos 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
Bien, ahora tenemos dos servidores proxy en nuestro sistema, y ambos funcionan a través de TOR: socks5://192.168.0.2:9050 y
Ahora podemos configurar el entorno de nuestra 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:8123Ahora el shell funcionará a través del proxy. Si queremos instalar paquetes, vale la pena añadir en /usr/local/etc/pkg.conf desde la raíz de la celda
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Y ahora ha llegado el momento de añadir el servicio oculto de TOR como 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: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.onionAquí está nuestra dirección para conectarnos. Vamos a verificar desde la máquina local. Pero primero tenemos que añadir nuestra clave SSH:
wallet@electrum:/ % mkdir ~/ .ssh
wallet@electrum:/ % ee ~/ .ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localY desde la máquina cliente con 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
Conectándose (Para que esto funcione, se necesita un demonio local de TOR, que escucha en el 9050)
user@local ~$ ssh remotebtc
La autenticidad del host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (no hay hostip para el comando proxy)' no puede ser establecida.
La huella digital de la clave ECDSA es SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
¿Está seguro de que quiere continuar conectándose (sí/no/[huella digital])? sí
Advertencia: Se agregó permanentemente 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) a la lista de hosts conocidos.
FreeBSD 12.1-RELEASE-p1 GENERIC
Para ahorrar espacio en disco en su directorio personal, comprima los archivos que rara vez usa con "gzip filename".
-- Dru
wallet@electrum:~ % logout
¡Éxito!
Para trabajar con pagos instantáneos y micropagos, también necesitamos un nodo , de hecho, esta será nuestra herramienta principal para trabajar con bitcoin. A *, que vamos a utilizar como demonio, tiene , que es una interfaz HTTP (REST) completa y permite trabajar tanto con transacciones off-chain como on-chain. c-lightning para funcionar necesita bitcoind un nodo.
*hay diferentes implementaciones del protocolo Lightning Network en diferentes lenguajes de programación. De las que hemos probado, c-lightning (escrito en C) ha demostrado ser el más estable y eficiente en recursos.
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/@[10:23] # adduser
Nombre de usuario: 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 se compila e instala todo lo necesario, crearemos un usuario RPC para lightningd en bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
# permitir solo c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Mi caótico cambio entre celdas no parece tan caótico si señalamos la utilidad tmux, que permite crear múltiples subsesiones de terminal dentro de una misma sesión. Análogo a: screen
Bueno, no queremos exponer la IP real de nuestro nodo y queremos realizar todas las operaciones financieras a través de TOR. Por lo tanto, necesitamos otro .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.onionahora crearemos el config 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
# 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=miusuario:miclave
#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
# para el ejemplo anterior, los registros de inicialización (mezclados con los registros de lightningd) deberían 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 ~/.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 necesitas crear un archivo de configuración para bitcoin-cli, la utilidad que se comunica con 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"
]ejecutamos lightningd
lightning@lightning:~ % lightningd --daemon
El propio lightningd se puede gestionar la utilidad lightning-cli, por ejemplo:
lightning-cli newaddr obtener una dirección para un nuevo pago entrante
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all enviar a la dirección todo el dinero del monedero (todas las direcciones on-chain)
También hay comandos para operaciones off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etc.
Y para comunicarse 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'
Resumiendo
# jls
JID Dirección IP Nombre de host Ruta
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
Contamos con un conjunto de contenedores, cada uno con su propio nivel de acceso tanto a la red local como al exterior.
# zfs list
NOMBRE USADO DISPONIBLE REFERIDO PUNTO DE MONTAJE
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 se puede ver, bitcoind ocupa todo el espacio de 190 GB. ¿Y si necesitáramos otra nodo para pruebas? Aquí es donde ZFS entra en juego. Con la ayuda de cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Se puede crear un snapshot y vincular una nueva celda a este snapshot. La nueva celda tendrá su propio espacio, pero en el sistema de archivos solo se considerará la diferencia entre el estado actual y el original (ahorrará al menos 190 GB).
Cada celda es su propio conjunto de datos ZFS, y esto es extremadamente conveniente. hacer otras cosas geniales, como enviar snapshots a través de SSH. No describiremos esto, ya hay suficiente información.
También es importante señalar la necesidad de monitoreo remoto del host, tenemos para estos fines .
B — seguridad
En cuanto a la seguridad, partamos de principios clave en el contexto de la infraestructura:
Privacidad — Las herramientas estándar de sistemas similares a UNIX garantizan la ejecución de este principio. Separamos lógicamente el acceso a cada elemento del sistema — la celda. El acceso se realiza mediante la autenticación estándar de usuarios con claves personales. Toda la comunicación entre y hasta las celdas finales se produce de forma cifrada. Gracias al cifrado de los discos, no tenemos que preocuparnos por la seguridad de los datos durante el reemplazo del disco o la migración 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 ejecución de este principio se realiza en varios niveles diferentes. Primero, es importante señalar que en el caso del hardware del servidor, la memoria ECC y ZFS ya "de fábrica" se encargan de la integridad de los datos a nivel de bits. Los snapshots instantáneos permiten hacer copias de seguridad en cualquier momento en caliente. Herramientas convenientes de exportación-importación de celdas hacen que la replicación de celdas sea sencilla.
Disponibilidad — Esto es opcional. Depende de tu nivel de notoriedad y de la existencia de detractores. En nuestro ejemplo, aseguramos la disponibilidad de la billetera exclusivamente desde la red TOR. Si es necesario, se puede bloquear todo en el firewall y permitir el acceso al servidor exclusivamente a través de túneles (TOR o VPN, eso es otro tema). De esta manera, el servidor estará aislado del mundo exterior tanto como sea posible, y solo nosotros podremos influir en su disponibilidad.
Imposibilidad de renuncia — Y esto depende de la explotación futura y del cumplimiento de las políticas correctas de derechos de usuario, acceso, etc. Pero con el enfoque correcto, todas las acciones de los usuarios son auditadas, y gracias a soluciones criptográficas es posible identificar de manera inequívoca quién y cuándo realizó determinadas acciones.
Por supuesto, la configuración descrita no es un ejemplo absoluto de cómo debe ser siempre; es más bien uno de los ejemplos de cómo puede ser, manteniendo unas capacidades de escalabilidad y personalización muy elásticas.
¿Y qué hay de la virtualización completa?
Sobre la virtualización completa con cbsd se puede . Solo añadiré que para trabajar bhyve es necesario habilitar ciertos parámetros del núcleo.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Así que si de repente hay necesidad de usar Docker, ¡levantamos algún Debian y adelante!
Eso es todo
Probablemente eso es todo lo que quería compartir. Si te gustó el artículo, puedes enviarme bitcoins — . Si quieres probar las celdas en acción y tienes un poco de bitcoins, puedes visitar mi .
Fuente: habr.com
