Controlul accesului bazat pe context ofera o filtrare avansata a traficului pe retea si poate fi folosit ca parte integrala a sistemului de securitate al unei retele de calculatoare -; “firewall”. Pentru a putea vorbi despre aceasta caracteristica a sistemului de securitate va trebui sa facem cateva referinte si la Sistemul Firewall (Cisco Firewall Feature Set (FFS) ) de protectie a retelelor din care face parte incepand cu versiunea 11.3 IOS a FFS. Desi este doar o parte din acest sistem de protectie , Controlul Accesului Bazat pe Context constituie unul dintre cele mai importante aspecte, un pachet elementar de elemente de siguranta care protejeaza si mentine securitatea interna a unei retele de calculatoare. l4i18ic
Sistemul Firewall este construit pentru a preveni accesul indivizilor neautorizati la retea si pentru a bloca eventualele atacuri asupra retelei , oferind in acelasi timp insa accesul personalului autorizat la resursele retelei.
De asemenea folosirea acestui sistem de protectie ofera si anumite avantaje printre care : protejarea retelelelor interne de accesul unor intrusi, monitorizarea traficului intre perimetrul retelelor, activarea accesului retelei la Web.
Sistemul Firewall poate fi folosit pentru configurarea unui ruter astfel:
- ca firewall intern sau parte a unui firewall intern;
- ca firewall intre grupuri din reteaua interna;
- ca firewall asigurand conexiuni sigure spre sau de la sucursale;
- ca firewall intre reteaua companiei proprii si retelele companiilor partenere;
Pentru a crea un firewall menit sa indeplineasca cerintele politicii de securitate a retelei trebuiesc determinate mai intai caracteristicile FFS cele mai apropiate si mai potrivite si trebuiesc apoi configurate corespunzator. Bineinteles ca puteti opta pentru un minim de securitate configurand caracteristicile FFS sa functioneze pentru o protectie minima a firewall-ului.
Setul de caracteristici FFS cuprinde urmatoarele :
- filtrare de baza si avansata a traficului (Basic and Advanced Traffic Filtering);
- suportul de securitate al serverului (Security Server Support );
- traducerea adreselor retelei (Network Address Translation);
- tehnologia de encriptare Cisco (Cisco Encryption Technology);
- securitatea IPSec a retelei (IPSec Network Security);
- autenticitatea ruter-ului vecin (Neighbor Router Authentication);
- monitorizarea loggin-ului (Event Logging);
Dintre aceste caracteristici pe noi ne intereseaza doar prima dintre ele, filtrarea de baza si avansata a traficului (Basic and Advanced Traffic Filtering), si mai exact filtrarea avansata (Advanced Traffic Filtering), in cadrul careia intra si Controlul Accesului Bazat pe Context. Despre celelalte caracteristici putem gasi informatii in diverse documentatii legate de securitatea retelelor.
In cadrul filtrarii de baza intra Listele de Acces Standard (Standard Acces Lists) si Listele de Acces Extinse Statice (Static Extended Acces Lists).
Filtrarea avansata cuprinde Liste de Acces Dinamice ( Lock-and-Key (Dynamic Access Lists) ) si Controlul Accesului Bazat pe Context (Context Based Acces Control).
Ca o descriere generala Controlul Accesului Bazat pe Context examineaza nu numai straturile retelei si transportul lor, dar si informatiile referitoare la protocoalele straturilor (cum ar fi informatii FTP) pentru a analiza starea conexiunilor TCP si UDP. Controlul Accesului Bazat pe Context mentine informatiile de stare ale conexiunii pentru conexiuni individuale. Aceste informatii de stare sunt utile in luarea unor decizii inteligente cu privire la traficul pachetelor. De asemenea aceste informatii de stare creeaza si sterg in mod dinamic, activ ’’ferestre’’ in firewall.

De aici inainte vom incepe descrierea amanuntita a Controlului Accesului Bazat pe Context sectiune ce va cuprinde mai multe parti:
1. Ce face CBAC
2. Ce nu face CBAC
3. Platforme
4. Cum functioneaza CBAC a) generalitati b) detalii
5. Cand si unde se configureaza CBAC
6. Procesul CBAC
7. Protocoale suportate
8. Restrictii
9. Impactul asupra performantei si memoriei sistemului

1. Ce face Controlul Accesului Bazat pe Context (CBAC) aTopi

Controlul Accesului Bazat pe Context filtreaza inteligent pachetele TCP si UDP pe baza unei informatii in legatura cu sesiunea de protocoale stratificate (application-layer protocol session information) si poate fi folosit pentru retele locale, retele externe si internet. Configurarea CBAC poate permite traficul pachetelor TCP si UDP prin firewall doar atunci cand conexiunea se face din interiorul retelei ce trebuie protejata. Cu alte cuvinte CBAC poate controla traficul sesiunilor ce provin dintr-o retea externa. In orice caz CBAC este capabil de a controla traficul atat de-o parte cat si de cealalta a unui firewall.
Fara CBAC filtrul traficului este limitat la implementarile listelor de acces care examineaza pachetele la nivelul stratului, sau cel mult, stratul de transport. CBAC insa examineaza nu numai straturile retelei si informatiile referitoare la transportul lor, dar si informatiile referitoare la protocoalele straturilor (cum ar fi informatii FTP) pentru analizarea starii sesiunilor TCP si UDP. Acest lucru permite suportul protocoalelor care implica crearea canalelor multiple ca rezultat al negocierilor pe controlul canalului. Majoritatea protocoalelor multimedia la fel ca si alte protocoale (FTP, RPC, SQL*Net) implica mai multe canale.
CBAC inspecteaza traficul ce trece prin firewall pentru a descoperi si controla informatii de stare pentru sesiunile TCP si UDP. Aceste informatii de stare sunt folosite pentru a crea ’’ferestre’’ temporare in listele de acces ale firewall-ului cu scopul de a permite ’’intoarcerea’’ traficului si conexiunilor de date alternative pentru sesiunile permise (sesiuni care provin din interiorul retelei protejate).
CBAC mai ofera si urmatoarele avantaje :
• blocajul java (Java blocking)
• respringerea serviciului de prevenire si detectare (Denial-of-Service prevention and detection )
• alerte in timp real si revizuirea pistelor (Real-time alerts and audit trails )

