Router Expert: Konfigurere CBAC - konfigurasjon Regler og CBAC implementation

Regler konfigurasjon
CBAC kan benyttes som en kant (offentlig /privat transittpunkt) eller innebygd (privat /privat transittpunkt) brannmur. I artikkelen August, dekket vi strategier for å bestemme de aktive tjenestene vi trenger for å gi rom for i tilgangspolitikk. Som vi gå videre til trinn to, skal vi lage en CBAC politikk og konfigurere en Cisco router for å tjene som en kant brannmur. Implementering CBAC som en kant eller innebygd enhet følger samme tre-trinns prosess. Men når implementere CBAC som en kant brannmur for å tjene som et offentlig /privat transitt-enhet, er det mulighet for at CBAC kan trenge å bli deployert med Network /Port Address Translation (N /PAT). Dette er nødvendig for å utnytte RFC1918 for privat nettverk adressering. CBAC er fullt tolkes med PAT og NAT og kan legges over eksisterende implementeringer, forutsatt at innkvartering i tilgangen politikk konto for adresseoversettelses regler.

Opprette tjeneste flytdiagrammer
I den siste utgaven av CBAC serien, har vi fokusert på nettverkstrafikk kvalifisering. Hvis du prøver å implementere CBAC - eller noen annen brannmur, for den saks skyld, uten å kvalifisere nettverkstrafikk, vil du mest sannsynlig har noen virkelig opprørt brukere. Betydningen av trafikken kvalifisering kan ikke understrekes sterkt nok. Når det er sagt, når du har samlet tjeneste utnyttelse data, det første trinnet i politikken etableringen er å skape inngående og utgående tjeneste flytdiagrammer.

Hvorfor? CBAC åpner portene for å være vert-til-vert samtaler skal skje når de først satt i gang. CBAC ettersyn, men fungerer bare etter at tilkoblingen har blitt fullstendig etablert. Men, for at CBAC å operere i det hele tatt, må samtalen skal tillates. Den SACL komponent av CBAC gir mulighet til å definere samtaler som kan etableres. Trafikken kvalifiseringsprosessen identifiserer de tjenestene du trenger for å tillate. Flytskjemaer gi " kart " slik at du kan visualisere data flyter at vertene trenger for å fungere. Sammen med gir nettverk visualisering, diagrammer tilbyr også:

Informasjon: Diagrammene fungere som følge rapporten fra trafikken kvalifiseringsprosessen og informasjonen ressurs for generering av tilgangspolitiske regler.

Dokumentasjon: For feilsøking access-regel problemer og kanskje enda viktigere de gir andre dokumentasjonen til å forstå hva du tenkte da du opprettet regelsettet.

Etnisitet resultater: Under testing og tuning scenen kartene detalj hvilke tjenester bør faktisk være synlig for usikrede brukere.

Eksempel flytdiagrammer
Vårt eksempel nettverket er (selvfølgelig) enkel. Den sikre nettverk er en enkelt klasse C subnett som inneholder bruker verter og seks tjenester verter. Fire av server vertene tilby tjenester som er tilgjengelig fra utsiden av det sikre nettverket. One (AAA-server) er kun tilgjengelig lokalt, og den andre (DNS /DHCP) har en sekundær avhengighet til eksterne servere. Her er en inngående tjeneste flytdiagram for vårt eksempel nettverket:

Her er den utgående tjeneste flytdiagram:

Diagrammene inneholde verten IP løse sammen med vertens tjenestetilbud (angitt med en S) og service primære og sekundære avhengig (angitt med en D). Ruterens CBAC ip-tilgang-gruppen
reglene vil gjenspeile disse avhengigheter ved å tillate tilgang til vertene og tjenesteportene.

Om " vertsavhengig " - Vertskapet er koblet til et nettverk opererer ikke i et vakuum. Ofte har de avhengigheter på andre verter for å kunne tjene sin funksjon. Disse avhengigheter kan kategoriseres i to klasser: primære og sekundære. En primære avhengighet
er et kommunikasjonsutveksling mellom to verter som er avgjørende for at verten for å utføre sin primære funksjon. Et eksempel på dette er en webserver som fungerer som en front-end til en DBMS server. Hvis webserveren og DBMS serveren ikke kan utveksle data, så er det ingen hensikt i å ha webserveren. En sekundær avhengighet er en kommunikasjon utveksling som er viktig, men ville sitt fravær ikke gjengi det vert ute av stand til å utføre sin primære funksjon. Et eksempel på dette ville være tilgang til en server logging. Hvis webserveren fungerer som front-end til DBMS serveren mistet tilgang til sin logging server, ville det være et problem, men det vil ikke hindre serveren fra å fungere.

