Távolról indítható titkosított gép

 ( nagylzs | 2019. október 9., szerda - 8:30 )

Van egy fejlesztői gépem a munkahelyemen, és azon vannak dolgaim. Ide értve mindenféle git repository-kat és más fejlesztői cuccokat. Ezen felül otthon is van ilyen gépem, néha azon dolgozom (hétvégén). Előfordul néha, hogy elfelejtek push-olni, és ott maradnak rajta dolgok. Aztán hazajövök, és a hétvégi éles rendszer frissítéskor derül ki, hogy valami nem volt push-olva. Vagy épp fordítva: hétvégén dolgozok otthon, és a munkahelyemen jövök rá hogy 100 sor kód hiányzik. Ez csak egy példa probléma a sok közül ami abból adódik, hogy valamit lementek egy gépre, és később már nem tudom elérni.

Ezeken a gépeken vannak olyan bizalmas dolgok is, ami miatt teljes lemez titkosítás van rajta (LUKS). (Pl. szerződésben foglaltak miatt van amit csak titkosítva lehet tárolni.)

Gondoltam arra hogy bekapcsolva hagyom ezeket a gépeket, hogy mindig el tudjam érni, de ezt elvetettem. A lehetséges sok indok közül az egyik, hogy nem akarok környezetet szennyezni, és miért menjen a gép egész héten/hétvégén, mikor 95% valószínűséggel nincs rá szükség. Egyébként biztonsági szempontból ez lenne az ideális, de nagy pazarlás lenne az otthoni gépemet bekapcsolva tartani egész héten.

Az ideális megoldás olyan, hogy a gép nem fogyaszt semmit ha nincs rá szükség, távolról fel tudom éleszteni, és a teljes lemez titkosítva van. De ha valaki kiveszi belőle az adathordozót, akkor nem fér hozzá az adatokhoz (jelszó nélkül).

A felélsztésre elvileg lehetőséget kínálna az alaplapon bekapcsolható "wake on lan" funkció. De a teljes lemezes titkosítás miatt sajnos ez így működésképtelen, a boot-oláskor nem tudom beírni a jelszót ha nem vagyok ott.

Elvi lehetőség lenne a részleges titkosítás - távolról elindítható a gép, de a bizalmas adatokat külön partícióra tenném, ami már csak jelszóval védve érhető el. Egyrészt ezt nem nehéz kijátszani (meg lehet root-olni a rendszert amikor nem veszem észre). Másrészt ez feltételezi azt, hogy előre tudni fogom hogy mik azok a könyvtárak amiben bizalmas adatok vannak, és hogy ez időben nem változik, és garantáltan nem tévedek benne.

Gondolkodtam azon is, hogy az alap rendszeren belül elindítok docker-ben egy másik rendszert, és ennek a másik rendszernek a root partíciója lenne titkosított lemezen. A külső rendszer csak egy üres héj lenne, és minden más a "belső" rendszerben. Ez csak egy kósza ötlet, még nem próbáltam megvalósítani. Nem vagyok benne hogy ez elég hatékony lenne (pl. teljes fejlesztői környezetet docker-ben elindítani, és ezt mégis hogy fogom kiteni a host gépen futó X szerverre?)

Újabb ötlet: bérelt szerveren indítok egy tightvnc-t és azon fejlesztek ssh tunnel-en át. Ott a fizikai hozzáférés korlátozása megfelelő mértékben megvalósul, és nincsen probléma az elindítással meg a leállítással. De sajnos ez se működik mindig. Van például egy olyan projekt amiben digitális nagyothalló készülékeket kell programozni egy speciális programozó eszközön keresztül. Na ezt például egy távoli szerveren nem lehet (egy bérelt VM-re nem tudom rádugni ezt az eszközt, és nem tudom rajta cserélgetni a füleseket).

Egyéb elvetemült ötlet: hibernálni a gépet, és feléleszteni ha szükség van rá. Ez egyébként ideális lehetne: szinte nulla fogyasztás, teljes lemez titkosítás és bármikor föl lehet éleszteni. Linux hibernálásban nem vagyok otthon, fogalmam sincs hogy ezt hogy lehetne megoldani úgy, hogy hibernált állapotból fölébredjen wake-on-lan -ra, és ne kérje be újra a LUKS jelszavát.

Tulajdonképpen ezt az utolsót leszámítva nem jut eszembe jó megoldás, de ehhez meg nem tudom hogy kezdjek hozzá.

Gondoltam megkérdezem itt, hátha valakinek van egy jó ötlete.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

2 lehetőséget látok:
1. menjen valami a munkahelyen 24/7 és ne felejts el oda pusholni :)
2. építsd/vegyél otthonra egy nagyon kis fogyasztású gépet és abban legyen(ek) a diszk(ek) (opcionálisan redundanciával) amiken a git repókat tárolod és ez a gép menjen 24/7

