The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

Dokumentáció/SL9.3/Adminisztráció/Linux-rendszerek biztonsága

Icon-lock.png A hálózatokon belül az adatok, szolgáltatások és az adatátvitel biztonsága mindig is fontos kérdés volt és egyre inkább azzá válik. Ez a fejezet arról szól, hogyan lehet megelőzni a rendszer jogosulatlan elérését és hogyan lehet védekezni a kívülről jövő támadások ellen.

Tartalomjegyzék

Bevezetés

Egy tanúsítványkezelő hatóság (certification authority, CA) létrehozása után titkosítható a kommunikáció az egész hálózaton, olyan technikákkal, mint például a virtuális magánhálózatok (virtual private network, VPN). Más mechanizmusok, például a forgalom elfedése (masquerading), a tűzfalak (firewall), illetve a Kerberos, szintén használhatók az adatcsere és az általános adatforgalom szabályozására. A Secure Shell (biztonságos parancsértelmező, SSH) protokoll segítségével titkosított kapcsolaton lehet bejelentkezni távoli gépekre. A szigorúan műszaki utasítások mellett a fejezet szól a Linux alapú hálózatok általánosabb biztonsági megfontolásairól is.

Az elfedés (masquerading) és a tűzfal (firewall) szabályozzák az adatfolyamot és az adatcserét. A Secure Shell (biztonságos parancsértelmező, SSH) protokoll segítségével titkosított kapcsolaton lehet bejelentkezni távoli gépekre. A fájlok, vagy akár teljes merevlemez-partíciók titkosításával védhetők az adatok még akkor is, ha egy nemkívánatos személy hozzáfér a fájlrendszerhez. A szigorúan műszaki utasításokon túl az utolsó szakasz a Linux alapú hálózatok biztonsági megfontolásait tárgyalja.

X.509 tanúsítványok kezelése YaST-al

Egyre több hitelesítési eljárás alapul titkosítási eljárásokon. Ezért fontos szerepet játszanak azok a digitális tanúsítványok, amelyek a titkosítási kulcsokat a tulajdonosaikhoz rendelik. Ilyen tanúsítványok nem csak a kommunikációban használatosak, de megtalálhatók például vállalati beléptetőkártyákon is. A tanúsítványok készítését és felügyeletét általában »hivatalos« cégek látják el, amelyek ezt kereskedelmi szolgáltatás keretében végzik. Különböző esetekben azonban felmerülhet az igény, hogy ön saját maga vegye át ezt a feladatot, például, ha a cég nem akarja kívülállóknak kiadni a személyes adatokat.

A SUSE LINUX két YaST modult kínál erre a célra, amelyek alapvető felügyeleti funkciókat nyújtanak a digitális X.509 tanúsítványokhoz. A következő részekben betekintést nyújtunk a digitális tanúsítványok alapjaiba, és elmagyarázzuk, hogyan tudja a YaST segítségével elkészíteni és felügyelni tanúsítványait. Azonban a digitális tanúsítványok témaköre rendkívül összetett, ezért az alábbi leírás csak egy áttekintést nyújt. További információ:: http://www.ietf.org/html.charters/pkix-charter.html

A digitális tanúsítványok alapjai

A digitális tanúsítványok titkosítási folyamatokat használnak azon adatok titkosításához, amelyeket védeni kell az illetéktelen hozzáféréstől. A felhasználó adatai egy másodlagos adatbejegyzéssel, vagy más néven kulccsal kerülnek titkosításra. A kulcs matematikai úton előállított adattal titkosítja a felhasználó adatait, így az eredeti tartalom nem ismerhető fel. Napjainkban általában az aszimmetrikus titkosítást alkalmazzák (nyilvános kulcs alapú titkosítás). A kulcsok mindig párban állnak:
Privát kulcs
A privát kulcsot tulajdonosának biztonságos helyen kell tárolnia. Véletlen nyilvánosságra kerülése veszélyezteti a kulcspárt, és ezzel használhatatlanná teszi azt.
nyilvános kulcs
A nyilvános kulcsot tulajdonosa nyilvánosságra hozza.

Kulcshitelesség

Mivel a nyilvános kulcs eljárás széles körben elterjedt, számos nyilvános kulcs elérhető. A rendszer sikeres használatához elengedhetetlen, hogy a nyilvános kulcs biztosan a kijelölt felhasználóé legyen. A felhasználók és a nyilvános kulcsok egymáshoz rendelését hitelesítő szervezetek igazolják a nyilvánoskulcs-tanúsítás által. A tanúsítványok tartalmazzák a tulajdonos nevét, a megfelelő nyilvános kulcsot és a kibocsájtó elektronikus aláírását. A hitelesítő szervezetek általában egy tanúsító infrastruktúrához tartoznak, amely a tanúsítványok kibocsájtása, aláírása mellett egyéb tanúsítványfelügyeleti feladatokat is ellátnak. Ezek magukba foglalják a tanúsítványok publikálását, visszavonását és megújítását is. Az ilyen infrastruktúrát általábannyilvános kulcsú infrastruktúrának vagy PKI-nak nevezik. Közismert PKI-szabvány az OpenPGP, amelyben a felhasználók teszik közzé saját tanúsítványukat központi hitelesítés nélkül. Ezek a tanúsítványok akkor válnak hitelessé, ha a »bizalmi hálózathoz« (web of trust) tartozó külső hitelesítő aláírja őket.

A hierarchikusan szervezett X.509 nyilvános kulcsú infrastruktúra (PKIX) egy másik lehetséges modell, amelyet az IETF (Internet Engineering Task Force) szervezet határozott meg. Ez a mintája majdnem minden nyilvánosan használt PKI-nek. Ebben a modellben a hitelesítés hierarchikus fastruktúrában történik a tanúsítványhatóság (CA) által. A fa gyökerét a root CA jelenti, amely hitelesíti az összes alsóbb rendű CA-t, amelyek hitelesítik az alattuk levőket, mígnem a legalsó szintű kiállítja a tanúsítványokat. A felhasználói tanúsítvány akkor válik megbízhatóvá, ha egy hiteles CA írta alá. E megoldás hitelesítési láncolatának a végén a root CA áll.

Az ilyen PKI megoldások biztonsága a tanúsítányok hitelességén áll vagy bukik. Annak érdekében, hogy a tanúsítványkibocsátás zavartalan legyen, a PKI operátor meghatároz egy tanúsítványalkalmazási nyilatkozatot (certificate practice statement - CPS), amelyben meghatározza a tanúsítványkezelés folyamatát. Ezzel biztosítható, hogy a PKI kizárólag megbízható tanúsítványokat állítson elő.

X.509 tanúsítványok

Egy X.509 tanúsítvány számos állandó mezővel és opcionális kiegészítésekkel rendelkező adatstruktúra. A fix mezők tartalmazzák a tulajdonos nevét, a nyilvános kulcsot és a kibocsátó CA adatait (nevét és aláírását). Biztonsági okokból a tanúsítványok csak meghatározott ideig érvényesek, tehát egy dátummező is található bennük. A CA garantálja a tanúsítvány érvényességét a megadott időszakra. A CPS általában kiköti, hogy a PKI (illetve konkrétan a CA) a lejárati határidő előtt készítsen és küldjön szét új tanúsítványt.

A kiegészítések bármiféle járulékos információt tartalmazhatnak. Az alkalmazásnak nem kell figyelembe vennie a kiegészítéseket, hacsak nincs kritikusként megjelölve. Ha egy alkalmazás egy kritikus kiegészítést nem ismer fel, el kell utasítania a tanúsítványt. Egyes kiegészítések a tanúsítvány használatát néhány alkalmazásra, például aláírásra vagy titkosításra korlátozhatják.

X.509v3 tanúsítvány ismerteti az X.509 tanúsítvány 3-as változatának alapelveit.


Táblázat: X.509v3 tanúsítvány
Mező Tartalom
Verzió A tanúsítvány verziója - például "v3"
Sorozatszám Egyedi tanúsítványazonosító (egész szám)
Aláírás A tanúsítvány aláírásához az algoritmus azonosítója használható.
Kiállító A kiállító hatóság (CA) egyedi neve (DN)
Érvényesség Az érvényesség időtartama (tól...ig)
Cím A tulajdonos egyedi neve (DN)
A nyilvános kulcs A tulajdonos nyilvános kulcsa és az algoritmus azonosítója
A kiálító egyedi azonosítója (Unique ID) A kiállító CA egyedi azonosítója (opcionális)
A tulajdonos egyedi azonosítója A tulajdonos egyedi azonosítója (Unique ID) - opcionális
Kiegészítések Egyéb opcionális információ, például »Kulcshasználat«, »Kikötések« stb.

X.509 tanúsítványok letiltása

Ha egy tanúsítvány az érvényességi időn belül megbízhatatlanná válik, azonnal le kell tiltani. Ez szükséges lehet például olyan esetben, amikor a privát kulcs nyilvánosságra került. Különösen akkor, ha a privát kulcs a CA-hoz tartozik, és nem egy felhasználói tanúsítványhoz. Ebben az esetben az összes felhasználói tanúsítványt, amelyet a CA kiállított, azonnal le kell tiltani. Amennyiben egy tanúsítvány letiltásra került, a PKI-nak (illetve a felelős CA-nak) azonnal értesítenie kell a használókat. Az ehhez használt eszköz a tanúsítvány-visszavonási lista (certificate revocation list - CRL).

Ezt a listát a CA készíti a CRL elosztási helye (a CDP-k) számára megadott időnként. A CDP opcionális attribútumként felvehető egy tanúsítványba, így a használó ellenőrizheti a tanúsítvány hitelességét, valamint, hogy nem került-e visszavonásra. Egy lehetséges megoldás az ellenőrzésre azonline tanúsítványstátusz protokoll (online certificate status protocol - OCSP). A CRL listák hitelességét a kibocsájtó CA aláírása szavatolja.X.509 visszavonási lista (CRL) ismerteti az X.509 CRL alapjait


Táblázat: X.509 visszavonási lista (CRL)
Mező Tartalom
Verzió A CRL verziója (pl. v4.2)
Aláírás A CLR aláírásához használt algoritmus azonosítója (ID)
Kiállító A CRL lista kibocsájtójának (általában a CA-nak) egyedi neve (DN)
Frissítés ideje A CRL publikációjának ideje (dátum és idő)
Következő frissítés A következő CRL frissítés ideje (dátum és idő)
A visszavont tanúsítványok listája Minden bejegyzés tartalmazza a tanúsítvány sorozatszámát, a visszavonás idejét és az opcionális kiegészítéseket.
Kiegészítések Egyéb CRL kiegészítések


A tanúsítványok és CRL-ek tárolása

Használatukhoz a tanúsítványoknak és a CRL listáknak nyilvánosan elérhetőknek kell lenniük. Ez tárolót (repository) igényel. Mivel a tanúsítványok és a CRL-ek nem hamisíthatók, az aláírásoknak köszönhetően a tárolót nem szükséges különösen védeni. Ellenkezőleg, a lehető legegyszerűbb és leggyorsabb elérés biztosítása a cél. Ezért a tanúsítványok általában LDAP vagy HTTP kiszolgálókon keresztül érhetők el. Bővebb információ:LDAP – címtárszolgáltatás mindenkinek. A Az Apache webszerver a HTTP kiszolgálóról tartalmaz információkat.

Saját PKI

A YaST tartalmazza az alapvető eszközöket az X.509 tanúsítványok kezeléséhez. Ez főként a CA-k, alárendelt CA-k és tanúsítványaik készítését foglalja magába. Itt kell megjegyezni, hogy a PKI szolgálatásai messze túlmutatnak a tanúsítványok és CRL-ek készítésén és terjesztésén. Egy PKI üzemeltetéséhez komoly, átgondolt adminisztrációs infrastruktúra szükséges. A tanúsítványok és CRL-ek folyamatos frissítése igen komplex felügyeletet igényel, amit a kereskedelmi PKI termékek biztosítanak és részben automatizálnak. A YaST jelenleg nem képes ezeket a háttérinformációkat biztosítani a tanúsítvány és CA kezelésekor, készítésekor. Általában a nyílt forráskódú PKI termékek kisebb tudásúak a kereskedelmi változatokénál. »Kisméretű« PKI felállításához használhatja a YaST modulokat az alábbiakban leírtak szerint. Azonban egy»hivatalos«megoldáshoz kereskedelmi verzió szükséges: —vagy akár a kereskedelmi —PKI.

YaST CA felügyeleti modulok

A YaST két modult biztosít az alapvető CA felügyelet ellátására. A két modul funkcióját az alábbiakban tárgyaljuk fő funkciójuk szerint.

Root CA készítése

PKI készítéséhez az első lépés mindig a root CA elkészítése. Ez a YaST vezérlőközpontban a Felhasználók és biztonságCA kezelés menüpontból érhető el. Miután a modul elindult, látható a már meglévő CA-k listája. A Root CA készítése megnyitja az első három párbeszédablakot, ahol beírhatjuk a CA készítéséhez szükséges információkat.

Adja meg a CA készítéséhez szükséges alapadatokat az első párbeszédablakban, az alábbiak szerintYaST CA modul—Alapadatok a Root CA készítéséhez. Az Általános név mezőben adja meg a nevet, amellyel a CA-ra hivatkozik. CA neve mezőben kell megadnia a CA hivatalos nevét. Több más dolog mellett például a könyvtárnevek ebből a névből származnak, ezért kizárólag a súgóban meghatározott karakterek használhatók. Ez a név jelenik meg az összefoglalóban is, amikor a modul elindul. Több elektronikus levélcím is megadható, amelyeket a CA felhasználói láthatnak. Ez hasznos lehet az érdeklődőknek. Adja meg az országot, ahol a CA üzemel: Ország.

YaST CA modul—Alapadatok a Root CA készítéséhez

A Következőgombra kattintás után adja meg a jelszót a második párbeszédablakban.Ez a jelszó mindig szükséges a CA használatakor – alárendelt CA és tanúsítvány készítéséhez. A Kulcshosszalapértelmezésként tartalmaz egy használható értéket, amelynek megváltoztatása nem feltétlenül szükséges, kivéve, ha egy alkalmazás nem tudja kezelni ezt a kulcsméretet. Az Érvényesség ideje CA esetén 3650 nap (körülbelül 10 év). Ez a hosszú időtartam érthető, hiszen egy CA lecserlése, törlése számos adminisztrációs ráfordítást igényel. A Kiterjesztések gombot választva egy párbeszédablak jelenik meg, ahol az X.509 attribútumkiterjesztések adhatók meg (YaST CA modul – bővítések beállítása). Ezek az értékek megfelelő alapértékeket tartalmaznak, és csak akkor változtassa meg, ha valóban tudja, mit kell beállítani.

A harmadik és egyben utolsó lépésként a YaST ismerteti a jelenlegi beállításokat, és megerősítést vár. A Készítkiválasztásakor a root CA elkészül, és megjelenik az áttekintésben:

Icon-info.png Ötlet:

Általánosságban ajánlott tiltani felhasználói tanúsítványok kibocsátását a root CA-n. Érdemes legalább egy alárendelt CA-t készíteni egy leválasztott, biztonságos környezetben - például egy szeparált, megbízható számítógépen. Ez nagyon megnehezíti a root CA megtámadását.

Alárendelt CA készítése és visszavonása

YaST CA modul - a CA használata
Az alárendelt CA-t ugyanúgy készítjük, mint a root CA-t, azzal a különbséggel, hogy először ki kell választani a CA-t, amely tartalmazza az alárendelt CA-t. Miután a program elindult, válassza a szükséges CA-t a listából, és nyomja meg a CA megadása gombot. Ha ez az első alkalom, amikor a CA kezelést használja, adja meg a jelszót, ami után eljuthat a párbeszédablakhoz, ahol a CA kulcsinformációi megjelennek. (YaST CA modul - a CA használata). Válassza a Bővítések..., alárendelt CA készítéseopciót. Ez ugyanazt a párbeszédablakot nyitja meg, mint a root CA készítésekor.
Icon-info.png Ötlet:

Az alárendelt CA érvényességi idejének teljes mértékben a szülő CA érvényességi idején belül kell lennie. Mivel az alárendelt CA mindig a szülő CA utánkészül, a hibás értékek hibaüzenethez vezetnek. Ennek elkerülésére adjon meg korrekt értéket az érvényességi időhöz.

Miután kiválasztotta a tanúsítványokat, lépjen át a párbeszédablakba, amelyben a CA-tanúsítványokat és alárendelt CA-kat kezelheti. Kapcsolja ki a nem kívánt (vagy veszélyeztetett) alárendelt CA-kat a Visszavonák gombbal. A visszavonás azonban nem elég az alárendelt CA kikapcsolásához. A CRL-be szintén publikálni kell a kikapcsolt alárendelt CA-t. A CRL készítési folyamatának leírása: CRL lista készítése.

Felhasználói tanúsítványok készítése és visszavonása

Kliens- és kiszolgálótanúsítványok készítéséhez először adja meg a CA-t (Alárendelt CA készítése és visszavonása). A felhasználói tanúsítványokat lehetőség szerint mindig az alárendelt CA-n készítsük, hogy a root CA-t biztonságban tudhassuk. A Tanúsítványok... kiválasztása után megjelenik a tanúsítványok adminisztrálásához szükséges párbeszédablak: A CA tanúsítványai. A felső rész tartalmazza a már meglevő tanúsítványokat, míg a kiválasztott tanúsítványokra vonatkozó adatok alul láthatók.

A Hozzáadás segítségével új kliens- és kiszolgálótanúsítványokat készíthetünk, adhatunk hozzá a CA listájához. Az adatok rögzítése igen hasonló a CA készítéséhez, és ugyanazok a szabályok érvényesek a tanúsítványokra is. Az elektronikus levélcím különösen fontos azon tanúsítványok esetén, amelyek elektronikus levelek aláírására, titkosítására készülnek. Aláírás esetén a tanúsítványnak tartalmaznia kell a küldő (a privát kulcs tulajdonosa) elektronikus levélcímét, hogy a megfelelő tanúsítvány a levelezőprogramban hozzárendelhető legyen. Titkosításhoz használt tanúsítvány hozzárendelésénél a fogadó (a nyilvános kulcs tulajdonosa) elektronikus levélcímét kell elhelyezni a tanúsítványban. Kiszolgálótanúsítványok esetén ezenfelül meg kell adni a kiszolgáló nevét az Általános név mezőben. A tanúsítványok alapértelmezett érvényessége 365 nap.

Icon-info.png Ötlet:

Amennyiben IPsec alapú alkalmazásokhoz kell tanúsítványokat készíteni Windows XP környezetben, olyan kliens tanúsítványt kell használni, amelynek van egy Kulcshasználat kiterjesztése, amely tartalmazza a Windows által elvárt értékeket.

A Visszavonás szolgál a nem szükséges vagy veszélyeztetett tanúsítványok törlésére. A visszavonás azonban nem elegendő a tanúsítványok kiiktatásához. A visszavont tanúsítványokat meg kell hirdetni a CRL segítségével. A CRL készítésének leírása a CRL lista készítése részben található. A visszavont tanúsítványok a CRL-ben történő közzététel utántörölhetőkteljesen.

A CA tanúsítványai

Alapértelmezett adatok megváltoztatása

Az előző részben ismertettük, hogyan tud alárendelt CA-t, kliens- és kiszolgálótanúsítványokat készíteni. Speciális beállítások használata szükséges az X.509 tanúsítványok kiterjesztéseinek használatához. Ezek a kiterjesztések előre definiált értékekekkel rendelkeznek minden tanúsítványtípusra, és normál körülmények között ezek módosítása nem szükséges. Néhány speciális alkalmazás azonban igényelheti ezek módosítását. Amennyiben ilyen alkalmazások részére gyakran készít tanúsítványokat, érdemes az alapértelmezett értékeket átállítani, különben minden egyes tanúsítványnál külön kell módosítani ezeket.

A rendszer több alapértelmezett beállítást tartalmaz minden CA, alárendelt CA, kliens- és kiszolgálótanúsítvány készítéséhez. Az alapértékek megváltoztatásához adja meg a kívánt CA-t az alábbiak szerint:Alárendelt CA készítése és visszavonása. Miután kiválasztotta a bővítésekmenüpontot, itt megtalálja az alapértelmezett beállítások opciót, ahol kiválaszthatja, melyik értéket kívánja módosítani. Ezek után megjelenik az alapértékeket tartalmazó párbeszédablak:YaST CA modul – bővítések beállítása.

YaST CA modul – bővítések beállítása

A rendszer által ismert bővítések fastruktúrája a képernyő bal oldalán tekinthető meg. Ha kiválaszt egy mezőt, a hozzá tartozó érték megjelenik a jobboldalon, ahol beállíthatja vagy törölheti az értéket, majd törölje ki a »kritikus« jelölést. A Következő gomb lenyomása után megtekinthet egy rövid összefoglalót és elmentheti a beállításokat a Mentésgombbal.

Icon-info.png Ötlet:

Minden alapérték-módosítás csak a módosítás után készült objektumokra érvényes. A módosítás a már meglévő CA-kat és tanúsítványokat nem érinti.

CRL lista készítése

Nem elég a veszélyeztetett vagy megbízhatatlanná vált tanúsítványokat törölni, vissza is kell vonni őket. Az alábbi leírások ismertetik a folyamatot: Alárendelt CA készítése és visszavonása (alárendelt CA) ésFelhasználói tanúsítványok készítése és visszavonása (felhasználói tanúsítványok). Ezek után a CRL-t el kell készíteni és az információkat közzé kell tenni.

A rendszer minden CA-hoz precízen nyilvántart egy CRL-t. A CRL készítéséhez, frissítéséhez válassza ki a CA-t (Alárendelt CA készítése és visszavonása) és kattintson a CRL gombra. A következő párbeszédablakban a CA utolsó CRL-jéről készült összefoglalóját tekintheti meg. Amennyiben visszavont alárendelt CA-kat vagy tanúsítványokat a lista készülte óta, készítsen egy újat, így a változások hozzáfűzésre kerülnek. CRL készítéséhez vagy frissítéséhez nyomja meg a CRL készítése gombot. .Ezek után adja meg az új CRL érvényességi idejét (alapértelmezés 30 nap), majd nyomja meg az OK gombot a CRL elkészítéséhez és megjelenítéséhez. Ezek után közzé kell tenni a CRL-t.

