Ka qenë e tillë, që unë profesionalisht jam administrator i sistemeve komputerike dhe rrjeteve (shkurt: sysadmin), dhe kam përjetuar pak më shumë se 10 vjet aktivitet profesional me sisteme të ndryshme, përfshirë ato që kërkojnë masa të [pëlqyera|përmirësuara] sigurie. Për më tepër, ndodhi që disa kohë më parë, e gjeta të interesant , dhe jo vetëm që e kam përdorur, por kam nisur disa mikro-shërbime, për të mësuar të punoj vetë me rrjetin e bitcoin-it (sigurisht, unë jam disi i tillë dev, kështu, kalova ashtu). Por nuk jam për zhvillimin, jam për një ambient të sigurt dhe efektiv për aplikacionet.
Teknologjitë financiare (fintech) ecin përkrah sigurisë informative (infosec) dhe e para pa të dytën mund të funksionojë, por jo për një kohë të gjatë. Kështu që, dëshiroj të ndaj përvojën time dhe grupin e mjeteve që përdor, i cili përfshin si fintech, ashtu edhe infosec, madje në të njëjtën kohë, si dhe mund të përdoret në një qëllim më të gjerë apo krejtësisht tjetër. Në këtë artikull do të flas më shumë për modelin e infrastrukturës për zhvillimin dhe operimin e shërbimeve financiare (dhe jo vetëm) - me një fjalë ato shërbime, ku "B" ka rëndësi. Ky informacion është e aplicueshme si në një bursë bitcoin-i, ashtu edhe në kopshtin tipik korporativ të shërbimeve të një kompanie të vogël, që nuk kanë asnjë lidhje me bitcoin-in.
Dëshiroj të theksoj se unë jam përkrahës i parimeve "mbaje të thjeshtë" dhe "më pak është më shumë", kështu që si artikulli, ashtu edhe ajo që përshkruan do të ketë cilësitë për të cilat këto parime flasin.
Skenari imagjinar: Le të shqyrtojmë gjithçka përmes një shembulli të një këmbimi bitcoin. Vendosëm të fillojmë këtë këmbim të rubleve, dollarëve, dhe eurove në bitcoin dhe anasjelltas, dhe tani kemi një zgjidhje funksionale, por për monedhat e tjera dixhitale si qiwi dhe webmoney, dmth. kemi zgjidhur të gjitha çështjet juridike, kemi një aplikacion të gatshëm që vepron si një portal pagesash për rubla, dollarë dhe euro, si edhe për sistemet e tjera të pagesës. Të lidhura me llogaritë tona bankare dhe duke pasur një API për aplikacionet tona të fundit. Kemi gjithashtu një aplikacion web që vepron si këmbim për përdoruesit, disi si një zyrë tipike qiwi ose webmoney — krijoni një llogari, shtoni një kartë dhe kështu me radhë. Ai komunikon me aplikacionin tonë portal, le të themi përmes REST API në rrjetin lokal. Dhe tani vendosëm të lidhim bitcoin dhe njëkohësisht të përmirësojmë infrastrukturën, pasi në fillim të gjithë ishim të nxitur të ngrihen në virtualboks në zyre nën tavolinë… situs përdorues, dhe ne filluam të shqetësohemi për uptime dhe performancën.
Pra, le të fillojmë me thelbin — zgjedhjen e serverit. Duke marrë parasysh që biznesi në shembullin tonë është i vogël dhe ne e besojmë hostin (OVH), do të zgjedhim ku nuk mund të instaloni sistemin nga një imazh origjinal .iso, por nuk është problem, ekipi ynë i IT-së patjetër do të kryejë një analizë të imazhit të instaluar. Kur të rritemi, ndoshta do të marrim me qira kabinetin tonë të mbyllur me akses fizik të kufizuar, ose ndoshta do të ndërtojmë qendrën tonë të të dhënave. Në çdo rast, duhet të mbani mend se kur merrni me qira pajisje dhe instaloni imazhe të gatshme, ka të ngjarë që sistemi juaj të ketë një "trojan" nga hosti, i cili në shumicën e rasteve nuk është për të ju spiunuar, por për t'ju ofruar mjete më të rehatshme për menaxhimin e serverit.
Instalimi i serverit
Këtu është e thjeshtë. Zgjidhni pajisjen që i përshtatet nevojave tona. Më pas, zgjedhim imazhin FreeBSD. Ose lidhemi (në rast të një hosti tjetër dhe pajisjes sonë) përmes IPMI ose me monitorin dhe shkembejmë imazhin .iso të FreeBSD në ngarkesë. Për instalimin orkestral, unë përdor dhe . E vetmja gjë është se në rastin tonë me kimsufi, ne zgjodhëm instalimin personalizues për të pasur dy disqe në pasqyrë që njihen "të hapura" vetëm për partitë e ngarkesës dhe /home, hapësira tjetër e diskut do të jetë e enkriptuar, por për këtë do të flasim më vonë.
Instalimi i sistemit ndodh në mënyrë standarde, nuk do të ndalem në këtë, vetëm do të theksoj se përpara fillimit të përdorimit duhet të kushtoni vëmendje ndaj forcimit opsioneve që ofron bsdinstaller në fund të instalimit (nëse e instaloni sistemin vetë):
Ka për këtë temë, shkurtimisht do ta përsëris këtu.
Aktivizimi i parametrave të lartpërmendur është gjithashtu i mundur në një sistem tashmë të instaluar. Për këtë duhet të redaktoni skedarin e ngarkuesit dhe të aktivizoni parametrat e kernelit. *ee — është një editor i tillë në 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=1Gjithashtu është e rëndësishme të siguroheni që keni instaluar versionin më të fundit të sistemit, dhe . Në rastin tonë, për shembull, kërkohet përmirësimi në versionin më të fundit, pasi imazhet paraprakisht të instaluara janë me vonesë nga gjashtë muaj në një vit. Dhe aty ndryshojmë portin SSH në një që është ndryshe nga ai i parazgjedhur, shtojmë autentifikimin me çelësa dhe e çaktivizojmë me fjalëkalim.
Më pas konfiguroni aide, monitorimin e gjendjes së skedave të konfigurimit të sistemit. Më shumë mund të lexoni .
pkg install aide
dhe redaktoni tabelën tuaj të 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/$MYFILENAMEAktivizoni
sysrc auditd_enable=YES
# service auditd start
Si ta administrojmë këtë është përshkruar shkëlqyer në .
Tani rinisni dhe filloni me softuerin në server. Çdo server përfaqëson një hipervizor për kontejnerë ose makina virtuale të plota. Prandaj, është e rëndësishme që procesori të mbështesë VT-x dhe EPT nëse planifikojmë të përdorim virtualizim të plotë.
Si menaxhim për kontejnerët dhe makinat virtuale unë përdor nga , dëshiroj shëndet dhe bekim më të madh për këtë utilitar të mrekullueshëm!
Kontejnerët? Po, sërish docker?
Jo, aspak. – është një mjet i shkëlqyer për kontejnerizimin, dhe përmenduri cbsd për orkestrimin e këtyre kontejnerëve, emri i tij është - qeliza.
Kletka është një zgjidhje jashtëzakonisht efektive për ndërtimin e infrastrukturës për qëllime të ndryshme, ku në fund kërkohet izolimi i plotë i shërbimeve ose proceseve të veçanta. Në thelb, kjo është një klon i sistemit host, por nuk kërkon virtualizim të plotë të "harduerit". Dhe burimet, falë kësaj, nuk shpenzohen për "OS-në mikpritëse", por vetëm për punën që po kryhet. Kur kletkat përdoren për nevoja të brendshme, kjo është një zgjidhje shumë e përshtatshme për përdorimin optimal të burimeve - një mori kletkash në një server fizik mund të përdorin secila veçmas të gjithë burimin e serverit kur është e nevojshme. Duke marrë parasysh se zakonisht nën-shërbimeve të ndryshme u nevojiten burime shtesë në kohë të ndryshme, mund të nxjerrim maksimale nga një server, nëse planifikojmë dhe shpërndajmë saktë kletkat midis serverëve. Në rast nevoje, kletkat mund të kenë gjithashtu limite të vendosura për burimin e përdorur.
E çfarë është me virtualizimin e plotë?
Sa di unë, cbsd përkrah punën bhyve dhe hipervizorët XEN. Të dytin nuk e kam përdorur kurrë, por i pari është një hipervizor relativisht i ri Ne do të shqyrtojmë një shembull të përdorimit bhyve në shembullin më poshtë.
Instalimi dhe konfigurimi i ambientit të hostit
Ne përdorim FS-in Ky është një instrument jashtëzakonisht i fuqishëm për menaxhimin e hapësirës në server. Falë ZFS, mund të ndërtohen drejtpërdrejt nga diskët RAID të ndryshme konfiguracionesh, të zgjerohen dinamikisht "në nxehtë", të zëvendësohen diskët e vdekur, të menaxhohen snapshot-et dhe shumë, shumë më tepër që mund të përshkruhen në një seri article. Të kthehemi te serveri ynë dhe diskët e tij. Në fillim të instalimit, ne lanë hapësirë të lirë për ndarjet e enkriptuara. Pse kështu? Kjo është për të bërë që sistemi të ngrihet automatikisht dhe të dëgjojë përmes SSH.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
shtojmë një ndarje disku në hapësirën e mbetur
geli init /dev/ada0p4
shkruajmë fjalëkalimin tonë të enkriptimit
geli attach /dev/ada0p4
përsëri shkruajmë fjalëkalimin dhe na shfaqet pajisja /dev/ada0p4.eli - kjo është hapësira jonë e enkriptuar. Pastaj e përsërisim të njëjtën gjë për /dev/ada1 dhe diskët e tjerë në RAID. Dhe krijojmë një .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli - mirë, kemi paketën minimale të gatshme për luftë. Një RAID i pasqyruar i diskëve për rastin e daljes jashtë funksioni të njërit nga tre.
Krijojmë një dataset në 'pulin' e ri
zfs create vms/jails
pkg install cbsd - nisëm komandën, dhe po instalojmë menaxhimin për qelizat tona.
Pasi që cbsd është instaluar, është e nevojshme ta inicializojmë:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
dhe përgjigjemi në një mori pyetjesh, kryesisht me përgjigje siç është në parazgjedhje.
* Nëse po përdorni enkriptim, është e rëndësishme që demon cbsdd të mos startojë automatikisht, derisa të dekriptoj diskët dorazi ose automatikisht (në shembullin tonë, kjo bëhet nga zabbix)
** Po ashtu nuk përdor NAT nga cbsd, por e konfigurimin vetë në 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 për qelitë
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Porti i rrjetit Bitcoin për të kaluar
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
Konfigurimi i politikave të firewall-it është gjithashtu një temë e veçantë, prandaj nuk do të thellohem në konfigurimin e politikës BLOCK ALL dhe konfigurimet e listave të bardha, mund ta bëni duke lexuar apo ndonjë nga një numër të madh artikujsh të disponueshëm në google.
Epo, kemi instaluar cbsd, është koha për të krijuar kalë tonë të parë të punës - demonin e Bitcoin në qeli!
cbsd jconstruct-tui
Këtu shohim dialogun e krijimit të qelisë. Pasi të kemi vendosur të gjitha vlerat, krijojmë!
Kur krijoni qelinë e parë, duhet të zgjidhni çfarë të përdorni si bazë për qelitë. Unë zgjedh distribucionin nga repozitorin FreeBSD me komandën repo. Ky zgjedhje bëhet vetëm gjatë krijimit të qelisë së parë për versionin specifik (mund të akomodoni qelitë e çdo versioni që është më i vjetër se versioni i hostit).
Pasi që gjithçka është instaluar - nisni qelinë!
# cbsd jstart bitcoind
Por na nevojitet të instalojmë softverin në qeli.
# jls
JID IP Address Hostname Path
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind për të hyrë në konsolën e qelisë
dhe brenda qelisë instalojmë softverin me varësitë e tij (sistemi ynë host mbetet i pastër)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
Bitcoin në qeli është, por na nevojitet anonimati, sepse duam të lidhemi me disa qeli përmes rrjetit TOR. Dhe në përgjithësi, kemi në plan që shumicën e qelive me softver të dyshimtë t'i menaxhojmë vetëm përmes proxy. pf mund të çaktivizojë NAT për një gamë të caktuar adresash IP në rrjetin lokal dhe të lejojë NAT vetëm për nodin tonë TOR. Kështu që edhe nëse ndonjë malware hyn në kafaz, ka shumë të ngjarë të mos mund të komunikojë me botën e jashtme, dhe nëse e bën, nuk do të zbulojë IP-në e serverit tonë. Prandaj krijojmë një kafaz tjetër për "kalimin" e shërbimeve si shërbimi ".onion" dhe si një proxy për dalje në internet për kafazet e ndara.
# 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
Vendosim të dëgjojmë në adresën lokale (për të gjitha kafazet e aksesueshme)
SOCKSPort 192.168.0.2:9050
Çfarë na mungon tjetër për lumturinë e plotë. Po, na nevojitet një shërbim për webin tonë, ndoshta jo vetëm një. Do të nisim nginx, i cili do të ushtrojë rolin e reverse-proxy dhe do të kujdeset për rinovimin e certifikatave Let’s Encrypt.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev: /@[15:47] # pkg install nginx py36-certbot
Dhe kështu 150 MB varësish e vendosëm në kafaz. Ndërsa hosti mbetet i pastër.
Do të kthehemi në konfigurimin e nginx më vonë, na nevojitet të ngremë dy kafaze tjera për portofolin tonë të pagesave në nodejs dhe rust dhe për aplikacionin web, i cili për ndonjë arsye është në apache dhe php, si dhe për të fundit na nevojitet një DB 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
… dhe 380 MB paketesh të izoluara
Më pas shkarkojmë aplikacionin tonë me git dhe e nisim.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp: /@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB paketesh. në kafaz.
Këtu jepim akses për zhvilluesin përmes SSH direkt në kafaz, ata do ta bëjnë vetë gjithçka:
webapp: /@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — ndryshojmë portin e SSH të kafazit në një port të rastësishëm
webapp: /@[16:02] # sysrc sshd_enable=YES
webapp: /@[16:02] # service sshd start
Ja pra, shërbimi është nisur, vetëm duhet të shtojmë një rregull në pf firewall
Le të shohim cilat janë IP-të e kafazeve dhe si duket "lokalja" jonë
# 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/webappdhe do të shtojmë një rregull
# 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
njësoj dhe duke qenë se jemi këtu, do të shtojmë gjithashtu një rregull për 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
Tani, pak rreth bitcoinëve
Çfarë kemi — kemi një aplikacion web, që është i aksesueshëm nga jashtë, dhe ai komunikon lokalisht me portofolin tonë të pagesave. Tani na nevojitet të përgatisim një mjedis pune për t'u ndërlidhur me rrjetin e bitcoin-it vetë — nodin bitcoind Ky është thjesht një demon që mbështet një kopje lokale të blockchain-it aktual. Ky demon ka RPC dhe funksionalitet të portofolit, megjithatë për zhvillimin e aplikacioneve ka "mbështetje" më të përshtatshme. Në fillim, ne vendosëm ta instalojmë electrum — është një portofol CLI. do të përdoret si "ruajtje e ftohtë" për bitcoinët tanë — në përgjithësi ato bitcoinë që duhet të ruhen "jashtë" sistemit që është i aksesueshëm për përdoruesit dhe gjithashtu sa më larg të jetë e mundur nga të tjerët. Ai gjithashtu ka GUI, prandaj të njëjtin portofol do ta përdorim edhe në
laptopët tanë. Aktualisht do ta përdorim electrum me serverë publikë, dhe më vonë do të ngrisim një tjetër qelizë , në mënyrë që të mos varemi nga askush.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum: /@[8:45] # pkg install py36-electrum
edhe 700 MB softueri është në qelizën tonë
electrum: /@[8:53] # adduser
Emri i përdoruesit: wallet
Emri i plotë:
Uid (Lëni bosh për default):
Grupi i hyrjes [wallet]:
Grupi i hyrjes është wallet. A dëshiron të ftesh wallet në grupe të tjera? []:
Klasa e hyrjes [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Katalogu i shtëpisë [ /home /wallet]:
Lejet e katalogut të shtëpisë (Lëni bosh për default):
A do të përdorë autentifikimin me fjalëkalim? [po]: jo
A do ta bllokosh llogarinë pas krijimit? [jo]:
Emri i përdoruesit: wallet
Fjalëkalimi:
Emri i plotë:
Uid: 1001
Klasa:
Grupet: wallet
Shtëpia: /home/wallet
Mënyra e Shtëpisë:
Shell: /bin/tcsh
E bllokuar: jo
OK? (po / jo): po
adduser: INFO: Suksesshëm e shtoi (wallet) në bazën e të dhënave të përdoruesve.
A dëshiron të shtosh një përdorues tjetër? (po / jo): jo
Mirupafshim!
electrum: /@[8:53] # su walletelectrum: /@[8:53] # su wallet
wallet@electrum: / % electrum-3.6 create
{
"msg": "Të lutem mbajeni farën tuaj në një vend të sigurt; nëse e humbni, nuk do të mund të rindërtoni portofolin tuaj.",
"path": " /usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "xhelozë fitne material shirit njëndërr vizual mirë cactus rastësor zog"
}Tani kemi krijuar portofolin.
wallet@electrum: / % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum: / % electrum-3.6 help
Për portofolin tonë on-chain do të mund të lidhen vetëm një grup i kufizuar njerëzish. Për të mos e hapur qasjen nga jashtë në këtë qelizë, lidhjet përmes SSH do të ndodhin përmes TOR (një variant decentralizuar i VPN). Ne e nisëm SSH-në në qelizë, por nuk e prekim pf.conf-in tonë në host.
electrum: /@[9:00] # sysrc sshd_enable=YES
electrum: /@[9:00] # service sshd start
Tani do ta çaktivizojmë qelizën me portofolin nga interneti. Do t'i vendosim një adresë IP nga një hapësirë tjetër të nënrrjetit, e cila nuk NAT-izohet. Fillimisht do të ndryshojmë /etc/pf.conf në host
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" do ta ndryshojmë në JAIL_IP_POOL="192.168.0.0/25", kështu që të gjitha adresat 192.168.0.126-255 nuk do të kenë qasje direkte në internet. Një lloj rrjeti software «air-gap». Dhe rregulli NAT mbetet siç ishte.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Riinizojmë rregullat
# pfctl -f /etc/pf.conf
Tani merremi me kafazit tonë
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Heqim IP-në e vjetër: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Cakto IP-në e re: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hmm, por tani sistemi ynë do të ndalojë gjithashtu së funksionuari. Megjithatë, mund të tregojmë proxy-në sistemike. Por ka një porosi, në TOR është proxy SOCKS5, dhe për lehtësi do të na duhej gjithashtu një 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
Ja, tani në sistemin tonë kemi dy serverë proxy, dhe të dy dalin përmes TOR: socks5://192.168.0.2:9050 dhe
Tani mund të konfigurojmë ambientin e portofolit tonë
# 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:8123pra tani shell-i do të punojë nën proxy. Nëse duam të instalojmë pakot, është mirë të shtojmë në /usr/local/etc/pkg.conf nga rrënjësia e kafazit
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Tani është koha për të shtuar shërbimin e fshehtë TOR si adresë për shërbimin tonë SSH në kafazin e portofolit.
# 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.onionJa adresa jonë për lidhje. Le të kontrollojmë nga makina lokale. Por së pari duhet të shtojmë çelësin tonë SSH:
wallet@electrum:/ % mkdir ~/ .ssh
wallet@electrum:/ % ee ~/ .ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localPo dhe nga makina kliente me 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
Po lidhemi (Për të punuar kjo, nevojitet një demon lokal TOR, i cili dëgjon në 9050)
user@local ~$ ssh remotebtc
Autenticiteti i host-it 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' nuk mund të vendoset.
Gishtin e kyçit ECDSA është SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
A jeni të sigurt që dëshironi të vazhdoni lidhjen (po/jo/[gisht])? po
Kujdes: Shtuar përherë 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) në listën e hosteve të njohur.
FreeBSD 12.1-RELEASE-p1 GENERIC
Për të kursyer hapësirë në disqet në direktorinë tuaj të shtëpisë, kompresoni skedarët që përdorni rrallë
me "gzip filename".
-- Dru <genesis@istar.ca>
wallet@electrum:~ % logout
Sukses!
Për të punuar me pagesat momentale dhe mikro, na nevojitet gjithashtu një nodë , kjo do të jetë mjeti ynë kryesor për punën me Bitcoin. Në *, i cili do të përdoret si demon, ka , i cili është një ndërfaqe e plotë HTTP (REST) dhe lejon punimin si me transaksionet off-chain ashtu edhe me ato on-chain. c-lightning për funksionimin e tij ka nevojë për bitcoind noda.
*ka realizime të ndryshme në gjuhë të ndryshme të programimit për protokollin Lightning Network. Nga ato që kemi testuar, c-lightning (i shkruar në C) doli të jetë më stabil dhe më ekonomik në burime.
# 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
Ndërsa po kompilojmë dhe instalojmë gjithçka të nevojshme, le të krijojmë një përdorues RPC për lightningd në bitcoind
# jexec bitcoind
bitcoind:/@[10:36] # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#lejo vetëm c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[10:39] # service bitcoind restart
Ndërrimi im kaotik midis qelizave duket se nuk është kaotik fare nëse shënojmë utilitarin tmux, i cili lejon krijimin e shumë nën-seancave terminale brenda një seance. Analogu: screen
Së pari, nuk duam të ekspozojmë IP-në reale të nodës tonë, dhe duam të realizojmë të gjitha operacionet financiare përmes TOR. Prandaj na nevojitet një tjetër .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.oniontani le të krijojmë konfigurinë për 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=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
# për shembullin e sipërm logjet e inicializimit (të përziera me logjet e lightningd) duhet të printojnë diçka të tillë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 ~
duhet gjithashtu të krijoni një skedë konfigurimi për bitcoin-cli, mjeti që komunikon me bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testpo e kontrollojmë
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]në funksion lightningd
lightning@lightning:~ % lightningd --daemon
Wine lightningd mund të menaxhoni mjetin lightning-cli, për shembull:
lightning-cli newaddr merrni një adresë për një pagesë të re hyrëse
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all dërgoni të gjitha paratë e portofolit (të gjitha adresat on-chain)
Po ashtu janë komandat për operacione off-chain lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay etj.
E për këtë komunikim me aplikacionin, kemi REST Api
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Le të përmbledhim
# 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
Ne kemi një grup konteinerësh, çdo një me nivelin e vet të aksesit si brenda ashtu edhe jashtë rrjetit lokal.
# 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-dataSi e duket, bitcoind zë të gjitha 190 GB hapësirë. Çfarë nëse na nevojitet një nodë tjetër për teste? Këtu ZFS është në fakt shumë i dobishëm. Me ndihmën e cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com mund të krijojmë një snapshots dhe ta lidhim një qelizë të re me këtë snapshots. Qeliza e re do të ketë hapësirën e saj të plotë, por në sistemin e skedarëve do të llogaritet vetëm diferenca mes gjendjes aktuale dhe origjinalit (do të kursenim të paktën 190 GB)
Çdo qelizë është një dataset i veçantë ZFS, dhe kjo është shumë e përshtatshme. të bëjmë gjëra të tjera interesante, si dërgimin e snapshots nëpërmjet SSH. Nuk do ta përshkruajmë këtë, ka shumë për të thënë.
Gjithashtu, është e rëndësishme të theksohet nevoja për monitorimin e distancës të hostit, për këto qëllime .
B — siguria
Sa i përket sigurisë, le të fillojmë nga parimet kyçe në kontekstin e infrastrukturës:
Privatësia — Mjetet standarde të sistemeve UNIX-like sigurojnë përmbushjen e këtij principi. Ne ndajmë logjikisht qasjen në çdo element të veçantë të sistemit — qelizën. Qasja bëhet nëpërmjet autentikimit standard të përdoruesve me çelësa privatë. Të gjitha komunikimet mes dhe deri te qelizat përfundimtare ndodhin në mënyrë të enkriptuar. Falë enkriptimit të disqeve ne mund të mos shqetësohemi për ruajtjen e të dhënave gjatë zëvendësimit të disqeve ose migrimit në një server tjetër. Qasja e vetme kritike është ajo në sistemin host, pasi kjo qasje siguron, në përgjithësi, qasje në të dhënat brenda kontejnerëve.
Integriteti — Përmbushja e këtij principi ndodh në disa nivele të ndryshme. Së pari, është e rëndësishme të theksohet se në rastin e pajisjeve serverike, memoria ECC, ZFS tashmë "nga kutia" kujdeset për integritetin e të dhënave në nivel bitesh. Snapshots momentalë lejojnë kopjimin në çdo moment në kohë. Mjetet e reja të eksportimit-importimit të qelizave e bëjnë të lehtë replikimin e qelizave.
Disponueshmëria — Kjo është opsionale. Varet nga shkalla e njohjes suaj dhe nga fakti që keni armiq. Në shembullin tonë, ne siguruam aksesin në portofol ekskluzivisht nga rrjeti TOR. Nëse është e nevojshme, mund të bllokoni gjithçka në firewalls dhe të lejoni aksesin në server vetëm përmes tunelesh (TOR ose VPN është një pyetje tjetër). Kështu serveri do të jetë i izoluar sa më shumë nga bota e jashtme, dhe ne do të jemi ata që do të ndikojmë në disponueshmërinë e tij.
Paaftësia për të refuzuar — Kjo varet nga përshtatja e mëtjeshme dhe përmbushja e politikave të drejta të të drejtave të përdoruesve, aksesit etj. Por me një qasje të duhur, të gjitha veprimet e përdoruesve auditohen, dhe falë zgjidhjeve kriptografike është e mundur të identifikohet me saktësi kush e kur ka bërë veprime të caktuara.
Sigurisht, konfigurimi i përshkruar nuk është një shembull absolut se si duhet të jetë gjithmonë, është më shumë një nga shembujt se si mund të jetë, duke ruajtur mundësi shumë elastike për shkallëzim dhe personalizim.
Po si është me virtualizimin e plotë?
Për virtualizimin e plotë me mjete cbsd mund . Do të shtoja vetëm se për punët bhyve duhet të aktivizoni disa parameter të bërthamës.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Kështu që nëse papritmas ka nevojë të ngremë docker, atëherë ngritni ndonjë debian dhe përpara!
Kjo është gjithçka
Mendoj se kjo është gjithçka që doja të ndaja. Nëse ju pëlqeu artikulli, mund t’i dergoni disa bitcoin — . Nëse dëshironi të provoni qelizat në veprim dhe keni pak bitcoin, mund të hyni në projektin tim .
Burimi: habr.com