2. Ce nu face Controlul Accesului Bazat pe Context (CBAC) aTopi

CBAC nu ofera filtrare inteligenta pentru toate protocoalele; el functioneaza doar pentru protocoalele care sunt specificate. Daca un anumit protocol nu este specificat lista de acces deja existenta va determina in ce mod va fi filtrat acel protocol. Nu vor fi create nici un fel de „ferestre” pentru protocoalele nespecificate pentru CBAC.
CBAC nu este o sursa de protectie pentru atacurile provenite din interiorul retelei protejate. CBAC protejeaza reteaua doar de atacurile care circula prin firewall.
CBAC protejeaza reteaua impotriva unor atacuri dar nu trebuie considerat o defensiva perfecta si impenetrabila. Cei ce sunt bine pregatiti pot sa lanseze atacuri care au surse de izbanda. Atata timp cat nu exista ceva de genul „protectie perfecta” CBAC detecteaza si protejeaza majoritatea atacurilor adresate retelei.

3. Platforme aTopi

Caracteristica CBAC a sistemului Firewall este suportata pe urmatoarele platforme :

? Seria Cisco 1600

? Seria Cisco 2500

4. Cum functioneaza Controlul Accesului Bazat pe Context (CBAC) aTopi

Inainte de a configura Controlul Accesului Bazat pe Context ar trebui inteleasa foarte bine aceasta parte a studiului acestei caracteristici. Daca functionarea Controlului Accesului Bazat pe Context nu este bine inteleasa atunci s-ar putea ca atunci cand se configureaza sa apara erori neprevazute ce vor duce la instabilitate si riscuri. a) generalitati aTopi

CBAC creeaza „ferestre” temporare in listele de acces ale interfetelor firewall-ului. Aceste „ferestre” sunt create atunci cand traficul cunoscut paraseste reteaua interna prin firewall. „Ferestrele” permit intoarcerea traficului (care in mod normal ar fi fost blocat) si a canalelor suplimentare de date in reteaua interna prin intermediul firewall-ului. Traficului ii este permis sa patrunda inapoi in retea numai daca face parte din aceeasi sesiune ca si traficul initial care a declansat CBAC atunci cand a trecut de firewall.
In Figura 1 listele de acces „legate” la S0 si S1 sunt configurate sa blocheze traficul Telnet, si nu exista nici o lista de acces cu destinatie indepartata configurata la E0. Cand solicitarea conexiunii pentru sesiunea Telnet a User-ului 1 trece prin firewall, CBAC creeaza o „fereastra” temporara in listele de acces „legate” la S0 pentru a permite intoarcerea traficului Telnet pentru sesiunea Telnet a User-ului 1. (Daca aceeeasi lista de acces este aplicata si lui S0 si lui S1 atunci aceeasi fereastra va apare la ambele interfete.). Daca ar fi fost necesar CBAC ar fi creat o „fereastra” similara intr-o lista de acces cu destinatie indepartata la E0 permitand intoarcerea traficului.

Figura 1: CBAC creeaza „ferestre” temporare de acces in listele de acces ale firewall-ului

b) detalii aTopi

Aceasta sectiune descrie modul in care CBAC inspecteaza pachetele si pastreaza informatii de stare despre sesiuni pentru a oferi un trafic inteligent.
Verificarea pachetelor

Folosind CBAC se specifica care protocoale sunt verificate si este specificata o interfata si o directie a interfetei respective (interior sau exterior) de unde provine verificarea initiala. Numai protocoalele specificate vor fi verificate de CBAC. Pentru aceste protocoale, pachetele ce circula prin firewall in orice directie sunt verificate, atata timp cat ele circula prin interfata unde este configurata verificarea.
Pachetele ce patrund prin firewall sunt verificate de CBAC doar daca ele au trecut initial prin listele de acces „legate” din interfata. Daca un pachet nu este acceptat de lista de acces atunci el este pur si simplu abandonat si nu mai este inspectat de CBAC.
CBAC verifica si monitorizeaza numai canalele de control ale conexiunilor; canalele de date nu sunt verificate. De exemplu in timpul unei sesiuni FTP atat canalele de control cat si canalele de date (care sunt create atunci cand un fisier de date este transferat) sunt monitorizate in vederea aparitiilor unor modificari, dar numai canalul de control este verificat (asta datorita faptului ca CBAC analizeaza comenzile si raspunsurile FTP).
Verificarea CBAC conduce la recunoasterea comenzilor specifice aplicatiilor din canalul de control, cat si la detectarea si prevenirea anumitor atacuri la nivelul aplicatiilor.

Un tabel de stare pastreaza informatii de stare despre sesiune

De fiecare data cand un pachet este verificat un tabel de stare este reinoit cu informatii despre starea conexiunii pachetului.
Intorcerea traficului prin firewall va fi permisa numai daca tabelul de stare contine informatii indicand faptul ca pachetul apartine unei sesiuni ce este permisa. Verificarea controleaza traficul care apartine unei sesiuni ce este permisa si sare peste traficul necunoscut. Atunci cand traficul ce se intoarce prin firewall este verificat tabelul de stare este reinoit cu ultimele informatii.

Aproximarea „sesiunilor” UDP

La UDP -; un serviciu fara conexiune -; nu exista practic sesiuni actuale, deci soft-ul aproximeaza sesiunile examinand informatiile din pachet si determinand daca pachetul este asemanator cu alte pachete UDP (spre exemplu adrese sursa/destinatie asemanatoare si numere de port), si daca pachetul a fost detectat la scurt timp dupa detectarea altor pachete UDP. „La scurt timp” inseamna in timpul perioadei de configurare a timpului de latenta UDP (configurable UDP idle timeout period).

Intrarile listelor de acces sunt create si sterse in mod dinamic pentru a permite intoarcerea traficului si a conexiunilor de date aditionale

CBAC creeaza si sterge in mod dinamic intrarile listelor de acces de la interfetele firewall-ului in functie de informatiile pastrate in tabelul de stare. Aceste intrari ale listelor de acces sunt aplicate interfetelor in vederea examinarii circulatiei traficului inapoi in reteaua interna. Ele creeaza „ferestre” temporare in firewall pentru a permite numai circulatia traficului care face parte dintr-o sesiune ce este permisa.
Intrarile temporare ale listelor de acces nu sunt salvate niciodata in memoria NVRAM.

