For mer bakgrunn, lese Forstå TCP /IP for å hindre angrep på nettverket, del 1 og forståelse TCP /IP for å hindre angrep på nettverket, del 2.

jeg har en brannmur og Intrusion Detection system (IDS). Hvorfor trenger jeg SACLs på min router?
Først, hvis du ikke har en brannmur og /eller nettverk IDS og har offentlig tilgjengelige verter, så bør du som et minimum skal bruke innkommende og utgående SACLs, så klikker du deg til neste avsnitt. Hvis du har en brannmur eller vert eller nettverk IDS (hisD /NIDS), er det noen veldig gode grunner til å bruke SACLs for både sikkerhet og ytelse.

Kort sagt, kan du kaste trafikk du rett og slett ikke vil ha, dvs. falske pakker med falsk eller RFC-1918-adresser, denial of service (DOS) og distribuerte DoS-angrep, og eventuelle nettverkstjeneste du ikke støtter (Internett-spill, chat, etc.). Når det gjelder effektivitet, bare gjør dette fornuftig. Det er rett og slett ingen grunn til å behandle trafikk som ikke er legitim. Avhengig av størrelsen på Internett-forbindelsen og synligheten av vertskapet, kan nettverksadministratorer forvente noen fra 2% til 10% av deres utnyttes innkommende nettverksbåndbredde å bli fortært av ". Støy "

Brannmurer og IDS arbeid ved å behandle hele (inngående /utgående) trafikkflyt. Denne behandlingen innebærer å inspisere hele pakkeinnhold ved å sammenligne den pakken til en regel base (brannmur) eller signatur database (IDS) og deretter bestemme en håndtering handling (forover /slipp /varsling /alarm). I tilfelle av brannmurer som opererer ved hjelp av Network Address Translation (NAT), er det lagt NAT behandling også. Alle disse prosesser forbruker ressurser. I lav til moderat gjennomstrømning miljøer, ikke behandlingen av en ekstra 2% til 15% av trafikken ikke oversette til lesbar ytelsen.

I høy gjennomstrømning miljøer, men behandlingen av støy trafikk gjør innvirkning ytelse. For eksempel, et Internett-tilgangspunkt med to DS3s fra ulike leverandører har en maksimal kapasitet på 90 Mbps. Hvis vi installerer en Nokia 500 kjører Check Point FW1 med NAT, som har totalt videresending evnen til 90+ Mbps med en intern og en ekstern grensesnitt, er vi i stand til å utnytte alle våre tilgjengelige båndbredden. Hvis vi antar gjennomsnittet for støy, vil bare en av våre ufiltrerte Internett-tilkoblinger på ledningen hastighet behandle 4,25 Mbps støy. Det gjør en totalt 8 + Mbps trafikk som ikke er i det hele tatt er relevant for våre produksjonskrav at vår brannmur trenger å behandle. På sikkerhetssiden, gjennomføring SACLs gir et lag av filtrering i tillegg til brannveggen. Den gir også beskyttelse mot potensielle brannmuren politikk feilkonfigurasjon og ulovlige verter som omgår brannmuren helt.

Når du bruker NIDS, SACLs bidra til å løse ytelsesproblemer. Som brannmurer, NIDS har en gjennomstrømming behandlingen tak. De fleste (ikke alle) NIDS har problemer behandlingen konsekvent trafikkpriser over 15 til 20 Mbps, noe som resulterer i droppet (ubehandlet) pakker, og i noen tilfeller, systemkrasj. I vårt eksempel miljø, hvis vi skal ha Internett tilgjengelig verter, ville vi trenger å legge til flere brannmur grensesnitt (synkende vår brannmur gjennomstrømning kapasitet) slik at vi kunne strukturere trafikk gjennomstrømningen (ved å distribuere vertene på tvers av flere DMZ grensesnitt) for å tillate NIDS å være effektive. Denne fremgangsmåten har imidlertid både skaleringsproblemer og ytelse bivirkninger.