Icon-info.png Ötlet:

A CRL-t használó alkalmazások elutasítják azokat a tanúsítványokat, amelyek a CRL-ben szerepelnek. PKI-szolgáltatóként az Ön feladata, hogy mindig készítse el és tegye közzé a legújabb CRL listát, mielőtt a régi lejár (érvényességi ideje lejárta előtt). A YaST jelenleg nem rendelkezik a funckió automatizálására szolgáló megoldással.

CA objektumok exportálása LDAP protokollon keresztül

A YaST LDAP klienssel elő kell készíteni a végrehajtó számítógépet LDAP exportra. Így futási időben elérhetővé válnak LDAP kiszolgálóinformációk, és ezek használhatók a párbeszédablakok automatikus kiegészítésére. Az LDAP export lehetséges egyéb esetben is, azonban az LDAP adatokat kézzel kell beírni. Mindig több jelszót is be kell írni (bővebb információ: LDAP exportálás közben szükséges jelszavak).


Táblázat: LDAP exportálás közben szükséges jelszavak
Jelszó Jelentés
LDAP jelszó A jelszó hitelesíti a klienst, hogy képes legyen objektumok létrehozására az LDAP címtárfában.
tanúsítványjelszó A jelszó hitelesíti a felhasználót, hogy ki tudja exportálni a tanúsítványt.
Új tanúsítványjelszó PKCS12 formátum használatos LDAP export közben. Ez a formátum kikényszeríti egy új jelszó hozzárendelését az exportált tanúsítványhoz.


Tanúsítványok, CA-k,és CRL-ek exportálhatók LDAP protokollon keresztül.

CA exportálása LDAP-n keresztül
CA exportálásához adja meg a CA-t, az alábbiak szerint: Alárendelt CA készítése és visszavonása. Válassza ki a KiterjesztésLDAP exportálás menüpontot, majd a következő ablakban adja meg az LDAP adatokat. Ha a rendszere YaST-al került konfigurálásra, a mezők automatikusan kitöltésre kerülnek. Ellenkező esetben minden adatot kézzel kell megadnia. A bejegyzések a »caCertificate«attribútummal lesznek kibővítve.
Tanúsítvány exportálása LDAP-n keresztül
Adja meg az exportálandó tanúsítványt tartalmazó CA-t, majd nyomja meg a Tanúsítványok gombot. Válassza ki a szükséges tanúsítványt a tanúsítványlistából a párbeszédablak felső részéből, majd az ExportálásLDAP exportálás menüpontokat. Az LDAP adatokat itt is meg kell adni, mint a CA exportálásánál. Ezek után a megfelelő felhasználói objektum kikeresésre kerül és ki lesz bővítve a »userCertificate« (PEM formátum) és »userPKCS12« (PKCS12 formátum) attribútumokkal.
CRL lista exportálása LDAP-on keresztül
Adja meg a CRL-t tartalmazó CA-t, amelyet exportálni kíván és válassza ki a CRL...opciót. Amennyiben szükséges, készítsen egy új CRL-t, majd exportálja a ExportálásLDAP formátumbaopcióval. Az LDAP információkat itt is meg kell adni a CA-hoz hasonló módon. Ezek után az LDAP bejegyzések létrejönnek ugyanazon a ponton, mint a CA, de a »certificateRevocationList« attribútumot használva.

CA objektumok exportálása fájlba

Amennyiben beállított egy CA-adminisztrálási lerakatot a számítógépen, ezzel az opcióval hozhatja létre a megfelelő CA objektumokat a megfelelő helyeken, közvetlenül fájl formájában. Különböző formátumok használhatók, például PEM, DER vagy PKCS12. PEM formátum esetén kiválaszthatja, hogy el kívánja -e menteni a kulcsokat, illetve, hogy a kulcsok titkosítottak legyenek -e. PKCS12 formátum esetén lehetséges a tanúsítvány-útvonal exportálása is.

A tanúsítvány CA és CRL fájl formátumba történő exportálása ugyanúgy történik, mint az LDAP export (CA objektumok exportálása LDAP protokollon keresztül), kivéve, hogy aFájlba exportálás parancsot kell választani azLDAP exportálás helyett. Ezek után megjelenik a párbeszédablak, ahol kiválaszthatja a kimeneti formátumot, és beírhatja a jelszót és a fájl nevét. A tanúsítványok ezután a megfelelő helyre kerülnek elmentésre az OKlenyomására.

Icon-info.png Ötlet:

Bármely tárolási helyet kiválaszthat a fájlrendszeren. Ez a parancs használható például CA objektumok USB meghajtóra exportálásra is.

Tanúsítványok exportálása hajlékonylemezre

A YaST lehetővé teszi tanúsítványok exportálását hajlékonylemezre. CA-k és CRL listák azonban nem exportálhatók hajlékonylemezekre. Ez a megoldás gyakori megoldás kiszolgálótanúsítványok átmásolására egy elszigetelt CA számítógép és egy kiszolgáló között. Ez a YaST funkció párja annak a speciális YaST modulnak, amely kizárólag az ilyen módon exportált tanúsítványok importáláshoz készült (lásd a következő szakaszban).

Hajlékonylemezre exportáláshoz először adja meg a CA-t, amely tartalmazza az exportálandó tanúsítványokat, majd válassza a Tanúsítványokmenüpontot. Válassza ki a szükséges tanúsítványt a listából és exportálja: ExportálásExportálás hajlékonylemezre. A következő párbeszédablak egy hajlékonylemez behelyezését kéri, valamint egy új PKCS12 jelszó megadását. Ezek után nyomja meg a Következőgombot és a tanúsítvány kiíródik a lemezre.

Általános kiszolgálótanúsítványok importálása

Ha rendelkezik egy exportált kiszolgálótanúsítvánnyal egy hajlékonylemezen, amely a YaST segítségével készült egy elszigetelt CA gépen, importálhatja azt egy másik kiszolgálón, mint Általános kiszolgálótanúsítványt. Ezt a telepítés során vagy később is megteheti a YaST Általános kiszolgálótanúsítványok importálása parancsával a YaST vezérlőközpont Felhasználók és biztonság menüpontja alatt. Az általános kiszolgálótanúsítvány az /etc/ssl/servercertskönyvtárban tárolódik és bármely CA által támogatott szolgáltatáshoz használható. Ha a tanúsítvány lejár, hasonló módon könnyedén lecserélhető. Egyetlen további művelet szükséges: a tanúsítványt használó szolgáltatásokat újra kell indítani.

Miután a modul elindult, ellenőrizze a jelenlegi tanúsítvány leírását. Importáláshoz válassza azImportálásHajlékonylemezrőlés helyezze be a megfelelő hajlékonylemezt, majd adja meg a tanúsítvány jelszavát és nyomja meg a Következőgombot. A tanúsítvány importálásra kerül és megjelenik a Leírás mezőben.

Icon-info.png Ötlet:

Amennyiben az ImportálásMerevlemezről opciót választja, kiválaszthatja a forrást a fájlrendszerből. Ez a megoldás alkalmazható USB meghajtókról történő tanúsítványimportáláshoz is.

VPN SUSE LINUX-al

A VPN (virtuális magánhálózat) technológia segítségével biztonságos kapcsolat építhető ki az Interneten keresztül. A kapcsolat nem internetes, de azon keresztül épül fel. A hitelesítési és egyéb védett adatcsomagok titkosított csatornában, új csomagok formájában kerülnek továbbításra. Ezzel a megoldással távoli számítógépek között építhető fel biztonságos, alacsony költségű kapcsolat. Az ilyen típusú kapcsolatra létrehozott szabvány az IPsec (Internet protocol security - Biztonságos Internet protokoll), amelyet Linuxon többek között a FreeS/WAN programmal valósítottak meg.

A VPN kapcsolat felépítéséhez minden résztvevő digitális tanúsítványa szükséges, amellyel ellenőrizhető a kapcsolat valódisága. Ilyen tanúsítványok a YaST program használatával készíthetők, majd használhatók VPN-hez. A X.509 tanúsítványok kezelése YaST-al oldal rövid magyarázatot ad a tanúsítványok készítéséről, felügyeletéről és működéséről. A következő rész ismerteti a VPN kiszolgáló és kliensek Linux illetve Windows alatti használatát és konfigurálását a YaST segítségével.

Road Warrior (utcai harcos) kiszolgálók beállítása

Road Warrior (utcai harcos) kiszolgálónak szokás nevezni a VPN kiszolgálónak azt a konfigurációját, amely bármilyen klienst fogad, aki rendelkezik érvényes és CA által aláírt tanúsítvánnyal. Egy Road Warrior kiszolgáló felállítása három lépésből áll, amelyeket az alábbiakban ismertetünk.
  1. Készítsen egy kiszolgálótanúsítványt a CA kezelő számítógépen;
  2. importálja a tanúsítványt a kiszolgálóra;
  3. állítsa be a kapcsolatot a kiszolgálón.

Kiszolgálótanúsítvány készítése

Készítse el a kiszolgálótanúsítványt a YaST CA felügyeleti moduljával (bővebben Felhasználói tanúsítványok készítése és visszavonása). Ezt követően mentse el a tanúsítványt a kulcsokkal és a résztvevő CA-kkal egy PKCSI12 formátumú fájlba (bővebben CA objektumok exportálása fájlba).

Icon-info.png Ötlet:

Ha Windows XP alapú IPsec alkalmazások részére készíti a tanúsítványokat, akkor klienstanúsítványokat kell használnia. A KeyUsage kiterjesztés tartalmazza a Windows számára szükséges beállításokat.

A kiszolgálótanúsítvány importálása

Indítsa el a VPN YaST modult a kiszolgálón a YaST vezérlőközpontból, a Felhasználók és Biztonság menüpontból. Az összefoglalónál, amint az a képen látható, válassza a TanúsítványokImport funkciót, majd jelölje ki a mentett PKCS12 fájlt. Az importáláshoz adja meg a PKCS12 jelszót. Ezek után a tanúsítvány megjelenik a tanúsítványok listájában. Válassza a Következő gombot az összefoglalóhoz való visszatéréshez.

YaST VPN Modul – összefoglaló
Icon-Important.png Fontos!

Ne használja a YaST CA felügyeleti moduljának "általános kiszolgálótanúsítvány" opcióját, mivel az IPsec kezeli a saját tanúsítványait.

VPN kapcsolat beállítása

Egy másik kapcsolat beállítása is szükséges, hogy a tanúsítvány biztosan az IPsechez használható legyen. Az összefoglalásban nyomja meg a Kapcsolatok, majd Hozzáadás gombokat a kapcsolatok összefoglalásánál. Miután kiválasztotta a Road Warrior kiszolgálót, elkészül egy olyan beállítás, amely bármilyen kapcsolatot elfogad, ha a kliens rendelkezik a CA által aláírt, érvényes tanúsítvánnyal.

Adja meg a kapcsolatok beállításait a párbeszédablakban. Írja be a saját IP-címét a Helyi IP-cím mezőbe. Betárcsázós Internet-hozzáférés esetén ez a cím általában nem ismert a csatlakozás előtt, mivel a szolgáltató a csatlakozás során rendel IP-címet a kliensekhez. Ha azonban elérhető az Internet a számítógépről, akkor szinte bizonyosan rendelkezik a gép egy alapértelmezett átjáróval. A %defaultroute beállítással a kiszolgáló mindig az alapértelmezett átjáró csatolóját fogja használni.

Amennyiben olyan kapcsolatot akar felállítani, amely automatikusan fel- és lekapcsolódik attól függően, hogy az alapértelmezett átjáró nélküli hálózati csatoló aktív vagy sem, válassza a %dynamic beállítást. Ebben az esetben a csatoló akutális IP-címe kerül használatra.

YaST VPN Modul – Csatlakozási beállítások

Ha azt akarja, hogy a kiszolgáló átjáróként üzemeljen és engedélyezze a hálózathoz való hozzáférést, akkor kapcsolja be az Átjáró funkcionalitásmenüpontot. Ezek után adja meg a hálózat címét, például 10.10.0.0/24. A szükséges tanúsítvány itt is kiválasztható. Az első tanúsítvány lesz az alapértelmezett.

Icon-info.png Ötlet:

Ez az egyszerűsített Road Warrior konfiguráció a tanúsítvány első Alany alternatív név (ha van ilyen), illetve a Megkülönböztetett név (DN) mezőjét használja.

A Következő gombra kattintás után megjelenő párbeszédablakban válassza ki a kapcsolatkezelés módját a számítógép indulásakor. A kapcsolat lehet »előkészített«, vagy »leállított«. Előkészített kapcsolat esetén a kiszolgáló várja a kliensek kapcsolatigénylését.

Ez csak akkor lehetséges, ha a helyi IP-cím már ismert. Ez azt is jelenti, hogy ha a %defaultroute változó be van állítva, akkor az alapértelmezett átjáró már ismert, és a számítógép már rákapcsolódott az Internetre. Amennyiben indulásakor a számítógép nincs az Icsatlakoztatva, megadhatja, hogy a kapcsolat törlődjön-e és újra felépüljön egy hálózati csatoló aktiválásakor, például egy DSL eszköz esetén. Amennyiben a kiválasztott csatoló nem az alapértelmezett átjáró csatolója, ne használja a %defaultroute beállítást mint helyi IP-címet. Az OK gomb megnyomása után az új kapcsolat megjelenik az összefoglaló listában. Az OK, majd Kilépés gombok lenyomása után a változások életbe lépnek.

VPN kliens beállítása Linuxon FreeS/WAN kiszolgálóhoz

Linuxon három fő lépés szükséges a VPN kliens beállításához:
  1. Készítsen egy klienstanúsítványt a CA felügyeleti számítógépen;
  2. exportálja ki a FreeS/WAN konfigurációs fájlt;
  3. importálja a fájlokat a kliens számítógépre.

Klienstanúsítvány készítése

A klienstanúsítványt a YaST CA Management modulja segítségével készítheti el (bővebben Felhasználói tanúsítványok készítése és visszavonása). Az elkészült tanúsítványt ezek után mentse a kulcsokkal és a résztvevő CA-kkal egy PKCSI12 formátumú fájlba (bővebben CA objektumok exportálása fájlba).

A FreeS/WAN konfigurációs állomány exportálása

Indítsa el a kiszolgálón a VPN YaST modult a YaST vezérlőpultból, a Felhasználók és biztonság részből. Az összefoglalásban ([[Dokumentáció/SL9.3/|]]) válassza a Kapcsolatok pontot, majd jelölje ki a kívánt kapcsolatot a megjelenő listából. Ezek után válassza ki a Szakértői...ExportálásFreeS/WAN pontokat, majd adja meg a helyet, ahová menteni kívánja a freeswan_ipsec.conf állományt, amelyet ezek után át kell másolni a Linux kliensre. A fájl alapértelmezett beállításokat tartalmaz a FreeS/WAN kliens részére, ennek részleteit lehet, hogy módosítani kell majd. Az állomány a FreeS/WAN 2-es verziójához készült, a korábbi változatokhoz további paraméterek megadása szükséges.

Állományok importálása a kliensen

Következő lépésként a tanúsítványokat és a konfigurációs fájlokat át kell töltenie a kliensre egy biztonságos csatornán keresztül. Az IPsec konfigurációs fájlt a /etc/ipsec.conf állományba kell menteni.

A tanúsítványok importálásához indítsa el a kliensen a YaST modul VPN opcióját, a YaST vezérlőközpontban, a Felhasználók és biztonság részből. Az összefoglalóban ([[Dokumentáció/SL9.3/|]]) válassza a TanúsítványokImportálás pontokat, majd válassza ki az elmentett klienstanúsítványt. Importáláshoz adja meg a tanúsítvány jelszavát. A tanúsítvány ezek után megjelenik a tanúsítványlistában, és a Következő gomb kiválasztásával visszatérhet az összefoglalóba.

Icon-info.png Ötlet:

A kapcsolat kialakítását befolyásolhatják a helyi igények, körülmények (pl. lehetséges, hogy meg kell változtatni a tanúsítványt és az azonosítót).

Manuális klienskonfiguráció

Ha a kliens nem rendelkezik a YaST VPN modullal, a tanúsítványt manuálisan is importálhatja:

  1. Másolja be a klienstanúsítványt a /etc/ipsec.d/certs fájlba.
  2. Másolja be a CA tanúsítványt a /etc/ipsec.d/cacerts fájlba.
  3. Másolja be a kulcsot az /etc/ipsec.d/private fájlba. Csak a root felhasználó érheti el ezeket az állományokat. Módosítsa ennek megfelelően a jogosultságokat.
  4. Adja meg a kulcs jelszavát a /etc/ipsec.secrets fájlban. Ez az állomány szintén csak root felhasználóként érhető el.

Az openssl parancssori program használható a tanúsítványok PKCS12 fájlból történő importálására:

openssl pkcs12 -clcerts -nokeys -in DATEI.p12 -out \
 /etc/ipsec.d/certs/cert_01.pem

Hasonlóképp járhat el a CA tanúsítványokkal:

openssl pkcs12 -cacerts -nokeys -in DATEI.p12 -out \
 /etc/ipsec.d/cacerts/cacert_01.pem

és a kulcsokkal:

openssl pkcs12 -nocerts -nodes -in USER.p12 -out \
 /etc/ipsec.d/private/key_01.pem

chmod 600 /etc/ipsec.d/private/key_01.pem

A -nodes paraméter azt adja meg, hogy a kulcs jelszó nélkül tárolódjon. Ez nem probléma, mivel a fájlt csak a root felhasználó érheti el. Még egy bejegyzés szükséges a /etc/ipsec.secrets fájlba, hogy a FreeS/WAN felismerje a kulcsokat. Használja a következő parancsokat:

echo ': RSA /etc/ipsec.d/private/key_01.pem ""' \
 >> /etc/ipsec.secrets

chmod 600 /etc/ipsec.secrets

Ezek után a konfigurációs állomány bemásolható az /etc/ipsec.conf helyre. Bizonyos körülmények között a leftcertben át kell alakítani a fájlnevet. Általában azonban a /etc/ipsec.d/certs/cert_01.pem már előre be van írva. A jogot követő értéknek meg kell egyeznie a kiszolgáló DNS nevével vagy IP-címével.

Az rcipsec start elindítja az IPsec szolgáltatást és felépíti a kapcsolatot, ha az auto=start már be van kapcsolva. Az ipsec auto --status vagy setkey-D parancsok és a /var/log/messages fájl vizsgálatával megállapítható, hogy minden megfelelően működik -e. Az rcipsec stop parancs leállítja az IPsec szolgáltatást és megszakít minden kapcsolatot.

IPsec kliensek Windows XP és Windows 2000 környezetben

A SUSE LINUX rendszerhez Windows XP és Windows 2000 kliensekről is csatlakozhat IPsec protokollon keresztül. Ehhez kövesse az alábbiakban leírt lépéseket.
  1. Készítse el a klienstanúsítványt a CA felügyeleti számítógépen.
  2. Exportálja a Windows konfigurációs állományt.
  3. Készítse elő a Windowst.
  4. Konfigurálja a Windows bővítőmodult.
  5. Importálja a klienstanúsítványt.
  6. Jegyezze fel a tanúsítvány fontos adatait.
  7. Állítsa be az IPsec kapcsolatot.
  8. Készítsen parancsikont a munkaasztalon.

Klienstanúsítvány készítése

Készítse el a klienstanúsítványt a YaST CA felügyeleti moduljával (bővebben Felhasználói tanúsítványok készítése és visszavonása). Ezt követően mentse el a tanúsítványt a kulcsokkal és a résztvevő CA-kkal egy PKCSI12 formátumú fájlba (bővebben CA objektumok exportálása fájlba).

A Windows konfigurációs állomány exportálása

Indítsa el a kiszolgálón a YaST modul VPN opcióját, a YaST vezérlőközpontban, a Felhasználók és biztonság részből. Az összefoglalásban ([[Dokumentáció/SL9.3/|]]) válassza a Kapcsolatok lehetőséget, majd jelölje ki a kívánt kiszolgálót a kapcsolatok összefoglalásában. Ezek után válassza ki a Szakértői...ExportálásWindows pontokat, majd adja meg a könyvtárat, ahová el kívánja menteni a windows_ipsec.conf állományt, amelyet majd át kell tölteni a Windows kliensre. A fájl Windows kliensek számára ajánlott konfiguráció, amelyet igény szerint testre kell szabni.

A Windows előkészítése

IPsec kapcsolat kézi beállítással is felépíthető. Ehhez az alábbi állományok szükségesek: ipseccmd.exe (Windows XP) vagy ipsecpol.exe (Windows 2000). Ezek az állományok a Windows telepítőkészletén találhatók. Windows XP használata esetén indítsa el a support\tools\setup.exe állományt a telepítő CD-ről (teljes telepítés). Ezek a programok parancssoros alkalmazások, ezért használatuk meglehetősen nehézkes. A kapcsolatok beállíthatók az MMC (Microsoft Management Console) használatával is, ami azonban szintén nem kézenfekvő. Ezért ajánlott az ipsec.exe eszköz használata, amely elvégzi az alapvető IPsec kapcsolat konfigurációját Windows XP vagy Windows 2000 alatt.

Ez a segédprogram letölthető a http://vpn.ebootis.de/package.zip címről. Tömörítse ki az állományt, például a C:\Programs\IPsec\ helyre. Itt szeretnénk köszönetet mondani a program készítőjének: <marcus@ebootis.de>.

Windows 2000 használata esetén először telepítse a Service Pack 2 javítócsomagot, amellyel a Windows 2000 képes lesz a 3DES titkosító eljárás kezelésére. Ellenkező esetben Windows 2000 alól a kapcsolódás nem lehetséges. A Windows 2000 Service Pack 2 letölthető:

http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/sp2lang.asp.

Windows 2000 használata esetén szükséges a ipsecpol.exe segédprogram is, amelyet az alábbi helyen talál:

http://agent.microsoft.com/windows2000/techinfo/reskit/tools/existing/ipsecpol-o.asp.

Icon-Important.png Fontos!

Ez a program rendszerint a C:/Programs/Resource Kit könyvtárba települ. Esetünkben azonban, mivel ez parancssori alkalmazás, érdemes átmásolni a futtatható állományokat tároló könyvtárba. Erősen ajánljuk az ipsecpol.exe fájl másolását a C:/WINNT, a hozzá tartozó DLL-ek elhelyezését pedig a C:/WINNT/System könyvtárba. Az ipsecpol alkalmazást rendszergazdaként kell futtatni.

A szükséges bővítőmodulok konfigurálása

Nyissa meg az MMC alkalmazást a Windows kliensen. A Start menüben válassza a FuttatásMMC menüpontokat. Az MMC-ben jelölje ki a FájlBővítőmodul hozzáadása/eltávolítása lehetőséget. Párbeszédablak jelenik meg, amelyben az aktív bővítőmodulokat láthatja. Válassza a Hozzáadás opciót. Választóablak jelenik meg, amely megmutatja az összes rendelkezésre álló bővítőmodulok listáját. TanúsítványokHozzáadás parancsok kiválasztásával eljuthat a konfigurációs varázslóhoz. Itt a Számítógép lehetőséget kell kiválasztani, majd a Következő gombot megnyomni. Válasszuk ki a Helyi számítógépBefejezés, majd az IP Biztonsági házirend kezeléseHozzáadás opciót. A konfigurációs varázslóban az alábbiakat válassza:Helyi számítógépBefejezés. Nyomja meg a Bezárás, majd az OK gombot.

Klienstanúsítvány importálása

A korábban hozzáadott két bővítőmodul most már látható az MMC-ben. Nyissa meg a Tanúsítványok könyvtárat. Kattintson a jobb egérgombbal a Saját tanúsítványok gombra, majd a legördülő menüből válassza a Minden feladatImportálás pontokat. Az ekkor megnyíló tanúsítványvarázslóban lépjen tovább: TovábbKeresés. A Fájltípus alatt adja meg a fájl elérését: Private Information Exchange (*.pfx,*.p12). Válassza ki az exportált PKCS12 fájlt és kattintson a Tovább gombra. Adja meg a YaST CA felügyelet moduljában használt jelszót, amelyet exportálásnál adott meg. Válassza a Tovább gombot, majd a Mentse a tanúsítványokat a következő helyreauto, továbbá a KövetkezőVége pontot. A párbeszédablak jelzi, hogy az importálás sikeres volt -e. Válassza az OK gombot.

A tanúsítvány fontos adatainak feljegyzése

Az előkészített IPsec példakonfiguráció általában már tartalmazza a kiállító CA megfelelő DN attribútumát (Kiállító). Az MMC programban válassza ki a FájlMentés opciót. Mentse el a konfigurációt a javasolt névvel a javasolt helyre. A tanúsítvány adatainak ellenőrzéséhez nyissa meg újra a Saját tanúsítványok könyvtárat az MMC-ben, majd nyissa meg a Tanúsítványok menüt. Jobb gombbal jelölje ki a tanúsítványt, és válassza ki a Megnyitás lehetőséget a legördülő listából, majd a Részletek oldalt.

Amikor kiválasztja a Kiállító opciót, az alábbiakhoz hasonló bejegyzéseket kell látnia, amelyek közül ezeket kell feljegyeznie:

 E=bsupport@suse.de
 CN=mainca
 OU=bu
 O=SuSE
 L=Nuremberg
 S=Franconia
 C=DE

Zárja be a tanúsítványnézetet az OK gombbal,az MMC-t pedig a FájlKilépésMentésIgengombokkal.

IPsec kapcsolat beállítása

Telepítse az ipsec.exe segédprogramot a package.zip kitömörítésével a C:\Programs\IPsec\ könyvtárba. A következő lépésként cserélje le az alapértelmezett ipsec.conf állományt a VPN kiszolgálóról exportált windows_ipsec.conf fájllal. Ezek után váltson át a C:\Programs\IPsec könyvtárba, és nyissa meg a fájlt egy akármilyen szövegszerkesztőprogrammal, a beállítások ellenőrzése végett. Az alábbiak az alapértelmezett beállítások:

conn <Kapcsolat neve>
 left=%any
 right=<A SuSE Linux kiszolgáló IP-címe>
 rightca=<a korábban feljegyzett értékek fordított
 sorrendben, vesszővel elválasztva, >
 network=auto
 auto=start
 pfs=yes

Az első sort balra kell igazítani, míg az összes többi behúzott sor. Az alábbiakban talál egy példát egy ipsec.conf állományra:

conn me_to_servername
 left=%any
 right=10.10.254.181
 rightca="C=DE,S=Franconia,L=Nuremberg,O=SuSE,OU=bu,
 CN=mainca,E=bsupport@suse.de" 
 network=auto
 auto=start
 pfs=yes

Parancsikon készítése

Végül készítsen parancsikont munkaasztalára a C:\Programs\IPsec\IPSEC.exe fájlhoz. Csatlakoztassa a számítógépet az Internetre, majd válassza ki a parancsikont. Egy ablak jelenik meg az aktuális kapcsolatra konfigurált IPsec szűrőkkel. A csatorna tesztelésének legjobb módja a ping <kliens IP-címe a titkosított hálózaton> parancs használata. A » Negotiating IP Security« üzenet egyszer vagy kétszer meg fog jelenni, ami után a normál ping válaszcsomagokat fogjuk látni. A csatorna ezek után aktív. Windows 2000 esetén kétszer kell a ping parancsot elindítani, tehát indítsuk el a ping segédprogramot még egyszer.

A kapcsolat lezárása

Az IPsec szűrő és csatorna lezárásához először el kell indítani az IPSEC.exe -off parancsot, majd az IPSEC.exe -delete parancssort. Egy parancsikon készítése a legegyszerűbb megoldás erre a műveletre is.

Álcázás és tűzfalak

Hálózati környezetben üzemeltetett Linux-rendszereken használhatók azok a kernelfunkciók, amelyek lehetővé teszik a hálózati csomagok előfeldolgozását a belső és külső hálózati terület határozott szétválasztása érdekében. A Linux hálózati szűrő keretrendszer biztosítja egy hatékony tűzfal létrehozásának lehetőségét, amely a különböző hálózatokat szétválasztja. Az iptables – ez egy általános táblázatos struktúra a szabályhalmazok meghatározásához – segítségével precízen szabályozható, hogy a hálózati csatolóhoz milyen csomagok jussanak el. A SuSEfirewall2 és a megfelelő YaST-modul segítségével egyszerűen beállítható egy ilyen csomagszűrő.

Csomagszűrés iptables segítségével

iptables: A csomag lehetséges útjai

A netfilter és iptables komponens felelős a hálózati csomagok szűréséért és kezeléséért, valamint a hálózati címfordításért (network address translation, NAT). A szűrési feltételek és a hozzájuk tartozó tevékenységek láncokként tárolódnak és az érkező hálózati csomagok sorban, a lánc összes feltételének meg kell, hogy feleljenek. A feltételláncokat táblázatok tartalmazzák. A táblák és a szabályhalmazok az iptables parancs segítségével módosíthatók.

A Linux-kernel három táblázatot tart fenn, a csomagszűrő funkcióinak megfelelő kategóriáihoz:

filter (szűrés)
Ez a táblázat tárolja a szűrőszabályok nagy részét, mivel szigorúbb értelemben ez valósítja meg a csomagszűrési mechanizmust, amely meghatározza, hogy a csomagok átengedésre (ACCEPT) vagy eldobásra (DROP) kerüljenek.
nat (címfordítás)
Ez a táblázat a csomagok forrás -és célcímének módosításait határozza meg. E funkciók segítségével álcázás is megvalósítható, amely a NAT egy speciális esete egy magánhálózat és az internet összekapcsolásakor.
mangle (szétdarabolás)
Az ebben a táblázatban tárolt szabályok lehetővé teszik az IP-csomagok fejléceiben tárolt értékek módosítását (mint például a szolgáltatás típusa).

A fent említett táblázatok előre meghatározott láncokat is tartalmaznak a csomagok ellenőrzéséhez:

PREROUTING
Ez a lánc a bejövő csomagokra vonatkozik.
INPUT
Ez a lánc a rendszer belső folyamataihoz címzett csomagokra vonatkozik.
FORWARD
Ez a lánc a rendszeren keresztül csak továbbított csomagokra vonatkozik.
OUTPUT
Ez a lánc a rendszertől származó csomagokra vonatkozik.
POSTROUTING
Ez a lánc a kimenő csomagokra vonatkozik.A iptables: A csomag lehetséges útjai bemutatja az utakat, amelyeken keresztül a hálózati csomag mozog egy adott rendszeren. Az egyszerűség kedvéért az ábra a táblázatokat a láncok részeként jeleníti meg, de valójában a láncok kerülnek a táblázatokon belül tárolásra.

A legegyszerűbb esetben a rendszerhez címzett bejövő csomag az eth0 csatolón keresztül érkezik. A csomag először a mangle táblázat PREROUTING láncához, majd a nat táblázat PREROUTING láncához kerül. A csomag irányítására vonatkozó következő lépésben kiderül, hogy a csomag valódi célja a rendszer egy saját folyamata. A mangle és filter táblázat INPUT láncainak átadás után a csomag végül eléri a célját, feltéve, hogy a filter táblázat szabályainak is megfelel.

Álcázás – alapok

Az álcázás a NAT (hálózati címfordítás) Linux-specifikus formája. Egy kis LAN (amelyben a gépek privát tartományból származó IP-címeket használnak – lásd: Hálózati maszkok és útválasztás) internethez csatlakoztatásához használható (ahol viszont a hivatalos IP-címek használatosak). Ahhoz, hogy a helyi hálózat gépei csatlakozni tudjanak az internetre, a privát címeket hivatalosra kell átfordítani. Ezt az útválasztó végzi, amely a LAN és az internet közötti átjáróként működik. Az alapelv egyszerű: az útválasztó egynél több hálózati csatolóval rendelkezik, jellemzően egy (vagy több) hálózati kártyával és egy másik, internet-csatlakozást biztosító felülettel (DSL, kábelmodem, Ethernet, ISDN stb.) Az utóbbi köti össze az útválasztót a külső világgal, a másik (vagy esetleg a többi) csatoló pedig a helyi hálózat gépeivel. A helyi hálózat gépei az útválasztó hálózati kártyájához (például eth0) csatlakoznak, és a nem helyi hálózaton belüli, hanem azon kívülre címzett csomagjaikat az alapértelmezett átjáróhoz (az útválasztóhoz) küldik.
Icon-Important.png Megfelelő hálózati maszk használata

A hálózat beállításakor győződjön meg róla, hogy a nyilvános (broadcast) cím és a hálózati maszk minden helyi gép esetén megegyezik. Ha nem, abból probléma származik, mivel a csomagok nem továbbíthatók megfelelően.

Ha a LAN egyik gépe csomagot küld egy internetes címre, akkor az az alapértelmezett útválasztóhoz kerül. Az útválasztót azonban be kell állítani ahhoz, hogy továbbítani tudja az ilyen csomagokat. Biztonsági okokból az alapértelmezett telepítésben a SUSE LINUX nem engedélyezi ezt. Az engedélyezéshez állítsa az /etc/sysconfig/sysctl fájlban lévő IP_FORWARD változót IP_FORWARD=yes értékre.

A külső kapcsolat másik oldala (gépe vagy útválasztója) látja ugyan az útválasztót, de semmit nem tud meg a belső hálózat azon gépéről, amelyről a csomagok erednek. Ezért hívják ezt a technikát álcázásnak. A címfordítás miatt minden válaszcsomag az útválasztóhoz érkezik (egyedül az útválasztó rendelkezik hivatalos IP-címmel). Az útválasztónak azonosítania kell a bejövő csomagokat és le kell fordítania a célcímeket, hogy a csomagok a helyi hálózat megfelelő gépéhez kerüljenek.

Mivel a bejövő forgalom irányítása az álcázási (címfordítási) táblázattól függ, kívülről nem lehet kapcsolatot kezdeményezni egy belső gép felé. Az ilyen kapcsolathoz ugyanis nincs bejegyzés a táblázatban (nincs hová továbbítani). A már létesített kapcsolatokhoz pedig egy állapotbejegyzés tartozik a táblázatban, amely bejegyzést másik kapcsolat nem használhatja.

Ez viszont problémákat jelenthet számos alkalmazásprotokoll – például az ICQ, a cucme, az IRC (DCC, CTCP) és az FTP (PORT módban) – alkalmazása esetén. A Netscape, a szabványos FTP program és számos más program az úgynevezett passzív (PASV) módot használják. A passzív mód használata sokkal kevesebb gondot jelent csomagszűrés és álcázás esetén.

Tűzfalak – alapok

A tűzfal valószínűleg a legszélesebb körben használt kifejezés azon mechanizmus leírására, amely egyszerre biztosítja és kezeli a hálózatok közötti kapcsolatot és szabályozza a közöttük haladó adatfolyamot. Precízen fogalmazva az itt leírt mechanizmus neve nem tűzfal, hanem csomagszűrés. A csomagszűrő meghatározott feltételeknek megfelelően szabályozza az adatfolyamot: engedélyez vagy tilt protokollok, portok és IP-címek alapján. Használatával blokkolhatók az olyan csomagok, amelyeknek – címük alapján – nem szabad elérniük a hálózatot. Mivel a legtöbb csomagszűrő alapértelmezésben mindent blokkol, például a webszerver nyilvános elérésének biztosításához kifejezetten meg kell nyitni a megfelelő portot (engedélyezni kell a webszerver forgalmát). A csomagszűrő azonban a cím- és portszűrési feltételeknek megfelelő (például a webszervernek küldött) csomagok tartalmát nem nézi meg. A csomagszűrő tehát akkor is átengedi a webszerverhez érkező csomagokat, ha azok célja egyébként az, hogy feltörjék vagy megrongálják a webszerveren futó CGI programot.

Egy lényegesen hatékonyabb, de sokkal bonyolultabb mechanizmus többfajta rendszer kombinációja, például az alkalmazásátjáróval vagy proxyval együttműködő csomagszűrés. Ebben az esetben a csomagszűrő visszautasítja a letiltott portokhoz címzett csomagokat. Csak az alkalmazásátjárónak küldött csomagok kerülnek elfogadásra. Ez az átjáró vagy proxy úgy tesz, mintha ő lenne a szerver valódi kliense. Ebben az esetben az ilyen proxy egy álcázó gépnek tekinthető az alkalmazás által használt protokollszinten. Egy példa ilyen proxyra a Squid, amely egy HTTP proxyszerver. A Squid használatához a böngészőt be kell állítani a proxyn keresztüli kommunikációra. A kért HTTP-oldalak a proxy gyorsítótárából kerülnek kiszolgálásra, a gyorsítótárból hiányzó oldalakat pedig a proxy kéri le az internetről. Másik példa: a SUSE proxycsomagja (proxy-suite) tartalmaz FTP-proxyt is.

Az alábbiakban a SUSE LINUX-ban található csomagszűrőre koncentrálunk. A csomagszűréssel és tűzfalkezeléssel kapcsolatos további információért olvassa el a howto csomagban lévő Tűzfal HOWTO-t. Ha ez a csomag telepítve van, akkor a HOWTO-t a less /usr/share/doc/howto/en/txt/Firewall-HOWTO.gz paranccsal olvashatja el.

SuSEfirewall2

A SuSEfirewall2 egy parancsfájl, amely beolvassa az /etc/sysconfig/SuSEfirewall2 fájlban beállított változókat az iptables szabályok előállításához. Három biztonsági zónát ad meg, de a következő példában csak az elsőt és másodikat vesszük figyelembe:
Külső zóna
Mivel nem szabályozható, hogy mi történik a külső hálózaton, a gépet védeni kell tőle. A legtöbb esetben a külső hálózat az internet, de a gyakorlatban lehet egy másik nem biztonságos hálózat is, mint például a WLAN.
Belső zóna
Ez a saját hálózatra utal, ami legtöbb esetben a helyi hálózat (LAN). Ha a hálózaton lévő gépek privát tartományba eső IP-címeket használnak (Hálózati maszkok és útválasztás), akkor engedélyezze a hálózati címfordítást (NAT), hogy a belső hálózaton lévő gépek el tudják érni a külső hálózatot.
Demilitarizált zóna (DMZ)
Az ebben a zónában lévő gépek a külső és belső hálózatról is elérhetők, de a belső hálózathoz nem tudnak hozzáférni. Ez a beállítás egy további védelmi vonalat húz a belső hálózat elé, mivel a DMZ-ben működő rendszerek el vannak szigetelve a belső hálózattól.A szűrési szabályok által kifejezetten nem engedélyezett hálózati forgalmat az iptables blokkolja. A bejövő forgalommal rendelkező csatolókat tehát a három zóna egyikébe kell helyezni. Minden zónához meg kell adni az engedélyezett szolgáltatásokat és protokollokat. A szabályhalmaz csak a távoli gépektől eredő csomagokra érvényes. A helyileg létrehozott csomagokat a tűzfal nem fogja el.

A beállítás a YaST segítségével is végrehajtható (Beállítás a YaST segítségével). Természetesen kézzel is elvégezhető az /etc/sysconfig/SuSEfirewall2 fájl módosításával. A fájlban számos megjegyzés található, az /usr/share/doc/packages/SuSEfirewall2/EXAMPLES könyvtárban pedig példák tekinthetők meg.

Beállítás a YaST segítségével

Icon-Important.png Automatikus tűzfalbeállítás

Telepítés után a YaST automatikusan elindít egy tűzfalat az összes beállított csatolón. Ha egy szerverprogram beállításra és aktiválásra kerül a rendszeren, akkor a YaST a szerverkonfigurációs modulok Portok megnyitása a tűzfal kiválasztott csatolóján vagy Tűzfal portjának megnyitása részeiben megadott beállításokkal módosítja az automatikusan létrehozott tűzfalkonfigurációt. Néhány szervermodul-párbeszédablak rendelkezik egy Tűzfalbeállítások gombbal a további szolgáltatások és portok aktiválásához. A YaST tűzfalbeállítási moduljával aktiválható, letiltható vagy függetlenül újrakonfigurálható a tűzfal.

A grafikus konfiguráció YaST párbeszédablaka a YaST vezérlőközpontból érhető el. Válassza ki a Biztonság és felhasználókTűzfal menüpontot. A beállítások hét részre vannak osztva, amelyek közvetlenül a képernyő baloldali fastruktúrájában érhetők el.

Indítás
Ebben párbeszédablakban állítható be az indítási viselkedés. Az alapértelmezett telepítés végén a SuSEfirewall2 már fut a frissen telepített rendszeren. Itt indítható el és állítható le a tűzfal. Ha tesztelni kívánja az aktuális tűzfalbeállításokat, akkor nyomja meg a Beállítások mentése és a tűzfal újraindítása most gombot.
YaST - tűzfalbeállítások
Csatolók
Itt látható az összes ismert hálózati csatoló. Egy csatoló zónából való eltávolításához válassza ki a csatolót, nyomja meg a Módosítás gombot, majd válassza ki a ____nincs_zóna____ menüpontot. Egy csatoló zónához adásához válassza ki a csatolót, nyomja meg a Módosítás gombot, majd válassza ki a kívánt zónát a listából. A Felhasználó által megadott menüpont segítségével egy saját beállításokkal rendelkező speciális csatoló is létrehozható.
Engedélyezett szolgáltatások
Itt lehet szolgáltatásokat biztosítani a szerverről egy védett zónához. A külső zóna alapértelmezés szerint védett. Ebben az esetben engedélyezni kell azokat a szolgáltatásokat, amelyeket a külső gépeknek látniuk kell. Aktiválja a megfelelő szolgáltatást, miután az Engedélyezett szolgáltatások a kiválasztott zónához menüpontban kiválasztotta a kívánt zónát.
Álcázás
Az álcázás segítségével a belső hálózat elrejthető a külső hálózatok (például az internet) elől. Lehetővé teszi ugyanakkor, hogy a belső hálózat átlátszó módon elérje a külső hálózatot. A külső hálózatról a belső hálózat felé érkező kérések blokkolásra kerülnek, a belső hálózat kérései kívülről nézve pedig úgy tűnnek, mintha az álcázó szervertől érkeznének.
Ha egy belső gép speciális szolgáltatásait elérhetővé kell tenni a külső hálózat számára, akkor a megfelelő szolgáltatáshoz speciális átirányítási szabályok adhatók meg.
Nyilvános üzenetek
Ebben a párbeszédablakban a nyilvános üzeneteket engedélyező UDP-portok kerülnek beállításra. A szükséges portszámokat vagy szolgáltatásokat hozzá kell adni a megfelelő zónához, szóközzel elválasztva. Lásd még: az /etc/services fájl.
A letiltott nyilvános üzenetek naplózása is itt engedélyezhető. Ez azonban problémát jelenthet, mivel a Windows gépek nyilvános üzeneteket használnak ahhoz, hogy tudjanak egymásról, ami nagyon sok elutasított csomagot eredményez.
IPsec-támogatás
Ebben a párbeszédablakban állítható be, hogy az IPsec-szolgáltatás engedélyezve legyen-e a külső hálózatból. A Részletek pontban állítható be, hogy mely csomagok megbízhatók.
Naplózási szint
Kétféle típusú esemény naplózható: az engedélyezett és az elutasított csomagok. Az engedélyezettek elfogadásra (ACCEPTED), az elutasítottak eldobásra (DROPPED) vagy visszautasításra (REJECTED) kerülnek. A Minden naplózása, a Csak a kritikus események naplózása és a Naplózás kikapcsolása lehetőségek közül választhat.A tűzfal beállításának befejezésekor a Tovább gombbal lépjen ki a párbeszédablakból. Ezután a tűzfalbeállítások zónaorientált összefoglalása jelenik meg, amelyben ellenőrizni kell a beállításokat. Az összefoglalásban minden engedélyezett szolgáltatás, port és protokoll megjelenik. Ha vissza kíván menni a beállításokhoz, akkor kattintson a Vissza gombra, a konfiguráció mentéséhez pedig az Elfogadás gombra.