5. Cand si unde se configureaza CBAC aTopi

Configurarea CBAC la nivelul firewall-ului protejeaza retelele interne. Astfel de firewall-uri ar trebui sa fie rutere CISCO cu setul de caracteristici configurat corespunzator.
CBAC trebuie folosit atunci cand firewall-ul este strabatut de trafic cum ar fi :

? aplicatii internet standard TCP si UDP

? aplicatii multimedia

? suport Oracle

CBAC ar trebui folosit pentru aceste aplicatii daca se vrea ca traficul acestor aplicatii sa treaca prin firewall numai in cazul in care sesiunea de trafic este initiata dintr-o anumita parte a firewall-ului (de obicei din reteaua interna protejata).
In cele mai multe cazuri CBAC va fi configurat numai intr-o singura directie la o singura interfata, ce duce la circulatia traficului inapoi in reteaua interna numai in cazul in care el face parte dintr-o sesiune ce este permisa.
Exista si cazuri mai rare cand se doreste configurarea CBAC in doua directii pentru o interfata sau mai multe, dar aceasta este o solutie mult mai complexa. CBAC este configurat in doua directii atunci cand se doreste protejarea retelei de ambele parti ale firewall-ului ca in cazul configuratiilor intranet sau extranet. Spre exemplu daca firewall-ul este situat intre doua retele ale unor companii partenere, s-ar dori restrictionarea traficului pentru anumite aplicatii intr-o directie, si pentru alte aplicatii in alta directie.

6. Procesul CBAC aTopi

Aceasta sectiune descrie o secventa simpla de evenimente ce au loc atunci cand CBAC este configurat la o interfata externa ce se conecteaza la o retea externa asa cum este Internetul.
In acest exemplu un pachet TCP paraseste reteaua interna prin interfata externa a firewall-ului. Pachetul TCP este primul pachet dintr-o sesiune Telnet, iar Telnet este configurat pentru verificarea CBAC.

1. Pachetul ajunge la interfata externa a firewall-ului.

2. Pachetul este evaluat in ciuda interfetei existente a listei de acces cu destinatie andepartata si este acceptat. (Un pachet neacceptat este pur si simplu abandonat in acest moment).

3. Pachetul este verificat de CBAC pentru a determina si inregistra informatii referitoare la starea conexiunii pachetului. Aceste informatii sunt inregistrate in noul tabel de stare creat pentru noua conexiune. (Daca aplicatia pachetului -; Telnet -; nu este configurata pentru verificarea CBAC pachetul va fi pur si simplu trimis mai departe afara din interfata la acest moment fara a mai fi verificat de CBAC.)

4. Pe baza informatiilor de stare obtinute, CBAC creeaza o intrare in lista de acces care este introdusa la inceputul interfetei externe a listelor de acces „legate” extinse. Aceasta intrare temporara in lista de acces are scopul de a permite traficul pachetelor interne care fac parte din aceeasi sesiune ca si pachetul verificat.

5. Pachetul extern este trimis mai departe afara din interfata.

6. Peste un anumit timp un pachet intern ajunge la interfata. Acest pachet face parte din aceeasi conexiune Telnet stabilita anterior odata cu pachetul extern. Pachetul intern este evaluat netinandu-se cont de existenta listei de acces interne si este acceptat datorita intrarii in lista de acces creata anterior.

7. Pachetul intern acceptat este verificat de CBAC si intrarea tabelului de stare este innoita conform noilor informatii. Pe baza acestor noi informatii intrarile in lista de acces extinsa „legata” pot fi modificate pentru a permite numai traficul pachetelor care sunt valabile pentru starea curenta a conexiunii.

8. Orice alte pachete interne sau externe care apartin conexiunii sunt verificate pentru reinnoirea tabelului de stare si pentru modificarea corespunzatoare a intrarilor temporare din lista de acces „legata” si sunt trimise mai departe prin interfata.

9. Cand conexiunea se incheie sau are time-out tabelul de stare este sters la fel ca si conexiunile intrarilor temporare din lista de acces „legata”.

In procesul descris mai sus listele de acces ale firewall-ului sunt configurate dupa cum urmeaza :

? O lista de acces IP cu destinatie indepartata (simpla sau extinsa) este aplicata interfetei externe. Aceasta lista de acces permite iesirea oricarui pachet dorit din retea inclusiv pachetele ce trebuiesc verificate de CBAC. In acest caz pachetele Telnet sunt acceptate.

? O lista de acces „legata” este aplicata interfetei externe. Aceasta lista de acces nu permite nici un fel de verificare CBAC a traficului - inclusiv a pachetelor Telnet. Atunci cand CBAC este declansat odata cu aparitia unui pachet extern el creeaza o „fereastra” temporara in lista de acces „legata” pentru a permite numai traficul ce face parte dintr-o sesiune ce este permisa. Daca lista de acces „legata” a fost configurata sa permita traficul de orice fel, CBAC ar crea „ferestre” de acces inutile pentru pachetele ce ar fi oricum acceptate.

7. Protocoale suportate aTopi

CBAC poate fi configurat pentru a verifica urmatoarele tipuri de sesiuni :

? Toate sesiunile TCP, referitoare la protocolul straturilor aplicatiilor (numit uneori verificare UDP „single-channel” sau „generic”)

? Toate sesiunile UDP, referitoare la protocolul straturilor aplicatiilor (numit uneori verificare TCP „single-channel” sau „generic”)

CBAC poate fi configurat sa verifice numai anumite protocoale ale straturilor de aplicatii. Urmatoarele protocoale ale straturilor de aplicatii pot fi de asemenea configurate pentru CBAC :

? Cu-SeeMe (numai versiunea White Pine)

? FTP

? H.323 (cum ar fi NetMeeting, ProShare)

? Java

? UNIX R-commands (cum ar fi r-login, r-exec, r-sh)

? RealAudio

? RPC (Sun RPC si nu DCE RPC sau Microsoft RPC)

? SMTP

? SQL*Net

? StreamWorks

? TFTP

? VDOLive

Cand un protocol este configurat pentru CBAC traficul acestui protocol va fi verificat, informatiile de stare vor ramane si, in general, pachetele vor fi acceptate inapoi prin firewall numai daca apartin unei sesiuni ce este permisa.

8. Restrictii aTopi