Som om ytelsesproblemer var ikke nok, det er også ytelsen virkningen av hendelsesalarmer. Implementering NIDS på offentlig tilgjengelige nettverkssegmenter har noen tvilsom verdi, fordi flertallet av påvisbare hendelsene er uløselig fra et søksmål ståsted, som hovedsakelig består av skanner sårbarhet og " script kiddie " angrep ved hjelp av falske IP-adresser. Forsvars - holder deg oppdatert med systemoppdateringer og hjelp SACLs - er mye mer fordelaktig da gjenkjenning. Den nyeste Network World IDS shootout funnet at den største ulempen med de fleste NIDS er systemsvikt på grunn av manglende evne til å behandle overdreven alarmer eller database låsing. Installere NIDS på en ufiltrert nettverket vil bare resultere i Nids krasjer og tonnevis av falske alarmer. Implementering SACLs kan nettverksadministratoren for å filtrere ut script kiddie skanner, kjente nettverksbaserte angrep, trojanske hester og andre ikke-støttet nettverk søknad om ønskelig. Slippe støy trafikk før den når NIDS forsvarer nettverket mot potensielle angrep og reduserer produksjonen av både falske og uløselig tilstand alarmer. Dette gjør at NIDS gjennomstrømming tilgjengelig for å overvåke for legitime angrep.

Vil bruken av SACLs påvirke rutere ytelse?
Rutere og brannmurer hente ut IP nyttelast fra lag 2 (L2) rammer fra en innkommende grensesnitt, prosess IP-pakken, og deretter kapsle IP pakke i L2 rammetypen av den utgående grensesnitt. Bruken av inngående SACLs på Cisco-rutere pålegger liten ytelsespåvirkning, siden trafikktilpasning er utført før pakken blir behandlet for videresending. IP-pakken trekkes ut, filtreres, og deretter bearbeidet for filtrering. Utgående SACLs brukes post-prosess, så bruken medfører ekstra pakkebehandling og bruker litt flere ruterressurser. Av denne grunn, er bruken av innkommende tilgangskontrollister foretrukket for pakkefiltrering operasjoner.

IOS tilgangslister
Før en SACL blir et instrument for å filtrere IP-trafikk, starter det som en vanlig tilgangsliste. IOS tilveiebringer et middel for å skape stripestrukturer for klassifisering L2 og L3 trafikk. Disse matriser blir så brukt av ulike IOS operasjoner for å identifisere trafikk som skal behandles av nevnte operasjon. Noen eksempler på disse operasjonene er distribusjonslister (som brukes til rute filtrering), rutekart (brukes med policy ruting), kryptokart (brukes for å påføre IPsec politikk) og tilgangsgrupper (som brukes til å implementere SACLs på ruteren grensesnitt). I tillegg til IP, støtter IOS tilgangslister for Appletalk, IPX, og Ethernet MAC. Hvert tilgangsliste typen har en tilhørende heltall rekkevidde. Når en administrator oppretter en tilgangsliste, må det bli tildelt en unik numerisk ID fra området i forbindelse med hver tilgangsliste type.

Merk:
For enkelhets skyld, vil vilkårene SACL og tilgangsliste være synonymt for påminnelse om denne artikkelen. Følgende retningslinjer knyttet til etableringen av SACLs gjelder for alle anvendelser av tilgangslister.

Implementering IOS SACLs
IP, Appletalk, L2 MAC, IPX - hvis IOS kan rute trafikken, IOS kan filtrere trafikken. Våre diskusjonen vil ta bare med TCP /IP SACLs som det finnes to varianter, " standard " og ". utvidet " Før vi diskutere forskjellene mellom dem, er det tre raske ting: Først, som jeg antydet ovenfor, er SACLs påføres grensesnitt som inngående (trafikk som strømmer inn i ruteren) eller utgående (trafikk strømmer ut av ruteren) filtre. SACLs tilordnes et grensesnitt med grensesnittkonfigurasjon Command < ip access-gruppen {nummer /navn} {inn /ut} >
. Hvis ingen filter punktet er definert, vil SACL bli brukt som en inngående filter (bare på IOS versjoner før 12.0).