Kézi beállítás

Az alábbi bekezdésekben részletes útmutatás található a tűzfal sikeres beállításához. Minden konfigurációs elem meg van jelölve, hogy a tűzfalhoz vagy az álcázáshoz fontos-e. A DMZ-vel (demilitarizált zóna) kapcsolatos szempontokról, amint azt a konfigurációs fájlnál említettük, itt nem lesz szó. Ezek jellemzően nagyobb szervezetek (vállalati hálózatok) összetettebb hálózati csatolóira alkalmazhatók és alkalmazandók, amelyek részletes beállításokat és a témával kapcsolatos alapos tudást igényelnek.

Először a YaST System Services (Runlevel) modul segítségével engedélyezze a SuSEfirewall2-t az adott futási szinten (általában 3 vagy 5). Ekkor beállításra kerülnek az /etc/init.d/rc?.d/ könytárakban a megfelelő szimbolikus láncok a SuSEfirewall2_* parancsfájlokhoz.

FW_DEV_EXT (tűzfal, álcázás)
Az internetre csatlakoztatott eszköz. Modemes csatlakozás esetén a ppp0, ISDN-kapcsolat esetén az ippp0, DSL-kapcsolatok esetén a dsl0 értéket kell megadni. Az alapértelmezett útvonalnak megfelelő csatoló használatához az auto értéket adja meg.
FW_DEV_INT (tűzfal, álcázás)
A belső, privát hálózatra csatlakoztatott eszköz (például az eth0). Hagyja üresen, ha nincs belső hálózat és a tűzfal csak azokat a gépeket védi, amelyen fut.
FW_ROUTE (tűzfal, álcázás)
Ha szükség van az álcázási funkcióra, akkor állítsa yes értékre. A belső gépek nem láthatók kívülről, mivel a belső hálózati címüket (például 192.168.x.x) az internetes útválasztók figyelmen kívül hagyják.
Álcázás nélküli tűzfal esetén akkor állítsa yes értékre, ha engedélyezni kívánja a hozzáférést a belső hálózathoz. A belső gépeknek ebben az esetben hivatalosan bejegyzett IP-címeket kell használniuk. Normális esetben nem szabad engedélyezni a belső hálózat kívülről történő korlátlan elérését.
FW_MASQUERADE (álcázás)
Ha szükség van az álcázási funkcióra, akkor állítsa yes értékre. A belső hálózatok számára virtuálisan közvetlen kapcsolatot biztosít az internethez. Biztonságosabb, ha a belső hálózat gépei és az internet között van proxyszerver. A proxyszerver által biztosított szolgáltatásokhoz nincs szükség álcázásra.
FW_MASQ_NETS (álcázás)
Adja meg az álcázandó gépeket vagy hálózatokat, az egyedi bejegyzések között szóközt hagyva. Például:
FW_MASQ_NETS="192.168.0.0/24 192.168.10.1"
FW_PROTECT_FROM_INT (tűzfal)
A tűzfalgép a belső hálózatból érkező támadások elleni védelme érdekében állítsa ezt yes értékre. A szolgáltatások csak akkor állnak a belső hálózat rendelkezésére, ha kifejezetten engedélyezve vannak. Lásd még FW_SERVICES_INT_TCP és FW_SERVICES_INT_UDP.
FW_SERVICES_EXT_TCP (tűzfal)
Adja meg az elérhetővé tenni kívánt TCP-portokat. Szokásos otthoni munkaállomás esetén, amelyik nem nyújt szolgáltatásokat, hagyja üresen.
FW_SERVICES_EXT_UDP (tűzfal)
Hagyja üresen, hacsak nem futtat UDP-szolgáltatást és nem kívánja kívülről elérhetővé tenni. UDP-t használó szolgáltatások: DNS-szerverek, IPSec, TFTP, DHCP és egyebek. Ebben az esetben adja meg a használandó UDP-portokat.
FW_SERVICES_INT_TCP (tűzfal)
Ezzel a változóval lehet megadni a belső hálózat számára rendelkezésre álló szolgáltatásokat. A jelölés az FW_SERVICES_EXT_TCP esetén is ugyanez, de a beállítások a belső hálózatra érvényesek. A változót csak akkor kell beállítani, ha az FW_PROTECT_FROM_INTyes értékre van állítva.
FW_SERVICES_INT_UDP (tűzfal)
Lásd FW_SERVICES_INT_TCP. A tűzfal beállítása után tesztelje az eredményt. A tűzfalszabályhalmazok akkor készülnek ténylegesen el, amikor a root felhasználó kiadja a SuSEfirewall2 start parancsot. Ezután próbálja ki például a telnet parancsot egy külső gépről, hogy a kapcsolat valóban le van-e tiltva. Majd tekintse meg a /var/log/messages fájlt, amelyben az alábbihoz hasonlót kell látnia:
Mar 15 13:21:38 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0
OUT= MAC=00:80:c8:94:c3:e7:00:a0:c9:4d:27:56:08:00 SRC=192.168.10.0
DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15330 DF PROTO=TCP
SPT=48091 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
OPT (020405B40402080A061AFEBC0000000001030300)

A tűzfal tesztelésére szolgáló csomag az nmap és a nessus. A megfelelő csomag telepítése után az nmap dokumentációja az /usr/share/doc/packages/nmap könyvtárban, a nessus dokumentációja pedig az /usr/share/doc/packages/nessus-core könyvtárban található.

További információ