CBAC este disponibil numai pentru traficul protocoalelor IP. Numai pachetele TCP si UDP sunt verificate. (Alt tip de trafic, cum ar fi ICMP, nu poate fi filtrat de CBAC si ar trebui filtrat cu listele de acces de baza).
CBAC poate fi folosit impreuna cu celelalte caracteristici ale firewall-ului mentionate mai devreme. CBAC functioneaza cu „fast switching” si „process switching”.
Daca se face o reconfigurare a listelor de acces atunci cand se configureaza CBAC se cere multa atentie pentru ca daca listele de acces blocheaza traficul TFTP printr-o interfata nu se va putea face bootare de pe acea interfata. (Aceasta nu este o limitare specifica CBAC dar face parte din existenta functionalitatii listelor de acces).
CBAC ignora mesajele ICMP care nu mai prezinta conexiune.

* Traficul FTP si CBAC

Referindu-ne la FTP, CBAC nu permite conexiuni „third-party” (transfer FTP „three-way”). Atunci cand CBAC verifica traficul FTP nu permite decat canalele de date cu portul destinatie ce ia valori cuprinse intre 1024 si 65535. CBAC nu va deschide un canal de date daca autenticitatea FTP client-server nu corespunde.

* Tehnologia de codificare CISCO si compatibilitatea CBAC

Daca se efectueaza trafic codat intre doua rutere, iar firewall-ul se gaseste intre cele doua rutere, CBAC poate sa nu functioneze asa cum ar trebui. Acest lucru se intampla deoarece sarcinile pachetelor sunt codate, deci CBAC nu poate face o verificare corecta a sarcinilor.
De asemenea daca atat codificarea cat si CBAC sunt configurate pe acelasi firewall , CBAC poate sa nu functioneze pentru anumite protocoale. In acest caz CBAC va functiona pe canale monovalente (single-channels) TCP si UDP, cu exceptiile Java si SMTP. Dar CBAC nu va functiona pentru protocoale cu canale plurivalente (multichannels), cu exceptiile StreamWorks si CU-SeeMe. Deci la o configurare a codificarii la nivelul firewall-ului va trebui facuta o configurare a CBAC pentru urmatoarele protocoale :

? Generic TCP

? Generic UDP

? CU-SeeMe

? StreamWorks

* Compatibilitatea IPSEC si CBAC

Daca CBAC si IPSEC sunt actionate pe acelasi ruter si ruterul tinta este nod final pentru traficul IPSEC, atunci IPSEC este compatibil cu CBAC (acest lucru este posibil deoarece CBAC poate efectua verificarea normala pe acest trafic).
Daca ruterul nu este nod final pentru traficul IPSEC, dar pachetele sunt pachete IPSEC atunci CBAC nu va verifica pachetele deoarece numarul protocolului din header-ul IP al pachetului IPSEC nu este TCP sau UDP. CBAC verifica numai pachetele TCP si UDP.

9. Impactul asupra performantei si memoriei sistemului aTopi

Folosirea CBAC necesita mai putin de 600 bytes pentru fiecare conexiune. Din acest motiv folosirea CBAC ar trebui sa se faca numai atunci cand prezenta lui este absolut necesara. De asemenea exista si o mica folosire a procesorului la fiecare verificare a pachetelor.
Uneori CBAC trebuie sa verifice liste de acces destul de lungi, ceea ce duce la un impact negativ asupra performantei sistemului. Totusi acest impact este evitat deoarece CBAC verifica listele de acces folosind o metoda de accelerare (CBAC imparte listele de acces si verifica fiecare din partile rezultate din aceasta impartire).

Configurarea Controlului accesului bazat pe context

Daca nu se cunoaste exact ce face si cum functioneaza CBAC s-ar putea sa existe unele configurari inadecvate ce vor afecta firewall-ul. Configurarea CBAC fara o intelegere exacta a ceea ce face si cum functioneaza nu este recomandata.

Pentru configurarea CBAC este necesara parcurgerea urmatoarelor etape :

1. Alegerea unei interfete (interna sau externa)
2. Configurarea listelor de acces la interfata
3. Configurarea „timeout-urilor” globale si a pragurilor de sensibilitate
4. Definirea unei reguli de verificare
5. Aplicare regulii de verificare unei interfete

De asemenea se mai pot parcurge si urmatoarele doua etape :

6. Configurarile de „display” , informatiile de stare si statisticile pentru CBAC
7. „Debug-ul” CBAC

1. Alegerea unei interfete (interna sau externa) aTopi

Inainte de toate trebuie luata decizia configurarii CBAC ori pe o interfata interna ori pe una externa a firewall-ului.
„Interna” se refera la partea de unde pornesc sesiunile pentru ca traficul sa fie lasat sa treaca prin firewall.
„Externa” se refera la partea de unde sesiunile nu mai pot porni (aceste sesiuni vor fi blocate).
Daca configurarea CBAC se va face in doua directii se va incepe prima oara cu configurarea CBAC intr-o singura directie, folosind denumirile cele mai apropiate pentru interfetele „interne” sau „externe”. Cand se face configurarea CBAC in cealalta directie denumirile interfetelor vor fi schimbate. (CBAC este rareori configurat in doua directii si de obicei atunci cand firewall-ul se afla intre doua retele ce trebuie protejate una de cealalta cum ar fi doua retele a unor firme partenere).
Firewall-ul este folosit in cele mai multe cazuri cu una dintre cele doua topologii ale retelelor. Determinand care dintre aceste doua topologii este cea mai in masura sa ajute se va determina daca CBAC va fi configurat pentru o interfata interna sau pentru una externa.

Prima topologie este prezentata in Figura 2. In aceasta simpla topologie CABC este configurat pentru interfata externa Serial 1. Acest lucru previne traficul de protocoale ce intra in firewall si in reteaua interna, exceptie facand cazurile cand traficul provine dintr-o sesiune initiata din reteaua interna.

Figura 2: Topologie Simpla

(CBAC configurat la interfata externa)
Cea de-a doua tolpologie este prezentata in Figura 3. In aceasta topologie CBAC este configurat pentru interfata interna Ethernet 0. Acest lucru permite traficului sa acceseze serviciile din „Zona Demilitarizata” (DMZ), cum ar fi serviciile DNS, dar previne patrunderea unui anumit trafic de protocol in reteaua interna, cu exceptia cazului in care traficul provine dintr-o sesiune initiata din reteaua interna.