For det andre, både standard og utvidede SACLs arbeide fra forskrift av " implisitt benekte alt, " noe som betyr at med mindre trafikk er eksplisitt tillatt, vil trafikken bli forkastet (som standard, dette er lagt til på slutten av hver SALC). For det tredje er SACLs behandlet fra toppen og ned. Imidlertid vil IOS endre rekkefølgen SACL oppføringer ved hjelp av en lav til høy nummerering når SACL er lastet inn i minnet i forhold til sin plassering. Dette skal ikke påvirke driften av SACL bortsett fra perspektivet til regelen behandling. En av de retningslinjer å huske på med SACLs er at du bør plassere de reglene som blir oftest anvendt på hodet av den SACL. Avhengig av hvilken type oppføring, spesielt filtrering regler mot vertene, kan noen omlegging forekomme uavhengig av rekkefølgen oppføringene er gjort.

Standard SACLs
Standard SACLs (S-SACLs) gir nettverksprotokollen (OSI-RM L3) kamp filtrering på en pakke kilde IP-adresse. Matching er behandlet fra toppen av listen; den første kampen bestemmer pakkehåndtering handling. Cisco bruker tall for å identifisere ulike typer SACLs. IP S-SACLs bruke nummeret varierer fra 1 til 99 og 1300 til 1999. To pakkehåndterings handlinger støttes: tillatelse (fremover) eller avslå (slippe inn i litt bøtte med fortvilelse). Kilden adressen definisjon støtter trafikk filter kvalifisering ved hjelp av en kombinasjon av nettverksklasse /maske, VSLM eller nettverks /maske, vertsadressen eller bare ren ". Noen " Når du oppretter nettverksadresse matchende uttalelser, er nettverksmasker inn med Ciscos omvendt maske " joker " notasjon. For eksempel, en klasse " C " nettverksmaske er skrevet som 0.0.0.255 istedenfor 255.255.255.0. Når du bruker classful adressering, er wildcard metoden ganske grei, men med VLSM det blir mer av en smerte. For å beregne wildcard maske, trekke fra nettverksadressemaske fra 255.255.255.255. Resultatet er wildcard maske. Her er en standard S-SACL -konfigurasjonssyntaksen:

< access-liste {id} {tillatelse /nekte} {host /src adr /enhver} {wildcard maske} {logge} > < .no>

Her er et eksempel standard SACL for filtrering av RFC-1918 prefikser:

access-list 10 bemerkning Nettverk og Loopback Adresser access-list 10 benekte verten 0.0.0.0 log access-list 10 nekte 0.0.0.0 0.255.255.255 log access-list 10 benekte 127.0.0.0 0.255.255.255 log access-list 10 bemerkning RFC-1918 Adresser access-list 10 benekte 10.0.0.0 0.255.255.255 log access-list 10 benekte 172.16.0.0 0,15 .255.255 log access-list 10 benekte 192.168.0.0 0.0.255.255 log access-list 10 bemerkning Multicast Class " D " adresserom access-list 10 benekte 224.0.0.0 31.255.255.255 log access-list 10 Generisk tillatelse all statement access-list 10 tillatelse noen

Utvidede SACLs Extended SACLs (E-SACL) gi nettverksprotokollen (OSI-RM L3 og OSI-RM L3) kamp filtrering på en pakke protokoll, kilde og destinasjon IP-adresse og portnummer (bare TCP /UDP). Som tilfellet er med S-SACLs, assosierer IOS spesifikk ID-nummer varierer med utvidede SACLs. ID range 100-199 er tilgjengelig i alle IOS implementasjoner som støtter utvidet SACLs, og spenner 2000 til 2699 er tilgjengelig på IOS versjon 12.x og senere. I tillegg til kilden og målet matchende støtte, kan E-SACLs matche på en rekke utvidede muligheter. Her er E-SACL -konfigurasjonssyntaksen:

< access-liste {id} {tillatelse /nekte} {protokoll} {host /src adr /enhver} {wildcard maske} {src port} { operatører [kvalifiseringer]} {host /dest adr /enhver} {wildcard maske} {dest port} {operatører [kvalifiseringer]} >

Mens de fleste av E-SACL kommandosyntaks er selv- forklarende, protokollen definisjon og de valgfrie ACL operatører krever noen videre diskusjon.

