Fehér Könyv (technikai)
www.balabit.com
SSH auditálás és „4-eyes” autorizáció Kivonat: Státusz: Verzió:
Hogyan segíti elő a Zorp legfontosabb szervereinek védelmét és auditálását? Kiadva 1.1
Dátum:
2006-04-13
Introduction
© 2006 BalaBit IT Security
Tartalomjegyzék
Tartalomjegyzék Előszó...............................................................................................................................................................3 1. Bevezetés.....................................................................................................................................................4 1.1. A Secure Shell protokollról dióhéjban...................................................................................................4 2. Az SSH működése........................................................................................................................................5 2.1. Az SSH alapjai......................................................................................................................................5 2.2. Az SSH problémái.................................................................................................................................5 3. A Zorp SSH proxy képességei......................................................................................................................6 3.1. Általános jellemzők...............................................................................................................................6 3.1.1. Az SSH kulcsok kezelése.............................................................................................................6 3.2. Forgalom auditálása.............................................................................................................................7 3.3. „4-eyes” autorizáció...............................................................................................................................8 3.3.1. A „4-eyes” alkalmazásának módjai...............................................................................................9
www.balabit.com
2/10
Előszó
Előszó Ebben a dokumentumban a Zorp új megoldásait mutatjuk be az érzékeny információkhoz való hozzáférés, valamint az üzletileg kritikus szerverek adminisztrálásának auditálására. Habár a témát főként a Zorp alkalmazásszintű tűzfal szempontjából tárgyaljuk, általános referenciaként is használható, így a Zorp adminisztrátorokon és IT biztonsági szakértőkön kívül mindenki számára hasznos lehet, akit érdekelnek a hálózati biztonsági kérdések. A bemutatott megoldások teljes megértéséhez a hálózatok és tűzfalak alapszintű ismerete hasznos, de nem elengedhetetlen. A bemutatásra kerülő eljárások és megoldások a Zorp 3.1-es verziójára vonatkoznak.
www.balabit.com
3/10
Előszó
1. Bevezetés Az első számítógépes hálózatokkal egyidőben jelent meg az igény olyan eszközökre, melyekkel egy számítógépet távolról el lehet érni. Hihetetlenül hasznos, ha egy adott gépet távolról elérhetünk egy terminálon keresztül, és ugyanúgy dolgozhatunk rajta, mintha csak előtte ülnénk. Szervereket adminisztrálhatunk, állományokhoz férhetünk hozzá, nagy teljesítményű gépeken távolról futtathatunk bonyolult számításokat, stb., anélkül, hogy fizikailag hozzáférnénk a géphez. Mindent elvégezhetünk akár a világ túlsó feléről is, pusztán csak hálózati hozzáférés és egy megfelelő alkalmazás szükséges. Hamar megszülettek az ilyen alkalmazások (mint például a TELNET), azonban ezek nem foglalkoztak a biztonság kérdésével. Az adatokat titkosítatlanul, szöveges formátumban továbbították, így a rosszindulatú támadók könnyen megszerezhettek érzékeny adatokat (pl.: a rendszergazda jelszavát), csak a helyi hálózati forgalmat kellett figyelniük. A Secure Shell (SSH) protokollt hálózatba kötött gépek távoli elérésére fejlesztették ki azzal a céllal, hogy kiváltsa a korábban használt titkosítatlan protokollokat (pl.: rlogin, TELNET, rsh), és lehetővé tegye a biztonságos, titkosított kommunikációt két gép között egy megbízhatatlan hálózaton keresztül is. Az SSH ezen kívül képes tetszőleges TCP port és X11 kapcsolatok titkosított továbbítására, valamint fájlok továbbítására a beágyazott SFTP vagy SCP protokollok segítségével.
1.1. A Secure Shell protokollról dióhéjban Az eredeti protokollt (SSH-1, 1995) 1996-ban továbbfejlesztették, így létrejött az SSH-2 protokoll, amely számos újdonságot és továbbfejlesztett biztonsági megoldásokat tartalmaz. A két verzió nem kompatibilis egymással, és mivel az SSH-1 protokoll tervezési hibái miatt sérülékeny, elavultnak tekintendő, így használata nem biztonságos és nem is javasolt. Gyakorlatilag az összes mai szerver- és kliensalkalmazás támogatja az SSH-2 protokollt, az SSH-1 használatát le kell tiltani. Sajnálatos módon egyes helyeken még manapság is használnak olyan alkalmazásokat, amelyek csak az SSH-1 verziót támogatják, így jelentős biztonsági kockázatot jelentenek. Az SSH ma a rendszeradminisztráció legelterjedtebb eszköze. Az SSH protokollnak számos különböző implementációja van, gyakorlatilag minden platformra elérhető (Windows, Linux, Unix, Mac OS X, BSD, stb.), a beágyazott rendszerektől kezdve az asztali számítógépeken át a mainframe-ekig. A különböző implementációk eltérhetnek az elérhetőségükben (nyílt forráskódú, ingyenes, kereskedelmi), valamint a teljességükben: egyes alkalmazás csak a protokoll bizonyos részeit implementálják, pl.: a WinSCP csak biztonságos fájlműveleteket hajt végre.
www.balabit.com
4/10
Előszó
2. Az SSH működése Ebben a fejezetben az SSH protokoll jellemzőit és koncepcióit mutatjuk be.
2.1. Az SSH alapjai Az SSH protokoll egyik fő jellemzője, hogy a kliens és a szerver között szinte a teljes kommunikáció titkosított – beleértve a felhasználó autentikálását is. (Természetesen az alkalmazott rejtjelezési eljárás megbeszélése nyílt üzenetekben történik.) A kapcsolat inicializálásakor történik a szerver autentikálása, valamint a rejtjelezési, adattömörítési, és a továbbított adatok sértetlenségének ellenőrzésére vonatkozó paraméterek megbeszélése. A protokoll kötelező része a felhasználó autentikálása is, ami különböző módszerekkel történhet, pl.: jelszó, RSA kulcs, Challenge/Response megoldások (S/Key, OPIE), stb. Az SSH tipikus felhasználási területei a következők: • •
•
• •
•
Távoli elérés (remote shell): Egy számítógép karbantartása távolról, interaktív terminál konzolon keresztül. Ez az SSH legelterjedtebb felhasználási módja. Távoli parancsvégrehajtás: Utasítások végrehajtása a távoli gépen. Egyes parancsok igen jelentős adatforgalmat eredményezhetnek, pl.: kézi vagy automatikus fájl másolás (scp), adat szinkronizálás (rsync), biztonsági mentések készítése (tar), stb. TCP IP továbbítás (más néven port forwarding): Bármilyen TCP/IP kapcsolat átvihető a kliensről vagy a szerverről a másik félhez a titkosított SSH csatornában. Ezáltal az SSH használható nem megengedett kommunikáció továbbítására is, így például a biztonsági politikában tiltott portok elérésére. Másfelől a TCP továbbítás segítségével bármilyen más – egyébként titkosítatlan – kommunikáció titkosítható, és gyakran használják két gép közti kapcsolat teljes titkosítására, mivel így nem szükséges egy teljes VPN kapcsolat kiépítése. Fájlműveletek: Állományok biztonságos másolása SFTP segítségével. X11 továbbítás: A szerveren futó, grafikus (X) felületet igénylő alkalmazások a kliens monitorán jelennek meg, de minden más szempontból a szerveren futnak, így lehetséges távolról is dolgozni velük. Agent továbbítás: Autentikációs kérések továbbítása a kliens gépére.
Az SSH kapcsolatban zajló kommunikáció ellenőrzése A szerver- és kliensalkalmazástól függően lehetséges egyetlen kapcsolaton belül több csatorna adatait is továbbítani, így például SFTP-n keresztül fájlokat másolni, és eközben a szerver beállításait karbantartani.
2.2. Az SSH problémái Mivel elterjedten használják szerverek adminisztrálására, az SSH a támadások gyakori célpontjává vált, beleértve a brute-force jelszófeltörési, valamint a különböző implementációkban talált sérülékenységek kihasználását célzó támadásokat is. Számos vírus is használ ilyen jellegű támadásokat.
www.balabit.com
5/10
Előszó
3. A Zorp SSH proxy képességei Ebben a fejezetben bemutatjuk a Zorp SSH proxy képességeit, valamint azt, hogy milyen biztonsági intézkedéseket lehet a segítségével megvalósítani.
3.1. Általános jellemzők A Zorp SSH proxy man-in-the-middle (MITM) technika segítségével dekódolja és a tűzfalon végződteti az SSH kapcsolatokat. Minden kapcsolatot két részre bont (kliens-Zorp és Zorp-szerver), és ellenőrzi a teljes átmenő forgalmat, így semmilyen adat nem továbbítható közvetlenül a szerver és a kliens között. A Zorp kizárólag az SSH-2 protokollt támogatja, de az SSH-2 elterjedtsége miatt ez semmilyen hátrányt nem jelent. A Zorp SSH proxy főbb képességeit az alábbiakban foglaltuk össze. Protokoll ellenőrzés: A proxy ellenőrzi a teljes SSH forgalmat, és csak akkor engedi át, ha teljesen megfelel az SSH-2 protokoll specifikációjának. Ezzel a Zorp hatékony védelmet biztosít számos, a szerver- és kliensalkalmazások sérülékenységeit (pl.: túlcsordulásokat) kihasználó támadások ellen. Rejtjelezési módszer ellenőrzése: A Zorp ellenőrizni tudja a kapcsolat belső paramétereit is, beleértve a kiválasztott titkosítási módot (cipher, kulcshossz, stb.), így védelmet nyújt a downgrade támadások ellen. Felhasználó autentikálásának ellenőrzése: A felhasználható autentikációs módszereket külön-külön lehet engedélyezni, így lehetőség van az erős autentikációs módszerek megkövetelésére a gyengébbek (pl.: jelszó) tiltásával. Felhasználó szintű szűrés és hozzáférés ellenőrzés is lehetséges. Habár ezeket a műveleteket természetesen magán a szerveren is el lehet végezni, a Zorp – mivel egy külső eszköz – akkor is megbízhatóan hajtja ezeket végre, ha a szerver vagy a kliens megbízhatatlanná válik (pl.: illetéktelen hozzáférés miatt). SSH csatornák felügyelete: A Zorp teljes mértékben felügyeli az SSH csatornákat, pontosan meghatározhatjuk, hogy az adott szerverről (vagy egy adott kapcsolatban) milyen csatornák engedélyezettek. Így például különböző feltételek alapján külön engedélyezhetőek/tilthatóak a fájlműveletek, a TCP IP továbbítás, az X továbbítás, stb. Agent továbbítás tiltása: A Zorp képes letiltani az agent továbbítást, így megakadályozható, hogy a belső hálózaton használt kulcsok külső gépeken elérhetővé váljanak. Távoli parancsvégrehajtás ellenőrzése: Mivel a Zorp teljes mértékben ellenőrzi az SSH kapcsolatokat, meghatározható, hogy mely parancsok engedélyezettek, illetve tiltottak. Bonyolultabb döntések is hozhatóak a kapcsolat különböző paraméterei alapján, pl.: csak bizonyos felhasználók hajthatnak végre egyes parancsokat, stb. A fenti feladatokat a Zorp a szervertől teljesen függetlenül, a szerver- és kliensalkalmazások szempontjából transzparensen hajtja végre, így nincs szükség az alkalmazások módosítására.
3.1.1. Az SSH kulcsok kezelése Ahhoz, hogy mind a szerver, mind a kliens felé ki lehessen építeni a kapcsolatot, a Zorpnak a megfelelő kulcsot kell felmutatnia a kliens felé, különben a kliens visszautasítja a kapcsolatot, mivel a kulcs nem egyezik meg a célszerver kulcsával. Ha a Zorp a szervereket védi, ezt a problémát könnyű elkerülni, csak a szerver kulcsát kell a Zorpon is elérhetővé tenni. Azonban ez nem lehetséges ha klienseket védünk, mivel általában nem áll rendelkezésre az összes célszerver privát kulcsa. Ilyen esetekben a Zorp SSH proxy képes automatikusan ellenőrizni a szerver kulcsát. Ez az SSL kapcsolatok tanúsítványának ellenőrzéséhez hasonlóan történik, de az SSH protokollban nem kapcsolódik tanúsítvány vagy más hasonló azonosító információ a kulcsokhoz. Alapvetően három lehetőségből lehet választani: 1. Elfogadunk bármilyen kulcsot. Ez természetesen nem biztonságos, így nem is elfogadható. 2. A publikus kulcsot hozzárendelhetjük egy adott IP cím – port párhoz, a known_hosts fájlhoz hasonlóan. Ismeretlen IP cím – port pár esetén a kapcsolatot megszakítjuk. 3. A 2-es megoldáshoz hasonlóan publikus kulcsokat rendelünk az IP cím – port párokhoz, de ismeretlen
www.balabit.com
6/10
Előszó pár esetén a felmutatott kulcsot hozzáadjuk a listához, és ettől kezdve erről az IP cím – port párról csak ezt a kulcsot fogadjuk el. A fentiekből látszik, hogy SSH esetén nincs lehetőség keybridgingre, mivel a publikus kulcsok nem tartalmaznak az X.509 tanúsítványokhoz hasonló azonosító információkat. A kliensek felé egy újonan generált kulcsot lehet csak mutatni, és későbbi felhasználásra tárolni.
3.2. Forgalom auditálása A Zorp segítségével lehetőségünk nyílik a hálózati forgalom megbízható, biztonságos rögzítésére, így a forgalom később elemezhető, és bizonyos események megvizsgálhatóak. Érzékeny rendszerek (pl.: pénzügyi szerverek) esetén gyakran szükséges igazolni, hogy bizonyos adatokat csak a megfelelő személyek értek el vagy módosítottak, vagy hogy egyáltalán nem módosították őket egy adott időpont után. Annak az igazolása is szükséges lehet, hogy az adatokhoz csak a megfelelő csatornákon (pl.: a megfelelő pénzügyi alkalmazáson) keresztül történt hozzáférés, és az adatokat senki sem módosította titokban közvetlenül például SSH kapcsolaton keresztül. Ily módon igazolható, hogy a szerveren tárolt adatok pontosak, és csak az ellenőrzött és rögzített változtatásokat hajtották rajtuk végre. Ilyen igazolásokra van szükség többek közt a Sarbanes-Oxley (SOX), a Health Insurance Portability & Accountability Act (HIPAA), a Basel II, és más hasonló szabályozások irányelveinek való megfeleléshez. A Zorp auditálási keretrendszere az SSH proxy révén képes az SSH csatornák forgalmát elkülönítve, fullduplex módon tárolni, így minden a szerverhez menő, illetve onnan jövő forgalom pontosan rögzíthető. Az adatok digitálisan aláírva, titkosítva tárolhatók, igazolva, hogy nem lettek módosítva, és egyúttal a jogosulatlan hozzáférést is megakadályozva. Minden tárolt adat és esemény később tetszőleges időpontban megtekinthető és visszajátszható. Mivel a Zorp csak a protokoll szabványainak teljesen megfelelő SSH forgalmat engedi át, és megérti az üzeneteket és utasításokat, az adatokat rendszerezett, könnyen áttekinthető formában tárolja.
SSH kapcsolatok auditálása A Zorp auditálási képességeinek egy fontos vonása, hogy használatához sem a szerver-, sem a kliensalkalmazást nem kell módosítani, továbbá a Zorp a klienstől és a szervertől is függetlenül üzemel, így akkor is pontos adatokat szolgáltat, ha a kliens vagy a szerver megbízhatatlanná válik. Ezáltal az auditálási
www.balabit.com
7/10
Előszó követelményeket megvalósító eszköz (a Zorp) teljesen különálló és független az auditált infrastruktúrától, aminek eredményeként könnyen integrálódik bármilyen környezetbe. Ugyanennek az éremnek a másik oldala, hogy a Zorp hatékonyan felhasználható különleges feladatokra, például honeypot rendszerek monitorozására, mivel az ilyen rendszereknél elengedhetetlen az átmenő forgalom pontos rögzítése anélkül, hogy ezt a támadó észrevenné. Az egyszerű hálózati hallgatózás (nework sniffing) erre a feladatra nem igazán alkalmas, mivel az SSH forgalom titkosított, azonban a Zorp SSH proxy könnyedén elérhetővé teszi ezt a forgalmat titkosítatlan formában is. (Természetesen a rögzített adatokat titkosítva tárolja, de a szükséges kulcsok és az adatok megtekintéséhez szükséges eszközök rendelkezésre állnak.)
3.3. „4-eyes” autorizáció Bizonyos feladatokat és folyamatokat – mint például kritikus rendszerek, pénzügyi adatok kezelése és karbantartása – nem lehet egyetlen személyre bízni, ezért számos helyen bevált gyakorlat, hogy bizonyos műveleteket csak akkor lehet végrehajtani, ha két jogosult személy is ellenőrizte. Ennek a megoldásnak a fő célja, hogy a véletlen vagy szándékos emberi hiba lehetőségét csökkentse a folyamat fokozott ellenőrzése segítségével anélkül, hogy a rendszer használhatóságát vagy a feladat elvégzéséhez szükséges időt lényegesen befolyásolná. Ennek az elvnek a tipikus felhasználási területei többek közt: • • • • •
hozzáférés bankszéfekhez; nagyösszegű átutalások végrehajtása; honlapok publikálása (csak akkor válik publikussá az oldal, ha egy szerkesztő ellenőrizte és jóváhagyta); rendelések és banki átutalások jóváhagyása vállalati menedzsment rendszerekben; különböző (pl.: katonai) döntéshozó rendszerek; stb.
A Zorp segítségével ezt a jól bevált koncepciót a rendszeradminisztrátorok munkájának ellenőrzésére is használhatjuk. Eddig erre nem, vagy csak nagyon körülményes és nehezen alkalmazható megoldások léteztek, mivel a rendszeradminisztráláshoz rendszergazdai jogosultságokra van szükség az adott szerveren, ami gyakorlatilag korlátlan hatalmat jelent az adott gép fölött. A legkisebb hiba, vagy egy pillanatnyi figyelemkiesés is súlyos következményekkel járhat. A „4-eyes” alapötlete az, hogy egyedül egy adminisztrátor sem jelentkezhet be a kérdéses gépre, és egyedül nem módosíthatja a konfigurációs állományokat. Csak két, egyszerre kapcsolódó és egymás munkáját folyamatosan ellenőrző adminisztrátor érheti el a szervert. Olyan rendszer kialakítása is lehetséges, ahol az ellenőrző adminisztrátor engedélyezi a másik hozzáférését a szerverhez. Az adminisztrátorok műveleteinek valósidejű követésére is van lehetőség.
www.balabit.com
8/10
Előszó Az elv alkalmazása jelentősen megnöveli a rendszeradminisztráció megbízhatóságát és auditálhatóságát – egy újabb ellenőrző és védelmi vonalat jelent azokon a területeken, ahol egyetlen személynek túl nagy befolyása lenne. Segítséget nyújt a szerveradminisztrálási folyamatok ellenőrzésében és betartásában is, megakadályozva, hogy egyvalaki károsíthassa a rendszert. Fontos megjegyezni, hogy önmagában a „4-eyes” autorizálás nem jelent tökéletes védelmet a külső támadókkal szemben, mivel azok a meglévő rendszer szabályait és ellenőrzéseit kijátszva férnek hozzá a rendszerhez.
3.3.1. A „4-eyes” alkalmazásának módjai A „4-eyes” autorizálás pontos működési módja az adott szervezet igényeinek megfelelően alakítható ki. A fő cél a bejelentkezés és a szerveren kiadott parancsok előzetes autorizálása és kontrollja, illetve bizonyos esetekben a folyamatos ellenőrzés megvalósítása. A működés alapja szinte minden esetbe az, hogy a Zorp SSH proxy felfüggeszti az eredeti SSH kapcsolatot, miután a felhasználó autentikálta magát egészen addig, míg az előre meghatározott hozzáférési feltételek nem teljesülnek. A feltételek teljesülése után (vagyis ha sikeresen lezajlott a „4-eyes” autorizáció) a kapcsolat folytatódik. Ha adott időn belül nem autorizálják a kapcsolatot, a Zorp megtagadja a hozzáférést. A gyakoribb feltételrendszereket az alábbiakban foglaljuk össze. Mindegyik bemutatott módszer alkalmazható az előző fejezetekben ismertetett auditálással párhuzamosan. Klasszikus „4-eyes” autorizáció Csak két különböző, egyszerre bejelentkező felhasználó férhet hozzá a rendszerhez, vagy bármely időpontban egyszerre legalább két felhasználónak kell bejelentkezve lennie. Lehetőség van felhasználócsoportok definiálására is, és ekkor az adott csoport legalább két tagjának kell bejelentkezve lennie. Egy másik megoldás, ha párba rendezzük az adminisztrátorokat, akik csak közösen jelentkezhetnek be a szerverre. Ebben a megoldásban a felhasználók autentikálása a szerveren történik, a Zorp a szerverautentikáció alapján kezeli a kapcsolatokat. A két felhasználó párhuzamosan dolgozhat a szerveren, nincs közöttük alárendelt kapcsolat, egyiküknek sincs több jogosultsága a másiknál. Ha az egyik felhasználó kapcsolata megszakad, a Zorp különböző módon reagálhat: • engedheti, hogy a másik felhasználó befejezze a munkáját, de újrakapcsolódást már csak a másik felhasználóval együtt engedélyez, vagy • automatikusan azonnal megszakítja a kapcsolatot. Autorizálás és valósidejű monitorozás Minden bejelentkezést és új SSH csatorna kiépítését engedélyezni kell. A két kapcsolat közül az egyik mindig az engedélyező, a másik az engedélyezett, így a két felhasználó is eltérő jogosultságokkal rendelkezik. Ebben a megoldásban is van lehetőség párok és felhasználócsoportok definiálására. A kapcsolat autorizálása egy külön SSH kapcsolaton keresztül történik, az engedélyező kiválaszthatja, hogy melyik felfüggesztett kapcsolatot vagy csatornát autorizálja. A szerver felé a Zorp csak akkor továbbítja a forgalmat, ha a kapcsolatot engedélyezték. A Zorp beállításaitól függően az engedélyező kapcsolatokat vagy felhasználókat autorizálhat. Ha az engedélyező kapcsolat megszakad, a Zorp az eredeti kapcsolatot automatikusan megszakítja. Az engedélyező felhasználó is bármikor megszakíthatja a korábban engedélyezett kapcsolatokat. Nem feltétlenül szükséges, hogy az autorizáló felhasználó is bejelentkezzen a szerverre, a környezettől és a Zorp beállításaitól függően az alábbi megoldások is lehetségesek: 1. Az autorizáló bejelentkezik a szerverre, és egy speciális parancs kiadásával valós időben ellenőrzi a szerver naplóüzeneteit, így minden művelet ellenőrizhető és naplózható. 2. Az autorizáló a szerver helyett egy speciális, izolált és zárt auditáló környezethez kapcsolódik – ez lehet akár a Zorp rendszeren, vagy egy dedikált gépen, amely csak a Zorppal van kapcsolatban. Ebben a
www.balabit.com
9/10
Előszó környezetben a Zorp által gyűjtött és rendezett adatokat lehet valós időben megtekinteni, és a többi felhasználó munkáját ellenőrizni. Fontos megjegyezni, hogy az előző megoldással szemben az itt megjelenő naplóüzenetek teljesen függetlenek a szervertől, így a szerverhez hozzáférő adminisztrátor vagy támadó sem tudja őket módosítani vagy befolyásolni.
Kérdéseit, megjegyzéseit az
[email protected] e-mail vagy az alábbi postacímre várjuk: BalaBit IT Security 1116 Budapest, Csurgói út 20/b Tel: 1 371-0540 Fax: 1 208-0875 Web: http://www.balabit.hu/ Copyright © 2006 BalaBit IT Security Ltd. Minden jog fenntartva. Bővebb információ az alábbi címen érhető el: http://www.balabit.com/products/zorp/docs/legal_notice.bbq
www.balabit.com
10/10