Figura 3: Topologia DMZ

(CBAC configurat la interfata externa)

Folosind aceste doua topologii se va decide daca CBAC va fi configurat pentru o interfata interna sau pentru o interfata externa.

2. Configurarea listelor de acces la interfata aTopi

Pentru o functionare adecvata a CBAC trebuie verificat daca configurarea listelor de acces la nivelul interfetei este corecta.
Pentru acest lucru trebuie urmarite urmatoarele reguli generale pentru evaluarea listelor de acces IP la nivelul firewall-ului :

? Permiterea traficului CBAC de a parasi firewall-ul

Toate listele de acces care evalueaza traficul ce paraseste reteaua protejata ar trebui sa permita traficul ce va fi verificat de CBAC. De exemplu, daca Telnet va fi verificat de CBAC, atunci traficul Telnet ar trebui sa fie permis de toate listele de acces ce se aplica traficului ce paraseste reteaua interna.

? Folosirea listelor de acces extinse pentru a interzice CBAC intoarcerea traficului ce intra in reteaua interna prin firewall.

Pentru creearea „ferestrelor” temporare in listele de acces, acestea ar trebui sa fie liste de acces extinse. Deci indiferent daca avem de-a face cu liste de acces ce vor fi aplicate traficului de intoarcere sau daca nu avem de-a face cu astfel de liste de acces, se va face uz de listele de acces extinse. Listele de acces extinse ar trebui sa interzica traficul de intoarcere CBAC deoarece CBAC va crea „ferestre” temporare in listele de acces. (Se doreste blocarea in general a traficului atunci cand acesta intra in retea).

OBS. Daca firewall-ul are numai doua conexiuni, una la reteaua interna si cealalta la reteaua externa, folosirea tuturor listelor de acces „legate” e foarte utila deoarece se opreste pachetele inainte ca ele sa poata afecta ruterul.

Interfata externa

Iata cateva indicatii despre listele de acces cand se va face configurarea CBAC pentru interfata externa.

? Daca la nivelul interfetei externe se gaseste o lista de acces cu destinatie indepartata, aceasta lista de acces poate fi o lista de acces standard sau o lista de acces extinsa. Aceasta lista de acces cu destinatie indepartata ar trebui sa permita traficul pe care CBAC ar trebui sa-l verifice. Daca traficul nu este permis atunci el nu poate fi verificat de CBAC si pur si simplu se va renunta la el.

? Lista IP de acces „legata” de la nivelul interfetei externe ar trebui sa fie o lista de acces extinsa. Aceasta lista de acces ar trebui sa interzica traficul ce ar trebui verificat de CBAC. (CBAC va crea „ferestre” temporare in aceasta lista de acces cat mai potrivite pentru a permite numai intoarcerea traficului care provine dintr-o sesiune ce este permisa, valida).

Interfata interna

Iata cateva indicatii despre listele de acces cand se va face configurarea CBAC pentru interfata interna.

? Daca la nivelul interfetei interne se gaseste o lista IP de acces „legata” sau daca la nivelul interfetei(lor) externe se gaseste o lista IP de acces cu destinatie indepartata, aceste liste de acces pot fi fie liste de acces standard fie liste de acces extinse. Aceste liste de acces ar trebui sa permita traficul ce trebuie inspectat de CBAC. Daca traficul nu este permis atunci el nu va fi verificat de CBAC ci pur si simpu se va renunta la el.

? Lista IP de acces cu destinatie indepartata de la nivelul interfetei interne si lista IP de acces „legata” de la nivelul interfetei externe ar trebui sa fie liste de acces extinse. Aceste liste de acces cu destinatie indepartata ar trebui sa interzica traficul ce ar trebui verificat de CBAC. (CBAC va crea „ferestre” temporare in aceste liste de acces cat mai potrivite pentru a permite numai traficul ce face parte dintr-o sesiune ce este permisa.) Nu este necesara o configurare a listelor de acces extinse atat la nivelul interfetei interne „legate” cat si la nivelul interfetei externe cu destinatie indepartata, dar este necesara cel putin una dintre cele doua pentru restrictionarea circulatiei traficului prin firewall in reteaua interna protejata.

3. Configurarea „timeout-urilor”globale si a pragurilor de sensibilitate aTopi

CBAC foloseste „timeout-urile” si pragurile de sensibilitate pentru a determina cat timp va controla informatiile de stare pentru o anumita sesiune si pentru a determina cand sa renunte la sesiunile care nu devin in intregime stabilite. Aceste „timeout-uri” si praguri de sensibilitate se aplica in general tuturor sesiunilor.

Se pot folosi valorile de baza ale „timeout-urilor” si pragurilor de sensibilitate sau se pot schimba aceste valori in functie de necesitatile securitatii atribuite. Nu ar trebui sa faceti modificari ale valorilor „timeout-urilor” sau pragurilor de sensibilitate inainte de a continua cu configurarea CBAC. Daca se vrea activarea sistemul de prevenire mult mai agresiv „TCP host-specific denial-of-service” care contine si blocarea initierii unei conexiunii la un „host” trebuie setat „block-time-ul” specificat in comanda „ip inspect tcp max-incomplete host”. (din cadrul tebelului de mai jos).
Toate „timeout-urile” si pragurile de sensibilitate CBAC sunt prezentate in tabelul de mai jos impreuna cu comanda specifica si valoarea de baza (default value).

