A tesztelés megmutatja: hogyan készüljön fel a Cisco ISE megvalósítására, és hogyan tudja megérteni, milyen rendszerfunkciókra van szüksége

A tesztelés megmutatja: hogyan készüljön fel a Cisco ISE megvalósítására, és hogyan tudja megérteni, milyen rendszerfunkciókra van szüksége

Milyen gyakran vásárolsz spontán, egy menő reklámnak engedve valamit, majd a következő tavaszi nagytakarításig, költözésig egy szekrényben, kamrában vagy garázsban porosodik ez az eleinte vágyott tárgy? Az eredmény csalódás az indokolatlan várakozások és a kidobott pénz miatt. Sokkal rosszabb, ha ez egy vállalkozással történik. A marketingtrükkök nagyon gyakran olyan jók, hogy a vállalatok úgy vásárolnak meg egy drága megoldást, hogy nem látják annak alkalmazásának teljes képét. Eközben a rendszer próbatesztelése segít megérteni, hogyan kell felkészíteni az infrastruktúrát az integrációra, milyen funkcionalitást és milyen mértékben kell megvalósítani. Így rengeteg problémát elkerülhet a „vakon” termékválasztás miatt. Ezen túlmenően, a hozzáértő „pilóta” után történő végrehajtás sokkal kevésbé pusztítja el az idegsejteket és a szürke hajat. Nézzük meg, miért olyan fontos a kísérleti tesztelés egy sikeres projekthez, a vállalati hálózatokhoz való hozzáférés szabályozására szolgáló népszerű eszköz, a Cisco ISE példáján keresztül. Tekintsük mind a szabványos, mind a teljesen nem szabványos lehetőségeket a gyakorlatunkban talált megoldás használatára.

Cisco ISE – „Radius szerver szteroidokon”

A Cisco Identity Services Engine (ISE) egy platform hozzáférés-vezérlő rendszer létrehozására egy szervezet helyi hálózatához. A szakértői közösségben a termék „Radius server on steroids” becenevet kapott tulajdonságai miatt. Miert van az? A megoldás lényegében egy Radius szerver, amelyhez rengeteg további szolgáltatást és „trükköt” csatoltak, amelyek segítségével nagy mennyiségű kontextuális információt kaphatunk, és az így létrejövő adathalmazt a hozzáférési szabályzatokban alkalmazhatjuk.

A többi Radius szerverhez hasonlóan a Cisco ISE is együttműködik a hozzáférési szintű hálózati berendezésekkel, információkat gyűjt a vállalati hálózathoz való csatlakozási kísérletekről, és a hitelesítési és engedélyezési házirendek alapján engedélyezi vagy megtagadja a felhasználókat a LAN-hoz. A profilalkotás, közzététel és más információbiztonsági megoldásokkal való integráció lehetősége azonban lehetővé teszi az engedélyezési politika logikájának jelentős bonyolítását, és ezáltal meglehetősen nehéz és érdekes problémák megoldását.

A tesztelés megmutatja: hogyan készüljön fel a Cisco ISE megvalósítására, és hogyan tudja megérteni, milyen rendszerfunkciókra van szüksége

A megvalósítás nem pilotálható: miért van szükség tesztelésre?

A pilot tesztelés értéke az, hogy egy adott szervezet adott infrastruktúrájában demonstrálja a rendszer összes képességét. Úgy gondolom, hogy a Cisco ISE kipróbálása a bevezetés előtt mindenki számára előnyös, aki részt vesz a projektben, és ez az oka annak.

Ez világos képet ad az integrátoroknak az ügyfél elvárásairól, és segít létrehozni egy megfelelő műszaki specifikációt, amely sokkal több részletet tartalmaz, mint a „győződjön meg róla, hogy minden rendben” kifejezés. A „pilóta” lehetővé teszi számunkra, hogy átérezzük az ügyfél minden fájdalmát, megértsük, mely feladatok prioritást élveznek számára, és melyek másodlagosak. Számunkra ez egy kiváló lehetőség arra, hogy előre kitaláljuk, milyen eszközöket használnak a szervezetben, hogyan zajlik majd a megvalósítás, milyen telephelyeken, hol találhatók stb.

A pilot tesztelés során az ügyfelek látják a valós rendszert működés közben, megismerkedhetnek a felületével, ellenőrizhetik, hogy kompatibilis-e a meglévő hardverükkel, és holisztikusan átlátják a megoldás működését a teljes bevezetés után. A „Pilot” pont az a pillanat, amikor láthatja az összes buktatót, amellyel valószínűleg találkozni fog az integráció során, és eldöntheti, hány licencet kell megvásárolnia.
Mi „felbukkanhat” a „pilóta” alatt

