Úgy alakult, hogy számítógépes rendszerek és hálózatok adminisztrátora vagyok (röviden: rendszergazda), és több mint 10 évnyi szakmai tevékenységem alatt számos különböző rendszert megismertem, beleértve azokat is, amelyek [megnövekedett|szigorúbb] biztonsági intézkedéseket igényelnek. Ezen kívül egy ideje találtam érdekesnek , és nemcsak használtam, hanem több mikro-szolgáltatást is indítottam, hogy megtanuljam, hogyan lehet saját magam dolgozni a bitcoin hálózaton (hiszen p2p, vagy mi a franc) fejlesztői szempontból (bár én valójában nem vagyok igazán az, csak úgy jártam arra). De nem a fejlesztésről beszélek, hanem a biztonságos és hatékony környezetről az alkalmazások számára. devA pénzügyi technológiák (
fintech) a hálózatbiztonsággal (infosec) együtt járnak, és az egyik a másik nélkül működhet, de nem tart sokáig. Ezért szeretném megosztani a tapasztalataimat és azoknak az eszközöknek a sorozatát, amelyeket használok, beleértve a, ráadásul egyszerre, és szélesebb, vagy akár teljesen más célokra is felhasználható. Ebben a cikkben nem annyira a bitcoinról fogok beszélni, hanem az infrastruktúra modelljéről a pénzügyi (és nemcsak) szolgáltatások fejlesztésére és üzemeltetésére – egy szóval azokról a szolgáltatásokról, ahol a „B” fontos szerepet játszik. Ez alkalmazható egy bitcoin tőzsdére, valamint egy olyan tipikus vállalati szolgáltatásállományra is, amelynek a bitcoinhoz semmi köze. ) a hálózatbiztonsággal (, valamint ) együtt járnak, és az egyik a másik nélkül működhet, de nem tart sokáig. Ezért szeretném megosztani a tapasztalataimat és azoknak az eszközöknek a sorozatát, amelyeket használok, beleértve aSzeretném megjegyezni, hogy a
„keep it stupid simple” „less is more” és elvek híve vagyok, ezért mind az írás, mind a benne leírtak ezeknek az elveknek a tulajdonságaival fognak rendelkezni.Képzelt forgatókönyv:
Воображаемый сценарий: Nézzük meg mindezt egy Bitcoin váltó példáján. Eldöntöttük, hogy forintot, dollárt, eurót váltunk Bitcoinra és vissza, és már van egy működő megoldásunk, de más digitális pénzekre, mint a Qiwi és Webmoney is kiterjesztjük, szóval minden jogi kérdést elintéztünk. Van egy kész alkalmazásunk, amely fizetési átjáróként működik forint, dollár és euró, valamint más fizetési rendszerek számára. Ez összekapcsolódik a bankszámláinkkal, és van egy API-nk a végső alkalmazásainkhoz. Emellett van egy webalkalmazásunk, amely a felhasználók számára váltóként funkcionál, hasonlóan egy tipikus Qiwi vagy Webmoney fiókhoz – hozzon létre fiókot, adjon hozzá egy kártyát és így tovább. Ez kapcsolódik a mi átjárónkhoz, például REST API-n keresztül a helyi hálózaton. Most úgy döntöttünk, hogy csatlakoztatjuk a bitcoint, és közben frissítjük az infrastruktúrát, mivel kezdetben mindent sietve állítottunk be virtuális boxokon az irodában az asztal alatt... a weboldalt kezdték használni, és mi aggódni kezdtünk a működési idő és teljesítmény miatt.
Tehát kezdjük a lényeget - a szerver kiválasztása. Mivel a vállalkozásunk ebben a példában kicsi, és megbízunk a szolgáltatóban (OVH), választunk , amelynél nem lehet telepíteni az operációs rendszert az eredeti .iso képből, de ez nem baj, az IT biztonsági osztály mindenképpen elemzi az telepített képet. Amikor növekszünk, szinte biztos, hogy bérelni fogunk egy saját, zárt szekrényt korlátozott fizikai hozzáféréssel, esetleg saját adatközpontot is építünk. Mindenesetre érdemes megjegyezni, hogy amikor hardvert bérelünk és kész képeket telepítünk, van esély arra, hogy a rendszerben egy „hosztektől származó trójai” fog lógni, amely a legtöbb esetben nem az Ön megfigyelésére szolgál, hanem hogy kényelmesebb szerverkezelési eszközöket ajánljon.
Szerver telepítése
Itt minden egyszerű. Kiválasztjuk az igényeinknek megfelelő hardvereket. Ezután kiválasztjuk a FreeBSD képet. Vagy csatlakozunk (más hosztnál és saját hardvernél) IPMI-vel vagy monitorral, és betesszük a rendszerbetöltőbe a FreeBSD .iso képet. Az orchestral telepítéshez én a és programot használom. Az egyetlen dolog, hogy a kimsufi esetében mi a custom installation -t választottuk, hogy a tükörben lévő két merevlemez csak a boot és a /home partíciók „nyitottak” legyenek, a lemez többi része titkosítva lesz, de erről később.
A rendszer telepítése standard módon történik, nem állok meg ezen, csak megjegyzem, hogy a használat megkezdése előtt érdemes figyelni hardenelés az opciókra, amelyeket ajánl bsdinstaller a telepítés végén (ha saját magad telepíted a rendszert):
Van erről a témáról, röviden itt megismétlem.
A fent említett paramétereket már telepített rendszeren is aktiválhatod. Ehhez módosítani kell a betöltő fájlt és engedélyezni a kernel paramétereket. *ee — egy szerkesztő a BSD-ben
# 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=1Azt is érdemes megbizonyosodni, hogy a legújabb verzió van telepítve, és . A mi esetünkben például a legújabb verzióra való frissítés szükséges, mivel a telepített képek hat hónappal egy évvel le vannak maradva. És ott megváltoztatjuk az SSH portot az alapértelmezetten eltérőre, hozzáadjuk a kulcs alapú hitelesítést és letiltjuk a jelszavas bejelentkezést.
Ezután beállítjuk aide, a rendszer konfigurációs fájljainak állapotának megfigyelésére. Bővebben olvashatsz .
pkg install aide
és szerkesztjük a crontabunkat
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/$MYFILENAMEEngedélyezzük
sysrc auditd_enable=YES
# service auditd start
Hogyan kell ezt jól adminisztrálni, azt remekül leírták a .
Most újraindítjuk a rendszert, és elkezdjük a szoftverbeállítást a szerveren. Minden szerver hipervizorként működik, vagy konténerek vagy teljes virtuális gépek számára. Ezért fontos, hogy a processzor támogassa a VT-x és EPT-t, ha teljes virtualizálást tervezünk használni.
Konténerek és virtuális gépek menedzselésére én a tól , sok egészséget és áldást kívánok ennek a nagyszerű segédprogramnak!
Konténerek? Ismét a docker kérdése?
De hogy is van ez. — ez egy kiváló eszköz a konténerezzéshez, míg az említett cbsd-t azoknak a konténereknek az orchestrationjára készült, amelyek neve — cellák.
A konténer egy rendkívül hatékony megoldás különböző célú infrastruktúrák kiépítésére, ahol végül teljes izolációra van szükség az egyes szolgáltatások vagy folyamatok között. Alapvetően ez a gazda rendszer klónja, de nincs szükség teljes hardver virtualizációra. Így az erőforrások nem az "ügyfél operációs rendszerre" költődnek, hanem csak a végrehajtandó feladatra. Amikor a konténereket belső igényekhez használják, ez egy nagyon kényelmes megoldás az erőforrások optimális kihasználására — több konténer is egyetlen fizikai szerveren külön-külön maximálisan kihasználhatja a szerver erőforrásait, ha szükséges. Figyelembe véve, hogy általában különböző alárendelt szolgáltatások különböző időpontokban igényelnek extra forrásokat, egyetlen szerverből maximális teljesítményt lehet kihozni, ha a konténereket megfelelően tervezik és elosztják a szerverek között. Szükség esetén a konténerekhez erőforrás-használati korlátokat is be lehet állítani.
Mi a helyzet a teljes virtualizációval?
Amennyire tudom, cbsd-t támogatja a bhyve és XEN hipervízort. A másodikat sosem használtam, de az első egy viszonylag fiatal . A következőkben bemutatunk egy példát a használatára. bhyve Példa alatt fogjuk ezt bemutatni.
A host környezet telepítése és beállítása
Használunk egy fájlrendszert . Ez egy rendkívül erőteljes eszköz a szerveren elérhető tárhely kezelésére. A ZFS segítségével közvetlenül a lemezekből építhetünk különböző konfigurációjú tömböket, dinamikusan "melegében" bővíthetjük a tárhelyet, cserélhetjük a hibás lemezeket, kezelhetjük a pillanatfelvételeket és még sok mást, amiről egy egész sorozatot lehetne írni. Térjünk vissza a szerverünkhöz és annak lemezeihez. A telepítés elején szabad területet hagytunk a lemezeken a titkosított partíciók számára. Miért? Azért, hogy a rendszer automatikusan fel tudjon állni, és SSH-n figyelni tudjon.
gpart add -t freebsd-zfs /dev/ada0
/dev/ada0p4 added!
hozzáadjuk a lemez partíciót a fennmaradó helyre
geli init /dev/ada0p4
megadjuk a titkosítási jelszavunkat
geli attach /dev/ada0p4
ismét beírjuk a jelszót, és megjelenik a /dev/ada0p4.eli eszköz — ez a mi titkosított terünk. Ezután ugyanezt megismételjük a /dev/ada1 és a többi lemez esetében a tömbben. És létrehozzuk az új .
zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — nos, készen van a minimális működőképes készletünk. Tükör tömb a lemezekből, ha az egyik a három közül meghibásodik.
Új „pool”-on adatbázist hozunk létre
zfs create vms/jails
pkg install cbsd — végrehajtottuk a parancsot, és telepítjük a menedzsmentet a sejtjeinkhez.
Miután cbsd-t telepítve lett, inicializálni kell:
# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv
nos, és rengeteg kérdésre válaszolunk, főleg az alapértelmezett válaszokkal.
*Ha titkosítást használ, fontos, hogy a démon cbsdd ne induljon el automatikusan, amíg manuálisan vagy automatikusan (példánkban ezt a zabbix végzi) nem dekódolja a lemezeket.
**Én sem NAT-ot használok a cbsd-t, hanem én állítom be őt 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 a sejtekhez
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Bitcoin hálózati port előre-irányítá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
A tűzfal politikák beállítása külön téma, ezért nem mélyedek el a BLOCK ALL politika és a fehérlisták beállításában, ezt elolvashatja vagy bármely más hatalmas mennyiségű cikkben, ami elérhető a Google-ben.
Nos… telepítettük a cbsd-t, ideje létrehozni az első munkalovunkat — a Bitcoin démonunkat a sejten belül!
cbsd jconstruct-tui
Itt a sejt létrehozási párbeszédablakát látjuk. Miután minden értéket beállítottunk, létrehozzuk!
Az első sejt létrehozásakor ki kell választani, hogy mit használjunk alapként a sejtek számára. Én a FreeBSD tárolóból választom a repo. Ez a választás csak az adott verzió első sejtjének létrehozásakor történik (bármekkora verziójú sejteket hosztolhatunk, ami újabb mint a hoszt verziója).
Miután minden telepítve van — elindítjuk a sejtet!
# cbsd jstart bitcoind
De először szoftvereket kell telepítenünk a sejtbe.
# jls
JID IP Cím Hostnév Útvonal
1 192.168.0.1 bitcoind.space.com /zroot/jails/jails/bitcoindjexec bitcoind hogy belépjünk a sejt konzoljába
és már a sejt belsejében telepítjük a szoftvert a függőségeivel (a hoszt rendszerünk tiszta marad)
bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils
bitcoind:/@[15:30] # sysrc bitcoind_enable=YES
bitcoind:/@[15:30] # service bitcoind start
A Bitcoin a sejten belül van, de anonim ként kell maradnunk, mert néhány sejtet szeretnénk csatlakoztatni a TOR hálózaton. És egyáltalán, a legtöbb sejtet gyanús szoftverekkel proxy-n keresztül akarjuk futtatni. Köszönhetően pf Lehetőség van a NAT-t egy adott IP-cím tartományra letiltani a helyi hálózaton, és lehetővé tenni a NAT-t csak a TOR-csomópontunk számára. Így még ha egy rosszindulatú program bekerül a cellába, akkor valószínűleg nem tud kapcsolatba lépni a külső világgal, és ha mégis, nem fogja felfedni a szerverünk IP-címét. Ezért létrehozunk egy új cellát a szolgáltatások "továbbításához", mint a ".onion"-szolgáltatás és mint egy proxy, amelyen keresztül az interneten kereshetnek a különböző cellák.
# 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
Tegyük a helyi címre hallgatni (minden cella számára elérhető)
SOCKSPort 192.168.0.2:9050
Mi hiányzik még a teljes boldogsághoz? Igen, szükségünk van egy szolgáltatásra a webünk számára, lehet, hogy nem is egyre. Indítsuk el az nginx-et, amely a reverse-proxy szerepét fogja betölteni és gondoskodik a Let’s Encrypt tanúsítványok megújításáról.
# cbsd jsconstruct-tui
# cbsd jstart nginx-rev
# jexec nginx-rev
nginx-rev:/@[15:47] # pkg install nginx py36-certbot
Íme, 150 MB függőség került a cellába. Az állomás továbbra is tiszta.
Később visszatérünk az nginx beállításához, először még szükségünk van két cella létrehozására a nodejs és rust alapú fizetési átjárónknak, és egy webalkalmazásnak, ami valami okból Apache-on és PHP-n fut, ráadásul az utolsónak szüksége van egy MySQL adatbázisra.
# 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
… és még 380 MB csomag izolaálva.
Ezután git-en keresztül betöltjük az alkalmazásunkat és elindítjuk.
# cbsd jsconstruct-tui
# cbsd jstart webapp
# jexec webapp
webapp:/@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql
450 MB csomag a cellában.
Itt SSH hozzáférést biztosítunk a fejlesztőknek a cellába, ők mindent megoldanak:
webapp:/@[16:02] # ee /etc/ssh/sshd_config
Port 2267 — megváltoztatjuk a cella SSH portját bármilyen tetszőleges számra
webapp:/@[16:02] # sysrc sshd_enable=YES
webapp:/@[16:02] # service sshd start
Most már elindult a szolgáltatás, hátra van még egy szabály hozzáadása a pf tűzfalhoz
Nézzük meg, milyen IP-címek vannak a cellákban, és hogy néz ki egyáltalán a "helyi hálózatunk".
# jls
JID IP cím Gazda Ösvény
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és hozzáadunk egy szabályt
# 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
nos, mivel itt vagyunk, adjunk hozzá egy szabályt a reverse-proxy-ra is:
## 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
Most egy kicsit a bitcoinokról
Mit is adunk? Van egy webalkalmazásunk, amely elérhető kívülről, és ami lokálisan kommunikál a fizetési átjárónkkal. Most fel kell készülnünk a Bitcoin hálózattal való interakcióra – a node-ra. bitcoind Ez csupán egy démon, amely egy helyi példányát tartja fenn az aktuális blokkláncnak. Ennek a démonnak van RPC és pénztárca funkciója, azonban alkalmazások fejlesztéséhez kényelmesebb "burkolatok" léteznek. Először úgy döntöttünk, hogy telepítjük electrum — ez egy CLI pénztárca. külön tárolásként fog szolgálni a bitcoinjaink számára — ezek azok a bitcoinok, amelyeket "kívül" kell tartanunk a felhasználók számára elérhető rendszeren és távol mindentől. Van GUI-ja is, így egy ilyen pénztárcát szeretnénk használni a
laptopjainkon. Egyelőre az Electrumot nyilvános szerverekkel használjuk, később pedig egy másik ketrecben beállítunk , hogy teljesen függetlenek legyünk bárkitől sem.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum: /@[8:45] # pkg install py36-electrum
még 700 MB szoftverünk van a ketrecben
electrum: /@[8:53] # adduser
Felhasználónév: wallet
Teljes név:
Uid (hagyja üresen az alapértelmezetthez):
Bejelentkezési csoport [wallet]:
A bejelentkezési csoport wallet. Meghívjuk a wallet-ot más csoportokba? []:
Bejelentkezési osztály [alapértelmezett]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Otthoni könyvtár [ /home/wallet]:
Otthoni könyvtár engedélyek (hagyja üresen az alapértelmezetthez):
Használjon jelszó alapú hitelesítést? [igen]: nem
Zárja le a fiókot a létrehozás után? [nem]:
Felhasználónév : wallet
Jelszó : <letiltva>
Teljes név :
Uid : 1001
Osztály :
Csoportok : wallet
Otthon : /home/wallet
Otthoni mód :
Shell : /bin/tcsh
Zárolva : nem
OK? (igen/nem): igen
adduser: INFO: Sikeresen hozzáadta (wallet) a felhasználói adatbázishoz.
Hozzon létre egy másik felhasználót? (igen/nem): nem
Viszlát!
electrum: /@[8:53] # su walletelectrum: /@[8:53] # su wallet
wallet@electrum: / % electrum-3.6 create
{
"msg": "Kérjük, hogy a magját biztonságos helyen tárolja; ha elveszíti, nem tudja visszaállítani a pénztárcáját.",
"path": "/usr/home/wallet/.electrum/wallets/default_wallet",
"seed": "irigykedő disznó anyag szalag ifjú ütés vizuális rendben kaktusz véletlen madár"
}Most létrehoztunk egy pénztárcát.
wallet@electrum: / % electrum-3.6 listaddresses
[
"18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
"14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
"1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
...
"1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
"18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]wallet@electrum: / % electrum-3.6 help
A mi on-chain pénztárcánkhoz ezentúl csak egy korlátozott kör tud csatlakozni. Annak érdekében, hogy ne nyissuk meg a külső hozzáférést ehhez a ketrechez, a csatlakozások SSH-n keresztül fognak történni TOVÁBBI részletek, ami egy decentralizált VPN opciót jelent. Elindítjuk a SSH-t a ketrecben, de nem érintjük az pf.conf-ot a gazdagépen.
electrum: /@[9:00] # sysrc sshd_enable=YES
electrum: /@[9:00] # service sshd start
Most kikapcsoljuk a pénztárcával rendelkező ketrec internet elérhetőségét. Egy másik alhálózatból származó IP-címet adunk neki, amely nem NAT-olt. Először megváltoztatjuk /etc/pf.conf a gazdagépen
# ee /etc/pf.conf
JAIL_IP_POOL="192.168.0.0/24" változtatjuk JAIL_IP_POOL="192.168.0.0/25", így minden cím 192.168.0.126-255 nem rendelkezik közvetlen internet hozzáféréssel. Olyan, mint egy szoftveres "air-gap" hálózat. A NAT szabály pedig marad a régi.
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
Újra töltjük a szabályokat.
# pfctl -f /etc/pf.conf
Most pedig nekilátunk a cellánknak.
# cbsd jconfig jname=electrum
jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Régi IP eltávolítása: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Új IP beállítása: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200Hm, de most már a rendszer is leállhat. Azonban megadhatjuk a rendszerszintű proxy-t. De van egy bökkenő, a TOR-hoz SOCKS5 proxy szükséges, és a kényelmünk érdekében még HTTP proxy-ra is szükség lenne.
# 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
Nos, most a rendszerünkben két proxy-szerver van, és mindkettő a TOR-on keresztül működik: socks5://192.168.0.2:9050 és
Most már beállíthatjuk a pénztárcánk környezetét.
# 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:8123Nos, mostantól a shell proxy-n keresztül fog működni. Ha csomagokat szeretnénk telepíteni, érdemes hozzáadni a /usr/local/etc/pkg.conf a cella root-jából
pkg_env: {
http_proxy: "http://my_proxy_ip:8123",
}Most pedig elérkezett az idő, hogy hozzáadjuk a TOR rejtett szolgáltatást SSH szolgáltatásunk címeként a pénztárca cellájához.
# 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.onionItt van a csatlakozási címünk. Ellenőrizzük egy helyi gépről. De először hozzá kell adnunk a SSH kulcsunkat:
wallet@electrum:/ % mkdir ~/.ssh
wallet@electrum:/ % ee ~/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@localMost pedig a kliens Linux gépről
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
Csatlakozunk (Ehhez szükséges egy helyi TOR démon, amely a 9050-es porton hallgat.)
user@local ~$ ssh remotebtc
A 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' gazdagép hitelessége nem állapítható meg.
Az ECDSA kulcsujjlenyomat SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Biztos benne, hogy folytatni szeretné a csatlakozást (igen/nem/[ujjlenyomat])? igen
Figyelmeztetés: A "mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion" (ECDSA) tartósan hozzá lett adva az ismert gazdagépek listájához.
FreeBSD 12.1-RELEASE-p1 GENERIC
A tárhely megtakarítása érdekében, tömörítse azokat a fájlokat, amelyekre ritkán használ.
Siker!
Az azonnali és mikrotranzakciók kezeléséhez szükség van egy node-ra is. , ez lesz a fő munkaszerszámunk a bitcoinnal. A *, amelyet démonként fogunk használni, rendelkezik amely egy teljes értékű HTTP (REST) interfészt biztosít, lehetővé téve, hogy off-chain és on-chain tranzakciókkal egyaránt dolgozzunk. c-lightning A működéshez szükséges bitcoind nód.
*Több különböző megvalósítás létezik a Lightning Network különböző programozási nyelveken. A tesztelt verziók közül a c-lightning (C nyelven írt) a legstabilabb és a legnagyobb erőforrás-hatékony.
# cbsd jsconstruct-tui
# cbsd jstart cln
# jexec cln
lightning:/{@[10:23]} # adduser
Felhasználónév: 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
Amíg a szükséges összes telepítése és fordítása folyik, létrehozunk egy RPC felhasználót a lightningd-hez. be. bitcoind
# jexec bitcoind
bitcoind:/{@[10:36]} # ee /usr/local/etc/bitcoin.conf
rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
#csak c-lightning engedélyezése
rpcallowip=192.168.0.7/32bitcoind:/{@[10:39]} # service bitcoind restart
A látszólag kaotikus váltásaim a cellák között nem is olyan kaotikus, ha megemlítjük az eszközt, tmux, amely lehetővé teszi, hogy egyetlen munkameneten belül több alsó munkamenetet hozzunk létre. Analóg: screen
Nos, nem akarjuk felfedni a nódunk valós IP címét, és minden pénzügyi tranzakciót a TOR-on keresztül szeretnénk végezni. Ezért szükségünk van egy másik .onion-ra.
# 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.onionMost létrehozunk egy konfigurációt a c-lightning-hez.
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 bővítmény
# https://github.com/fiatjaf/lightningd-gjson-rpc/tree/master/cmd/sparko
sparko-host=192.168.0.7
sparko-port=9737
sparko-tls-path=sparko
#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
# a fenti példához az inicializáló naplóknak (amelyek keverve vannak a lightningd naplóval) valami ilyesmit kell nyomtatniuk: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 ~
A konfigurációs fájlt is létre kell hozni a bitcoin-cli számára, amely a bitcoind
lightning@lightning:~ % mkdir .bitcoin
lightning@lightning:~ % ee .bitcoin/bitcoin.conf
rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=testellenőrzés
lightning@lightning:~ % bitcoin-cli echo "test"
[
"test"
]indítjuk lightningd-hez.
lightning@lightning:~ % lightningd --daemon
Mi lightningd-hez. vezérelheti az eszközt lightning-cli, például:
lightning-cli newaddr címet kapni az új bejövő tranzakcióhoz
{
"address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
"bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all küldje el az összes pénzt a pénztárcában lévő címre (minden on-chain címre)
Ezen kívül parancsok az off-chain műveletekhez lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay stb.
De a programmal való kommunikációhoz REST Api áll rendelkezésünkre
curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'
Összegzés
# jls
JID IP cím Hostnév Útvonal
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
Van egy sor konténerünk, mindegyik saját hozzáférési szinttel a helyi hálózaton belül és kívül.
# zfs list
NÉV HASZNÁLT ELÉRHETŐ REFERENCIA MENTÉSI PONT
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-dataAhogy látható, a bitcoind minden 190 GB helyet foglal. Mi a helyzet, ha szükségünk lenne egy másik csomópontnál a teszteléshez? Itt a ZFS pont jól jön. Segítségével cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com Lehet készíteni egy pillanatfelvételt, és egy új tárolót kötni ehhez a pillanatfelvételhez. Az új tárolónak teljesen saját környezete lesz, de a fájlrendszeren belül csak a jelenlegi állapot és az eredeti közötti különbséget fogjuk figyelembe venni (legalább 190 GB-ot spórolhatunk).
Minden tároló egy külön ZFS adathalmazon alapul, ami rendkívül kényelmes. hogy különféle más menő dolgot tegyünk, mint például pillanatfelvételek küldése SSH-n. Erről most nem beszélünk, így is sokat mondtunk.
Fontos megjegyezni a hoszt távoli monitorozásának szükségességét, erre az célokra .
B – biztonság
A biztonság tekintetében kezdjük a legfontosabb elvekkel az infrastruktúrára vonatkozóan:
Adatvédelem – A UNIX-alapú rendszerek standard eszközei biztosítják ennek az elvnek a végrehajtását. Logikailag elkülönítjük a hozzáférést minden logikailag különálló rendszer elemhez – tárolóhoz. A hozzáférés standard felhasználói hitelesítéssel, a felhasználók személyes kulcsaival történik. A kommunikáció minden végső tároló között titkosított formában zajlik. A lemezek titkosításának köszönhetően nem kell aggódnunk az adatok megőrzéséért lemezcserék vagy másik szerverre történő migráció során. Az egyetlen kritikus hozzáférés a hoszt rendszerhez való hozzáférés, mivel ez általában hozzáférést biztosít az adatokhoz a tartályokban.
Integritás – Ennek az elvnek a végrehajtása különböző szinteken valósul meg. Először is fontos megjegyezni, hogy a szerver hardver esetében az ECC memória, a ZFS „do-it-yourself” gondoskodik az adatok integritásáról a bitek szintjén. Az azonnali pillanatfelvételek lehetővé teszik, hogy bármikor élőben biztonsági mentést végezzen. A tárolók export-import eszközei megkönnyítik a tárolók replikálását.
Elérhetőség – Itt már opcionális. Függ a széleskörű ismeretségedtől és attól, hogy vannak-e ellenségeid. A példánkban a pénztárca elérhetőségét kizárólag a TOR hálózaton keresztül biztosítottuk. Szükség esetén a tűzfalon le lehet tiltan a külső világ közvetlen elérését, és a szerverhez való hozzáférést kizárólag alagútokon (TOR vagy VPN esetében) engedélyezhetjük. Így a szerver a lehető legjobban el lesz vágva a külső világtól, és a hozzáférhetőségét csak mi befolyásolhatjuk.
Megfékezhetetlenség — Ez a további használattól és a felhasználói jogok, hozzáférések stb. helyes politikájának betartásától függ. De helyes megközelítéssel minden felhasználói tevékenység auditálásra kerül, és a kriptográfiai megoldásoknak köszönhetően egyértelműen azonosítható, hogy ki és mikor hajtott végre bizonyos tevékenységeket.
Természetesen a leírt konfiguráció nem egy abszolút példa arra, hogy ez mindig hogyan kellene mennie, inkább csak egy példa arra, hogyan nézhet ki, megőrizve a nagyon rugalmas skálázási és testreszabási lehetőségeket.
De mi van a teljes virtualizációval?
A cbsd eszközeivel teljes virtualizálásról lehet . Csak annyit tennék hozzá, hogy a működéshez bhyve bizonyos kernelparamétereket kell aktiválni.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Szóval, ha esetleg szükség van Docker indítására, akkor elindítunk egy Debian-t, és rajta!
Azt hiszem, ennyi.
Igen, ez minden, amivel meg akartam osztani. Ha tetszett a cikk, akkor lehet nekem Bitcoin-t küldeni — . Ha szeretné kipróbálni a kereteket működés közben, és van néhány Bitcoin-ja, akkor elérhet engem a .
Forrás: habr.com
