Impulzus

 
A Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Hallgatói Képviseletének lapja
Random cikkajánló

Fejezetek az Izland-expedíció naplójából

Törd át korlátaid!

"Nem, nem akartam öngyilkos lenni ..."

Extrapoláció

"Pentium MCMLXXXIV"

Kéri András (nessie), II. Info.

SCHinema

Kedves TDK-zó Hallgatók!

Karriertörténet

Bemutatkozik a Vackor Család

A mostani és a jövő félévre már vannak konkrétabb elképzeléseink. Az idei Qpán a színdarabok között néhány Monty Python jelenetet fogunk előadni, majd november végén, a Kultúr Reszort fesztiválján is szeretnénk egy vagy két előadással fellépni.

Pozitívan gondolkodom...

2003-as rendezvénynaptár

ÚjVár, Táncklub, Banális és a többiek.

Privát szféra

A nemzetközi helyzet fokozódik. Manapság elég egy nagyon komoly névtelen feljelentés ahhoz, hogy az ajtónkon kopogtassanak az illetékesek, és elvigyék a számítógépünket az összes adathordozónk társaságában. A világháló tele van rémtörténetekkel, melyek az eljáró hatóságok hihetetlen hozzá nem értését és rugalmatlanságát ecsetelik. Ki ne hallott volna olyan "szakértőkről", akik a lefoglalt gépeken talált őskövület típusú programok miatt is képesek több tízezer forintos büntetési tételeket szülni?

Persze nem csak rossz példák léteznek: a legutóbbi, nagy port kavart eset (amely egy cégvezető körül forog, aki akár 1 év börtönt is kaphat, mert illegális szoftvereket használtak a munkatársai) néhány dologban újdonsággal szolgál. A monitorokat például már nem viszik el a rendőrök. :)

Nem egy ismerősömnek lopták már el a számítógépét: igen kellemetlen, ha a bankszámlánkról elutalják külföldre az összes pénzünket, csak mert a kedvenc böngészőnk megjegyezte a jelszavakat.

Mit tehetünk annak érdekében, hogy a saját adataink kizárólag általunk legyenek elérhetőek, és csak tőlünk függjön, hogy pontosan ki és mikor tekinthet bele a merevlemezünk tartalmába? Ehhez szeretnék néhány tanácsot adni. Elsősorban linuxos módszerekről lesz szó, de az ötleteket minden bizonnyal tetszőleges más rendszereken is meg lehet valósítani.

Fontos megjegyezni, hogy valószínűleg illegális alkalmazása is van az itt leírtaknak (mint bármi más hasznos dolognak, ugye). Természetesen nem az a célunk, hogy ezt támogassuk, sokkal inkább a privát információ védelme, úgymint:

  • magánlevelezések;
  • saját programok, forráskódok, egyéb szellemi termékek;
  • digitális fényképek;
  • szoftvergyűjtemények (elavult programok, shareware alkalmazások, szabad szoftverek, valamint kereskedelmi programok biztonsági másolatai);
  • jelszavak;
  • rendszermentések (melyek bármelyik fenti tételt tartalmazhatják).

Kódolt file-rendszer

Mit sem ér a legbiztonságosabb operációs rendszer és a gondosan kiépített jogosultsági rend, ha a géphez fizikailag hozzá lehet férni. Ezt a lehetőséget sosem zárhatjuk ki!

A megoldás a kódolt fájlrendszer: minden adat kódolt állapotban legyen lemezen, olvasáskor a rendszer kódolja ki, íráskor kódolja be. A folyamat legyen átlátszó, minden program változtatás nélkül működjön. A bűvös kód sehol ne legyen leírva, azt kizárólag billentyűzetről adjuk meg minden rendszerindításkor!

Linux alatt mindez már régóta működőképes, ráadásul olyan elegáns módon, hogy még a megszokott file-rendszerünket sem kell lecserélni, mert bármelyik "alá" beépíthetjük a kódolást.

Nézzük, mi minden kell, ha stabil, 2.4-es megoldást szeretnénk (ha jól tudom, a 2.5-ös kernelben minden benne van):

  • patch-int-2.4.18.0 (international patch a kernelhez, lásd amerikai exportkorlátozás);
  • loop-hvr-2.4.18.0 (a loopback device kiegészítése néhány alapvető dologgal, amelyek furcsa mód nincsenek benne a hivatalos verzióban);

Nagyon fontos, hogy multiprocesszorosra fordítsuk a kernelt! Elvileg semmi értelme nincs, de tapasztalataim szerint SMP támogatás nélkül nem fordul le a kernel, ha a fenti patch-eket rárakjuk. Jelöljünk be minden fontosat, ami a Crypto API menü alatt van a menuconfig-ban!