Tehát hogyan kell megfelelően felkészülni a Cisco ISE megvalósítására? Tapasztalataink alapján 4 fő szempontot számoltunk össze, amelyeket fontos figyelembe venni a rendszer pilot tesztelése során.

Forma tényező

Először is el kell döntenie, hogy a rendszer milyen formában kerül megvalósításra: fizikai vagy virtuális felsővonalon. Mindegyik lehetőségnek vannak előnyei és hátrányai. Például egy fizikai felsővonal erőssége a kiszámítható teljesítmény, de nem szabad elfelejteni, hogy az ilyen eszközök idővel elavulnak. A virtuális felsővonalak kevésbé kiszámíthatók, mert... függ a hardvertől, amelyen a virtualizációs környezetet telepítik, de komoly előnyük van: ha van támogatás, mindig frissíthetők a legújabb verzióra.

Az Ön hálózati berendezése kompatibilis a Cisco ISE-vel?

Természetesen az ideális forgatókönyv az lenne, ha minden berendezést egyszerre csatlakoztatnánk a rendszerhez. Ez azonban nem mindig lehetséges, mivel sok szervezet továbbra is használ nem felügyelt kapcsolókat vagy olyan kapcsolókat, amelyek nem támogatják a Cisco ISE-t futtató technológiák egy részét. Egyébként nem csak kapcsolókról beszélünk, ezek lehetnek vezeték nélküli hálózati vezérlők, VPN-koncentrátorok és bármilyen egyéb berendezés is, amelyhez a felhasználók csatlakoznak. Gyakorlatomban előfordult már, hogy a rendszer teljes megvalósításra való bemutatása után az ügyfél a hozzáférési szintkapcsolók szinte teljes flottáját korszerű Cisco berendezésekre frissítette. A kellemetlen meglepetések elkerülése érdekében érdemes előre tájékozódni a nem támogatott felszerelések arányáról.

Minden eszköze szabványos?

Minden hálózatnak vannak tipikus eszközei, amelyekhez nem lehet nehéz csatlakozni: munkaállomások, IP-telefonok, Wi-Fi hozzáférési pontok, videokamerák stb. De az is előfordul, hogy nem szabványos eszközöket kell a LAN-hoz csatlakoztatni, például RS232/Ethernet busz jelátalakítókat, szünetmentes tápegység interfészt, különféle technológiai berendezéseket stb. Fontos, hogy előre meghatározzuk az ilyen eszközök listáját. , így már a megvalósítási szakaszban megértheti, hogy technikailag hogyan fognak működni a Cisco ISE-vel.

Konstruktív párbeszéd informatikusokkal

A Cisco ISE ügyfelei gyakran biztonsági osztályok, míg az IT osztályok általában a hozzáférési rétegkapcsolók és az Active Directory konfigurálásáért felelősek. Ezért a biztonsági szakemberek és az informatikusok közötti produktív interakció a rendszer fájdalommentes megvalósításának egyik fontos feltétele. Ha az utóbbiak ellenségesen érzékelik az integrációt, akkor érdemes elmagyarázni nekik, hogy a megoldás miként lesz hasznos az informatikai részleg számára.

Az 5 legjobb Cisco ISE használati eset

Tapasztalataink szerint a rendszer szükséges funkcionalitását a pilot tesztelési szakaszban is azonosítják. Az alábbiakban bemutatjuk a megoldás legnépszerűbb és kevésbé gyakori felhasználási eseteit.

Biztonságos LAN hozzáférés vezetéken keresztül az EAP-TLS segítségével

Amint azt pentesztelőink kutatásának eredményei mutatják, a támadók meglehetősen gyakran hétköznapi aljzatokat használnak, amelyekhez nyomtatók, telefonok, IP-kamerák, Wi-Fi pontok és egyéb nem személyes hálózati eszközök csatlakoznak. Ezért még akkor is, ha a hálózati hozzáférés dot1x technológián alapul, de alternatív protokollokat használnak felhasználói hitelesítési tanúsítványok használata nélkül, nagy a valószínűsége a sikeres támadásnak munkamenet-elfogással és brute-force jelszavakkal. A Cisco ISE esetében sokkal nehezebb lesz egy tanúsítványt ellopni - ehhez a hackereknek sokkal nagyobb számítási teljesítményre lesz 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áljon. Az egyiket feltételesen „vendégnek” nevezhetjük. Rajta keresztül a vendégek és a cég alkalmazottai egyaránt hozzáférhetnek a vezeték nélküli hálózathoz. Amikor megpróbálnak csatlakozni, az utóbbiakat egy speciális portálra irányítják át, ahol a hozzáférés megtörténik. Ez azt jelenti, hogy a felhasználó kap egy tanúsítványt, és személyes eszköze úgy van beállítva, hogy automatikusan újracsatlakozzon a második SSID-hez, amely már az EAP-TLS-t használja az első eset minden előnyével.