Valoarea „timeout-ului” sau pragului de sensibilitate ce poate fi modificata Comanda Valoarea de baza
Durata de timp in care soft-ul asteapta ca o sesiune TCP sa ajunga la starea stabilita inainte de a fi abandonata. ip inspect tcp synwait-time secunde 30 secunde
Durata de timp in care o sesiune TCP va fi inca analizata dupa ce firewall-ul a detectat un schimb FIN (FIN-exchange). ip inspect tcp finwait-time secunde 5 secunde
Durata de timp in care o sesiune TCP inca va fi analizata dupa nivel de activitate 0 (TCP idle timeout). 1 ip inspect tcp idle-time secunde 3600 secunde (1 ora)
Durata de timp in care o sesiune UDP va fi inca analizata dupa nivel de activitate 0(UDP idle timeout) .1 ip inspect udp idle-time secunde 30 secunde
Durata de timp in care o sesiune de cautare a numelui DNS (DNS name lookup session )va fi inca analizata dupa nivel de activitate 0. ip inspect dns-timeout secunde 5 secunde
Numarul de sesiuni semi-deschise existente care vor duce la startul stergerii sesiunilor semi-deschise. 2 ip inspect max-incomplete high numar 500 sesiuni semi-deschise existente
Numarul de sesiuni semi-deschise care vor duce la stoparea stergerii sesiunilor semi-deschise. 2 ip inspect max-incomplete low numar 400 sesiuni semi-deschise existente
Rata de sesiuni nou stabilite care vor duce la startul stergerii sesiunilor semi-deschise. 2 ip inspect one-minute high numar 500 sesiuni semi-deschise existente pe minut
Rata de sesiuni nou stabilite care vor duce la stoparea stergerii sesiunilor semi-deschise. 2 ip inspect one-minute low numar 400 sesiuni semi-deschise existente pe minut
Numarul sesiunilor TCP semi-deschise existente cu aceeasi adresa de destinatie la “host” (destination host address) care va duce la startul renuntarii la sesiunile semi-deschise la aceeasi adresa de destinatie la “host”.3 ip inspect tcp max-incomplete host numar block-time minute 50 sesiuni TCP semi-deschise existente;0 minutes
1 Peste timeout-urile generale TCP si UDP se pot suprapune anumite sesiuni de protocoale de aplicatii-strat (apllication-layer protocols) asa cum este descris in ip inspect name (global configuration).

2 Pentru mai multe informatii urmariti urmatoarea sectiune : „Sesiuni semi-deschise”.

3 Oricand pragul de sensibilitate „max-incomplete host” este depasit, soft-ul va renunta la sesiunile semi-deschise in mod diferit daca timeout-ul block-time-ului este zero sau un numar pozitiv diferit de zero. Daca timeout-ul block time-ului este zero, softul va sterge cele mai vechi sesiuni semi-deschise existente pentru „host” pentru fiecare cerere de conexiune noua la „host” si va permite trecerea pachetului SYN. Daca timeout-ul block time-ului este mai mare decat zero, softul va sterge toate sesiunile semi-deschise existente pentru „host” si apoi va bloca toate noile cereri de conexiune la „host”. Soft-ul va continua sa blocheze toate noile cereri de conexiune pana cand block time-ul expira.

Pentru reintroducerea valorilor de baza a „timeout-urilor” si pragurilor de sensibilitate se foloseste forma inversa a comenzilor din tabelului de mai sus.

Sesiuni semi-deschise

Un numar neobisnuit de mare de sesiuni semi-deschise (fie absolute fie raportate la rata de sosire) poate indica un atac „denial-of-service”. Pentru TCP „semi-deschis” inseamna ca sesiunea nu a atins starea stabilita -; mecanismul „TCP three-way handshake” nu este inca complet. Pentru UDP „semi-deschis” inseamna ca firewall-ul nu a detectat nici un trafic de intoarcere.
CBAC masoara atat numarul total al sesiunilor semi-deschise existente cat si rata incercarilor de stabilire a conexiunii de catre sesiuni. Atat sesiunile semi-deschise TCP cat si UDP sunt incadrate in numarul total si rata de masurare. Masurarile se fac odata la fiecare minut.
Atunci cand numarul de sesiuni semi-deschise existente depaseste pragul de sensibilitate (the max-incomplete high number), soft-ul va sterge sesiuni semi-deschise asa cum este necesar pentru a accepta noi cereri de conexiune. Soft-ul va continua sa stearga sesiuni semi-deschise corespunzator pana cand numarul de sesiuni semi-deschise existente va fi sub o alta valoare a pragului de sensibilitate (the max-incomplete low number).
Atunci cand rata noilor incercari de conexiune depaseste pragul de sensibilitate (the one-minute high number), soft-ul va sterge sesiuni semi-deschise asa cum este necesar pentru a accepta noi incercari de conexiune. Soft-ul va continua sa sterga sesiuni semi-deschise corespunzator pana cand rata noilor incercari de conexiune va fi sub o alta valoare a pragului de sensibilitate (the one-minute low number). Rata pragurilor de sensibilitate este calculata ca fiind numarul de noi incercari de conexiune din sesiune detectate in perioada din ultimul minut. (Rata este calculata invers proportional din punct de vedere exponential.)

4. Definirea unei reguli de verificare aTopi

Dupa ce s-a facut configurarea „timeout-urilor” si pragurilor de sensibilitate generale trebuie definita o regula de verificare. (inspection rule). Aceasta regula va determina ce trafic IP (ce protocoale de aplicatii strat) va fi verificat de CBAC la o interfata.
In mod normal se defineste o singura regula de verificare. Singura exceptie este in cazul in care se vrea configurarea CBAC in doua directii cum s-a mentionat mai devreme in sectiunea „Cand si unde se configureaza CBAC”. In cazul in care CBAC este configurat in doua directii la nivelul unei singure interfete a firewall-ului ar trebui configurate doua reguli, una pentru fiecare directie.
O regula de verificare ar trebui sa specifice fiecare protocol de aplicatii-strat dorit la fel ca si in cazurile generale TCP si UDP daca acest lucru este dorit. Regula de verificare consta intr-o serie de afirmatii fiecare dintre ele mentionand un protocol si specificand numele aceleiasi reguli de verificare.
Pentru a defini o regula de verificare se va urmarii materialul din urmatoarele doua sectiuni :

Configurarea verificarii protocolului de aplicatii-strat

Configurarea verificarii generale TCP si UDP

Configurarea verificarii protocolului de aplicatii-strat

Obs. Daca se doreste functionarea verificarii CBAC impreuna cu traficul NetMeeting 2.0 (un protocol de aplicatii-strat H.323) va trebui facuta si configurarea verificarii pentru TCP, asa cum se va descrie mai tarziu in sectiunea „Configurarea verificarii generale TCP si UDP”. Acest lucu este necesar intrucat NetMeeting 2.0 foloseste un canal aditional TCP nedefinit in specificatiile H.323.

Pentru a configura verificarea protocolului de aplicatii-strat va trebui sa procedati intr-unul din cele doua moduri generale descrise in tabelul de mai jos:

Sarcina Comanda
Se va face configurarea verificarii CBAC pentru un protocol de aplicatii-strat (cu exceptia RPC si Java). Se foloseste unul dintre cuvintele cheie ale protocoalelor definite in Tabelul 1, de mai jos.Se repeta aceasta comanda pentru fiecare protocol dorit. Se foloseste acelasi “nume de verificare” pentru a crea o singura regula de verificare. ip inspect name inspection-name protocol atimeout secundei
Se activeaza verificarea CBAC pentru protocolul de aplicatii-strat RPC.Se poate specifica numere multiple de programe RPC repetand aceasta comanda penru fiecare numar de program. Se foloseste acelasi “nume de verificare” pentru a crea o singura regula de verificare. ip inspect name inspection-name rpc program-number number await-time minutei atimeout secundei

Tabelul 1 : Cuvinte cheie pentru protocoale de aplicatii

Protocol de aplicatii Cuvantul cheie al protocolului
CU-See-Me cuseeme
FTP ftp
H.323 h323
UNIX R commands (r-login, r-exec, r-sh) rcmd
RealAudio realaudio
SMTP smtp
SQL*Net sqlnet
StreamWorks streamworks
TFTP tftp
VDOLive vdolive

Configurarea verificarii generale TCP si UDP

Se poate face configurarea verificarii TCP si UDP astfel incat sa fie permisa intrarea pachetelor TCP si UDP in reteaua interna prin firewall chiar daca protocolul de aplicatii-strat nu este configurat pentru verificare. In orice caz verificarea TCP si UDP nu recunoaste comenzile specifice aplicatiilor si deci s-ar putea sa nu permita intoarcerea pachetelor pentru o aplicatie, mai ales daca pachetele de intoarcere au un numar de port diferit fata de pachetul ce tocmai a parasit firewall-ul.

Orice protocol de aplicatii-strat care este verificat va lua intaietate fata de verificarea pachetelor TCP si UDP. De exemplu, daca verificarea este configurata pentru FTP, toate informatiile canalelor de control vor fi inregistrate in tabelul de stare, si traficul FTP va fi acceptat inapoi prin firewall daca informatiile canalelor de control sunt bune pentru starea sesiunii FTP. Faptul ca verificarea TCP este configurata nu este relevant pentru informatiile de stare FTP.
Cu verificarea TCP si UDP pachetele ce patrund in retea trebuie sa corespunda intocmai cu pachetul corespunzator ce tocmai a iesit din retea. Pachetele ce patrund in retea trebuie sa aiba aceleasi adrese sursa/destinatie si aceleasi numere de port sursa/destinatie ca si pachetul ce a parasit reteaua (numai ca inversate); altfel pachetele ce vor sa patrunda in retea vor fi blocate la interfata. De asemenea, se va renunta la toate pachetele TCP cu o secventa de numere din afara „ferestrei”.
Cu verificarea UDP configurata, raspunsurile vor fi acceptate inapoi prin firewall daca sunt primite intr-un timp configurabil dupa ce a fost trimisa ultima solicitare de raspuns. (Acest timp este configurat cu comanda ip inspect udp idle-time).
Pentru a configura verificarea CBAC pentru pachetele TCP si UDP este necesara folosirea uneia din cele doua sarcini din tabelul de mai jos :

Sarcina Comanda
Activarea verificarii CBAC pentru pachetele TCPFolosirea aceluiasi “nume de verificare” ca atunci cand se specifica alte protocoale pentru a crea o singura regula de verificare. ip inspect name inspection-name tcp atimeout secundei
Activarea verificarii CBAC pentru pachetele UDPFolosirea aceluiasi “nume de verificare” ca atunci cand se specifica alte protocoale pentru a crea o singura regula de verificare. ip inspect name inspection-name udp atimeout secundei

5. Aplicarea regulii de verificare unei interfete aTopi

Dupa ce s-a definit o regula de verificare se va aplica aceasta regula unei interfete.
In mod normal se aplica numai o singura regula de verificare unei interfete. Singura exceptie va avea loc atunci cand se vrea configurarea CBAC in doua directii cum a fost descris anterior in sectiunea „Cand si unde se configureaza CBAC” . Pentru CBAC configurat in doua directii la o singura interfata a firewall-ului ar trebui aplicate doua reguli, una pentru fiecare directie.
Daca CBAC se configureaza la o interfata externa, se aplica aceasta regula traficului cu destinatie indepartata.
Daca CBAC se configureaza la o interfata interna, se aplica aceasta regula traficului ”legat”.
Pentru a aplica o regula de verificare unei interfete se foloseste urmatoarea sarcina de configurare la interfata :

Sarcina Comanda
Se aplica o regula de verificare la o interfata. ip inspect inspection-name Ain | outS

6. Configurarile de „display”, informatiile de stare si statisticile pentru
CBAC
aTopi

Se pot vedea anumite informatii CBAC executand unele din urmatoarele comenzi EXEC :

Sarcina Comanda
Arata o regula de verificare particulara. show ip inspect name inspection-name
Arata configurarea verificarii complete CBAC. show ip inspect config
Arata configurarea interfetei cu referinte la regulile de verificare aplicate si la listele de acces. show ip inspect interfaces
Arata sesiunile existente care sunt monitorizate si verificate de CBAC. show ip inspect session adetaili
Arata toate configuratiile CBAC si toate sesiunile existente care sunt monitorizate si verificate de CBAC. show ip inspect all

7. „Debug-ul” CBAC aTopi

Pentru a activa debug-ul CBAC se pot activa mesajele „trail” care vor fi afisate pe consola dupa inchiderea fiecarei sesiuni CBAC.
Pentru a activa mesajele „trail” trebuie sa executati urmatoarea sarcina:

Sarcina Comanda
Activarea mesajelor “trail” CBAC. ip inspect audit trail

Comenzi generale de „debug”

Sarcina Comanda
Afisarea mesajelor despre functiile software intentate de CBAC. debug ip inspect function-trace
Afisarea mesajelor despre obiectele soft ce sunt create de CBAC. Crearea obiectelor corespunde inceperii sesiunilor CBAC verificate. debug ip inspect object-creation
Afisarea mesajelor despre obiecte software sterse de CBAC. Stergerea obiectelor corespunde incheierii sesiunilor CBAC verificate. debug ip inspect object-deletion
Afisarea mesajelor despre evenimentele software CBAC , incluzand informatii despre procesarea pachetelor CBAC. debug ip inspect events
Afisarea mesajelor despre evenimentele de timp CBAC cum ar fi atunci cand este atins un timeout CBAC. debug ip inspect timers
Activarea optiunii detaliate, care poate fi folosita in combinatii cu alte optiuni pentru aditionarea de noi informatii. debug ip inspect detail

