Szeretnek megvalositani titkositott root file rendszert tavoli gepen, pontosabban hogy minden olyan resz amiben erdemi adat, konfig stb lehet azok kodolva legyenek, de ugyanakkor ujra tudjam inditani tavolrol is a gepet optimalis esetben es lehetoleg csomagbol legyenek felteve az alkalmazasok es ha mar pofatlan akarok lenni akkor debian (szeru) rendszer legyen. :)
Amikre gondoltam, h teljes titkositott particiok, ezesetben nem problema a csomagbol felrakni dolgokat vagy h mit hova tesz, igazabol a gondot csak az ujrainditas megoldasa okozza, ami viszont eleg lenyeges hiba lehet.
Masik megoldas amire gondoltam, h root, etc, usr nincs kodolva es a problemas konfigokat meg amik veluk jar beallitom mindenben h mashol van amit hasznaljon, ez kevesbe jar gonddal restart eseten, viszont idovel sokmindenre kell figyelni h mashova tegye, egy esetleges csomagfrissites netan modosithatja a konfigot amiben le van irva mi hol van...
Harmadik megoldasnak gondoltam olyat, h kulon particio problemas konfigoknak es tarsainak amire nem atirnam h onnan dolgozzon, hanem csak symlink-el atlinkelnem az eredeti helyere, igy csomagfrissites eseten (csak kititkositott particiok eseten lenne errol szo) nem irna felul olyat amit nem kellene, viszont meg lenne a lehetosege 1-2 alkalmazasnal h mig nem kodolom ki azt amin az adatok vannak addig megprobalna restart eseten elindulni az alkalmazas es ha nem talal konfigot vagy logfile-t csak semmire mutato linket akkor legeneralja magatol ujonnan.
Kinek mi a velemenye vagy milyen egyeb otletei vannak?
U.I.: bar bizok benne ennek nincs kulonosebb jelentosege, de mindezt sw-es raid1-en kellene megvalositani :)
- 1933 megtekintés
Hozzászólások
Nem debian, de esetleg Devil linux + hardware-esen titkosithato pendrive?
- A hozzászóláshoz be kell jelentkezni
Ez kb ugyanaz mintha kulon valasztanam azokat a particiokat titkositva amik problemasak, max teljesitmeny romlas, emelett stabilitas vesztes is h pendrive-ot terheljek, es ha mar van 2 vinyo a gepben minek vegyek melle meg 2 pendrive-ot is?
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Lehet az is, hogy a pendrive-on csak egy kulcsfájl lenne, amivel meg tudod nyitni a titkosított partíciót felcsatolás előtt. A kulcs ettől kezdve nem játszik szerepet.
Tudomásom szerint sw megoldásban gondolkodva 2 lehetőség van:
- a jelszót magad írod be indításkor, amit initrdbe tett script bekér és felhúzza a rootFS-t.
- a szitu ugyanaz, csak initrdben fel kell csatolni a pendrive-ot és a rajta lévő kulccsal nyitni a titkosított partíciót
Első nálad kiesett, másodiknak pedig nincs értelme, ha azt szeretnéd, hogy más ne férjen hozzá, mert ott van a pendrive a gépben. Max odaerősíted a salgó polchoz és ha viszik a gépet a pendrive kicsúszik, blab-bla, de vagy bejön vagy nem:)
Utolsó esetben olyat tudnék elképzelni, hogy rootFS titkosítatlan. Mezei fájlok elférnek ezen. Az általad féltve örzött configok pedig egy másik, titkosított partícion, amit te húzol fel minden restartot követően. Nyílván nem lesz belőle túl sok:)
- A hozzászóláshoz be kell jelentkezni
Az kb lenyegtelen szempont most h kulcs-al vagy jelszoval oldom-e meg a kodolast, a lenyeg h tavolrol lehessen kikodolnom akar ujrainditas utan is.
initrd-be tehetnek olyat is, h elinditson ssh-t vmi minimalis rendszerrel amire tavolrol belepve mar ki tudom kodolni a vinyokat es elinditani a teljes rendszert, de tapasztalatom nem sok van se ezzel se a reszleges titkositassal ezert kerdeznem h melyik jobb megoldas, melyikkel van kevesebb szivas, melyik stabilabb stb. ?
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Szerintem az "utolsó esetben..." kezdetű bekezdésem.
- A hozzászóláshoz be kell jelentkezni
Konkretan mi ellen vedene ez?
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Remelhetoleg semmi ellen, ez inkabb csak paranoia, mivel tavol vagyok a geptol szeretnem megnyugtatni magam vmi titkositassal, h akik helyileg elerik azok se nyulhatnak bele az adataimba es max olyat tudnanak lemasolni ami egyebkent barmelyik ures alaprendszerben benne van.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Hát paranoia ellen ez nem nyújt védelmet: ha a root filerendszert titkosítatlanul hagyod ("alaprendszer"), akkor egy livecd-vel nemcsak olvasni, hanem írni is tudják, ergo felülírhatják az indító scripteket, hogy küldje el nekik a jelszót, vagy telepítsen egy root backdoor-t...
Én is ilyen "paranoiás" vagyok, de aztán idővel mindig konszolidálódom, mert csak magamnak okozok felesleges fejtörést, adatvesztés-veszélyt. Nem a CIA és a földönkívüliek ellen kell védvonalakat kiépíteni, mert arra magánemberként nem vagy képes, hanem pl. lopás vagy BSA ellenőrzés esetén a jelszófileod/barátnőd képei ne kerüljenek illetéktelen kezekbe.
Ahhoz meg elég ez is: https://wiki.ubuntu.com/EncryptedPrivateDirectory
Blokkszint helyett filerendszer szinten, egy könyvtár és annak tartalma lesz titkosítva, hasonlóan az NTFS titkosított könyvtárához. És kapásból bejelentkezéssel automatizálható, nem kell trükközni a rendszerindításhoz.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Ahha. Akkor imho csinalj TPM-es trusted bootot, TPM-ben tartott kulccsal a rootfs-hez, es a tenyleges szenzitiv adatokat tartalmazo particiokat boot utan kezzel (ssh-n) mountold fel.
De ez sem tokeletes, mert:
- a futo gep memoriajabol ki lehet szedni a tenyleges fs-titkositasra hasznalt szimmetrikus kulcsot
- fizikai tamadasokkal szemben a TPM-eket sem keszitettek fel igazan
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
en serveren dmcryptet hasznalok. A rendszer nincsen titkositva, igy sshn szepen be tudom elesiteni reboot utan.
dmcryptnek van initrd-be rakhato cucca, amivel meg lehet oldani hogy rootfs-t is crypteled. Persze /boot-nak nem szabad encryptelve lennie. Bootkor ker jelszot, de biztos meg lehet oldani, hogy initrdbol huzol halozatot meg ssht, es akkor tavolrol is letre tudod hozni encyptelt particiot.
- A hozzászóláshoz be kell jelentkezni
Két lehetőség:
-Olyan vasat veszel, amiben van távoli konzol.
-Az alaprendszer csak egy vmware-t futtat, abban futnak a dolgaid külön OS-ben, ami alá olyan cryptofs-t raksz, amilyet akarsz. Távolról elérheted a konzolt, ergo be tudod írni a passphrase-t.
A helyben tárolt, automatikusan, emberi beavatkozás nélkül kinyitott cryptofs csak sz@rpofozás: a folyamatot ki lehet nyerni az initrd-ből, ergo livecd-vel le lehet játszani a folyamatot úgy, hogy a másik oldal kezében van a root-jogosultság.
A harmadik lehetőség meg unionfs-sel megcsinálni a /etc-t, és ahonnan a másik felét veszi, azt előtte cryptofs-ről húzza fel, plusz a teljes /home /opt, /srv meg amit akarsz utána jön fel manuálisan -- szintén cryptofs-ről.
- A hozzászóláshoz be kell jelentkezni
"-Az alaprendszer csak egy vmware-t futtat, abban futnak a dolgaid külön OS-ben, ami alá olyan cryptofs-t raksz, amilyet akarsz. Távolról elérheted a konzolt, ergo be tudod írni a passphrase-t."
Erre is gondoltam, de nemigazan van benne tapasztalatom milyen teljesitmeny romlassal jarna mindez, marmint h alap rendszerben futna az aktiv rendszer?
Xen-el meg van keves tapasztalatom, de hvm-et nem tud a proci a tobbi fele virtualizaciot meg nem ismerem igazan plane hvm nelkul meg teljesitmeny szempontjabol...
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Ha vm-be tennek titkositott rendszert, ugy h az az 1 vm lenne lenyegeben csak a rendszerben es minden lehetsegre allo eroforrast annak adni, akkor hogy lenne jobb, ha titkositott particiora (pl lvm-en belul) tennem a virtualizalt os-t ami a lenyegi dolgokat vegzi vagy inkabb normal particiora titkositva tegyem fel az os-t?
Vagyis a titkositast az alaprendszer vegezze vagy inkabb a guest, elvi es teljesitmenybeli kulonbsegek mennyire vannak, melyik virtualizacio lenne erre a legjobb h legkevesebb eroforrasveszteseggel jarna de stabil is lenne? Proci nem tud hardveres virtualizaciot es linux lenne alap ill. guest rendszer is.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Én a guest-en belül oldanám meg a titkosítást, így ugyanis a host-on magán nem kell bepötyögni passphrase-t, és így ott direktben nem lesz lelopható. (Igen, akkor is lelopható, ha kulcsos ssh-val mész be, némi trükközéssel hozzáhegeszthető a ttysnoop vagy valami hasonló cucc, aztán bimm-bamm...)
- A hozzászóláshoz be kell jelentkezni
Ha guest-en oldok meg teljes rendszer titkositast (marpedig ha teszem akkor amiatt teszem virtualizacioba elsosorban) akkor annak a kikodolasahoz (mivel helyileg nem tudok ott lenni) csak a host-on at juthatok el.
Vagy en maradtam le vmirol? :S
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Teljesen értelmetlen amit csinálsz. Ameddig fizikailag valaki hozzáfér a rendszerhez, addig akármekkora mélységben "rejted" virtuális gépek virtuális diszkjeire az adatot, sohasem lehetsz biztos, hogy amikor távolról beírod a passphraset, akkor ténylegesen közvetlenül a titkosító programmal, és nem csak egy trójaival beszélsz-e. Akinek fizikailag hozzáférése van, az bármikor felülírhatja ezt a felületet, hiszen a titkosítást végző alrendszernek nyilvánvalóan titkosítatlanul kell meglennie.
update:
Arra gondolok, hogy kiveszem a diszket/bedobok egy liveCD-t, így tudok bootolni egy független rendszert. Opcionálisan elindítom a virtuális gépet, és megfertőzöm egy alkalmas rootkittel/vírussal vagy csak felülírom a "biztonságos távoli mount" scriptet. Innentől fogva amint te legközelebb távolról aktiválod, a támadó is hozzáfér mindenhez a te észrevételed nélkül.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Azert kozel sem ertelmetlen, mert nem mind1 mifele hozzaferesrol van szo, ha vki hozzafer, nincsenek kodolva az adatok akkor siman lemasolhatja amit csak akar maganak megha nem is ert kulonosebben hozza vagy csak kivancsi viszont az mar teljesen masfajta megkozelites ha szandekosan leallitja azert h rootkit-et vagy hasonlot rejtsen el benne h lehallgathasson, megfigyelhessen, jelszavakat lophasson vagy amit akar. Ilyen ellen kb semmi nem ved vagy olyan esetleg olyan szintu paranoia ami csak nagyon keveseknek adatott meg, teszem azt nem tervezett leallas eseten aktivalodik a mini plasztik bomba, ha azt elore hatastalanitanak akkor a rendszer torolne onmagat stb. stb. stb.
En viszont olyanra gondoltam, h alap rendszerben virtualizalva fut a titkositott rendszer, optimalis esetben hetekig vagy honapikig se kell leallitani a host-ot, ha megis van nem tervezett leallas akkor meg elotte at lehet nezni h tortent-e vmi feltuno dolog.
Mindenesetre igaz, h ilyen szempontbol jobb lenne a guest-nek titkositva lenni, mert ha biztosabbra akarok menni akkor gyanu eseten migralom mashova a virtualis rendszert ami maga titkositva van, ezaltal ahhoz nem ferhetnek ilyenkor hozza es a mar migralt uj helyen levo vm-et nyugodtabban ellenorizhetem vagy akar korabbi gepen rendszer ujrarakas utan ujra vissza is tehetem kulonosebb nehezsegek nelkul...
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
"mert ha biztosabbra akarok menni akkor gyanu eseten migralom mashova a virtualis rendszert ami maga titkositva van, ezaltal ahhoz nem ferhetnek ilyenkor hozza"
Ez nem egeszen igy mukodik, pl. a vmware vm-ek kulon file-ban tartjak az nvram-jukat (plaintextben), meg eloszeretettel irkaljak ki diszkre a memoriajuk tartalmat (szinten plaintextben).
Akkor mar inkabb a vmware ACE-t nezd meg, de igazabol sibidiba -nak van igaza: ennek igy kulonosebben nincs sok ertelme.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Csak tudnam miert jon mindenki vmware-el?!?!?!
Nekem stabil rendszer kell, tisztan linux-al, grafikus feluletek nelkul. Xen-t kicsit ismerem, de abban amennyire tudom nincsenek ilyen hulyesegek, pl lvm particiokra dolgozik meg fizikai memoriaba es meg teljesitmenyben is jobb amire nekem kell...
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
A vmware-nek is adhatsz fizikai diszket/partíciót... A vmware akkor ír fizikai memóriaképet a diszkre, ha pause-t nyomsz -- legalábbis szerintem...
- A hozzászóláshoz be kell jelentkezni
Vagy ha snapshotolsz, vagy ha swap-elni tamad kedve, amit meg altalanos esetben nem olyan nehez elintezni, ha celzott tamadasban gondolkodik az ember.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
A swap megy a normál swapterületre, valóban, azt lehet szépen cryptofs-re rakni a host-oldalon (random kulcs hasnzálatával), snapshot-ra meg valóban nem ad megoldást a guest saját cryptofs-es mókája -- úgy tűnik, hogy a távoli konzol lesz az üdvözítő megoldás.
- A hozzászóláshoz be kell jelentkezni
Nem azt mondom, hogy titkosítani értelmetlen, nekem is van. Csak már iszonyatosan túlbonyolítottad. Fizikai védelem hiányában a blokk szintű titkosítással és virtuális gépekkel való vesződés helyett (az utóbbit nem is értem mire jó), az eCryptFS (https://wiki.ubuntu.com/EncryptedPrivateDirectory) ugyanolyan biztonságot nyújt, de:
- két kattintás belőhető bármilyen disztrón
- ugyanúgy kernelszintű
- nem kell az egész filerendszert titkosítani, elég a szenzitív adatokat tartalmazó könyvtárakat
- jobban skálázódik (nem gond ha át kell méretezni a partíciót)
- a bejelentkezés egybeköthető a titkosítás feloldásához szükséges autentikációval
- userenként saját kulcs a saját adatokhoz, központi kulcs helyett az összes adathoz
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
"Csak már iszonyatosan túlbonyolítottad"
Pedig ponthogy az egyszerusites s celom s virtualizacio otletevel, ugyanis ha a teljes rendszer kodolva van akkor nem kell vegignyalaznom minden konyvtarat es fajlt h problemas lehet-e, pl mysql adatok, konfigokban nehol plain text jelszavak, esetleg logokban is megjelenhetnek hasonlok. Szoval eleg sokminden lehet, ami idovel uj alkalmazasokkal, neha csak 1-1 csomag upgrade-el is bovulhet es folyamatosan nyomon kellene kovetni.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
A guest-ed szépen elérhető például ssh-n (ha beállítod), vagy vmware esetén https-en, konzolon. Így a host-on a vmware szervert kéne megbuherálni, hogy a vmware-es konzolon beírt dolgokat logolja le. Nem lehetetlen, de jóval nehezebb, mint a hoston az sshd-t megpatkolni egy ttysnoop-pal, vagy hasonlóval.
- A hozzászóláshoz be kell jelentkezni
1. amennyire neztem xen vagy virtualbox ami eselyes teljesitmeny szempontjabol nalam, mivel linux a host es guest is, ill. grafikus feluletre se igen van szuksegem, inkabb h hoston csak a legalapabb dolgok legyenek.
2. meg mindig nemigazan ertem hogy erem el magat a guest-et ha az teljesen titkositva van, az ugyebar nem tud elindulni mig nem oldom fel a titkositast vagy olyanra gondolsz h guest-et ugy erni el tavolrol h teszem azt webfeluleten kiadni, mint vmi konzolkepernyo (amolyan remote managemant kartya stilusban vagy ip alapu monitor switch modjara)?
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
A vmware-hez sem kell sem hos, sem guest oldalon grafikus felület. A host-on csücsül egy tomcat, a telepítéskor megadható portokon (http és https). Ezen keresztül böngészőből szépen el tudod érni a host-ot, a beállításokat, illetve egy pluginen keresztül a guest-ek konzolját.
- A hozzászóláshoz be kell jelentkezni
ha mar tavoli konzol, nincsen veletlenul mellette gep amit el tudsz erni, es van serial portja? Serial console tud mukodni, arra ki tudod tolni a grubot es a teljes linuxot.
- A hozzászóláshoz be kell jelentkezni