diagram ut hver vertens funksjonelle og avhengige tilgang krav kan virke som overkill (spesielt i store og komplekse nettverk). Men du vil finne innsatsen verdt. Forstå utveksling av data mellom maskiner er avgjørende for å skape en funksjonell og effektiv sikkerhet tilgang politikk. Det gjør feilsøking og testing mye enklere, sammen med å gi deg med dataene for å avkrefte det uunngåelige, " det fungerte før du implementert sikkerhetspolitikk " klage du vil utvilsomt få fra systemadministratorer og brukere av systemene og tjenestene du prøver å beskytte.

CBAC implementering
Gjennomføringen av CBAC på en IOS router innebærer fire konfigurasjonsoppgaver:

Interface utvalg

SACL etableringen

Inspeksjon regel oppretting

Interface konfigurasjon

Interface utvalg
Fordi CBAC er en type access-kontrollisten, er den første oppgaven med selve konfigurasjonen for å avgjøre på hvilket grensesnitt (s) for å konfigurere CBAC. CBAC kan konfigureres en rekke forskjellige måter, avhengig av nettverket topologi. Som en oppfriskning, her er et diagram som gjenspeiler hvordan IP-pakker blir behandlet av de router tilgang lister.

Det er fire CBAC enkel implementering topologier for å kontrollere tilgang. En implementering kan benytte til å kontrollere en trafikk ensrettet eller en kombinasjon av to til å styre trafikken begge veier.

CBAC inspeksjon på interne grensesnittet med Adgangskontroll på utsiden grensesnittet.

CBAC inspeksjon på utsiden grensesnitt med Adgangskontroll på innsiden grensesnittet

CBAC inspeksjon og tilgangskontroll på utsiden grensesnittet

CBAC inspeksjon og tilgangskontroll på innsiden grensesnittet

Vårt eksempel miljøet krever privat til offentlig og offentlig-til-private samtaler. Slik at en kombinasjon av en topologier, og to er en god blanding. Den støtter tilgang modell nødvendig med begrenset kompleksitet og vil være lett å feilsøke.

SACL etableringen
Bruke flytdiagrammer som en guide, må vi opprette to SACLs å definere de tillatte utgående samtaler og gi den plassholder for dynamiske ACL uttalelser som gjør at samtalen " tilbake " trafikk. CBAC vil arbeide med både numeriske og navngitte utvidet tilgang lister. Mens både utføre like godt, bruker navngitte tilgangslister har noen fordeler. Først de virker som en feilsøkingsapparatet fordi access-listens navn kan benyttes som en referanse. For det andre navngitte tilgangslister er redigerbar. Så verter og tjenester kan legges til og fjernes uten å måtte opprette en ny liste. Fordi det er en god idé å ta alle fordeler vi kan, vil våre eksempler bruke navngitte lister.

Utenfor inngående liste
Base listen på funnene som er beskrevet i den inngående tjeneste flytdiagram. Brukere utenfor det sikre nettverket trenger tilgang til:

POP3 kjører på verts 66.45.100.66

SMTP kjører på verts 66.45.100.2

SSH /FTP kjører på verts 66,45. 100,49

HTTP, SSH, og Squid kjører på verts 66.45.100.44