A SuSEfirewall2 csomaggal kapcsolatos legfrissebb információ és más dokumentáció az /usr/share/doc/packages/SuSEfirewall2 könyvtárban található. A netfilter és iptables projekt honlapján (http://www.netfilter.org) egy nagy dokumentumgyűjtemény található, több nyelven is.

SSH: Biztonságos hálózati műveletek

Ahogy egyre több számítógép működik hálózatos környezetekben, annál gyakrabban van szükség arra, hogy egy gépet távolról elérjünk. Ez általában azt jelenti, hogy a felhasználó hitelesítési célból elküld egy bejelentkezési név és jelszó karaktersorozatot. Ha ezek a karaktersorozatok nyílt szövegként kerülnek átvitelre, akkor mások lehallgathatják ezeket, és visszaélhetnek a felhasználói fiókokkal úgy, hogy a jogosult felhasználó még csak nem is tud róla. Azon kívül, hogy ezzel egy támadó a felhasználó minden fájljához hozzáférhet, az illegális fiókot a rendszergazda vagy root hozzáférés megszerzésére, vagy akár a más rendszerekbe behatolásra is fel lehet használni. A múltban a távoli kapcsolatokhoz a Telnet protokollt használták, ami sem titkosítással, sem egyéb biztonsági mechanizmusok útján nem adott védelmet a lehallgatás ellen. Más nem védett kommunikációs csatornák is léteznek, ilyen például a hagyományos FTP protokoll és néhány távoli másolóprogram.

Az SSH programcsomag a hitelesítési karaktersorozatok (általában egy bejelentkezési név és jelszó), valamint a gépek közötti egyéb adatcsere titkosításával biztosítja a szükséges védelmet. Az SSH használata esetén az adatfolyamot továbbra is rögzítheti egy harmadik fél, de a tartalom titkosítva van és a titkosítási kulcs ismerete nélkül nem fejthető vissza nyílt szöveggé. Így az SSH biztonságos kommunikációt tesz lehetővé nem biztonságos hálózatokon, például az interneten. A SUSE LINUX csomagban az OpenSSH csomag található meg.

Az OpenSSH csomag

A SUSE LINUX alapértelmezésben telepíti az OpenSSH csomagot. Ezután a telnet, rlogin, rsh, rcp és ftp programok alternatívájaként rendelkezésre áll az ssh, az scp és az sftp. Az alapértelmezett konfigurációban egy SUSE LINUX rendszer elérése csak OpenSSH segédprogramok használatával lehetséges és csak akkor, ha a tűzfal engedélyezi a hozzáférést.

Az ssh program

Az ssh programmal be lehet jelentkezni a távoli rendszerekre és azokat interaktívan lehet használni. Kiváltja mind a telnet, mind az rlogin programot. Az slogin program az ssh-ra mutató szimbolikus lánc. Az ssh sun parancs segítségével jelentkezzen be például a sun gépre. A gép bekéri a sun géphez tartozó jelszót.

A sikeres hitelesítés után használhatja a távoli parancssort vagy az interaktív alkalmazásokat – például a YaST-ot – is. Ha a helyi felhasználónév eltér a távoli gépen használttól, akkor az ssh -l augustine sun vagy ssh augustine@sun parancs segítségével másik névvel is bejelentkezhet.

Az ssh ezen felül lehetőséget ad arra is, hogy parancsokat futtassunk a távoli rendszeren ugyanúgy, mint az rsh esetében. Az alábbi példában adja ki az uptime parancsot a sun nevű gépen, és hozzon létre egy tmp nevű könyvtárat. A program kimenete megjelenik az earth helyi terminálján.

ssh otherplanet "uptime; mkdir tmp"
tux@otherplanet's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Az idézőjelek ahhoz szükségesek, hogy mindkét utasítást el lehessen küldeni egy paranccsal. Ennek hatására a második parancs is végrehajtásra kerül a sun gépen.

scp – Secure Copy (biztonságos másolás)

Az scp fájlokat másol egy távoli gépre. Ez az rcp biztonságos és titkosított megfelelője. Az scp MyLetter.tex sun parancs például átmásolja a MyLetter.tex fájlt az earth gépről a sun gépre. Ha a felhasználói név az earth gépen különbözik a sun gépen használttól, akkor adja meg az utóbbit felhasználónév@gépnév formátumban. Ehhez a parancshoz nem tartozik -l paraméter.

A megfelelő jelszó megadása után az scp elindítja az adatátvitelt és csillagokat ír egymás mellé egy sorba, ezzel mutatja a folyamat előrehaladását. Emellett jobb oldalon kiírja az átvitel várható idejét is. A kimenetek a -q paraméter segítségével letilthatók.

Az scp rekurzív másolási funkciót is biztosít a teljes könyvtárakhoz. Az scp -r src/ sun:backup/ parancs az src könyvtár teljes tartalmát – az összes alkönyvtárat is beleértve – átmásolja a sun gépen lévő backup könyvtárba. Ha ez az alkönyvtár még nem létezik, akkor a rendszer automatikusan létrehozza.

A -p paraméter hatására az scp változatlanul hagyja a fájlok időbélyegét. A -C tömöríti az adatátvitelt. Ez a lehető legkisebbre tömöríti össze az átvinni kívánt adatkötetet, de jobban leterheli a processzort.

sftp – Secure File Transfer (biztonságos fájlátvitel)

Az sftp az scp helyett használható biztonságos fájlátvitelre. Az sftp munkamenet során számos, az ftp-ből már ismert parancs használható. Az sftp program jobb választás lehet, mint az scp, különösen ismeretlen fájlnevű adatok átvitelekor.

Az SSH démon (sshd) – szerveroldal

Az ssh és scp SSH kliensprogramok használatához futnia kell egy szervernek – az SSH démonnak – a háttérben, hogy figyelje a kapcsolatokat a 22-es TCP/IP porton. A démon az első elindításkor három kulcspárt hoz létre. Minden kulcspár egy saját és egy nyilvános kulcsot tartalmaz, amint azt a nyilvános kulcsú titkosításnál megszokhattuk. Az SSH-n keresztüli kommunikáció biztonsága érdekében a saját kulcsfájlok elérhetőségét a rendszeradminisztrátorra kell korlátozni. A fájljogosultságok az alapértelmezett telepítésnek megfelelően kerülnek beállításra. A saját kulcsokat csak helyileg kéri az SSH démon, és azokat nem is szabad senki másnak odaadni. A nyilvános kulcsokat (ezek nevének kiterjesztése .pub ) viszont meg kell kapnia a kapcsolatot kérő kliensnek. Ezek bárki számára olvashatók.

A kapcsolatot az SSH-kliens kezdeményezi. A várakozó SSH-démon és a kérő SSH-kliens kicserélik azonosítási adataikat, hogy összehasonlítsák a használt protokollt és szoftververziót, illetve megakadályozzák a rossz porton történő kapcsolódást. Mivel az eredeti SSH-démon egyik folyamata válaszol a kérésre, egyszerre több SSH-kapcsolat is létesíthető.

Az SSH-szerver és -kliens közötti kommunikációhoz az OpenSSH az SSH protokoll 1-es és 2-es verzióját támogatja. Az újonnan telepített SUSE LINUX rendszer alapértelmezett verziója a 2. Ha frissítés után is az 1. változatot szeretné tovább használni, kövesse az /usr/share/doc/packages/openssh/README.SuSE fájl utasításait. Ez a dokumentum azt is leírja, hogy az SSH 1 környezet hogyan alakítható át pár lépés segítségével működő SSH 2 környezetté.

SSH 1-es verzió használata esetén a szerver elküldi a saját nyilvános kulcsát és egy szerverkulcsot, amelyet az SSH démon minden órában újból létrehoz. Ezekkel az SSH-kliens titkosítani tud egy szabadon választott munkamenet-kulcsot, amelyet átküld az SSH-szervernek. Az SSH-kliens azt is megmondja a szervernek, hogy mely titkosítási módszert (rejtjelezést) használja.

Az SSH 2-es verzió nem igényel szerverkulcsot. Mindkét oldal a Diffie-Helman algoritmust használja a kulcsok cseréjéhez.

A saját kulcsra és a szerverkulcsra feltétlenül szükség van a munkamenetkulcs visszafejtéséhez, azok nem származtathatók le a nyilvános részekből. Csak az érintett SSH-démon tudja visszafejteni a munkamenetkulcsot a saját kulcsai segítségével (lásd: man/usr/share/doc/packages/openssh/RFC.nroff). Ez a kezdeti kapcsolati fázis közelebbről is megfigyelhető az SSH kliens -v hibakeresési lehetősége segítségével.

Alapértelmezés szerint az SSH protokoll 2-es változata kerül alkalmazásra. A protokoll 1-es változatának használatához írja ezt felül a -1 kapcsolóval. A kliens, ha már egyszer kapcsolatba lépett egy távoli géppel, a nyilvános kulcsokat a ~/.ssh/known_hosts fájlban tárolja. Ez megakadályozza azokat a támadásokat, amikor idegen SSH-szerverek megpróbálnak hamis neveket és IP-címeket használni. Az ilyen támadások felismerhetők a ~/.ssh/known_hosts fájlban nem szereplő nyilvános kulcsról, vagy arról, hogy a szerver a megfelelő saját példány hiányában nem tudja visszafejteni a munkamenetkulcsot.

Az /etc/ssh/ fájlban tárolt saját és nyilvános kulcsokról ajánlatos biztonsági másolatot készíteni egy megfelelően védett külső helyre. Így a kulcsmódosítások észrevehetők, és a régiek egy újratelepítés után ismét használhatók. Ez megkíméli a felhasználókat a zavaró figyelmeztetésektől. Ha kiderül, hogy a figyelmeztetés ellenére mégis egy megfelelő SSH-szerverről van szó, akkor a ~/.ssh/known_hosts fájlból el kell távolítani a rendszerre vonatkozó meglévő bejegyzést.

SSH: hitelesítési mechanizmusok

Ezután történik a tényleges hitelesítés, amely a legegyszerűbb formában egy jelszó megadásából áll. Az SSH célja egy biztonságos, egyszerűen használható szoftver bevezetése volt. Mivel az rsh-t és rlogin-t is kiváltja, az SSH-nak egy mindennapi használatra megfelelő hitelesítési eljárást is biztosítania kell. Az SSH ezt egy másik kulcspár segítségével hajtja végre, amelyet a felhasználó állít elő. Az SSH csomagban egy segédprogram szolgál erre: az ssh-keygen. Az ssh-keygen -t rsa vagy ssh-keygen -t dsa parancs beírása után létrejön a kulcspár. A rendszer ezután egy fájlnevet kér a kulcsok tárolásához.Erősítse meg az alapértelmezett beállítást és válaszoljon a jelszókérésre. Annak ellenére, hogy a szoftver üres jelszót kínál fel, az itt leírt eljáráshoz ajánlatos egy 10-30 karakteres szöveget megadni. Ne használjon rövid és egyszerű szavakat vagy kifejezéseket. Ismétléssel erősítse meg a jelszót. Ezt követően látni fogja, hogy a saját és a nyilvános kulcsok hol kerülnek tárolásra. Ebben a példában az id_rsa és az id_rsa.pub fájlban.

Az ssh-keygen -p -t rsa vagy ssh-keygen -p -t dsa parancs segítségével változtassa meg a régi jelszót. Másolja át a nyilvános kulcskomponenseket (a példában id_rsa.pub) a távoli gépre és mentse el a ~/.ssh/authorized_keys fájlba. A következő kapcsolatteremtéskor a jelszó segítségével hitelesítenie kell magát. Ha ez nem történik meg, akkor ellenőrizze a fájlok helyét és tartalmát.

Hosszú távon ez az eljárás nehézkesebb, mint a jelszó megadása minden alkalommal. Ezért az SSH csomag egy másik eszközt is biztosít, az ssh-agent programot, amely az X munkamenet időtartamára megtartja a saját kulcsokat. A teljes X munkamenet az ssh-agent leszármazott folyamataként kerül elindításra. Ennek legegyszerűbb módja, ha a .xsession fájl elején a usessh változót yes értékre állítja és bejelentkezik egy képernyőkezelőn keresztül (pl. KDM vagy XDM). Egy másik lehetőség az ssh-agent startx parancs kiadása.Ezután a szokásos módon használhatja az ssh és scp parancsokat. Ha a fent leírt módon osztotta ki a nyilvános kulcsot, akkor a továbbiakban nem kell jelszót megadnia. Ne felejtse el bezárni vagy jelszavas védelmi alkalmazással (ilyen pl. az xlock) zárolni az X munkamenetet.

Az SSH 2 protokoll miatt bevezetett minden fontos változás dokumentálva van az /usr/share/doc/packages/openssh/README.SuSE fájlban is.

X hitelesítési és továbbítási mechanizmusok

A korábban leírt biztonsággal kapcsolatos javításokon túl az SSH a távoli X alkalmazások használatát is leegyszerűsíti. Ha az ssh parancsot a -X opcióval futtatja, akkor a DISPLAY változó automatikusan beállításra kerül a távoli gépen, és a meglévő SSH kapcsolaton keresztül minden X kimenet exportálódik a távoli gépre. Az ezzel a módszerrel távolról elindított és helyileg megjelenített X alkalmazásokat ugyanakkor nem hallgathatják le jogosulatlan egyének.

A -A paraméter hozzáadásával az ssh-agent hitelesítési mechanizmus átkerül a következő gépre. Ezen a módon különböző gépekről dolgozhat jelszó megadása nélkül, de csak akkor, ha a nyilvános kulcsot eljuttatta a célgépekre is, és ott megfelelően elmentette.Az alapértelmezett beállítások mindkét mechanizmust letiltják, de az /etc/ssh/sshd_config rendszerszintű konfigurációs fájl vagy a felhasználó ~/.ssh/config fájlja segítségével aktiválhatók.Az ssh segítségével a TCP/IP-kapcsolatok is átirányíthatók. Az alábbi példában az SSH átirányítja az SMTP portot:

ssh -L 25:sun:25 earth

E parancs segítségével a earth 25-ös portjára (SMTP) érkező kapcsolatok egy titkosított csatornán keresztül átirányításra kerülnek a sun SMTP portjára. Ez különösen azok számára hasznos, akik SMTP-AUTH vagy POP-before-SMTP funkció nélkül használnak SMTP-szervereket. Az e-mail üzenetek a hálózatra csatlakozó tetszés szerinti helyről továbbíthatók kézbesítésre a »saját« levelezőszerverre. Ehhez hasonlóan az earth POP3 kérései (110-es port) is továbbíthatók a sun POP3 portjára a következő parancs segítségével:

ssh -L 110:sun:110 earth

Mindkét parancsot root felhasználóként kell végrehajtani, mivel a kapcsolat speciális helyi portokkal került kialakításra. Az e-maileket a normál felhasználók egy meglévő SSH-kapcsolaton keresztül küldik el és kapják meg. Az SMTP és POP3 gép értéke ennek a feladatnak az ellátásához localhost kell, hogy legyen. További információt a fent leírt programok kézikönyvoldalai (man), valamint az /usr/share/doc/packages/openssh könyvtárban található fájlok adnak.

Hálózati hitelesítés – Kerberos

Egy nyílt hálózat nem biztosít a szokásos jelszavas hitelesítésen kívül olyan szolgáltatásokat, amelyekkel a munkaállomások egyértelműen azonosíthatják a felhasználókat. Általában a felhasználónak minden, a hálózaton elérhető szolgáltatáshoz külön hitelesítenie kell magát, jelszó használatával. A Kerberos egy olyan hitelesítési megoldást biztosít, amely segítségével a felhasználónak csak egyszer kell regisztrálnia magát és ezek után a hálózati munkamenet teljes ideje alatt megbízhatóvá válik.A biztonságos hálózat eléréséhez az alábbi követelmények szükségesek:
  • Minden felhasználónak bizonyítania kell személyazonosságát, mielőtt egy szolgáltatást elér, továbbá biztosítani kell, hogy senki se férhessen hozzá más felhasználók azonosítójához.
  • Gondoskodni kell arról is, hogy a hálózati kiszolgálók szintén igazolják azonosságukat, hiszen ellenkező esetben egy támadó értékes információkat szerezhet a kiszolgáló megszemélyesítésével. Ezt a megoldást kölcsönös hitelesítésnek nevezzük, mivel a kliens hitelesíti magát a kiszolgáló felé és viszont: a kiszolgáló is hitelesíti magát a kliens felé.

A Kerberos a fenti elvárások megvalósítását erősen titkosított hitelesítés alkalmazásával segít elérni. A következőkben bemutatjuk, hogyan is történik mindez. Csak a Kerberos alapjait tárgyaljuk; a részletes technikai utasítások a Kerberos szoftver dokumentációjában találhatók.

A Kerberos fogalomtára

A következőkben összefoglaljuk a legfontosabb Kerberos-fogalmakat

Igazolvány
A felhasználóknak vagy a klienseknek valamilyen igazolványt kell felmutatniuk, hogy hozzáférjenek a kért szolgáltatáshoz. A Kerberos két típusú igazolványt ismer: jegyet és hitelesítőt.
jegy
A jegy egy kiszolgáló alapú igazolvány, amelyet a kliens a szolgáltatást futtató kiszolgálóhoz való csatlakozáskor használ. Tartalmazza a kiszolgáló és a kliens nevét, a kliens internetes címét, egy időbélyeget, az életciklust és egy véletlenszerűen generált kulcsot. Az összes adat titkosítva van a kiszolgáló kapcsolati kulcsával (session key).
hitelesítő
A jeggyel együtt használva a hitelesítő biztosítja, hogy a kliens valóban az, akinek mondja magát. A hitelesítő egy, a kliens nevéből, IP-címéből és a munkaállomás aktuális idejéből épül fel, amely adatok titkosításra kerülnek a kapcsolati kulccsal. Ezt a kulcsot csak a munkállomás és a szolgáltatást nyújtó kiszolgáló ismeri. Egy hitelesítő csak egyszer használható - szemben a jeggyel. A hitelesítőt a kliens készíti.
alany (principal)
A Kerberos alany egy egyedi azonosító (felhasználó vagy szolgáltatás), amelyhez jegy rendelhető. Az alany a következő komponensekből áll:
  • primary – az alany első része, amely felhasználó esetén megegyezhet a felhasználónévvel.
  • instance – elhagyható, a "primary" mezőt jellemző adatok. Ez a szöveg a /karakterrel kerül elválasztásra a "primary" mezőtől.
  • realm – itt adható meg a "realm" (tartomány) értéke, amely általában a domain neve, nagybetűs karakterekkel.
kölcsönös hitelesítés
A Kerberos garantálja, hogy a kliens és a kiszolgáló egyaránt megbizonyosodhasson a másik azonosságáról. Közös kapcsolati kulcson osztoznak, és ezt használják a titkosított kommunikációra.
kapcsolati kulcs
A kapcsolati kulcsok a Kerberos által előállított ideiglenes privát kulcsok. Ezeket a kliens ismeri és ezekkel titkosítja a kiszolgáló és a munkaállomás közötti kommunikációt a jegy kérésének és megérkezésének folyamata alatt.
ismétlés
Szinte az összes hálózati csomag lehallgatható és újraküldhető. A Kerberos esetén ez különösen veszélyes lehet, hiszen a támadó megszerezheti a szolgáltatáskérést, amely tartalamazza a jegyet és a hitelesítőt. Ezek után újraküldheti (megismételheti) a kérést, hogy Önt megszemélyesítse. Azonban a Kerberos néhány eljárással képes a probléma kezelésére.
kiszolgáló vagy szolgáltatás
A szolgáltatás egy megadott feladat végrehajtása, míg a folyamatot a kiszolgálóhajtja végre.

Hogyan működik a Kerberos?

A Kerberos szolgáltatást gyakran nevezik külső, bizalom alapú hitelesítő szolgáltatásnak, amely azt jelenti, hogy minden kliens megbízik a Kerberos ítéletében, hogy a többi kliens személyazonossága érvényes-e. A Kerberos egy adatbázisban tárolja a felhasználóit és a privát kulcsokat.

Ahhoz, hogy biztosítsuk a Kerberos megbízhatóságát, helyezzük a hitelesítő és a jegykiadó kiszolgálót egy külön gépre. Gondoskodjunk róla, hogy kizárólag az adminisztrátor érhesse el ezt a gépet, fizikailag és a hálózaton keresztül egyaránt. Ne használjunk felesleges hálózati szolgáltatásokat - beleértve akár az – sshd-t is.

Első kapcsolat
Az első kapcsolat a Kerberossal nagyban hasonlít bármely hálózati belépési folyamathoz. Adja meg a felhasználónevét. Ez az információ, valamint a jegykiadó szolgáltatás neve elküldésre kerül a hitelesítési kiszolgálóhoz (Kerberos). Ha a hitelesítő kiszolgáló felismeri a felhasználónevet, elkészíti a véletlenszerű kapcsolati kulcsot a kliens és a jegykiadó kiszolgáló közötti kommunikációhoz. Ezek után a hitelesítő kiszolgáló előkészíti a jegyet a jegykiadó kiszolgálónak. A jegy a kapcsolati kulccsal titkosítva tartalmazza a következő információkat. A kapcsolati kulcsot kizárólag a hitelesítő- és a jegykiadó kiszolgáló ismeri.
  • a kliens és a jegykiadó kiszolgáló neve
  • az aktuális idő
  • a jegyhez rendelt életciklus
  • a kliens IP címe
  • az újonnan készített kapcsolati kulcs
A jegy visszakerül a klienshez a kapcsolati kulccsal együtt, szintén titkosított formában, de ebben az esetben a kliens privát kulcsát használva. Ezt a privát kulcsot kizárólag a kliens és a Kerberos ismeri, mivel az a felhasználó jelszavából származik. Miután a kliens megkapta a választ, bekéri a jelszót. Ezt a jelszót egy kulccsá alakítja a kliens, amellyel kikódolja a hitelesítési kiszolgálótól érkezett csomagot. Ezzel a csomag»ki van bontva«és a jelszó, valamint a kulcs törlődik a munkállomás memóriájából. Amíg a további jegyek lekérésére használt jegy élettartama nem jár le, a munkállomás képes személyazonossága bizonyítására.
Szolgáltatás kérése
Bármely szolgáltatás kéréséhez a kliens alkalmazásnak bizonyítania kell személyazonosságát a kiszolgáló felé. Ezért az alkalmzások egy hitelesítőt készítenek. A hitelesítő az alábbi komponensekből áll:
  • a kliens megbízó neve
  • a kliens IP címe
  • az aktuális idő
  • ellenőrző összeg (melyet a kliens választ)
Ezek az információk a kapcsolati kulccsal kerülnek titkosítása, amelyet a kliens már korábban megkapott a kiszolgálótól. A hitelesítő és a jegy elküldésre kerül a kiszolgálóhoz. A kiszolgáló a kapcsolati kulcs saját példányát használja a hitelesítő kicsomagolásához. Ezzel rendelkezik az összes információval a szolgáltatás igénylő kliensről és össze tudja azt hasonlítani a kliens által küldött jeggyel. A kiszolgáló ellenőrzi, hogy a jegy és a hitelesítő ugyanattól a klienstől származik -e?
Mindenféle biztonsági ellenőrzés nélkül ez a fázis ideális lenne egy ismétléses támadáshoz. Valaki újraküldheti a hálózatról korábban ellopott kérést . Ennek kivédésére a kiszolgáló nem engedélyez olyan kéréseket, ahol a jegy és az időbélyeg már korábban megérkezett. Ráadásul, ha a kérés időbélyege túlságosan eltér a kérés érkezési idejétől, akkor a kérés eldobható.
Kölcsönös hitelesítés
Kerberos hitelesítés használható mindkét irányban. Nem csak az a kérdés, hogy a kliens az -e, akinek vallja magát: a kiszolgálónak is hitelesíteni kell magát, ha a kliens kéri azt. Ezért a kiszolgáló is küld egy hitelesítőt. Hozzáadja a klienstől kapott ellenőrző összeghez és titkosítja a kapcsolati kulcssal, amely kizárólag közte és a kliens között ismert. A kliens ezt mintegy bizonyítékként veszi a kiszolgáló hitelességét illetően és elkezdenek együtt dolgozni.
Jegy kiadás —Kapcsolódás minden kiszolgálóhoz
A jegyek úgy lettek kialakítva, hogy egyszerre csak egy kiszolgálóval legyenek használhatók. Ez azt jelenti, hogy minden egyes szolgáltatás igényléskor új jegy kérése szükséges. A Kerberos külön eljárással rendelkezik különálló kiszolgálókhoz való jegyek igénylésére. Ezt a szolgáltatást nevezzük»jegykiadó szolgáltatásnak«. A jegykiadó egy, a korábban említett szolgáltatásokhoz nagyon hasonlító szolgáltatás. Ugyanazokat a hozzáférési protokollokat használja, amelyeket már megtárgyaltunk. Minden alkalommal, amikor egy alkalmazásnak jegyre van szüksége - amelyet még nem igényelt korábban -, a jegykiadó kiszolgálóhoz fordul. Ez a kérés a következő részekből áll:
  • a megbízó neve
  • jegykiadó jegy
  • egy hitelesítő
Mint bármely más kiszolgáló, a jegykiadó kiszolgáló ellenőrzi a jegykiadó jegyet és a hitelesítőt. Ha ezek megfelelőek, a jegykiadó kiszolgáló új kapcsolati kulcsot készít, amely a kliens és az új kiszolgáló között használható. Ezek után elkészül a jegy az új kiszolgálóhoz, amely az alábbi információkat tartalmazza:
  • a kliens megbízó neve
  • a kiszolgáló megbízó neve
  • az aktuális idő
  • a kliens IP-címe
  • az újonnan készített kapcsolati kulcs
Az új jegy új időtartamot is kap, amely kevesebb, mint a jegykérő jegy hátralévő időtartama vagy a szolgáltatásra jellemző alapértelmezett időtartam. A kliens megkapja a jegyet és a kapcsolati kulcsot, amelyet a jegykiadó szolgáltatás küldött - de ez alkalommal a válasz a jegykérő jegyben található kapcsolati kulcssal van titkosítva. A kliens képes a válasz visszafejtésére a jelszó bekérése nélkül, amikor az új szolgáltatáshoz kapcsolódik. Tehát a Kerberos képes a jegyeket egymás után kérni anélkül, hogy a felhasználótól újra belépési adatokat kérjen.
Windows 2000 kompatibilitás
A Windows 2000 tartalmazza a Microsoft Kerberos 5 implementációját. A SUSE LINUX a Kerberos 5 Heimdal változatát tartalmazza. További hasznos információk találhatók a Heimdal kézikönyvében: További információ.

A Kerberos felhasználói szemmel

Ideális esetben a felhasználó egyetlen kapcsolata a Kerberossal a munkaállomásra való bejelentkezéskor történik. A belépési folyamat magába foglalja a jegykérő jegy kiadását is. Kilépésnél a felhasználó Kerberos-jegye automatikusan megsemmisül, ami megakadályozza, hogy mások a felhasználó nevében dolgozzanak, amikor az nincs belépve. Az automatikus megsemmisítés néha kellemetlen helyzetekhez vezethet, amikor a felhasználó tovább van belépve, mint a jegy maximális időtartama (ideális beállítás lehet például 10 óra). A felhasználók új jegykérő jegyet kérhetnek a "kinit" program futtatásával. A jelszó megadása után a Kerberos további hitelesítés nélkül hozzáférést létesít a szolgáltatásokkal. A Kerberos által igényelt jegylista a klist parancs futtatásával kérhető le.

Az alábbiakban található néhány alkalmazás, amelyek használhatók Kerberos hitelesítéssel. Ezek az alkalmazások az /usr/lib/mit/binvagy /usr/lib/mit/sbinkönyvtárban találhatók. Az alkalmazások funkciója teljesen megfelel a UNIX vagy Linux alapú változataiknak, valamint képesek a Kerberos hitelesítés kezelésére.

  • telnet, telnetd
  • rlogin
  • rsh, rcp, rshd
  • ftp, ftpd
  • ksu

A továbbiakban nem szükséges jelszó megadása ezekhez az alkalmazásokhoz, mivel a Kerberos már igazolta a személyazonosságot. Az ssh, amennyiben Kerberos támogatással lett lefordítva, képes a jegyek továbbítására más munkállomásokra is. Ha az SSH-t egy másik munkaállomásra történő bejelentkezésre használja, az SSH biztosítja, hogy a jegy titkosított tartalma az új helyzetnek megfelelően módosuljon. A jegyek munkaállomások közötti másolása önmagában nem elegendő, mivel a jegyek munkállomás-specifikus adatokat tartalmaznak (ilyen például az IP-cím). Az XDM és a KDM szintén támogatja a Kerberost. További alkalmazásokról a Kerberos V5 UNIX User's Guide kézikönyvben lehet olvasni, ezen a címen:http://web.mit.edu/kerberos

További információ

Az MIT Kerberos hivatalos lapja:http://web.mit.edu/kerberos. Itt megtalálhatók a hivatkozások a fontosabb dokumentációkra, beleértve a Kerberos telepítését, felhasználását és adminisztrálását.

Az ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS címen található leírás a Kerberos működésének bővebb, könnyen olvasható leírását tartalmazza. Ezen az oldalon szintén bőségesen gyűjthetők további információk a Kerberosról.

A hivatalos Kerberos FAQ a http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html címen olvasható. A Brian Tung által írt Kerberos—A Network Authentication System című könyv (ISBN 0-201-37924-4) szintén rengeteg hasznos információt tartalmaz.

A Kerberos telepítése és felügyelete

Ez a fejezet a MIT Kerberos implementációjának telepítését, valamint a felügyelet egyes szempontjait ismerteti. A fejezet feltételezi, hogy rendelkezik a Kerberos alapvető fogalmaival, ismereteivel (lásd Hálózati hitelesítés – Kerberos).

A Kerberos tartomány (realm) kiválasztása

A telepített Kerberos-rendszer tartományát (domain) "realm"-nek nevezzük és egy névvel hivatkozunk rá: lehet például FOOBAR.COM, vagy egyszerűen ACCOUNTING. A Kerberos megkülönbözteti a kis- és nagybetűket, vagyis a foobar.com nem egyezik meg a FOOBAR.COM tartománnyal. Bármely megoldást választhatja. Bevált gyakorlat azonban a nagybetűs tartománynevek alkalmazása.

Szintén hasznos a saját DNS tartománynév (vagy altartomány, mint ACCOUNTING.FOOBAR.COM) használata. Amint az alábbiakban is látható, a felügyelet egyszerűbb lehet, ha a Kerberos kliensek DNS-szolgáltatáson keresztül találják meg a KDC-t vagy a Kerberos-szolgáltatásokat. Ehhez ajánlott a tartomány nevének egy, a DNS-ben megtalálható altartományt választani.

Szemben a DNS felépítésével, a Kerberos nem hierarchikus. Nem készíthető egy tartomány FOOBAR.COM néven, valamint két »al-tartomány« mondjuk DEVELOPMENT és ACCOUNTING néven. A két al-tartomány nem örökli meg az alanyokat (principals) a FOOBAR.COM tartományból. Ehelyett három különálló tartományt kell létrehozni és tartományok közti (crossrealm) hitelesítést kell végezni az egyes tartományok között, hogy az egyik tartomány felhasználói elérjék a másikat.

Az egyszerűség kedvéért feltételezzük, hogy csak egy tartomány készült az egész szervezet számára. A tartományok közti hitelesítés leírása: [[Dokumentáció/SL9.3/|]], . Ebben a helyezetben az EXAMPLE.COM tartománynevet használjuk minden példában.

A KDC hardver beállítása

A legelső feladat a Kerberos működéséhez egy számítógép kiválasztása, amely kulcselosztó központként (KDC) funkcionál. Ez a számítógép tartalmazza az összes felhasználói információt és a jelszavakat.

A KDC a legfontosabb része a biztonsági rendszernek. Ha valaki feltöri, az összes felhasználói azonosító és a Kerberos által védett rendszerek elérhetővé válnak. Egy támadó, aki hozzáfér a Kerberos adatbázishoz, bármely alanyt megszemélyesítheti. Amennyire csak lehet, növeljük a gép biztonságát:

  • A számítógépet egy fizikailag védett helységben, például egy lezárt szerverteremben helyezzük el, ahova csak igen kevés embernek van hozzáférése.
  • Ne futtasson semmilyen hálózati alkalmazást a KDC kivételével - beleértve a kliens- és kiszolgálóalkalmazásokat is. A KDC ne importáljon fájlrendszereket NFS protokollon keresztül és ne használjon DHCP-t a hálózati konfiguráció lekérésére.
  • Célszerű minimális rendszert telepíteni, majd a nem szükséges csomagokat eltávolítani (a kiszolgáló szolgáltatásokat is, például mint az inetd, portmap, cups és minden X-alapú alkalmazás). Akár egy SSH démon telepítése is potenciális veszélyforrás lehet.
  • Grafikus bejelentkezés nem szükséges, ezért az X kiszolgáló potenciális biztonsági rés. A Kerberos saját felügyeleti felülettel rendelkezik.*Konfigurálja az /etc/nsswitch.conf állományt, hogy csak helyi felhasználók és csoportok léphessenek be. Változtassa meg a passwd és group sorokat az alábbiak szerint::
passwd:         files 
group:          files
  • Módosítsa a passwd, group, shadow, és gshadow állományokat az /etc könyvtárban és távolítsa el a + karakterrel kezdődő sorokat (ezek a NIS névfeloldáshoz szükséges sorok).
  • Szintén vegye számításba a DNS névfeloldás kikapcsolását, mivel ez is biztonsági kockázatot jelent. Amennyiben hiba található a DNS kliensben, egy támadó könnyen kihasználhatja azt. A DNS feloldások kikapcsolásához egyszerűen távolítsa el a következő állományt: /etc/resolv.conf.
  • Tiltson le minden felhasználót a "root" kivételével. Az /etc/shadow állományban a jelszavak helyére írjon * vagy ! karaktert.

Időszinkronizáció

A Kerberos sikeres használhatához elengedhetetlen, hogy a szervezeten belül minden rendszeróra szinkronizálva legyen. Ez azért fontos, mivel a Kerberos védekezik a tranzakciók ismételt lejátszása ellen. Egy támadó elfoghatja a hálózaton a Kerberos azonosítókat és újraküldheti azokat. A Kerberos számos megoldást tartalmaz ezek kivédésére. Egyike ezeknek, hogy egy időbélyeget helyez el a jegyekben. A kiszolgáló, amely megkapja a jegyet, ellenőrzi, hogy az időbélyeg egyezik-e a jelenlegi idővel és amennyiben az nem megfelelő, eldobja a jegyet.

A Kerberos engedélyez bizonyos késést az időbélyegeknek. Azonban a számítógépek órái megbízhatatlanok. Nem szokatlan, hogy egy PC órája fél órát késik vagy siet egy héten belül. Ezért minden számítógépét szinkronizálja egy központi időforráshoz.

Egyszerű megoldás egy NTP időkiszolgáló telepítése az egyik számítógépre és minden kliens idejének hozzá szinkronizálása. Az időszinkronizáció megvalósítható az NTP démon kliens módban történő futtatásával minden számítógépen, vagy az ntpdate parancs napi egyszeri kiadásával (ez a megoldás csak kis számú kliens esetén működik). A KDC-nek szintén szinkronizálnia kell az idejét a közös időforráshoz. Mivel az NTP démon futtatása biztonsági kockázatot jelent, érdemes egy időzített ntpdate parancsot futtatni. Az NTP konfigurációja túlmutat ezen a fejezeten. További információ az alábbi oldalon található: /usr/share/doc/packages/xntp-doc.

A Kerberos által elfogadott időkülönbség állítható. Ez az érték (időelcsúszás, clock skew) a krb5.conf konfigurációs állományon keresztül konfigurálható az alábbiak szerint: Az időelcsúszás (clock skew) beállítása.

Naplózási beállítások

Alapértelmezés szerint a KDC minden információt a syslogba naplóz. A KDC üzemeltetéséhez elengedhetetlen a naplófájl rendszeres vizsgálata, szokatlan események vagy potenciális problémák keresése. A felülvizsgálat megtehető naplófájlellenőrző parancsfájlok segítségével a KDC-n, vagy a fájlok másik számítógépre, az rsync parancs segítségével történő átmásolásával. A syslog naplófájl-továbbítási mechanizmusának használata nem ajánlott, mivel az információ kódolatlanul kerül átvitelre a hálózaton.

A KDC beállítása

Ez a fejezet bemutatja a KDC alapvető konfigurációját és telepítését, beleértve az adminisztratív alany elkészítését. Ez a folyamat több lépésből áll:
Az RPM fájlok telepítése
A KDC részére fenntartott számítógépen több különböző csomag telepítése szükséges. További információ:Az RPM fájlok telepítése
A konfigurációs fájlok hangolása
A /etc/krb5.conf és /var/lib/kerberos/krb5kdc/kdc.conf konfigurációs állományokat a saját rendszerünk szerint kell testreszabni. Ezek az állományok tartalmazzák a KDC működéséhez szükséges összes paramétert. Bővebb információ: [[Dokumentáció/SL9.3/|]]
A Kerberos adatbázis elkészítése
A Kerberos egy adatbázisban tárolja a alanyok adatait és a hitelesítéshez szükséges összes kulcsot. Bővebben: [[Dokumentáció/SL9.3/|]]
Az ACL fájlok testreszabása
adminisztrátorok hozzáadása
A KDC Kerberos adatbázisa távolról is felügyelhető. A jogosulatlan hozzáférések kivédéséhez a Kerberos hozzáférési listákat használ. Az adminisztrátori alanyt külön engedélyezni kell, hogy kezelhesse az adatbázis. Bővebben:[[Dokumentáció/SL9.3/|]]
Adminisztrátorok hozzáadása a Kerberos adatbázishoz
Legalább egy adminisztratív alany használata szükséges a Kerberos futtatásához. Ezt a alanyt a KDC indítása elött létre kell hozni. Bővebben: [[Dokumentáció/SL9.3/|]]
A Kerberos démon elindítása
Miután a KDC telepítésre és konfigurálásra került, indítsa el a Kerberos démont, hogy a tartomány elérhesse a Kerberos szolgáltatásokat. Bővebben: [[Dokumentáció/SL9.3/|]]
Saját alany létrehozása

Az RPM fájlok telepítése

Mielőtt elkezdené, telepítse a Kerberos szoftvert. A KDC-n telepítse az alábbi csomagokat: krb5, krb5-server és krb5-client.

A Mesterkulcs (Master Key) megadása

A következő lépés a Kerberos adatbázis elkészítése, amelyben az alanyokkal kapcsolatos összes adat található. Először adjuk meg az adatbázis mesterkulcsát, amely védi az adatbázist a jogosulatlan hozzáférésektől - különösen ami a szalagos mentéseket illeti. A mesterkulcs a jelszóból származik és egy ún. "stash" fájlban kerül tárolásra. Ez az oka, amiért nem szükséges a KDC minden indulásánál beírni a jelszót. Ellenőrizze, hogy jó jelszót választ - például egy mondat egy könyv véletlenszerűen kinyitott oldaláról.

Amikor szalagos mentést készít a Kerberos adatbázisról, (/var/lib/kerberos/krb5kdc/principal), ne mentse el a stash fájlt, amely itt található: /var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM). Ellenkező esetben bárki képes lesz olvasni és kikódolni az adatbázist a szalag olvasása után. Szintén ezen okok miatt érdemes egy másolatot tartani a fájlról egy megbízható, biztonságos helyen, hogy visszaállíthassa azt egy esetleges szalagról történő visszatöltés után.

