Hvor ofte køber du spontant noget, bukker under for en sej reklame, og så samler denne oprindeligt ønskede genstand støv i et skab, pantry eller garage indtil næste forårsrengøring eller flytning? Resultatet er skuffelse på grund af uberettigede forventninger og spildte penge. Det er meget værre, når det sker for en virksomhed. Meget ofte er marketinggimmicks så gode, at virksomheder køber en dyr løsning uden at se det fulde billede af dens anvendelse. I mellemtiden hjælper prøvetest af systemet med at forstå, hvordan man forbereder infrastrukturen til integration, hvilken funktionalitet og i hvilket omfang der skal implementeres. På denne måde kan du undgå et stort antal problemer på grund af at vælge et produkt "blindt". Derudover vil implementering efter en kompetent "pilot" bringe ingeniører meget mindre ødelagte nerveceller og gråt hår. Lad os finde ud af, hvorfor pilottest er så vigtigt for et vellykket projekt, ved at bruge eksemplet på et populært værktøj til at kontrollere adgangen til et virksomhedsnetværk - Cisco ISE. Lad os overveje både standard og helt ikke-standard muligheder for at bruge den løsning, vi stødte på i vores praksis.
Cisco ISE - "Radius-server på steroider"
Cisco Identity Services Engine (ISE) er en platform til at skabe et adgangskontrolsystem til en organisations lokale netværk. I ekspertsamfundet fik produktet tilnavnet "Radius-server på steroider" for dets egenskaber. Hvorfor det? Grundlæggende er løsningen en Radius-server, hvortil der er knyttet et stort antal yderligere tjenester og "tricks", så du kan modtage en stor mængde kontekstuel information og anvende det resulterende sæt af data i adgangspolitikker.
Som enhver anden Radius-server interagerer Cisco ISE med netværksudstyr på adgangsniveau, indsamler oplysninger om alle forsøg på at oprette forbindelse til virksomhedens netværk og, baseret på godkendelses- og autorisationspolitikker, tillader eller nægter brugere adgang til LAN. Muligheden for profilering, udstationering og integration med andre informationssikkerhedsløsninger gør det dog muligt at komplicere autorisationspolitikkens logik betydeligt og derved løse ganske vanskelige og interessante problemer.
Implementering kan ikke afprøves: hvorfor har du brug for test?
Værdien af pilottest er at demonstrere alle systemets muligheder i den specifikke infrastruktur i en specifik organisation. Jeg tror på, at pilotering af Cisco ISE før implementering gavner alle involverede i projektet, og her er hvorfor.
Dette giver integratorer en klar idé om kundens forventninger og hjælper med at skabe en korrekt teknisk specifikation, der indeholder meget flere detaljer end den almindelige sætning "sørg for, at alt er i orden." "Pilot" giver os mulighed for at føle al smerten fra kunden, at forstå, hvilke opgaver der er en prioritet for ham, og hvilke der er sekundære. For os er dette en glimrende mulighed for på forhånd at finde ud af, hvilket udstyr der bruges i organisationen, hvordan implementeringen vil foregå, på hvilke steder, hvor de er placeret og så videre.
Under pilottest kan kunderne se det virkelige system i aktion, stifte bekendtskab med dets interface, kan tjekke, om det er kompatibelt med deres eksisterende hardware, og få en holistisk forståelse af, hvordan løsningen vil fungere efter fuld implementering. "Pilot" er selve det øjeblik, hvor du kan se alle de faldgruber, du sandsynligvis vil støde på under integrationen, og bestemme, hvor mange licenser du skal købe.
Hvad kan "dukke op" under "piloten"
Så hvordan forbereder du dig ordentligt til implementering af Cisco ISE? Ud fra vores erfaring har vi talt 4 hovedpunkter, som er vigtige at overveje under pilottestningen af systemet.
Form faktor
Først skal du beslutte i hvilken formfaktor systemet skal implementeres: fysisk eller virtuel upline. Hver mulighed har fordele og ulemper. For eksempel er styrken ved en fysisk upline dens forudsigelige ydeevne, men vi må ikke glemme, at sådanne enheder bliver forældede med tiden. Virtuelle uplines er mindre forudsigelige, fordi... afhænger af den hardware, som virtualiseringsmiljøet er installeret på, men de har en seriøs fordel: Hvis support er tilgængelig, kan de altid opdateres til den nyeste version.
Er dit netværksudstyr kompatibelt med Cisco ISE?
Selvfølgelig ville det ideelle scenarie være at tilslutte alt udstyr til systemet på én gang. Dette er dog ikke altid muligt, da mange organisationer stadig bruger ikke-administrerede switches eller switches, der ikke understøtter nogle af de teknologier, der kører Cisco ISE. Vi taler i øvrigt ikke kun om switches, det kan også være trådløse netværkscontrollere, VPN-koncentratorer og alt andet udstyr, som brugerne forbinder sig med. I min praksis har der været tilfælde, hvor kunden, efter at have demonstreret systemet til fuld implementering, opgraderet næsten hele flåden af adgangsniveauomskiftere til moderne Cisco-udstyr. For at undgå ubehagelige overraskelser er det værd at finde ud af på forhånd andelen af ikke-understøttet udstyr.
Er alle dine enheder standard?
Ethvert netværk har typiske enheder, der ikke burde være vanskelige at oprette forbindelse til: arbejdsstationer, IP-telefoner, Wi-Fi-adgangspunkter, videokameraer og så videre. Men det sker også, at ikke-standardiserede enheder skal tilsluttes LAN, for eksempel RS232/Ethernet-bussignalomformere, uafbrydelige strømforsyningsgrænseflader, forskelligt teknologisk udstyr osv. Det er vigtigt at bestemme listen over sådanne enheder på forhånd , så du allerede på implementeringsstadiet har en forståelse af, hvordan de teknisk set vil arbejde med Cisco ISE.
Konstruktiv dialog med IT-specialister
Cisco ISE-kunder er ofte sikkerhedsafdelinger, mens it-afdelinger normalt er ansvarlige for at konfigurere adgangslagsswitches og Active Directory. Derfor er produktivt samspil mellem sikkerhedsspecialister og it-specialister en af de vigtige forudsætninger for smertefri implementering af systemet. Hvis sidstnævnte opfatter integration med fjendtlighed, er det værd at forklare dem, hvordan løsningen vil være nyttig for IT-afdelingen.
Top 5 Cisco ISE use cases
Det er vores erfaring, at den nødvendige funktionalitet af systemet også identificeres på pilotteststadiet. Nedenfor er nogle af de mest populære og mindre almindelige use cases for løsningen.
Sikker LAN-adgang over en ledning med EAP-TLS
Som resultaterne af vores pentesteres forskning viser, bruger angribere ganske ofte almindelige stik, som printere, telefoner, IP-kameraer, Wi-Fi-punkter og andre ikke-personlige netværksenheder er forbundet til for at trænge ind i en virksomheds netværk. Derfor, selvom netværksadgang er baseret på dot1x-teknologi, men alternative protokoller bruges uden brug af brugergodkendelsescertifikater, er der stor sandsynlighed for et vellykket angreb med sessionsaflytning og brute-force-adgangskoder. I tilfældet med Cisco ISE vil det være meget sværere at stjæle et certifikat - til dette vil hackere have brug for meget mere computerkraft, så denne sag er meget effektiv.
Dual-SSID trådløs adgang
Essensen af dette scenarie er at bruge 2 netværksidentifikatorer (SSID'er). En af dem kan betinget kaldes "gæst". Gennem den kan både gæster og virksomhedens medarbejdere få adgang til det trådløse netværk. Når de forsøger at oprette forbindelse, bliver sidstnævnte omdirigeret til en særlig portal, hvor klargøring finder sted. Det vil sige, at brugeren får udstedt et certifikat, og hans personlige enhed er konfigureret til automatisk at oprette forbindelse til det andet SSID, som allerede bruger EAP-TLS med alle fordelene ved det første tilfælde.
MAC Authentication Bypass og profilering
En anden populær anvendelse er automatisk at registrere den type enhed, der tilsluttes, og anvende de korrekte begrænsninger på den. Hvorfor er han interessant? Faktum er, at der stadig er ret mange enheder, der ikke understøtter godkendelse ved hjælp af 802.1X-protokollen. Derfor skal sådanne enheder have adgang til netværket ved hjælp af en MAC-adresse, som er ret let at forfalske. Det er her Cisco ISE kommer til undsætning: ved hjælp af systemet kan du se, hvordan en enhed opfører sig på netværket, oprette dens profil og tildele den til en gruppe andre enheder, for eksempel en IP-telefon og en arbejdsstation . Hvis en hacker forsøger at forfalske en MAC-adresse og oprette forbindelse til netværket, vil systemet se, at enhedsprofilen er ændret, vil signalere mistænkelig adfærd og vil ikke tillade den mistænkelige bruger at komme ind på netværket.
EAP-kæde
EAP-Chaining-teknologi involverer sekventiel godkendelse af den fungerende pc og brugerkonto. Denne sag er blevet udbredt, fordi... Mange virksomheder opfordrer stadig ikke til at forbinde medarbejdernes personlige gadgets til virksomhedens LAN. Ved at bruge denne tilgang til autentificering er det muligt at kontrollere, om en bestemt arbejdsstation er medlem af domænet, og hvis resultatet er negativt, vil brugeren enten ikke få adgang til netværket, eller vil være i stand til at komme ind, men med visse restriktioner.
poseren
Denne sag handler om at vurdere arbejdsstationssoftwarens overensstemmelse med krav til informationssikkerhed. Ved hjælp af denne teknologi kan du kontrollere, om softwaren på arbejdsstationen er opdateret, om sikkerhedsforanstaltninger er installeret på den, om værtsfirewallen er konfigureret osv. Interessant nok giver denne teknologi dig også mulighed for at løse andre opgaver, der ikke er relateret til sikkerhed, for eksempel at kontrollere tilstedeværelsen af nødvendige filer eller installere systemdækkende software.
Mindre almindelige use cases for Cisco ISE omfatter adgangskontrol med end-to-end domænegodkendelse (passivt ID), SGT-baseret mikrosegmentering og filtrering samt integration med mobile device management (MDM)-systemer og sårbarhedsscannere.
Ikke-standardprojekter: hvorfor skulle du ellers have brug for Cisco ISE, eller 3 sjældne tilfælde fra vores praksis
Kontrol af adgang til Linux-baserede servere
Engang løste vi en temmelig ikke-triviel sag for en af de kunder, der allerede havde implementeret Cisco ISE-systemet: Vi var nødt til at finde en måde at kontrollere brugerhandlinger (for det meste administratorer) på servere med Linux installeret. I søgen efter et svar kom vi på ideen om at bruge den gratis PAM Radius Module-software, som giver dig mulighed for at logge ind på servere, der kører Linux med godkendelse på en ekstern radiusserver. Alt i denne henseende ville være godt, hvis ikke for et "men": radiusserveren, der sender et svar på godkendelsesanmodningen, giver kun kontonavnet og resultatet - vurder accepteret eller vurder afvist. I mellemtiden, for autorisation i Linux, skal du tildele mindst én parameter mere - hjemmemappe, så brugeren i det mindste kommer et sted hen. Vi fandt ikke en måde at give dette som en radius-attribut, så vi skrev et særligt script til fjernoprettelse af konti på værter i en semi-automatisk tilstand. Denne opgave var ganske mulig, da vi havde at gøre med administratorkonti, hvor antallet ikke var så stort. Herefter loggede brugere på den nødvendige enhed, hvorefter de fik tildelt den nødvendige adgang. Et rimeligt spørgsmål opstår: er det nødvendigt at bruge Cisco ISE i sådanne tilfælde? Faktisk nej - en hvilken som helst radiusserver duer, men da kunden allerede havde dette system, tilføjede vi simpelthen en ny funktion til det.
Opgørelse af hardware og software på LAN
Vi arbejdede engang på et projekt om at levere Cisco ISE til én kunde uden en foreløbig "pilot". Der var ingen klare krav til løsningen, plus vi havde at gøre med et fladt, ikke-segmenteret netværk, hvilket komplicerede vores opgave. I løbet af projektet konfigurerede vi alle mulige profileringsmetoder, som netværket understøttede: NetFlow, DHCP, SNMP, AD-integration mv. Som et resultat blev MAR-adgang konfigureret med mulighed for at logge på netværket, hvis godkendelse mislykkedes. Det vil sige, at selvom godkendelse ikke lykkedes, ville systemet stadig tillade brugeren at komme ind i netværket, indsamle oplysninger om ham og registrere dem i ISE-databasen. Denne netværksovervågning over flere uger hjalp os med at identificere forbundne systemer og ikke-personlige enheder og udvikle en tilgang til at segmentere dem. Herefter konfigurerede vi desuden posting til at installere agenten på arbejdsstationer for at indsamle oplysninger om den software, der er installeret på dem. Hvad er resultatet? Vi var i stand til at segmentere netværket og bestemme listen over software, der skulle fjernes fra arbejdsstationer. Jeg vil ikke lægge skjul på, at yderligere opgaver med at distribuere brugere i domænegrupper og afgrænse adgangsrettigheder tog os ret meget tid, men på denne måde fik vi et komplet billede af, hvilken hardware kunden havde på netværket. Det var i øvrigt ikke svært på grund af det gode arbejde med at profilere ud af boksen. Nå, hvor profilering ikke hjalp, kiggede vi os selv og fremhævede switchporten, som udstyret var tilsluttet.
Fjerninstallation af software på arbejdsstationer
Denne sag er en af de mærkeligste i min praksis. En dag kom en kunde til os med et råb om hjælp - noget gik galt, da Cisco ISE implementeredes, alt gik i stykker, og ingen andre kunne få adgang til netværket. Vi begyndte at undersøge det og fandt ud af følgende. Virksomheden havde 2000 computere, som i mangel af en domænecontroller blev administreret under en administratorkonto. Med henblik på peering implementerede organisationen Cisco ISE. Det var nødvendigt på en eller anden måde at forstå, om et antivirus var installeret på eksisterende pc'er, om softwaremiljøet blev opdateret osv. Og da it-administratorer installerede netværksudstyr i systemet, er det logisk, at de havde adgang til det. Efter at have set, hvordan det fungerer, og efter at have udbedret deres pc'er, kom administratorerne på ideen om at installere softwaren på medarbejdernes arbejdsstationer eksternt uden personlige besøg. Forestil dig, hvor mange skridt du kan spare om dagen på denne måde! Administratorerne udførte adskillige kontroller af arbejdsstationen for tilstedeværelsen af en specifik fil i mappen C:Program Files, og hvis den var fraværende, blev automatisk afhjælpning startet ved at følge et link, der førte til fillagringen til installations-.exe-filen. Dette gjorde det muligt for almindelige brugere at gå til en fildeling og downloade den nødvendige software derfra. Desværre kendte administratoren ikke ISE-systemet godt og beskadigede bogføringsmekanismerne - han skrev politikken forkert, hvilket førte til et problem, som vi var med til at løse. Personligt er jeg oprigtigt overrasket over sådan en kreativ tilgang, for det ville være meget billigere og mindre arbejdskrævende at lave en domænecontroller. Men som et proof of concept virkede det.
Læs mere om de tekniske nuancer, der opstår ved implementering af Cisco ISE i min kollegas artikel .
Artem Bobrikov, designingeniør for Information Security Center hos Jet Infosystems
efterskrift:
På trods af at dette indlæg taler om Cisco ISE-systemet, er de beskrevne problemer relevante for hele klassen af NAC-løsninger. Det er ikke så vigtigt, hvilken leverandørs løsning der er planlagt til implementering - det meste af ovenstående vil fortsat være gældende.
Kilde: www.habr.com