MAC-hitelesítés bypass és profilalkotás

Egy másik népszerű felhasználási eset a csatlakoztatott eszköz típusának automatikus felismerése és a megfelelő korlátozások alkalmazása. Miért érdekes? Az a tény, hogy még mindig nagyon sok olyan eszköz van, amely nem támogatja a 802.1X protokollt használó hitelesítést. Ezért az ilyen eszközöket MAC-címmel kell engedélyezni a hálózathoz, amelyet meglehetősen könnyű meghamisítani. Itt jön a segítség a Cisco ISE: a rendszer segítségével megtekintheti, hogyan viselkedik egy eszköz a hálózaton, létrehozhatja a profilját és hozzárendelheti más eszközök csoportjához, például egy IP telefonhoz és egy munkaállomáshoz. . Ha a támadó megpróbál meghamisítani egy MAC-címet és csatlakozni a hálózathoz, a rendszer látni fogja, hogy az eszközprofil megváltozott, gyanús viselkedést jelez, és nem engedi be a gyanús felhasználót a hálózatba.

EAP-láncolás

Az EAP-Chaining technológia magában foglalja a működő számítógép és a felhasználói fiók szekvenciális hitelesítését. Ez az eset azért terjedt el, mert... Sok vállalat még mindig nem ösztönzi az alkalmazottak személyes kütyüjének a vállalati LAN-hoz való csatlakoztatását. Ezzel a hitelesítési megközelítéssel ellenőrizhető, hogy egy adott munkaállomás tagja-e a tartománynak, és ha az eredmény negatív, akkor a felhasználó vagy nem kerül be a hálózatba, vagy be tud lépni, de bizonyos feltételek mellett. korlátozásokat.

Postázás

Ez az eset a munkaállomás-szoftver információbiztonsági követelményeknek való megfelelőségének felméréséről szól. Ezzel a technológiával ellenőrizheti, hogy a munkaállomás szoftvere frissítve van-e, telepítve vannak-e biztonsági intézkedések, be van-e konfigurálva a gazdagép tűzfala stb. Érdekes módon ez a technológia lehetővé teszi más, nem a biztonsággal kapcsolatos feladatok megoldását is, például a szükséges fájlok meglétének ellenőrzését vagy a rendszerszintű szoftverek telepítését.

A Cisco ISE kevésbé gyakori használati esetei közé tartozik a hozzáférés-vezérlés végpontok közötti tartományhitelesítéssel (Passive ID), az SGT-alapú mikroszegmentációval és szűréssel, valamint a mobileszköz-kezelő (MDM) rendszerekkel és a sebezhetőség-ellenőrzőkkel való integráció.

Nem szabványos projektek: miért van még szüksége Cisco ISE-re, vagy 3 ritka eset a gyakorlatunkból

Hozzáférés szabályozása Linux alapú szerverekhez

Egyszer egy meglehetősen nem triviális esetet oldottunk meg az egyik ügyfél számára, aki már telepítette a Cisco ISE rendszert: meg kellett találnunk a felhasználói műveletek (többnyire adminisztrátorok) vezérlését olyan szervereken, amelyeken Linux van telepítve. A választ keresve felmerült az ingyenes PAM Radius Module szoftver használatának ötlete, amely lehetővé teszi a Linuxot futtató szerverekre való bejelentkezést külső sugárszerveren történő hitelesítéssel. Ebben a tekintetben minden jó lenne, ha nem egy „de”-re: a sugárszerver a hitelesítési kérésre választ küldve csak a fiók nevét és az eredményt adja meg - értékeli elfogadva vagy elutasítva. Mindeközben a Linux engedélyezéséhez hozzá kell rendelnie még legalább egy paramétert - a saját könyvtárat, hogy a felhasználó legalább eljusson valahova. Nem találtuk meg a módját, hogy ezt sugár attribútumként adjuk meg, ezért írtunk egy speciális szkriptet a fiókok távoli létrehozásához a gazdagépeken félautomata módban. Ez a feladat teljesen megoldható volt, mivel rendszergazdai fiókokkal volt dolgunk, amelyek száma nem volt olyan nagy. Ezután a felhasználók bejelentkeztek a kívánt eszközre, majd hozzárendelték a szükséges hozzáférést. Felmerül egy jogos kérdés: szükséges-e ilyen esetekben a Cisco ISE használata? Valójában nem – bármelyik sugaras szerver megteszi, de mivel az ügyfél már rendelkezett ezzel a rendszerrel, egyszerűen hozzáadtunk egy új funkciót.