A mesterkulcs beállításához futtassa a kstash parancsot paraméterek nélkül és adja meg a jelszót kétszer:

kstash

Master key:<enter pass phrase>
Verifying password - Master key:<enter pass phrase again>


Tartomány (realm) készítése

Végezetül, készítse el a tartomány bejegyzéseit a Kerberos adatbázisban. Indítsa el a kadmin parancsot a -l paraméterrel. Ez a paraméter utasítja a kadmin-t, hogy a helyi adatbázist használja. Alapértelmezésként a hálózaton keresztül próbálja meg elérni a Kerberos admin szolgáltatást. Ebben a fázisban ez nem fog működni, mivel a szolgáltatás még nem fut.

Ezek után utasítsa a kadmin-t, hogy inicializálja a tartományt. Néhány kérdés következik, amelyekre érdemes az alapértelmezett beállításokat elfogadni:

kadmin -l

kadmin> init EXAMPLE.COM
Realm max ticket life [unlimited]: <press return>
Realm max renewable ticket life [unlimited]: <press return>

] A beállítások ellenőrzéséhez használja a list parancsot:

kadmin> list *
default@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/hprop@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
changepw/kerberos@EXAMPLE.COM

Ez azt mutatja, hogy néhány alany már található az adatbázisban. Ezek mindegyike a rendszer belső használatú alanyai, amelyet a Kerberos maga használ.

alany készítése

Ezek után készítsen két alanyt: egy normál alanyt a mindennapi munkáhóz és egyet a Kerberos adminisztratív feladatainak ellátására. Feltételezve, hogy a felhasználó neve newbie, az alábbiak szerint járjon el:
kadmin -l

kadmin> add newbie
Max ticket life [1 day]: <press return>
Max renewable life [1 week]: <press return>
Principal expiration time [never]: <press return>
Password expiration time [never]: <press return>
Attributes []: <press return>
newbie@EXAMPLE.COM's Password: <type password here>
Verifying password: <re-type password here>

Az alapértelemezett beállítások Enter -rel történő elfogadása megfelelő, azonban válasszon egy megfelelő jelszót.

Ezek után készítsen egy másik alanyt, amelynek neve: newbie/admin. Ezt az addnewbie/admin parancs kiadásával érheti el a kadmin promptnál. A névhez írt admin szó egy szerep (role). Később használja ezt a szerepet, amikor adminisztrálja a Kerberos adatbázist. Egy felhasználó számos szerepet betölthet a különböző feladatokhoz. A szerepek tulajdonképpek teljesen különböző fiókok, azonos névvel.

A KDC indítása

Indítsa el a KDC démont. Ezzel elindítja a kdc-t (amely a felhasználói hitelesítéseket és jegyigényléseket kezeli), a kadmind-t (ez a távoli adminisztrációhoz szükséges modul) és a kpasswd-t (a felhasználói jelszóváltoztatási kérések kezeléséhez szükséges modul). A démon kézi indításához adja ki a rckdc start parancsot. Ellenőrizze az insserv kdc paranccsal, hogy a KDC automatikusan elindul-e, amikor a kiszolgáló újraindul.

A Kerberos kliensek beállítása

A Kerberos konfigurálásakor alapvetően két lehetőség közül választhat: statikus beállítások a /etc/krb5.conf fájlon keresztül vagy dinamikus konfigurálás DNS-en keresztül. DNS konfiguráció esetén a Kerberos alkalmazások a DNS bejegyzések segítségével találják meg a KDC szolgáltatásokat. Statikus konfiguráció esetén adja meg a KDC kiszolgáló nevét a krb5.conf állományban (és módosítsa az állományt, ha áthelyezi a KDC-t vagy módosítja a tartományt).

A DNS alapú konfigurálás általában jóval rugalmasabb és az egy munkállomásra eső munka is jóval kevesebb. Azonban ehhez a megoldáshoz a tartomány nevének meg kell egyeznie a DNS tartománnyal vagy annak egy al-domainjának kell lennie. A Kerberos DNS-en keresztüli beállítása szintén felvet egy minimális biztonsági kérdést is: egy támadó komolyan veszélyeztetheti a rendszert a DNS-en keresztül (a DNS kiszolgálók megtámadásával, DNS rekordok módosításával stb.). Azonban ez gyakorlatilag egy DoS támadásnak felel meg. Hasonló a helyzet a statikus konfigurációval is, hacsak nem IP-címet használunk a krb5.conf állományban a számítógép neve helyett.

Statikus beállítás

A Kerberos beállításának egyik lehetősége, hogy módosítja a /etc/krb5.conf állományt. Az állomány tartalmaz néhány alapértelmezett példát is. Mielőtt hozzákezd a beállításhoz, törölje ezeket! A krb5.conf több bekezdésből áll, mindegyik bekezdés szögletes zárójelekkel kezdődik, hasonlóan az alábbihoz: [this].

A Kerberos kliensek konfigurációjához írja be a következő bekezdést a krb5.conf fájlba (ahol a kdc.example.com a KDC neve):

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

A default_realm sor adja meg a Kerberos alkalmazásokhoz használt alapértelmezett tartománynevet. Több tartomány esetén egy másik [realms] rész hozzáadása szükséges.

Szükséges továbbá egy olyan bekezdés megadása, amely a számítógépneveket tartománnyal párosítja. Például, amikor egy távoli számítógéphez csatlakozik, a Kerberosnak tudnia kell, melyik tartományba tartozik az adott számítógép. Ezt a [domain_realms] bekezdésben adhatja meg:

[domain_realm]
        .example.com = EXAMPLE.COM
        www.foobar.com = EXAMPLE.COM

Ez azt adja meg, hogy az example.com DNS tartományok minden számítógépe a EXAMPLE.COM Kerberos tartományt használja. Továbbá, a www.foobar.com az EXAMPLE.COM tartomány tagjának tekintendő.

DNS alapú konfiguráció

A DNS alapú Kerberos konfiguráció nagyban kihasználja az SRV rekordokat. Bővebben erről a (RFC2052) A DNS RR for specifying the location of services című cikkben olvashat, a http://www.ietf.org címen. Ezek a bejegyzések nem támogatottak a BIND korábbi verzióiban. Legalább BIND 8 használata szükséges.

Az SRV bejegyzés neve - legalábbis a Kerberos számára - mindig _service._proto.realm formátumú kell, hogy legyen, ahol a "realm" a Kerberos tartomány neve. A DNS tartománynevekben a kis- és nagybetűk nincsenek megkülönböztetve, tehát az olyan Kerberos tartománynevek, amelyekben igen, problémát okozhatnak ezzel a megoldással. A _service a szolgáltatás neve (például különböző neveket kell használni, amikor a KDC-t vagy a jelszószolgáltatást kívánja elérni). A _proto lehet _udp vagy _tcp, de nem minden szolgáltatás támogatja mindkettőt.

Az SRV bejegyzés adat része tartalmaz egy prioritási értéket, súlyt, portszámot és egy hosztnevet. A prioritás határozza meg, melyik számítógéppel lép kapcsolatba először (az alacsonyabb érték magasabb prioritást jelent). A súly célja, hogy terheléselosztást biztosítson az egyenlő prioritású kiszolgálók között. Valószinűleg erre nem lesz szüksége, ezért állítsa 0-ra.

A Heimdal Kerberos jelenleg az alábbi neveket használja szolgáltatás kereséshez:

_kerberos
A KDC démon (hitelesítés és jegykiadás) elérhetőségét adja meg. A bejegyzés ehhez hasonló:
_kerberos._udp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com. 
_kerberos._tcp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos-adm
A távoli felügyeleti szolgáltatás elérhetőségét adja meg. A bejegyzés az alábbiakhoz hasonló:
_kerberos-adm._tcp.EXAMPLE.COM. IN  SRV    0 0 749 kdc.example.com.
Mivel a kadmind nem támogatja az UDP protokollt, ezért nem lehet _udp bejegyzés.Akárcsak a statikus konfigurációs állomány esetén, itt is van rá lehetőség, hogy értesítsük a klienst, ha egy megadott számítógép része a EXAMPLE.COM tartománynak, de nem része a example.com DNS tartománynak. Ez megoldható egy TXT rekord hozzáadásával a _keberos.hostname-hez, az alábbiak szerint:
_keberos.www.foobar.com.  IN TXT "EXAMPLE.COM"

Az időelcsúszás (clock skew) beállítása

Az időelcsúszás (clock skew) egy tolerancia, amellyel meghatározhatjuk, mely jegyek érvényesek, ha az időbélyegük nem egyezik meg pontosan a helyi idővel. Általában ez az érték 300 másodperc (5 perc). Ez azt jelenti, hogy a jegy rendelkezhet +/- 5 perc időeltéréssel a helyi időhöz képest.

NTP szinkronizáció esetén csökkentheti ezt az értéket 1 percre. Az érték beállítható a /etc/krb5.conf állományban az alábbiak szerint:

[libdefaults]
        clockskew = 120

A Kerberos kliens konfigurálása YaST segítségével

A fentiekben leírt kézi konfigurálás mellett lehetőség van a YaST használatára is a Kerberos kliens konfigurálásához. Ehhez indítsa el a YaST -ot a Vezérlőpultból, majd válassza ki a Hálózati szolgáltatásokKerberos kliensopciót. A párbeszédablak megnyílásakor válassza a Kerberos aktiválása menüt. DNS alapú kliens beállításához elengendő az Alapvető Kerberos beállítások elfogadása. Amennyiben a tartomány nem támogatja ezt a fajta beállítást, adja meg a megfelelő értékeket a Alapértelmezett domain, Alapértelmezett tartomány és a KDC-szerver címe mezőkben. A További beállítások egy másik YaST párbeszédablakot indít el, ahol módosíthatja a jegyekhez, OpenSSH támogatáshoz és időszinkronizációhoz kapcsolódó beállításokat.

A További beállítások hatására megjelenő párbeszédablak tartalmazza a jegy attribútumaihoz tartozó beállításokat. A jegy más számítógépekre továbbításához válassza a Továbbítható jegyek opciót. Csak megadott jegyek áttöltésének engedélyezéséhez jelölje ki a Gyorstárazott jegyek opciót. A PAM modul lehetősége biztosít a jegyek tárolására azután is, hogy azok már lejártak; Ennek bekapcsolásához engedélyezze a Jegyek megtartása opciót. A Jegy alapértelmezett élettartama meghatározható napokban, órákban, percekben (a megfelelő mértékegységet használva d, h, and m, szóközök nélkül megadva). Az OpenSSH kliensek Kerberos hitelesítésének bekapcsolásához válassza ki a megfelelő opciót. Ezek után a kliensek Kerberos jegyeket használnak az SSH kiszolgálóhoz történő csatlakozáskor. Egyes felhasználói fiókok kizárhatók a Kerberos hitelesítésből a Minimum UID megadásával. Például, esetleg ki akarja zárni a rendszeradminisztrátort (root). Végül, használja az Időelcsúszás beállítást az engedélyezett időeltérés meghatározásához.

A rendszeridő NTP-n keresztül történő szinkronizálásához beállíthatja a számítógépet, mint NTP kliens. Ehhez válassza az NTP beállítása... opciót. Miután befejezte a beállításokat, a YaST elvégzi a szükséges módosításokat és a Kerberos kliens használatra kész.

Távoli Kerberos-felügyelet

Ahhoz, hogy távolról is képes legyen alanyok hozzáadására és eltávolítására a Kerberos adatbázishoz, a KDC konzoljának közvetlen elérése nélkül, meg kell mondania a Kerberos adminisztráció kiszolgálónak, mely alanyok mit csinálhatnak. Ezt a /var/heimdal/kadmind.acl (az ACL a hozzáférési lista rövidítése) fájl szerkesztésével érheti el. Az ACL fájl segítségével precízen konfigurálhatja a hozzáférési listákat. További részletek: man8 kadmind.

Most egyszerűen engedélyezzen magának minden jogot az adatbázisban az alábbi sor beírásával:

newbie/admin              all

Cserélje le a newbie felhasználónevet a sajátjára. Indítsa újra a KDC-t a változtatások életbe léptetéséhez.

A kadmin használata távoli adminisztrációhoz

Mindezek után a Kerberos távoli adminisztrációja már elvégezhető a kadmin segédprogrammal. Először kérjen egy jegyet az admin szerephez és használja ezt a kadmin kiszolgálóhoz csatlakozásra:

kadmin newbie/admin
Authenticating as principal newbie/admin@EXAMPLE.COM with password.
Password for newbie/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin: 
A getprivs parancs használatával ellenőrizheti, milyen jogosultságokkal rendelkezik. A fenti lista az összes jogosultságot mutatja.

Példaként módosítsa a newbiealanyt:

kadmin newbie/admin
Authenticating as principal newbie/admin@EXAMPLE.COM with password.
Password for newbie/admin@EXAMPLE.COM:

kadmin:  getprinc newbie
Principal: newbie@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" newbie
Principal "newbie@EXAMPLE.COM" modified.
kadmin:  getprinc joe
Principal: newbie@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (newbie/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:
   

Ezzel megváltoztatta a Kerberos jegy élettartamát 8 órára. További információ a kadmin parancsról és beállításairól ezen a címen található: http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4/doc/krb5-admin.html#Kadmin%20Options.

Kerberos számítógép alany készítése

Azon túl, hogy biztosítjuk, minden hálózatba kötött számítógép ismeri a Kerberos tartományát, valamint, hogy melyik KDC-vel kell kapcsolatba lépnie, készítsünk egy ún. számítógép alanyt (host principal) számukra. Eddig kizárólag a felhasználói adatokról volt szó. A Kerberos kompatibilis szolgáltatások azonban általában igénylik saját hitelesítésüket is a felhasználó felé. Ezért speciális számítógép alanyoknak kell jelen lennie a Kerberos adatbázisban a tartomány minden gépéhez.

A névkonvenció a számítógép alanyok számára a következő: hoszt/<hosztnév>@<REALM>. Ezen belül a hosztnév a számítógép teljes hosztneve. A számítógép alanyok hasonlóak a felhasználói alanyokhoz, de azért akad számos különbség is. A fő különbség a kettő között, hogy a kulcs jelszóval védett. Amikor a felhasználó jegykérő jegyet kér a KDC-től, meg kell adnia Kerberos-jelszavát, hogy a Kerberos ki tudja kódolni a jegyet. Természetesen igen kényelmetlen lenne a rendszeradminisztrátoroknak, ha minden 8 órában új jegyet kellene kérniük az SSH démonnak.

Ehelyett az első jegy kikódoláshoz szükséges kulcsot az adminsztrátor egyszer lekérheti a KDC-ből és eltárolhatja egy helyi, keytab nevű fájlba. A szolgáltatások - mint az SSH démon - olvassák ezt a fájlt és automatikusan ezt használják új jegy kérésére. Az alapértelmezett keytab fájl itt található: /etc/krb5.keytab.Számítógép alany készítéséhez a test.example.com számára adja ki a következő parancsokat a kadmin programban:

kadmin newbie/admin
Authenticating as principal newbie/admin@EXAMPLE.COM with password.
Password for newbie/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/test.example.com
WARNING: no policy specified for host/test.example.com@EXAMPLE.COM;
defaulting 
to no policy
Principal "host/test.example.com@EXAMPLE.COM" created.
  

Jelszó megadása helyett válassza a -randkey opciót a kadmin-ban, véletlenszerű kulcs generálásához. Ez azért szükséges, mivel nem akar felhasználói beavatkozást. Ez egy kiszolgáló fiók a számítógép számára.

Végül exportálja a kulcsot és tárolja el a helyi /etc/krb5.keytab keytab állományban. Ennek a fájlnak egy superuser a tulajdonosa, tehát root felhasználónak kell lenni az alábbi parancs kiadásához:

kadmin:  ktadd host/test.example.com
Entry for principal host/test.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/test.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:
Amint elkészült, a kdestroy parancs segítségével ellenőrizze, hogy megsemmisítette-e az admin jegyet, amelyet a kinit kért.

Kerberos PAM támogatás bekapcsolása

A SUSE LINUXban található egy pam_krb5 nevű PAM modul, amely támogatja a Kerberos felhasználók és jelszavak használatát. Ez a modul használható különféle alkalmazásokhoz (például parancssori belépés, su, grafikus belépés (KDM)), ahol a felhasználó megadja a jelszavát és ezzel az alkalmazás automatikusan kér egy Kerberos jegyet a nevében.

A pam_unix2 modul továbbá támogatja a Kerberos hitelesítést és jelszófrissítést. A pam_unix2 Kerberos támogatását az /etc/security/pam_unix2.conf fájlban lehet bekapcsolni. Ennek tartalmaznia kell az alábbi sorokat:

auth:       use_krb5 nullok
account:    use_krb5
password:   use_krb5 nullok
session:    none

Ezek után minden program, amely figyelembe veszi az állomány bejegyzéseit, Kerberost fog használni a felhasználói hitelesítéshez. Olyan felhasználók esetében, akik nem rendelkeznek Kerberos alannyal, a pam_unix visszaadja a vezérlést a hagyományos jelszavas hitelesítésnek. Azok, akik rendelkeznek alannyal, ezek után megváltoztathatják Kerberos jelszavukat a passwd paranccsal.

A pam_krb5 finomhangolásához az /etc/krb5.conf állományt kell szerkeszteni, amelyben megadhat alapértelemezett alkalmazásokat a pam számára. További információ: man5 pam_krb5.A pam_krb5 modul kifejezetten Kerberost nem támogató hálózati alkalmazásohoz lett kifejlesztve. Ez egy teljesen más témakör, mint amit az alábbiakban tárgyalunk.

SSH beállítása Kerberos hitelesítéshez

Az OpenSSH támogatja a Kerberos hitelesítést mindkét (1-es és 2-es) verziójában. Az 1. verzióban a Kerberos jegy különleges protokollüzenetek formájában kerül elküldésre. A 2-es verzió nem közvetlenül a Kerberost, hanem a GSSAPI (General Security Services API) szabványt használja. Ez egy programozási felület, amely nem Kerberos-specifikus. Arra tervezték, hogy elrejtse a mögötte rejlő hitelesítési rendszer típusát, legyen az Kerberos vagy nyilvános kulcs alapú hitelesítés, mint az SPKM vagy egyebek. A SUSE LINUX tartalmazza a GSSAPI modulokat, azonban kizárólag a Kerberost támogatja.

SSHD Kerberos hitelesítéssel történő használatához módosítsa az /etc/ssh/sshd_config állományt az alábbi módon:

# These are for protocol version 1 
KerberosAuthentication yes
KerberosTicketCleanup yes
# These are for version 2 
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Ezek után indítsa újra az SSH démont: rcsshdrestart.

A Kerberos hitelesítés 2-es verzióval történő használatát a kliensoldalon is engedélyezni kell. Ez megvalósítható rendszerszinten az /etc/ssh/ssh_config fájlban, vagy felhasználónként a ~/.ssh/config állományokban. Mindkét esetben az alábbi paramétert kell hozzáadni a konfigurációs állományhoz: GSSAPIAuthentication yes.Ezek után a Kerberos hitelesítés működik. A klist paranccsal ellenőrizheti, hogy rendelkezik -e érvényes jeggyel és kapcsolódhat az SSH kiszolgálóhoz. SSH 1-es protokoll kikényszerítéséhez használja a -1 parancssori paramétert.

Icon-info.png Egyéb paraméterek

Az /usr/share/doc/packages/openssh/README.kerberos állomány bővebben tárgyalja az OpenSSH és a Kerberos együttműködését.

Kerberos és LDAP használata

A Kerberos használata közben az egyik lehetséges megoldás a felhasználói információk (felhasználói név, csoportok, saját könyvtár stb.) helyi hálózaton keresztüli közzétételére az LDAP. Erős hitelesítés szükséges, hogy elkerülje a csomagok hamisíthatóságát és egyéb támadásokat. Egy megoldás lehet Kerberos használata az LDAP kommunikációhoz.

Az OpenLDAP a legtöbb hitelesítést az SASL (simple authentication session layer) protokollon keresztül valósítja meg. A SASL tulajdonképpen egy hitelesítéshez készült hálózati protokoll. A SUSE LINUX-ban használt SASL megoldás a cyrus-sasl, amely számos különböző hitelesítést támogat. A Kerberos alapú hitelesítés a GSSAPI-n keresztül történik. Alapértelmezés szerint a GSSAPI-hoz tartozó SASL bővítőmodul nem kerül telepítésre, hanem kézzel telepíthető az alábbi paranccsal: rpm -ivh cyrus-sasl-gssapi-*.rpm.

Ahhoz, hogy a Kerberos csatlakozni tudjon egy OpenLDAP kiszolgálóhoz, készítsen egy alanyt: ldap/earth.example.com és adja hozzá a keytab fájlhoz.

Alapértelmezés szerint az LDAP kiszolgáló slapd szolgáltatása az ldap csoport és felhasználó nevében fut, míg a keytab állomány kizárólag a root által olvasható. Ezért vagy az LDAP konfiguráción kell módosítani, hogy a root felhasználó nevében fusson, vagy a keytab fájlt olvashatóvá kell tenni az ldap csoport számára.

Az slapd root-ként történő futtatásához módosítsa az /etc/sysconfig/openldap állományt. Kapcsolja ki az OPENLDAP_USER és OPENLDAP_GROUP változókat egy megjegyzés karakter elhelyezésével a sor elejére.Ahhoz, hogy a keytab állományt az LDAP csoport is olvashassa, adja ki az alábbi parancsokat

chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab

Egyik megoldás sem tökéletes. Azonban jelenleg nem lehetséges az OpenLDAP beállítása egy különálló keytab fájl használatára. Végül indítsa újra az LDAP kiszolgálót: rcldap restart.

Kerberos hitelesítés használata LDAP protokollal

Most már használhatók a különféle LDAP eszközök - mint például az ldapsearch - automatikus Kerberos hitelesítéssel.

ldapsearch -b ou=people,dc=example,dc=com '(uid=newbie)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# newbie, people, example.com
dn: uid=newbie,ou=people,dc=example,dc=com
uid: newbie
cn: Olaf Kirch
[...]
Amint látható, az ldapsearch kiír egy üzenetet, hogy megkezdte a GSSAPI hitelesítést. A következő üzenet kétségkívül kicsit zavaros; ez a security strength factor (biztonság mértéke) (SSF for short), amely 56. (Az 56-os érték tetszőleges. Valószínűleg azért ez az érték látható, mivel ennyi a bitek száma a DES titkosítási kulcsban). Ezek a sorok mindenesetre jelzik, hogy a GSSAPI titkosítás sikeres és a titkosítás működik, hogy védje a bizalmas adatokat az LDAP kapcsolat során.

A Kerberos hitelesítés mindig kölcsönös. Ez azt jelenti, hogy nemcsak magunkat kell azonosítani az LDAP kiszolgáló fele, de az LDAP kiszolgálónak is hitelesítenie kell saját magát. Ezzel biztosítható, hogy egy valódi LDAP kiszolgálóval kommunikálunk és nem egy támadó által felállított szolgáltatással.

Kerberos hitelesítés és LDAP hozzáférés-vezérlés

Ezek után engedélyezzük minden felhasználónak, hogy módosítsa a "login shell" attribútumát az LDAP felhasználói rekordjában. Feltételezve, hogy a a felhasználót joe-nak hívják és az alábbi helyen található: uid=joe,ou=people,dc=example,dc=com, állítsa be a következő hozzáférés-vezérlést a /etc/openldap/slapd.conf állományban:

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
       by self write
# Every user can read everything
access to *
       by users read

A második bekezdés jogosultságot ad a bejelentkezett felhasználóknak a saját loginShell attribútumuk írására. A harmadik bejegyzés minden bejelentkezett felhasználónak engedélyezi a teljes címtár olvasását.

Már csak egy aprócska részlet hiányzik a kirakósból: hogyan tudja az LDAP kiszolgáló kitalálni, hogy a joe@EXAMPLE.COM Kerberos felhasználó tartozik az uid=joe,ou=people,dc=example,dc=com LDAP DN-hez? Az ilyen típusú összerendeléseket kézzel kell elvégezni a saslExpr bejegyzést használva. A mi példánknál maradva, írjuk be az alábbiakat a slapd.conf fájlba:

    saslRegexp
        uid=(.*),cn=GSSAPI,cn=auth 
        uid=$1,ou=people,dc=example,dc=com

Ahhoz, hogy megértse, hogyan is működik az egész, tudni kell, hogy amikor az SSL hitelesít egy felhasználót, az OpenLDAP egy DN-t készít az SASL által megadott névből (például joe) és SASL típusából (GSSAPI). Az eredmény: uid=joe,cn=GSSAPI,cn=auth.

Ha az saslRegexp konfigurálva van, az SASL ellenőrzi az SASL információkból kapott DN-t és szükség esetén lecseréli az saslRegexp második elemével. A helyettesítő $1 lecserélésre kerül egy szövegrészlettel, amelyet a (.*) kifejezés talál meg.

Ennél bonyolultabb kifejezések is lehetségesek. Ha több, bonyolultabb címtárstruktúra vagy séma van, ahol a felhasználónevek nem részei a DN-nek, használhatók keresési kifejezések is, hogy párosítsák az SASL DN-t a felhasználó DN-jével.

Partíciók és fájlok titkosítása

Alkalmazás-példahelyzetek

Minden felhasználó rendelkezik bizalmas adatokkal, amelyekhez nem akarja, hogy mások hozzáférjenek. Minél sűrűbben csatlakozik és minél mobilabb valaki, annál inkább figyelnie kell az adatok kezelése miatt. A fájlok vagy akár egy teljes partíció titkosítása mindig ésszerű, ha a harmadik fél hálózati kapcsolaton keresztül vagy közvetlenül fizikailag hozzá tud férni. Az alábbi lista néhány elképzelhető használati példahelyzetet mutat be.

Noteszgépek
Ha noteszgéppel utazik, akkor érdemes titkosítani a merevlemezen lévő bizalmas adatokat tartalmazó partíciókat. A titkosított fájlrendszerben vagy fájlban található adatok a noteszgép elvesztése vagy ellopása esetén is biztonságban vannak.
Cserélhető adathordozó
Az USB flash-meghajtók és a külső merevlemezek a noteszgépekhez hasonlóan ellophatók. A titkosított fájlrendszer ilyen esetekben is védelmet biztosít.

Crypto fájlrendszer beállítása a YaST segítségével

A YaST lehetővé teszi a fájlok és partíciók titkosítását a telepítés során, vagy akár a már telepített rendszeren. Titkosított fájlok létrehozása nem gond, hiszen kiválóan elférnek a meglévő partíciókon belül. Egy teljes partíció titkosításához azonban rá kell szánni erre egy külön partíciót – gondoljon erre, amikor a partíciók elrendezését kialakítja. A YaST által javasolt partícióelrendezés alapértelmezés szerint nem tartalmaz titkosított partíciót. Az ilyen partíciót a particionálás során, kézzel kell felvenni.

Titkosított partíció létrehozása a telepítés közben

Icon-Caution.png Jelszó bevitele

Titkosított partíciók létrehozásakor olvassa el gondosan a jelszóbiztonsággal kapcsolatos figyelmeztetéseket és jól jegyezze meg a használt jelszavakat. Jelszó nélkül a titkosított adatok nem érhetők el.

A particionálásra használható YaST szakértői párbeszédablak (Particionálás) tartalmazza a titkosított partíció létrehozásához szükséges összes lehetőséget. Hagyományos partíció létrehozásához kattintson a Létrehozás gombra. A megjelenő párbeszédablakban adja meg az új partíció paramétereit, mint például a kívánt formázás és a csatolási pont. A Fájlrendszer titkosítása gombra kattintva fejezze be a műveletet. A következő párbeszédablakban állítsa be a jelszót és biztonsági okokból ismételje meg. Miután befejezte a particionálási párbeszédablak kitöltését és megnyomta az OK gombot, létrejön az új titkosított partíció. Az operációs rendszer indítás közben, mielőtt a partíciót felcsatolná, jelszót kér a felhasználótól.

Ha az indítás során nem kívánja felcsatolni a titkosított partíciót, akkor a jelszó kérésekor egyszerűen csak üsse le az Enter billentyűt. Ezután utasítsa el a jelszó újbóli beírásának lehetőségét is. A titkosított fájlrendszer ebben az esetben nem kerül felcsatolásra és az operációs rendszer folytatja a rendszerindítást. Ez az adatok védelmének biztonságosabb módja. A partíció felcsatolás után az összes felhasználó számára rendelkezésre áll.

Ha a titkosított fájlrendszert csak szükség esetén kell felkapcsolni, akkor a fstab beállítások párbeszédablakban jelölje meg az Indítás során ne kerüljön csatolásra négyzetet. A megjelölt partíció a rendszer indítása során nem kerül csatolásra. Ha később mégis használni kívánja, akkor a mount partíció_neve csatolási_pont parancs segítségével kézzel csatolja fel. A partíció felcsatolása közben adja meg a jelszót. Ha befejezte a partíció használatát, akkor az umount partíció_neve parancs segítségével csatolja le, hogy mások ne érhessék el.

Titkosított partíció létrehozása egy futó rendszeren

Icon-Caution.png Titkosítás aktiválása futó rendszeren

Titkosított partíciók futó rendszeren is hasonlóan hozhatók létre, mint telepítés során. Egy meglévő partíció titkosítása azonban megsemmisíti a rajta található adatokat.

A futó rendszeren a YaST vezérlőközpontban válassza ki a RendszerParticionálás menüpontot. A folytatáshoz kattintson az Igen lehetőségre. A Létrehozás gomb helyett most a Szerkesztés gombra kattintson. Az eljárás további része ugyanaz.

Titkosított fájlok telepítése

A bizalmas adatok tárolásához teljes partíciók titkosítása helyett egy-egy fájlon belül is létrehozható egy titkosított fájlrendszer. Ezeket ugyanabban a YaST párbeszédablakban lehet létrehozni. Nyomja meg a Titkosított fájl gombot, majd adja meg a fájl elérési útját és kívánt méretét. Fogadja el a formázáshoz felajánlott beállításokat és a fájlrendszer típusát. Ezután adja meg a csatolási pontot és döntse el, hogy a titkosított fájlrendszert a rendszerindítás során kívánja-e felcsatolni.

A titkosított fájlok előnye, hogy a merevlemez átparticionálása nélkül is elkészíthetők. A hurokeszköz segítségével kerülnek felcsatolásra és ugyanúgy viselkednek, mint a nem titkosított partíciók.

Fájlok titkosítása a vi segítségével

A titkosított partíciók használatának az a hátránya, hogy amíg a partíció fel van csatolva, addig legalább a root felhasználó hozzá tud férni az adatokhoz. Ez megakadályozható a vi titkosított módban használatával.

Készítsen a vi -x fájlnév paranccsal egy új fájlt. A vi bekér egy jelszót, majd titkosítja a fájl tartalmát. Amikor a fájlt legközelebb megnyitja vi-ban, ismét meg kell adni a megfelelő jelszót.

A nagyobb biztonság érdekében a titkosított fájlt egy már biztonságos partícióban is elhelyezheti. Ez hasznos, mivel a vi-ban használt titkosítási mechanizmus nem nevezhető erősnek.

Cserélhető adathordozók tartalmának titkosítása

A cserélhető adathordozókat – például a külső merevlemezeket vagy az USB-meghajtókat – a YaST ugyanúgy ismeri fel, mint minden más merevlemezt. Az ilyen adathordozón található fájlok és partíciók is titkosíthatók a fent leírt módon. Ezeket az adathordozókat ne csatolja fel a rendszerindítás során, mivel ezek általában csak akkor kerülnek csatlakoztatásra, ha a rendszer már fut.

Biztonság és megbízhatóság

A Linux- és UNIX-rendszerek egyik fő jellemzője, hogy egyszerre több felhasználót tudnak kezelni (többfelhasználósság) és lehetővé teszik, hogy ezek a felhasználók egyidejűleg több feladatot hajtsanak végre ugyanazon a számítógépen (többfeladatosság). Az operációs rendszer a hálózat szempontjából átlátszó. A felhasználók gyakran nem is tudják, hogy az általuk használt adatokat és alkalmazásokat helyileg vagy a hálózaton keresztül érik el.

A többfelhasználósság miatt a különböző felhasználók adatait külön kell tárolni. Garantálni kell a biztonságot és megbízhatóságot. Az adatok biztonsága már azelőtt is fontos probléma volt, hogy a számítógépeket hálózatokon keresztül összekapcsolták volna. Csakúgy, mint manapság, a legfontosabb szempont akkor is az volt, hogy az adatok akkor is rendelkezésre álljanak, ha az adathordozó – általában merevlemez – elveszett vagy másképp károsodott.

Ez a rész elsősorban a megbízhatósággal kapcsolatos témakörökre és a felhasználók személyiségi jogainak védelmére koncentrál, de nem hangsúlyozható kellően, hogy egy átfogó biztonsági alapelvnek mindig tartalmaznia kell azokat az eljárásokat, amelyekkel garantálható, hogy rendszeresen frissített, működő és tesztelt biztonsági mentések legyenek kéznél. Enélkül nagyon nehéz az adatok visszanyerése – nemcsak hardverhiba esetén, hanem akkor is, ha az a gyanú merült fel, hogy valaki jogosulatlan hozzáférés birtokában belenyúlt a fájlokba.

Helyi és hálózati biztonság

Az adatok sokféleképpen elérhetők:

  • személyes kommunikáció révén olyan személyekkel, akik rendelkeznek a kívánt információval, vagy hozzáférnek egy számítógép adataihoz
  • közvetlenül a számítógép konzoljáról (fizikai hozzáférés)
  • soros vonalon keresztül
  • hálózati kapcsolat segítségével

Ezen esetek mindegyikében a kérdéses erőforrások és adatok elérése előtt a felhasználót hitelesíteni kell. A webszerverek kevésbé lehetnek korlátozók ebben a vonatkozásban, de továbbra sem kívánatos a személyes adatok nyilvánosságra hozatala.A fenti lista első esete az, ahol a legtöbb felhasználói interakció történik; például, amikor kapcsolatba lép egy banki alkalmazottal, és bizonyítania kell, hogy Ön a bankszámla tulajdonosa. Ezután meg kell adnia egy aláírást, PIN-kódot vagy jelszót annak bizonyítására, hogy Ön valóban az, akinek állítja magát. Bizonyos esetekben lehet, hogy egyes adatok kicsalhatók egy tájékozott személytől azzal, hogy ügyesen előadva valami olyan szöveget, ami ismert információmorzsákat tartalmaz, elnyerik a bizalmát. Az áldozat lépésről-lépésre egyre több információt adhat ki, esetleg anélkül, hogy egyáltalán észrevenné azt. A hackerek ezt social engineering néven emlegetik). Ez ellen csak az emberek felvilágosításával, a nyelvhasználat és az információ tudatos kezelésével lehet védekezni. A számítógéprendszerekbe betörés előtt a támadók gyakran megpróbálják célba venni a recepciósokat, a vállalatnál dolgozó karbantartó személyzetet vagy akár a családtagokat. Az ilyen emberi kapcsolatokra épülő támadások sok esetben csak nagyon lassan derülnek ki.A jogosulatlan adatelérésre vágyó személyek a hagyományos módszereket is kipróbálhatják, és megpróbálhatnak közvetlenül hozzáférni a hardvereszközökhöz. Éppen ezért a gépet mindenféle beavatkozás ellen érdemes védeni, hogy senki ne távolíthassa el, cserélhesse le vagy tehesse tönkre az alkatrészeit. Ez a biztonsági mentésekre, valamint a hálózati és tápkábelekre is vonatkozik. Biztonságossá kell tenni a rendszerindítási folyamatot is, mivel vannak olyan jól ismert billentyűkombinációk, amelyekkel nemkívánatos eredmények érhetők el. Ez ellen a BIOS és a rendszertöltő jelszavának beállításával lehet védekezni. Még mindig sok helyen használnak soros portokhoz csatlakozó soros terminálokat. A hálózati csatolókkal szemben ezeknek nincs szükségük hálózati protokollokra a gazdagéppel folytatott kommunikációhoz. Egy egyszerű kábelen vagy infravörös porton sima karakterek haladnak át az eszközök között. Az ilyen rendszerek leggyengébb pontja maga a kábel: egy erre csatlakoztatott régebbi nyomtatóval egyszerűen rögzíthető minden, ami a vezetékeken keresztülmegy. Ami egy nyomtató számára elérhető, az más módon is hozzáférhető, a támadásba fektetett erőfeszítéstől függően.

Egy fájl helyi gépen történő olvasásához más hozzáférési szabályokra van szükség, mint egy hálózati kapcsolat megnyitásához egy másik gépen futó szerver felé. Különbség van a helyi és a hálózati biztonság között. A határ ott húzódik, ahol a máshová küldendő adatokat csomagokba kell helyezni.

Helyi biztonság

A helyi biztonság a gép helyének fizikai környezetével kezdődik. Olyan helyre telepítse a gépet, ahol a biztonság megfelel az elvárásoknak. A helyi biztonság fő célja a felhasználók elkülönítése, így a felhasználók nem szerezhetik meg a többiek jogosultságait és személyazonosságát. Ez egy általánosan betartandó szabály, de különösen igaz a root felhasználóra, aki a legfőbb jogokat gyakorolja a rendszeren. A root bármely helyi felhasználó azonosságát magára veheti jelszó megadása nélkül és elolvashatja bármelyik helyileg tárolt fájlt.

Jelszavak

A Linux-rendszereken a jelszavak természetesen nem nyílt szövegként kerülnek tárolásra és a beírt szöveges karaktersorozat sem egyszerűen csak össze van vetve az eltárolt mintával. Ha ez lenne a helyzet, akkor a rendszeren lévő minden fiók veszélybe kerülne, ha valaki hozzáférne a jelszófájlhoz. Ehelyett a jelszavak titkosítva tárolódnak, minden beíráskor újból titkosításra kerülnek, és a két titkosított karaktersorozat kerül összehasonlításra. Ez azonban csak akkor nyújt nagyobb biztonságot, ha a titkosított jelszóból nem fejthető vissza az eredeti karaktersorozat.

Ez egy speciális algoritmussal érhető el, amelyet csapóajtó (trapdoor) algoritmusnak is hívnak, mivel csak egy irányba működik. A titkosított karaktersorozatot megszerző támadó hiába ismeri az algoritmust, nem tudja egyszerűen, az algoritmus alkalmazásával megszerezni a jelszót. Ehelyett az összes lehetséges karakterkombinációt ki kell próbálnia, amíg nem talál egy olyan kombinációt, ami titkosítva úgy néz ki, mint a jelszó. Nyolc karakter hosszúságú jelszó esetén meglehetősen sok kombinációt kell kiszámoltatni.

A hetvenes években bizonyították, hogy ez a metódus a használt algoritmus viszonylagos lassúsága miatt sokkal biztonságosabb a többinél, mivel egy jelszó titkosítása eltart néhány másodpercig. Időközben azonban a PC-k teljesítménye kellően megnövekedett ahhoz, hogy több százezer vagy millió titkosítást végezzenek másodpercenként. Éppen ezért ma már a felhasználók a titkosított jelszavakat sem láthatják (az /etc/shadow fájlt a felhasználók nem olvashatják). Ami még fontosabb, hogy a jelszavak ne legyenek egyszerűen kitalálhatók abban az esetben, ha a jelszófájl egy esetleges hiba miatt láthatóvá válik. Következésképpen nem túl hasznos például a »micimacko« jelszót »m1c1m@ck0« értékre »lefordítani«.

A szó néhány betűjének hasonlóan kinéző számokkal való helyettesítése nem elég biztonságos. A szavak megfejtéséhez szótárakat használó jelszótörő-programok is alkalmaznak hasonló behelyettesítéseket. Jobb módszer egy olyan szó létrehozása, amelynek nincsen általános jelentése; egy olyan szóé, ami csak az adott személy számára értelmes, például egy mondat szavainak vagy egy könyv címének első betűi, mint például Umberto Eco »A rózsa neve« című könyve. Ez az alábbi biztonságos jelszót adja: »U3Arn9«. Ezzel szemben a »borbarat«, »kati72« és hasonló jelszavakat egyszerűen kitalálhatja egy olyan személy, aki egy kicsit ismeri a felhasználót.

A rendszerindítási folyamat

Állítsa be a rendszert úgy, hogy ne lehessen hajlékonylemezről vagy CD-ről elindítani: vagy azzal, hogy teljesen eltávolítja ezeket a meghajtókat, vagy azzal, hogy beállít egy BIOS-jelszót és megadja, hogy a rendszer csak merevlemezről indulhasson. A Linux-rendszert általában egy rendszertöltő indítja el, amely lehetőséget ad arra, hogy további paramétereket adjon át az elindított kernelnek. A /boot/grub/menu.lst fájlban egy további jelszó beállításával (A rendszertöltő) akadályozza meg, hogy mások ilyen paramétereket adhassanak meg a rendszerindítás során. Ez kritikus fontosságú a rendszer biztonsága szempontjából. A kernel nemcsak hogy maga is root jogosultságokkal fut, de ő az első, aki a rendszerindítás során root jogosultságokat oszt ki.

Fájljogosultságok

Általános szabályként mindig a lehető legkorlátozottabb jogosultságokat kell használni az adott feladathoz. E-mail olvasásához vagy írásához például biztosan felesleges root jogosultság. Ha a levelezőprogramban hiba van, akkor ezt ki lehet használni egy olyan támadáshoz, amely pontosan azokkal a jogosultságokkal zajlik, mint amelyekkel a program rendelkezett induláskor. A fenti szabályt követve a lehető legkisebbre csökkenthető a potenciális kár.

A SUSE disztribúció több mint 200 ezer fájljának jogosultságait körültekintően kell megválasztani. A kiegészítő szoftvereket vagy egyéb fájlokat telepítő rendszeradminisztrátornak körültekintően kell eljárnia, különösen a jogosultságbitek beállításakor. A tapasztalt és a biztonságot szem előtt tartó rendszeradminisztrátorok mindig a -l paraméterrel használják az ls parancsot, és egy bővebb fájllistát jelenítenek meg, amelyben azonnal észlelhetők a nem megfelelő fájljogosultságok. Egy nem megfelelő fájlattribútum nemcsak azt jelenti, hogy a fájlok módosíthatók vagy törölhetők. Ezeket a módosított fájlokat a root felhasználó hajthatja végre, illetve konfigurációs fájlok esetén a programok az ilyen fájlokat root jogosultságokkal használhatják. Ez jelentősen növeli egy támadó esélyeit. Az ilyen támadásokat kakukktojásoknak (cuckoo eggs) hívják, mivel a programot (a tojást) egy másik felhasználó (madár) hajtja végre (költi ki) hasonlóan ahhoz, ahogy a kakukk másik madarat vesz rá, hogy költse ki a tojásait.

