Det har vist sig, at jeg professionelt er system- og netværksadministrator (kort sagt: sysadmin), og jeg har haft fornøjelsen af at arbejde med forskellige systemer i lidt over 10 år, herunder dem, der kræver [по|за]vishenede sikkerhedsforanstaltninger. Desuden fandt jeg for noget tid siden Bitcoin interessant , og jeg har ikke bare brugt det, men også startet flere mikro-tjenester for at lære at arbejde med Bitcoin-netværket (det er trods alt p2p) fra en udviklers perspektiv (jeg er selvfølgelig ikke den bedste dev, bare en forbipasserende). Men jeg vil ikke tale om udvikling, jeg vil tale om et sikkert og effektivt miljø for applikationer.
Finansielle teknologier (fintech) går hånd i hånd med informationssikkerhed (infosec), og det første kan fungere uden det andet, men ikke længe. Derfor vil jeg dele min erfaring og det værktøjssæt, jeg bruger, som inkluderer både fintech, og infosec, og gør det samtidig, og det kan også anvendes i bredere eller helt andre sammenhænge. I denne artikel vil jeg ikke så meget tale om Bitcoin, men om infrastrukturomodelle til udvikling og drift af finansielle (og ikke kun) tjenester – med et ord de tjenester, hvor 'B' betyder noget. Dette gælder både for Bitcoin-børser og for den typiske virksomheds 'zoo' af tjenester i en lille virksomhed, der ikke har noget med Bitcoin at gøre.
Jeg vil gerne påpege, at jeg støtter principperne for «keep it stupid simple» og «less is more», så både artiklen og det, jeg beskriver, vil have egenskaber, der er i overensstemmelse med disse principper.
Forestilling af et scenarie: Lad os tage et kig på det med et eksempel fra en bitcoin-børs. Vi har besluttet at lancere en børs for at bytte rubler, dollars og euro til bitcoin og vice versa, og vi har allerede en fungerende løsning. Men for andre digitale penge som Qiwi og Webmoney, altså, vi har håndteret alle juridiske spørgsmål, der er en klar applikation, der fungerer som betalingsgateway for rubler, dollars og euro samt andre betalingssystemer. Den er knyttet til vores bankkonti og har noget API til vores slutapplikationer. Vi har også en webapplikation, der fungerer som en børs for brugere, ligesom et typisk Qiwi eller Webmoney kabinet — opret en konto, tilføj et kort, osv. Den kommunikerer med vores gateway-applikation via REST API lokalt. Og så har vi besluttet at tilslutte bitcoin og samtidig opgradere infrastrukturen, da alt oprindeligt blev hastigt opsat på VirtualBox-maskiner under skrivebordet... siden har hjemmesiden fået brugere, og vi er blevet bekymrede for oppetid og ydeevne.
Så lad os starte med det grundlæggende — valget af server. Da virksomheden i vores eksempel er lille, og vi stoler på vores hostingudbyder (OVH), vælger vi hvor det ikke er muligt at installere systemet fra det originale .iso image, men det er ikke noget problem. IT-sikkerhedsafdelingen vil bestemt udføre en analyse af det installered image. Og når vi vokser, lejer vi endda vores eget skab med lås og begrænset fysisk adgang, eller måske bygger vi vores eget datacenter. Under alle omstændigheder skal man huske, at når man lejer hardware og installerer færdige images, er der en risiko for, at der hænger en 'trojaner fra hosteren' i systemet, som i de fleste tilfælde ikke er beregnet på at overvåge dig, men for at tilbyde mere brugervenlige serveradministrationsværktøjer.
Serverinstallation
Her er det meget enkelt. Vi vælger hardware, der passer til vores behov. Derefter vælger vi FreeBSD image. Eller vi forbinder (hvis det er en anden host og vores egen hardware) via IPMI eller med en monitor og indlæser .iso FreeBSD image. Til orkestrering installation bruger jeg og . Det eneste er, at i vores tilfælde med kimsufi, valgte vi tilpasset installation for at sikre, at de to diske i RAID 1 kun har "åbne" boot- og /home-partitioner, den resterende diskplads vil være krypteret, men dette kommer vi tilbage til senere.
System installation occurs in the standard way; I won't dwell on that, but I will note that before starting operation, you should pay attention to hardening the options offered by bsdinstaller at the end of the installation (if you are installing the system yourself):
Der er on this topic, I will briefly repeat it here.
You can enable the aforementioned parameters also on an already installed system. To do this, you need to edit the bootloader file and enable the kernel parameters. *ee is an editor in 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=1You should also ensure that you have the latest version of the system and . In our case, for example, an upgrade to the latest version is required, as the pre-installed images lag behind by six months to a year. Additionally, we change the SSH port to one different from the default, add key authentication, and disable password authentication.
Then we set up aide, monitoring the status of system configuration files. You can read more detailed information in .
pkg install aide
and edit our 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/$MYFILENAMEAktiverer
sysrc auditd_enable=YES
# service auditd start
How to administer this is excellently described in .
Now we reboot and proceed to the software on the server. Each server acts as a hypervisor for containers or full virtual machines. Therefore, it is important that the processor supports VT-x and EPT if we plan to use full virtualization.
For managing containers and virtual machines, I use fra , wishing it good health and blessings for this great utility!
Containers? Is it again docker?
But no. — is a great tool for containerization, and the mentioned cbsd is for orchestrating these containers, which are called cells.
En celle er en yderst effektiv løsning til at opbygge infrastruktur til forskellige formål, hvor der kræves fuldstændig isolation af individuelle tjenester eller processer. I princippet er det en klon af værtssystemet, men det kræver ikke fuld virtualisering af 'hardwaren'. Og ressourcer bruges derfor ikke på 'gæste-OS', men kun på det udførte arbejde. Når celler bruges til interne behov, er det en meget bekvem løsning til optimal ressourceudnyttelse — mange celler på én fysisk server kan hver især bruge serverens fulde ressourcer efter behov. Da forskellige underservices normalt har brug for ekstra ressourcer på forskellige tidspunkter, kan man maksimere serverens ydeevne, hvis man planlægger og balancerer cellerne korrekt mellem serverne. Hvis nødvendigt, kan der også sættes begrænsninger på de ressourcer, der anvendes af cellerne.
Hvad med fuld virtualisering?
Så vidt jeg ved, cbsd understøtter driften bhyve og XEN hypervisorer. Den sidstnævnte har jeg aldrig brugt, men den første er en relativt ny . Vi vil se på et eksempel på brugen af bhyve i det følgende eksempel.
Installation og konfiguration af værtmiljøet
Vi bruger FS . Det er et ekstremt kraftfuldt værktøj til administration af plads på serveren. Med ZFS kan man direkte fra diske opbygge arrays af forskellige konfigurationer, dynamisk "on-the-fly" udvide pladsen, udskifte døde diske, administrere snapshots og meget, meget mere, som kunne beskrives i en hel serie artikler. Lad os vende tilbage til vores server og dens diske. I starten af installationen efterlod vi ledig plads på diskene til krypterede partitioner. Hvorfor? Det er for at sikre, at systemet automatisk starter op og lytter via SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
tilføjer en diskpartition til det reserverede plads
geli init /dev/ada0p4
indtaster vores krypteringskode
geli attach /dev/ada0p4
indtager igen koden, og vi får en enhed /dev/ada0p4.eli — det er vores krypterede rum. Derefter gentager vi det samme for /dev/ada1 og de øvrige diske i arrayet. Og vi opretter et nyt .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — så er vi klar med vores minimale kampklar opsætning. Et spejlet arrays af diske i tilfælde af, at en af de tre går i stykker.
Opretter et datasæt på den nye "pulje"
zfs create vms/jails
pkg install cbsd — vi har kørt kommandoen, og vi installerer management til vores containment.
Efter at cbsd det er installeret, skal det initialiseres:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
og så svarer vi på en masse spørgsmål, for det meste med standard svar.
*Hvis du bruger kryptering, er det vigtigt, at daemonen cbsdd ikke starter automatisk, før du manuelt eller automatisk dekrypterer diskene (i vores eksempel gør zabbix dette)
**Jeg bruger heller ikke NAT fra cbsd, men 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 netværksport videresendelse
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
Konfiguration af firewall-politikker er også et separat emne, så jeg vil ikke dykke ned i konfigurationen af BLOCK ALL-politikken og konfigurationen af whitelist, det kan gøres ved at læse eller en hvilken som helst af de mange artikler tilgængelige på Google.
Nå… vi har installeret cbsd, det er tid til at oprette vores første arbejdshest — Bitcoin daemon i containment!
cbsd jconstruct-tui
Her ser vi dialogen til oprettelse af containment. Når vi har indtastet alle værdier, opretter vi!
Ved oprettelsen af den første containment skal du vælge, hvad der skal bruges som basis for containment. Jeg vælger distributionen fra FreeBSD-repositoriet med kommandoen repo. Dette valg træffes kun ved oprettelse af den første containment af en bestemt version (du kan hoste containment af enhver version, så længe den er nyere end værtsversionen).
Når alt er installeret — kører vi containment!
# cbsd jstart bitcoind
Men vi skal installere softwaren i containment.
# jls
JID IP Adresse Værtsnavn Sti
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind for at komme ind i containment-konsollen
og indeni containment installerer vi softwaren med dens afhængigheder (vores værtsystem forbliver rent)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoin er i containment, men vi har brug for anonymitet, fordi vi ønsker at forbinde til nogle containment over TOR-netværket. Og generelt planlægger vi at køre de fleste containment med mistænkelig software kun gennem proxy. pf Det er muligt at deaktivere NAT for et bestemt interval af IP-adresser i det lokale netværk og kun tillade NAT for vores TOR-node. På den måde vil selv hvis en skadelig aktør trænger ind, være det usandsynligt, at de vil kunne kommunikere med omverdenen, og hvis de gør, vil de ikke afsløre IP-adressen på vores server. Derfor opretter vi endnu en celle til "tunneling" af tjenester som en "onion"-service og som en proxy til internetadgang for separate 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
Lad os lytte på den lokale adresse (tilgængelig for alle celler)
SOCKSPort 192.168.0.2:9050
Hvad mangler vi ellers for fuldkommen lykke? Jo, vi har brug for en tjeneste til vores web, måske endda flere. Lad os starte nginx, som vil fungere som reverse-proxy og sørge for fornyelse af Let’s Encrypt certifikaterne.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev: /@[15:47] # pkg install nginx py36-certbot
Og nu har vi 150 MB afhængigheder indlæst i cellen. Værten er stadig ren.
Vi vender tilbage til konfigurationen af nginx senere, vi skal oprette yderligere to celler til vores betalingsgateway på nodejs og rust samt en webapplikation, som af en eller anden grund bruger apache og php, og desuden kræver den 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 yderligere 380 MB pakker er isoleret
Derefter downloader vi vores anvendelse 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 cellen.
Her giver vi udvikleren adgang via SSH direkte til cellen, de klarer det hele selv:
webapp: /@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — ændrer cellens SSH-port til hvilken som helst vilkårlig port
webapp: /@[16:02] # sysrc sshd_enable=YES
webapp: /@[16:02] # service sshd start
Sådan, tjenesten er startet, det er kun nødvendigt at tilføje en regel til pf firewall
Lad os se, hvilke IP-adresser vores celler har, og hvordan vores "lokalnet" overhovedet ser ud
# jls
JID IP Adresse Værtsnavn Sti
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/webappog lad os tilføje 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
Og da vi er her, lad os også tilføje en regel til 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
Nu lidt om bitcoins
Hvad har vi - vi har en webapplikation, som er tilgængelig udefra, og den kommunikerer lokalt med vores betalingsgateway. Nu skal vi forberede et arbejdsmiljø til interaktion med selve bitcoin-netværket - noden bitcoind det er bare et demon, der understøtter en lokal kopi af blockchainen. Denne demon har RPC og funktionaliteten til en tegnebog, men til udvikling af applikationer er der mere praktiske "wraps". Først besluttede vi at installere electrum — det er en CLI-tegnebog. vil vi bruge som "kold opbevaring" for vores bitcoins — generelt de bitcoins, som skal opbevares "udenfor" det system, der er tilgængeligt for brugerne og på afstand fra alle. Den har også en GUI, så vi planlægger at bruge en lignende tegnebog på
vores laptops. I starten vil vi bruge electrum med offentlige servere, og senere vil vi opsætte , så vi slet ikke er afhængige af nogen.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum: /@[8:45] # pkg install py36-electrum
yderligere 700 MB software har vi i cellen
electrum: /@[8:53] # adduser
Brugernavn: wallet
Fulde navn:
Uid (lad være tom for standard):
Login gruppe [wallet]:
Login gruppe er wallet. Skal wallet inviteres til andre grupper? []:
Login klasse [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Hjemme bibliotek [/home/wallet]:
Hjemme biblioteks rettigheder (lad være tom for standard):
Brug password-baseret autentificering? [ja]: nej
Lås kontoen efter oprettelse? [nej]:
Brugernavn : wallet
Password :
Fulde navn :
Uid : 1001
Klasse :
Grupper : wallet
Hjem : /home/wallet
Hjem mode :
Shell : /bin/tcsh
Låst : nej
OK? (ja/nej): ja
adduser: INFO: Succesfuldt tilføjet (wallet) til bruger databasen.
Tilføj en anden bruger? (ja/nej): nej
Farvel!
electrum: /@[8:53] # su walletelectrum: /@[8:53] # su wallet
wallet@electrum: / % electrum-3.6 create
{
"msg": "Venligst opbevar din seed på et sikkert sted; hvis du mister den, vil du ikke kunne gendanne din tegnebog.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}Nu har vi oprettet en tegnebog.
wallet@electrum: / % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum: / % electrum-3.6 help
Til vores on-chain tegnebog vil kun et begrænset antal personer fremover kunne tilslutte. For ikke at åbne adgangen udadtil i denne celle, vil forbindelser via SSH ske gennem TOR (denne decentrale variant af VPN). Vi opsætter SSH i cellen, men rører ikke vores pf.conf på værten.
electrum: /@[9:00] # sysrc sshd_enable=YES
electrum: /@[9:00] # service sshd start
Nu deaktiverer vi cellen med tegnebogen fra internetadgang. Vi giver den en IP-adresse fra et andet subnet, som ikke NAT'er. Først ændrer vi /etc/pf.conf på værten
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" ændrer til JAIL_IP_POOL="192.168.0.0/25", dermed vil alle adresser 192.168.0.126-255 ikke have direkte adgang til internettet. En slags software 'air-gap' netværk. Og NAT-reglen forbliver som før
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Genstarter reglerne
# pfctl -f /etc/pf.conf
Nu tager vi fat på vores celle
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Fjern gammel IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Opsæt ny IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, men nu stopper selve systemet også med at fungere. Men vi kan angive en systemproxy. Men der er et men, på TOR er denne SOCKS5-proxy, og for nemhedens skyld ville vi også have 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 = socks5polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Nå, nu har vores system to proxy-servere, og begge går gennem TOR: socks5://192.168.0.2:9050 og
Nu kan vi konfigurere miljøet for vores tegnebog
# 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:8123nå, nu vil shell fungere gennem proxy. Hvis vi ønsker at installere pakker, bør vi tilføje i /usr/local/etc/pkg.conf fra root af cellen
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Nu er det tid til at tilføje TOR hidden service som adressen til vores SSH-service i celleaftegnerens
# 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.onionHer er vores adresse til forbindelse. Lad os tjekke fra den lokale maskine. Men først skal vi tilføje vores SSH-nøgle:
wallet@electrum:/ % mkdir ~/ .ssh
wallet@electrum:/ % ee ~/ .ssh /authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localOg fra den klientmaskine der kører 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
Tilslutning (For at dette skal fungere, skal en lokal TOR-daemon lytte på 9050)
user@local ~$ ssh remotebtc
Ægthed af vært 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<ingen hostip til proxy-kommando>)' kan ikke bekræftes.
ECDSA-nøglefingeraftryk er SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Er du sikker på, at du vil fortsætte med at forbinde (ja/nej/[fingeraftryk])? ja
Advarsel: Permanent tilføjet 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) til listen over kendte værter.
FreeBSD 12.1-RELEASE-p1 GENERIC
For at spare diskplads i dit hjemmemappe, komprimer filer, du sjældent bruger med "gzip filnavn".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Succes!
For at arbejde med øjeblikkelige og mikrobetalinger har vi også brug for en node , dette vil være vores primære arbejdsredskab med Bitcoin. I *, som vi vil bruge som demon, har , som er et fuldt funktionelt HTTP (REST) interface og gør det muligt at arbejde med både off-chain transaktioner og on-chain transaktioner. c-lightning til at fungere kræver bitcoind en node.
*der findes forskellige implementeringer af Lightning Network-protokollen i forskellige programmeringssprog. Af dem vi har testet, virker c-lightning (skrevet i C) som den mest stabile og ressourceeffektive.
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/@[10:23] # adduser
Brugernavn: 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 vi kompilere og installerer alt nødvendigt, opretter vi en RPC-bruger til lightningd i bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
# tillad kun c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Mit kaotiske skift mellem terminalvinduer viser sig ikke at være så chaotisk, hvis man bemærker værktøjet tmux, som gør det muligt at skabe mange under-sessioner inden for én session. Tilsvarende: screen
Okay, vi ønsker ikke at afsløre den virkelige IP for vores node, og vi vil udføre alle finansielle transaktioner gennem TOR. Derfor har vi brug for endnu en .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.onionnu opretter vi konfigurationen 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 det ovenstående eksempel bør initialiseringsloggene (blandet med lightningd-loggene) vise noget somlightning@lightning:~ % mkdir .lightning/plugins
lightning@lightning:~ % cd .lightning/plugins/
lightning@lightning:~/.lightning/plugins:% hent 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 ~
det skal også oprettes en konfigurationsfil for bitcoin-cli, et værktøj der kommunikerer med bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testtjekker
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]starter lightningd
lightning@lightning:~ % lightningd --daemon
Den lightningd man kan styre værktøjet lightning-cli, for eksempel:
lightning-cli newaddr få en adresse for en ny indkommende betaling
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all sende alle penge fra wallet (alle on-chain adresser) til adressen
Der er også kommandoer til off-chain operationer lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay osv.
Og til kommunikation med applikationen har vi et REST API
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Lad os opsummere
# jls
JID IP Adresse Værtsnavn Sti
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 sæt containere, hver med sit eget adgangsniveau til både lokale og eksterne netværk.
# zfs list
NAVN BRUGT TILGÆNGELIG REFERERET MONTERINGSSTED
zroot 279G 1.48T 88K /zroot
zroot/ROOT 1.89G 1.48T 88K ingen
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-dataSom man kan se, optager bitcoind hele 190 GB plads. Hvad hvis vi har brug for en node til test? Her passer ZFS perfekt. Ved hjælp af cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Du kan oprette et snapshot og binde en ny celle til dette snapshot. Den nye celle vil have sit helt eget rum, men i filsystemet vil der kun blive taget højde for forskellen mellem den nuværende tilstand og originalen (vi sparer mindst 190 GB).
Hver celle er et separat ZFS-datasæt, og det er ekstremt praktisk. at lave andre gode ting, som at sende snapshots via SSH. Vi vil ikke beskrive dette, da der allerede er meget.
Det er også vigtigt at bemærke behovet for fjernmonitorering af værten; vi har til disse formål .
B – sikkerhed
Når det kommer til sikkerhed, lad os tage udgangspunkt i grundlæggende principper i konteksten af infrastrukturen:
Fortrolighed — Standardværktøjer i UNIX-lignende systemer sikrer opfyldelsen af dette princip. Vi opretter en logisk opdeling af adgangen til hvert logisk adskilt element i systemet – cellen. Adgang gives via standard brugergodkendelse ved hjælp af brugerens private nøgler. Al kommunikation mellem og til de endelige celler foregår i krypteret form. Takket være disk kryptering kan vi være sikre på databeskyttelsen under udskiftning af harddiske eller migration til en anden server. Den eneste kritiske adgang er adgangen til værtsystemet, da denne adgang i almindelighed giver adgang til data inden i containerne.
Integritet — Opfyldelsen af dette princip sker på flere forskellige niveauer. For det første er det vigtigt at nævne, at i tilfælde af serverhardware, ECC-hukommelse, sørger ZFS allerede "ud af boksen" for dataintegritet på bitniveau. Øjeblikkelige snapshots gør det muligt at tage sikkerhedskopier når som helst on-the-fly. Praktiske eksport-import værktøjer til celler gør det nemt at replikere celler.
Tilgængelighed — Dette er allerede valgfrit. Det afhænger af din grad af kendthed og om du har nogen fjender. I vores eksempel sikrede vi adgang til tegnebogen udelukkende fra TOR-netværket. Om nødvendigt kan man på firewallen blokere alt og kun tillade adgang til serveren gennem tunneller (TOR eller VPN er et andet spørgsmål). På denne måde vil serveren være skåret af fra omverdenen så meget som muligt, og vi vil kun kunne påvirke dens tilgængelighed.
Mulighed for tilbageholdelse — Dette afhænger af den fortsatte anvendelse og overholdelse af de rette politikker for brugers rettigheder, adgang osv. Men med den rette tilgang bliver alle brugeres handlinger revideret, og takket være kryptografiske løsninger er det muligt klart at identificere, hvem og hvornår der har udført de enkelte handlinger.
Den beskrevne konfiguration er selvfølgelig ikke et absolut eksempel på, hvordan det altid skal være, det er mere et af eksemplerne på, hvordan det kan være, mens man bevarer meget fleksible muligheder for skalering og tilpasning.
Og hvad med fuld virtualisering?
Om fuld virtualisering med cbsd kan man . Jeg vil blot tilføje, at for at arbejde bhyve er det nødvendigt at aktivere nogle kerneparametre.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Så hvis der pludselig er behov for at oprette en docker, så opretter vi en eller anden debian og så videre!
Det var det hele
Det er nok alt, hvad jeg ville dele. Hvis du kunne tænke dig at donere bitcoins, så kan du sende dem til mig — . Hvis du vil prøve cellerne i aktion og har lidt bitcoins, så kan du besøge mit .
Kilde: habr.com
