Milyen gyakran vásárol valamit spontán, egy menő reklám hatására, majd ez a kezdetben vágyott dolog a szekrényben, spájzban vagy garázsban porosodik, egészen a következő nagytakarításig vagy költözésig? Az eredmény: csalódás a megalapozatlan elvárások és a feleslegesen elköltött pénz miatt. Sokkal rosszabb, amikor mindez a vállalkozásra vonatkozik. Nagyon gyakran a marketingtrükkök olyan jók, hogy a cégek drága megoldásokat vásárolnak anélkül, hogy teljes képet kapnának annak alkalmazásáról. Ezzel szemben a rendszer próba tesztelése segít megérteni, hogyan készítsük elő az infrastruktúrát az integrációra, milyen funkciókat és milyen mértékben érdemes bevezetni. Így elkerülhetjük a termék „vakságos” kiválasztásából fakadó problémák óriási számát. Továbbá, a jól megtervezett „pilot” bevezetése jóval kevesebb idegsejtet és ősz hajat okoz a mérnököknek. Nézzük meg, miért olyan fontos a pilot tesztelés a sikeres projekt szempontjából, a népszerű vállalati hálózati hozzáférés-ellenőrző eszköz, a Cisco ISE példáján keresztül. Áttekintjük a tipikus és a teljesen szokatlan alkalmazási módokat, amelyek előfordultak a gyakorlatunkban.
Cisco ISE – „Radius-szerver szteroidokon”
A Cisco Identity Services Engine (ISE) egy platform a szervezetek helyi számítógépes hálózatához való hozzáférés-ellenőrző rendszer kialakítására. A szakmai közösség a terméket annak tulajdonságai miatt „Radius-szerver szteroidokon” néven emlegeti. Miért? Lényegében a megoldás egy Radius-szerver, amelyhez rengeteg kiegészítő szolgáltatás és „kis trükk” csatlakozik, lehetővé téve a nagy mennyiségű kontextuális információ megszerzését és az így nyert adatok alkalmazását a hozzáférési politikákban.
Mint bármely más Radius-szerver, a Cisco ISE is kommunikál a hozzáférési szintű hálózati berendezésekkel, összegyűjti az összes vállalati hálózathoz való csatlakozási kísérletről szóló információt, és az autentikációs és jogosultsági politikák alapján eldönti, hogy engedélyezni vagy megakadályozni a felhasználók bejutását a helyi hálózatba. Azonban a profilozás, a rendezés, más információbiztonsági megoldásokkal való integráció lehetősége jelentősen bonyolítja a jogosultsági politika logikáját, így érdekes és nehéz feladatok megoldására ad lehetőséget.
Bevezetni tilos, tesztelni szükséges: miért van szükség a tesztelésre?
A próbaregisztráció értéke abban rejlik, hogy bemutatja a rendszer összes lehetőségét egy adott szervezet konkrét infrastruktúrájában. Meggyőződésem, hogy a Cisco ISE próbagyűjtése minden projekt résztvevőjének hasznos, és itt van, miért.
Az integrátorok számára ez világos képet ad a megrendelők elvárásairól, és segít egy helyes műszaki specifikáció kidolgozásában, amely sokkal részletesebb, mint a szokásos „csináljátok meg, hogy minden rendben legyen” kifejezés. A „próba” lehetővé teszi számunkra, hogy megérezzük a megrendelő minden nehézségét, hogy megértsük, mely feladatok prioritásosak a számukra, és melyek másodlagosak. Számunkra ez nagyszerű lehetőség, hogy előre tisztában legyünk azzal, milyen berendezéseket használnak a szervezetben, hogyan fog zajlani a bevezetés, mely helyszíneken, hol helyezkednek el, és így tovább.
A megrendelők pedig a próbatelepítés során valós rendszert látnak működés közben, megismerkednek a felhasználói felülettel, ellenőrizhetik, hogy az kompatibilis-e a meglévő „hardverükkel”, és átfogó képet nyernek arról, hogy hogyan fog működni a megoldás a teljes bevezetés után. A „próba” az a pillanat, amikor láthatjuk az összes „csapdát”, amelyekkel biztosan szembe kell néznünk az integráció során, és eldönthetjük, hány licencet kell vásárolnunk.
Mi „bukkanhat” fel a „próbán”
Tehát hogyan készülhetünk fel helyesen a Cisco ISE bevezetésére? Tapasztalataink szerint 4 alapvető szempontot számoltunk össze, amelyet fontos figyelembe venni a rendszer próbatesztelés során.
Formátum
Először is meg kell határozni, hogy a rendszer milyen formátumban valósul meg: fizikai vagy virtuális appliance formájában. Mindkét változatnak vannak előnyei és hátrányai. Például a fizikai appliance erőssége a kiszámítható teljesítmény, de ne feledkezzünk meg arról sem, hogy ezek az eszközök idővel elavulnak. A virtuális appliance-ek kevésbé kiszámíthatók, mivel attól függnek, hogy milyen berendezésekre alapozza a virtualizációs környezetet, de van egy komoly előnyük is: ha van támogatás, mindig frissíthetők a legújabb verzióra.
Kompatibilis-e a hálózati berendezése a Cisco ISE-vel?
Természetesen az ideális forgatókönyv az lenne, ha az összes berendezést egyszerre csatlakoztatnánk a rendszerhez. Azonban ez nem mindig lehetséges, mivel sok szervezet még mindig nem menedzselt switcheket vagy azokat a switcheket használ, amelyek nem támogatják azokat a technológiákat, amelyeken a Cisco ISE működik. Egyébként nem csak a switchekről van szó, hanem vezeték nélküli hálózati vezérlőkről is. VPN-koncentrátorok és bármilyen más eszköz, amelyhez a felhasználók csatlakoznak. A gyakorlatomban voltak olyan esetek, amikor a rendszer bemutatása után az ügyfél szinte az összes hozzáférési switchét modern Cisco berendezésre frissítette a teljes körű bevezetés érdekében. A kellemetlen meglepetések elkerülése érdekében érdemes előre kideríteni a nem támogatott eszközök arányát.
Minden eszköze szabványos?
Bármely hálózaton vannak szabványos eszközök, amelyek csatlakoztatása nem okozhat nehézséget: automatizált munkahelyek, IP-telefonok, Wi-Fi hozzáférési pontok, videokamerák és így tovább. De előfordulhat olyan is, hogy nem szabványos eszközöket kell csatlakoztatni a helyi hálózathoz, például RS232/Ethernet buszjel-átalakítókat, szünetmentes tápegység interfészeket, különféle technológiai berendezéseket és másokat. Fontos ezeket az eszközöket előre meghatározni, hogy a bevezetés szakaszában már legyen elképzelésük arról, hogyan fognak technikailag működni a Cisco ISE-vel.
Konstruktív párbeszéd az IT-sekkel
A Cisco ISE megrendelői gyakran a biztonsági részlegek, miközben a hozzáférési switchek és az Active Directory beállításáért általában az IT részlegek felelnek. Ezért a biztonsági szakemberek és az IT-sek közötti eredményes együttműködés az egyik fontos feltétele a rendszer fájdalommentes bevezetésének. Ha az utóbbiak ellenségesen viszonyulnak az integrációhoz, érdemes elmagyarázni nekik, hogy a megoldás hogyan hasznos lesz az IT osztály számára.
Top-5 felhasználási eset a Cisco ISE-ben
Tapasztalataink szerint a szükséges funkciók is az előzetes tesztelés során derülnek ki. Az alábbiakban néhány népszerűbb és kevésbé elterjedt felhasználási esetet mutatunk be.
Biztonságos hozzáférés a helyi hálózathoz EAP-TLS segítségével
A kutatásaink eredményei alapján a pentestereink rámutattak, hogy a támadók gyakran használják a vállalati hálózathoz csatlakozó normál konnektorokat, amelyekhez nyomtatók, telefonok, IP-kamerák, Wi-Fi-hálózati pontok és más nem személyes hálózati eszközök csatlakoznak. Ezért, még ha a hálózati hozzáférés dot1x technológia alapján valósul meg is, de alternatív protokollokat használnak a felhasználók hitelesítését igazoló tanúsítványok alkalmazása nélkül, jelentős a session átvétel és a jelszó brute-force támadás esélye. A Cisco ISE esetében a tanúsítvány feltörése sokkal nehezebb lesz — a hackereknek sokkal nagyobb számítási teljesítményre van szükségük, így ez az eset nagyon hatékony.
Dual-SSID vezeték nélküli hozzáférés
Ennek a forgatókönyvnek a lényege, hogy 2 hálózati azonosítót (SSID) használunk. Az egyikük feltételesen nevezhető 'vendég'-nek. Ezen keresztül a vendégek és a cég dolgozói is csatlakozhatnak a vezeték nélküli hálózathoz. Az utóbbiak, amikor csatlakoznak, egy különleges portálra irányítják őket, ahol provisioning történik. Tehát a felhasználónak kiállítanak egy tanúsítványt, és beállítják a saját eszközét, hogy automatikusan újracsatlakozzon a második SSID-hez, ahol már EAP-TLS-t használnak, az első eset minden előnyével.
MAC Authentication Bypass és profilalkotás
Egy másik népszerű eset az, amikor automatikusan meghatározzák a csatlakoztatott eszköz típusát, és a megfelelő korlátozásokat alkalmazzák. Miért érdekes ez? Mivel még mindig sok olyan eszköz létezik, amely nem támogatja a 802.1X protokoll alapú hitelesítést. Ezért az ilyen eszközöket MAC-cím alapján kell a hálózatba engedni, amely viszonylag könnyen hamisítható. Itt jön a képbe a Cisco ISE: a rendszeren keresztül láthatjuk, hogyan viselkedik az eszköz a hálózatban, készíthetünk róla egy profilt, és hozzárendelhetjük egy másik eszközcsoporthoz, például IP-telefon és munkaállomás. Ha egy támadó hamisítja a MAC-címét és próbál csatlakozni a hálózathoz, a rendszer észleli, hogy az eszköz profilja megváltozott, jelezni fogja a gyanús viselkedést, és nem engedi be a gyanús felhasználót a hálózatba.
EAP-Chaining
Az EAP-Chaining technológia a munkahelyi számítógép és a felhasználói fiók folyamatos hitelesítését jelenti. Ez a megoldás széles körben elterjedt, mivel sok vállalatnál még mindig nem támogatták a munkavállalók személyes eszközeinek csatlakoztatását a vállalati helyi hálózathoz. Ezzel a hitelesítési megközelítéssel ellenőrizhetjük, hogy a konkrét munkaállomás tagja-e a tartománynak, és ha nem, akkor a felhasználó vagy nem fér hozzá a hálózathoz, vagy korlátozott hozzáféréssel beléphet.
Elhelyezkedés
Ez az eset a munkaállomás szoftverösszetételének megfelelőségének értékeléséről szól az információbiztonsági követelményeknek. Ezzel a technológiával meg lehet vizsgálni, hogy a munkaállomáson frissítve van-e a szoftver, telepítve vannak-e a védelmi eszközök, be van-e állítva a hoszt tűzfal stb. Érdekes, hogy ez a technológia más feladatok megoldására is alkalmas, amelyek nem kapcsolódnak a biztonsághoz, például a szükséges fájlok meglétének vagy a rendszeres szoftverek telepítésének ellenőrzésére.
Ritkábban előforduló Cisco ISE használati forgatókönyvek közé tartozik a hozzáférésvezérlés áthidaló domén hitelesítéssel (Passive ID), az SGT-alapú mikroszegmentálás és szűrés, valamint az integráció a mobil eszközkezelő rendszerekkel (MDM) és a sebezhetőségellenőrzőkkel (Vulnerability Scanner).
Nem megszokott projektek: mire lehet még szükség a Cisco ISE-re, avagy 3 ritka eset a gyakorlatunkból
Hozzáférés-ellenőrzés Linux alapú szerverekhez
Egyszer egy elég összetett ügyet kellett megoldanunk egy ügyfelünk számára, akinek már telepítve volt a Cisco ISE rendszere: ki kellett találnunk, hogyan lehetne ellenőrizni a felhasználói tevékenységeket (főként rendszergazdák voltak) Linux operációs rendszert futtató szervereken. A válasz keresése során felmerült az ötlet, hogy használjuk a szabad PAM Radius Module szoftvert, amely lehetővé teszi a Linux alapú szerverekre való belépést egy külső radius-szerveren végzett hitelesítéssel. Mindez jól működne, ha nem lenne egy „de”: a radius-szerver, amikor választ küld a hitelesítési kérésre, csak a felhasználói nevet és az eredményt adja vissza – assess accepted vagy assess rejected. Ugyanakkor a Linuxban a jogosultságok hitelesítéséhez legalább még egy paramétert meg kell adni – a home directory-t, hogy a felhasználó legalább valahova eljuthasson. Nem találtunk módot, hogy ezt radius-attribútumként átadhassuk, ezért írtunk egy speciális szkriptet, amely távoli felhasználói fiókok létrehozására szolgál a hosztokon félautomatikus módban. Ez a feladat teljesíthető volt, mivel rendszergazdai fiókokkal foglalkoztunk, amelyek száma nem volt túl nagy. Ezután a felhasználók beléptek a szükséges eszközre, ahol hozzárendeltek számukra a szükséges hozzáférést. Felmerül a jogos kérdés: feltétlenül szükséges-e ilyen esetekben a Cisco ISE használata? Valójában nem – bármilyen radius-szerver megfelel, de mivel az ügyfélnek már volt egy ilyen rendszere, csak annyit tettünk, hogy hozzáadtunk egy új funkciót.
Eszközök és szoftverek leltározása a helyi hálózatban
Egyszer egy Cisco ISE szállítási projekten dolgoztunk egy ügyfélnek előzetes "pilótaprogram" nélkül. A megoldással szemben nem voltak világos követelmények, és emellett egy sík, nem szegmentált hálózattal is dolgunk volt, ami megnehezítette a feladatunkat. A projekt során beállítottuk az összes lehetséges profilozási módszert, amelyet a hálózat támogatott: NetFlow, DHCP, SNMP, AD integráció stb. Végül MAR hozzáférést állítottunk be, amely lehetővé tette a belépést a hálózatba, még ha a hitelesítés nem volt sikeres. Ez azt jelenti, hogy még ha a hitelesítés nem volt sikeres, a rendszer akkor is engedte a felhasználót a hálózatba, összegyűjtve róla az információt, és elmentve azt az ISE adatbázisába. Ez a hálózati megfigyelés néhány héten keresztül segített kiemelni a csatlakoztatott rendszereket és az anonim eszközöket, és kidolgozni egy megközelítést a szegmentálásukra. Ezt követően további beállítást végeztünk az ügynök munkavállalói állomásokra való telepítése érdekében, hogy információt gyűjtsünk azokon a telepített szoftverekről. Mi lett a végeredmény? Sikerült szegmentálnunk a hálózatot és meghatároznunk a szoftverek listáját, amelyeket el kellett távolítani a munkavállalói állomásokról. Nem titkolom, hogy a felhasználók domain csoportokba való besorolása és a hozzáférési jogok korlátozása elég sok időt vett igénybe, de így teljes képet kaptunk arról, hogy milyen "hardver" volt az ügyfelünknél a hálózatban. Egyébként ezt nem volt nehéz elérni a profilozás "dobozból" történő jó működése miatt. Nos, ahol a profilozás nem segített, ott saját magunk néztük meg, kiemelve a switch portot, amelyhez a berendezés csatlakozott.
Távoli szoftvertelepítés munkavállalói állomásokra
Ez az eset az egyik legfurcsább a gyakorlatomban. Egy alkalommal egy ügyfél segítséget kért tőlünk – a Cisco ISE bevezetése során valami rosszul sült el, minden összeomlott, és senki más nem tudott hozzáférni a hálózathoz. Megkezdtük a vizsgálatot, és a következőket állapítottuk meg. A cégnek 2000 számítógépe volt, amelyeket a tartományvezérlő hiányában az adminisztrátori fiók alól irányítottak. Számlálási célokból a szervezet a Cisco ISE-t vezette be. Valahogy meg kellett érteni, hogy van-e telepített vírusirtó a meglévő PC-ken, frissítve van-e a szoftver környezet stb. Mivel a hálózati eszközöket az IT-adminisztrátorok vezették be a rendszerbe, értelemszerűen hozzáférésük volt hozzá. Miután megnézték, hogyan működik, és elvégezték a saját PC-jük számlálását, az adminisztrátorok kiötlötték, hogy távolról telepítsenek szoftvereket a munkatársak munkaállomásaira személyes látogatások nélkül. Csak képzeljék el, mennyi lépést lehet így megspórolni egy nap alatt! Az adminisztrátorok több ARM ellenőrzést végeztek el egy adott fájl keresésére a C:Program Files könyvtárban, és annak hiányában automatikus remediáció indult, amely egy hivatkozáson keresztül vitt az .exe telepítő fájl tárolójához. Ez lehetővé tette a felhasználók számára, hogy belépjenek a fájlmegosztásba, és letöltsék onnan a szükséges szoftvert. Sajnos az admin nem ismerte jól az ISE rendszert, és megsérült a számlálási mechanizmus – rosszul írta meg a politikát, ami ahhoz a problémához vezetett, amelynek megoldásához minket is bevontak. Személy szerint őszintén meglep, hogy ilyen kreatív megoldást alkalmaztak, hiszen sokkal olcsóbb és kevésbé munkás lett volna egy tartományvezérlőt létrehozni. De mint Proof of Concept, ez működött.
Több információt a Cisco ISE bevezetése során felmerülő technikai részletekről olvashat kollégám cikkében. .
Artem Bobrikov, tervező mérnök az "Inforsystem Jet" vállalat Információbiztonsági Központjában.
Utószó:
Habár ez a bejegyzés a Cisco ISE rendszerről szól, a leírt problémák relevánsak a NAC megoldások teljes osztályára. Nem számít, hogy melyik gyártó megoldását tervezik bevezetni, a fenti megállapítások nagyrészt alkalmazhatóak maradnak.
Forrás: habr.com