Miután bebootoltunk az új kernellel, csináljunk egy akkora /cryptfile-t dd-vel, amekkora kódolt fájlrendszert akarunk, majd próbáljuk ki a következőt:

# losetup -e blowfish -k 256 /dev/loop0 /cryptfile

A parancs jelszót kér. Figyeljünk arra, hogy mit adunk meg, mert utólag nem lehet módosítani! Mondanom sem kell, hogy ne a születési dátumunk legyen... Ne spóroljunk a jelszóval, legalább 15 karakternyi kisbetűt, nagybetűt, számot, extra karaktert használjunk el a biztonság érdekében!

# mkfs -t ext2 /dev/loop0; mount /dev/loop0 /mnt

Ezután kedvünkre mountolhatjuk ki/be a kódolt file-rendszerünket, a jelszó egészen addig érvényes, amíg losetup -d-t nem mondunk.

Kódolt root partíció

A Crypto API olyan stabil és gyors, hogy akár a root partíció is kódolt lehet, az operációs rendszer akkor is megfelelő sebességgel teszi a dolgát. Érezhető lassulást csak nagy adatmennyiség mozgatásánál tapasztalhatunk. Egyáltalán szükség van erre? Miért nem elegendő csupán a tényleg fontos adatok védelme? Ha nem kódolunk mindent, akkor a támadó, aki fizikailag hozzáfér a géphez, bebootolhat egy CD-ről, és biztonsági lyukat csempészhet a rendszerbe (például egy új felhasználót). Ekkor a tényleges adatlopás később történik meg, miután mi megadtuk a bűvös jelszót...

A szükséges lépések röviden (a részleteket bőségesen taglalják a megfelelő HOWTO-k):

  • Alakítsunk ki egy kicsi partíciót a /boot-nak;
  • Szerezzünk be egy initrd-t is a kernelünkhöz (például egy Linux install CD-ről), és alakítsuk át, hogy indításkor ne az installer induljon, hanem a mi losetup, mount parancsaink;
  • Tegyük az initrd-t és a kernelt a /boot partícióra, tegyük bootolhatóvá, csináljuk kódolt particiókat;
  • Másoljuk át az oprendszerünket a kódolt területre, és lehetőleg ne hagyjunk belőle kódolatlan verziót a gépen!

Egyre elterjedtebbek a naplózó file-rendszerek. Nagy előnyük, hogy jól tűrik az áramszünetet, kikapcsolást. Ha első nekifutásunkban egy ext3-at állítunk be a /dev/loop0-ra, akkor azt tapasztalhatjuk, hogy egyáltalán nem szereti a resetet, minden szabálytalan leállítás után sokáig szöszmötöl a helyreállítással. Ennek az az oka, hogy a loopback device is cache-el! A journal fájlt kénytelenek leszünk máshova, mondjuk a /boot-ra rakni. Paranoiások, vigyázat! A journal fájlban is lehet privát információ!

Virtuális gép

Mit tegyünk, ha más, kevésbé kezelhető vagy megbízható operációs rendszereket szeretnénk ugyanígy védeni? Installáljunk VMware-t egy kódolt partícióra!

Megtehetjük, hogy a virtuális gép is szolgáltasson a hálózaton: használjuk a VMware által felkínált IP tartományokat (pl. 192.168.116.0/24), és a gazda gépen portforward szabályokkal irányítsuk be a szükséges csomagokat. A visszafele irány NAT-tal működhet. Akár el is rejthetjük a gazda gépet, ha lecsukjuk a saját szolgáltatásait, funkciója ekkor mindössze a kódolás lesz. Ha még azt is megoldjuk, hogy a virtuális gépből ne lehessen kitörni, akkor egészen a Mátrixban érezhetjük magunkat. :) Blokkoljuk a VMware felől a gazda felé a kapcsolatkezdeményező csomagokat, melyekre amúgy sincs szükség, nyilván nem a virtuális gépből akarjuk elérni saját magunkat.

Természetesen a hálózati kapcsolatainkat is célszerű titkosítani, és itt nem csak egy szimpla SSH-ra gondolok. Ha VPN-t használunk (Virtual Private Networking), a külső megfigyelő még azt sem fogja tudni megtippelni, hogy milyen típusú forgalmat bonyolítunk. Sok-sok TCP/IP kapcsolatot belekódolhatunk egyetlen adatfolyamba. Tömörített adatfolyammal akár még a sávszélességünket is növelhetjük. :)

Bereg