git repo a git szerverre való, amit a kedves dolgozó elér az irodából direktben, vagy pedig otthonról az irodai VPN-en keresztül. De persze lehet kókányolni is, utána meg szűkölni, ha felfordul. Ennyi erővel tartsa a repókat pendriveon a kulcstartóján.
-------------------------
Hivatásos pitiáner
neut @

totally agree, de gondoltam azért próbálok az eredeti problémára is valami konstruktívat írni :D

Végig se olvastam a témainditót mert az első bekezdés után nyilvánvaló volt, hogy kókányolni akarunk...
-------------------------
Hivatásos pitiáner
neut @

Hogyhogy nem a preshazban vagy?

Bezárt. Konszolidálódok éppen (ha nem látszana :D).
-------------------------
Hivatásos pitiáner
neut @

Teljesen nyilvánvalóan NEM kókányolni akarunk. Nem értem honnan veszitek hogy nincs git szerver? Sőt, több is van...

És ki mondta hogy nincs? Van rendes gitlab szerver! A probléma nem azzal van hogy nincs szerver, hanem hogy néha elfelejtek push-olni. PLUSZ nem csak konkrétan a gitlab-bal van baj, hanem úgy általában véve mindenféle más adattal is, ami éppen nem azon a gépen van mint amihez épp leülök.

Csak egy tipp és kell hozzá szerver is: a LUKS tud network unlockot, amikor egy szervertől kéri le a kulcsot. Így otthon felold, de ha viszik a gépet, akkor nem tudnak vele mit kezdeni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Na ez egy értelmes válasz! :-) Nem tudtam hogy van ilyen, de utána nézek! Talán még az sem lesz lehetetlen, hogy az otthoni MikroTik -on keresztül távolról toljam neki a kulcsot amikor el akarom indítani.

Találtam is hozzá leírást: https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x-server-and-enable-remote-unlocking/ hamarosan kipróbálom egy virtuális gépen és megírom a tapasztalatokat.

Majd számolj be róla, eddig csak egy RedHat sajtóközleményben találkoztam vele, hogy talán a 7.4-ben tech preview-ként megjelent és 7.5-től támogatott is lesz :) [bár ha jól látom, amit te linkeltél, az nem feltétlenül az]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egy alapvetően nem technikai jellegű problémára keresel technikai megoldsát.

Ezen kívül biztonsági indokokat hozol fel követelményként, de a jelenlegi szokásaid (és a felvetett ötleteid) eleve lehetetlenné teszik a "biztonság" elérését.

Használj laptopot munkára.
És akkor egy helyen lesz minden kódod, titkosítva is lehet minden, és bárhová magaddal viheted, stb.

Szerintem.
--
zrubi.hu

> Egy alapvetően nem technikai jellegű problémára keresel technikai megoldsát.

+1

Illetve letezhet technikai megoldas, de ezt a workflow-t elotte ketszer is atgondolnam.

Ez így van. Ami a workflow-t illeti, az át van gondolva! Nem célom az, hogy távolról utólag push-oljam föl a változtatásaimat. Nem ez a normál workflow! Viszont mindenkivel előfordult már, hogy elfelejtette. Én elég feledékeny vagyok, és elég gyakran előfordul velem ahhoz, hogy megpróbáljak rá megoldást keresni.

Szóval nem egy rosszul megtervezett workflow-t akarok ilyen módon kijavítani, hanem egy jól megtervezett, de feledékenységből rosszul kivitelezett workflow-t akarok (esetenként) távolról megmenteni, és elkerülni hogy adott esetben 50km-t kelljen utaznom egy kis feledékenység miatt.

Plusz még egyszer hangsúlyozom, hogy itt nem csak a git-ről van szó. Vannak egyéb adatok is amikre általában nincsen szükségem, de nagyon ritkán lehet hogy mégis kell és akkor szeretnék hozzáférni. (És ezek között vannak olyanok amiket nem akarok felhőbe tölteni.)

Erre valo a laptop. Viszed magaddal oda, ahonnan dolgozni szeretnel.

Hát igen esetleg ez is jó lehet. Bár ezen a gépen pont nincs D-SUB de talán az még megoldható hogy legyen.

Szerintem is a "dolog-beosztásodon" kellene változtatni, vagy laptop, vagy pendrive, vagy hdd. Ez nem lenne nagy megerőltetés.

/* Sokszor túlbonyolítunk amúgy dolgokat.
De ha maga a megoldás érdekel, akkor én a leggyorsabban pl egy pic-cel csinálnám meg. Jó persze, azért, mert én ahhoz értek és ez menne a leggyorsabban. Csak egy wifi jelszót kellene kérnem a munkahelyen (meg persze a hálózati policy is érdekes lehet, ez függ a cégtől) és 3-4000 Ft-ból összeraknám. Kényelem és biztonság. Meg egy kicsit fun. De nem industrial. */