Sammen med disse TCP baserte tjenester, vi må også konfigurere (hvis ønskelig) ICMP. Per 12.2.15T, har blitt lagt Stateful inspeksjon av visse ICMP-meldingstyper.

 Type 0 Echo replyType 3 Destinasjon unreachableType 8 Echo requestType 11 Tid exceededType 13 Stempel requestType 14 Stempel svar.  Denne forbedringen ble lagt for å gi vertene tilkoblet sikret nettverk for å generere ICMP-meldinger til vertene på usikret side av ruteren. Alternativet gir liten effekt når implementert for å spore ICMP-meldinger stammer fra usikrede verter. Så hvis meldingen støtte ICMP fra eksterne verter til interne verter er nødvendig, bør støtte iverksette for bestemte verter og for bestemte meldingstyper. I tillegg er det en god idé å implementere ICMP hastighetsbegrensende (se oktober 2002) for å motvirke eventuelle ICMP utnytte som kunne distribueres mot de sikret vertene. Fordi disse er " eksternt " tilgang til tjenester, støtte for  ping 
 kommandoen er en nødvendighet for feilsøking. Så vi vil inkludere støtte for ICMP ekko og ekko-svar for de fire servere. 
 
 Her er -konfigurasjonssyntaksen dialogboksen for vår ekstern inngående SACL: 
 
 lab-router (config) # ip access-list utvidet eksterne-services-SACLlab-router (config-ext-NaCl) #permit tcp noen vert 66.45.100.60 eq pop3lab-router (config-ext-NaCl) #permit TCP noen vert 66.45.100.2 eq smtp lab-router (config-ext-NaCl) #permit TCP noen vert 66.45.100.49 eq 22 lab -router (config-ext-NaCl) #permit TCP noen vert 66.45.100.44 eq 22lab-router (config-ext-NaCl) #permit TCP noen vert 66.45.100.49 ftp lab-router (config-ext-NaCl) #permit tcp noen vert 66.45.100.49 eq ftplab-router (config-ext-NaCl) #permit TCP noen vert 66.45.100.49 eq ftp-datalab-router (config-ext-NaCl) #permit TCP noen vert 66.45.100.44 eq 3128 lab-ruter (config-ext-NaCl) #permit TCP noen vert 66.45.100.44 eq 80lab-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.60 ECHOLAB-router (config-ext-NaCl) #permit ICMP noen vert 66,45 .100.2 ekko lab-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.44 ECHOLAB-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.49 ECHOLAB-router (config-ext-NaCl) # Tillatelsen ICMP noen vert 66.45.100.60 ekko-replylab-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.2 ekko-svar lab-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.44 ekko- replylab-router (config-ext-NaCl) #permit ICMP noen vert 66.45.100.49 ekko-svar   Inside inngående liste 
 For vårt eksempel, følger innsiden filterliste samme linje som utsiden filter; tillatte tjenester er eksplisitt definert. Denne tilnærmingen er den sikreste, men er også den mest konstriktiv til brukeren. Hvis den eksterne tjenesten ikke utnytter en tillatt protokollen og service port, vil det ikke fungere. Base denne listen på funnene som er beskrevet i den utgående tjeneste flytdiagram. Verter på det sikre nettverket trenger tilgang til følgende protokoller på eksterne verter: 
 
 SSH /FTP for den generelle bruker befolkningen 
 
 HTTP /HTTPS for verts 66.45.100.44 
 < li> DNS (TCP) for verts 66.45.100.101 
 
 DNS (UDP) for verts 66.45.100.101 
 
 TACACS for 66.45.100.254 
 I de fleste miljøer, HTTP er tillatt. Dessverre har de fleste av programmene administratorer ikke ønsker at brukerne skal bruke vil operere over eller tunnel gjennom HTTP (80) eller HTTPS (443). For å motvirke dette har en HTTP /HTTPS Squid proxy-server er iverksatt, og brukerne er ikke tillatt å stamme HTTP /HTTPS-tilkoblinger utgående. Gjennomføringen av Squid gir noen store fordeler. Først eliminerer det brukerens evne til å utnytte bruken av port 80 og 443 for uautoriserte programmer. Sekund, klarer den den tilgjengelige båndbredden mer effektivt, fordi brukerne har en felles web cache. Tredje, (dette kan være en ulempe) gjør det mulig for selskapet å overvåke HTTP aktivitet, spesielt upassende aktivitet slik at den kan beskytte seg selv. Endelig kan det fungere som en Web anonymizer for eksterne verter (som er grunnen til eksterne verter har adgang) som ikke ønsker å ha sine IP-adresser logget på Web server tilgang til loggene. Squid støtter flere godkjenningsordninger, slik at tilgangen kan kontrolleres. 
 
 Her er -konfigurasjonssyntaksen dialogboksen for vår interne innkommende SACL: 
 
 lab-router (config-ext-NaCl) # ip access-list utvidet intern-perm-påhengs-servlab-router ( config-ext-NaCl) #permit tcp vert 66.45.101.100 vert 65.45.101.254 eq tacacslab-router (config-ext-NaCl) #permit tcp vert 66.45.101.100 vert 65.45.101.254 gt 1024lab-router (config-ext-NaCl) #permit tcp 66.45.101.0 0.0.0.255 vert 65.45.101.1 eq 22lab-router (config-ext-NaCl) #permit icmp 66.45.101.0 0.0.0.255 vert 65.45.101.1 ECHOLAB-router (config-ext-NaCl) #permit tcp vert 66.45.100.44 noen eq 80 lab-router (config-ext-NaCl) #permit tcp vert 66.45.100.44 noen eq 443lab-router (config-ext-NaCl) #permit tcp vert 66.45.100.101 noen eq domainlab-router (config -ext-NaCl) #permit udp vert 66.45.100.101 noen eq domainlab-router (config-ext-NaCl) #permit tcp 66.45.101.0 0.0.0.255 noen eq ftplab-router (config-ext-NaCl) #permit TCP 66,45. 101,0 0.0.0.255 noen eq ftp-datalab-router (config-ext-NaCl) #permit icmp 66.45.101.0 0.0.0.255 noen ekko lab-router (config-ext-NaCl) #permit icmp 66.45.101.0 0.0.0.255 noen ekko -reply   Inspeksjon regel oppretting 
 Cisco anbefaler at du stiller de tilstandskontroll regel variabler før du lager CBAC inspeksjon regler. Men du skal tune mange av disse variablene du virkelig trenger data om ting som for eksempel økt volum (per tjeneste), session satt opp, økt varighet, etc. (Vi vil få inn hvordan å samle disse dataene neste gang.) Selvfølgelig, Dette er data de fleste folk ikke har når de setter opp sine brannmurer. Så hvordan akkurat du skal tune CBAC riktig? Tross alt, er verdien av tuning å stramme opp konfigurasjonen for å møte kravene stedets. Du vil finne at når brannmuren er gjennomført, vil dette bli et pågående arbeid. Så når du først gjennomføre CBAC, er best å kjøre med standardinnstillingene, samle data, og deretter tune. 
 
 Uten byrden av tuning, skape CBAC reglene er ganske enkel. Antallet protokoller som CBAC kan gi inspeksjon varierer avhengig av IOS versjon. Kommandoen -konfigurasjonssyntaksen imidlertid ikke. For de fleste " protokoller " kommandoen format er  < ip inspisere navn {regelsett navn} {protokollen} {alert [on | off]} {revisjons-trail [on | off]} {timeout [i sek]} > 
 . Varselet bryteren aktiverer /deaktiverer overtredelses merknader. Revisjons-trail alternativet slår på detaljert session tracking (src /dest adresse og portnumre og byte overført). Hvis du aktiverer RPC inspeksjon, er konfigurasjonen syntaks  < ip inspisere {name [regelsett name]} RPC-programmet-nummer {prog #} vente-tid {i min} {alert [on | off]} {revisjon -TRAIL [on | off]} {timeout [i sek]} > 
. 
 
 Cisco anbefaler igjen opprettelsen av et enkelt regelsett for de fleste implementeringer. Hvis imidlertid CBAC inspeksjon blir gjennomført på flere grensesnitt og /eller ulike retninger, er det tilrådelig (ifølge Cisco) for å opprette flere regelsett. Etter mye eksperimentering, virker det som den eneste grunnen til å konfigurere mer enn en enkelt CBAC regelsettet er når kravene inspeksjons for grensesnittene er forskjellige. Og selv da, kan du opprette en meta-liste som dekker kravene til begge deler. 
 
 For vårt eksempel nettverk, må vi definere fire inspeksjonsregler for eksternt grensesnitt og fem regler for det indre. Her er dialogen -konfigurasjonssyntaksen for det eksterne grensesnittet CBAC regelsett: 
 
 lab-router (config) # ip inspisere navn eksterne-kontroll-innkommende tcplab-router (config) # ip inspisere navn eksterne-kontroll-innkommende udplab-router (config) # ip inspisere navn eksterne-kontroll-innkommende ftplab-router (config) # ip inspisere navn eksterne-kontroll-inngående smtp  Her er dialogen -konfigurasjonssyntaksen for det interne grensesnittet CBAC regelsett: 
 
 lab-router (config) # ip inspisere navn intern-kontroll-utgående tcplab-router (config) # ip inspisere navn intern-kontroll-utgående udplab-router (config) # ip inspisere navn intern-kontroll-utgående ftplab -router (config) # ip inspisere navn intern-kontroll-utgående smtplab-router (config) # ip inspisere navn intern-kontroll-utgående ICMP  Disse to regelsettene treffer mark for de fleste miljøer (Legg merke til at revisjons-trail logging har ikke blitt aktivert, vil vi komme inn på hvorfor neste måned). TCP og UDP reglene gir inspeksjon for ett-session program. FTP og SMTP inspeksjonsregler overvåke for protokoll konkrete brudd. Som for ICMP inspeksjon, det fungerer bare for de støttede protokoller og bare spor stat basert på kilden til meldingen. Så selv om det kan administratorer gi smak ICMP støtte, er dens nytte tvilsom i motsetning til ved hjelp av verktøy som hastighetsbegrensende å bufre potensielt skadelig ICMP bruk. Det beste alternativet er å bruke både CBAC ICMP inspeksjon og hastighetsbegrensende. 
 
  Interface konfigurasjon 
 Det synes som CBAC ble utviklet som en " hardt på utsiden, myk på innsiden " sikkerhetsteknologi (minst at hvordan dokumentasjonen skildrer det). Cisco retningslinje om hvordan du installerer CBAC på ruteren grensesnitt er skrå mot denne bruken modell. Etter litt eksperimentering, men det kan hurtig fastslått at CBAC er i stand til mer enn bare å beskytte en Soho fra Internett. Det er derfor vi har diskutert alle de CBAC topologi variasjoner dekket over. Forhåpentligvis vil det gi et mer komplett bilde for deg enn dokumentasjonen Cisco. 
 
 Vårt eksempel implementerer CBAC inspeksjon fra eksternt og internt gytt tilkoblinger. For enkelthets skyld benytter det topologier en og to i kombinasjon. Interface konfigurasjon omfatter to trinn. Først må du bruke SACL som en IP-tilgangsgruppe på grensesnittet: 
 
 lab-router (config) #interface ethernet 0 /0lab-router (config-hvis) # ip-tilgang-gruppen ekstern-tjenester- SACL i  Deretter vil du bruke CBAC inspeksjon regel som vil endre IP access-gruppen SACL. I dette tilfellet vil det være installert på innsiden grensesnittet. Konfigurasjonen syntaks er < ip inspisere  {regelsett navn} {inn | ut} 
 >. 
 
 lab-router (config) #interface ethernet 0 /1lab-router (config-hvis) # ip inspisere intern-kontroll-utgående i  Derimot er CBAC regelsettet er installert på den eksterne grensesnittet vil endre den SACL tilknyttet IP tilgangsgruppe installert på innsiden grensesnittet. 
 
 lab-router (config) #interface ethernet 0 /1lab-router (config-hvis) # ip-tilgang-gruppen intern-perm-påhengs-serv InLab-router (config-hvis) # exitlab-router ( config) #interface ethernet 0 /0lab-router (config-hvis) # ip inspisere intern-kontroll-utgående i  Som dekker det grunnleggende for å implementere CBAC på iOS FFS rutere. Men fortvil ikke, vi har fortsatt å dekke tuning, revisjon, feilsøking, feilretting og logging. Jeg vil lagre det på neste måned. Som alltid, håper du finner dette nyttig og tilbakemeldinger er alltid velkommen. Ser du neste måned (kanskje på Nettverk Vedtak konferansen i Atlanta) samme bat tid, samme bat kanal. 
 
  denne artikkelen nyttig for deg Var? Har du forslag til temaer du ønsker vi skal ta opp? Send en e-post til oss og gi oss beskjed! 

            
            
 
		  





Previous:Hvor mulig er det å implementere ATM i et lite trafikkert område (landlig område)  
Next Page:Hvordan kan vi skape et best mulig IT strategisk plan?