Med E-SACLs, er protokollen inngangsnøkkel. Det definerer pakketypen som blir filtrert. Oppføringen kan enten være et heltall (1-255) eller IP-protokollen søkeord. En liste over noen av de mer populære søkeordene er nedenfor, med sine IANA (Internet Assigned Numbers Authority) protokoll ID heltall. Verdien i filtrering av protokolltypen er graden av detalj det lar administratoren kontrollere flyten av trafikk til å være vert og subnett. Husk at når filtrering av protokollen, overstyrer IP ordet noen tilsvarende protokoll-spesifikke (dvs. TCP eller UDP) oppføring. Ved bruk av protokollspesifikke oppføringer må du huske å oppgi dem fra de mest spesifikke (dvs. TCP, ICMP, etc) til minst spesifikke (dvs. IP). Her er noen av de mer vanlige filtrerte protokoller:

IP Enhver protokoll i en IP-pakke TCP Bare TCP-pakker (Protocol ID 6) UDP Bare UDP-pakker (Protocol ID 17) ICMP Bare ICMP-pakker (Protocol ID 1) OSPF Bare OSPF pakker (Protocol ID 89) GRE Bare GRE pakker (Protocol ID 47) AH Bare IPsec /Authentication Header pakker (Protocol ID 51) ESF Bare IPSec /Encapsulation Nyttelast pakker (Protocol ID 50)

E- SaCl operatører varierer avhengig av protokollen definisjonen. Bellow er en kort liste over de mest brukte operatører, deres funksjon og tilgjengelighet av protokoll:

Operatør Funksjon Protocol tilgjengelighet eq Match på L4 portnummeret TCP /UDP gt Match på noen L4 portnummer høyere enn en definert TCP /UDP lt Match på noen L4 portnummer mindre enn en definert TCP /UDP utvalg Match på noen L4 portnummer innenfor definert område (lav til høy) TCP /UDP etablert Drop noen pakke med bare SYN flagget satt. Pakker med ACK eller RST vil bli akseptert TCP logge Logg kamper på denne oppføringen. Meldingene sendes til " forvarsel " logging anlegget. Loggen setningen kan brukes alene eller post-Holdte etter en annen operatør uttalelse. Alle protokoller log-inngangsfunksjoner som loggen operatør, men inkluderer input grensesnittet i rapporten. Alle protokoller

Det finnes en rekke andre aktører for IGMP og ICMP som ikke er nevnt ovenfor. For å finne ut mer, bruker IOS kommandolinje hjelp. Her er et eksempel E-SACL for filtrering av RFC-1918 prefikser:

access-list 101 bemerkning Nettverk og Loopback Adresser aksess-liste 101 nekte ip vert 0.0.0.0 noen log aksess-liste 101 nekte ip 0.0.0.0 0.255.255.255 de logg aksess-liste 101 nekte ip 127.0.0.0 0.255.255.255 de logg aksess-liste 101 bemerkning RFC-1918 Adresser aksess-liste 101 nekte ip 10.0.0.0 0.255.255.255 de logg aksess-liste 101 nekte ip 172,16. 0.0 0.15.255.255 de logg aksess-liste 101 nekte ip 192.168.0.0 0.0.255.255 de logg aksess-liste 101 bemerkning Multicast Class " D " adresserom access-liste 101 nekte ip 224.0.0.0 31.255.255.255 de logg aksess-liste 101 bemerkning Generic tillatelse all statement aksess-liste 101 tillatelse ip alle alle

Før vi går videre til navngitte SACLs, det er en mer bemerkelsesverdige ting om S-SACLs og E-SACLs - du kan ikke redigere dem. Du kan legge til dem, men du kan ikke fjerne en oppføring. Når du legger til en oppføring, er det satt i stein og post-Holdte til slutten av listen. Hvis du prøver å slette en oppføring hele listen vil bli slettet.

Hva dette betyr er at du bør lage SACLs som ASCII tekstfiler og laste dem ved hjelp av < kopiere tftp innkjørings konfigurasjon >
kommando. Du vil finne at dette er den beste måten å laste opp noen SACL som må redigeres med noen regularitet eller har mer enn noen få oppføringer. Det er også en god idé å lagre kopier av dine gamle listene slik at du enkelt kan gå tilbake hvis det er et problem.