Amúgy egy időben próbálkoztam ezzel is, de akkor meg a HDD-t hagytam otthon. :-)

ubuntuban megoldhato: dropbear-initramfs csomag. a /etc/dropbear-initramfs konyvtarba kell berakni az authorized_keys, config, *_host_key fajlokat.

initramfs-nek elmondod hogy szedjen fel ip (/etc/initramfs-tools/initramfs.conf)
IP="192.168.2.101::192.168.2.1:255.255.255.0::eth0:off"

ezutan bootolaskor felhuzza az ipt, indit egy ssht, oda ssh kulcssal be tudsz lepni, es be tudod irni a luks jelszot. utana szepen kikapcsolja az ssht, meg leszedi az ipt.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Igen, ilyet én is csináltam. De ehhez portforward is kell kívülről az illetőnek.

Szerintem az (vagy VPN) most is van a kérdezőnek. Én is ezt javaslom!

Igen, van. L2TP MikroTik-on át, és ssh tunnel is lehetséges.

Hasonlót anno csináltam ügyfélnek. A fontos adatokat tartalmazó partíciót luks-al titkosítottam, a kulcsot kitettem pendrivera. VPN kapcsolatot csináltam egy távoli távoli gépre. A távoli gépen egy scriptet futtatva a local gépre egy ramdrive-ba felmásoltam a kulcsot, kikulcsoltam, töröltem a kulcsot.

TPM nincs a gépben? Mert ha igen, akkor oda lehet rakni a kulcsokat, arra van kitalálva.

es ha viszik az egesz gepet akkor ugyanugy elerik az adatot?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hát, Windows-on, bitlockerrel, ahol tpm-be van a cucc, hogy tudjon automatán indulni, ha más OS-t indítok a gépen a hdd tartalmát nem látja.

Mar miert ernek el?

Valami hasonlót csinálok, igaz biztonsági mentés a cél.
A cégnél van VPN és arról elérhetőék a git repok, de nem akarok, illetve kényelmetlen minden fityfenét állandóan kommitolni + pusholni, így ez szinkronizálni nem az igazi. Illetve vannak dolgok amik a szerverre nem kerülnek fel, de néha jól jön (pl reflog). A git arra való, hogy a fejlesztésben segítsen, backupra, szinkronizálásra inkább valami más kell.

Van a cégnek Office365 és korlátlan OneDrive, de mivel a szinkronizációs stratégiája egy kalap ...., nem lenne szerencsés a git repokat benne tartani. (Amúgy is szóköz van az elérési útvonalban, és az IT ragaszkodik a távolról piszkálásához, szóval ezen nem tudok változtatni.)

Szóval van egy cuki kis backup programom, ami periodikusan archívba teszi a megfelelő dolgaimat, az archív pedig megy a OneDrive könyvtárába, és így fel a felhőbe. Az archív jelszó védett, de lehetne akár titkosított is. Ha a backup program fel tudja kelteni a gépet, elég lehet csupán 1 órát várnod a hiányzó anyagra.

"A cégnél van VPN és arról elérhetőék a git repok, de nem akarok, illetve kényelmetlen minden fityfenét állandóan kommitolni + pusholni, így ez szinkronizálni nem az igazi."

Ezeken mindig kicsit megrökönyödök, hogy vannak olyan helyek még, ahol a VPN szitokszónak számít mert lassú és macerás a használata.
-------------------------
Hivatásos pitiáner
neut @

Titkosítatlan oprendszer, titkosított konténer.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Idézet:
Másrészt ez feltételezi azt, hogy előre tudni fogom hogy mik azok a könyvtárak amiben bizalmas adatok vannak, és hogy ez időben nem változik, és garantáltan nem tévedek benne.

Mondjuk erre könnyen választ ad a vonatkozó standard (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf). Ami az OS része, ott biztos nem lehet. Ami a változó adatok területe, ott lehet. Ha nem használsz helyi szolgáltatást a dolgaid alternatív tárolására, akkor jó közelítéssel a home alatti dolgok kellenek neked.

Mondjuk a többi részre ez nem ad választ, mivel ha nem zárt a bekapcsolás pillanatától a lánc, akkor mindig van olyan elem, ami illetéktelen módosításával támadható a rendszer. (Erre a problémára született a secure boot.) Esetleg két kulccsal két LUKS partícióval tudnám ezt elképzelni: egyik a home partició, amit mondjuk a pam modulon keresztül bejelentkezéskor oldasz fel, meg egy rendszer partíció, aminek a kulcsát a tpm modulban tartod, így az OS fel tud bootolni róla. Meg egy secure boot se árt (ha rendelkezik az uefid saját kulcstárral).

Zavard össze a világot: mosolyogj hétfőn.

KVM over IP, amit esetlegesen bekapcsolsz egy remote managed tappal :)

Valami ILO megoldás? Távolról át tudod venni a konzolt.