Det skjedde slik at jeg av yrke er administrator av datasystemer og nettverk (kort sagt: systemadministrator), og jeg hadde muligheten til å fortelle prof. i litt mer enn 10 år. aktivitetene til et bredt spekter av systemer, inkludert de som krever [ekstremt] sikkerhetstiltak. Det hendte også at jeg for en tid tilbake fant det interessant dev
, så jeg gikk forbi). Men jeg snakker ikke om utvikling, jeg snakker om et trygt og effektivt miljø for applikasjoner.
Finansiell teknologi (fintech) gå ved siden av informasjonssikkerhet (INFOSEC) og den første kan fungere uten den andre, men ikke lenge. Derfor vil jeg dele min erfaring og settet med verktøy jeg bruker, som inkluderer begge deler fintechOg INFOSEC, og samtidig, og kan også brukes til et bredere eller helt annet formål. I denne artikkelen vil jeg fortelle deg ikke så mye om Bitcoin, men om infrastrukturmodellen for utvikling og drift av finansielle (og ikke bare) tjenester - med et ord, de tjenestene der "B" betyr noe. Dette gjelder både for Bitcoin-børsen og for den mest typiske bedriftens dyrehage av tjenester til et lite selskap som ikke er knyttet til Bitcoin på noen måte.
Jeg vil bemerke at jeg er tilhenger av prinsippene "hold det dumt enkelt" и "mindre er mer", derfor vil både artikkelen og det som er beskrevet i den ha egenskapene som disse prinsippene handler om.
Tenkt scenario: La oss se på alt ved å bruke eksemplet med en bitcoin-veksler. Vi bestemte oss for å starte utveksling av rubler, dollar, euro for bitcoins og tilbake, og vi har allerede en fungerende løsning, men for andre digitale penger som qiwi og webmoney, dvs. Vi har lukket alle juridiske spørsmål, vi har en ferdig applikasjon som fungerer som en betalingsgateway for rubler, dollar og euro og andre betalingssystemer. Den er koblet til våre bankkontoer og har en slags API for sluttapplikasjonene våre. Vi har også en nettapplikasjon som fungerer som en utveksler for brukere, vel, som en typisk qiwi- eller webmoney-konto – opprett en konto, legg til et kort og så videre. Den kommuniserer med gateway-applikasjonen vår, om enn via REST API i lokalområdet. Og så bestemte vi oss for å koble til bitcoins og samtidig oppgradere infrastrukturen, fordi... I utgangspunktet ble alt lagt opp i en hast på virtuelle bokser på kontoret under bordet... siden begynte å bli brukt, og vi begynte å bekymre oss for oppetid og ytelse.
Så la oss starte med det viktigste - å velge en server. Fordi virksomheten i vårt eksempel er liten og vi stoler på vertskapet (OVH) vi vil velge
Serverinstallasjon
Alt er enkelt her. Vi velger maskinvaren som passer våre behov. Velg deretter FreeBSD-bildet. Vel, eller vi kobler til (i tilfelle av en annen hoster og vår egen maskinvare) via IPMI eller med en skjerm og mater .iso FreeBSD-bildet inn i nedlastingen. For et orkesteroppsett bruker jeg
Installasjon av systemet skjer på en standard måte, jeg vil ikke dvele ved dette, jeg vil bare merke at det er verdt å ta hensyn til før du starter driften herding alternativene den tilbyr bsdinstaller
på slutten av installasjonen (hvis du installerer systemet selv):
Det er
Det er også mulig å aktivere de ovennevnte parameterne på et allerede installert system. For å gjøre dette, må du redigere bootloader-filen og aktivere kjerneparametere. *ee er en editor som dette i 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
Du bør også sørge for at du har den nyeste versjonen av systemet installert, og
Så konfigurerer vi aide
, overvåker statusen til systemkonfigurasjonsfiler. Du kan lese mer i detalj
pkg install aide
og rediger 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
Vi inkluderer
sysrc auditd_enable=YES
# service auditd start
Hvordan du administrerer denne saken er perfekt beskrevet i
Nå starter vi på nytt og fortsetter til programvaren på serveren. Hver server er en hypervisor for containere eller komplette virtuelle maskiner. Derfor er det viktig at prosessoren støtter VT-x og EPT hvis vi planlegger å bruke full virtualisering.
For å administrere containere og virtuelle maskiner jeg bruker
Containere? Docker igjen eller hva?
Men nei. cbsd
å orkestrere disse beholderne, som kalles celler.
Buret er en ekstremt effektiv løsning for å bygge infrastruktur for en rekke formål, hvor fullstendig isolering av individuelle tjenester eller prosesser til slutt kreves. I hovedsak er det en klone av vertssystemet, men det krever ikke full maskinvarevirtualisering. Og takket være dette brukes ikke ressurser på "gjeste-OS", men bare på arbeidet som utføres. Når celler brukes til interne behov, er dette en veldig praktisk løsning for optimal ressursbruk – en haug med celler på én maskinvareserver kan hver for seg bruke hele serverressursen om nødvendig. Med tanke på at vanligvis trenger forskjellige undertjenester tillegg. ressurser til forskjellige tider, kan du trekke ut maksimal ytelse fra én server hvis du planlegger og balanserer cellene mellom serverne på riktig måte. Om nødvendig kan celler også gis begrensninger på ressursen som brukes.
Hva med full virtualisering?
Så vidt jeg vet cbsd
støtter arbeidet bhyve
og XEN hypervisorer. Jeg har aldri brukt den andre, men den første er relativt ny bhyve
i eksemplet nedenfor.
Installere og konfigurere vertsmiljøet
Vi bruker FS
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
legg til en diskpartisjon til den gjenværende plassen
geli init /dev/ada0p4
skriv inn vårt krypteringspassord
geli attach /dev/ada0p4
Vi skriver inn passordet igjen og vi har en enhet /dev/ada0p4.eli - dette er vår krypterte plass. Så gjentar vi det samme for /dev/ada1 og resten av diskene i arrayet. Og vi lager en ny
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli
– Vel, vi har minimumskampsettet klart. Et speilet utvalg av disker i tilfelle en av de tre feiler.
Opprette et datasett på en ny "pool"
zfs create vms/jails
pkg install cbsd
— vi lanserte et team og satte opp ledelse for cellene våre.
etter cbsd
installert, må den initialiseres:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
Vel, vi svarer på en haug med spørsmål, for det meste med standardsvar.
*Hvis du bruker kryptering, er det viktig at demonen cbsdd
startet ikke automatisk før du dekrypterer diskene manuelt eller automatisk (i vårt eksempel er dette gjort av zabbix)
**Jeg bruker heller ikke NAT fra cbsd
, og jeg konfigurerer det selv i 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
Å sette opp brannmurpolicyer er også et eget emne, så jeg vil ikke gå dypt inn på å sette opp BLOCK ALL policy og sette opp hvitelister, det kan du gjøre ved å lese
Vel... vi har installert cbsd, det er på tide å lage vår første arbeidshest - den burede Bitcoin-demonen!
cbsd jconstruct-tui
Her ser vi celleopprettingsdialogen. Etter at alle verdiene er satt, la oss lage!
Når du oppretter din første celle, bør du velge hva du skal bruke som base for cellene. Jeg velger en distribusjon fra FreeBSD-depotet med kommandoen repo
. Dette valget gjøres kun når du oppretter den første cellen i en spesifikk versjon (du kan være vert for celler av enhver versjon som er eldre enn vertsversjonen).
Etter at alt er installert, lanserer vi buret!
# cbsd jstart bitcoind
Men vi må installere programvare i buret.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoind
jexec bitcoind
for å komme inn i cellekonsollen
og allerede inne i cellen installerer vi programvaren med dens avhengigheter (vertssystemet vårt forblir rent)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Det er Bitcoin i buret, men vi trenger anonymitet fordi vi ønsker å koble til noen bur via TOP-nettverket. Generelt planlegger vi å kjøre de fleste celler med mistenkelig programvare kun via en proxy. Takk til pf
Du kan deaktivere NAT for et visst utvalg av IP-adresser på det lokale nettverket, og tillate NAT kun for TOR-noden vår. Selv om skadelig programvare kommer inn i cellen, vil den mest sannsynlig ikke kommunisere med omverdenen, og hvis den gjør det, vil den ikke avsløre IP-en til serveren vår. Derfor oppretter vi en annen celle for å "videre" tjenester som en ".onion"-tjeneste og som en proxy for tilgang til Internett til individuelle celler.
# 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
Sett til å lytte på en lokal adresse (tilgjengelig for alle celler)
SOCKSPort 192.168.0.2:9050
Hva mer trenger vi for fullstendig lykke? Ja, vi trenger en tjeneste for nettet vårt, kanskje mer enn én. La oss lansere nginx, som vil fungere som en omvendt proxy og sørge for å fornye Let's Encrypt-sertifikater
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
Så vi plasserte 150 MB med avhengigheter i et bur. Og verten er fortsatt ren.
La oss gå tilbake til å sette opp nginx senere, vi må heve ytterligere to celler for vår betalingsgateway på nodejs og rust og en webapplikasjon, som av en eller annen grunn er i Apache og PHP, og sistnevnte krever også en MySQL-database.
# 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
...og ytterligere 380 MB med pakker isolert
Deretter laster vi ned applikasjonen vår med git og starter den.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB pakker. i et bur.
her gir vi utvikleren tilgang via SSH direkte til cellen, de vil gjøre alt der selv:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267
— endre SSH-porten til cellen til en hvilken som helst vilkårlig
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Vel, tjenesten kjører, alt som gjenstår er å legge til regelen pf
brannmur
La oss se hvilken IP-adresse cellene våre har og hvordan vårt "lokale område" generelt ser ut.
# 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
og legg til en regel
# 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
Vel, siden vi er her, la oss også legge til en regel for omvendt 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
Vel, nå litt om bitcoins
Det vi har er at vi har en nettapplikasjon som er eksponert eksternt og den snakker lokalt med betalingsgatewayen vår. Nå må vi forberede et arbeidsmiljø for samhandling med selve Bitcoin-nettverket - noden bitcoind
det er bare en demon som holder den lokale kopien av blokkjeden oppdatert. Denne daemonen har RPC- og lommebokfunksjonalitet, men det er mer praktiske "innpakninger" for applikasjonsutvikling. Til å begynne med bestemte vi oss for å sette electrum
er en CLI-lommebok.
bærbare datamaskiner. Foreløpig vil vi bruke Electrum med offentlige servere, og senere vil vi heve det i en annen celle
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
ytterligere 700 MB programvare i buret vårt
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"
}
Nå har vi laget en lommebok.
wallet@electrum:/ % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]
wallet@electrum:/ % electrum-3.6 help
Til vår på kjedet Bare et begrenset antall personer vil kunne koble seg til lommeboken fra nå av. For ikke å åpne tilgang til denne cellen fra utsiden, vil tilkoblinger via SSH skje gjennom TOP (en desentralisert versjon av VPN). Vi starter SSH i cellen, men berører ikke vår pf.conf på verten.
electrum:/@[9:00] # sysrc sshd_enable=YES
electrum:/@[9:00] # service sshd start
La oss nå slå av cellen med lommebokens Internett-tilgang. La oss gi den en IP-adresse fra en annen subnettplass som ikke er NATert. La oss først endre oss /etc/pf.conf
på verten
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24"
la oss endre det til JAIL_IP_POOL="192.168.0.0/25"
, dermed vil ikke alle adresser 192.168.0.126-255 ha direkte tilgang til Internett. Et slags programvare "air-gap" nettverk. Og NAT-regelen forblir som den var
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Overbelastning av reglene
# pfctl -f /etc/pf.conf
La oss nå ta på cellen vår
# 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, men nå slutter selve systemet å fungere for oss. Vi kan imidlertid spesifisere en systemproxy. Men det er én ting, på TOR er det en SOCKS5-proxy, og for enkelhets skyld vil vi også ha en 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 = socks5
polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Vel, nå er det to proxy-servere i systemet vårt, og begge sendes ut via TOR: socks5://192.168.0.2:9050 og
Nå kan vi konfigurere lommebokmiljøet vårt
# 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
Vel, nå vil skallet fungere fra en proxy. Hvis vi ønsker å installere pakker, bør vi legge til /usr/local/etc/pkg.conf
fra under roten av buret
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}
Vel, nå er det på tide å legge til den skjulte TOR-tjenesten som adressen til vår SSH-tjeneste i lommebokburet.
# 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
Dette er tilkoblingsadressen vår. La oss sjekke fra den lokale maskinen. Men først må vi legge til SSH-nøkkelen vår:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@local
Vel, fra en Linux-klientmaskin
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
La oss koble til (For at dette skal fungere, trenger du en lokal TOR-demon som lytter på 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
Suksess!
For å jobbe med øyeblikkelig- og mikrobetalinger trenger vi også en node c-lightning
nødvendig for å fungere bitcoind
men ja.
*Det er forskjellige implementeringer av Lightning Network-protokollen på forskjellige språk. Av de vi testet, virket c-lightning (skrevet i C) den mest stabile og ressurseffektive
# 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
Mens alt nødvendig er kompilert og installert, la oss lage en RPC-bruker for 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
Min kaotiske veksling mellom celler viser seg å ikke være så kaotisk hvis du legger merke til verktøyet tmux
, som lar deg opprette flere terminalunderøkter i én økt. Analog: screen
Så vi ønsker ikke å avsløre den virkelige IP-en til noden vår, og vi ønsker å utføre alle økonomiske transaksjoner gjennom TOP. Derfor er det ikke nødvendig med en annen .løk.
# 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
La oss nå lage en konfigurasjon for 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 ~
du må også lage en konfigurasjonsfil for bitcoin-cli, et verktøy som kommuniserer med bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test
kryss av
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]
lansering lightningd
lightning@lightning:~ % lightningd --daemon
Selv lightningd
du kan kontrollere verktøyet lightning-cli
, for eksempel:
lightning-cli newaddr
få adressen for en ny inngående betaling
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}
lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all
send alle pengene i lommeboken til adressen (alle adresser i kjeden)
Også kommandoer for off-chain operasjoner lightning-cli invoice
, lightning-cli listinvoices
, lightning-cli pay
og så videre.
Vel, for kommunikasjon med applikasjonen har vi en REST Api
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Oppsummere
# 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
Vi har et sett med containere, hver med sitt eget tilgangsnivå både fra og til det lokale nettverket.
# 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
Som du kan se, tar bitcoind opp hele 190 GB plass. Hva om vi trenger en annen node for tester? Det er her ZFS kommer godt med. Med hjelp cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com
du kan lage et øyeblikksbilde og legge ved en ny celle til dette øyeblikksbildet. Den nye cellen vil ha sin egen plass, men bare forskjellen mellom gjeldende tilstand og originalen vil bli tatt i betraktning i filsystemet (vi vil spare minst 190 GB)
Hver celle er sitt eget separate ZFS-datasett, og dette er ekstremt praktisk.
Det er også verdt å merke seg behovet for fjernovervåking av verten, for disse formålene vi har
B - sikkerhet
Når det gjelder sikkerhet, la oss ta utgangspunkt i nøkkelprinsippene i infrastruktursammenheng:
konfidensialitet - Standardverktøy for UNIX-lignende systemer sikrer implementeringen av dette prinsippet. Vi skiller logisk tilgang til hvert logisk separate element i systemet - en celle. Tilgang gis gjennom standard brukerautentisering ved bruk av brukernes personlige nøkler. All kommunikasjon mellom og til endecellene skjer i kryptert form. Takket være diskkryptering trenger vi ikke å bekymre oss for sikkerheten til data når vi bytter ut en disk eller migrerer til en annen server. Den eneste kritiske tilgangen er tilgang til vertssystemet, siden slik tilgang generelt gir tilgang til data inne i containere.
integritet «Implementeringen av dette prinsippet skjer på flere forskjellige nivåer. For det første er det viktig å merke seg at når det gjelder servermaskinvare, ECC-minne, tar ZFS allerede "ut av boksen" seg av dataintegriteten på nivået av informasjonsbiter. Øyeblikkelige øyeblikksbilder lar deg ta sikkerhetskopier når som helst på farten. Praktiske verktøy for celleeksport/import gjør cellereplikering enkel.
tilgjengelighet – Dette er allerede valgfritt. Avhenger av graden av berømmelse og det faktum at du har hatere. I vårt eksempel sørget vi for at lommeboken var tilgjengelig utelukkende fra TOP-nettverket. Om nødvendig kan du blokkere alt på brannmuren og gi tilgang til serveren utelukkende gjennom tunneler (TOR eller VPN er en annen sak). Dermed vil serveren i størst mulig grad være avskåret fra omverdenen, og bare vi selv vil kunne påvirke tilgjengeligheten.
Umulig å nekte – Og dette avhenger av videre drift og overholdelse av riktige retningslinjer for brukerrettigheter, tilgang osv. Men med riktig tilnærming blir alle brukerhandlinger revidert, og takket være kryptografiske løsninger er det mulig å entydig identifisere hvem som utførte bestemte handlinger og når.
Selvfølgelig er ikke den beskrevne konfigurasjonen et absolutt eksempel på hvordan den alltid skal være, den er snarere et eksempel på hvordan den kan være, samtidig som den beholder svært fleksible skalerings- og tilpasningsmuligheter.
Hva med full virtualisering?
Om full virtualisering ved hjelp av cbsd kan du bhyve
Du må aktivere noen kjernealternativer.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...
# cat /boot/loader.conf
...
vmm_load="YES"
...
Så hvis du plutselig trenger å starte en docker, installer litt debian og gå!
Det er alt
Jeg antar at det var alt jeg ønsket å dele. Hvis du likte artikkelen, kan du sende meg noen bitcoins -
Kilde: www.habr.com