Hardver és szoftver leltár a LAN-on

Egyszer egy olyan projekten dolgoztunk, amely a Cisco ISE-t egy ügyfélnek előzetes „pilot” nélkül szállította. Nem voltak egyértelmű követelmények a megoldással szemben, ráadásul lapos, nem szegmentált hálózattal volt dolgunk, ami megnehezítette a dolgunkat. A projekt során minden lehetséges profilalkotási módszert konfiguráltunk, amit a hálózat támogatott: NetFlow, DHCP, SNMP, AD integráció stb. Ennek eredményeként a MAR hozzáférést úgy konfigurálták, hogy a hitelesítés sikertelensége esetén be tudjon jelentkezni a hálózatba. Azaz, ha a hitelesítés nem is sikerült, a rendszer akkor is beengedi a felhasználót a hálózatba, információkat gyűjt róla és rögzíti az ISE adatbázisban. Ez a több hétig tartó hálózatfigyelés segített azonosítani a csatlakoztatott rendszereket és a nem személyes eszközöket, és kialakítani egy megközelítést ezek szegmentálására. Ezt követően a feladást úgy konfiguráltuk, hogy az ügynököt telepítsük a munkaállomásokra, hogy információkat gyűjtsünk a rájuk telepített szoftverekről. mi az eredmény? Sikerült szegmentálni a hálózatot, és meghatározni azon szoftverek listáját, amelyeket el kell távolítani a munkaállomásokról. Nem rejtem véka alá, hogy a felhasználók domain csoportokba való felosztása és a hozzáférési jogok lehatárolása nem kevés időt vett igénybe, de így teljes képet kaptunk arról, hogy az ügyfél milyen hardverrel rendelkezik a hálózaton. Ez egyébként nem volt nehéz a dobozból történő profilalkotás jó munkájának köszönhetően. Nos, ahol a profilozás nem segített, ott megnéztük magunkat, kiemelve a kapcsolóportot, amelyre a berendezés csatlakoztatva volt.

Szoftverek távoli telepítése munkaállomásokra

Ez az eset az egyik legfurcsább a gyakorlatomban. Egy nap egy ügyfél segélykiáltással fordult hozzánk – valami elromlott a Cisco ISE implementálásakor, minden elromlott, és senki más nem tudta elérni a hálózatot. Elkezdtünk utána nézni, és a következőket tudtuk meg. A cégnek 2000 számítógépe volt, melyeket tartományvezérlő hiányában rendszergazdai fiókkal kezeltek. A peering érdekében a szervezet bevezette a Cisco ISE-t. Valahogy meg kellett érteni, hogy a meglévő számítógépekre telepítettek-e vírusirtót, frissítették-e a szoftverkörnyezetet stb. És mivel a rendszergazdák hálózati eszközöket telepítettek a rendszerbe, logikus, hogy hozzáfértek. Miután a rendszergazdák megnézték, hogyan működik, és megcsinálták a számítógépeiket, az az ötlet, hogy a szoftvert távolról, személyes látogatások nélkül telepítsék az alkalmazottak munkaállomásaira. Képzelje csak el, hány lépést spórolhat meg naponta így! Az adminisztrátorok többször ellenőrizték a munkaállomást, hogy a C:Program Files könyvtárban található-e egy adott fájl, és ha az hiányzott volna, akkor a fájltárolóra mutató hivatkozást követve a telepítő .exe fájlhoz automatikus javítás indult. Ez lehetővé tette a hétköznapi felhasználók számára, hogy egy fájlmegosztáshoz lépjenek, és onnan töltsék le a szükséges szoftvereket. Sajnos az adminisztrátor nem ismerte jól az ISE rendszert és megrongálta a feladási mechanizmusokat - rosszul írta a szabályzatot, ami egy olyan problémához vezetett, amelynek megoldásában részt vettünk. Én személy szerint őszintén meglep egy ilyen kreatív megközelítés, mert sokkal olcsóbb és kevésbé munkaigényes lenne egy tartományvezérlőt létrehozni. De a koncepció bizonyítékaként működött.

A Cisco ISE implementációja során felmerülő technikai árnyalatokról kollégám cikkében olvashat bővebben „Cisco ISE megvalósítási gyakorlat. A mérnök nézete".

Artem Bobrikov, a Jet Infosystems Információbiztonsági Központjának tervezőmérnöke

utószó:
Annak ellenére, hogy ez a bejegyzés a Cisco ISE rendszerről beszél, a leírt problémák a NAC megoldások teljes osztályára vonatkoznak. Nem annyira fontos, hogy melyik gyártó megoldását tervezik implementálni – a fentiek többsége továbbra is alkalmazható marad.

Forrás: will.com

Hozzászólás