Comenzi de „debug” la nivel de transport

Sarcina Comanda
Afisarea mesajelor despre evenimentele TCP verificate de CBAC inclusiv detalii despre pachetele TCP. debug ip inspect tcp
Afisarea mesajelor despre evenimentele UDP verificate de CBAC inclusiv detalii despre pachete UDP. debug ip inspect udp

Comenzi de „debug” pentru protocoale de aplicatii

Sarcina Comanda
Afisarea mesajelor despre evenimentele protocolului verificat de CBAC inclusiv detalii despre pachetele protocolului.Vezi Tabelul 2 pentru determinarea cuvintelor cheie ale protocolului. debug ip inspect protocol

Tabelul 2 : Cuvinte cheie ale protocoalelor de aplicatii pentru comanda de „debug” „ip inspect”

Protocolul de aplicatii Cuvantul cheie al protocolului
CU-See-Me cuseeme
FTP commands and responses ftp-cmd
FTP tokens (enables tracing of the ftp tokens parsed) ftp-tokens
H.323 h323
Java applets http
UNIX R commands (r-login, r-exec, r-sh) rcmd
RealAudio realaudio
RPC rpc
SMTP smtp
SQL*Net sqlnet
StreamWorks streamworks
TFTP tftp
VDOLive vdolive

O ultima sectiune din aceasta prezentare ar fi Anularea CBAC :

Daca se doreste acest lucru se poate anula Controlul Accesului Bazat pe Control folosind comanda no ip inspect de configurare globala.

Obs. Comanda no ip inspect sterge toate intrarile de configurare si reseteaza toate „timeout-urile” si pragurile de sensibilitate la cele de baza (defaults). Toate sesiunile existente sunt sterse la fel ca si listele de acces asociate acestora.

In majoritatea cazurilor anularea Controlului Accesului Bazat pe Control nu prezinta nici un impact negativ asupra securitatii deoarece CBAC creeaza liste de acces de tip „permit”. Fara configurarea CBAC nu sunt pastrate nici un fel de liste de acces de tip „permit”. In concluzie nici un fel de trafic (de intoarcere sau trafic din canalele de date) nu poate sa treaca prin firewall. Exceptiile le constituie blocajele SMTP si Java. Avand CBAC anulat comenzi SMTP sau apleturi Java nepermise pot trece prin firewall.

BIBLIOGRAFIE :

1) Cisco Systems https://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/sccbac.htm

2) Network Security Library Online, February 1999 https://secinf.net/info/fw/cisco/cisco.html

3) National Security Agency, Guide to Cisco Router Setup, December 27, 2001 https://nsa1.www.conxion.com/

4) Held & Hundley, Cisco Access Lists Field Guide
McGraw Hill Publishing, 2000

5) Morrissey, Peter, The cost of Security on Cisco Routers, February 1, 1999 https://www.networkcomputing.com/1004/1004ws2.html

6) Strebe & Perkins, Firewalls 24 Seven, Alameda, CA.
Sybex Network Press, 2000

7) Buchmann & Hogrell, CCNP Routing Guide, Berkeley CA.
Osborne Publishing, 2000

8) Bugtraq List https://lists.nas.nasa.gov/archives/ext/bugtraq/1998/09/msg00099.html

9) Router God Website https://routergod.com/donking/

10)https://www.banknet.kz/Iinfo/cisco/cc/td/doc/product/software/ios113ed/113t/113t_3/firewall.htm

11)https://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/sccbac.htm#xtocid168970
12) Antoine, Vanessa, et al., NSA/SNAC Router Security Configuration Guide Version 1.0j, National Security Agency, November 2001 https://nsa1.www.conxion.com/cisco/index.html
13) Antoine, Vanessa, et al., NSA/SNAC Router Security Configuration Guide, Executive Summary, Version 1.0c, National Security Agency, November 2001 https://nsa1.www.conxion.com/cisco/index.html
14) McIntyre, Robert., Cisco's hidden gem: The IOS firewall, TechRepublic 13 December 2001.
URL: https://www.zdnet.com.au/newstech/security/story/0,2000024985,20262359-1,00.htm
15) Unknown. Benefits and Limitations of Context Based Access Control, Cisco Systems, Date Unknown. https://www.cisco.com/warp/public/110/36.html
16) Unknown. Cisco IOS Firewall Feature Set and Context-Based Access Control, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/firewall.htm
17) Unknown. Cisco IOS Firewall Overview, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/scfirewl.htm
18) Unknown. Cisco IOS Security Configuration Guide, Release 12.2, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/
19) Unknown. Cisco IOS Security Command Reference, Release 12.2, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/
20) Unknown. Configuring Context-Based Access Control, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/sccbac.htm
21) Unknown. Configuring Network Security, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/ios127xe/config/secure.htm
22) Unknown. Context-Based Access Control, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/iosfw2_2.htm
23) Unknown. Context-Based Access Control Commands, Cisco Systems, Date Unknown. https://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_r/srprt3/srdcbac.htm
24) Unknown. Context-Based Access Control: Introduction and Configuration, Cisco Systems, Date Unknown. https://www.cisco.com/warp/public/110/32.html
25) Unknown. Cisco ISP Essentials, Cisco Systems, Date Unknown. https://www.cisco.com/public/cons/isp/essentials/IOS_Essentials_2-9.pdf
26) Unknown. Improving Security on Cisco Routers, Cisco Systems, Date Unknown. https://www.cisco.com/warp/public/707/21.html
27) Unknown. Increasing Security on IP Networks, Cisco Systems, Date Unknown https://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs003.htm
28) Unknown. Network Security Policy: Best Practices White Paper, Cisco Systems, Date Unknown https://www.cisco.com/warp/public/126/secpol.html

Obs. Acest referat a fost realizat prin traducere din limba engleza a mai multor surse de documentatie majoritatea materialelor provenind din documentatii atestate CISCO. Sper ca acest referat sa fie util si sa constituie un material de studiu folositor pentru cei ce vor sa se documenteze in domeniul retelelor de calculatoare.