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

Fórumok

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ások

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 @

É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)

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

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.

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. */

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!

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.

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

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.

a) opció: remote management, KVM, Intel AMT - itt ugye arról van szó, hogy még a bootolás folyamatában a konzolt el tudod érni, és be tudod pötyögni a jelszót - ehhez általában Q-szériás chipset szokott kelleni, ami desktop gépen ritka, mint a fehér holló, plusz kell valami jumphost-szerűség (mondjuk ez lehet a router), amire távolról belépsz pl. ssh-n vagy valami VPN-en keresztül, és amiről aztán LAN-on el tudod érni a gépet, mivel ezt az Intel AMT-t épeszű ember ki nem rakja a netre közvetlenül elérhető formában, mert akkora fos biztonságilag,

b) opció: kétlépcsős bootolás - először feljön az OS jelszó nélkül (vagy TPM-ből feloldva a jelszót), oda be tudsz távolról lépni ssh-val, aztán kézzel felmountolsz egy másik fájlrendszert, és az már lehet jelszóvédett - itt ugye az a csel, hogy minden fontos dolgot az utóbbi helyre kell rakni (pl. lehet egyszerűen a /home ez a fájlrendszer, csak azt kell megoldani, hogy legyen hová belépni addig is, amíg nincs /home).

Csodalkozom, hogy meg senki nem irta, ugyhogy biztos van vele vlami gond. Anno amikor erre merult fel igenyem, ezt ugy csinaltam, hogy kulon lemezen volt az elsodleges userem home konyvtara, ami titkositva volt, es volt egy masodlagos user, aminek csak annyi dolga volt, hogy leven az o homeja nem titkositott lemezen volt, be tudtam vele lepni ssh-n, es kezzel felmountolni a particiot. Ja, igen, hazi szerver volt, ezert ssh-n leptem be, es viszonylag ritkan kellett, de desktoppal is megoldhato, csak macera.

De ha quick and dirty eleg, akkor nem hibernalas, hanem sleep kell neked. Hibernalasnal imho ugyan ugy kerne a jelszot.