Oppkalt SACLs
De to største problemene med S-SACLs og E-SACLs er å identifisere dem og redigere dem. Navngitte SACLs (N-SACL) løse disse to problemene. Navngitte SACLs ble introdusert i IOS versjon 11.2.

N-SACLs tillate bruk av et menneskelig navn som en referanse i stedet for et tall. Navnet kan være opptil 100 ASCII-tegn. En N-SACL kan anvendes i IOS sammenheng som et nummerert SACL kan anvendes. Når den brukes til å filtrere trafikk på en router grensesnitt, grensesnittet underkommando < ip access-gruppen {inn | ut} > til
brukes gjelde en SACL til grensesnittet. Funksjonelt, N-SACLs er de samme som S-SACLs og E-SACLs. Deres konfigurasjonen er annerledes, ved hjelp av en nestet struktur som ligner på en ruting policy statement. Konfigurasjonen syntaks for å opprette en navngitt standard eller utvidet SACL er følgende:

< ip access-list {standard | utvidet} [ASCII navn] >

Når listen er opprettet, er du droppet inn i en underkommando konfigurasjon sammenheng. Kommandosyntaksen paralleller de som er tilgjengelige for å lage S-SACLs eller E-SACLs, avhengig av hvilken type liste som opprettes standard eller utvidet. Når oppføringene er gjort, < exit >
underkommando deg tilbake til hovedkonfigurasjonsteksten. For å gjøre ytterligere endringer, bruker samme N-SACL konfigurasjon uttalelse, og du vil bli returnert til N-SACL underkommandogrensesnittet.

Den store fordelen med å bruke N-SACLs er at de kan redigeres. Det betyr at filterreglene kan fjernes forlate listen og bestiller intakt. Men vent! Alt er ikke alt er rosenrødt i SACL hagen. I likhet med sine tall brødre, er selektive tillegg støttes ikke av N-SACLs. Alle nye oppføringer blir etterHoldte til slutten av listen, som krever listen som skal slettes og lastes om endringer eller nye oppføringer i matchende rekkefølge må gjøres ved hjelp av TFTP. Men listen er godt tenkt ut, kan endringer være skriptede fordi valgt uttalelse fjerning støttes (vi vil ta dette opp senere i denne serien). Her er et eksempel N-SACL for filtrering av RFC-1918 prefikser:

ip access-list utvidet RFC1918-IN bemerkning Nettverk og Loopback Adresser nekte ip vert 0.0.0.0 noen log nekte ip 0.0.0.0 0.255.255.255 noen log nekte ip 127.0.0.0 0.255.255.255 noen logg bemerkning RFC-1918 adresser nekte ip 10.0.0.0 0.255.255.255 noen logg nekte ip 172.16.0.0 0.15.255.255 de logg nekte ip 192.168.0.0 0.0.255.255 de logg bemerkning Multicast Class " D " adresserom nekte ip 224.0.0.0 31.255.255.255 noen logge bemerkning Generic tillatelse alle utsagn Tillatelsen ip alle alle

Konklusjon
Det denne artikkelen har vi sett på å implementere numeriske og oppkalt SACLs. Neste måned vil vi gjennomgå noen tips for å skape SACLs og ta en titt på hva du bør faktisk være filtrering på Internett gateway. Så følg med.

Postscript
Mens den felles nomenklatur " Access Control List " (ACL) har vært brukt i mange år for å referere til ruter filtre, har videreutviklinger i IOS evne og utviklingen i operativsystemer og filtreringsteknologier generelt skapt et behov for mer spesifikke eller beskrivende definisjoner. Begrepene " statiske " og " dynamisk " ACL-brukes for å diskriminere mellom de metoder for å kontrollere tilgang til nettverket. Statiske ACL er " statisk " regler som filtrerer trafikk. Nettverk og verts uttalelser som tillater tilgang er alltid åpne. Dynamisk ACL åpen kvalifisert tilgang kun for en begrenset periode og spore delstaten kommunikasjon utveksling. Når man diskuterer Network Access Control, definerer metode for kontroll er kritisk ved beskrivelse av sikkerhetsløsning.

Var denne artikkelen nyttig for deg? Har du forslag til temaer du ønsker å få behandlet? Send en e-post og gi oss beskjed!