A SUSE LINUX rendszer a következő fájlokat tartalmazza az /etc könyvtárban: permissions, permissions.easy, permissions.secure és permissions.paranoid. Ezeknek a fájloknak az a célja, hogy speciális jogosultságokat határozzanak meg, például bárhonnan írható könyvtárakat, vagy fájlok esetében megadják a set user ID bitet (a set user ID bittel rendelkező programok nem az ezeket elindító felhasználó jogosultságaival futnak, hanem a fájl tulajdonosának – a legtöbb esetben a root felhasználónak a jogosultságaival). Az adminisztrátor az /etc/permissions.local fájl segítségével saját beállításokat adhat meg.

Annak meghatározásához, hogy a SUSE konfigurációs programjai melyik fenti fájlokat használják a megfelelő jogosultságok beállításához, a YaST szoftverben válassza ki a Biztonság menüpontot. A témakörrel kapcsolatos további informácót az /etc/permissions megjegyzései és a chmod kézikönyvoldala tartalmaz (man chmod).

Puffertúlcsordulások és formátum-karaktersorozat hibák

Különleges körültekintéssel kell eljárni, amikor a programnak olyan adatokat kell feldolgoznia, amelyet a felhasználó módosíthat vagy módosíthatott, de ez inkább az alkalmazásprogramozó problémája, mint a normál felhasználóké. A programozónak vigyáznia kell arra, hogy az alkalmazás megfelelően értelmezze az adatokat, ne történhessen meg, hogy az adatok tárolásához túl kicsi memóriaterületekre ír. A programnak is következetes módon kell átadnia az adatokat az erre a célra meghatározott felületeken keresztül.

Puffertúlcsordulás akkor történhet, ha a memóriapuffer aktuális mérete a pufferbe íráskor nem kerül figyelembevételre . Ez olyan esetekben fordul elő, amikor a felhasználó által előállított adat több területet használ fel, mint amennyi a pufferben rendelkezésre áll. Ennek eredményeképp az adatok a pufferterület végén túlra íródnak, ami bizonyos körülmények között lehetővé teszi, hogy a program a felhasználói adatok egyszerű feldolgozása helyett a felhasználó (és nem a programozó) által befolyásolt programkódot hajtson végre. Az ilyen típusú hibáknak komoly következményei vannak, különösen akkor, ha a program speciális jogosultságokkal kerül végrehajtásra (Fájljogosultságok).

A formátum-karaktersorozat hibák némileg eltérő módon működnek, de ez ismét egy olyan felhasználói bemenet, amely rossz irányba viszi a programot. A legtöbb esetben ezek a programozási hibák a speciális jogosultságokkal rendelkező programok – a setuid és setgid programok – esetén kerülnek kihasználásra. Ez szintén azt jelenti, hogy az adatok és a rendszer úgy védhetők az ilyen hibák ellen, hogy a megfelelő jogosultságok elávolításra kerülnek a programokról. A legjobb módszer a lehető legalacsonyabb szintű jogosultságok alkalmazása (Fájljogosultságok).

Mivel a puffeltúlcsordulások és a formátum-karaktersorozat hibák a felhasználói adatok kezelésével kapcsolatos hibák, nemcsak akkor használhatók ki, ha egy helyi fiók rendelkezik hozzáféréssel. A jelentett hibák nagy része egy hálózati kapcsolaton keresztül is kihasználható. Ennek megfelelően a puffertúlcsordulásokat és formátum-karatersorozat hibákat úgy kell osztályozni, hogy a helyi és a hálózati biztonság szempontjából is lényegesek.

Vírusok

Szemben azzal, amit néhányan mondanak, vannak Linuxon futó vírusok is. Az ismert vírusokat a szerzők az elv igazolásaként készítették, bizonyítva, hogy az alkalmazott technika valóban működik. Eddig ezen vírusok egyike sem szabadult még el.

A vírusok nem maradhatnak életben és nem terjedhetnek olyan gazdarendszer nélkül, amelyeken megtelepedhetnének. A mi esetünkben a gazdarendszer lehet egy program vagy a rendszer egy fontos tárolóterülete, mint például a master boot rekord, amelynek a vírus programkódja számára írhatónak kell lennie. A többfelhasználósság miatt a Linux az írási hozzáférést bizonyos fájlok esetén korlátozhatja. Ez különösen a rendszerfájlok esetén fontos. Ha a szokásos munkát root jogosultságokkal végzi, akkor megnöveli annak esélyét, hogy a rendszert vírus fertőzze meg. Ha ezzel szemben a fent említett lehető legalacsonyabb jogosultságok alapelvét követi, akkor a vírusfertőzés esélye kicsi.

Nem érdemes továbbá olyan internetes forrásból programot telepíteni, amelyet nem ismer igazán. A SUSE RPM csomagjai kriptográfiai aláírást tartalmaznak, így afféle digitális címkék formájában jelzik, hogy a csomagok a megfelelő gondossággal lettek elkészítve. A vírusok megjelenése tipikus jele annak, hogy az adminisztrátor vagy a felhasználó nem rendelkezik a szükséges biztonsági ismeretekkel és veszélyezteti a rendszert, amelyet a tervezés legelső lépésétől kezdve nagyon biztonságossá kell tenni.

A vírusokat nem szabad összekeverni a férgekkel (worm), amelyek teljes mértékben a hálózatok világához tartoznak. A férgek terjedéséhez nincs szükség gazdagépre.

Hálózati biztonság

A hálózati biztonság kialakítása fontos, hogy védettek legyünk a kívülről indított támadásokkal szemben. A felhasználó hitelesítéséhez felhasználónevet és jelszót bekérő szokásos bejelentkezési folyamat továbbra is helyi biztonsági kérdés. Abban a speciális esetben, amikor a bejelentkezés hálózaton keresztül történik, meg kell különböztetni a két biztonsági aspektust. A tényleges hitelesítésig történő dolgok a hálózati biztonság tárgykörébe tartoznak, ami pedig utána következik, az már a helyi biztonságéba.

X Window rendszer és X hitelesítés

Ahogy már az elején is szó volt róla, a hálózat átlátszósága a UNIX rendszer egyik központi jellemzője. Az X, a UNIX operációs rendszer ablakkezelő rendszere igen látványosan képes ezt a funkciót kihasználni. X használata esetén teljesen normális dolog bejelentkezni egy távoli gépen és elindítani egy grafikus programot, amely azután adatokat küld át a hálózaton, amelyek megjelennek a saját gépünkön.

Amikor az X klienst távolról kell megjeleníteni egy X szerver segítségével, a szervernek meg kell védenie az általa kezelt erőforrást (azaz a megjelenítőt) a hitelesítés nélkül eléréstől. Konkrétabban: a kliensprogram számára meg kell adni bizonyos jogosultságokat. X Window rendszerrel ez kétféleképpen hajtható végre; a két módszer neve gép alapú hozzáférés-vezérlés és cookie alapú hozzáférés-vezérlés. Az előbbi annak a gépnek az IP-címére épül, amelyen a kliensnek futnia kell. Az ezt vezérlő program az xhost. Az xhost megadja egy legális kliens IP-címét az X szerverhez tartozó kis adatbázisban. Az IP-cím alapú hitelesítés azonban nem túl biztonságos. Ha például egy második felhasználó is használja a kliensprogramot küldő gépet, akkor ez a felhasználó az X szerverhez is hozzáférhet – ugyanúgy, mint az, aki ellopja az IP-címet. E hibák miatt ez a hitelesítési mód nem is kerül részletesebben leírásra itt, de a man xhost parancs használatával többet is megtudhat róla.

Cookie alapú hozzáférés-vezérlés esetén a rendszer létrehoz egy karaktersorozatot, amelyet csak az X szerver és a jogosult felhasználó ismer – ez olyan, mint valami azonosítókártya. Ez a cookie (a szó nem a szokásos sütikből ered, hanem a kínai szerencsesütikből, amelyek mindegyike egy mondást tartalmaz) a felhasználó saját könyvtárában található .Xauthority fájlban kerül tárolásra, és minden X kliens számára rendelkezésére áll, amely az ablak megjelenítéséhez az X szerver használatára vár. A felhasználó az xauth eszköz segítségével megvizsgálhatja az .Xauthority fájlt. Ha átnevezte az .Xauthority fájlt vagy véletlenül törölte a saját könyvtárból, akkor nem nyithatók meg új ablakok és X kliensek. Az X Window rendszer biztonsági mechanizmusaival kapcsolatos további információt az Xsecurity kézikönyvoldala tartalmaz (man Xsecurity).

Az SSH (secure shell) segítségével a hálózati kapcsolat teljesen titkosítható és átlátszó módon továbbítható egy X szerver számára anélkül, hogy a felhasználó észrevenné a titkosítási mechanizmust. Ezt X továbbításnak (X forwarding) is nevezik. Az X továbbítás a szerveroldalon egy X szerver szimulálásával, a távoli gépen pedig egy DISPLAY környezeti változó beállításával valósítható meg. Az SSH-val kapcsolatban további részletek: SSH: Biztonságos hálózati műveletek.

Icon-Caution.png Figyelmeztetés!

Ha azt a gépet, amelyre bejelentkezett, nem tekinti biztonságosnak, akkor ne használjon X továbbítást. Engedélyezett X továbbítással egy támadó az SSH-kapcsolaton keresztül hitelesítheti magát az X szerverére, és ha már behatolt, akkor figyelheti például a billentyűzetbemenetet.

Puffertúlcsordulások és formátum-karaktersorozat hibák

Amint már szó esett róla (Puffertúlcsordulások és formátum-karaktersorozat hibák), a puffertúlcsordulásokat és formátum-karaktersorozat hibákat a helyi és hálózati biztonságot is egyaránt érintőként kell kezelni. Hasonlóan az ilyen hibák helyi változataihoz, a hálózati programok puffertúlcsodulásait sikeresen kihasználók általában root jogosultságokat igyekeznek szerezni. Még ha nem is ez a helyzet, egy támadó akkor is kihasználhatja a hibát arra, hogy megszerezze egy nem kiváltságos felhasználói fiók elérését a rendszeren esetleg előforduló egyéb gyenge pontok kiaknázására.

A hálózati kapcsolaton keresztül kihasználható puffertúlcsordulások és formátum-karaktersorozat hibák a távoli támadások leggyakoribb formái. Ezek kihasználásának módjai – az újonnan megtalált biztonsági réseket kihasználó programok – gyakran felkerülnek a biztonsági levelezési listákra. Ezek segítségével a gyenge pont a kód részleteinek ismerete nélkül is célba vehető. Az évek során a tapasztalat azt mutatta, hogy a hibákat kihasználó kódok elérhetősége szerepet játszott a még biztonságosabb operációs rendszerek kifejlesztésében, nyilvánvalóan azzal, hogy az operációs rendszerek készítői kényszerítve voltak a szoftvereikban található hibák kijavítására. Szabad szoftver esetén bárki hozzáférhet a forráskódhoz (a SUSE LINUX-ot az összes rendelkezésre álló forráskóddal együtt adják ki) és bárki, aki gyenge pontot és ezt kihasználó kódot talál, javítást küldhet a megfelelő hiba kijavításához.

DoS – szolgáltatás megbénítása (Denial of Service)

Az ilyen támadás célja egy szerverprogram vagy egy teljes szerver blokkolása, ami többféle módon érhető el: a szerver túlterhelése, illetve leterhelve tartása rossz csomagokkal; vagy egy távoli puffertúlcsordulás kihasználása. A DoS támadások egyetlen célja legtöbbször a szolgáltatás kiiktatása. Ha egy adott szolgáltatás elérhetetlenné válik, akkor a kommunikáció sebezhető lesz a köztes támadásokkal (lehallgatás, TCP-kapcsolat eltérítése, hamisítás), valamint a DNS-hamisítással szemben.

Köztes támadások: lehallgatás, eltérítés, hamisítás

Általában minden olyan távoli támadást köztes támadásnak hívunk, amikor a támadó a kommunikáló gépek közé áll. Majdnem minden köztes támadásra jellemző, hogy az áldozat általában észre sem veszi, hogy valami történik. Számos különböző változat létezik, például a támadó elfoghat egy kapcsolatkérést és maga továbbíthatja a célgép számára. Ezután az áldozat tudtán kívül kapcsolatot teremt egy rossz géppel, mivel a másik végpont átveszi a legális célgép helyét.

A köztes támadás legegyszerűbb formáját lehallgatásnak (sniffing) hívják– a támadó »csak« figyeli az átmenő hálózati forgalmat. Összetettebb támadás, ha a »köztes« támadó egy már felépített kapcsolatot próbál meg átvenni (eltérítés). Ehhez a támadónak elemeznie kell egy ideig a csomagokat, hogy meg tudja jósolni a kapcsolathoz tartozó TCP-sorozatszámokat. Amikor a támadó végül átveszi a célgép szerepét, az áldozat észreveszi, mivel hibaüzenetet kap, amely jelzi, hogy a kapcsolat hiba miatt megszakadt.

Az eltérítéssel szemben titkosítással nem védett protokollok, amelyek csak egy egyszerű hitelesítési eljárást hajtanak végre a kapcsolat létrehozásakor, leegyszerűsítik a támadók dolgát.

A hamisítás (spoofing) egy olyan támadás, amelyben a csomagok módosításra kerülnek, hogy hamis forrásadatokat (legtöbbször IP-címet) tartalmazzanak. A támadás aktívabb formái ilyen hamis csomagok küldésére épülnek – ilyet Linux-gépen csak az adminisztrátor (a root) tehet.

Az említett támadások nagy részét DoS támadással együtt hajtják végre. Ha egy támadó lehetőséget lát arra, hogy egy adott gépet váratlanul leterheljen – hacsak egy rövid időre is – akkor ez egyszerűbbé teszi számára egy aktív támadás végrehajtását, mivel a gép egy ideig nem tud beavatkozni a támadásba.

DNS-hamisítás

A DNS-hamisítás azt jelenti, hogy a támadó módosítja a DNS-szerver gyorsítótárát azáltal, hogy hamisított DNS-válaszcsomagokkal válaszol és megpróbálja rábírni a szervert bizonyos adatok küldésére a szervertől információt kérő áldozatnak. Számos szerver IP-címek vagy gépnevek alapján bizalmi kapcsolatokat tart fenn más gépekkel. A támadónak jól kell ismernie a gépek közötti bizalmi kapcsolat tényleges felépítését ahhoz, hogy magát megbízható gépnek álcázza. A támadó a szükséges információ megszerzéséhez általában elemzi a szervertől kapott néhány csomagot. A támadónak gyakran egy jól időzített DoS támadást kell indítania a névszerveren is. Védekezzen ez ellen úgy, hogy csak titkosított kapcsolatokat használ, amelyek képesek ellenőrizni a túloldali gépnek az azonosságát.

Férgek

A férgeket (worm) általában keverik a vírusokkal, pedig a kettő között határozott különbség van. A vírusokkal ellentétben a férgeknek a működéshez nem kell megfertőzniük a gép valamely programját. Ehelyett arra specializálódtak, hogy a lehető leggyorsabban terjedjenek a hálózati struktúrákban. A régebben megjelent férgek, mint például a Ramen, a Lion vagy az Adore, a szerverprogramok – például bind8 vagy lprNG – jól ismert biztonsági réseit használják ki. A férgek elleni védekezés viszonylag könnyű. Mivel a biztonsági rés felfedezése és a féreg támadása között eltelik egy kis idő, jó esély van arra, hogy az érintett program frissített változata időben megjelenjen. Ez csak akkor hasznos, ha az adminisztrátor a kérdéses rendszeren valóban telepíti a biztonsági frissítéseket.

Néhány általános biztonsági tipp és trükk

A biztonság megfelelő kezelése érdekében figyelemmel kell kísérni az új fejlesztéseket és ismerni kell a legfrissebb biztonsági problémákat. A rendszer mindenfajta problémák elleni védelmének egyik lehetséges módja a biztonsági közlemények által javasolt frissítési csomagok lehető leggyorsabb telepítése. A SUSE biztonsági közlemények a következő levelezési listán kerülnek közreadásra, ami az alábbi címen lehet feljelentkezni: http://www.novell.com/linux/security/securitysupport.html. A suse-security-announce@suse.de listán első kézből értesülhet a frissítési csomagokkal kapcsolatos tudnivalókról és a SUSE biztonsági csoportjának tagjai is az aktív listatagok között vannak.

A suse-security@suse.de levelezési lista kiváló hely bármilyen biztonsági kérdés felvetésére. A listára a suse-security-announce@suse.de fent megadott URL-jén lehet feliratkozni.

A bugtraq@securityfocus.com a világ egyik legismertebb biztonsági listája. Ajánljuk a lista olvasását (naponta kb. 15-20 levél érkezik) rá. További információ: http://www.securityfocus.com.

Az alábbi szabálylista az alapszintű biztonsági megfontolások kezeléséhez nyújt hasznos segítséget:

  • A mindennapos feladatok lehető legkorlátozottabb jogosultsággal való elvégzését előíró szabálynak megfelelően a rendszeres feladatokat ne root felhasználóként hajtsa végre. Ez csökkenti a kakukktojások és vírusok saját hiba miatti érkezését.
  • Ha lehetséges, akkor mindig titkosított kapcsolatot alkalmazzon egy távoli gép használatához. telnet, ftp, rsh és rlogin helyett mindig érdemes az ssh-t (secure shell) használni.
  • Kerülje a csak IP-címekre épülő hitelesítési módszerek használatát.
  • A hálózattal kapcsolatos legfontosabb csomagokból mindig telepítse a legfrissebb változatot és jelentkezzen fel a megfelelő levelezési listákra, hogy értesüljön a megfelelő programok (bind, sendmail, ssh stb.) új verzióiról. Ugyanez igaz a helyi biztonság szempontjából fontos szoftverekre is.*A rendszer biztonsága szempontjából kritikus fontosságú fájlok jogosultságainak módosítása érdekében módosítsa az /etc/permissions fájlt. Ha eltávolította egy programról a setuid bitet, akkor elképzelhető, hogy nem tudja a kívánt módon végrehajtani a feladatát, azonban nem jelent további biztonsági kockázatot. Hasonló megközelítés alkalmazható a mindenki számára írható könyvtárak és fájlok esetében is.
  • A szerver működéséhez nem elegendhetetlenül szükséges hálózati szolgáltatásokat tiltsa le. Ez biztonságosabbá teszi a rendszert. A LISTEN socket állapottal rendelkező nyitott portok a netstat programmal kereshetők meg. Ami a paramétereket illeti, érdemes a netstat -ap vagy netstat -anp formában használni a parancsot. A -p opció lehetővé teszi annak megtekintését, hogy melyik eljárás milyen néven foglal le portot.
  • Hasonlítsa össze a netstat eredményeit azzal, amelyet egy, a gépen kívülről kezdeményezett portelemzés eredményez. E feladatra megfelelő program az nmap, amely nem csak a gép portjait ellenőrzi, hanem ebből következtet is arra, hogy mely szolgáltatások várnak ezek mögött. A portelemzés azonban rosszindulatú cselekménynek is minősülhet, így ne hajtsa végre olyan gépen, ahol az adminisztrátor kifejezetten nem hagyta jóvá. Végül ne feledje el, hogy nem csak a TCP-portokat kell elemezni, hanem az UDP-portokat is (-sS és -sU opciók).
  • A rendszer fájlintegritásának megbízható módon történő megfigyeléséhez használja a SUSE LINUX disztribúcióban megtalálható tripwire programot. Titkosítsa a tripwire által létrehozott adatbázist a módosítás megakadályozásához. A gépen kívül, egy hálózatra nem csatlakoztatott adathordozón tartson fenn az adatbázisról egy biztonsági másolatot.
  • Harmadik féltől származó szoftver telepítésekor megfelelő körültekintéssel járjon el. Előfordult már, hogy egy cracker egy trójai programot épített be a biztonsági szoftvercsomag tar archív állományába, de ezt szerencsére gyorsan észrevették. Ha kétségei vannak egy adott webhellyel kapcsolatban, ne telepítse az onnan letöltött bináris csomagokat.*A SUSE RPM csomagjai gpg-aláírással vannak ellátva. A SUSE által az aláíráshoz használt kulcs:
  • ID:9C800ACA 2000-10-19 SUSE Package Signing Key <build@suse.de>
  • Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
  • Az rpm --checksig package.rpm parancs megmutatja, hogy az eltávolított csomag aláírása és ellenőrzőösszege helyes-e. A kulcs a disztribúció első CD-jén és a legtöbb kulcsszerveren megtalálható.
  • Rendszeres időközönként ellenőrizze a felhasználók és a rendszerfájlok biztonsági mentéseit. Gondoljon arra, hogyha nem ellenőrzi, hogy a mentés működik-e, akkor az lehet, hogy teljesen értéktelen.
  • Ellenőrizze a naplófájlokat. Hacsak lehetséges, írjon egy kis parancsfájlt a gyanús bejegyzések megkereséséhez. Ez kétségkívül nem egyszerű feladat. A végén csak azt tudhatja, hogy mely bejegyzések szokatlanok és melyek nem.
  • A tcp_wrapper segítségével korlátozhatja a gépen futó egyedi szolgáltatások elérését, így explicit módon vezérelheti, hogy melyik IP-címek csatlakozhatnak egy szolgáltatáshoz. A tcp_wrapper-rel kapcsolatos további információrt tekintse meg a tcpd és hosts_access man oldalait (man 8 tcpd, man hosts_access).
  • A SuSEfirewall segítségével javítható a tcpd által kínált biztonság (tcp_wrapper).
  • A biztonsági intézkedéseket redundánsra tervezze: a kétszer megjelenő üzenet jobb, mint ha nincs üzenet.

Központi biztonsági bejelentési cím

Biztonsággal kapcsolatos problémák észlelése esetén (először ellenőrizze a rendelkezésre álló frissítési csomagokat) írjon egy e-mailt az alábbi címre: security@suse.de. Adja meg a probléma részletes leírását és az érintett csomag verziószámát. A SUSE mindent megtesz, hogy a lehető leggyorsabban válaszoljon. Az e-mail üzeneteket bátran titkosítsa pgp segítségével. A SUSE pgp kulcsa az alábbi:
ID:3D25D3D9 1999-03-06 SUSE Security Team <security@suse.de>
Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5

Ez a kulcs a http://www.novell.com/linux/security/securitysupport.html címről is letölthető.