Hur ofta köper du nĂ„got spontant, lockad av en fantastisk reklam, och sedan ligger den frĂ„n början önskade saken och samlar damm i garderoben, förrĂ„det eller garaget fram till nĂ€sta storstĂ€dning eller flytt? Resultatet blir en besvikelse pĂ„ grund av orimliga förvĂ€ntningar och slösslade pengar. Mycket vĂ€rre Ă€r det nĂ€r nĂ„got liknande hĂ€nder i affĂ€rslivet. Marknadsföringstricks Ă€r ofta sĂ„ effektiva att företag köper dyra lösningar utan att se hela bilden av hur de kommer att anvĂ€ndas. Under tiden hjĂ€lper provtestning av systemet till att förstĂ„ hur man förbereder infrastrukturen för integration, vilken funktionalitet och i vilken omfattning som bör implementeras. PĂ„ sĂ„ sĂ€tt kan man undvika en stor mĂ€ngd problem som följer av att vĂ€lja produkter âblintâ. Dessutom kommer implementeringen efter en vĂ€lintegrerad âpilotâ att orsaka betydligt mindre stress och grĂ„a hĂ„r för teknikerna. LĂ„t oss titta pĂ„ varför pilot-testning Ă€r sĂ„ viktigt för ett framgĂ„ngsrikt projekt, med hjĂ€lp av ett populĂ€rt verktyg för Ă„tkomstkontroll av företagsnĂ€tverk â Cisco ISE. Vi kommer att övervĂ€ga bĂ„de standard- och helt unika anvĂ€ndningsscenarier som vi stött pĂ„ i vĂ„r praktik.
Cisco ISE â "Radius-server pĂ„ steroider"
Cisco Identity Services Engine (ISE) Àr en plattform för att skapa ett system för Ätkomstkontroll av organisationens lokala datanÀtverk. Inom expertkretsar har produkten fÄtt smeknamnet "Radius-server pÄ steroider" pÄ grund av sina egenskaper. Varför det? I grunden Àr lösningen en Radius-server, till vilken ett stort antal extra tjÀnster och "finesser" har kopplats som möjliggör insamling av stora mÀngder kontextuell information och anvÀndning av dessa data i Ätkomstpolitiken.
Precis som alla andra Radius-servrar samverkar Cisco ISE med nÀtverksutrustning pÄ ÄtkomstnivÄ, samlar information om alla försök att ansluta till företagsnÀtverket och baserat pÄ autentisering och auktorisering policyer avgör om anvÀndare slÀpps in i LAN eller inte. Möjligheten till profilering, övervakning och integration med andra sÀkerhetslösningar gör det möjligt att komplexifiera auktoriseringspolitiken avsevÀrt och dÀrigenom lösa ganska svÄra och intressanta uppgifter.
Implementera eller pilotera: varför behövs testning?
VÀrdet av pilot-testning ligger i att demonstrera alla systemets möjligheter i den specifika infrastrukturen hos en viss organisation. Jag Àr övertygad om att pilotering av Cisco ISE före implementation Àr till nytta för alla projektets deltagare, och hÀr Àr varför.
För integratörer ger detta en tydlig bild av kundens förvÀntningar och hjÀlper till att formulera en korrekt teknisk specifikation som innehÄller mycket mer detaljer Àn den vanliga frasen 'gör sÄ att allt fungerar bra'. 'Piloten' lÄter oss kÀnna av alla kundens smÀrtpunkter, förstÄ vilka uppgifter som Àr prioriterade för dem, och vilka som Àr mindre viktiga. För oss Àr detta ett utmÀrkt tillfÀlle att pÄ förhand klargöra vilken utrustning som anvÀnds i organisationen, hur implementationen kommer att göras, pÄ vilka platser, var de ligger och sÄ vidare.
Kunderna fÄr under pilot-testningen se det verkliga systemet i aktion, bekanta sig med dess grÀnssnitt, kontrollera om det Àr kompatibelt med deras befintliga 'hÄrdvara', och fÄ en helhetsbild av hur lösningen kommer att fungera efter fullstÀndig implementering. 'Piloten' Àr den tidpunkt nÀr man kan se alla 'fÀllor' man sannolikt kommer att möta vid integration, och avgöra hur mÄnga licenser som behöver köpas.
Vad kan 'dyka upp' under 'piloten'
SÄ hur ska man förbereda sig för implementeringen av Cisco ISE pÄ rÀtt sÀtt? FrÄn vÄr erfarenhet har vi identifierat 4 viktiga punkter att beakta under pilot-testningsprocessen.
Formfaktor
Först och frÀmst mÄste man bestÀmma i vilken form faktorn systemet kommer att implementeras: som en fysisk eller virtuell appliance. Varje alternativ har sina fördelar och nackdelar. Till exempel Àr en stark sidan av fysiska appliances deras förutsÀgbara prestanda, men man fÄr inte glömma att sÄdana enheter blir förÄldrade över tid. Virtuella appliances Àr mindre förutsÀgbara, eftersom de beror pÄ hÄrdvaran som virtualiseringsmiljön körs pÄ, men de har den stora fördelen att de alltid kan uppdateras till den senaste versionen om de har stöd.
Ăr din nĂ€tverksutrustning kompatibel med Cisco ISE?
SjÀlvklart skulle det ideala scenariot vara att ansluta all utrustning till systemet pÄ en gÄng. Men det Àr inte alltid möjligt, eftersom mÄnga organisationer fortfarande anvÀnder obekanta switchar eller switchar som inte stödjer vissa teknologier som Cisco ISE arbetar med. Det handlar inte bara om switchar, det kan ocksÄ vara trÄdlösa nÀtverkskontroller, VPN-hubbar och all annan utrustning som anvÀndare ansluter till. I min erfarenhet har jag sett fall dÀr kunden efter en demonstration av systemet uppgraderade i stort sett hela sitt utbud av access-switchar till modern Cisco-utrustning för en fullstÀndig implementering. För att undvika obehagliga överraskningar Àr det viktigt att i förvÀg ta reda pÄ andelen icke-stödd utrustning.
Ăr alla era enheter standardiserade?
I ett nÀtverk finns det standardenheter vars anslutning inte borde orsaka problem: automatiserade arbetsstationer, IP-telefoner, Wi-Fi-Ätkomstpunkter, videokameror och sÄ vidare. Men det hÀnder ocksÄ att man behöver ansluta icke-standardiserade enheter, som RS232/Ethernet-signalkonverterare, UPS-grÀnssnitt, olika tekniska utrustningar osv. Det Àr viktigt att identifiera en lista över sÄdana enheter i förvÀg, sÄ att ni under implementeringen redan har en uppfattning om hur de tekniskt sett kommer att fungera med Cisco ISE.
Konstruktiv dialog med IT-specialister
Ofta Àr det sÀkerhetsavdelningar som bestÀller Cisco ISE, medan IT-avdelningarna vanligtvis ansvarar för att konfigurera access-switchar och Active Directory. DÀrför Àr produktivt samarbete mellan sÀkerhetspersonal och IT-specialister en av de viktiga förutsÀttningarna för en smÀrtfri implementering av systemet. Om IT-specialister Àr tveksamma till integrationen, bör man förklara för dem hur lösningen kommer att vara nyttig för IT-avdelningen.
Topp 5 anvÀndningsfall för Cisco ISE
Enligt vÄr erfarenhet identifieras den nödvÀndiga funktionaliteten för systemet Àven under pilot-testfasen. Nedan följer nÄgra av de mest populÀra och mindre vanliga anvÀndningsfallen för lösningen.
SĂ€ker kabelanslutning till LAN med EAP-TLS
Som vĂ„ra penetrationstestare har visat i sina studier, anvĂ€nder illvilliga aktörer ganska ofta vanliga uttag, dit skrivare, telefoner, IP-kameror, Wi-Fi-punkter och andra icke-personliga nĂ€tverksenheter Ă€r anslutna, för att fĂ„ tillgĂ„ng till företagets nĂ€tverk. DĂ€rför, Ă€ven om nĂ€tverksĂ„tkomst sker via dot1x-teknologi, men alternativa protokoll anvĂ€nds utan anvĂ€ndarautentiseringscertifikat, finns det en hög risk för lyckade attacker med sessionstrafikavlyssning och bruteforce-lösenord. NĂ€r det gĂ€ller Cisco ISE blir det betydligt svĂ„rare att knĂ€cka certifikatet â hackarna behöver avsevĂ€rt större berĂ€kningskraft, vilket gör detta fall ganska effektivt.
TrÄdlös Ätkomst Dual-SSID
Essensen av detta scenario ligger i anvÀndningen av 2 nÀtverksidentifierare (SSID). En av dem kan benÀmnas "gÀstÄtkomst". Genom den kan bÄde gÀster och företagets anstÀllda komma in i det trÄdlösa nÀtverket. De anstÀllda omdirigeras vid anslutningsförsök till en sÀrskild portal dÀr provisionering sker. Det innebÀr att anvÀndaren fÄr ett certifikat och konfigurationen av deras personliga enhet sker för automatisk Äteranslutning till det andra SSID, dÀr EAP-TLS anvÀnds med alla fördelar frÄn det första scenariet.
MAC-autentisering Bypass och profilering
Ănnu ett populĂ€rt scenario handlar om automatisk identifiering av typen av ansluten enhet och tillĂ€mpning av rĂ€tt begrĂ€nsningar. Varför Ă€r detta intressant? Det finns fortfarande mĂ„nga enheter som inte stöder autentisering enligt protokollet 802.1X. DĂ€rför mĂ„ste sĂ„dana enheter fĂ„ Ă„tkomst till nĂ€tverket baserat pĂ„ MAC-adressen, som Ă€r ganska lĂ€tt att förfalska. HĂ€r kommer Cisco ISE till hjĂ€lp: systemet kan se hur enheten beter sig i nĂ€tverket, skapa en profil och koppla den till en grupp av andra enheter, som en IP-telefon och en arbetsstation. Om en angripare försöker förfalska MAC-adressen och koppla upp sig i nĂ€tverket, kommer systemet att se att enhetsprofilen har Ă€ndrats, ge en signal om misstĂ€nkt beteende och inte slĂ€ppa in den misstĂ€nkta anvĂ€ndaren i nĂ€tverket.
EAP-Chaining
Teknik EAP-Chaining innebÀr sekventiell autentisering av arbetsstationen och anvÀndarkontot. Denna lösning har blivit vanlig, eftersom mÄnga företag fortfarande inte tillÄter att medarbetarnas personliga enheter kopplas till det företagsinterna nÀtverket. Genom att anvÀnda denna autentisering kan man kontrollera om en viss arbetsstation Àr medlem i domÀnen, och om svaret Àr negativt kan anvÀndaren antingen inte komma Ät nÀtverket eller fÄ begrÀnsad Ätkomst.
Postering
I detta fall handlar det om att bedöma om programvaran pÄ arbetsstationen uppfyller IT-sÀkerhetskraven. Med denna teknik kan man kontrollera om programvaran pÄ arbetsstationen Àr uppdaterad, om skyddsmedel Àr installerade, om hostfirewall Àr korrekt konfigurerad osv. Intressant nog gör denna teknik det ocksÄ möjligt att lösa andra uppgifter som inte Àr relaterade till sÀkerhet, till exempel att kontrollera om nödvÀndiga filer finns eller om gemensamma systemprogram Àr installerade.
Mindre vanliga anvÀndningsfall för Cisco ISE inkluderar Ätkomstkontroll med genomgÄende domÀnautentisering (Passive ID), SGT-baserad mikromolning och filtrering, samt integration med mobila enhetshanteringssystem (MDM) och sÄrbarhetsscanners (Vulnerability Scanner).
SkrÀddarsydda projekt: varför Cisco ISE kan behövas, eller 3 sÀllsynta fall frÄn vÄr praktik
à tkomstkontroll till servrar baserade pÄ Linux
En gĂ„ng arbetade vi med ett ganska komplext fall för en av vĂ„ra kunder som redan hade implementerat Cisco ISE-systemet: vi behövde hitta ett sĂ€tt att kontrollera anvĂ€ndarĂ„tgĂ€rder (det handlade huvudsakligen om administratörer) pĂ„ servrar med installerat Linux OS. I vĂ„r sökning efter ett svar kom vi pĂ„ idĂ©n att anvĂ€nda den fria programvaran PAM Radius Module, som möjliggör inloggning pĂ„ servrar som kör Linux med autentisering pĂ„ en extern radius-server. Allt i denna plan skulle vara bra, om det inte vore för ett "men": radius-servern, i sitt svar pĂ„ autentiseringsbegĂ€ran, skickar endast anvĂ€ndarnamn och resultat â assess accepted eller assess rejected. Under tiden, för att autentisera i Linux, mĂ„ste minst en parameter tilldelas â hemkatalog, sĂ„ att anvĂ€ndaren faktiskt kan komma nĂ„gonstans. Vi fann ingen lösning för att ge detta som en radius-attribut, sĂ„ vi skrev ett speciellt skript för att skapa anvĂ€ndarkonton pĂ„ vĂ€rdar pĂ„ ett halvautomatiskt sĂ€tt. Denna uppgift var helt genomförbar, eftersom vi hade att göra med administratörs konton, vars antal inte var sĂ„ stort. DĂ€refter loggade anvĂ€ndarna in pĂ„ den nödvĂ€ndiga enheten, varefter de blev tilldelade nödvĂ€ndig Ă„tkomst. En berĂ€ttigad frĂ„ga uppstĂ„r: mĂ„ste man nödvĂ€ndigtvis anvĂ€nda just Cisco ISE i sĂ„dana fall? Faktum Ă€r att nej â vilken radius-server som helst skulle fungera, men eftersom kunden redan hade detta system, lade vi helt enkelt till en ny funktion till det.
Inventering av "hÄrdvara" och mjukvara i LAN
En gÄng arbetade vi med ett projekt för leverans av Cisco ISE till en kund utan en preliminÀr "pilot". Det fanns inga tydliga krav pÄ lösningen, och dessutom hade vi att göra med ett platt, icke-segmenterat nÀtverk, vilket komplicerade vÄr uppgift. Under projektet konfigurerade vi alla möjliga profileringmetoder som nÀtverket stödde: NetFlow, DHCP, SNMP, integration med AD, osv. Som ett resultat konfigurerades Ätkomst via MAR, vilket innebar att anvÀndare kunde gÄ in i nÀtverket Àven vid misslyckad autentisering. Det vill sÀga, Àven om autentiseringen inte lyckades fick systemet ÀndÄ anvÀndaren in i nÀtverket, samlade information om denne och registrerade den i ISE-databasen. Denna nÀtverksövervakning under flera veckor hjÀlpte oss att identifiera anslutna system och icke-personliga enheter samt att utveckla en strategi för att segmentera dem. Efter det konfigurerade vi dessutom skÀrmdelning för att installera agenten pÄ arbetsstationer för att samla information om den installerade programvaran. Vad blev resultatet? Vi lyckades segmentera nÀtverket och definiera en lista över programvara som behövde tas bort frÄn arbetsstationerna. Jag ska inte dölja att de följande uppgifterna för att fördela anvÀndarna i domÀngrupper och begrÀnsa Ätkomst rÀttigheterna tog ganska lÄng tid, men pÄ sÄ sÀtt fick vi en fullstÀndig bild av vilken "hÄrdvara" som fanns i kundens nÀtverk. För övrigt var det inte svÄrt tack vare den bra profilering som fungerade "ur lÄdan". DÀr profileringen inte hjÀlpte, tittade vi sjÀlva, och isolerade porten pÄ switchen dit utrustningen var ansluten.
FjÀrrinstallation av programvara pÄ arbetsstationer
Denna fallstudie Àr en av de mest mÀrkliga i min praktik. En gÄng kontaktade en kund oss med ett rop om hjÀlp - vid implementeringen av Cisco ISE gick nÄgot fel, allt kraschade och ingen kunde fÄ tillgÄng till nÀtverket. Vi började utreda och kom fram till följande. Företaget hade 2000 datorer, som i brist pÄ en domÀnkontroller styrdes frÄn administratörskontot. För att göra en inventering implementerades Cisco ISE i organisationen. Man behövde pÄ nÄgot sÀtt förstÄ om antivirusprogram var installerat pÄ de befintliga datorerna, om programvaran var uppdaterad etc. Eftersom nÀtverksutrustningen lades in i systemet av IT-administratörer var det logiskt att de hade tillgÄng till det. Efter att ha sett hur det fungerade och genomfört en inventering av sina datorer kom administratörerna pÄ idén att installera programvara pÄ anstÀlldas arbetsstationer pÄ distans utan personliga besök. TÀnk bara pÄ hur mÄnga steg man kan spara pÄ en dag! Administratörerna genomförde flera kontroller av ARM för att se om en viss fil fanns i katalogen C:Program Files, och om den saknades initierades en automatisk remediering med en lÀnk som ledde till ett filarkiv med installationsfilen .exe. Detta gjorde att vanliga anvÀndare kunde gÄ in i fildelningen och ladda ner den nödvÀndiga programvaran dÀrifrÄn. TyvÀrr kÀnde administratören inte systemet ISE sÀrskilt bra och skadade mekanismerna för inventeringen - han skrev policyn fel, vilket ledde till det problem vi blev inkopplade för att lösa. Jag Àr personligen uppriktigt förvÄnad över en sÄ kreativ lösning, för det hade varit mycket billigare och mindre arbetskrÀvande att skapa en domÀnkontroller. Men som proof of concept fungerade detta.
Mer om de tekniska aspekterna som uppstÄr vid implementeringen av Cisco ISE, lÀs i min kollegas artikel .
Artem Bobrikov, projektörsingenjör vid InformationssĂ€kerhetscenteret pĂ„ företaget âInfosystem Jetâ
Epilog:
Trots att detta inlÀgg handlar om Cisco ISE-systemet, Àr de beskrivna problemen relevanta för hela klassen av NAC-lösningar. Det spelar ingen roll vilket leverantörslösning som ska implementeras - det mesta av det som sagts ovan kommer att förbli tillÀmpligt.
KĂ€lla: habr.com
