Tak se stalo, že jsem profesionální administrátor počítačových systémů a sítí (zkráceně: sysadmin) a měl jsem možnost pracovat s nejrůznějšími systémy během více než 10 let své profesní činnosti, včetně těch, které vyžadují [po|za]výšená bezpečnostní opatření. A také se stalo, že před nějakým časem jsem našel zajímavý , a nejenže jsem ho používal, ale také jsem spustil několik mikroservisů, abych se naučil samostatně pracovat s bitcoinovou sítí (p2p přece jen) z pohledu vývojáře (jsem sice tak trošku amatérský dev, jen jsem kolem projížděl). Ale nemluvím o vývoji, mluvím o bezpečném a efektivním prostředí pro aplikace.
Finanční technologie (fintech) jdou ruku v ruce s informační bezpečností (infosec), a první bez druhého sice může fungovat, ale ne dlouho. A proto se chci podělit o svou zkušenost a o soubor nástrojů, které používám, což zahrnuje jak fintech, tak i infosec, přičemž obojí může být použito i v širším nebo úplně jiném smyslu. V tomto článku nebudu mluvit tolik o bitcoinu, jako spíše o modelu infrastruktury pro vývoj a provoz finančních (a nejen) služeb — jednoduše řečeno těch služeb, kde má „B“ význam. To platí jak pro bitcoinovou burzu, tak pro typický korporátní „zoo“ služeb malé firmy, která s bitcoinem vůbec nesouvisí.
Chci poznamenat, že jsem zastáncem principů „keep it stupid simple“ a „less is more“, takže jak článek, tak popsané v něm bude mít vlastnosti, které tyto principy odrážejí.
Představovaný scénář: Pojďme si vše přesně ukázat na příkladu bitcoinové směnárny. Rozhodli jsme se spustit směnu rublů, dolarů a eur za bitcoiny a zpět, a už máme funkční řešení, ale pro jiné digitální měny jako jsou Qiwi a Webmoney, tzn. vyřešili jsme všechny právní otázky, máme hotovou aplikaci, která slouží jako platební brána pro rublů, dolarů a eur a další platební systémy. Je propojena s našimi bankovními účty a má určité API pro naše koncové aplikace. Také máme webovou aplikaci, která funguje jako směnárna pro uživatele, něco jako typický Qiwi nebo Webmoney účet — založte si účet, přidejte kartu, atd. Komunikuje s naší bránou, třeba pomocí REST API v lokálním prostředí. A teď jsme se rozhodli připojit bitcoiny a současně vylepšit infrastrukturu, protože původně vše bylo rychle zprovozněno na VirtualBoxech v kanceláři pod stolem... lidé začali používat web a my jsme se začali obávat o dostupnost a výkonnost.
Takže začneme s hlavním — výběrem serveru. Protože podnikání v našem příkladu je malé a důvěřujeme poskytovateli (OVH), zvolíme ve které nelze nainstalovat systém z originálního obrazu .iso, ale nevadí, oddělení IT bezpečnosti určitě provedou analýzu nainstalovaného obrazu. A když porosteme, pronajmeme si vůbec vlastní skříň se zámkem a omezeným fyzickým přístupem, nebo možná postavíme vlastní datové centrum. V každém případě je dobré mít na paměti, že při pronájmu hardwaru a instalaci hotových obrazů je šance, že ve vašem systému bude viset 'trojský kůň od poskytovatele', který v většině případů není určen pro sledování vás, ale aby poskytl pohodlnější nástroje pro správu serveru.
Instalace serveru
Tady je to jednoduché. Vybereme hardware, který splňuje naše potřeby. Poté vybereme obraz FreeBSD. Nebo se připojíme (v případě jiného poskytovatele a našeho hardwaru) přes IPMI nebo s monitorem a načteme .iso obraz FreeBSD. Pro orchestrální instalaci používám a . Jediné, v našem případě s Kimsufi, jsme vybrali vlastní instalaci aby dva disky v zrcadle měly 'otevřené' pouze zaváděcí a /home oddíly, zbytek prostoru disku bude zašifrován, ale o tom později.
Instalace systému probíhá standardním způsobem, nebudu se na tom zdržovat, pouze poznamenám, že před zahájením provozu byste měli věnovat pozornost hardeningu možnostem, které nabízí bsdinstaller na konci instalace (pokud systém instalujete sami):
Existuje na toto téma, stručně ho zde zopakuji.
Zmiňované parametry lze také aktivovat na již nainstalovaném systému. K tomu je potřeba upravit soubor zaváděče a povolit parametry jádra. *ee — to je editor v 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=1Také byste měli zajistit, že máte nainstalovanou nejnovější verzi systému, a . V našem případě například vyžaduje upgrade na nejnovější verzi, protože předinstalované obrazy zaostávají o půl roku až rok. A také upravujeme SSH port na jiný než je standardní, přidáváme autentizaci pomocí klíčů a vypínáme hesla.
Poté nastavíme aide, monitorování stavu konfiguračních souborů systému. Podrobněji si o tom můžete přečíst .
pkg install aide
a upravíme náš 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/$MYFILENAMEAktivujeme
sysrc auditd_enable=YES
# service auditd start
Jak tuto věc spravovat, je výborně popsáno v .
Nyní restartujeme a přejdeme k softwaru na serveru. Každý server představuje hypervisor pro kontejnery nebo celé virtuální stroje. Proto je důležité, aby procesor podporoval VT-x a EPT, pokud plánujeme používat plnou virtualizaci.
Jako správu kontejnerů a virtuálních strojů používám od , přeji mu hodně zdraví a úspěchů za tuto skvělou utilitu!
Kontejnery? Zase docker?
Ale kdepak. — to je skvělý nástroj pro kontejnerizaci, a zmiňovaný cbsd pro orchestraci těchto kontejnerů, jehož jméno je — buňky.
Klece jsou vysoce efektivním řešením pro vytváření infrastruktury pro různé účely, kde je nakonec požadována úplná izolace jednotlivých služeb nebo procesů. V podstatě se jedná o klon hostitelského systému, ale není potřeba plná virtualizace «hardwaru». Díky tomu se prostředky neztrácejí na «hostitelské OS», ale pouze na vykonávanou práci. Když se klece používají pro vnitřní potřeby, je to velmi pohodlné řešení pro optimální využití zdrojů – množství klecí na jednom fyzickém serveru může každá samostatně využívat veškeré prostředky serveru, pokud je to potřeba. Vzhledem k tomu, že různé podslužby obvykle potřebují dodatečné prostředky v různých dobách, lze z jednoho serveru vytěžit maximální výkon, pokud správně naplánujeme a rozložíme klece mezi servery. V případě potřeby lze klecím také nastavit omezení na používané zdroje.
Jak to vypadá s plnou virtualizací?
Jak mi je známo, cbsd podporuje práci bhyve a XEN hypervisory. Druhý jsem nikdy nepoužíval, ale první je relativně mladý . Podíváme se na příklad použití bhyve v dalším příkladu.
Instalace a nastavení hostitelského prostředí
Používáme FS . To je velmi mocný nástroj pro správu prostoru na serveru. Díky ZFS můžeme přímo z disků vytvářet pole nejrůznějších konfigurací, dynamicky «za chodu» rozšiřovat prostor, měnit vadné disky, spravovat snímky a mnoho, mnoho dalšího, co by se dalo popsat v celé sérii článků. Vraťme se k našemu serveru a jeho diskům. Na začátku instalace jsme na discích nechali volné místo pro šifrované oddíly. Proč tak? To proto, aby se systém automaticky spouštěl a naslouchal přes SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
přidáváme oddíl disku na zbývající místo
geli init /dev/ada0p4
zadáme naše šifrovací heslo
geli attach /dev/ada0p4
opět zadáváme heslo a objeví se nám zařízení /dev/ada0p4.eli — to je náš šifrovaný prostor. Poté opakujeme totéž pro /dev/ada1 a další disky v poli. A vytvoříme nový .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — no a máme minimální bojovou sestavu připravenou. Zrcadlové pole disků pro případ, že jeden ze tří selže.
Vytváříme dataset na novém „poolu“
zfs create vms/jails
pkg install cbsd — spustili jsme příkaz a instalujeme management pro naše jails.
Poté co cbsd je nainstalován, je třeba ho inicializovat:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
a odpovíme na spoustu otázek, většinou odpovědí podle výchozího nastavení.
*Pokud používáte šifrování, je důležité, aby démon cbsdd nebude automaticky spuštěn, dokud neodšifrujete disky ručně nebo automaticky (v našem příkladu to dělá zabbix)
**Také nepoužívám NAT od cbsd, ale nastavím ho sám v 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 pro jails
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Port forward pro Bitcoin síť
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
Nastavení pravidel firewallu je také samostatné téma, proto se nebudu hlouběji zabývat nastavením politiky BLOCK ALL a nastavením whitelistů, to lze provést přečtením nebo jakéhokoli z obrovského množství článků dostupných na googlu.
No co… máme nainstalováno cbsd, je čas vytvořit našeho prvního pracovního koně — bitcoinového démona v jailu!
cbsd jconstruct-tui
Tady vidíme dialog pro vytvoření jailu. Po nastavení všech hodnot jej vytvoříme!
Při vytváření prvního jailu je třeba zvolit, co použít jako základ pro jaily. Já volím distribuci z repozitáře FreeBSD pomocí příkazu repo. Tento výběr se provádí pouze při vytváření prvního jailu konkrétní verze (můžete hostit jaily jakýchkoli verzí, které jsou starší než verze hostitele).
Poté, co je vše nainstalováno — spouštíme jail!
# cbsd jstart bitcoind
Ale potřebujeme do jailu nainstalovat software.
# jls
JID IP Adresa Hostname Cesta
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind abychom se dostali do konzole jailu
a uvnitř jailu nainstalujeme software s jeho závislostmi (náš hostitelský systém zůstává čistý)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoin v jailu je, ale potřebujeme anonymitu, protože se chceme připojit k některým jailům přes síť TOR. A vůbec, máme v plánu většinu jailů se podezřelým softwarem provozovat pouze přes proxy. Díky pf Můžeme vypnout NAT pro určitý rozsah IP adres v místní síti a povolit NAT pouze pro náš TOR uzel. Tak i když se do klece dostane škodlivý software, pravděpodobně se nedostane do kontaktu se světem venku, a i když se dostane, neodhalí IP našeho serveru. Proto vytváříme ještě jednu klec pro "přesměrování" služeb jako je " .onion" služba a pro proxy pro přístup na internet pro jednotlivé klece.
# 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
Nastavujeme naslouchání na lokální adrese (přístupné pro všechny klece)
SOCKSPort 192.168.0.2:9050
Co nám ještě chybí pro úplné štěstí? Ano, potřebujeme službu pro náš web, možná i víc než jednu. Spustíme nginx, který bude sloužit jako reverse-proxy a postará se o prodloužení certifikátů Let’s Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev: /@[15:47] # pkg install nginx py36-certbot
A tak jsme umístili 150 MB závislostí do klece. A hostitel stále zůstává čistý.
K nastavení nginx se vrátíme později, potřebujeme vztyčit ještě dvě klece pro náš platební bránu na nodejs a rust a webovou aplikaci, která je z nějakého důvodu na apachu a PHP, a také pro tuto potřebujeme databázi 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
… a dalších 380 MB balíků izolováno.
Dále stáhneme naše aplikace pomocí gitu a spustíme je.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp: /@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB balíků. v kleci.
Tady dáváme přístup vývojářům přes SSH přímo do klece, oni si tam už vše udělají:
webapp: /@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — měníme port SSH klece na libovolný náhodný
webapp: /@[16:02] # sysrc sshd_enable=YES
webapp: /@[16:02] # service sshd start
Tak, služba je spuštěna, zbývá přidat pravidlo do pf firewall
Podíváme se, jaké IP adresy máme u klecí a jak vůbec vypadá naše „lokalka“
# jls
JID IP Adresa Hostitel Cesta
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/webappa přidáme pravidlo
# 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
No a když jsme tu, přidáme také pravidlo na 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
A teď trochu o bitcoinech
Co máme — máme webovou aplikaci, která je dostupná zvenku, a místně komunikuje s naší platební branou. Teď potřebujeme připravit pracovní prostředí pro interakci s vlastní bitcoinovou sítí — node. bitcoind to je jen démon, který podporuje místní kopii aktuálního blockchainu. Tento démon má RPC a funkčnost peněženky, nicméně pro vývoj aplikací existují pohodlnější "obaly". Nejdříve jsme se rozhodli nainstalovat electrum — to je CLI peněženka. bude u nás používána jako "studené úložiště" pro naše bitcoiny — v podstatě ty bitcoiny, které je třeba uchovávat "mimo" systém přístupný uživatelům a daleko od všech. Také má GUI, proto takovou peněženku plánujeme použít na
našich laptopech. Prozatím budeme používat electrum s veřejnými servery, a později v další kleci zprovozníme , abychom byli zcela nezávislí.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
ještě 700 MB softwaru máme v kleci
electrum:/@[8:53] # adduser
Uživatelské jméno: wallet
Celé jméno:
Uid (nechejte prázdné pro výchozí hodnotu):
Přihlašovací skupina [wallet]:
Přihlašovací skupina je wallet. Pozvat wallet do dalších skupin? []:
Přihlašovací třída [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Domovský adresář [ /home/wallet]:
Oprávnění k domovskému adresáři (nechejte prázdné pro výchozí hodnotu):
Použít ověřování s heslem? [yes]: no
Zamknout účet po vytvoření? [no]:
Uživatelské jméno : wallet
Heslo :
Celé jméno :
Uid : 1001
Třída :
Skupiny : wallet
Domov : /home/wallet
Mód domova :
Shell : /bin/tcsh
Zamčeno : ne
OK? (yes/no): yes
adduser: INFO: Úspěšně přidáno (wallet) do databáze uživatelů.
Přidat dalšího uživatele? (yes/no): no
Na shledanou!
electrum:/@[8:53] # su walletelectrum:/@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Uložte si svůj seed na bezpečném místě; pokud jej ztratíte, nebudete schopni obnovit svou peněženku.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "žárlivý vepř materiál stužka mladý úder vizuální v pořádku kaktus náhodný pták"
}Takže teď máme vytvořenou peněženku.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum:/ % electrum-3.6 help
K naší on-chain peněžence se od nynějška bude moci připojit pouze omezený okruh osob. Abychom neotevřeli přístup zvenčí do této klece, připojení přes SSH proběhne prostřednictvím TOR (taková decentralizovaná varianta VPN). Spouštíme v kleci SSH, ale neleze do našeho pf.conf na hostiteli.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
Teď vypneme kleci s peněženkou přístup k internetu. Dáme jí IP adresu z jiného prostoru podsítě, která není NAT-ována. Nejprve změníme /etc/pf.conf na hostiteli
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" změníme na JAIL_IP_POOL="192.168.0.0/25", tímto způsobem všechny adresy 192.168.0.126-255 nebudou mít přístup k internetu. Jakýsi softwarový „air-gap“ network. A pravidlo NAT zůstává stejné.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Přetížení pravidel
# pfctl -f /etc/pf.conf
Teď se pustíme do naší buněk
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Odstranit starou IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Nastavit novou IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmmm, ale teď nám přestane fungovat i samotný systém. Můžeme ale specifikovat systémový proxy. Ale je tu jedno velké ale, na TOR je to SOCKS5 proxy, a pro pohodlí bychom potřebovali ještě HTTP proxy.
# 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
Tak, nyní máme v našem systému dva proxy servery, a oba směrují přes TOR: socks5://192.168.0.2:9050 a
Teď můžeme nastavit prostředí našeho peněženky
# 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:8123no, nyní shell bude fungovat přes proxy. Pokud chceme instalovat balíčky, má smysl přidat do /usr/local/etc/pkg.conf z pod root buněk
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}A teď přišel čas přidat TOR hidden service jako adresu našeho SSH služby v buně peněženky.
# 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.onionTady je naše adresa pro připojení. Pojďme to zkontrolovat z místního počítače. Ale nejprve musíme přidat náš SSH klíč:
wallet@electrum:/ % mkdir ~/ .ssh
wallet@electrum:/ % ee ~/ .ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localNo a z klientské linuxové mašiny
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
Připojujeme se (Aby to fungovalo, potřebujeme lokální TOR démon, který naslouchá na 9050)
user@local ~$ ssh remotebtc
Autenticita hostitele 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' nemůže být potvrzena.
ECDSA klíč otisk je SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Jste si jisti, že chcete pokračovat v připojení (ano/ne/[otisk])? ano
Varování: Trvale přidáno 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) do seznamu známých hostitelů.
FreeBSD 12.1-RELEASE-p1 GENERIC
Pro ušetření místa na disku ve vašem domácím adresáři, komprimujte soubory, které zřídka
používáte s "gzip název_souboru".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Úspěch!
Pro práci s okamžitými a mikro-platbami potřebujeme také uzel , to vlastně bude náš hlavní pracovní nástroj s bitcoiny. U *, který zamýšlíme používat jako démona, je , který je plnohodnotným HTTP (REST) rozhraním a umožňuje pracovat jak s off-chain transakcemi, tak s on-chain transakcemi. c-lightning pro fungování je potřeba bitcoind noda.
*existují různé implementace v různých programovacích jazycích protokolu Lightning Network. Z těch, které jsme testovali, se c-lightning (napsaný v C) ukázal jako nejstabilnější a nejvíce efektivní z hlediska prostředků.
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:\/@[10:23] # adduser
Uživatelské jméno: 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
Pokud se teď během kompilace a instalace všeho potřebného vytvoříme RPC uživatele pro lightningd v bitcoind
# jexec bitcoind
bitcoind:\/@[10:36] # ee \/usr\/local\/etc\/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#pouze pro c-lightning
rpcallowip=192.168.0.7\/32bitcoind:\/@[10:39] # service bitcoind restart
Moje chaotické přepínání mezi okny se ukazuje být méně chaotické, pokud započítáme utilitu tmux, která umožňuje během jedné relace vytvářet více podsestavení terminálů. Analog: screen
Takže, nechceme odhalit skutečnou IP naší nody a chceme provádět všechny finanční operace přes TOR. Budeme potřebovat ještě jednu .onion.
# jexec tor
tor:/@[9:59] # ee /usr/local/etc/tor/torrc
HiddenServiceDir \/var\/db\/tor\/cln\/\nHiddenServicePort 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.onionteď vytvoříme konfiguraci pro 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
# pro výše uvedený příklad by počáteční protokoly (smíchané s protokoly lightningd) měly tisknout něco jakolightning@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 ~
je také potřeba vytvořit konfigurační soubor pro bitcoin-cli, nástroj, který komunikuje s bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testkontrolujeme
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]spouštíme lightningd
lightning@lightning:~ % lightningd --daemon
Samotný lightningd můžete ovládat nástroj lightning-cli, například:
lightning-cli newaddr získat adresu pro novou příchozí platbu
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all odeslat na adresu všechny peníze z peněženky (všechny on-chain adresy)
Také příkazy pro off-chain operace lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay atd.
A pro komunikaci s aplikací máme REST Api
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Shrnujeme
# jls
JID IP Adresa Název hostitele Cesta
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
Máme sadu kontejnerů, každý s vlastním úrovněm přístupu jak do tak i z lokální sítě.
# zfs list
NÁZEV VYUŽITÍ VOLNÉ ODKAZ MONTOVACÍ BOD
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-dataJak je vidět, bitcoind zabírá všech 190 GB prostoru. A co když budeme potřebovat další uzel pro testy? Zde je ZFS jako stvořený pro tuto situaci. Pomocí cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Můžete vytvořit snímek a připojit novou buňku k tomuto snímku. Nová buňka bude mít zcela vlastní prostor, ale ve FS se bude zohledňovat pouze rozdíl mezi aktuálním stavem a originálem (ušetříme minimálně 190 GB).
Každá buňka je samostatný datový set ZFS, což je velmi pohodlné. provádět různé další skvělé věci, jako je odesílání snímků přes SSH. Nehodláme to popisovat, už toho bylo dost.
Je také třeba zmínit potřebu vzdáleného monitorování hostitele, máme pro tyto účely .
B — bezpečnost
Pokud jde o bezpečnost, vycházejme z klíčových principů v kontextu infrastruktury:
Ochrana soukromí — Standardní nástroje systémů podobných UNIXu zajišťují splnění tohoto principu. Logicky oddělujeme přístup k každému logicky samostatnému prvku systému — buňce. Přístup je realizován prostřednictvím standardní uživatelské autentizace na základě osobních klíčů uživatelů. Veškerá komunikace mezi a do konečných buněk probíhá v šifrované podobě. Díky šifrování disků se nemusíme obávat o bezpečnost dat při výměně disku nebo migraci na jiný server. Jediný kritický přístup je přístup k hostitelskému systému, protože tento přístup obvykle zajišťuje přístup k datům uvnitř kontejnerů.
Integrita — Vykonávání tohoto principu probíhá na několika různých úrovních. Nejprve je důležité zmínit, že v případě serverového hardware, ECC paměti, ZFS již „z krabice“ pečuje o integritu dat na úrovni bitů informací. Okamžité snímky umožňují zálohování kdykoliv v reálném čase. Pohodlné nástroje pro export a import buněk usnadňují replikaci buněk.
Dostupnost — To už je volitelné. Závisí na míře vaší známosti a na tom, zda máte nepřátele. V našem příkladu jsme zajistili dostupnost peněženky výhradně z TOR sítě. Pokud to bude nutné, můžete na firewallu zablokovat vše a povolit přístup na server výhradně prostřednictvím tunelů (TOR nebo VPN je jiná otázka). Tak bude server odříznut od vnějšího světa co nejvíce, a jeho dostupnost budeme moci ovlivnit pouze my sami.
Nemožnost odmítnutí — To záleží na dalším používání a dodržování správných politik uživatelských práv, přístupu atd. Ale při správném přístupu jsou všechny akce uživatelů auditovány a díky kryptografickým řešením je možné jednoznačně identifikovat, kdo a kdy prováděl určité akce.
Samozřejmě, popsaná konfigurace není absolutním příkladem toho, jak by to mělo být vždy, je to spíše jeden z příkladů, jak to může být, přičemž si zachovává velmi flexibilní možnosti škálování a přizpůsobení.
A co úplná virtualizace?
O úplné virtualizaci prostřednictvím cbsd lze říci . Jen dodám, že pro práci bhyve je nutné aktivovat některé parametry jádra.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="ANO"
...Takže pokud by byla potřeba spustit docker, zvedneme nějaký debian a vpřed!
A to je vše
Snad je to vše, co jsem chtěl sdílet. Pokud se vám článek líbil, můžete mi poslat bitcoiny — . Pokud chcete vyzkoušet buňky v akci a máte nějaké bitcoiny, můžete navštívit můj .
Zdroj: habr.com
