Blog despre resurse educaţionale din IT » Web

Cum sa realizezi masquerading, transparent proxy, forwardare de porturi, si alte forme de NAT pentru kernelurile Linux ver 2.4.

admin — Wed, 06 Apr 2011 12:50:50 +0000

traducere ver. 0.2 de catre Riddl

Multumiri tuturor celor care m-au ajutat, in special lui Gushterul.
Observatie f importanta: probabil ca exista unele greseli in acest document.
Am tradus si eu cum m-am priceput mai bine, daca descoperiti greseli de
traducere si pentru observatii pertinente trimiteti-mi mail pentru Riddl la
“discutzii at gmx dot net”. Nu uitati sa precizati numele documentului.
Multumesc anticipat.
Aceasta versiune este putin modificata fata de original, deorece unii termeni
sunau foarte ciudat in ro.
Pentru ultima versiune a acestui document verifica
.

Lecturare placuta!
______________________________________________________________________
Linux 2.4 NAT HOWTO
Rusty Russell, lista de discutii netfilter@lists.samba.org
$Revision: 1.3 $ $Date: 2002/06/05 13:21:56 $

Acest document descrie cum sa realizezi masquerading, transparent proxy,
forwardare de porturi, si alte forme de NAT pentru kernelurile Linux ver 2.4.

______________________________________________________________________

Cuprins

1. Introducere
2. Care este site-ul oficial si care sunt listele de discutii?
2.1. Ce inseamna NAT?
2.2. De ce as dori sa realizez NAT?
3. Doua tipuri de NAT
4. Trecere rapida de la kernelurile 2.0 si 2.2
4.1. Doresc sa realizez doar masquerading! Help!
4.2. Dar despre ipmasqadm?
5. Controlul a ceea ce dorim sa facem cu NAT?
5.1 Selectare simpla folosind iptables
5.2 Aspecte delicate in privinta selectarii pachetelor ce le dorim
modificate
6. Cum sa modificam pachetele
6.1 Folosirea NAT pentru modificarea adresei sursa (SNAT)
6.1.1 Masquerading
6.2 Folosirea NAT pentru modificarea adresei destinatie (DNAT)
6.2.2 Redirectare
6.3 Mapare complexa
6.3.1. Selectarea de adrese multiple dintr-un sir
6.3.2. Realizarea de mapare NAT nula
6.3.3. Comportamentul NAT standard
6.3.4. Mapare implicita a porturilor sursa
6.3.5. Ce se intampla cand NAT-area nu reuseste
6.3.6. Mapari multiple, Suprapuneri si Conflicte
6.3.7. Schimbarea destinatiei conexiunilor generate local
7. Protocoale speciale
8. Avertizmente privind folosirea NAT
9. Folosirea SNAT si rutarea
10. Folosirea DNAT pentru adrese aflate in aceeasi retea.
11. Multumiri

______________________________________________________________________

1. Introducere

Bine ai venit!

Esti pe cale sa incepi sa inveti fascinanta (si uneori inspaimantatoare)
lume a NAT-ului: traducerea adreselor de retea. Acest Howto iti va fi
oarecum un ghid precis pentru kernelurile din linux ver. 2.4 si peste.

In kernelul de linux ver. 2.4, a fost introdus suport pentru modificarea
pachetelor, numit “netfilter”. Un nivel deasupra acestuia pune la dispozitie
NAT (translatarea adreselor de retea), complet rescris fata de versiunile din
kernelurile anterioare.

2. Care este site-ul oficial si care sunt listele de discutii?

Sunt trei site-uri oficiale:

o Multumiri lui Filewatcher .
o Multumiri Echipei Samba si SGI .
o Multumiri lui Harald Welte .

Le poti accesa pe toate folosind round-robin DNS la:
si

Pentru lista de discutii oficiala de la netfilter, vezi:
.

2.1. Ce inseamna NAT?

In mod normal, pachetele intr-o retea se deplaseaza de la sursa (cum ar fi
computerul tau) la destinatia (cum ar fi www.securityorg.net) prin mai
multe legaturi de retea diferite: de exemplu cam 19 de la locatia in care ma
aflu eu. Nici una din aceste legaturi nu iti modifica pachetul, pur si simplu
este trimis mai departe.

Daca una din aceste legaturi ar fi facut NAT, atunci ar fi modificat sursa sau
destinatia pachetului ce intra. Dupa cum iti imaginezi nu asa a fost conceput
sistemul sa functioneze, si din aceasta cauza NAT este intodeauna ceva
in genul unui infirm. Deobicei legatura care a facut NAT va tine minte cum a
modificat pachetul, si cand un pachet replica vine din cealalta parte, va
realiza modificarea inversa a pachetului replica, asa ca totul va functiona.

2.2. De ce as dori sa realizez NAT?

Intr-o lume perfecta nu ai avea nevoie. Intre timp, principale motive sunt:

Conexiunile prin modem la internet
Cele mai multe ISP-uri iti dau doar o singura adresa IP cand te
conectezi la ei. Poti trimite pachete cu orice adresa sursa pe care o
doresti, dar doar pachetele cu aceasta adresa IP se vor intoarce la
tine. Daca doresti sa folosesti mai multe sisteme (cum ar fi reteaua
de acasa) pentru a le conecta la internet prin aceasta singura
legatura vei avea nevoie de NAT.
Aceasta este de departe cel mai raspandit mod de folosire al NAT-ului
din zilele noastre, cunoscut si sub numele de “masquerading” in lumea
Linuxului. Eu numesc aceasta SNAT, deoarece modifici adresa sursa a
primului pachet.

Servere multiple
Uneori doresti sa modifici directia in care sa se indrepte pachetele
ce intra in reteaua ta. In mod frecvent aceasta este (ca si mai sus)
deoarece ai doar o singura adresa IP, dar doresti ca oameni sa poata
sa ajunga la computerele din spatele sistemului cu adresa IP “reala”.
Daca rescrii adresa destinatie a pachetelor care intra, poti realiza
acest lucru. Acest tip de NAT a fost numit forwardare (inaintare) de
porturi in versiunile anterioare de Linux.
O variatie des intalnita a acestei aplicatii al NAT-ului este
load-sharing-ul (incarcare partajata), unde se mapeaza mai multe
sisteme, permitand sistemelor sa ajung la aceste sisteme. Daca
realizezi acest lucru la o scara mare, ar fi bine sa te uiti pe
Linux Virtual Server .

Proxy transparent
Uneori doresti sa para ca fiecare pachet care trece prin sistemul tau
Linux este destinat pentru un program ruland chiar pe sistemul tau.
Acest lucru este folosit pentru a realiza proxy-uri transparente: un
proxy este un program care se interpune intre reteaua ta si lumea
exterioara, mediand comunicarea intre ele. Se numeste transparent
deoarece reteaua ta nici nu va realiza ca foloseste un proxy, doar daca
bineinteles, proxy-ul nu functioneaza.
Squid-ul poate fi configurat sa ruleze in acest mod, si aceasta era
numita redirectare sau realizare de proxy transparent in versiunile
anterioare de linux.

3. Doua tipuri de NAT

Am impartit NAT-ul in doua tipuri: NAT pentru sursa (SNAT) si NAT pentru
destinatie (DNAT).

SNAT este realizat atunci cand modifici adresa sursa al primului pachet:
schimbi sursa de unde porneste conexiunea. SNAT este intodeauna realizat dupa
procesul de rutare al pachetelor, chiar inainte de a pleca pe conexiune
pachetul. Masquerading este o forma particulara de SNAT.

DNAT este realizat cand modifici adresa destinatie al primului pachet: schimbi
destinatia unde va fi facuta conexiunea. DNAT este intodeauna realizat
inainte de rutarea pachetelor, cand pachetul tocmai a venit prin interfata.
Forwardare de porturi, load-sharing-ul, si proxy-ul transparent sunt toate
forme de DNAT.

4. Trecere rapida de la kernelurile 2.0 si 2.2

Imi pare rau pentru aceia dintre dumneavastra socati de trecerea de la
versiunea 2.0 (ipfwadm) la 2.2 (ipchains). Exista vesti bune si vesti proaste.

In primul rand, poti in mod simplu sa folosesti ipchains si ipfwadm ca mai
inainte. Pentru aceasta trebuie sa incarci (insmod) modulele pentru kernel
“ipchains.o” sau “ipfwadm.o” ce se gasesc in ultima distributie netfilter.
Acestea se exclud reciproc (ai fost avertizat), si nu ar trebui folosite cu
nici un alt modul din netfilter.

Odata ce unul din aceste module a fost incarcat, vei putea folos ipchains si
ipfwadm in mod normal, insa cu unele diferente:

- Setarea de timeout-uri pentru masquerading cu ipchains -M -S, sau ipfwadm
-M -s nu rezolva nimic. Cum timeout-urile sunt mai mari pentru noua
infrastructura NAT, acest lucru nu ar trebui sa conteze.

- Campurile init_seq, delta si previous_delta in listarea detaliata a
masqueradarii sunt intodeauna zero.

- Resetarea si listarea counter-elor simultana “-Z -L” nu mai este posibila:
countere-le nu vor fi resetate.

- Nivelul de compatibilitate nu este foarte bun pentru un numar de conexiuni
foarte mare: nu il folosi pentru gateway-ul corporatiei.

Hackerii pot deasemenea sa observe:

- Acum te poti lega si pe porturile 61000-65095 chiar daca realizezi
masquerading. Codul pentru masqueradare obisnuia sa considere ca nimic in
aceasta raza ar fi fost ceva corect, asa ca programele nu puteau sa o
foloseasca.

- “Hack-ul” (nedocumentat) “getsockname”, pe care programele ce realizau proxy
transparent il puteau folosi pentru a afla adresa reala a conexiunilor nu
mai este disponibil.

- “Hack-ul” (nedocumentat) bind-to-foreign-address (atasare pe o adresa
straina) nu mai este deasemnea implementat; acesta era folosit pentru a
completa iluzia de proxy transparent.

4.1. Doresc sa realizez doar masquerading! Help!

Aceasta este ce vor majoritatea oamenilor. Daca ai o adresa PPP IP dinamica,
vrei in mod simplu sa spui sistemului tau ca toate pachetele ce vin din
reteaua interna ar trebui sa fie modificate astfel incat sa para ca vin de la
sistemul tau.

# Incarca modulul NAT (acesta introduce toate modulele necesare)
modprobe iptable_nat

# In tabela NAT (-t nat) in chain-ul POSTROUTING adauga o regula
# pentru toate pachetele care ies prin ppp0 (-p ppp0) care precizeaza
# sa masqueradeze conexiunea (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Da drumul la forwardarea IP
echo 1 > /proc/sys/net/ipv4/ip_forward

Observatie: aici nu faci nici un fel de filtrare a pachetelor: pentru aceasta
citeste Packet Filtering HOWTO: capitolul “Folosirea impreuna a NAT-ului si a
filtrarii de pachete”.

4.2. Dar despre ipmasqadm?

Nu este cazul sa ne facem probleme prea mari pentru compatibilitate. Poti
folosi in mod simplu “iptables -t nat” pentru a realiza forwardare de
porturi. De exemplu, in Linux 2.2 ai fi facut:

# Linux 2.2
# Forwardeaza pachetele TCP catre portul 8080, adresa 1.2.3.4, spre
# portul 80, adresa 192.168.1.1
ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80

Acum ar trebui sa faci:

# Linux 2.4
# Adauga o regula inainte de procesul rutarii in chain-ul PREROUTING
# (-A PREROUTING) in tabela NAT (-t nat) pentru ca pachetele TCP
# (-p tcp) care vin spre adresa 1.2.3.4 (-d 1.2.3.4), portul 8080
# (–dport 8080) sa aiba destinatia mapata (-j DNAT) catre
# 192.168.1.1, portul 80 (–to 192.168.1.1:80)
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 –dport 8080 \
-j DNAT –to 192.168.1.1:80

5. Controlul a ceea ce dorim sa facem cu NAT?

Ai nevoie sa scrii reguli NAT pentru a spune kernelului ce conexiuni sa
schimbe, si cum sa le schimbe. Pentru a realiza aceasta folosim comanda
iptables, si precizam ca dorim a schimba tabela NAT prin specificarea optiunii
“-t nat”.

Tabela regulilor NAT cuprinde trei liste numite “chain-uri”: fiecare regula
este examinata in chain pana cand una se potriveste. Doua chain-uri sunt
numite PREROUTING (pentru DNAT, pentru pachetele care tocmai au intrat) si
POSTROUTING (pentru SNAT, pentru pachetele care sunt pe cale sa iasa). Al
treilea chain (OUTPUT) va fi ignorat in cele ce urmeaza.

Urmatoarea diagrama ilustreaza destul de bine cum stau lucrurile:

La fiecare dintre punctele de mai sus, cand un pachet trece este determinat
carei conexiuni ii este asociat. Daca este o conexiune noua, este determinat
chain-ul corespunzator in tabela NAT pentru a determina ce sa facem cu acel
pachet. Raspunsul determinat va fi aplicat pentru toate pachetele viitoare
apartinand acelei conexiuni.

5.1 Selectare simpla folosind iptables

iptables admite un numar de optiuni standard dupa cum sunt listate mai jos.
Toate optiunile care incep cu “–” pot fi prescurtate, atat timp cat iptables
poate sa le deosebeasca de alte optiuni. Daca kernelul tau are iptables
compilat ca modul, este necesar sa incarci intai modulul iptables: “insmod
ip_tables”.

Cea mai importanta optiune in acest caz este optiunea de selectare a tabelei,
“-t”. Pentru toate actiune NAT, vei dori sa folosesti “-t nat” pentru tabela
NAT. A doua cea mai importanta optiune este “-A” pentru a adauga o noua regula
la sfarsitul unui chain (“-A POSTROUTING”), sau “-I” pentru a insera o regula
la inceputul unui chain (“-I PREROUTING”).

Poti specifia sursa (“-s” sau “–source”) si destinatia (“-d” sau
“–destination”) pachetelor pe care le doresti sa le prelucrezi prin NAT.
Aceste optiuni pot fi urmate de o singura adresa IP (192.168.1.1), un nume
(www.securityorg.net), sau o adresa de retea (192.168.1.0/24 sau
192.168.1.0/255.255.255.0).

Poti specifica interfata cu care sa se potriveasca regula, de intrare (“-i”
sau “–in-interface”) sau de iesire (“-o” sau “–out-interface”), dar ceea ce
poti specifica depinde si de chain-ul in care introduci regula: pentru
chain-ul PREROUTING poti selecta numai interfete prin care intra pachetele,
si in chain-ul POSTROUTING poti selecta numai interfete de iesire. Daca
folosesti o interfata gresita iptables iti va da eroare.

5.2 Aspecte delicate in privinta selectarii pachetelor ce le dorim modificate

Am spus mai sus ca poti preciza o adresa sursa si destinatie. Daca vei omite
optiunea privitoare la adresa sursa, atunci regula se va potrivi pentru
orice adresa sursa. Analog, daca omiti optiunea pentru adresa destinatie, atunci
regula se va potrivi pentru orice adresa destinatie.

Poti deasemenea indica un protocol specific (“-p” sau “–protocol”), cum ar fi
TCP sau UDP; doar pachetele de acest tip se vor potrivi cu regula. Principalul
motiv pentru a preciza unul dintre aceste protocoale permite apoi folosirea de
noi optiuni: in special optiunile “–source-port” si “–destination-port”
(prescurtate “–sport” si “–dport”).

Aceste optiuni iti permite sa specifici ca numai pachetele cu anumite porturi
destinatie sau porturi sursa se vor potrivi cu regulii. Aceste optiuni sunt
folositoare, de exemplu, pentru redirectarea cererilor web (porturile TCP 80
sau 8080) si nemodificarea celorlalte pachete.

Aceste optiuni trebuie sa fie puse dupa optiunea “-p” (care are ca alt efect
incarcarea optiunilor extinse pentru acel protocol). Poti folosi pentru
porturi numere, sau nume cum sunt scrise in fisierul /etc/services.

Toate caracteristicile dupa care poti selecta un pachet sunt detaliate in
pagina de manual pentru iptables (man iptables).

6. Cum sa modificam pachetele

In concluzie, acum stim cum sa selectam pachetele pe care le dorim modificate.
Pentru a scrie regulile complete trebuie sa spunem kernelului cu exactitate
ceea ce dorim sa facem pachetelor.

6.1 Folosirea NAT pentru modificarea adresei sursa

Doresti sa faci SNAT; sa schimbi adresa sursa a conexiunilor cu ceva diferit.
Acesta este realizat in chain-ul POSTROUTING, chiar inainte de a fi trimis
pachetul; acesta este un detaliu important, deoarece inseamna ca orice alceva
in sistemul Linux (rutare, filtrare de pachete) va vedea doar pachetul
neschimbat. Mai inseamna deasemenea ca optiunea “-o” (interfata de iesire)
poate fi folosita.

SNAT este specificat folosind optiunea “-j SNAT”; si optiunea “–to-source”
specifica o adresa IP, un sir de adrese IP, si un port optional sau un sir de
porturi (doar in cazul protocoalelor UDP si TCP).

## Schimba adresa sursa cu 1.2.3.4
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT –to 1.2.3.4

## Schimba adresa sursa cu 1.2.3.4, 1.2.3.5 sau 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT –to 1.2.3.4-1.2.3.6

## Schimba adresa sursa cu 1.2.3.4, si porturile intre 1-1023
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT –to 1.2.3.4:1-1023

6.1.1 Masquerading

Exista un caz particular de SNAT numit masquerading: ar trebui sa fie folosit
numai pentru adrese IP asignate dinamic, cum ar fi in cazul celor ce se
conecteaza prin dial-up (pentru adrese IP statice, foloseste SNAT ca mai sus).

Nu este necesar cand faci masquerading sa specifici adresa sursa: deoarece va
folosi adresa sursa a interfetei prin care va iesi pachetul. Dar ce este mai
importat, daca legatura cu ISP-ul cade, conexiunile (care acum sunt pierdute
oricum) sunt uitate, acest lucru inseamnand mai putine probleme tehnice cand
legatura cu ISP-ul revine cu o noua adresa IP.

## masqueradare pentru ppp0
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

6.2 Folosirea NAT pentru modificarea adresei destinatie (DNAT)

Aceasta se realizeaza in chain-ul PREROUTING, exact dupa primirea
pachetului, aceasta insemna ca orice in sistemul Linux (rutare, filtrare de
pachete) va vedea pachetul cu noua adresa destinatie. Mai inseamna ca optiunea
“-i” (interfata de intrare) poate fi folosita.

Se specifica folosirea DNAT cu ajutorul optiunii “-j DNAT”, iar optiunea
“–to-detination” specifica o adresa IP, un sir de adrese IP, si un port
optional sau un sir de porturi (acest lucru fiind valabil doar pentru
protocoalele UPD si TCP).

## Schimba adresa destinatie cu 5.6.7.8
# iptables -t nat -A PREROUTING -i eth0 -j DNAT –to 5.6.7.8

## Schimba adresa destinatie cu 5.6.7.8, 5.6.7.9 sau 5.6.7.10.
# iptables -t nat -A PREROUTING -i eth0 -j DNAT –to 5.6.7.8-5.6.7.10

##Schimba adresa destinatie a traficului spre portul 80 cu 5.6.7.8, port 8080.
# iptables -t nat -A PREROUTING -p tcp –dport 80 -i eth0 \
-j DNAT –to 5.6.7.8:8080

6.2.2 Redirectare

Exista un caz particular de DNAT numita redirectare: este o simpla conventie
care este echivalenta cu a realiza DNAT catre adresa interfetei prin care
intra pachetele.

## Trimite traficul care vine pe portul 80 catre squid (proxy-ul
transparent
# iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 \
-j REDIRECT –to-port 3128

Observatie: squid-ul trebuie sa fie configurat pentru a putea fi folosit ca
proxy transparent!

6.3 Mapare complexa

Sunt cateva lucruri rafinate in folosirea NAT pe care majoritatea oamenilor nu
vor avea nevoie sa le foloseasca. Aceste lucruri sunt documentate mai jos
pentru curiosi.

6.3.1. Selectarea de adrese multiple dintr-un sir

Daca un sir de adrese IP este specificat, adresa IP care va fi folosita este
bazata pe cea mai putin folosita la conexiuni adresa IP de care sistemul stie.
Acest comportament furnizeaza load-balancing primar.

6.3.2. Realizarea de mapare NAT nula

Poti folosi tinta “-j ACCEPT” pentru a permite realizarea conexiunii fara sa
fie realizat deloc NAT.

6.3.3. Comportamentul NAT standard

Comportamentul obisnuit este sa modifice conexiunea cat mai putin posibil, cu
exceptia regulilor date de catre utilizator. Aceasta inseamna ca nu vor fi
remapate porturile decat daca suntem obligati sa realizam acest lucru.

6.3.4. Mapare implicita a porturilor sursa

Chiar daca folosirea NAT nu este ceruta pentru o conexiune, translatarea
portului sursa poate fi facut automat, daca o alta conexiune a fost mapata
peste una noua. De exemplu considerati un caz care este comun in masquerading:

1. O conexiune web este realizata de la un sistem cu IP-ul 192.1.1.1 cu portul
sursa 1024 catre www.securityorg.net portul 80.

2. Aceasta conexiune este masqueradata de un sistem care se ocupa cu acest
lucru, pentru a folosi IP-ul sursa al sistemului ce realizeaza masqueradarea
(1.2.3.4)

3. Insusi sistemul ce realizeaza masquerading initiaza o conexiune catre
www.securityorg.net, portul 80, de la 1.2.3.4 (adresa interfetei externe)
portul 1024

4. Codul NAT va modifica portul sursa al celei de-a doua conexiuni cu 1025,
astfel ca sa nu existe conflict intre cele doua conexiuni.

Cand se realizeaza aceasta mapare automata a sursei, porturile sunt impartite
in trei clase:

o Porturile sub 512
o Porturile intre 512 si 1023
o Porturile de la 1024, inclusiv, in sus

Un port nu va fi niciodata mapat automat intr-o clasa diferita.

6.3.5. Ce se intampla cand NAT-area nu reuseste

Daca nu mai este disponibil nici un mod in care sa se relizeze maparea unica a
conexiunii cerute de catre utilizator, conexiunea va fi abandonata. Acest
comportament se aplica ai in cazurile in care pachetele nu au putut fi
clasificate ca parte a unei conexiuni, deoarece sunt malformate, sau sistemul
nu mai are memorie libera, etc.

6.3.6. Mapari multiple, Suprapuneri si Conflicte

Daca ai reguli care folosesc NAT pentru mapare de porturi aflate intr-o raza
comuna; codul NAT este destul de inteligent pentru a evita conflicte. Aceasta
pentru ca, avand doua reguli, este corecta maparea adresei sursa pentru
192.168.1.1 si respectiv 192.168.1.2 in adresa 1.2.3.4.

Mai mult, poti face mapare peste adrese IP reale folosite, atat timp cat
aceste adrese trec deasemenea prin masina care realizeaza maparea. Asa ca daca
ai o retea asignata (1.2.3.0/24), dar ai o retea interna care foloseste
aceasta clasa de IP-uri si inca o retea care foloseste o clasa de adrese IP
private 192.168.1.0/24, poti sa realizezi SNAT pentru adresele cu sursa IP
192.168.1.0/24 peste adresele din reteaua 1.2.3.0, fara sa iti fie teama de
conflicte:

# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT –to 1.2.3.0/24

Aceeasi logica se aplica adreselor folosite de insusi sistemul ce realizeaza
NAT: in acest fel functioneaza si masquerading-ul (prin folosirea impreuna a
adresei interfatei de catre pachetele masqueradate si pachetele “reale”
venite de la insusi sistemul ca realizeaza masquerading-ul).

De altfel, poti mapa aceleasi pachete pe mai multe sisteme diferite, si
acestea vor fi folosite in comun. De exemplu, daca nu doresti sa mappezi nimic
peste adresa 1.2.3.5, ai putea sa dai urmatoarea comanda:

# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT –to 1.2.3.0-1.2.3.4 –to 1.2.3.6-1.2.3.254

6.3.7. Schimbarea destinatiei conexiunilor generate local

Codul NAT iti permite sa introduce reguli in chainul OUTPUT avand ca tinta
DNAT, dar acest lucru nu este in intregime suportat in kernelurile 2.4 (poate
fi programat dar are nevoie de noi optiuni, testari, si putina programare,
asa ca daca nimeni nu il contacteaza pe Rusty pentru al scrie, nu o sa fie
disponibil prea devreme).

Limitarea curenta este faptul ca poti sa schimbi destinatia pachetelor doar
catre sistemul local ( “-j DNAT –to 127.0.0.1″), nu si catre alte sisteme, in
caz contrar replicile nu vor fi primite in mod corect inapoi.

7. Protocoale speciale

Unele protocoale nu accepta sa fie NAT-uite. Pentru fiecare dintre aceste
protocoale, doua module speciale trebuiesc scrie; unul pentru urmarirea
conexiunilor si al doilea pentru operatia de NAT-are propriu-zisa.

In cadrul distributiei netfilter, exista module pentru ftp: ip_conntrack_ftp.o
si ip_nat_ftp.o. Daca le inserezi in kernel (insmod) sau le compilezi in
kernel, atunci realizarea oricarui tip de NAT pentru conexiuni ftp ar trebui
sa functioneze. Daca nu, atunci poti folosi ftp pasiv, si chiar si atunci s-ar
putea sa nu functioneze foarte sigur daca vrei sa realizezi alceva decat SNAT.

8. Avertizmente privind folosirea NAT

Daca realizezi NAT pentru o conexiune, pachetele venind din ambele sensuri
(din afara si din inauntrul retelei) trebuie sa treaca prin sistemul care
realizeaza NAT-area, in caz contrar lucrurile nu vor functiona sigur. In
special, codul urmarii conexiunilor reansambleaza fragmentele, care inseamna
ca nu numai depistarea conexiunilor nu va fi sigura, dar chiar si pachetele
s-ar putea sa nu treaca deloc, ca fragmente fiind retinute.

9. Folosirea SNAT si rutarea

Daca doresti sa realizezi SNAT, vei dori sa fii sigur ca fiecare masina la
care ajung pachete care sunt parte a unei conexiuni SNAT, vor trimite
pachetele replica inapoi la sistemul care realizeaza SNAT-ul.
De exemplu, daca mapezi niste pachete ce ies, cu adresa sursa 1.2.3.4, atunci
ruterul extern trebuie sa stie ca trebuie sa trimita pachetele replica inapoi
(care vor avea adresa destinatie 1.2.3.4) catre acest sistem.
Acest lucru poate fi realizat in urmatoarele moduri:

1. Daca realizezi SNAT peste adresa propriului sistem (pentru care rutarea si
toate celelalte merg deja), nu trebuie sa faci nimic

2. Daca realizezi SNAT peste o adresa nefolosita din propriul LAN (de exemplu,
mappezi peste 1.2.3.99, o adresa IP nefolosita din reteaua ta 1.2.3.0/24),
sistemul ce realizeaza NAT va trebui sa raspunda la cereri ARP pentru aceea
adresa ca si pentru propria sa adresa: cea mai simpla metoda de a rezolva
acest lucru este sa creezi un alias pentru adresa IP, de exemplu:

# ip address add 1.2.3.99 dev eth0

3. Daca realizezi SNAT peste o adresa complet diferita, va trebui sa te asiguri
ca masinile la care vor ajunge pachetele SNAT-atate vor ruta aceasta adresa
inapoi catre sistemul pe care se realizeaza SNAT-ul. Aceasta este realizata
deja daca sistemul care realizeaza SNAT-ul este gateway-ul lor default, in caz
contrar va trebui sa adaugi o ruta pe fiecare sistem prin care trec pachetele
modificate.

10. Folosirea DNAT pentru adrese aflate in aceeasi retea.

Daca realizezi forwardare de porturi inapoi in aceeasi retea, trebuie sa fii
sigur ca atat pachetele viitoare cat si pachetele ce vin in replica vor trece
prin sistemul ce realizeaza DNAT-ul (pentru ca acestea sa fie modificate).
Codul NAT va bloca (inca din ver. 2.4.0-test6) pachetele ICMP de redirectare
care rezulta atunci cand pachetele NAT-ate se indreapta catre aceeasi interfata
spre care au venit, dar serverul care primeste acele pachete va incerca in
continuare sa raspunda direct catre client (care nu va recunoaste pachetele
replica).

Cazul clasic este cand un sistem din reteaua interna incearca sa acceseze
serverul www “public”, care este defapt DNAT-at de la adresa publica (1.2.3.4)
catre un sistem din reteaua interna (192.168.1.1), astfel:

# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp –dport 80 -j DNAT –to 192.168.1.1

O cale este sa rulezi un server de DNS intern care sa stie adresa IP reala
(interna) al site-ului public de web, si sa inainteze toate celelate cereri
catre un server DNS extern. Aceasta inseamna ca va fi folosita o conexiune
directa catre server-ul de web, fara sa mai fie nevoie de a trece prin
sistemul care realizeaza NAT.

Cealalta cale este sa realizezi, pe sistemul care face DNAT, mapparea adresei
sursa spre propria lui adresa pentru conexiunile venind din reteaua interna,
pacalind serverul de web sa trimita pachetele replica spre masina ce se ocupa
cu NAT-area. Pentru acest exemplu vom proceda astfel (presupunem ca adresa IP
al sistemului care realizeaza NAT este 192.168.1.250):

# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp –dport 80 -j SNAT –to 192.168.1.250

Deoarece regula din chain-ul PREROUTING este executata prima, pachetele vor fi
deja destinate pentru server-ul de web intern: putem preciza care din pachete
sunt din reteaua interna dupa adresa IP sursa.

11. Multumiri

Multumirile sunt in primul rand pentru WatchGuard, si David Bonn, care a
crezut in ideea netfilter destul pentru a ma sustine sa o tranform in
realitate. Si pentru toti ceilalti, care m-au suportat cand faceam pe grozavul
cand am invatat despre uratenia NAT-ului, in special celor ce mi-au citit
jurnalul.

Rusty.

IPCHAINS pentru Linux. HOWTO

admin — Wed, 06 Apr 2011 12:36:44 +0000

traducere ver. 0.2 de catre Riddl
Documentul a fost tradus intr-un ritm foarte alert.
Nu este o traducere profesionala. Deasemenea nu este o traducere mot-a-mot.
Am incercat sa respect versiunea originala.
Multumiri lui Gushterul. Daca gasiti greseli sau aveti obervatii dati-mi
un mail pentru Riddl la “discutii at gmx dot net”. Nu uitati sa precizati
numele documentului.
Multumesc anticipat.
Pentru ultima versiune a acestei traduceri verifica
.

Lecturare placuta!

______________________________________________________________________
Rusty Russell
v1.0.8, Tue Jul 4 14:20:53 EST 2000

Acest document descrie cum sa obtii, instalezi si configurezi software-ul
ipchains pentru realizarea de firewall sub Linux, precum si cateva
posibilitati de folosire al acestuia.
______________________________________________________________________

Cuprins

1. Introducere
1.1. La ce foloseste?
1.2. De ce?
1.3. Cum?
1.4. De unde?
2. Bazele teoretice ale filtrarii de pachete
2.1. La ce foloseste?
2.2. De ce?
2.3. Cum?
2.3.1. Un kernel ce are compilat suport pentru filtrare de
pachete
2.3.2. ipchains
2.3.3. Crearea regulilor permanente
3. Sunt derutat! Rutare, masqueradare, forwardare de pachete, ipautofw….
3.1. Ghidul de trei linii al lui Rusty privind masqueradarea
3.2. Promovare gratuita: regulile WatchGuard
3.3. Firewall-uri obisnuite
3.3.1. Retea privata: Proxy-uri traditionale
3.3.2. Retea privata: Proxy-uri transparente
3.3.3. Retea privata: Masquerading
3.3.4. Retea publica
3.3.5. Servicii interne limitate
3.4. Mai multe informatii despre masquerading

4. Filtrul de pachete
4.1. Cum travereseaza pachetele filtrele
4.1.1. Folosirea ipchains
4.1.2. Ce vei vedea cand porneste computerul
4.1.3. Operatii pentru o singura regula
4.1.4. Optiuni de filtrare
4.1.4.1. Specificarea adreselor IP sursa si destinatie
4.1.4.2. Specificarea inversa
4.1.4.3. Specificarea protocolului
4.1.4.3.1. Specificarea porturilor TCP si UDP
4.1.4.3.2. Specificarea tipului si codului
ICMP
4.1.4.4. Specificarea interfetei
4.1.4.5. Specificarea doar a pachetelor TCP SYN
4.1.4.6. Despre fragmente
4.1.5. Efectele filtrarii de pachete
4.1.5.1. Specificarea unei tinte
4.1.5.2. Logarea pachetelor
4.1.5.3. Schimbarea tos (type of service)
4.1.5.4. Marcarea unui pachet
4.1.5.5. Operatii pentru un chain
4.1.5.6. Crearea unui chain nou
4.1.5.7. Stergerea unui chain
4.1.5.8. Stergerea tuturor regulilor unui chain
4.1.5.9. Listarea regulilor unui chain
4.1.5.10. Resetarea (aducerea la 0) a counter-elor
4.1.5.11. Setarea policy-ului
4.1.6. Operatii pentru masquerading
4.1.7. Verificarea unui pachet
4.1.8. Mai multe reguli dintr-o data si ceea ce se intampla
atunci
4.2. Exemple folositoare
4.2.1. Folosirea ipchains-save
4.2.2. Folosirea ipchains-restore
5. Diverse
5.1. Cum sa iti organizezi regulile firewall-ului
5.2. Ce anume sa nu filtrezi spre afara
5.2.1. Pachete icmp
5.2.2. Conexiunile TCP catre servere DNS (servere de nume)
5.2.3. FTP
5.3. Filtrarea Pingului Mortii
5.4. Filtrarea pentru Teardrop si Bonk
5.5. Filtrarea fragmentelor in masa
5.6. Schimbarea regulilor din firewall
5.7. Cum realizez protectia impotriva spoofarii IP
5.8. Proiecte mai avansate
5.8.1. SPF: filtrare dupa starea pachetului (stateful packet
filtering)
5.8.2. “Hack-ul” ftp-data al lui Michael Hasenstein
5.9. Planuri de viitor
6. Probleme des intalnite
6.1. ipchains -L ingheata!
6.2. Specificarea inversa nu poate fi realizata!
6.3. Masqueradarea/Forwardarea nu se realizeaza!
6.4. Tinta -j REDIR nu merge!
6.5. Specificare mai multor interfete (ex “-i ppp+”) nu merge!
6.6. TOS nu merge!
6.7. ipautofw si ipportfw nu merg!
6.8. xosview este stricat!
6.9. Segmentation Fault din cauza tintei “-j REDIRECT”!
6.10. Nu pot preciza valori de timeout pentru masquerading!
6.11. Vreau sa filtrez IPX!
7. Un exemplu serios
7.1. Topologia retelei
7.2. Scopurile
7.3. Inainte de realizarea filtrarii de pachete
7.4. Filtrarea de pachete pentru pachetele directe
7.4.1. Trecerea spre alte chain-uri din chain-ul forward
7.4.2. Definirea chain-ului icmp-acc
7.4.3. Reguli pentru conexiuni reteaua interna ==> DMZ
(servere)
7.4.4. Reguli pentru conexiuni din reteaua externa ==> DMZ
(servere)
7.4.5. Reguli pentru conexiuni din reteaua interna ==> reteaua
externa
7.4.6. Reguli pentru conexiuni din DMZ ==> reteaua interna
7.4.7. Reguli pentru conexiuni din DMZ ==> reteaua externa
7.4.8. Reguli pentru conexiuni din reteaua externa ==> reteaua
interna
7.4.9. Filtrul de pachete pentru insusi sistemul care este
ruter
7.4.9.1. Interfata catre reteaua externa
7.4.9.2. Interfata catre reteaua de servere (DMZ)
7.4.9.3. Interfata catre reteaua interna
7.5. In final
8. Anexa: Diferente intre ipchains si ipfwadm
8.1. Tabel pentru informare rapida
8.2. Exemple de comenzi ipfwadm translatate in ipchains
9. Anexa: Folosirea scriptului ipfwadm-wrapper
10. Anexa: Multumiri.
10.1. Traduceri

______________________________________________________________________

1. Introducere

Aceste este IPCHAINS-HOWTO pentru Linux; citeste capitolul “De unde?”
pentru site-ul principal care contine ultima veriune. Ar trebui sa citesti
deasemenea NET-3-HOWTO. IP-Masquerading HOWTO, PPP-HOWTO, Ethernet-HOWTO si
Firewall HOWTO ar fi deasemenea interesante de citit (la fel ar putea sa fie
intesante si FAQ-ul alt.fan.bigfoot).

Daca filtrarea de pachete este ok pentru tine, citeste sectiunea “De ce?”,
sectiunea “Cum?”, si citeste printre randuri sectiunea “Reguli pentru
firewall”.

Daca faci trecerea de la ipfwadm, citeste sectiunea “Introducere”,”Cum?”,
anexa “Diferente intre ipchains si ipfwadm” si sectiunea “Folosirea
scriptului ipfwadm-wrapper”.

1.1. La ce foloseste?

Ipchains pentru linux este o rescriere a codului pentru firewall IPv4 pentru
Linux (care a fost in mare preluat de la BSD) si o rescriere a ipfwadm, care
este o rescriere a ipfw apartinand BSD-ului. Ipchains este cerut pentru
administrarea filtrelor de pachete in kernelurile Linux versiunea 2.1.102 si
mai avansate.

1.2. De ce?

Deoarece: codul mai vechi pentru firewall nu intelegea fragmentele, avea
counter-e pe 32 biti (cel putin pe Intel), nu suporta alte protocoale in afara
TCP, UDP si ICMP, nu putea sa realizeze schimbari mari rapid, nu stia sa
specifice reguli inverse, are cateva inflorituri, si poate fi greu de manevrat
(facandu-l predispus la erori din partea utilizatorului).

1.3. Cum?

In mod curent codul pentru filtrarea de pachete este inclus in kernelurile de
la versiunea 2.1.102.. Pentru versiunile 2.0 va trebui sa aplici un patch
pe care il downloadezi de pe pagina web. Daca kernelul 2.0 este mai recent
decat patch-ul respectiv, ar trebui sa mearga; aceasta parte de cod din kernel
este destul de stabila (ex. patch pentru kernel 2.0.34 este bun si pentru
kernel 2.0.35). Deoarece patch-ul pentru ver. 2.0 este incompatibil cu
patch-urile pentru ipportfw si ipautofw, nu recomand aplicarea acestuia decat
in cazul in care ai mare nevoie de functionalitatea oferita de ipchains.

1.4. De unde?

Pagina oficiala poate fi gasita in trei locuri:
Multumiri lui Penguin Computing
Multumiri echipei SAMBA
Multumiri lui Jim Pick .

Exista o lista de discutii pentru rapoarte privind bug-uri, discutii,
dezvoltare si folosire. Subscrie-te pe aceasta lista trimitand la subscribe at
east.balius.com un mesaj avand in corpul mesajului “subscribe ipchains-list”.
Pentru a trimite mail la toti cei care sunt subscrisi pe lista foloseste
adresa ipchains-list at east.balius.com.

2. Bazele teoretice ale filtrarii de pachete

2.1. La ce foloseste?

Intreg traficul dintr-o retea este transmis sub forma de pachete. De exemplu,
downloadarea unui fisier (sa zicem, in marime de 50K) va cauza primirea a in
jur de 36 de pachete cu o marime de 1460 bytes fiecare.

Partea de inceput a oricarui pachet spune unde se duce, de unde a venit, tipul
pachetului, si alte asemenea detalii. Aceasta parte de inceput a pachetului se
numeste header. Restul pachetului care contine informatia propriu-zisa este
numita body (corp).

Unele protcoale, cum ar fi TCP, care este folosit pentru trafic web, mail, si
conectarea de la distanta pe alte sisteme, folosesc termenul de “conexiune” –
inainte de transmiterea oricaror informatii cu date propriu-zise, pachete
diferite (cu headere speciale) sunt schimbate, spunand “Vreau sa ma
conectez”, “OK”, si “Mersi”. Apoi pachete normale sunt schimbate.

Un filtru de pachete este o portiune de cod care se uita la headerul
pachetelor pe masura ce acestea trec, si decid soarta intregului pachet. Poate
sa decida sa ignore pachetul (ignora pachetul ca si cum nu ar fi fost
primit), accepta pachetul (lasa pachetul sa intre), sau sa respinga pachetul
(asemanator cu ignorarea pachetul cu deosebira ca spune sistemului care l-a
trimis acest lucru).

Sub linux, filtrarea de pachete este compilata in kernel, si sunt cateva
smecherii pe care le putem face cu pachetele, dar ramane valabil principiul
general al examinarii headerelor si determinarea sortii pachetului.

2.2. De ce?

Control. Securitate. Vigilenta.

Control:
cand folosesti un sistem Linux pentru a-ti conecta reteaua interna
la o alta retea (sa spunem, Internet) ai posibilitatea de a permite
un anumit tip de trafic, si sa refuzi pe altele. De exemplu,
header-ul contine adresa destinatie a unui pachet, asa ca poti
preveni pachetele sa se duca spre o anumita parte a retelei
exterioare. Ca un alt exemplu, folosesc Netscape pentru accesarea
arhivelor Dilbert. Sunt reclame pe pagina de la doubleclick.net, si
Netscape imi pierde timpul incarcandu-le. Spunand filtrului de pachete
sa nu permita pachete de la sau spre nici una din adresele detinute
de catre doubleclick.net rezolva aceasta problema (cu toate acestea
sunt modalitati mai bune pentru aceasta: vezi Junkbuster).

Securitate:
cand sistemul tau Linux este singurul intre haosul Internetului
si reteaua ta ordonata si delicata, este placut sa stii ca poti
sa restrictionezi ceea ce vine tropaind la usa. De exemplu, poti sa
permiti la tot sa iasa din retea, dar ai putea fi ingrijorat de
binecunoscutul “Ping al Mortii” venind de la persoanele din afara rau
intentionate. Ca un alt exemplu, s-ar putea sa nu doresti ca
persoanele din afara sa se telnet-uiasca pe sistemul tau Linux, chiar
daca toate conturile tale au parole. Poate doresti (ca multi oameni)
sa fii un observator al Internet-ului, si nu server (de voie, sau in
alt mod). Pur si simplu nu lasa pe nimeni sa se conecteze, punand
fitrul de pachete sa respinga pachetele folosite la initierea de
conexiuni.

Vigilenta:
uneori o masina prost configurata in reteaua locala va decide sa
arunce pachete spre lumea din afara. Este dragut sa spui filtrului de
pachete sa te anunte daca se intampla ceva anormal; poate poti face
ceva cu privire la acel lucru, sau poate esti doar curios.

2.3. Cum?

2.3.1. Un kernel ce are compilat suport pentru filtrare de pachete

Ai nevoie de un kernel care sa aiba suport compilat pentru IP firewall chains.
Poti sa iti dai seama daca ai kernelul care iti trebuie verificand existenta
fisierului “/proc/net/ip_fwchains”. Daca acesta exista, este ok.

Daca nu, trebuie sa compilezi un kernel cu suport pentru IP firewall chains.
Intai downloadeaza sursele kernelului pe care il doresti. Daca ai sursele
pentru kernel peste versiunea 2.1.102, inclusiv, nu va fi necesar sa ii aplici
patch. In caz contrar, aplica un patch de pe pagina web listata mai sus, si
realizeaza configuratia cum este detaliat mai jos. Daca nu stii cum sa faci
asta nu intra in panica — citeste Kernel-HOWTO.

Optiunile de configurarea ce trebuie facute pentru kernel ver 2.0 sunt:

______________________________________________________________________
CONFIG_EXPERIMENTAL=y
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_CHAINS=y
______________________________________________________________________

Pentru kernelurile ver. 2.1 sau 2.2:

______________________________________________________________________
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
______________________________________________________________________

Comanda ipchains cumunica kernelului si ii spune ce pachete sa filtreze. Mai
jos este prezentat cum vei realiza filtrarea de pachete.

2.3.2. ipchains

Comanda ipchains introduce si sterge reguli din portiunea din kernel
referitoare la filtrarea de pachete. Aceasta inseamna ca orice vei realiza va
fi pierdut dupa rebootare, citeste “Crearea regulilor permanente” pentru a
vedea cum sa faci regulile permanente.

ipchains inlocuieste ipfwadm, care a fost folosit pentru vechiul cod de
firewall IP. Exista o multime de scripturi folositoare de pe site-ul ftp al
ipchains-ului:

http://netfilter.filewatcher.org/ipchains/ipchains-scripts-1.1.2.tar.gz

Aceasta arhiva contine un script numit ipfwadm-wrapper care iti permite sa
realizezi filtrarea de pachete exact cum era inainte. Probabil ca nu ar trebui
sa folosesti acest scipt in afara de cazul cand doresti o cale rapida de a
upgrada un sistem ce foloseste ipfwadm (este mai incet, nu verifica
argumentele, etc.). In acest caz nu ai nevoie nici de acest HOWTO.

Vezi anexa “Diferente intre ipchains si ipfwadm” si anexa “Folosirea scriptului
ipfwadm-wrapper” pentru mai multe detalii privind ipfwadm.

2.3.3. Crearea regulilor permanente

Regulile curente ale firewall-ului se afla in kernel, si de aceea vor fi
pierdute la rebootare. Recomand folosirea scripturile “ipchains-save” si
“ipchains-restore” pentru a face regulile permanente. Pentru a realiza
aceasta, seteazati regulile, apoi ruleaza (ca root):

# ipchains-save > /etc/ipchains.rules
#

Creaza un script astfel:

#! /bin/sh
# Script to control packet filtering.

# If no rules, do nothing.
[ -f /etc/ipchains.rules ] || exit 0

case “$1″ in
start)
echo -n “Turning on packet filtering:”
/sbin/ipchains-restore < /etc/ipchains.rules || exit 1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo “.”
;;
stop)
echo -n “Turning off packet filtering:”
echo 0 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -F
/sbin/ipchains -X
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward ACCEPT
echo “.”
;;
*)

echo “Usage: /etc/init.d/packetfilter {start|stop}”
exit 1
;;
esac

exit 0

Asigura-te ca acest script este rulat devreme in procesul de incarcare al
sistemului. In cazul meu (Debian 2.1), am facut o legatura simbolica numita
“S39packetfilter” in directorul “/etc/rcS.d” (acesta va fi rulat inainte de
S40network).

3. Sunt derutat! Rutare, masqueradare, forwardare de pachete, ipautofw….

Acest HOWTO este dedicat filtrarii de pachete. Aceasta inseamna a decide ce
pachete sa lasi sa treaca sau nu. Cu toate acestea, Linux-ul fiind terenul de
joaca al hackerilor probabil ca doresti sa realizezi mai multe de atat.

O problema este faptul ca aceeasi comanda “ipchains” este folosita sa
controlezi masqueradingul cat si realizarea de proxy transparent, deasemenea
aceastea sunt diferite fata de filtrarea de pachete (implementarea Linux
curenta le pune una langa celelalte, lasand impresia ca sunt strans
inrudite).

Realizarea de masquerading si proxy transparent sunt detaliate in HOWTO-uri
separate, si auto forwardarea si fowardarea de porturi sunt controlate de
comenzi diferite, dar cum multa lume ma intreaba despre acestea, voi include o
multime de scenarii posibile si voi indica momentul cand trebuie aplicat
fiecare. Meritele de securitate ale fiecarei configuratii nu va fi discutat
aici.

3.1. Ghidul de trei linii al lui Rusty privind masqueradarea

Se presupune ca interfata ta externa este “ppp0″. Foloseste comanda “ifconfig”
pentru a afla interfata, si modifica dupa caz:

# ipchains -P forward DENY
# ipchains -A forward -i ppp0 -j MASQ
# echo 1 > /proc/sys/net/ipv4/ip_forward

3.2. Promovare gratuita: regulile WatchGuard

Poti sa cumperi firewall-uri gata facute. Unul excelent este FireBox de la
WatchGuard. Este excelent pentru ca imi place, este sigur, este bazat pe
Linux, si pentru ca au finantat suportul pentru ipchains cat si pentru noul
cod de firewall (pentru 2.4). Pe scurt, WatchGuard ma platesc pe mine pentru a
avea ce manca in timp ce muncesc pentru voi. Asa ca ia in considere produsul
lor.

http://www.watchguard.com

3.3. Firewall-uri obisnuite

Te ocupi de littlecorp.com. Ai o retea interna, si o conexiune PPP catre
internet (de pe ruterul firewall.littlecorp.com care are adresa 1.2.3.4).
Folosesti ethernet pentru reteaua locala, si sistemul tau se numeste “myhost”.
Sectiunea care urmeaza va ilustra diferite scenarii care sunt obisnuite.
Cititi cu atentie, pentru ca sunt fiecare usor diferite.

3.3.1. Retea privata: Proxy-uri traditionale

In acest scenariu, pachetele din reteaua privata nu vor ajunge pe Internet si
viceversa. Adresele IP pentru reteaua privata ar trebui sa fie asignate din
clasa de IP-uri pentru retele private conform cu RFC1918 (ex: 10.*.*.*,
172.16.*.*-172.31.*.* or 192.168.*.*).

Singurul mod prin care te conecteazi la Internet este prin conectare la
firewall, care este singurul sistem comun celor doua retele, pe care le
conecteaza. Pentru a realiza acest lucru folosesti (pe firewall) o aplicatie
numita proxy (exista proxy-uri pentru FTP, www, telnet, RealAudio, Usenet News
si alte servicii). Citeste Firewall HOWTO.

Orice servicii pe care le doresti accesibile de pe Internet trebuie sa fie pe
firewall. (insa vezi “Servicii interne limitate”).

Exemplu: Permiterea acesului web din reteaua privata catre Internet

1. Reteaua privata are asignate adresele 192.168.1.*, myhost fiind sistemul cu
adresa 192.168.1.100, iar interfata ethernet a firewall-ului avand asignata
adresa 192.168.1.1.

2. Un proxy pentru web (ex. squid) este instalat si configurat pe firewall, sa
spunem ca asculta pe portul 8080.

3. Netscape-ul din reteaua privata este configurat sa foloseasca drept proxy
portul 8080 de pe firewall.

4. DNS nu trebuie sa fie configurat in reteaua privata.

5. DNS trebuie sa fie configurat pe firewall.

6. Nici o ruta default (gateway) nu trebuie sa fie configurata in reteaua
privata.

Netscape de pe myhost citeste http://slashdot.org

1. Netscape se conecteaza la portul 8080 de pe firewall, folosind portul 1050
de pe myhost. Intreaba de pagina web a adresei “http://slashdot.org”.

2. Proxy-ul se uita dupa numele “slashdot.org”, si gaseste 207.218.152.131.
Apoi deschide o conexiune catre acea adresa IP (folosind portul 1025 de pe
interfata externa a firewall-ului), si intreaba serverul web (portul 80) de
pagina web.

3. Pe masura ce primeste pagina web prin conexiunea cu serverul de web,
firewall-ul copiaza informatia catre conexiunea cu Netscape.

4. Netscape afiseaza pagina

Din punctul de vede al slashdot.org, conexiunea este facuta de la 1.2.3.4,
portul 1025 catre 207.218.152.131 (slashdot.org), portul 80. Din punctul de
vedere al myhost conexiunea este realizata de la 192.168.1.100 (myhost),
portul 1050, catre 192.168.1.1 (interfata ethernet a firewall-ului), portul
8080.

3.3.2. Retea privata: Proxy-uri transparente

Singurul mod prin care te conectezi la Internet este prin conectare la
firewall, care este singurul sistem comun celor doua retele, pe care le
conecteaza. In acest scop rulezi o aplicatie (pe firewall) numita proxy
transparent; kernelul schimba destinatia pachetele din reteaua privata care ar
fi trebuit sa fie trimise spre Internet catre proxy-ul transparent. (modifica
rutarea).

Proxy transparent insemna ca hosturile din reteaua privata nu au nevoie sa
shtie ca este implicat un proxy.

Orice servicii pe care le doresti accesibile de pe Internet trebuie sa fie pe
firewall. (insa vezi “Servicii interne limitate”).

Exemplu: Permiterea acesului web din reteaua privata catre Internet

1. Reteaua privata are asignate adresele 192.168.1.*, myhost fiind sistemul cu
adresa 192.168.1.100, iar interfata ethernet a firewall-ului avand asignata
adresa 192.168.1.1.

2. Un proxy de web transparent (cred ca sunt patch-uri pentru squid, pentru ai
permite sa lucreze in acest mod, sau incerca “transproxy”) este instalat si
configurat pe firewall, sa spunem ca asculta pe portul 8080.

3. Kernelului ii este spus, folosind ipchains, sa redirecteze conexiunile
catre portul 80 spre proxy.

4. Netscape din reteaua privata este configurat sa se conecteze direct.

5. DNS trebuie sa fie configurat in reteaua privata (trebuie sa rulezi un
server DNS pentru reteaua locala, ca un proxy, pe firewall).

6. Ruta default (gateway) trebuie sa fie configurata in reteaua privata,
pentru a trimite pachetele catre firewall.

Netscape de pe myhost citeste http://slashdot.org.

1. Netscape rezolva numele “slashdot.org” in adresa 207.218.152.131. Apoi
deschide o conexiune catre aceea adresa folosind portul local 1050, si
cere serverului de web (portul 80) pagina web.

2. Pe masura ce pachetele de la myhost (portul 1050) catre slashdot.org
(portul 80, trec prin firewall, ele sunt redirectate catre proxy-ul
transparent ce asculta pe portul 8080. Proxy-ul transparent deschide o
conexiune (folosind portul local 1025) catre 207.218.152.131, portul 80 (care
este adresa reala catre care se indreptau pachetele originale).

3. Pe masura ce primeste pagina web prin conexiunea cu serverul de web,
firewall-ul copiaza informatia catre conexiunea cu Netscape.

4. Netscape afiseaza pagina.

Din punctul de vedere al slashdot.org, conexiunea este facuta de la 1.2.3.4
(interfata PPP a firewall-ului), portul 1025 catre 207.218.152.131
(slashdot.org), portul 80. Din punctul de vedere al myhost conexiunea este
realizata de la 192.168.1.100 (myhost), portul 1050, catre 207.218.152.131
(slashdot.org) portul 80, dar defapt vorbeste cu proxy-ul transparent.

3.3.3. Retea privata: Masquerading

In acest scenariu, pachetele din reteaua privata nu vor ajunge pe Internet
fara o modificare in prealabil si viceversa. Adresele IP pentru reteaua
privata ar trebui sa fie asignate din clasa de IP-uri pentru retele private
conform cu RFC1918 (ex: 10.*.*.*, 172.16.*.*-172.31.*.* sau 192.168.*.*).

In loc sa folosim un proxy, folosim o facilitate speciala a kernelului numita
“masquerading”. Masqueradarea recreeaza pachetele pe masura ce acestea trec
prin firewall, in asa fel incat intodeauna par ca vin de la insusi firewall-ul.
Apoi rescrie raspunsurile in asa fel incat apar ca si cum ar veni de la insasi
destinatia originala.

Masquerading are module speciale pentru unele protocoale mai speciale, cum ar
fi FTP, RealAudio, Quake, etc. Pentru protocoale pentru care nu se poate
realiza acest lucru, facilitatea “forwardare automata” care poate manipula
unele dintre aceste protocoale prin realizarea automata de forwardare pentru
porturile necesare. Vezi “ipportfw” (kernelurile 2.0) sau “ipmasqadm”
(kernelurile 2.1).

Orice servicii pe care le doresti accesibile de pe Internet trebuie sa fie pe
firewall. (insa vezi “Servicii interne limitate”).

Exemplu: Permiterea accesului la web din reteaua privata catre Internet.

1. Adresa privata are asignate adresele 192.168.1.*, myhost fiind sistemul cu
adresa 192.168.1.100, iar interfata ethernet a firewall-ului avand asignata
adresa 192.168.1.1.

2. Firewall-ul este configurat sa realizeze masquerading pentru pachetele care
pleaca din reteaua privata spre Internet, portul 80.

3. Netscape este configurat sa se conecteze direct.

4. DNS trebuie configurat corect in reteaua privata.

5. Firewall-ul ar trebui sa fie ruta default (gateway) pentru reteaua privata.

Netscape de pe myhost citeste http://slashdot.org

1. Netscape rezolva numele “slashdot.org” in adresa IP 207.218.152.131. Apoi
deschide o conexiune catre acea adresa IP, folosind portul local 1050, si cere
serverului de web (portul 80) pagina web.

2. Pe masura ce pachetele de la myhost (portul 1050) catre slashdot.org
(portul 80) trec prin firewall, acestea sunt rescrie pentru a parea ca vin de
pe interfata PPP a firewall-ului, portul 65000. Firewall-ul are o adresa
internet valida (1.2.3.4) asa ca pachetele replica de la slashdot.org sunt
rutate inapoi corect.

3. Pe masura ce pachetele de la slashdot.org (portul 80) sunt rutate inapoi
catre firewall.littlecorp.com (portul 65000), acestea sunt rescrise pentru a
se inapoia catre myhost, portul 1050. Aceasta este reala magie a
masqueradingului: tine minte cand rescrie pachetele ce ies pentru ca sa poata
rescrie pachetele replica pe masura ce acestea vin.

4. Netscape afiseaza pagina.

Din punctul de vedere al slashdot.org, conexiunea este realizata de la adresa
IP 1.2.3.4 (interfata PPP a firewall-ului) portul 65000, catre
207.218.152.131 (slashdot.org) portul 80.

3.3.4. Retea publica

In acest scenariu, reteaua ta personala este parte din Internet: pachetele
pot sa circule fara nici o modificare intre ambele retele. Adresele IP ale
retelei interne trebuie sa fie asignate printr-o cerere pentru un bloc de
adrese IP, astfel incat restul Internetului sa stie cum sa ruteze pachetele
catre aceasta. Aceasta implica o conexiune permanenta.

In acest caz, filtrul de pachete este folosit pentru a decide ce pachete sa fie
forwardate intre reteaua ta si restul Internetului, de exemplu sa permiti
restului Internetului accesul numai la serverele interne de web.

Exemplu: Permiterea accesului web din reteaua personala catre Internet

1. Reteaua interna are adresele IP asignate conform cu blocul de adrese IP pe
care le-ai inregistrat. (sa zicem 1.2.3.*)

2. Firewall-ul este configurat sa permita traficul.

3. Netscape este configurat sa se conecteze direct.

4. DNS trebuie sa fie corect configurat in reteaua ta.

5. Firewall-ul trebuie sa fie ruta default (gateway) pentru reteaua ta.

Netscape de pe myhost citeste http://slashdot.org

1. Netscape rezolva numele “slashdot.org” in adresa IP 207.218.152.131.
Deschide apoi o conexiune catre aceea adresa IP, folosind portul local 1050,
si cere serverului de web (portul 80) pagina web.

2. Pachetele trec prin firewall-ul tau la fel cum trec prin multe alte rutere
intre tine si slashdot.org.

3. Netscape afiseaza pagina.

Exista doar o singura conexiune: de la 1.2.3.4 (myhost) portul 1050, la
207.218.152.131 (slashdot.org) portul 80.

3.3.5. Servicii interne limitate

Sunt cateva lucruri pe care le poti intreprinde pentru a permite accesul din
afara Internetului catre servicile interne, decat sa rulezi acele servici pe
firewall. Aceast lucru este posibil printr-o solutie pentru conexiunile
externe in gen proxy sau masquerading.

Cea mai simpla abordare este sa rulezi aplicatia “redirector”, care este un
proxy care asteapta o conexiune pe un port dat, si apoi deschide o conexiune
interna catre un host intern, pe un anumit port, si copiaza datele intre cele
doua conexiuni. Din punctul de vedere al Internetului, conexiunea este facuta
pe firewall. Din punctul de vedere al serverului intern, conexiunea este
facuta intre interfata interna a firewall-ului si serverul intern.

O alta cale (care, pentru kernel ver. 2.0 este necesar un patch pentru
ipportwf, sau un kernel versiunea 2.1 sau peste) este sa folosesti forwardarea
de porturi din kernel. Aceasta realizeaza acelasi lucru ca “redirector”
intr-un mod diferit: kernelul rescrie pachetele pe masura ce ele trec,
schimbandu-le adresa si portul destinatie catre un host si port anumit din
reteaua interna. Din punctul de vedere al Internetului conexiunea este facuta
cu firewall-ul. Din punctul de vedere al serverului intern, conexiunea este
una directa intre serverul intern si hostul din Internet.

3.4. Mai multe informatii despre masquerading

David Ranch a scris un excelent nou HOWTO despre masquerading, care se
suprapune mult peste acest HOWTO. Poti sa gasesti acest HOWTO la

http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html

Pagina oficiala pentru Masquerading este la:

http://ipmasq.cjb.net

4. Filtrul de pachete

Aceasta sectiune descrie tot ceea ce trebuie sa stii cu adevarat pentru a
realiza un filtru de pachete ca sa iti indeplineasca cerintele.

4.1. Cum travereseaza pachetele filtrele

Kernelul porneste cu trei liste de reguli; aceste liste se numesc chain-uri.
Aceste trei chain-uri incluse default sunt: input, output si forward. Cand un
pachet soseste (sa zicem, prin placa Ethernet) kernelul foloseste chain-ul
input pentru a decide soarta pachetului. Daca trece de acest chain, kernelul
decide unde sa trimita pachetul (aceasta este numita rutare). Daca este
destinat pentru o alta masina, pachetul trece prin chain-ul forward. In final,
chiar inainte ca un pachet sa plece, kernelul verifica chain-ul output.

Un chain este o lista cu reguli ce trebuie verificate. Fiecare regula spune
“daca headerul pachetului arata asa, atunci iata ce sa faci cu pachetul”. Daca
regula nu se potriveste cu pachetul, atunci urmatoarea regula din chain este
examinata. In final, daca nu mai exista reguli de verificat, atunci kernelul
verifica politica (policy-ul) pe care o are chain-ul. Intr-un sistem in care
se pune baza pe securitate, de obicei politica este sa ignore pachetul sa sa
ii dea reject.

Pentru fanii ASCII, aceasta este calea pe care o parcurge un pachet:

—————————————————————-
| ACCEPT/ interfata lo |
v REDIRECT _______ |
–> C –> S –> ______ –> D –> ~~~~~~~~ –>|Chain-ul|—> _________–>
h a |Chain-ul| e {Decizie } |forward | |Chain-ul |ACCEPT
e n |input | m {de rutare} |________|—>|output |
c i |________| a ~~~~~~~~ | | ->|_________|
k t | s | | | | |
s y | q | v | | |
u | v e v DENY/ | | v
m | DENY/ r Proces Local REJECT | | DENY/
| v REJECT a | | | REJECT
| DENY d ——————— |
v e —————————–
DENY

Iata o descriere a fiecarui pas:

Checksum: Acesta este un test pentru a vedea daca pachetul a fost corupt in
vreun fel. Daca da, atunci este ignorat.

Normalitate (sanity): Acest test defapt exista inainte fiecarui chain, dar
acela care se face inainte chain-ului input este cel mai important. Pachetele
malformate ar putea sa incurce codul de verificare al regulilor, aceastea sunt
ignorate aici (daca acest lucru se intampla, un mesaj este trimis catre
syslog).

Chain-ul input: Acesta este primul chain din firewall unde pachetul va fi
verificat. Daca decizia chain-ului nu este DENY (ignora) sau REJECT, pachetul
isi continua drumul.

Demasquerade:Daca pachetul este o replica la un pachet asupra caruia a fost
realizata masquerading, se realizeaza asupra acestuia demasquradare, iar apoi
se indreapta direct catre chain-ul output. Daca nu folosesti Masquerading IP,
poti sa stergi mental aceasta din diagrama.

Decizie de rutare: Campul privind destinatia este examinat de catre codul ce
realizeaza rutarea, pentru a decide daca pachetul trebuie sa se indrepte catre
un proces local (vezi “Procesul local” de mai jos) sau forwardat catre o
masina la distanta (vezi “Chain-ul forward” de mai jos).

Procesul local: Un proces ruland pe masina poate primi pachete dupa pasul
deciziei privind rutarea pachetelor, si poate trimite pachete (care trec prin
pasul deciziei rutarii, apoi travereseaza chain-ul output)

Interfata lo: Daca pachetele unui proces local, sunt destinate pentru un
proces local, acestea vor iesi prin chain-ul output cu interfata setata “lo”,
apoi se vor intoarce prin chain-ul input cu interfata deasemenea “lo”.
Interfata “lo” este numita interfata loopback.

local: daca pachetul nu a fost creat de un proces local, atunci chain-ul
forward este verificat, in caz contrar pachetul se duce catre chain-ul output.

Chain-ul forward: Acest chain este traversat de orice pachet care incearca sa
treaca prin aceasta masina catre alta.

Chain-ul output: Acest chain este traversat de toate pachetele chiar inainte
de a iesi.

4.1.1. Folosirea ipchains

In primul rand, asigurate ca ai versiunea de ipchains la care se refera acest
document.

$ ipchains –version
ipchains 1.3.9, 17-Mar-1999

Observatie: recomand 1.3.4 (care nu are optiuni in format lung, cum ar fi
“–sport”), 1.3.8 sau mai avansate; acestea fiind foarte stabile.

ipchains are o destul de detaliata pagina de manual (man ipchains), si daca
ai nevoie de mai multe detalii in particular, poti sa verifici interfata
pentru programare (man 4 ipfw), sau fisierul net/ipv4/ip_fw.c in sursele
kernelului 2.1.x, care este (bineinteles) o sursa de incredere.

Mai exista deasemenea o fisa de referinta rapida creata de catre Scott Bronson
in arhiva surselor, in format US Letter PostScript(TM) si A4.

Sunt mai multe lucruri diferite pe care le poti face cu ipchains. In primul
rand comenzi prin care poti administra un chain intreg. Incepi cu trei
chain-uri compilate default pe care nu le poti sterge: input, output si
forward.

1. Creaza un chain nou (-N).
2. Sterge un chain gol (-X).
3. Schimba policy-ul (politica) pentru unul din chain-urile default (-P).
4. Listeaza regulile dintr-un chain (-L).
5. Sterge regulile dintr-un chain (-F)
6. Reseteaza counter-ele pentru pachete si bytes pentru toate regulile
dintr-un chain (-Z).

Sunt mai multe moduri de a manipula regulile dintr-un chain:

1. Adauga o noua regula intr-un chain (-A).
2. Introduce o noua regula la o pozitia anumita intr-un chain (-I) (default
adauga la inceput).
3. Inlocuieste o regula la o anumita pozitie din chain (-R).
4. Sterge o regula la o anumita pozitie din chain (-D).
5. Sterge prima regula care se potriveste din chain (-D).

Sunt cateva operatii si pentru masquerading:

1. Listeaza conexiunile pentru care se fac in mod curent masquerading
(-M -L).
2. Stabileste valori de timeout pentru masquerading (-M -S). (Dar citeste si
“Nu pot preciza valori de timeout pentru masquerading!”)

Ultima (si poate cea mai folositoare) functie iti permite sa verifici ce s-ar
intampla cu un pachet dat daca ar traversa un chain dat.

4.1.2. Ce vei vedea cand porneste computerul

Inainte de rularea oricarei comenzi ipchains (fii atent, unele distributii
ruleaza ipchains in scripturile de initializare), nu vor exista nici un fel de
reguli in nici unul dintre chain-urile incluse default (“input”, “output” si
“forward”), si fiecare din aceste chain-uri va avea un policy de ACCEPT.
Aceasta inseamna ca nu exista filtrare de pachete.

4.1.3. Operatii pentru o singura regula

Acesta este unul dintre cele mai importante lucruri; manipularea regulilor.
Cel mai obisnuit, vei folosi probabil comenzile de adaugare (-A) si de
stergere (-D). Celelalte (-I pentru introducere si -R pentru inlocuire) sunt
doar prelungiri ale comenzilor precedente.

Fiecare regula specifica o multime de conditii pe care un pachet trebuie sa le
indeplineasca, si ce sa faca daca regulile sunt indeplinite (o “tinta”). De
exemplu, s-ar putea sa doresti sa ignori toate pachetele ICMP venind de la
adresa 127.0.0.1. Deci, in acest caz conditiile sunt ca protocolul sa fie
ICMP si adresa sursa sa fie 127.0.0.1. Tinta noastra este “DENY”.

127.0.0.1 este interfata “loopback”, care exista chiar daca nu ai legatura
reala la o retea. Poti folosi programul “ping” pentru a genera acest tip de
pachete (pur si simplu trimite pachete ICMP de tip 8 (echo request) la care
toate host-urile ar trebui sa raspunda cu pachete ICMP de tip 0 (echo replay)). Aceast program este foarte folositor pentru teste.

# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

— 127.0.0.1 ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# iptables -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

— 127.0.0.1 ping statistics —
1 packets transmitted, 0 packets received, 100% packet loss
#

Poti vedea aici ca primul ping reuseste (“-c 1″ spune sa sa trimita doar un
singur pachet).

Apoi adaugam in coada (-A) chain-ului “input”, o regula ce spune ca
pentru pachetele de la 127.0.0.1 (“-s 127.0.0.1″) de tip ICMP (“-p icmp”)
trebuie sa sarim la “DENY” (“-j DENY”).

Apoi testam regula noastra, folosind al doilea ping. Va fi o pauza pana cand
programul se da batut sa astepte un raspuns care nu va veni niciodata.

Am putea sa stergem regula in doua moduri. Intai, deoarece stim ca este
singura regula din chain-ul input, putem folosi o stergere numarata, ca
in:

# iptables -D input 1
#

Pentru a sterge regula cu numarul 1 din chain-ul input.

Al doilea mod este sa scriem comanda prin care am introdus regula -A, dar sa
inlocuim -A cu -D. Aceasta este folositor cand ai un chain complex de reguli
si nu doresti sa le numeri ca sa iti dai seama ca este a 37-a regula de
care vrei sa scapi. In aces caz, vom folosi:

# ipchains -D input -s 127.0.0.1 -p icmp -j DENY
#

Sintaxa comenzii -D trebuie sa aiba exact aceleasi optiuni cum are comanda -A
(sau -I, sau -R). Daca sunt reguli identice in acelasi chain, numai prima
regula va fi stearsa.

4.1.4. Optiuni de filtrare

Am vazut folosirea optiunii “-p” pentru a specifica protocolul, si optiunii
“-s” pentru a specifica adresa sursa, dar sunt alte optiuni pe care le putem
folosi pentru a preciza caracteristici ale pachetului. Ceea ce urmeaza este
un compedium complet.

4.1.4.1. Specificarea adreselor IP sursa si destinatie

Adresele IP ale sursei (“-s”) si destinatiei (“-d”) pot fi specificate in
patru moduri. Cea mai obisnuita forma este sa folosesti numele complet, cum
ar fi “localhost” sau “www.securityorg.net”. Cea de-a doua cale este sa
specifici adresa IP cum ar fi “127.0.0.1″.

Cea de a treia si a patra cale permite specificarea unui grup de adrese IP,
cum ar fi “199.95.207.0/24″ sau “199.95.207.0/255.255.255.0″. Amandoua
specifica orice adresa IP de la 199.95.207.0 pana la 199.95.207.255 inclusiv;
cifrele dupa “/” spun care parti din adresa IP sunt semnificative. “/32″ sau
“/255.255.255.255″ este default (se potriveste cu toata adresa IP). Pentru a
specifica oricare adresa IP “/0″ poate fi folosit, astfel:

# ipchains -A input -s 0/0 -j DENY
#

Aceasta este folosit in mod rar, deoarece efectul de mai sus este asemanator
cu nespecificare deloc a optiunii “-s”.

4.1.4.2. Specificarea inversa

Multe optiuni, inclusiv optiunile “-s” si “-d” pot avea argumentele precedate
de “!” (pronuntat “nu”) pentru a corespunde adreselor care NU sunt egale cu
adresele date. De exemplu, “-s ! localhost” corespunde oricarui pachet care
nu vine de la localhost.

4.1.4.3. Specificarea protocolului

Protocolul poate fi specificat prin optiunea “-p”. Protocolul poate fi un
numar ( daca stii valorile numerice de protocol pentru IP) sau un nume pentru
cazurile speciale de “TCP”, “UDP” sau “ICMP”. Nu conteaza daca se foloseste
sau nu CAPS, asa ca “tcp” merge la fel ca si “TCP”.

Numele protocolului poate fi precedat de “!”, pentru a inversa, ca si “-p !
tcp” pentru a specifica pachetele care nu sunt TCP.

4.1.4.3.1. Specificarea porturilor TCP si UDP

Pentru cazul special cand este specificat un protocol TCP si UDP, poate fi
precizat un argument in plus insemnand portul TCP sau UDP, sau un sir
(inclusiv capetele sirului) de porturi (citeste insa mai jos “Despre
fragmente”). Un sir este reprezentat prin caracterul “:”, cum ar fi
“6000:6010″ care acopera 11 numere de porturi, de la 6000 la 6010 inclusiv.
Daca limita de jos este omisa, atunci este considerata 0. Daca limita de sus
este omisa, atunci este considerata 65535. Deci, pentru a specifica
conexiunile TCP venind de la porturile sub 1024, sintaxa ar fi urmatoarea
“-p TCP -s 0.0.0.0/0 :1023″. Numerele de porturi pot fi specificate si prin
nume, exemplu “www”.

Observatie: sensul regulii poate fi inversat si in cazul porturilor daca se
pune in fata acestui argument semnul “!”. Deci, pentru a specifica orice
pachet care este pachet TCP dar nu este WWW, ai scrie astfel:

-p TCP -d 0.0.0.0/0 ! www

Este important sa realizezi ca

-p TCP -d ! 192.168.1.1 www

este foarte diferit de

-p TCP -d 192.168.1.1 ! www

Prima regula se potriveste cu toate pachetele care sunt de tip TCP, spre
portul 80 si care nu au ca destinatie adresa 192.168.1.1. Iar, cea de a doua
regula se potriveste cu toate pachetele de tip TCP care au ca destinatie
192.168.1.1, fara sa fie spre portul 80.

In sfarsit, pentru regula urmatoare se potrivesc pachetele care nu au ca
destinatie adresa 192.168.1.1 si nici portul 80.

-p TCP -d ! 192.168.1.1 ! www

4.1.4.3.2. Specificarea tipului si codului ICMP

Cand este precizat tipul de protocol ICMP, exista deasemenea argumente ce pot
fi precizate in plus. ICMP nu are porturi. ICMP are un tip si un cod.

Poti sa le specifici folosind nume ICMP (vezi ipchains -h icmp pentru a lista
aceste nume) dupa optiunea “-s”, sau ca numere insemnand tipul ICMP si codul,
unde tipul urmeaza dupa optiunea “-s”, iar codul dupa optiunea “-d”.

Numele ICMP sunt destul de lungi: trebuie sa folosesti doar destul de multe
litere astfel incat sa se deosebeasca unele de altele.

Iata o mica tabela pentru cele mai intalnite tipuri de pachete ICMP:

Numar Nume Cerut de catre

0 echo-reply ping
3 destination-unreachable Any TCP/UDP traffic.
5 redirect routing if not running routing daemon
8 echo-request ping
11 time-exceeded traceroute

Observatie: numele ICMP nu pot fi precedate deocamdata de semnul “!”.

Sub nici o forma sa nu blochezi toate pachetele ICMP de tip 3! Citeste mai jos
“Pachete icmp”.

4.1.4.4. Specificarea interfetei

Optiunea “-i” specifica numele interfatei cu care sa corespunda. O interfata
este dispozitivul fizic prin care intra pachetul sau prin care iese pachetul.
Poti folosi comanda ifconfig pentru a lista interfetele care sunt “sus”.
(in stare de functionare in acel moment).

Interfata pentru pentru pachete ce sosesc (pachetele ce traverseaza chain-ul
input) este considerata interfata prin care au intrat. In mod logic, interfata
pentru pachetele care pleaca (pachetele ce traverseaza chain-ul output) este
interfata prin care vor iesi. Interfata pentru pachetele ce traverseaza
chain-ul forward este deasemenea interfata prin care vor iesi pachetele.

Este perfect valabil sa specifici o interfata care nu exista;
regula nu se va potrivi cu nici un pachet pana cand interfata nu este sus.
Aceasta este extrem de folositor pentru legaturi PPP de dial-up (de obicei
interfete ppp0) si asemanatoare.

Ca un caz special, un nume de interfata terminandu-se cu “+” se va potrivi cu
toate interfetele (fie ca exista sau nu) care incep cu acel sir de caractere.
De exemplu pentru a specifica o regula care sa se potriveasca tuturor
interfetelor PPP, optiunea -i ppp+ ar fi folosita.

Numele interfetei poate fi precedata de “!”, pentru a corespunde cu pachetul
care nu se potriveste cu intefata specificata.

4.1.4.5. Specificarea doar a pachetelor TCP SYN

Uneori este folositor sa permiti conexiunile TCP intr-o singura directie, nu
si in cealalta. De exemplu, ai putea sa permiti conexiuni catre un server
extern WWW, dar nici o conexiune de la acel server.

Naiv ar fi sa blochezi pachetele TCP dinspre server. Din pacate, conexiunile
TCP cer ca pachetele sa circule in ambele directii.

Solutia ar fi sa blochezi numai pachetele folosite pentru a initia
conexiuni. Aceste pachete sunt numite pachete SYN (ok, tehnic sunt pachete cu
flag SYN pus si cu flagurile RST si ACK nepuse, dar le numim pe scurt
pachete SYN). Prin ignorarea acestor pachete, putem sa oprim aceste
conexiuni.

Optiunea “-y” este folosita pentru aceasta; este valida numai pentru
regulile in care specificam tcp ca protocol. De exemplu, pentru a specifica
incercarile de conexiune de la 192.168.1.1:

-p TCP -s 192.168.1.1 -y

Aceasta optiune poate fi inversat prin precedarea “-y” cu semnul “!”, care se
potriveste pentru toate pachetele care nu initiaza conexiuni.

4.1.4.6. Despre fragmente

Uneori un pachet este prea mare pentru a incape cu totul pe conexiune. Cand
aceasta se intampla, pachetul este divizat in fragmente, si trimis ca pachete
multiple. Celalalt capat reansambleaza aceste fragmente pentru a construi
intregul pachet.

Problema cu fragmentele este ca unele dintre argumentele descrise mai sus (in
particular portul sursa, portul destinatie, tipul ICMP, codul ICMP, flagul syn
TCP) cere kernelului sa verifice inceputul pachetului, care exista numai in
primul pachet.

Daca sistemul tau este singura conexiune catre o retea externa, atunci poti
spune kernelului Linux sa reansambleze toate pachetele care trec prin el, prin
compilarea kernelului cu optiunea “IP: always defragment set” egala cu “Y”.

In caz contrar, este important sa stii cum sunt tratate fragmentele de catre
regulile de filtrare. Orice regula de filtrare care cere informatii pe care
nu le avem nu se va potrivi. Aceasta inseamna ca primul fragment este tratat
ca orice alt pachet. Al doilea si urmatoarele nu vor mai fi. De aceea o
regula -p tcp -s 192.168.1.1 www (specificand un port sursa “www”) nu se vor
potrivi cu un fragment (altul decat primul). Nici regula opusa nu va face
acest lucru -p TCP -s 192.168.1.1 ! www.

Oricum, poti sa specifici o regula special pentru fragmentul al doilea si
urmatoarele, folosind optiunea “-f”. Evident, nu este corect sa specifici
porturi TCP sau UDP, tip ICMP, cod ICMP, sau flag syn TCP, intr-o asemenea
regula cu referire la fragmente.

Este de asemenea legal sa specifici ca o regula nu se aplica la al doilea si
urmatoarele fragmente, prin precedarea lui “-f” cu “!”.

De obicei este considerat sigur sa lasi sa treaca al doilea si urmatoarele
fragmente, deoarece filtrarea va afecta primul fragment, si de aceea previne
reansamblarea pe calculatorul destinatie; cu toate acestea, sunt cunoscute
bug-uri care permit caderea sistemului doar prin simpla trasnmitere de
fragmente. Este decizia ta.

Nota pentru network-heads: pachetele cu malformatii (pachete TCP, UDP si
ICMP prea scurte codului de firewall ca sa citeasca tipul portului sau codul
ICMP si tipul) sunt tratate ca fragmente de asemenea. Doar fragmentele TCP
care incep de la pozitia 8 sunt ignorate de catre kernel (un mesaj este trimis
catre syslog, daca acest lucru se intampla). De exemplu, urmatoarea regula va
ignora toate fragmentele ce au ca destinatie 192.168.1.1:

# ipchains -A output -f -d 192.168.1.1 -j DENY
#

4.1.5. Efectele filtrarii de pachete

Acum stim toate modurile in care putem sa folosim o regula pentru a se potrivi
anumitor pachete. Daca un pachet se potriveste cu o regula, urmatoarele
lucruri se intampla:

1. Counter-ul de byte pentru acea regula creste cu o valoare egala cu
marimea pachetului (header si restul pachetului)
2. Counter-ul de pachete pentru acea regula este incrementat.
3. Daca regula o cere, informatii despre pachet sunt scrise in fisierele de
log.
4. Daca regula o cere, TOS al pachetului este schimbat.
5. Daca regula o cere, pachetul este marcat (acest lucru nu este posibil in
kernelurile ver. 2.0).
6. Tinta regulii este examinata pentru a decide soarta acelui pachet.

Pentru varietate le voi examina in ordinea importantei.

4.1.5.1. Specificarea unei tinte

O tinta spune kernelului ce sa faca pachetului care se potriveste unei
reguli. ipchains foloseste “-j” (in sensul “sare la”) pentru argumentul
tintei. Numele tintei trebuie sa fie mai mic decat 8 caractere, si conteaza
daca este scris cu litere mici sau mari: “RETURN” sau “return” sunt lucruri
diferite.

Cel mai simplu caz este atunci cand nu este nici o tinta specificata. Acest
tip de regula (numita uneori “accounting rule”) este folositoare cand dorim
sa avem o evidenta a numarului de pachete care indeplinesc anumite conditii.
Chiar daca se potriveste sau nu kernelul examineaza urmatoarea regula din
chain. De exemplu, pentru a numara pachetele care vin de la 192.168.1.1:

# ipchains -A input -s 192.168.1.1
#

(Folosind “ipchains -L -v” putem vedea counter-ele de pachete si bytes
asociate fiecarei reguli.)

Exista sase tinte speciale. Primele trei sunt destul de simple: ACCEPT,
REJECT si DENY. ACCEPT lasa pachetul sa treaca. DENY ignora pachetul ca si
cand nu ar fi fost primit. REJECT ignora pachetul, insa (daca nu a fost un
pachet ICMP) trimite un pachet replica ICMP catre sursa care spune ca
destinatia nu poate fi atinsa (destination unreachable).

Urmatoarea regula, MASQ spune kernelului sa masqueradeze pachetul. Pentru ca
aceasta tinta sa poate fi folosita trebuie sa fie compilat kernelul cu suport
pentru “IP Masquerading”. Pentru detalii privind masquerading citeste
Masquerading-HOWTO si anexa “Diferente intre ipchains si ipfwadm”. Aceasta
tinta este corecta numai pentru pachetele ce traverseaza chain-ul forward.

O alta tinta importnta este REDIRECT care comunica kernelului sa trimita un
pachet catre un port local in loc de destinatia spre care se indrepta.
Aceasta poate fi specificata doar pentru regulile in care se specifica
protocolul TCP sau UDP. Optional, poate fi specificat un port, sub forma de
nume sau numar, in continuare la “-j REDIRECT” care va determina ca pachetul
sa fie redirectat catre un anumit port, nu spre portul spre care se indrepta.
Aceasta tinta este valabila doar pentru pachetele ce traverseaza chain-ul
input.

Ultima tinta este RETURN, care este similar cu ajungerea pachetului direct la
sfarsitul chain-ului (citeste “Setarea policy-ului” de mai jos).

Orice alta tinta indica un chain definit de catre utilizator (cum este descris
in “Operatii pentru un chain” de mai jos). Pachetul va incepe traversarea
regulilor in acel chain. Daca acel chain nu decide soarta pachetului, odata
traversarea terminata in acel chain, traversarea este continuata de la
urmatoarea regula din chain-ul anterior.

Considera doua chain-uri: input (chain-ul predefinit) si test (un chain
definit de catre utitlizator).

`input’ `Test’
—————————- —————————-
| Rule1: -p ICMP -j REJECT | | Rule1: -s 192.168.1.1 |
|————————–| |————————–|
| Rule2: -p TCP -j Test | | Rule2: -d 192.168.1.1 |
|————————–| —————————-
| Rule3: -p UDP -j DENY |
—————————-

Considera un pachet TCP venind de la 192.168.1.1 si ducandu-se catre 1.2.3.4.
Acesta intra in chain-ul INPUT. Rule1 nu se potriveste cu el, Rule2 se
potriveste asa ca urmatoarea regula care este examinata este prima din
chain-ul test. Rule1 se potriveste dar nu este specificata nici o tinta,
asa ca urmatoarea regula este examinata. Rule2 nu se potriveste asa ca am
ajuns la sfarsitul chain-ului. Astfel ne reintoarcem in chain-ul INPUT, unde
am examinat Rule2, asa ca examinam Rule3 care nici aceasta nu se potriveste.

Deci calea urmata de catre pachet este:

v __________________________
`input’ | / `Test’ v
————————|–/ ———————–|—-
| Rule1 | /| | Rule1 | |
|———————–|/-| |———————-|—|
| Rule2 / | | Rule2 | |
|————————–| ———————–v—-
| Rule3 /–+___________________________/
————————|—
v

Citeste sectiunea “Cum sa iti organizezi regulile firewall-ului” pentru
modalitati efective de a folosi chain-uri definite de catre utilizator.

4.1.5.2. Logarea pachetelor
(nt. log= jurnal,logare=scriere in fisiere de log)

Aceasta este un efect secundare pe care il poate avea faptul ca un pachet sa
se potriveasca cu o regula, poti sa decizi ca informatii despre pachetul
respectiv sa fie scris in fisierele de log prin folosirea optiunii “-l”. In
mod normal nu vei dori acest lucru pentru pachetele normale, dar aceasta este
o optiune folositoare in cazul unor anumite pachete.

Kernelul scrie aceste informatii astfel:

Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
L=34 S=0×00 I=18 F=0×0000 T=254

Mesajul din loguri este special conceput concis, continand informatii
folositoare. Contine urmatoarele:

1. “input” este chain-ul care a continut regula care s-a potrivit cu pachetul,
cauzand mesajul din loguri.

2. “DENY” este ceea ce a decis regula privind soarta pachetului. Daca aceasta
este “-” atunci regula nu a afectat deloc pachetul (o regula de
contabilizare).

3. “eth0″ este numele interfetei. Cum pachetul a fost logat in chain-ul input,
inseamna ca “eth0″ este numele interfetei de intrare.

4. “PROTO=17″ insemna ca pachetul apartine protocolului 17. O lista cu
numerele de protocoale este data in fisierul “/etc/protocols”. Cele mai
intalnite sunt 1 (ICMP), 6 (TCP) si 17 (UDP).

5. “192.168.2.1″ este sursa IP al pachetului.

6. “:53″ reprezinta portul sursa al pachetului. Uitandu-ne in fisierul
“/etc/services” vedem ca acest numar corespunde portului “domain” (probabil ca
este un pachet replica de la serverul DNS). Pentru TCP si UDP, acest numar
reprezinta portul sursa. Pentru ICMP, este tipul ICMP. Pentru alte protocoale
va fi 65535.

7. “192.168.1.1″ este adresa IP destinatie.

8. “:1025″ inseamna ca portul destinatie este 1025. Pentru UDP si TCP acesta
reprezinta portul destinatie. Pentru ICMP reprezinta codul. Pentru altele va
fi 65535.

9. “L=34″ inseamna ca pachetul este in marime totala de 34 bytes.

10. “S=0×00″ reprezinta tos (type of service). Imparte la 4 aceasta valoare
pentru a avea tos in formatul folosit de catre ipchains.

11. “I=18″ reprezinta IP ID.

12. “F=0×0000″ reprezinta offset-ul de fragment pe 16 biti plus flaguri. O
valoare ce incepe cu “0×4″ sau “0×5″ inseamna ca bit-ul “Don’t Fragment”
este pus. “0×2″ sau “0×3″ inseamna ca bitul “More Fragments” este pus;
asteapta-te sa urmeze fragmente dupa acesta. Restul numarului reprezinta
offsetul pentru acest fragment, impartit la 8.

13. “T=254″ reprezinta Time To Live (ttl, timpul de existenta) al pachetului.
Aceasta valoare este decrementata la fiecare link pe care il trece, si incepe
deobicei la 15 sau 255.

14. “(#5)” in kernelurile mai recente (versiunile peste 2.2.9, inclusiv)
reprezinta numarul reguli care a determinat mesajul.

Pe sisteme standard Linux, mesajul kernelului este preluat de klogd (daemonul
de logare al kernelului) care paseaza mai departe mesajul catre syslogd
(deamonul pentru logare al sistemului). Fisierul “/etc/syslog.conf”
controleaza comportamentul deamonului syslogd, specificand unde sa afiseze
mesajele primite de la un anumit proces si nivelul de loggare al mesajului
respectiv.

De exemplu, pe sistemul meu, “/etc/syslog.conf” contine doua linii care
specifica afisare mesajelor care se potrivesc cu “kern.info”.

kern.* -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages

Aceasta inseamna ca mesajele sunt duplicate in “/var/log/kern.log” si in
“/var/log/messages”. Pentru mai multe detalii, vezi “man syslogd.conf”.

4.1.5.3. Schimbarea tos (type of service)

Exista patru biti rar folositi in headerul IP, numiti biti tipul serviciului
(TOS). Valorea acestor biti determina modul in care vor fi tratate pachetele;
cei patru biti sunt “intarziere minima”, “transmitere maxima”, “maxima
siguranta” si “cost minim”. Doar unul dintre acesti biti este permis sa fie
setat. Rob van Nieuwkerk, autorul codul de modificare al TOS, exemplifica:

In special “intarziere minima” este important pentru mine. L-am setat
pentru pachetele “interactive” de pe ruterul linux. Sunt in spatele
unei legaturi de 33.6K. Linux da prioritate pachetelor in trei cozi de
asteptare. In acest mod am o performanta pentru traficul interactiv in
timp ce fac download-uri (ar fi putut merge mai repede, daca nu ar fi
fost o asa coada de asteptare in driver-ul pentru portul serial,
dar intarziere este acum de numai 1.5 secunde).

Nota: evident, nu ai nici un control asupra pachetelor care vin; poti controla
numai prioritatea pachetelor care pleaca. Pentru a negocia prioritatile cu
celalalt capat este necesar un protocol ca RSVP (nu ma intrebati, nu cunosc
nimic despre el).

Cea mai intalnita folosire este setarea conexiunilor ftp si telnet “intarziere
minima” si datelor FTP “transmitere maxima”. Aceasta ar putea fi realizata
dupa cum urmeaza:

ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0×01 0×10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0×01 0×10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0×01 0×08

Optiunea “-t” are doi parametri, amandoi in format hexazecimal. Aceaste
argumete permite modificarea compleza a bitilor TOS: prima valoare si
valoarea curenta a TOS-ului sunt adunate pe biti, apoi a doua valoare este
XOR-uita cu aceasta. Daca aceasta este prea confuz, foloseste urmatoarea
tabela:

TOS Name Value Typical Uses

Minimum Delay – intarziere minima 0×01 0×10 ftp, telnet
Maximum Throughput – transmitere maxima 0×01 0×08 ftp-data
Maximum Reliability – maxima siguranta 0×01 0×04 snmp
Minimum Cost – cost minim 0×01 0×02 nntp

Andi Kleen precizeaza urmatoarele:

Poate ar fi folositor sa facem legatura cu parametrul txqueue-len al ifconfig
in discutia despre biti TOS. Lungimea default a cozii de asteptare pentru
interfata este optimizata pentru placile ethernet, pentru modemuri aceasta
este prea lunga rezultand un randament scazut al planificarii in 3 benzi (in
care punerea in lista de asteptare este realizata de catre TOS). Este o idee
buna sa o setezi cu o valoare optima intre 4-10 pentru modem sau legaturi
simple ISDN; pentru mai multe interfete o coada de asteptare mai lunga este
necesara. Aceasta este o problema pentru kernelurile 2.0 si 2.1, dar in 2.1
este disponibila o optiune pentru ifconfig (cu o versiune recenta de
nettools), pe cand in 2.0 sunt necesare patch-uri pentru codul sursa al
driverelor.

Deci, pentru a avea beneficii maxime din manipularea TOS pentru conexiuni PPP,
da comanda “ifconfig $1 txqueuelen” in scriptul /etc/ppp/ip-up. Numarul care
trebuie folosit depinde de viteza modemului si marimea bufferului; dupa cum
spune si Andi:

Cea mai optima valoare pentru o configuratie data trebuie experimentata. Daca
listele de asteptare sunt prea scurte pe un ruter, atunci pachetele vor fi
ignorate. Deasemenea exista beneficii chiar fara rescrierea TOS, rescriere TOS
este folositoare pentru programele necooperante (dar toate programele standard
ce folosesc Linux sunt cooperante).

4.1.5.4. Marcarea unui pachet

Acest lucru permite interctiuni puternice si complexe cu noua implemetare
Quality of Service apartinand lui Alex Kuznetsov, la fel ca si forwardarea
bazata pe marcarea pachetelor in kernelurile versiunea 2.1 si mai avansate.
Aceasta optiune este ignorata in ver. 2.0.

4.1.5.5. Operatii pentru un chain

O foarte folositoare caracteristica a ipchains-ului este posibilitatea
gruparii regulilor in chain-uri. Poti sa denumesti chain-urile cum doresti,
atata timp cat nu intra in conflict cu chain-urile predefinite (input,
output, forward) sau cu tintele (MASQ, REDIRECT, ACCEPT, DENY, REJECT sau
RETURN). Recomand sa folosesti numirea chain-urile cu litere mari, deoarece
voi folosi numele mari pentru viitoare extensii. Numele unui chain poate fi in
lungime de pana la 8 caractere.

4.1.5.6. Crearea unui chain nou

Sa creeam un chain nou cu numele de test.

# ipchains -N test
#

Este simplu. Acum poti sa pui reguli in el in felul in care este prezentat mai
sus.

4.1.5.7. Stergerea unui chain

Stergerea unui chain este simpla de asemenea.

# ipchains -X test
#

De ce “-X”, pentru ca toate literele bune au fost folosite.

Exista doua restrictii in ceea ce priveste stergerea de chain-uri: chain-ul
trebuie sa fie gol (vezi “Stergerea tuturor regulilor unui chain” de mai jos)
si nu trebuie sa fie tinta nici unei reguli. Nu poti sterge nici unul dintre
chain-urile predefinite.

4.1.5.8. Stergerea tuturor regulilor unui chain

Si acest lucru este simplu de realizat prin optiunea “-F”, de exemplu:

# ipchains -F forward
#

Daca nu specifici un chain atunci toate regulile vor fi sterse.

4.1.5.9. Listarea regulilor unui chain

Poti lista toate regulile dintr-un chain folosind comanda “-L”:

# ipchains -L input
Chain input (refcnt = 0): (policy ACCEPT)
target prot opt source destination ports
ACCEPT icmp —– anywhere anywhere any
# ipchains -L test
Chain test (refcnt = 1):
target prot opt source destination ports
DENY icmp —– localnet/24 anywhere any
#

“Refcnt-ul” afisat la listarea regulilor din chain-ul test, indica numarul de
reguli care au ca tinta chain-ul test. Valoarea acesteia trebuie sa fie 0 (si
chain-ul sa fie gol) inainte ca acest chain sa poata fi sters.

Daca numele chain-ului este omis atunci toate chain-urile sunt listate chiar
si cele goale.

Sunt trei optiuni care pot fi folosite impreuna cu “-L”. Optiunea “-n”
(numeric) este foarte folositoare deorece impiedica ipchains sa incerce
rezolvarea IP-lor in nume, care (daca folosesti ca majoritatea oamenilor DNS)
va cauza mari intarzieri daca DNS-ul tau nu este configurat corect, sau ai
filtrat cererile catre serverele DNS. Cauzeaza deasemenea afisarea porturilor
sub forma de numere, mai degraba decat nume.

Optiunea “-v” iti arata toate detaliile regulii, cum ar fii counter-ele de
pachete si bytes, mask-urile TOS, interfetele si marcajul pachetelor. In caz
contrar aceste optiuni sunt omise. De exemplu:

Observati ca valoarea countere-lor pentru pachete si bytes sunt afisate cu
ajutorul sufixelor “K”, “M” sau “G” pentru 1000, 1.000.000 si respectiv
1.000.000.000. Folosirea optiunii “-x” (expandeaza numerele) afiseaza numerele
in format lung in ca bytes.

4.1.5.10. Resetarea (aducerea la 0) a counter-elor

Este folositor sa ai posibilitatea de a reseta counter-ele. Aceasta se
realizeaza cu ajutorul optiunii “-Z”. De exemplu:

# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp —– 0xFF 0×00 lo anywhere anywhere any
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
0 0 ACCEPT icmp —– 0xFF 0×00 lo anywhere anywhere any
#

Problema cand abordezi lucrurile in acest mod este ca uneori doresti sa vezi
valorile counter-elor chiar inainte de a le reseta. In exemplul de mai sus,
este posibil ca unele pachete sa fii trecut intre comenzile “-L” si “-Z”. Din
acest motiv este posibila folosirea impreuna a acestor comenzi, sa resetezi
valoarea counter-elor chiar in momentul afisarii acestora. Din nefericire,
daca faci asta, nu poti sa actionezi doar asupra unui singur chain, trebuie sa
listezi si resetezi counter-ele pentru toate chain-urile.

# ipchains -L -v -Z
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp —– 0xFF 0×00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp —– 0xFF 0×00 ppp0 localnet/24 anywhere any
# ipchains -L -v
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp —– 0xFF 0×00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp —– 0xFF 0×00 ppp0 localnet/24 anywhere any
#

4.1.5.11. Setarea policy-ului

Am atins in treacat ce se intampla cand un pachet ajunge la capatul unuia
dintre chain-urile predefinite, cand am discutat modul in care pachetele
circula prin chain-uri, in capitolul de mai sus “Specificarea unei tinte”.
In acest caz, politica (policy-ul) chain-ului determina soarta pachetului.
Doar chain-urile predefinite (input, output si forward) au policy, deoarece
in chain-urile definite de catre utilizator cand se ajunge la capatul
acestora, traversarea continua din chain-ul anterior.

Policy-ul poate fi unul din primele patru tinte speciale: ACCEPT, DENY,
REJECT sau MASQ. MASQ este valid doar pentru chain-ul “forward”.

Este deasemenea important sa observi ca tinta RETURN intr-o regula intr-unul
din chain-urile predefinite este folositoare pentru a se folosi in mod special
policy-ul chain-ului, cand un pachet se potriveste cu regula.

4.1.6. Operatii pentru masquerading

Sunt cativa parametri pe care ii poti modifica in cazul masquerading-ului.
Sunt legate de ipchains, pentru ca nu se merita scrierea unei noi comenzi
pentru aceasta.

Comanda pentru masqueradare este “-M”, si poate fi combinata cu “-L” pentru a
lista conexiunile care sunt in mod curent masqueradate, sau cu “-S” pentru a
seta parametrii pentru masquerading.

Comanda “-L” poate fi insotita de “-n” (afisarea de numere in loc de nume
pentru adrese IP si porturi) sau “-v” (afiseaza deltas in numere succesive
pentru conexiunile masquradate, doar in caz daca te intereseaza).

Comanda “-S” ar trebui urmata de trei valori pentru timeout, fiecare valoare
in secunde: pentru sesiunile TCP, pentru sesiunile TCP dupa un pachet FIN, si
pentru pachete UDP. Daca nu doresti una din aceste valori, pur si simplu pune
valoarea 0.

Valorile default sunt listate in “/usr/src/linux/include/net/ip_masq.h” si
sunt 15 minute, 2 minute si respectiv 5 minute.

Cea mai intalnita valoare ce trebuie schimbata este prima, pentru FTP (vezi
mai jos “FTP”).

Observa problemele legate de setarea valorile pentru timeout in “Nu pot
preciza timeout-uri pentru masquerading”.

4.1.7. Verificarea unui pachet

Uneori doresti sa vezi ce se intampla cand intra un anumit pachet, cum ar fi
pentru testarea regulilor firewall-ului. ipchains are comanda “-C”, ce
permite acest lucru, folosind exact aceleasi rutine pe care le foloseste
kernelul pentru diagnosticarea pachetelor reale.

Poti stipula care chain sa testeze pachetul cu optiunea “-C” urmat de
numele pachetului. In timp ce kernelul incepe intodeauna traversarea in
chain-urile input, output sau forward, ai puterea sa incepi traversarea in
orice chain in scopul testarii.

Detaliile in ceea ce priveste “pachetul” sunt specificate folosind aceeasi
sintaxa din specificarea regulilor. In special, protocolul “-p”, adresa sursa
“-s”, adresa destinatie “-d”, si interfata “-i” sunt obligatorii. Daca
protocolul este TCP sau UDP, atunci un singur port destinatie si un singur
port sursa trebuie specificat, daca protocolul este ICMP atunci trebuie
specificat tipul si codul (doar daca nu este specificata optiunea “-f” pentru
a preciza un fragment, caz in care aceste optiuni sunt ilegale).

Daca protocolul este TCP (si optiunea “-f” nu este specificata), optiunea “-y”
poate fi specificata, pentru a indica faptul ca pachetul de test are bitul SYN
pus.

Dam mai jos un exemplu de testare a unui pachet ce vine de la 192.168.1.1,
portul 60000 catre 192.168.1.2, portul www, intrand prin interfata eth0, in
chain-ul “input”. Acesta este un caz clasic de initiere a unei conexiuni www:

# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
#

4.1.8. Mai multe reguli dintr-o data si ceea ce se intampla atunci

Uneori o singura linie de comanda poate produce mai multe efecte. Aceasta se
realizeaza in doua moduri. Intai, poti sa specifici un hostname care este
rezolvat (folosind DNS) in mai multe adrese IP, ipchains se va comporta ca si
cum ai fi dat mai multe comenzi pentru fiecare adresa IP in parte.

De exemplu, daca hostname-ul “www.foo.com” este rezolvat in trei adrese IP,
si hostname-ul “www.bar.com” in doua adrese IP, atunci comanda
“ipchains -A input -j reject -s www.bar.com -d www.foo.com” ar fi echivalenta
cu introducerea a sase reguli diferite in chain-ul input, daca s-ar folosi
adrese IP.

Un alt mod prin care sa determini ipchains sa realizeze mai multe actiuni este
prin folosirea optiunii bidirectionale “-b”. Aceasta optiune determina
ipchains sa se comporte ca si cum ai fi dat comanda de doua ori, insa a doua
oara cu parametrii de la sursa si destinatie inversati. De exemplu, pentru a
evita forwardarea catre sau de la 192.168.1.1:

# ipchains -b -A forward -j reject -s 192.168.1.1
#

Personal, nu imi place prea mult aceasta optiune “-b”; daca doresti utilitate
citeste “Folosirea ipchains-save” de mai jos.

Optiunea “-b” poate fi folosita langa comenzile de introducere de reguli
(“-I”), stergere (“-D”) (dar nu varianta care accepta un numar al unei
reguli), adaugare (“-A”) si verificare (“-C”).

O alta optiune folositoare este “-v” care iti afiseaza exact ceea ce ipchains
realizeaza prin comenzile date. Acest lucru este folositor daca folosesti
comenzi ce pot avea efectul a mai multor reguli. De exemplu, aici verificam
comportamentul fragmentelor intre 192.168.1.1 si 192.168.1.2.

# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
tcp opt —f- tos 0xFF 0×00 via lo 192.168.1.1 -> 192.168.1.2
* -> *
packet accepted
tcp opt —f- tos 0xFF 0×00 via lo 192.168.1.2 -> 192.168.1.1
* -> *
packet accepted
#

4.2. Exemple folositoare

Am o conexiune dialup PPP (-i ppp0). Citesc stirile (-p TCP -s
news.virtual.net.au nntp) si mail-ul (-p TCP -s mail.virtual.net.au pop-3) de
fiecare data cand ma conectez. Folosesc metoda de FTP a Debianului pentru a-mi
updata sistemul regulat (-p TCP -y -s ftp.debian.org.au ftp-data). Navighez pe
web cu ajutorul proxy-ului ISP-ului atata timp cat acesta merge (-p TCP -d
proxy.virtual.net.au 8080), dar nu suport bannerele de la doubleclick.net in
arhivele Dilbert (-p TCP -y -d 199.95.207.0/24 and -p TCP -y -d
199.95.208.0/24).

Nu ma deranjeaza ca oameni sa incerce sa faca ftp pe masina mea cat timp sunt
online (-p TCP -d $LOCALIP ftp), dar nu vreau ca nimeni din exterior sa
pretinda ca are una din adresele retelei mele interne (-s 192.168.1.0/24).
Acest lucru este numit spoofare IP, si exista o modalitate mai buna de a te
proteja impotriva acesteia in kernelurile 2.1.x si mai avansate: citeste “Cum
realizez protectia impotriva spoofarii IP”.

Aceasta configurare este destul de simpla, pentru ca nu sunt in mod curent
alte hosturi in reteaua mea interna.

Doresc ca nici un proces local (ex. lynx, netscape) sa se conecteze la
doubleclick.net:

# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
#

Acum doresc sa realizez prioritati asupra a pachete variate ce pleaca (nu prea
are sens sa fac acest lucru pentru pachetele ce intra). Cum am un numar mai
mare de acest tip de reguli, are sens sa le pun pe toate intr-un singur chain,
numit ppp-out.

# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
#

Intarziere minima pentru traficul www si telnet.

# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0×01 0×10
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 telnet -t 0×01 0×10
#

Cost minim pentru canalul de date ftp, nntp, si pop3:

# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0×01 0×02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0×01 0×02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0×01 0×02
#

Sunt cateva restrictii pentru pachetele ce vin prin interfata ppp0: se cream
atunci un chain numit “ppp-in”:

# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
#

Acum, nici un pachet care vine prin interfata ppp0, nu are voie sa pretinda ca
are adresa sursa 192.168.1.*, asa ca le igoram si le logam:

# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#

Permit pachetele catre DNS (rulez un server de nume care inainteaza toate
cererile catre 203.29.16.1, asa ca ma astept la pachete replica DNS doar de
acolo, pachete catre portul ftp, si doar canalul de date pentru conexiunile
ftp in exterior (care ar trebui sa fie doar pe un port peste 1023, si pe
porturile pentru X11 in jur de 6000).

# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#

Accept replay-urile la pachetele TCP:

# ipchains -A ppp-in -p TCP ! -y -j ACCEPT
#

In sfarsit conexiunile locale sunt ok:

# ipchains -A input -i lo -j ACCEPT
#

Acum, politica default in chain-ul input este DENY, astfel incat orice altceva
este ignorat:

# ipchains -P input DENY
#

Observatie: Nu mi-as configura chain-urile in aceasta ordine, deoarece
pachetele ar putea sa treaca in timp ce introduc regulile. Cel mai sigur este
sa setezi politica DENY intai, apoi sa introduci regulile. Bineinteles, daca
regulile tale au nevoie de cereri DNS pentru a rezolva numele, s-ar putea sa
fi in necaz.

4.2.1. Folosirea ipchains-save

Configurarea regulilor pentru firewall in modul in care doresti, si apoi sa
incerci sa memorezi comenzile pe care le-ai folosit ca sa faci acelasi lucru
din nou este chinuitor.

Asa ca, ipchains-save este un script care citeste configuratia curenta a
chain-urilor si le salveaza intr-un fisier. Deocamdata te tin in suspans cu
privire la ce realizeaza ipchains-retore.

ipchains-save poate salva un singur chain, sau toate chain-urile (daca nici un
nume de chain, nu este specificat). Singura optiune permisa este “-v” care
afiseaza regulile pe masura ce acestea sunt salvate. Politica acestor chain-uri
este deasemenea salvata pentru chain-urile input, output si forward.

# ipchains-save > my_firewall
Saving `input’.
Saving `output’.
Saving `forward’.
Saving `ppp-in’.
Saving `ppp-out’.
#

4.2.2. Folosirea ipchains-restore

ipchains-restore restaureaza chain-urile salvate cu ipchains-save. Poate avea
doua optiuni: “-v” care afiseaza fiecare regula pe masura ce este adaugata, si
“-f” care obliga stergerea chain-urile definite de catre utilizator daca
exista, in modul descris mai jos.

Daca este gasit un chain definit de utilizator este gasit in fisierul din care
se restaureaza regulile, ipchains verifica daca nu exista deja acel chain.
Daca exista, atunci vei fi intrebat daca fie chain-ul respectiv sa fie golit
de reguli, fie sa fie sarit. Daca specifici “-f” in linia de comanda, nu vei
mai fi intrebat, chain-ul va fi golit de reguli.

De exemplu:

# ipchains-restore < my_firewall
Restoring `input’.
Restoring `output’.
Restoring `forward’.
Restoring `ppp-in’.
Chain `ppp-in’ already exists. Skip or flush? [S/f]? s
Skipping `ppp-in’.
Restoring `ppp-out’.
Chain `ppp-out’ already exists. Skip or flush? [S/f]? f
Flushing `ppp-out’.
#

5. Diverse

Aceasta parte contine toate informatiile si FAQ-urile pe care nu am putut sa
le introduc in structura de mai sus.

5.1. Cum sa iti organizezi regulile firewall-ului

Aceasta intrebare cere putina gandire. Poti incerca sa le organizezi pentru a
optimiza viteza (minimizezi numarul de reguli pentru cele mai comune pachete)
sau sa cresti manevrabilitatea.

Daca ai o legatura care se intrerupe, sa spunem o conexiune PPP, ai putea dori
ca prima regula in chain-ul input sa fie “-i ppp0 -j DENY” in timpul bootarii,
apoi sa ai ceva de genul acesta in scriptul ip-up:

# Re-create the `ppp-in’ chain.
ipchains-restore -f < ppp-in.firewall

# Replace DENY rule with jump to ppp-handling chain.
ipchains -R input 1 -i ppp0 -j ppp-in

Scriptul ip-down ar arata astfel:

ipchains -R input 1 -i ppp0 -j DENY

5.2. Ce anume sa nu filtrezi spre afara

Sunt cateva lucruri de care trebuie sa fi constient inainte de a incepe
filtrarea pachetelor pe care nu le doresti.

5.2.1. Pachete icmp

ICMP este folosit (printre alte lucruri) pentru a indica esecul alte
protocoale (cum ar fi TCP si UDP). Pachetele “destination-unreachable” in
special. Blocarea acestor pachete inseamna ca niciodata nu vei avea erori de
genul “Host unreachable” sau “No route to host”; orice conexiune doar va
astepta o replica (replay) care nu va veni niciodata. Aceasta este iritabil,
dar rar fatal.

O problema mai grava este rolul ICMP in descoperirea MTU-ului. Toate
implementarile bune TCP (Linux este inclus) folosesc descoperirea MTU pentru a
incerca sa isi dea seama care este marimea maxima a unui pachet care poate
ajunge la destinatie fara sa fie fragmentat (fragmentarea incetineste
performanta, in special cand fragmente ocazionale sunt pierdute). Descoperirea
MTU functioneaza prin transmiterea de pachete cu bit “nu fragmenta” pus, si
apoi transmiterea de pachete mai mici daca primeste replica ICMP indicand ca
este necesarea fragmentarea. Acesta este un tip de pachet
“destination-unreachable”, si daca nu este primit, sistemul nu isi va reduce
MTU-ul, si performantele nu vor exista.

Observa faptul ca este comun sa blochezi toate pachetele ICMP de redirectare
(de tip 5); aceastea pot fi folosite pentru a manvevra rutarea (deasemenea
stive bune IP au masuri de protectie), asa ca sunt vazute ca risc minim.

5.2.2. Conexiunile TCP catre servere DNS (servere de nume)

Daca incerci sa blochezi conexiunile TCP catre exterior, tine minte ca DNS nu
foloseste intodeauna UDP; daca raspunsul de la server depaseste 512 bytes,
clientul foloseste o conexiune TCP (tot spre portul 53) pentru date.

Aceasta poate fi o capcana deoarece DNS va merge in mare parte. Daca nu
permiti asemenea transferuri TCP; este posibil sa experimentezi intarzieri
mari si alte probleme ocazionale DNS.

Daca aceste cereri DNS sunt intodeauna catre aceeasi sursa externa (fie direct
prin folosirea liniei de nameserver din /etc/resolv.conf, fie folosind un
nameserver pentru cache in mod forward), atunci ai nevoie doar sa permiti
conexiunile TCP catre portul 53 pe acel nameserver de la portul local 53 (in
caz in care folosesti nameserver pentru cache) sau de la un port local (>1023)
daca folosesti /etc/resolv.conf.

5.2.3. FTP

Problema clasica a filtrului de pachete este FTP. FTP are doua moduri; cel
traditional care este numit mod activ, si cel mai recent care este numit ftp
pasiv. Browsere-le web folosesc de obicei default modul pasiv, pe cand
ftp-urile din linia de comanda modul activ.

In mod activ, cand celalalt capat doreste sa trimita un fisier (sau chiar ca
rezultat a unei comenzi ls sau dir) incerca sa deschida o conexiune TCP catre
masina locala. Asta inseamna ca nu poti sa filtrezi aceste conexiuni TCP fara sa
impiedici conexiunile ftp active.

Daca ai posibilitatea sa folosesti ftp pasiv, atunci este bine; modul pasiv
creaza conexiuni TCP de la client la server, chiar si pentru datele care vin.
In caz contrar, este recomandat sa lasi conexiunile TCP pe porturile locale
mai mari de 1024 si nu intre 6000 si 6010 (6000 este folosit de X).

5.3. Filtrarea Pingului Mortii

Sistemele Linux sunt acum imune la celebrul Ping al Mortii, care presupune
trimiterea de pachetele ICMP anormal de mari care umple bufferele in stiva TCP
de pe sistem cauzand blocarea acestuia.

Daca protejezi sisteme care ar putea fi vulnerabile, poti in mod simplu sa
ignori fragmentele ICMP. In mod normal pachetele ICMP nu sunt atat de mari
pentru a fi nevoie de fragmentarea acestora, asa ca nu va influenta nimic in
rau, exceptand ping-urile cu pachete de marime mare. Am auzit (neconfimat)
rapoarte cum ca pentru unele sisteme ar fi suficient numai ultimul fragment al
unui asemenea pachet ICMP, pentru a bloca sistemul, deci blocarea numai a
primului fragment nu este recomandata.

In timp ce exploiturile pe care le-am vazut foloseau numai protocolul ICMP
pentru aceste atacuri, nu exista nici un motiv pentru care TCP si UDP sa nu
fie folosit in acelasi mod, asa ca blocarea fragmentelor ICMP este doar o
solutie temporara.

5.4. Filtrarea pentru Teardrop si Bonk

Teardrop si Bonk sunt doua tipuri de atacuri (in principal asupra masinilor ce
ruleaza Windows NT) care se bazeaza pe fragmente ce se suprapun partial.
Acestea pot fi oprite prin configurarea sistemului Linux sa realizeze
defragmentare sau sa nu permita fragmente catre sistemele vulnerabile.

5.5. Filtrarea fragmentelor in masa

Cateva stive TCP mai putin sigure se spune ca au probleme in ceea ce priveste
numarul mare de fragmente de pachete, atunci cand nu primesc toate
fragmentele. Linux nu are aceasta problema. Poti filtra aceste fragmente (care
pot sa impiedice folosirea lor legitima) sau sa compilezi kernelul cu optiunea
“IP: always defragment” setata “Y” (doar daca sistemul tau linux este singura
ruta pentru aceste pachete).

5.6. Schimbarea regulilor din firewall

Sunt cateva probleme legate de viteza cu care pot fi schimbate regulile din
firewall. Daca nu esti atent, poti sa lasi pachete sa intre cand esti la
jumatatea acestor modificari. O rezolvare simpla ar fi:

# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY

… realizeaza modificari …

# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#

Se ignora astfel toate pachetele pe durata modificarilor.

Daca schimbarile tale sunt doar intr-un singur chain, ai putea crea un nou
chain cu noile reguli, si apoi sa inlocuiesti (“-R”) regula care facea
referire la vechiul chain cu o noua regula catre noul chain: apoi poti sa
stergi vechiul chain. Aceasta inlocuire va fi automata.

5.7. Cum realizez protectia impotriva spoofarii IP

Spoofarea IP este o tehnica in care un host trimite pachete care pretind ca
sunt de la un alt host. Cum filtrarea de pachete ia decizii bazandu-se pe
adresa sursa, spoofarea IP este folosita pentru a pacali filtrele de pachete.
Este folosita deasemenea pentru a ascunde identitatea atacatorilor care
folosesc atacuri SYN, Teardrop, Ping of Death si similare (nu iti face griji
daca nu stii ce inseamna).

Cea mai buna cale de a te proteja contra spoofarii este Verificarea adresei
sursa, si este realizata de catre codul de rutare, si deloc de catre cel al
firewall-ului. Verifica existenta fisierului
/proc/sys/net/ipv4/conf/all/rp_filter. Daca exista, atunci pornirea
Verificarii adresei sursa este solutia potrivita pentru tine. Pentru a realiza
acest lucru, introduce urmatoarele linii undeva in scripturile de pornire,
inainte de initializarea oricarei interfete de retea:

# Aceastea este cea mai buna metoda:
# da drumu la Verificarea adresei sursa si ai protectie anti-spoof
# pentru toate interfetele curente si viitoare.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n “Setting up IP spoofing protection…”
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo “done.”
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo “CONTROL-D will exit from this shell and continue system startup.”
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi

(nt. sau in fisierul sysctl.conf adauga:
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
)

Daca nu poti realiza acest lucru, atunci poti in mod manual sa introduci
reguli pentru a proteja fiecare interfata. Aceasta cere insa cunoasterea
fiecarei interfete. Kernelurile 2.1 rejecteaza automat pachetele care pretind
a veni de la adresele 127.* (rezervate pentru interfata loopback, lo).

De exemplu, sa presupunem ca avem trei interfete, eth0, eth1 si ppp0. Folosim
ifconfig pentru a vedea adresele interfetelor si netmaskul acestora. Sa zicem
ca eth0 este atasata unei retele 192.168.1.0 cu netmask-ul 255.255.255.0, eth1
apartine unei retele 10.0.0.0 cu netmask 255.0.0.0, si ppp0 este conectata la
Internet (unde orice adrese, exceptand cele din clasele private, sunt
permise). Introducem regulile:

# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#

Aceasta rezolvare a problemei nu este atat de buna cum este Verificarea
adresei sursa, deoarece daca reteaua se schimba, trebuie sa iti modifici
regulile din firewall.

Daca ai un kernel ver 2.0, ai dori sa iti protejezi chiar si interfata
loopback:

# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#

5.8. Proiecte mai avansate

Exista o biblioteca pe care am scris-o, inclusa in distributia surselor numita
“libfw”. Aceasta foloseste posibilitatea din IP Chains ver 1.3 si peste, de
a copia un pachet pentru a putea fi folosit in mediul utilizator (folosind
optiunea IP_FIREWALL_NETLINK).

Valorea cu care este marcat pachetul poate fi folosita pentru a specifica
parametrii de Calitate a serviciului pentru pachete, sau pentru a specifica
cum ar trebui sa fie facuta forwardarea de porturi pentru pachete. Nu am
folosit nici una dintre acestea, dar daca ai vreo observatie contacteaza-ma.

Lucuri cum ar fi verificarea dupa stare (prefer termenul de firewall dinamic)
pot fi implementate in mediul utilizator prin folosirea acestei biblioteci.
Alta idee mai interesanta ar fi controlarea pachetelor intr-un mediu
utilizator cu ajutorul unui daemon, destul de usor de realizat.

5.8.1. SPF: filtrare dupa starea pachetului (stateful packet filtering)

ftp://ftp.interlinx.bc.ca/pub/spf este
site-ul proiectului SPF, apartinand lui Brian Murrell, care realizeaza
urmarirea conexiunile in mediu utilizator. Se adauga astfel securitate
simnificativa pentru site-uri cu banda limitata.

In prezent nu este disponibila multa documentatie, dar iata postari pe o lista
de discutii in care Brian raspunde la niste intrebari:

> cred ca se realizeaza exact ce doresc. Intra in functiune o regula
> temporara pentru a permite intrarea pachetele ce vin ca raspuns la o
> cerere anterioara
Da, exact asta se realizeaza. Cu cat este mai compatibil cu mai multe
protocoale, cu atat regula temporara este corecta. Pentru moment
suporta (din cate imi amintesc, scuzati eventualele erori sau
omisiuni) FTP (atat activ, cat si pasiv, inautru sau spre exterior),
RealAudio, traceroute, ICMP si ICQ simplu (conexiuni dinspre servere
ICQ, si conexiuni TCP directe, dar conexiuni secundare directe TCP
pentru lucruri ca transferul de fisiere, nu sunt inca realizate)

> este un inlocuitor pentru ipchains sau un lucru suplimentar?
Este un lucru suplimentar. Gandeste-te la ipchains ca la un engine
care permite sau interzice pachetelor traversarea printr-un sistem
linux. SPF este driver-ul, care monitorizeaza constant traficul si
comunica ipchains-ului ce anume sa schimbe in reguli pentru a permite
un anumit tip de trafic.

5.8.2. “Hack-ul” ftp-data al lui Michael Hasenstein

Michael Hasenstein, de la SuSE, a scris un patch de kernel care adauga
urmarirea conexiunilor ftp pentru ipchains. Poate fi gasit la

http://www.suse.de/~mha/patch.ftp-data-2.gz

5.9. Planuri de viitor

Realizarea de firewall si NAT-ul au fost rescrise pentru 2.4. Planuri si
discutii sunt disponibile pe lista de discutii de la netfilter (vezi
http://lists.samba.org ). Aceste versiuni noi ar
trebui sa rezolve multe dintre problemele actuale de utilizare (realizarea de
masquerading si firewall nu ar trebui sa fie asa de grea) si sa permite
dezvoltarea de firewall-uri mai flexibile.

6. Probleme des intalnite

6.1. ipchains -L ingheata!

Probabil ca ai blocate cererile catre DNS; eventual va da timeout. Incearca sa
folosesti optiunea “-n” (numeric), care previne ipchains sa rezolve numele.

6.2. Specificarea inversa nu poate fi realizata!

Trebuie sa pui semnul “!” singur, cu spatii de o parte si de alta. O greseala
clasica este:

# ipchains -A input -i !eth0 -j DENY
#

Nu va exista niciodata o interfata numita “!eth0″, dar ipchains nu isi da
seama de acest lucru.

6.3. Masqueradarea/Forwardarea nu se realizeaza!

Verifica daca forwardarea pentru pachete este setata (in kernelurile recente
default este scos, insemnand ca pachetele nici macar nu vor incerca sa
traverseze chain-ul “forward”). Poti sa ii pornesti aceasta facilitate prin:

# echo 1 > /proc/sys/net/ipv4/ip_forward
#

Daca aceasta comanda functioneaza, o poti pune intr-unul din scripturile ce
ruleaza la bootare, pentru a avea tot timpul aceasta facilitate; desi vei dori
sa iti configurezi firewall-ul, in caz contrar exista posibilitatea ca unele
pachete sa treaca.

6.4. Tinta -j REDIR nu merge!

Trebuie sa permiti forwardarea de pachete (citeste mai sus) pentru ca
redirectarea sa fie posibila; altfel codul de rutare ignora pachetul. Asa ca
daca folosesti doar redirect, si nu ai forwarding-ul setat, ar trebui sa iti
dai seama ca este de la asta.

Observa ca REDIR (fiind in chain-ul input) nu afecteaza conexiunile catre
procesele locale.

6.5. Specificare mai multor interfete (ex “-i ppp+”) nu merge!

Exista un defect de programare in kernelurile ver. 2.1.102 si 2.1.103 (si
in unele patch-uri mai vechi pe care le-am relizat) care determina
comanda ipchains de specificare a mai multor interfete (ex “-i ppp+”) sa nu
mearga.

Acest lucru a fost indreptat in kernelurile recente si in patch-ul 2.0.34 de
pe site-ul web. Poti deasemenea sa il indrepti manual, in sursele kernelului
modificand linia 63 din fisierul include/linux/ip_fw.h:

#define IP_FW_F_MASK 0x002F /* All possible flag bits mask */

In loc de 0x002F ar trebui sa fie “0x003F”. Modifica si recompileaza kernelul.

6.6. TOS nu merge!

Aceasta este greseala mea: setarea campului TOS nu a setat in realitate TOS
in kernelurile ver. 2.1.102 pana la 2.1.111. Aceasta problema a fost rezolvata
in 2.1.112.

6.7. ipautofw si ipportfw nu merg!

Pentru 2.0.x, aceasta este adevarat; nu am avut timp pentru a crea si mentine
un patch pentru ipchains si ipautofw/ipportfw.

Pentru 2.1.x, downloadeaza ipmasqadm al lui Juan Ciarlante de la:
name=”http://juanjox.linuxhq.com/”>

si foloseste-l la fel ca si cum ai fi folosit ipautofw si ipportfw, cu
exceptia faptului ca in loc de ipportfw tastezi ipmasqadm portfw, si in loc de
ipautofw tastezi ipmasqadm autofw.

6.8. xosview este stricat!

Fa upgrade la versiunea 1.6.0 sau mai avansata, unde nu este necesar nici un
fel de reguli in firewall pentru kernelurile 2.1.x. Se pare ca iar nu
functioneaza in ver. 1.6.1.; te rog contacteaza autorul (nu este greseala
mea!).

6.9. Segmentation Fault din cauza tintei “-j REDIRECT”!

Acesta este o eroare de programare in ipchains, ver. 1.3.3. Upgrade.

6.10. Nu pot preciza valori de timeout pentru masquerading!

Este adevarat (pentru kernelurile 2.1.x) pana la ver. 2.1.123. In 2.1.124,
incercarea de a seta valori pentru timeout-ul din masqueradig cauza o blocare
a kernelului (schimba return cu ret la linia 1328 din fisierul
net/ipv4/ip_fw.c). In 2.1.125, functioneaza cum trebuie.

6.11. Vreau sa filtrez IPX!

Asta se pare ca vor si altii. Din pacate codul meu acopera doar IP. Insa,
exista posibilitatea pentru a filtra IPX! Trebuie doar sa scrii codul, te voi
ajuta unde este posibil.

7. Un exemplu serios

Acest exemplu a fost luat de la Michael Neuling si tutorialul meu din
LinuxWorld din Martie 1999; acesta nu este singura cale pentru a rezova
problema data, dar este probabil cea mai simpla. Sper ca o sa o gasesti
interesanta.

7.1. Topologia retelei

- O retea interna masqueradata (sisteme de operare variate), pe care o numim
“GOOD”.

- Servere expuse intr-o retea separata (numita “DMZ” de la zona
demilitarizata).

- Conexiunea PPP catre Internet (numita “BAD”).

Retea externa (BAD)
|
|
ppp0|
—————
| 192.84.219.1| Reteaua de servere (DMZ)
| |eth0
| |———————————————-
| |192.84.219.250 | | |
| | | | |
|192.168.1.250| | | |
————— ——– ——- ——-
| eth1 | SMTP | | DNS | | WWW |
| ——– ——- ——-
| 192.84.219.128 192.84.219.129 192.84.218.130
|
Retea interna (GOOD)

7.2. Scopurile

Filtrul de pachete de pe ruter:

PING orice retea
Aceasta este folositor pentru a verifica daca un sistem este oprit.

TRACEROUTE orice retea
Inca odata, folositor pentru analize.

Acces DNS
Pentru a face ping-ul si DNS-ul mai folositor

In cadrul DMZ:
Serverul de mail (SMTP):

- SMTP catre exterior
- Permiterea accesului SMTP din interior si exterior
- Permiterea accesului POP3 din interior.

Serverul de nume (DNS):

- Trimitere de pachete DNS catre exterior
- Permiterea accesului DNS din reteaua interna, externa si de pe ruter.

Serverul WWW:

- Permiterea accesului http din exterior si interior
- Permiterea accesului rsync din interior

Reteaua interna:

Permiterea accesului www, ftp, ssh si traceroute
Aceastea sunt lucruri permise destul de standard, in unele
locuri sistemele au voie sa faca orice, dar aici vom fi mai
restrictivi.

Permiterea accesului SMTP catre serverul de mail
Evident, dorim ca sa aiba posibilitatea sa trimita mailuri.

Permiterea accesului POP3 catre serverul de mail
In acest mod isi pot citi mail-ul.

Permiterea accesului DNS catre nameserver
Au nevoie de posibilitatea de a rezolva numele externe pentru
www, ssh, ftp, si traceroute.

Permiterea accesului rsync catre serverul de web
Acesta este modul prin care vor sincroniza serverul extern de
web cu cel intern.

Permiterea accesului WWW catre serverul de WEB
Evident, trebuie sa poata fi accesat serverul nostru extern
de web.

Permiterea ping-ului catre ruter
Pentru a realiza daca este jos ruterul, ca sa nu dea vina pe
noi daca un server extern este jos.

7.3. Inainte de realizarea filtrarii de pachete

- Anti-spoofing
Cum nu avem de a face cu rutare asimetrica, putem in mod simplu sa dam
drumul la anti-spoofing pentru toate interfetele.

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
#

- Configurarea filtrului de pachete sa interzica (DENY) toate pachetele
Permitem insa traficul pentru interfata loopback, dar nu permiterm
nimic alceva.

# ipchains -A input -i ! lo -j DENY
# ipchains -A output -i ! lo -j DENY
# ipchains -A forward -j DENY
#

- Configurarea interfetelor
Aceasta este de obicei realizata in scripturile de initializare. Fii
sigur ca pasii de mai sus sunt realizati inainte de configurarea
interfetelor, pentru a preveni scaparea eventualelor pachete.

- Introduce modulele de masquerading specifice protocolului
Este necesar sa introducem modulul de masquerading pentru FTP, astfel
incat ftp activ si pasiv sa fie disponibile din reteaua interna.

# insmod ip_masq_ftp
#

7.4. Filtrarea de pachete pentru pachetele directe

Deorece se realizeaza masquerading, cel mai bine este sa le filtrezi in
chain-ul forward.

Imparte chain-ul forward in diferite chain-uri definite de catre utilizator in
functie de interfata sursa/destinatie; aceasta abordare imparte problema in
bucati.

ipchains -N good-dmz
ipchains -N bad-dmz
ipchains -N good-bad
ipchains -N dmz-good
ipchains -N dmz-bad
ipchains -N bad-good

Acceptarea erorile standard ICMP este un lucru obisnuit, asa ca specificam un
chain pentru acestea.

ipchains -N icmp-acc

7.4.1. Trecerea spre alte chain-uri din chain-ul forward

Din nefericire, in chain-ul forward cunoastem doar interfata de iesire. De
aceea, pentru a realiza interfata pe unde a intrat pachetul, ne folosim de
adresa sursa (facilitatea anti-spoofing previne adresele sursa false).

Observa ca logam toate pachetele cu adresa sursa falsa (evident, aceasta nu ar
trebui sa se intample niciodata).

ipchains -A forward -s 192.168.1.0/24 -i eth0 -j good-dmz
ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j good-bad
ipchains -A forward -s 192.84.219.0/24 -i ppp0 -j dmz-bad
ipchains -A forward -s 192.84.219.0/24 -i eth1 -j dmz-good
ipchains -A forward -i eth0 -j bad-dmz
ipchains -A forward -i eth1 -j bad-good
ipchains -A forward -j DENY -l

7.4.2. Definirea chain-ului icmp-acc

Pachetele care sunt erori ICMP sunt acceptate, in caz contrar, traversarea va
continua din chain-ul anterior.

ipchains -A icmp-acc -p icmp –icmp-type destination-unreachable -j ACCEPT
ipchains -A icmp-acc -p icmp –icmp-type source-quench -j ACCEPT
ipchains -A icmp-acc -p icmp –icmp-type time-exceeded -j ACCEPT
ipchains -A icmp-acc -p icmp –icmp-type parameter-problem -j ACCEPT

7.4.3. Reguli pentru conexiuni reteaua interna ==> DMZ

Restrictii interne:

- Este permis accesul WWW, ftp, traceroute, ssh catre exterior
- Este permis accesul accesul SMTP catre serverul de mail
- Este permis accesul pop3 catre serverul de mail
- Este permis accesul DNS la namerserver
- Este permis rsync catre serverul de Web
- Este permis accesul WWW catre serverul de Web
- Este permis ping catre ruter

Am putea sa realizam masquerading din reteaua interna catre DMZ, dar nu facem
acest lucru. Cum nimeni din reteaua interna nu ar trebui sa incerce sa faca
lucruri rele, logam toate pachetele ce sunt interzise.

Observati ca in versiunile mai vechi de Debian numesc “pop3″ “pop-3″ care nu
respecta RFC1700.

ipchains -A good-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A good-dmz -p tcp -d 192.84.219.128 pop3 -j ACCEPT
ipchains -A good-dmz -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A good-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A good-dmz -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A good-dmz -p tcp -d 192.84.218.130 rsync -j ACCEPT
ipchains -A good-dmz -p icmp -j icmp-acc
ipchains -A good-dmz -j DENY -l

7.4.5. Reguli pentru conexiuni din reteaua interna ==> reteaua externa

Restrictionare in reteaua DMZ numai la:
- serverul de mail:
- SMTP catre exterior
- acceptare acces SMTP din interior si exterior
- acceptare acces pop3 din interior

- serverul de nume:
- trimitere cereri DNS catre exterior
- acceptarea acces DNS din reteaua interna, externa si ruter

- serverul de web:
- acceptare acces HTTP din exterior si interior
- acceptare acces rsync din interior

Lucruri pe care le permitem din Internet catre DMZ

- nu logam violarile, deoarece se pot intampla.

ipchains -A bad-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A bad-dmz -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bad-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bad-dmz -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A bad-dmz -p icmp -j icmp-acc
ipchains -A bad-dmz -j DENY

7.4.5. Reguli pentru conexiuni din reteaua interna ==> reteaua externa

Restrictionare in reteaua interna numai la:
- permiterea in exterior traficului WWW, ftp, traceroute, ssh
- acceptare acces SMTP catre serverul de mail
- acceptare acces POP-3 catre serverul de mail
- acceptare acces DNS catre nameserver
- acceptare acces rsync catre nameserver
- acceptare acces WWW catre serverul de web
- acceptare ping catre ruter
- logare a violarilor
- porturile UDP destinatie 33434 sunt permise si folosite de
traceroute

Multi oameni permit totul din reteaua locala, noi nu.
Ftp pasiv este utilizat cu ajutorul modulului de masquerading.

ipchains -A good-bad -p tcp –dport www -j MASQ
ipchains -A good-bad -p tcp –dport ssh -j MASQ
ipchains -A good-bad -p udp –dport 33434:33500 -j MASQ
ipchains -A good-bad -p tcp –dport ftp -j MASQ
ipchains -A good-bad -p icmp –icmp-type ping -j MASQ
ipchains -A good-bad -j REJECT -l

7.4.6. Reguli pentru conexiuni din DMZ ==> reteaua interna

Daca realizam masquerading din reteaua interna catre DMZ, pur si si
simplu refuzam pachetele ce vin din cealalta parte. Astfel, permitem
pachetele care nu pot fi decat parte a unei conexiuni stabilite.

ipchains -A dmz-good -p tcp ! -y -s 192.84.219.128 smtp -j ACCEPT
ipchains -A dmz-good -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A dmz-good -p tcp ! -y -s 192.84.219.129 domain -j ACCEPT
ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 rsync -j ACCEPT
ipchains -A dmz-good -p icmp -j icmp-acc
ipchains -A dmz-good -j DENY -l

7.4.7. Reguli pentru conexiuni din DMZ ==> reteaua externa

Restrictionare in reteaua DMZ numai la:
- serverul de mail:
- SMTP catre exterior
- acceptare acces SMTP din interior si exterior
- acceptare acces pop3 din interior

- serverul de nume:
- trimitere cereri DNS catre exterior
- acceptarea acces DNS din reteaua interna, externa si ruter

- serverul de web:
- acceptare acces HTTP din exterior si interior
- acceptare acces rsync din interior

ipchains -A dmz-bad -p tcp -s 192.84.219.128 smtp -j ACCEPT
ipchains -A dmz-bad -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A dmz-bad -p tcp -s 192.84.219.129 domain -j ACCEPT
ipchains -A dmz-bad -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A dmz-bad -p icmp -j icmp-acc
ipchains -A dmz-bad -j DENY -l

7.4.8. Reguli pentru conexiuni din reteaua externa ==> reteaua interna

- Nu permitem nici o conexiune nemasqueradata din reteaua externa catre
reteaua interna

ipchains -A bad-good -j REJECT

7.4.9. Filtrul de pachete pentru insusi sistemul care este ruter

- Daca doresti sa filtrezi pachetele ce au ca destinatie insusi ruterul,
aceasta sa realizeaza in chain-ul input. Cream cate un chain pentru fiecare
interfata destinatie.

ipchains -N bad-if
ipchains -N dmz-if
ipchains -N good-if

- Cream reguli pentru a sari la aceste chain-uri

ipchains -A input -d 192.84.219.1 -j bad-if
ipchains -A input -d 192.84.219.250 -j dmz-if
ipchains -A input -d 192.168.1.250 -j good-if

7.4.9.1. Interfata catre reteaua externa

Restrictionarea ruterului numai la:
- PING catre orice retea
- TRACEROUTE catre orice retea
- acces catre DNS
- Interfata externa primeste deasemenea replay-uri la pachetele
masqueradate (masquerading foloseste porturile sursa 61000 si
65095), erorile ICMP pentru acestea si replay-urile la PING.

ipchains -A bad-if -i ! ppp0 -j DENY -l
ipchains -A bad-if -p TCP –dport 61000:65095 -j ACCEPT
ipchains -A bad-if -p UDP –dport 61000:65095 -j ACCEPT
ipchains -A bad-if -p ICMP –icmp-type pong -j ACCEPT
ipchains -A bad-if -j icmp-acc
ipchains -A bad-if -j DENY

7.4.9.2. Interfata catre reteaua de servere (DMZ)

Restrictionarea ruterului numai la:
- PING catre orice retea
- TRACEROUTE catre orice retea
- acces catre DNS
- interfata catre DMZ primeste replay-uri DNS, ping si erori ICMP

ipchains -A dmz-if -i ! eth0 -j DENY
ipchains -A dmz-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT
ipchains -A dmz-if -p UDP -s 192.84.219.129 53 -j ACCEPT
ipchains -A dmz-if -p ICMP –icmp-type pong -j ACCEPT
ipchains -A dmz-if -j icmp-acc
ipchains -A dmz-if -j DENY -l

7.4.9.3. Interfata catre reteaua interna

Restrictionarea ruterului numai la:
- PING catre orice retea
- TRACEROUTE catre orice retea
- acces catre DNS

Restrictionarea retelei interne numai la:
- permiterea in exterior traficului WWW, ftp, traceroute, ssh
- acceptare acces SMTP catre serverul de mail
- acceptare acces POP-3 catre serverul de mail
- acceptare acces DNS catre nameserver
- acceptare acces rsync catre nameserver
- acceptare acces WWW catre serverul de web
- acceptare ping catre ruter
- interfata interna primeste ping-uri, replay-uri la ping si erori ICMP

ipchains -A good-if -i ! eth1 -j DENY
ipchains -A good-if -p ICMP –icmp-type ping -j ACCEPT
ipchains -A good-if -p ICMP –icmp-type pong -j ACCEPT
ipchains -A good-if -j icmp-acc
ipchains -A good-if -j DENY -l

7.5. In final

- Stergerea regulilor ce blocheaza pachetele:

ipchains -D input 1
ipchains -D forward 1
ipchains -D output 1

8. Anexa: Diferente intre ipchains si ipfwadm

Unele dintre aceste modificari sunt un rezultat al schimbarilor din kernel, si
unele al faptului ca ipchains este diferit de ipfwadm

1. Multe argumente au fost schimbate: literele mari indica o comanda, literele
mici indica o optiune.

2. Chain-uri arbitrare sunt posibile, deci chiar si chain-urile predefinite
au nume intregi in loc de argumente (ex. “input” in loc de “-I”).

3. Optiunea “-k” a disparut: foloseste “! -y”.

4. Optiunea “-b” defapt introduce/sterge/adauga doua reguli, ma degraba decat
o singura regula bidirectionala.

5. Optiunea “-b” poate fi folosita impreauna cu “-C” pentru a realiza doua
verificari (cate una in fiecare directie).

6. Optiunea “-x” in folosire cu “-l” a fost inlocuit cu “-v”.

7. Porturi multiple sursa si destinatie nu mai sunt suportate. Din fericire
faptul ca se pot nega siruri de porturi a indreptat pe undeva acest lucru.

8. Interfetele pot fi specificate numai prin nume (nu si prin adrese). Vechea
sintaxa s-a schimbat in liniste oricum pentru kernelurile versiunea 2.1.

9. Fragmentele sunt examinate, nu mai sunt permise automat.

10. Accounting chain-urile explicite au fost inlaturate

11. Protocoale diferite peste IP pot fi testate.

12. Comportamentul vechi pentru potrivirea SYN si ACK (care inainte a fost
ignorat pentru pachetele non-TCP) s-a schimbat; optiunea SYN nu este valida
pentru reguli care nu sunt specifice TCP.

13. Counterele sunt acum pe 64 de biti pentru masini pe 32 de bit, nu pe 32 de
biti.

14. Inversarea optiunilor este posibila.

15. Codurile ICMP sunt suportate acum.

16. Definirea mai multe interfete odata este suportata.

17. Manipularea TOS este acum verificata: inainte kernelul te oprea in
liniste, acum ipchains returneaza o eroare pentru cazurile invalide.

8.1. Tabel pentru informare rapida

[ In principal, argumentele pentru comenzi sunt cu litere mari, si argumentele
pentru optiuni sunt cu litere mici ]

Inca un lucru de observat, masquerading este specificat prin “-j MASQ”, este
complet diferit fata de “-j ACCEPT”, si nu tratat doar ca un efect secundar,
cum face ipfwadm.

================================================================
| ipfwadm | ipchains | Note
—————————————————————-
| -A [both] | -N acct | Creeaza un chain “acct”
| |& -I 1 input -j acct | si determina pachetele din
| |& -I 1 output -j acct | chain-ul input si output
| |& acct | sa il traverseze
—————————————————————-
| -A in | input | O regula fara nici o tinta
—————————————————————-
| -A out | output | O regula fara nici o tinta
—————————————————————-
| -F | forward | Foloseste acesta ca [chain].
—————————————————————-
| -I | input | Foloseste acesta ca [chain].
—————————————————————-
| -O | output | Foloseste acesta ca [chain].
—————————————————————-
| -M -l | -M -L |
—————————————————————-
| -M -s | -M -S |
—————————————————————-
| -a policy | -A [chain] -j POLICY | (dar vezi -r si -m).
—————————————————————-
| -d policy | -D [chain] -j POLICY | (dar vezi -r si -m).
—————————————————————-
| -i policy | -I 1 [chain] -j POLICY| (dar vezi -r si -m).
—————————————————————-
| -l | -L |
—————————————————————-
| -z | -Z |
—————————————————————-
| -f | -F |
—————————————————————-
| -p | -P |
—————————————————————-
| -c | -C |
—————————————————————-
| -P | -p |
—————————————————————-
| -S | -s | Accepta un port sau un sir
| | | nu valori multiple.
—————————————————————-
| -D | -d | Accepta un port sau un sir
| | | nu valori multiple.
—————————————————————-
| -V | | Foloseste -i [nume].
—————————————————————-
| -W | -i |
—————————————————————-
| -b | -b | Acum sunt defapt 2 reguli.
—————————————————————-
| -e | -v |
—————————————————————-
| -k | ! -y | Nu functioneaza daca nu
| | | este specificat -p tcp.
—————————————————————-
| -m | -j MASQ |
—————————————————————-
| -n | -n |
—————————————————————-
| -o | -l |
—————————————————————-
| -r [redirpt] | -j REDIRECT [redirpt] |
—————————————————————-
| -t | -t |
—————————————————————-
| -v | -v |
—————————————————————-
| -x | -x |
—————————————————————-
| -y | -y | Nu functioneaza daca nu
| | | este specificat -p tcp.
—————————————————————-

8.2. Exemple de comenzi ipfwadm translatate in ipchains

Comanda veche: ipfwadm -F -p deny

Comanda noua: ipchains -P forward DENY

Comanda veche: ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0

Comanda noua: ipchains -A forward -j MASQ -s 192.168.0.0/24 -d
0.0.0.0/0

Comanda veche: ipfwadm -I -a accept -V 10.1.2.1 -S 10.0.0.0/8 -D
0.0.0.0/0

Comanda noua: ipchains -A input -j ACCEPT -i eth0 -s 10.0.0.0/8 -d
0.0.0.0/0

(Observa ca nu exista nici un echivalent pentru a specifica interfata prin
adresa: foloseste numele interfetei. Pe aceasta masina, 10.1.2.1 corespunde cu
eth0).

9. Anexa: Folosirea scriptului ipfwadm-wrapper

Scriptul ipfwadm-wrapper ar trebui sa fie un inlocuitor pentru ipfwadm pentru
compatibilitate cu ipfwadm 2.3a.

Singura optiune pe care nu o poate folosi este “-V”. Cand aceasta este
folosita un avertisment este afisat. Daca optiunea “-W” este deasemenea
folosita, optiunea “-V” este ignorata. In caz contrar, scriptul incearca sa
gaseasca numele interfetei asociata cu aceea adresa folosind ifconfig. Daca
acest lucru nu reuseste (cum ar fi din cauza ca interfata nu este activata)
atunci scriptul se opreste cu un mesaj de eroare.

Acest avertizment poate fi ascuns daca se inlocuieste “-V” cu “-W”, sau
redirectand output-ul scriptului catre /dev/null.

Daca gasesti greseli in acest script, sau lucruri care sunt diferite intre
realul ipfwadm si acest script, te rog sa imi trimiti bug-ul: trimite un
e-mail la rusty@linuxcare.com cu “BUG-REPORT” in campul subiectului. Te rog sa
listezi versiunea ta de ipfwadm (ipfwadm -h), versiunea de ipchains (ipchains
–version) si versiunea scriptului ipfwadm wrapper (ipfwadm-wrapper
–version). Trimite de asemenea output-ul pentru ipchains-save. Multumiri
anticipate.

Folosirea impreuna a acestui script si ipchains este riscul tau.

10. Anexa: Multumiri.

Multe multumiri pentru Michael Neuling, care a realizat prima versiune de cod
pentru IP chains in timp ce lucra pentru mine. Imi cer scuze in mod public
pentru ca nu am luat in considerare ideea sa de result-caching, pe care a
propus-o mai tarziu Alan Cox, si pe care in final am inceput sa o implementez,
observand greselile mele.

Multumiri lui Alan Cox, pentru tech suport de 24 de ore prin e-mail, si pentru
incurajari.

Multumiri tuturor autorilor codului ipfwadm si ipfw, in special lui Jos Vos.

Multumiri pentru beta-testeri si vanatorii de bug-uri in special lui: Jordan
Mendelson, Shaw Carruthers, Kevin Moule, Dr. Liviu Daia, Helmut Adams,
Franck Sicard, Kevin Littlejohn, Matt Kemner, John D. Hardin, Alexey
Kuznetsov, Leos Bitto, Jim Kunzman, Gerard Gerritsen, Serge Sivkov,
Andrew Burgess, Steve Schmidtke, Richard Offer, Bernhard Weisshuhn,
Larry Auton, Ambrose Li, Pavel Krauz, Steve Chadsey, Francesco
Potorti`, Alain Knaff, Casper Boden-Cummins and Henry Hollenberg.

10.1. Traduceri

Oamenii care realizeaza traduceri ar trebui sa se puna la inceputul paginii de
Multumiri, astfel:”Multe multumiri lui XXX, pentru traducerea exacta din
engleza. Apoi spune-mi despre traducere ta, pentru a putea sa te includ aici.

Arnaud Launay, asl@launay.org:

http://www.freenix.fr/unix/linux/HOWTO/IPCHAINS-HOWTO.html

Giovanni Bortolozzo, borto@pluto.linux.it:

http://www.pluto.linux.it/ildp/HOWTO/IPCHAINS-HOWTO.html

Herman Rodrнguez, herman@maristas.dhis.org:

http://netfilter.kernelnotes.org/ipchains/spanish/HOWTO.html

CUM SA administrati rapid un DNS. HOWTO

admin — Wed, 06 Apr 2011 12:29:27 +0000

DNS HOWTO
Nicolai Langfeldt (janl@linpro.no), Jamie Norrish and others
Version 3.1, 2001-01-18
Traducerea: Victor Plugaru(vuk@go.ro). Cu scuzele de rigoare
pentru eventualele greseli si/sau inadvertente.

CUM SA administrati rapid un DNS.
______________________________________________________________________

Cuprins

1. Preambul

1.1 Chestiuni legale
1.2 Credit si cereri de suport.
1.3 Dedicatie

2. Introducere.

3. Caching name server.

3.1 Pornirea lui named
3.2 Resolvere
3.3 Felicitari

4. Forwarding

5. Un domeniu simplu

5.1 Intai teorie seaca
5.2 Propriul nostru domeniu
5.3 Zona reverse
5.4 Cuvinte de atentionare
5.5 De ce nu functioneaza interogarile inverse.
5.5.1 Zona reverse nu este investita.
5.5.2 Aveti un subnet fara clase
5.6 Servere slave (sclav)

6. Optiuni de securitate fundamentale.

6.1 Restrictionarea transferurilor pe zone
6.2 Protectia in situatii de spoofing
6.3 Rularea lui named ca non-root

7. Un exemplu real de domeniu

7.1 /etc/named.conf (sau /var/named/named.conf)
7.2 /var/named/root.hints
7.3 /var/named/zone/127.0.0
7.4 /var/named/zone/land-5.com
7.5 /var/named/zone/206.6.177

8. Intretinere

9. Conversia de la versiunea 4 la versiunea 8

10. Intrebari si raspunsuri

11. Cum sa deveniti un administrator DNS la scara mare.

______________________________________________________________________

1. Preambul

Cuvinte cheie: DNS, BIND, BIND 4, BIND 8, named, dialup, ppp, slip, ISDN,
internet, domeniu, nume, rezolutie, hosturi, caching.

Acest document este parte din Proiectul Documentatiei Linux (Linux
Documentation Project)

1.1. Chestiuni legale

(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co.
Nu distribuiti modificand fara copyright, distribuiti liberi dar
pastrati mesajul de copyright.

1.2. Credite si cereri de suport

Vreau sa multumesc lui Arnt Gulbrandsen caruia i-am cauzat suferinta
cu aceste tiparituri si care mi-a oferit multe sugestii utile. Vreau
sa multumesc de asemeni numeroselor persoane care mi-au trimis sugestii si
note prin e-mail.

Acesta nu va fi niciodata un document final; va rog sa imi trimiteti
e-mailuri despre problemele si succesele dumneavoastra. Puteti da o mana
de ajutor la imbunatatirea acestui HOWTO. Asa ca va rog sa trimiteti
comentarii si/sau sugestii la janl@linpro.no. Sau cumparati cartea mea
despre DNS. Vedeti bibliografia despre informatii in legatura cu aceasta
chestiune. Daca trimiteti un e-mail si asteptati raspunsuri, dati dovada de
curtoazie si asigurati-va ca adresa de reply este corecta si functioneaza.
Tot astfel, va rog sa cititi sectiunea “qanda” inainte de a-mi trimite
e-mail. Inca un lucru, inteleg doar limbile norvegiana si engleza.

Acesta este un HOWTO (CUM_SA). L-am intretinut ca parte a LDP din 1995. Am
scris, in timpul anului 2000 o carte pe aceiasi tema. Vreau sa spun ca,
desi acest HOWTO este asemanator cartii din multe puncte de vedere, nu
este o versiune redusa astfel incat sa promovez vinderea cartii. Veti gasi
cartea in bibliografie in finalul acestui HOWTO. Cititorii acestui HOWTO
m-au ajutat sa inteleg ceea ce e dificil de inteles in legatura cu
DNS. Aceasta m-a ajutat la carte, iar cartea m-a ajutat de asemeni
sa inteleg la ce ar servi acest HOWTO. Acest HOWTO a completat cartea.
Cartea a completat versiunea 3 a acestui HOWTO. Multumirile mele
editorului cartii, care si-a incercat norocul cu mine

1.3. Dedicatie

Acest HOWTO este dedicat lui Anne Line Norheim Langfeldt, desi dansa nu il
va citi niciodata pentru ca nu e genul.

1. Introducere

Ce este si ce nu este aceasta.

DNS este Domain Name System (Sistemul Domeniului de Nume). DNS converteste
numele masinilor (de calcul) in adrese IP pe care toate masinile de pe
Internet le au. Translateaza (sau “mapeaza” cum se zice in jargon) din
nume in adrese si din adrese in nume, precum si alte cateva lucruri. Acest
HOWTO documenteaza definirea acestor mapari folosind sisteme UNIX, cu
cateva lucruri specifice Linux-ului.

O mapare este o simpla asociere intre doua lucruri, in acest caz un nume
de masina, ca ftp.linux.org, si IP-ul masinii (sau adresa)
199.249.150.4. DNS-ul contine de asemeni mapari si in alt sens, din
IP catre numele masinii; aceasta se numeste “mapare inversa”

DNS este, pentru neinitiati (dumneavoastra , una dintre
cele mai obscure domenii din administrarea retelelor. Din fericire, DNS nu
este chiar asa de greu. Acest HOWTO va incerca sa va clarifice
cateva lucruri. Descrie cum sa setati un server de nume DNS simplu,
incepand doar cu un server cache si pana la a seta un sever DNS primar
pentru domeniu. Pentru setari mai complexe consultati sectiunea “qanda”
din acest document. Daca nu este descris acolo (ceea ce va trebuie),
va trebui sa consultati documentatie “adevarata”. Voi reveni si voi arata
in ce consta aceasta documentatie “adevarata” in “ultimul capitol”.

Inainte de a incepe ar trebui sa va configurati masina astfel incat sa
puteti folosi telnet de la si catre aceasta masina si sa puteti face tot
felul de conexiuni in retea, si in special sa puteti da telnet 127.0.0.1
si sa reusiti sa intrati pe propria masina (ar trebui sa incercati
asta chiar acum!). Va trebuie de asemeni fisierele /etc/nsswitch.conf,
/etc/resolv.conf si /etc/hosts corecte, ca punct de plecare pentru ca nu
le voi explica functiile aici. Daca nu aveti toate acestea configurate si
in stare de functionare, Networking-HOWTO si/sau Networking-Overview-HOWTO
explica cum sa le configurati. CItiti-le.

Cand spun “masina dumneavoastra” inteleg masina pe care vreti
sa configurati DNS, nu orice alta masina pe care o aveti si care ar fi
implicata in efortul de a pune la punct reteaua.

Presupun ca nu sunteti in spatele nici unui fel de firewall care blocheaza
interogarile de nume. Daca sunteti in atare situatie, vedeti sectiunea
“quanda”.

Serverul de nume in UNIX este indeplinit de un program numit named. Acesta
este o parte a pachetului “BIND” coordonat de The Internet
Software Cosortium. Named este inclus in majoritatea distributiilor de Linux
si este de obicei instalat in /usr/sbin/named, de obicei dintr-un pachet
BIND.

Daca aveti un named probabil ca il puteti si folosi. Daca nu aveti unul,
puteti lua distributia binara de de pe un site ftp Linux, sau luati ultima
si cea mai “tare” sursa de la . Acest
HOWTO se refera la BIND versiunea 8. Versiunea veche a acestui document,
despre BIND 4 este inca disponibila la .
in caz ca folositi BIND 4. Daca paginile man ale named (chiar la sfarsit,
in sectiunea FILES) fac referire la named.conf, aveti BIND 8. Daca fac
referire la named.boot, aveti BIND 4. Daca aveti BIND 4
si sunteti constient de problemele de securitate, ar fi bine sa faceti
uprade la BIND 8. Acum.

DNS este o baza de date distribuita in retea. Aveti grija ce puneti in ea.
Daca puneti “balarii” in ea, dumneavoastra si altii, tot “balarii”
veti avea. Mentineti DNS-ul restrans si consistent si veti avea parte de
servicii de buna calitate de la el. Invatati sa il folositi, administrati,
depanati si veti fi inca un bun administrator, evitand ingenuncherea
Internetului din cauza prostului management.

Indicatie: faceti copii de rezerva a tuturor fisierelor pe care va indic
sa le modificati, daca le aveti deja, asa incat daca trecand
prin acestea (configurari, modificari) nimic nu mai merge, sa puteti
reveni la vechea dumneavoastra stare de functionare.

3. Caching name server

Un prim model de configurarie DNS, foarte util pentru dialup, modem
de cablu si utilizatori ADSL.

In distributiile Redhat si inrudite puteti obtine aceleasi rezultate
practice ca in prima sectiune a acestui HOWTO, instaland
pachetul BIND, utilitarele bind si caching-nameserver-ul. Daca
folositi Debian, instalati bind si bind-doc. Bine inteles ca
doar instaland aceste pachete nu veti invata atat de mult ca si cand ati
citi acest HOWTO. Asa ca instalati pachetele si verificati fisierele
instalate.

Un server cache de nume va gasi raspunsuri la interogarile de nume si va
memora aceste raspunsuri pentru data viitoare cand veti
avea nevoie. Aceasta va scurta semnificativ timpul de asteptare urmatoarea
data, in special daca aveti o conexiune lenta.

In primul rand aveti nevoie de un fisier numit /etc/named.conf
(Debian: /etc/bind/named.conf). Acesta este citit cand named porneste.
Deocamdata ar trebui sa contina pur si simplu:

______________________________________________________________________
// Config file for caching only name server

options {
directory “/var/named”;

// Uncommenting this might help if you have to go through a
// firewall and things are not working out. But you probably
// need to talk to your firewall admin.

// query-source port 53;
};

zone “.” {
type hint;
file “root.hints”;
};

zone “0.0.127.in-addr.arpa” {
type master;
file “pz/127.0.0″;
};
______________________________________________________________________

Pachetele distributiilor Linux pot folosi diferite nume de fisiere
pentru fiecare tip de fisier mentionat aici, cu toate acestea, continutul
va fi identic.

Linia “directory” ii spune lui named unde sa caute fisiere. Toate fisierele
named subsecvente vor fi relative la aceasta. pz este un director sub
/var/named, de ex. /var/named/pz. /var/named este directorul corect
potrivit Standardului de Fisiere Linux.

Fisierul /var/named/root.hints ar trebui sa contina urmatoarele: (daca
execuati cut si paste dintr-o versiune electronica a acestui document,
aveti in vedere ca nu trebuie sa existe spatii de inceput in acest fisier,
de exemplu toate liniile trebuie sa inceapa cu un caracter
non-blank. Anumite programe de procesare de text vor insera spatii
la inceputul liniilor, cauzand confuzie. In acest caz va rog
sa indepartati spatiile goale.)

______________________________________________________________________
;
; There might be opening comments here if you already have this file.
; If not don’t worry.
;
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
;
M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33
I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12
______________________________________________________________________

Fisierul descrie serverele de nume “radacina” din lume. Acestea se schimba
in timp si trebuie mentinute permanent. Vedeti sectiunea “intretinere”
despre cum sa mentineti la curent acest fisier.

Urmatoarea sectiune in named.conf este ultima zona. II voi explica
utilizarea intr-un capitol ulterior. Deocamdata creati din aceasta un
fisier numit 127.0.0 in subdirectorul pz (din nou, indepartati
spatiile goale daca executati cut si paste).

______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
______________________________________________________________________

Pe urma, aveti nevoie de un fisier /etc/resolv.conf care sa arate cam asa:
(indepartati spatiile!)

______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1
______________________________________________________________________

Linia “search” specifica ce domenii ar trebui cautate pentru un nume de
host la care vreti sa va conectati. Linia “nameserver” indica serverul
dumneavoastra de nume, in acest caz propria dumneavoastra masina,
daca acolo ruleaza named (127.0.0.1 e perfect, nu conteaza ca mai aveti si
alta adresa IP). Daca doriti sa apara mai multe servere de nume, puneti
cate o linie “nameserver” pentru fiecare. (Nota: named niciodata
nu citeste acest fisier, ci rezolverul, programul care il utilizeaza
pe named. Nota2 :in unele fisiere resolv.conf gasiti o linie “domain”. E
in regula, dar nu folositi si “search” si “domain”, doar una dintre ele va
merge).

Pentru a ilustra ce face acest fisier: daca un client incearca
sa caute (hostul) “foo”, atunci foo.subdomeniu.domeniul-tau.edu este
incercat primul, apoi foo.domeniul-tau.edu si apoi foo. Nu e de preferat
sa puneti prea multe domenii in linia “search” pentru ca va dura mult sa
le interogheze pe toate.

Exemplul de mai sus presupune ca apartineti domeniului
subdomeniu.domeniul-tau.edu; atunci masina dumneavoastra este numita
probabil masina-ta.subdomeniu.domeniul-tau.edu Linia “search” n-ar trebui
sa contina TLD-ul dumneavoastra (Top Level Domain “edu”- Domeniul de Nivel
Inalt) in acest caz. Daca aveti nevoie sa va conectati
la hosturi din alt domeniu, in mod frecvent, puteti adauga acel domeniu in
linia “search” astfel: (indepartati spatiile!)

______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu other-domain.com
______________________________________________________________________

si asa mai departe. Evident, trebuie sa puneti nume reale de domeniu
in locul celor din exemplu. Importat: observati lipsa punctelor de
la sfarsitul numelor de domeniu.

3.1 Pornirea lui named

Dupa toate acestea este timpul sa pornim named. Daca folositi o conexiune
dialup, conectati-va intai. Dati comanda “ndc start” si apasati Enter,
fara nici o optiune. Daca nu merge asa, incercati “/usr/sbin/ndc start”.
Daca tot nu merge, vedeti sectiunea “qanda”. Daca observati in
fisierul mesajelor syslog (de obicei /var/adm/messages sau
/var/log/messages) in timp ce porniti named (incercati tail -f
/var/log/messages), ar trebui sa vedeti ceva asemanator :

(liniile care se incheie in \ continua pe linia urmatoare)

Dec 15 23:53:29 localhost named[3768]: starting. named 8.2.2-P7 \
Fri Nov 10 04:50:23 EST 2000^Iprospector@porky.\
devel.redhat.com:/usr/src/bs/BUILD/bind-8.2.2_P7/\
src/bin/named
Dec 15 23:53:29 localhost named[3768]: hint zone “” (IN) loaded\
(serial 0)
Dec 15 23:53:29 localhost named[3768]:Zone “0.0.127.in-addr.arpa”\
(file pz/127.0.0): No default TTL set using SOA\
minimum instead
Dec 15 23:53:29 localhost named[3768]: master zone\
“0.0.127.in-addr.arpa” (IN) loaded (serial 1)
Dec 15 23:53:29 localhost named[3768]:listening on [127.0.0.1].53 (lo)
Dec 15 23:53:29 localhost named[3768]: listening on [10.0.0.129].53\
(wvlan0)
Dec 15 23:53:29 localhost named[3768]: Forwarding source address is\
[0.0.0.0].1034
Dec 15 23:53:29 localhost named[3769]: Ready to answer queries.

Daca sunt multe mesaje de eroare, trebuie sa fie o greseala
pe undeva. Named va indica fisierul unde se afla greseala. Reveniti si
verificati fisierul respectiv. Dati comanda “ndc restart” si ati
rezolvat problema.

Acum puteti testa configurarea. In mod traditional, un program numit
nslookup e folosit pentru aceasta. In mod curent, dig e recomandat.

$ dig -x 127.0.0.1

; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY:1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.

;; Total query time: 30 msec
;; FROM: lookfar to SERVER: default — 127.0.0.1
;; WHEN: Sat Dec 16 00:16:12 2000
;; MSG SIZE sent: 40 rcvd: 110

Daca ati obtinut aceasta, serviciul functioneaza. Speram. Daca treburile
stau altfel, reveniti si verificati totul. De fiecare data cand moficati
fisierul named.conf, trebuie sa reporniti named cu comanda ndc restart.

Acum puteti efectua o interogare. Incercati sa cautati o masina apropiata.
pat.uio.no este apropiata de mine, la Universitatea din Oslo.

$ dig pat.uio.no

; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode:QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY:3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN

;; ANSWER SECTION:
pat.uio.no. 1D IN A 129.240.130.16

;; AUTHORITY SECTION:
uio.no. 1D IN NS nissen.uio.no.
uio.no. 1D IN NS ifi.uio.no.
uio.no. 1D IN NS nn.uninett.no.

;; ADDITIONAL SECTION:
nissen.uio.no. 1D IN A 129.240.2.3
ifi.uio.no. 1H IN A 129.240.64.2
nn.uninett.no. 1D IN A 158.38.0.181

;; Total query time: 112 msec
;; FROM: lookfar to SERVER: default — 127.0.0.1
;; WHEN: Sat Dec 16 00:23:07 2000
;; MSG SIZE sent: 28 rcvd: 162

De data aceasta dig a cerut lui named sa caute masina pat.uio.no.
A contactat una dintre masinile server de nume indicate in fisierul
root.hints si a cerut calea de acolo. Poate dura putin pana obtine
rezultatul, dupa cum va trebui sa caute in domeniile din /etc/resolv.conf.
Observati “aa” in linia “flags:”. Inseamna ca raspunsul este
autoritativ, venit proaspat de la un server autoritativ. Voi explica
ce inseamna “autoritativ” mai tarziu.

Daca veti face aceiasi interogare din nou, veti obtine aceasta:

$ dig pat.uio.no

; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status:NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN

;; ANSWER SECTION:
pat.uio.no. 23h59m58s IN A 129.240.130.16

;; AUTHORITY SECTION:
UIO.NO. 23h59m58s IN NS nissen.UIO.NO.
UIO.NO. 23h59m58s IN NS ifi.UIO.NO.
UIO.NO. 23h59m58s IN NS nn.uninett.NO.

;; ADDITIONAL SECTION:
nissen.UIO.NO. 23h59m58s IN A 129.240.2.3
ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2
nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181

;; Total query time: 4 msec
;; FROM: lookfar to SERVER: default — 127.0.0.1
;; WHEN: Sat Dec 16 00:23:09 2000
;; MSG SIZE sent: 28 rcvd: 162

Observati lipsa flagului “aa” din acest rezultat. Inseamna ca named
nu a mai iesit in retea pentru a afla acest raspuns, daca informatia se
afla in cache acum. Dar informatia din cache poate fi veche (stale). Asa
ca sunteti informati despre aceasta (foarte subtil)
prin lipsa lui “aa”. Dar oricum, acum stiti ca serviciul cache functioneaza.

3.2. Rezolvere

Toate sistemele de operare care implementeaza standardul C API fac uz de
apelul gethostbyname si gethostbyaddr. Acestea pot obtine informatii din
diverse surse. Din ce surse se alimenteaza, este indicat in fisierul
/etc/nsswitch.conf in Linux (si alte UNIX-uri). Acesta este un fisier lung
care specifica din ce fisier sau baza de date se vor obtine diferitele
tipuri de date. De obicei contine informatii folositoare la inceput, pe
care ar trebui sa le cititi. Dupa aceasta, cautati linia incapand cu
“hosts:”; va trebui sa aveti:

______________________________________________________________________
hosts: files dns
______________________________________________________________________

(va aduceti aminte de spatiile de inceput, nu-i asa? Nu le voi mai mentiona)

Daca nu exista nici o linie cu “hosts:”, puneti una ca mai
sus. Aceasta indica cum ca programele ar trebui sa examineze
fisierul /etc/hosts intai, apoi sa verifice DNS-ul conform /etc/resolv.conf.

3.3. Felicitari

Acum deja stiti cum sa configurati un named cu caching. Luati o bere, un
lapte acru si sarbatoriti.

4. Forwarding

In retele mari, bine organizate, academice sau ISP (Internet Service
Provider – Furnizor de Servicii Internet), veti constata uneori ca
administratorii de retea au pus la punct o ierarhie de servere DNS
pentru forwarding (inaintare- transfer), care usureaza
incarcarea retelei interiorare si exterioare. Nu e usor de stiut daca va
aflati intr-o asemenea retea sau nu. Oricum, nu este important si,
folosind serverul DNS al furnizorului dumneavoastra din retea ca “forwarder”
puteti obtine raspunsurile mai rapid si cu o incarcare mai mica a retelei.
Daca folositi un modem, aceasta poate fi chiar un castig. De
dragul acestui exemplu sa presupunem ca furnizorul are doua servere de
nume pe care vrea sa le folositi cu IP-urile 10.0.0.1 si 10.1.0.1. Atunci,
in named.conf la dumneavoastra, in interiorul sectiunii “options”,
inserati aceste linii:

______________________________________________________________________
forward first;
forwarders {
10.0.0.1;
10.1.0.1;
};
______________________________________________________________________

Exista de asemeni o smecherie draguta pentru masinile dialup care folosesc
“forwardere”. Este descrisa in sectiunea “qanda”.

Restartati serverul de nume si testati-l cu dig. Ar trebui sa mearga perfect.

5. Un domeniu simplu

Cum configurati propriul domeniu.

5.1. Intai teorie seaca

In primul rand: ati citit tot pana aici, nu? Trebuie.

Inainte de a porni intr-adevar aceasta sectiune, va voi expune ceva
teorie si un exemplu despre cum functioneaza DNS. Si o veti citi pentru ca
va este necesara. Daca nu doriti, ar trebui macar sa o parcurgeti rapid.
Opriti-va din cititul printre randuri cand ajungeti la ceea ce ar trebui
sa aveti in fisierul named.conf.

DNS este un sistem ierarhic, arborescent. Varful este notat “.” si
este denumit “root”, cum este uzual pentru structurile de
date arborescente. Dedesubt exista un numar de Top Level Domain – Domenii
de Nivel Inalt – TLD-uri. Cele mai cunoscute sunt .COM .ORG .EDU .NET, dar
sunt mai multe. Ca si la un arbore, exista o radacina care se imparte pe
ramuri. Daca aveti ceva cunostinte despre computere, veti recunoaste DNS
ca un arbore de cautare si veti fi capabili sa gasiti nodurile nodurile
mici (leaf nodes) si marginile (edges). Punctele sunt noduri, marginile
sunt in nume. Cand cautati o masina, interogarea porneste recursiv
in ierarhie, plecand de la radacina (root). Daca doriti sa aflati adresa
pentru prep.ai.mit.edu, serverul dumneavoastra de nume va incepe
sa caute undeva. Incepe prin a cauta in cache. Daca stie raspunsul,
avandu-l in cache mai dinainte, va raspunde imediat, asa cum am vazut in
ultima sectiune. Daca nu stie, va indeparta partea din nume incepand de la
stanga, verificand daca stie ceva despre ai.mit.edu, apoi mit.edu., apoi
edu., si apoi daca nu cumva “.” are cunostinta, pentru ca asa s-a specificat in
fisierul hints (indicii). Apoi va intreba un server “.” (root)
despre prep.ai.mit.edu. Acest server “.” nu va sti raspunsul dar
va ajuta serverul dumneavoastra in calea sa, dandu-i o referinta,
spunandu-i unde sa mai caute. Aceste referinte vor conduce eventual
serverul dumneavoastra catre un server de nume care cunoaste
raspunsul. Voi ilustra aceasta acum, “+norec” inseamna ca “dig” aplica
interogari ne-recursive, asa ca va trebui sa aplicam chiar noi
recursivitatea. Cealalta optiune ar fi sa reducem cantitatea de date
pe care “dig” o produce asa incat sa nu avem de-a face cu prea multe pagini:

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu.
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; AUTHORITY SECTION:
. 5d23h48m47s IN NS I.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS E.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS D.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS A.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS H.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS C.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS G.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS F.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS B.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS J.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS K.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS L.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS M.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6d23h48m47s IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.32.64.12
M.ROOT-SERVERS.NET. 6d23h48m47s IN A 202.12.27.33

Aceasta este referinta. Ne ofera doar o “sectiune autoritativa”
nu o “sectiune de raspuns”. Propriul nostru nameserver ne raporteaza
la alt nameserver. Alegeti la intamplare:

$ dig +norec +noH +noques +nostats +nocmd
prep.ai.mit.edu. @H.ROOT-SERVE
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
MIT.EDU. 2D IN NS BITSY.MIT.EDU.
MIT.EDU. 2D IN NS STRAWB.MIT.EDU.
MIT.EDU. 2D IN NS W20NS.MIT.EDU.

;; ADDITIONAL SECTION:
BITSY.MIT.EDU. 2D IN A 18.72.0.3
STRAWB.MIT.EDU. 2D IN A 18.71.0.151
W20NS.MIT.EDU. 2D IN A 18.70.0.160

Se refera la serverele MIT.EDU odata. Din nou, alegeti unul la intamplare:

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @bitsy.mit.edu
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 3h50m7s IN A 198.186.203.18

;; AUTHORITY SECTION:
AI.MIT.EDU. 6H IN NS FEDEX.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS LIFE.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS ALPHA-BITS.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS BEET-CHEX.AI.MIT.EDU.

;; ADDITIONAL SECTION:
FEDEX.AI.MIT.EDU. 6H IN A 192.148.252.43
LIFE.AI.MIT.EDU. 6H IN A 128.52.32.80
ALPHA-BITS.AI.MIT.EDU. 6H IN A 128.52.32.5
BEET-CHEX.AI.MIT.EDU. 6H IN A 128.52.32.22

DE data aceasta avem o “sectiune de raspuns” si un raspuns la interogarea
noastra. “Sectiunea autoritativa” contine informatii despre ce servere
sa interogam despre ai.mit.edu data viitoare. Asa ca le puteti interoga
data viitoare direct despre ce nume va intereseaza din domeniul ai.mit.edu.

Deci pornind de la “.” am gasit serverele de nume pentru fiecare nivel
in numele de domeniu, prin referinte. Daca ati folosit propriul
server de nume in loc de alte servere,
nameserverul dumneavoastra a stocat, bineinteles in cache, toata
informatia pe care a gasit-o “sapand” (comanda “dig”) pentru aceasta, si
nu va trebui sa cerceteze mult pentru raspunsuri, un timp.

In structura arborescenta analoga, fiecare “.” este un punct
de ramificatie si fiecare parte intre “.” reprezinta
numele ramurilor individuale in arbore. Unul urca pe arbore luand numele
pe care il dorim (prep.ai.mit.edu) intreband root-ul “.” sau orice
server parinte dinspre root catre prep.ai.mit.edu despre care
avem informatii in cache. Odata ce limitele cache-ului
sunt atinse, rezolverul recursiv “iese” interogand serverele, obtinand
referinte (margini – edges) in nume.

Un domeniu mai putin discutat, dar la fel de important
este in-addr.arpa. Este de asemeni catalogat ca un domeniu “normal” ne
permite sa obtinem numele host-ului cand ii cunoastem adresa. Un lucru
important de retinut aici este ca adresele IP sunt scrise in
ordine inversa in domeniul in-addr.arpa. Daca aveti adresa unei masini, de
exemplu 192.148.52.43, named procedeaza ca in exemplul cu
prep.ai.mit.edu:
cauta serverele arpa. , cauta serverele in-addr.arpa, cauta serverele
192.in-addr.arpa. , cauta serverele 148.192.in-addr.arpa., cauta serverele
52.148.192.in-addr.arpa. , cauta inregistrarile necesare pentru
43.52.148.192.in-addr.arpa. Inteligent, nu? (Spuneti “da”.) Reversia
numerelor poate crea confuzie.

5.2. Propriul nostru domeniu

Acum sa definim propriul nostru domeniu. Vom face domeniul linux.bogus
si vom defini masini in el. Voi folosi nume de domenii total aiurea,
astfel incat sa ne asiguram ca nu deranjam pe nimeni Acolo Afara.

Inca un lucru inainte de a incepe. Nu toate caracterele sunt permise
in numele de domenii. Suntem restrictionati la caracterele din alfabetul
englez: a-z si numere 0-9 si caracterul “-”. Limitati-va la aceste
caractere. Caracterele majuscule si minuscule sunt identice pentru DNS,
deci pat.uio.no este identic cu Pat.Uio.No.

Am pornit deja aceasta parte cu o linie in named.conf:

______________________________________________________________________
zone “0.0.127.in-addr.arpa” {
type master;
file “pz/127.0.0″;
};
______________________________________________________________________

Va rog sa observati lipsa lui “.” la sfarsitul numelor de domeniu in acest
fisier. Acesta spune ca acum vom definit zona 0.0.127.in-addr.arpa, care
este serverul master pentru ea si care este stocat in fisierul numit
pz/127.0.0. Deja am configurat acest fisier, care arata:

Observati “.” la sfarsitul fiecarui nume de domeniu in acest fisier,
in contrast cu named.conf de mai sus. Unii prefera sa inceapa fiecare zona
cu directiva $ORIGIN, dar aceasta configurare este superflua. Originea
(din care face parte ierarhia DNS) unei fisier zona este specificata
in sectiunea “zone” din fisierul named.conf; in acest caz este
0.0.127.in-addr.arpa.

Acest “fisier zona” contine 3 “inregistrari resursa” (RR): A SOA RR. A NS
RR si un PTR RR. SOA este prescurtarea pentru Start of Authority. “@”
este notatia speciala semnificand originea, si cum coloana “domain” pentru
acest fisier indica 0.0.127.in-addr.arpa, prima linie inseamna in realitate:

0.0.127.in-addr.arpa. IN SOA …

NS este name server RR. Nu este nici un “@” la inceputul acestei linii;
este implicit pentru ca inceputul liniei anterioare incepe cu un “@”. Va
scuteste de redactat. Astfel, linia NS poate fi scrisa deasemeni:

0.0.127.in-addr.arpa. IN NS ns.linux.bogus

Aceasta spune DNS-ului ce masina este name-serverul pentru
domeniul 0.0.127.in-addr.arpa, este ns.linux.bogus. “ns” este un nume
uzitat pentru serverele de nume, dar ca si pentru serverele web care
sunt numite www.ceva numele poate fi oricare.

Si, in final, inregistrarea PTR (Domain Name Pointer – Pointerul Numelui
de Domeniu) arata ca hostul de la adresa 1 din
subnetul 0.0.127.in-addr.arpa, de exemplu 127.0.0.1 este numit localhost.

Inregistrarea SOA este preambulul tuturor fisierelor de zona, si ar trebui
sa fie exact cate una pentru fiecare fisier de zona. Aceasta descrie zona,
de unde vine (o masina numita ns.linux.bogus), cine este responsabil
pentru continutul ei (hostmaster@linux.bogus; ar trebui sa inserati adresa
dumneavoastra de e-mail aici), ce versiune a fisierului zona este (serial:1)
si alte lucruri care au de-a face cu cachingul si serverele DNS secundare.
Pentru restul campurilor (refresh, retry, expire si minimum)
folositi numerele utilizate in acest HOWTO si ar trebui sa fiti in
siguranta. Inainte de SOA apare o linie esentiala, linia $TTL 3D. Puneti
in ea toate fisierele de zona.

Acum reporniti named (cu comanda ndc restart) si folositi “dig” pentru a
examina rezultatele. -x cere o interogare inversa:

$ dig -x 127.0.0.1

; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.

;; Total query time: 5 msec
;; FROM: lookfar to SERVER: default — 127.0.0.1
;; WHEN: Sat Dec 16 01:13:48 2000
;; MSG SIZE sent: 40 rcvd: 110

Deci se descurca sa obtina localhostul din 127.0.0.1, e OK. Acum, pentru
scopul nostru principal, inserati o noua sectiune zona (“zone”) in
named.conf:

______________________________________________________________________
zone “linux.bogus” {
notify no;
type master;
file “pz/linux.bogus”;
};
______________________________________________________________________

Observati din nou lipsa “.” din numele de domeniu din fisierul named.conf.
In fisierul zona linux.bogus vom pune niste date total aiurea.

______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
NS ns ; Inet Address of name server
MX 10 mail.linux.bogus ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
______________________________________________________________________

Doua lucruri trebuie observate in legatura cu inregistrarea SOA:
ns.linux.bogus trebuie sa fie o masina cu inregistrare “A”. Nu este in
regula sa avem o inregistrarea CNAME pentru masina mentionata in
inregistrarea SOA. Numele ei nu este obligatoriu sa fie “ns”, poate
fi orice nume “legal”, acceptabil, de host. Apoi, hostmaster.linux.bogus
trebuie citit ca hostmaster@linux.bogus. Acesta ar trebui sa fie un mail
alias sau un mailbox (cutie postala) unde persoanele care intretin DNS-ul
ar trebui sa citeasca frecvent mailul. Orice mail privind domeniul va fi
trimis la adresa listata aici. Numele nu e necesar
sa fie “hostmaster”, paote fi adresa dumneavoastra normala
de e-mail, dar adresa de e-mail “hostmaster” ar trebui sa functioneze
la fel de bine.

Exista un tip nou “RR” in acest fisier, RR-ul “MX”-ului sau
Mail Exchanger-ului. Acesta indica sistemului de e-mail unde
sa trimita mailul adresat cuiva@linux.bogus, dupa nume
mail.linux.bogus sau mail.friend.bogus. Numerele din fata fiecarei
masini este prioritatea RR-ului MailExchangerului. RR-ul
cu cel mai mic numar (10) este unde mailul ar trebui sa fie trimis daca
este posibil. Daca acesta rateaza, mailul va fi trimis urmatorului
cu numar mai mare, un manager de e-mail secundar (mail handler),
de exemplu mail.friend.bogus, care are prioritatea 20 aici.

Restartati named cu “ndc restart”. Examinati rezultatul cu “dig”:

$ dig any linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23499
;; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; linux.bogus, type = ANY, class = IN

;; ANSWER SECTION:
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
linux.bogus. 3D IN MX 20 mail.friend.bogus.
linux.bogus. 3D IN NS ns.linux.bogus.
linux.bogus. 3D IN SOA ns.linux.bogus.hostmaster.linux
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum

Examinand cu atentie rezultatele de mai sus, veti descoperi o hiba. Linia

linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.

este total gresita. Ar trebui sa fie:

linux.bogus. 3D IN MX 10 mail.linux.bogus.

Am facut intentionat o greseala, ca sa puteti invata din ea . Privind
in fisierul zona, vom observa aceasta linie;

MX 10 mail.linux.bogus ; Primary Mail Exchanger

Lipseste un punct. Sau are prea multe “linux.bogus”. Daca un nume de
masina nu se termina cu punct intr-un fisier zona, originea este adaugata
la sfarsitul lui, cauzand dublura linux.bogus.linux.bogus. Asa ca ori

______________________________________________________________________
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
______________________________________________________________________

ori

______________________________________________________________________
MX 10 mail ; Primary Mail Exchanger
______________________________________________________________________

este corect. Prefer ultima forma, e mai putin de scris.
Sunt anumiti experti in BIND care dezaproba, si altii care aproba aceasta.
Intr-un fisier zona, domeniul ar trebui sa fie ori scris si terminat
in “.” ori ne inclus deloc, caz in care ramane implicita originea.

Trebuie sa va stresez cu ideea ca in fisierul named.conf nu trebuie sa fie
semne “.” dupa numele de domenii. N-aveti idee de cate ori
prea multe sau prea putine “.” au pus in stare de confuzie utilizatorii.

Deci, ideea mea aici este noul fisier zona , cu cateva informatii in plus:

______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
TXT “Linux.Bogus, your DNS consultants”
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost A 127.0.0.1

gw A 192.168.196.1
HINFO “Cisco” “IOS”
TXT “The router”

ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
HINFO “Pentium” “Linux 2.0″
www CNAME ns

donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO “i486″ “Linux 2.0″
TXT “DEK”

mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
HINFO “386sx” “Linux 1.2″

ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
HINFO “P6″ “Linux 2.1.86″
______________________________________________________________________

Aici sunt cateva noi RR-uri: HINFO (Host INFOrmation) are doua parti; e un
obicei bun sa le comentati pe fiecare. Prima parte este harware-ul si
CPU-ul din respectiva masina, iar a doua parte
este software-ul sau sitemul de operare de pe masina. Masina “ns” este
un Pentium si ruleaza Linux 2.0. CNAME (Canonical NAME) este o cale de a
da fiecarei masini mai multe nume. Deci “www” este un alias pentru “ns”.

Utilizarea inregistrarii CNAME este controversata. Dar e in OK sa urmati
regula potrivit careia o inregistrare MX, CNAME sau SOA nu trebuie sa nu
se refere niciodata la o inregistrare CNAME, trebuie intotdeauna sa se
refere la o inregistrare “A”, deci este inadmisibil sa avem:

______________________________________________________________________
foobar CNAME www ; NO!
______________________________________________________________________

dar corect sa avem

______________________________________________________________________
foobar CNAME ns ; Yes!
______________________________________________________________________

Este de asemeni sigur sa presupunem ca un CNAME nu este un nume de
host corect pentru o adresa de e-mail: webmaster@www.linux.bogus
este o adresa de e-mail ilegala, incorecta, data de configurarea de mai sus.
Va puteti chiar astepta la cativa administratori de e-mail de Afara sa
restrictioneze aceasta regula, daca pentru
dumneavoasta functioneaza. Calea pentru a evita aceasta este sa folositi
inregistrari “A” (si poate si altele, cum ar fi reguli MX) in loc:

______________________________________________________________________
www A 192.168.196.2
______________________________________________________________________

Un numar de arch-BIND-wizards recomanda sa nu utilizati de loc
CNAME. Dar discutia legata aceasta nu face obiectul acestui HOWTO.

Dar cum vedeti, acest HOWTO si multe site-uri nu urmeaza aceasta regula.

Incarcati noua baza de date cu “ndc reload” ceea ce il obliga
pe named sa-si reciteasca fisierele.

$ dig linux.bogus axfr

; <<>> DiG 8.2 <<>> linux.bogus axfr
$ORIGIN linux.bogus.
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum

3D IN NS ns
3D IN NS ns.friend.bogus.
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN TXT “Linux.Bogus, your DNS consultants”
gw 3D IN TXT “The router”
3D IN HINFO “Cisco” “IOS”
3D IN A 192.168.196.1
localhost 3D IN A 127.0.0.1
mail 3D IN HINFO “386sx” “Linux 1.2″
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.4
www 3D IN CNAME ns
donald 3D IN TXT “DEK”
3D IN HINFO “i486″ “Linux 2.0″
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.3
ns 3D IN HINFO “Pentium” “Linux 2.0″
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.2
ftp 3D IN HINFO “P6″ “Linux 2.1.86″
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.5
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum

;; Received 29 answers (29 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:35:05 2000

Asta e bine. Si observati ca arata chiar ca fisierul zona. Sa verificam ce
spune doar pentru www:

$ dig www.linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27345
;; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;; www.linux.bogus, type = A, class = IN

;; ANSWER SECTION:
www.linux.bogus. 3D IN CNAME ns.linux.bogus.
ns.linux.bogus. 3D IN A 192.168.196.2

Cu alte cuvinte, numele real al lui www.linux.bogus este ns.linux.bogus,
si va da si cateva informatii despre “ns” de asemeni, suficient pentru a
va conecta la el daca cere un program.

Acum suntem la jumatatea drumului.

5.3. Zona reverse

Acum programele pot converti numele din linux.bogus in adrese la care se
conecteaza. Dar de asemeni este ceruta o zona reverse, una care sa
faca DNS-ul capabil sa converteasca adresele in nume. Acest nume
este folosit de o multime de servere de diverse tipuri (FTP, WWW, IRC si
altele) pentru a decide daca vor comunica cu dumneavoastra sau nu, si daca
da, ce prioritate vi se va acorda. Pentru acces deplin la toate serviciile
Internet , o zona reverse este necesara.

Puneti aceasta in named.conf:

______________________________________________________________________
zone “196.168.192.in-addr.arpa” {
notify no;
type master;
file “pz/192.168.196″;
};
______________________________________________________________________

Este exact acelasi lucru ca si cu 0.0.127.in-addr.arpa si continuturile
sunt similare:

______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.

1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
______________________________________________________________________

Acum restartati named-ul cu “ndc restart” si examinati rezultatele cu “dig”:

______________________________________________________________________
$ dig -x 192.168.196.4 +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8764
;; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; 4.196.168.192.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 3D IN PTR mail.linux.bogus.
______________________________________________________________________

deci arata OK, executati “dig” pentru toata configuratia pentru a o examina:

______________________________________________________________________
dig -x 192.168.196 AXFR

; <<>> DiG 8.2 <<>> -x AXFR
$ORIGIN 196.168.192.in-addr.arpa.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum

3D IN NS ns.linux.bogus.
4 3D IN PTR mail.linux.bogus.
2 3D IN PTR ns.linux.bogus.
5 3D IN PTR ftp.linux.bogus.
3 3D IN PTR donald.linux.bogus.
1 3D IN PTR gw.linux.bogus.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum

;; Received 8 answers (8 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:44:03 2000
____________________________________________________________________

Arata bine! Daca output-ul dumneavoastra nu arata la fel, cautati eroarea
in mesajele din syslog. Am explicat cum sa faceti aceasta in prima
sectiune la paragraful “Pornirea lui named”.

5.4. Cuvinte de atentionare.

Trebuie sa adaug niste lucruri aici. Numerele IP utilizate in exemplele de
mai sus sunt luate din blocul “retelelor private”, ele nu sunt permise a
se utiliza in Internet, deci sunt potrivite a fi utilizate intr-un exemplu
ca acest HOWTO. Al doilea lucru este numarul de notificare:linia. Acesta
ii spune lui named sa nu notifice serverele secundare (slave)
cand a suferit o actualizare la unul dintre fisierele sale “zone”. In BIND 8
named poate notifica celelalte servere listate in inregistrarile NS in
fisierul “zone” cand o zona este actualizata. Aceasta situatie
este avantajoasa in mod normal. Dar pentru experimente private
cu zone, aceasta optiune ar trebui sa fie dezactivata – nu vrem sa
poluam Internetul cu experimentele noastre, nu?

Si, bineinteles, acest domeniu este total aiurea si la fel
sunt toate adresele din el. Pentru un exemplu real vedeti urmatoarea
sectiune principala.

5.5. De ce nu functioneaza interogarile inverse (reverse lookups).

Sunt cateva “chestii” care in mod normal sunt evitate la interogarile
de nume vazute adesea la configurarea zonelor inverse. Inainte
de a trece mai departe, trebuie ca pe masinile dumneavoastra, interogarile
inverse sa fie functionale pe propriul nameserver. Daca nu functioneaza,
reveniti si puneti totul la punct inainte de a continua.

Voi discuta doua situatii de nefunctionare a interogarilor
inverse, asa cum sunt vazute din afara retelei dumneavoastra.

5.5.1 Zona inversa nu este investita.

Cand cereti unui provider o plaja de adrese si un nume de domeniu,
numele de domeniu este in mod normal investit. Investirea este “eticheta”
pe care NS (Name Server) o inregistreaza si care va ajuta sa treceti de la
un nameserver la altul, asa cum am explicat in “teoria seaca” de mai
sus. Ati citit aceasta, nu-i asa? Daca zona inversa nu functioneaza,
reveniti si cititi-o. Acum.

Zona inversa trebuie de asemeni investita. Daca aveti clasa 192.168.196 de
la provider cu domeniul linux.bogus, ei trebuie sa insereze inregistrarile
NS atat pentru zona directa (forward) cat si pentru cea inversa. Daca
urmati lantul de la in-addr.arpa in sus pana la reteaua dvs, probabil
gasiti o ruptura in acest lant, cel mai probabil la providerul dvs. Gasind
ruptura din lant, contactati providerul si cereti-i sa corecteze eroarea.

5.5.2. Aveti un subnet fara clase.

Acesta este oarecum un subiect avansat, dar subneturile fara clase sunt
ceva comun in ziua de azi si probabil ca aveti unul daca sunteti intr-o
firma mica.

Un subnet fara clase este ceea ce tine Internetul in picioare in
zilele noastre. Cu cativa ani in urma au fost discutii intense cu privire
la limitarile adreselor IP. Tipii de la IETF (Internet Engineering
Task Force – ei mentin Internetul in stare de functionare) si-au stors
creierii si au rezolvat problema. Cu un pret. Pretul este ca veti
obtine mai putin de un subnet de clasa “C” si unele lucruri s-ar putea
sa crape. Va rog consultati ASK MR DNS la:
pentru o buna explicatie
cu privire la aceste lucruri, si cum sa va descurcati.

Ati citit-o? Eu nu o voi explica, asa ca, va rog cititi-o!

Prima parte a acestei probleme este ca ISP-ul dvs. trebuie
sa inteleaga tehnica descrisa de Mr. DNS. Nu toti ISP-stii mici au habar
de aceasta problema. Daca asa sta treaba, va trebui sa le explicati
problema si sa si insistati. Asigurati-va ca ati inteles-o dvs. intai.

Ei vor configura atunci o zona inversa foarte draguta pe serverul lor,
pe care o puteti examina spre corectitudine cu “dig”.

A doua si ultima parte a problemei este ca trebuie sa intelegeti
tehnica. Daca nu sunteti sigur, reveniti si recititi-o. Atunci puteti sa
va configurati propria zona inversa fara clase, asa cum este descrisa
de Mr. DNS.

Mai e o capcana care pandeste aici. Rezolverele vechi nu vor fi capabile
sa urmeze “fenta” cu CNAME in lantul de rezolvare si vor esua in
incercarea de a rezolva invers masina dvs. Rezultatul poate fi acela
ca serverul ii aloca o clasa de acces incorecta,
interzicerea accesului sau ceva de genul aceasta. Daca va impotmoliti
intr-un asemena serviciu, singura solutie (despre care am cunostinta) este
pentru ISP sa insereze inregistrarea dvs. PTR direct in fisierul zonei
fara clase in loc de inregistrare CNAME.

Alte ISP-uri ofera alte cai de a rezolva aceasta problema, cum ar fi
formularele bazate pe Web care va permit sa va introduceti maparile inverse.

5.6. Servere slave (sclav)

Odata ce v-ati setat corect zonele pe serverele master, trebuie sa
configurati macar un server slave (“sclav”). Serverele slave sunt necesare
pentru a asigura robustetea serviciilor. Daca serverul master a picat,
oamenii de pe internet vor putea totusi primit date despre doemeniu de
la serverul slave. Un server slave ar trebui sa fie cat mai indepartat
de dvs posibil si sa imparta cu serverul master cat mai
putine din resursele de alimentare cu energie, LAN, ISP, oras, tara.
Daca toate aceste lucruri sunt diferite de ale serverului master, aveti un
bun server slave.

Un server slave este pur si simplu un nameserver care copie fisierele zone
de la master. Il configurati astfel:

______________________________________________________________________
zone “linux.bogus” {
type slave;
file “sz/linux.bogus”;
masters { 192.168.196.2; };
};
______________________________________________________________________

Un mecanism numit trasfer de zone este folosit pentru a copia datele.
Transferul de zone este controlat de inregistrarea SOA:

______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
______________________________________________________________________

O zona este transferata doar daca numarul serial al masterului este mai
mare decat al slave-ului. Dupa fiecare interval de refresh, slave-ul
va verifica daca masterul a fost actualizat.
Daca verificarea esueaza (pentru ca masterul nu este disponibil)
va reincerca verificarea. Daca va continua sa esueze atat timp cat dureaza
intervalul de expirare, slave-ul va sterge zona din propriul sistem de
fisiere si nu va mai actiona ca server pentru acea zona.

6. Optiuni fundamentale de securitate.

de Jamie Norrish

Seterea optiunilor de configurare pentru a reduce posibilitatea aparitiei
problemelor

Sunt cativa pasi simpli pe care ii puteti parcurge si care va vor asigura
un server mai sigur si totodata ii vor reduce incarcarea. Materialul
prezentat aici nu este mai mult decat un puct de plecare. Daca va preocupa
securitatea (si ar trebui sa va preocupe), va rog sa consultati si
alte resurse de pe Internet (vedeti “ultimul capitol”).

Urmatoarele directive de configurare apar in named.conf.
Daca o directiva apare in sectiunea “options” din fisier, se
aplica tuturor zonelor listate in acel fisier. Daca apare in optiunile
unei zone, se aplica numai acelei zone. On optiune dintr-o
zona suprascrie, anuleaza o inregistrare din zona “options”.

6.1. Restrictionarea trasferului pe zone.

Pentru ca serverele slave sa fie capabile sa raspunda interogarilor spre
domeniul dvs. trebuie sa fie capabile sa transfere informatia zona de la
serverul primar. In foarte putine cazuri e nevoie de aceasta. De
aceea, restrictionati transferurile pe zona, folosind optiunea
“allow-trasfer”. Presupunand ca 194.168.1.4 este adresa IP a lui
ns.friend.bogus, si adaugandu-va in scop de depanare:

______________________________________________________________________
zone “linux.bogus” {
allow-transfer { 192.168.1.4; localhost; };
};
______________________________________________________________________

Restrictionand transferul pe zone, va asigurati ca singura
informatie disponibila utilizatorilor este cea pe care acestia o cer
direct = nimeni nu poate cere, interoga toate detaliile configurarii dvs.

6.2. Protectia impotriva spoofing-ului.

In primul rand, dezactivati orice interogari pentru domenii care nu va
apartin, cu exceptia masinii dvs. interne/locale. Aceasta nu
doar preintampina utilizarea frauduloasa a serverului dvs. DNS, dar reduce
si utilizarea ne-necesara a acestuia.

______________________________________________________________________
options {
allow-query { 192.168.196.0/24; localhost; };
};

zone “linux.bogus” {
allow-query { any; };
};

zone “196.168.192.in-addr.arpa” {
allow-query { any; };
};
______________________________________________________________________

Mai departe, dezactivati interogarile recursive cu exceptia celor de
la masinile locale/interne. Aceasta reduce riscul atacurilor
prin “otravirea” cache-ului, cand date false alimenteaza serverul.

______________________________________________________________________
options {
allow-recursion { 192.168.196.0/24; localhost; };
};
______________________________________________________________________

6.3. Rularea lui named ca non-root.

Este o idee buna sa rulati named ca utilizator altul decat root, asa incat
daca acesta este compromis, privilegiile castigate de catre cracker
sa fie cat mai limitate. Intai trebuie sa creati un grup si un
utilizator sub care named sa ruleze, si apoi sa modificati scriptul pe
care il folositi pentru a porni named. Transferati noul grup si utilizator
catre named folosind flagurile -d si -u.

De exemplu, in Debian GNU/Linux 2.2 ati putea modifica scriptul /etc/init.d/bind
pentru a contine urmatoarea linie (unde userul si grupul “named” au fost
deja create):

______________________________________________________________________
start-stop-daemon –start –quiet –exec /usr/sbin/named — -u named -g named
______________________________________________________________________

La fel se procedeaza si cu RedHat si cu celelalte distributii. Dave Lugo a
descris un setup dual chroot
care s-ar putea
sa fie interesant de citit.

7. Un exemplu real de domeniu.

Unde vom lista fisiere reale de zona.

Utilizatorii mi-au sugerat sa includ un exemplu real de domeniu, ca si
unul tutorial, de instructaj.

Folosesc acest exemplu cu permisiunea lui David Bullock de la LAND-5.
Aceste fisiere dateaza din 24 septembrie 1996, si au fost editate pentru a
se conforma restrictiilor BIND 8 si folosesc extensii scrise
de mine. Deci, ceea ce vedeti aici s-ar putea sa difere de ceea
ce ati putea afla interogand LAND-5 acum.

7.1. /etc/named.conf (sau /var/named/named.conf)

Aici gasim zona master pentru cele doua zone inverse necesare: reteaua
127.0.0 si subreteaua (subnetul) de la LAND-5 206.6.177 ca linie primara
pentru zona de forward a LAND-5 land-5.com. Observati ca in loc ca toate
fisierele sa fie adunate nu in directorul “pz” asa cum am facut in acest
HOWTO, le pune intr-un director numit “zone”.

______________________________________________________________________
// Boot file for LAND-5 name server

options {
directory “/var/named”;
};

zone “.” {
type hint;
file “root.hints”;
};

zone “0.0.127.in-addr.arpa” {
type master;
file “zone/127.0.0″;
};

zone “land-5.com” {
type master;
file “zone/land-5.com”;
};

zone “177.6.206.in-addr.arpa” {
type master;
file “zone/206.6.177″;
};
______________________________________________________________________

Daca puneti aceasta in fisierul dvs. named.conf spre a va juca, VA ROG
puneti “notify no: ” in sectiunea zone, pentru cele doua zone land-5,
spre a evita incidentele.

7.2. /var/named/root.hints

Tineti minte ca acest fisier este dinamic, iar cel listat aici este
vechi. Mai bine folositi unul produs cu “dig” asa cum am
explicat mai devreme:

______________________________________________________________________
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN

;; ANSWER SECTION:
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241

;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE sent: 17 rcvd: 436
______________________________________________________________________

7.3. /var/named/zone/127.0.0

Doar bazele, inregistrarea SOA obligatorie, si o inregistrare
care mapeaza 127.0.0.1 catre localhost. Ambele sunt necesare. Nimic mai
mult nu ar trebui sa fie in acest fisier. Nu vor
trebui niciodata updatate, decat daca nameserver-ul sau adresa hostmaster
a dvs se modifica.

______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609203 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.

1 PTR localhost.
______________________________________________________________________

Daca veti cauta intr-o instalare BIND aleatorie, veti observa probabil
ca linia $TTL lipseste. Nu a fost folosita inainte si doar versiunea 8.2
BIND avertizeaza asupra lipsei acesteia. Va recomand sa puneti linia $TTL
in fisierele zona cand observati ca lipseste.

7.4. /var/named/zone/land-5.com

Aici observam inregistrarea SOA obligatorie, inregistrarea
NS necesara. Putem vedea ca are un nameserver secundar la ns2.psi.net. Asa
ar trebui sa fie, intotdeauna sa fie un al doilea nameserver
in afara retelei, ca backup. Observam ca exista un host master numit
land-5 care se ocupa de multiplele servicii Internet, si ca acesta
este inregistrat cu CNAME ( o alternativa este utilizarea inregistrarii A).

Asa cum vedem din inregistrarea SOA, fisierul zona incepe cu land-5.com,
persoana de contact este root@land-5.com. hostmaster este o alta
adresa folosita adesea pentru persoana de contact. Numarul serial este
obisnuitul format yyyymmdd cu numarul serial de astazi adaugat. Aceasta
este probabil a sasea versiune a fisierului zona, din 20
septembrie 1996. Tineti minte ca numarul serial trebuie sa creasca
monoton, aici este un singur digit pentru numarul serial de astazi, dupa 9
editari va trebui sa astepam pana maine inainte
de a edita din nou fisierul. Ganditi-ba la posibilitatea de a folosi 2
digiti.

______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; serial, todays date + todays serial
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
NS land-5.com.
NS ns2.psi.net.
MX 10 land-5.com. ; Primary Mail Exchanger
TXT “LAND-5 Corporation”

localhost A 127.0.0.1

router A 206.6.177.1

land-5.com. A 206.6.177.2
ns A 206.6.177.3
www A 207.159.141.192

ftp CNAME land-5.com.
mail CNAME land-5.com.
news CNAME land-5.com.

funn A 206.6.177.2

;
; Workstations
;
ws-177200 A 206.6.177.200
MX 10 land-5.com. ; Primary Mail Host
ws-177201 A 206.6.177.201
MX 10 land-5.com. ; Primary Mail Host
ws-177202 A 206.6.177.202
MX 10 land-5.com. ; Primary Mail Host
ws-177203 A 206.6.177.203
MX 10 land-5.com. ; Primary Mail Host
ws-177204 A 206.6.177.204
MX 10 land-5.com. ; Primary Mail Host
ws-177205 A 206.6.177.205
MX 10 land-5.com. ; Primary Mail Host
; {Many repetitive definitions deleted – SNIP}
ws-177250 A 206.6.177.250
MX 10 land-5.com. ; Primary Mail Host
ws-177251 A 206.6.177.251
MX 10 land-5.com. ; Primary Mail Host
ws-177252 A 206.6.177.252
MX 10 land-5.com. ; Primary Mail Host
ws-177253 A 206.6.177.253
MX 10 land-5.com. ; Primary Mail Host
ws-177254 A 206.6.177.254
MX 10 land-5.com. ; Primary Mail Host
______________________________________________________________________

Daca veti examina nameserverul lui land-5, veti observa ca numele
hosturilor sunt exprimate in forma ws_number. De la ultimele versiuni de
BIND4 ,named a inceput sa intareasca restrictiile in legatura
cu caracterele ce pot fi folosite in numele hosturilor. Asa ca aceasta
nu functioneaza sub BIND8, asa ca am inlocuit caracterul “-” (liniuta)
cu caracterul “_” pentru a fi folosit in acest HOWTO.

Un alt lucru de remarcat este ca statiile de lucru nu au nume individuale,
ci mai curand un prefix urmat de doua din ultimile parti ale
IP-ului. Folosirea unei astfel de conventii poate simplifica
intretinerea semnificativ, dar poate fi un pic impersonala si,
in fapt, o sursa de iritare printre clientii dumneavoastra.

De asemeni, observam ca funn.land-5.com este un alias
pentru land-5.com, dar folosind inregistrarea A nu CNAME. Aceasta este o
buna politica, asa cum am spus si mai devreme.

7.5. /var/named/zone/206.6.177

Voi face comentariile dupa acest fisier:

______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.
NS ns2.psi.net.
;
; Servers
;
1 PTR router.land-5.com.
2 PTR land-5.com.
2 PTR funn.land-5.com.
;
; Workstations
;
200 PTR ws-177200.land-5.com.
201 PTR ws-177201.land-5.com.
202 PTR ws-177202.land-5.com.
203 PTR ws-177203.land-5.com.
204 PTR ws-177204.land-5.com.
205 PTR ws-177205.land-5.com.
; {Many repetitive definitions deleted – SNIP}
250 PTR ws-177250.land-5.com.
251 PTR ws-177251.land-5.com.
252 PTR ws-177252.land-5.com.
253 PTR ws-177253.land-5.com.
254 PTR ws-177254.land-5.com.
______________________________________________________________________

Zona inversa este partea de configurare care da dureri de cap. Este
folosita pentru a identifica numele de host daca aveti IP-ul
unei masini. Exemplu: sunteti un server IRC si acceptati conexiuni de la
clientii IRC. Oricum, sunteti un server norvegian si acceptati
doar conexiuni de la clientii din Norvegia si celelalte tari scandinave.
Cand primiti o conexiune de la un client, biblioteca C e capabila sa
va spune IP-ul masinii client, pentru ca numarul IP este continut in toate
pachetele care traverseaza reteaua. Acum puteti invoca o functie
numita gethostbyaddr care cauta numele unui host avand data adresa IP.
Gethostbyaddr va interoga un server DNS, care va traversa reteaua
de servere DNS cautand masina respectiva. Sa presupunem ca conexiunea client
este de la ws-177200.land-5.com. Numarul IP pe care biblioteca C il
livreaza catre serverul IRC este 206.6.177.200. Pentru a afla numele
acelei masini trebuie sa gasim 200.177.6.206.in-addr.arpa. Serverul DNS va
trebui intai sa gaseasca serverele arpa. , apoi in-addr.arpa. ,
urmand calea inversa spre 206, apoi 6, in final gasind serverul pentru
177.6.206.in-addr.arpa la LAND-5. De unde va lua raspunsul final, cum ca
pentru 200.177.6.206.in-addr.arpa avem o inregistrare “PTR
ws-177200.land-5.com” insemnand ca numele care insoteste 206.6.177.200
este ws-177200.land-5.com.

Inapoi la exemplul cu serverele IRC. Serverul IRC accepta doar conexiuni
din tari scandinave, de exemplu: *.no, *.se, *.dk, numele
ws-177200.land-5.com e clar ca nu indeplineste aceasta conditie si
serverul ii va respinge conexiunea. Daca nu a fost
mapare inversa a lui 206.2.177.200 prin zona in-addr.arpa serverul nu va
fi capabil sa gaseasca numele deloc si nici sa compare 206.2.177.200
cu *.no, *.se and *.dk, asa ca acestea nu se vor potrivi nicicum.

Unii va vor spune ca maparea inversa nu este importanta pentru servere sau
nu este importanta deloc. Nu este asa: multe servere FTP, news, IRC
si unele servere WWW (web) nu vor accepta conexiuni de la masini ale caror
nume nu le pot afla. Deci maparea inversa este de fapt obligatorie
si necesara.

8. Intretinere.

Tineti-l in viata.

Exista o sarcina de intretinere cand aveti de-a face cu named-uri, alta
decat a le mentine ruland. Aceea de a mentine fisierul
root.hints actualizat, la zi. Cea mai usoara cale este cu “dig”. Prima
data rulati “dig” fara nici un argument, si veti obtine datele din
“root.hints” conform propriului nameserver. Apoi interogati unul
dintre rootservere listate cu “dig @rootserver”. Veti observa ca
rezultatul seamana foarte bine cu un
fisier “root.hints”. Salvati-l intr-un fisier (dig
@e.root-servers.net . ns >root.hints.new) si inlocuiti vechiul
root.hints cu el.

Nu uitati sa restartati named dupa inlocuirea fisierului cache.

Al Longyear mi-a trimis acest script care rulat, poate actualiza automat
fisierul root.hints. Instalati-l intr-o intrare crontab pentru a
fi rulat odata pe luna si puteti uita de el. Scriptul presupune ca
va merge serviciul de mail si ca este definita adresa de hostmaster.
Puteti sa il modificati pentru a se potrivi configuratiei dvs.

______________________________________________________________________
#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# named up-test suggested by Erik Bryer.
#
(
echo “To: hostmaster ”
echo “From: system ”

# Is named up? Check the status of named.
case ‘ndc status 2>&1 in
*’cannot connect to command channel’*)
echo “named is DOWN. root.hints was NOT updated”
echo
exit 0
;;
esac
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
# NOTE: /var/named must be writable only by trusted users or this script
# will cause root compromise/denial of service opportunities.
cd /var/named 2>/dev/null || {
echo “Subject: Cannot cd to /var/named, error $?”
echo
echo “The subject says it all”
exit 1
}

# Are we online? Ping a server at your ISP
case ‘ping -qnc 1 some.machine.net 2>&1′ in
*’100% packet loss’*)
echo “Subject: root.hints NOT updated. The network is DOWN.”
echo
echo “The subject says it all”
exit 1
;;
esac

dig @e.root-servers.net . ns >root.hints.new 2> errors

case ‘cat root.hints.new’ in
*NOERROR*)
# It worked
:;;
*)
echo “Subject: The root.hints file update has FAILED.”
echo
echo “The root.hints update has failed”
echo “This is the dig output reported:”
echo
cat root.hints.new errors
exit 1
;;
esac

echo “Subject: The root.hints file has been updated”
echo
echo “The root.hints file has been updated to contain the following
information:”
echo
cat root.hints.new

chown root.root root.hints.new
chmod 444 root.hints.new
rm -f root.hints.old errors
mv root.hints root.hints.old
mv root.hints.new root.hints
ndc restart
echo
echo “The nameserver has been restarted to ensure that the update is complete”
echo “The previous root.hints file is now called
/var/named/root.hints.old.”
) 2>&1 | /usr/lib/sendmail -t
exit 0
______________________________________________________________________

Unii dintre dvs v-ati prins ca fisierul root.hints este disponibil
prin ftp din Internic. Va rog nu folositi ftp
pentru a actualiza root.hints, metoda de mai sus este mult mai prietenoasa
pentru net si Internic.

9. Conversia de la versiunea 4 la versiunea 8.

Aceasta a fost la inceput o sectiune despre folosirea lui BIND 8 scrisa de
David E. Smith (dave@bureau42.ml.org). Am editat cate ceva pentru a
se potrivi noului nume al sectiunii.

Nu sunt prea multe de spus. Cu exceptia inlocuirii fisierului named.boot
cu named.conf, restul este identic. Iar BIND 8 vine cu un script PERL care
converteste totul de la vechiul la noul format. Exemplu de fisier
named.boot (vechiul stil) pentru caching nameserver:

______________________________________________________________________
directory /var/named
cache . root.hints
primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone
primary localhost localhost.zone
______________________________________________________________________

In linia de comanda, in directorul bind8/src/bin/named (aceasta presupune
ca aveti sursele distributiei). Daca aveti pachetul binar, scriptul e prin
preajma… Dati comanda :

______________________________________________________________________
./named-bootconf.pl < named.boot > named.conf
______________________________________________________________________

care va crea named.conf:

______________________________________________________________________
// generated by named-bootconf.pl

options {
directory “/var/named”;
};

zone “.” {
type hint;
file “root.hints”;
};

zone “0.0.127.IN-ADDR.ARPA” {
type master;
file “127.0.0.zone”;
};

zone “localhost” {
type master;
file “localhost.zone”;
};
______________________________________________________________________

Functioneaza pentru orice intra intr-un fisier named.boot, desi nu
adauga toate imbunatatirile si optiunile de configuratie pe care
le permite BIND8. Aici este un named.conf care face aceleasi
lucruri, dar ceva mai eficient:

______________________________________________________________________
// This is a configuration file for named (from BIND 8.1 or later).
// It would normally be installed as /etc/named.conf.
// The only change made from the tock’ named.conf (aside from this
// comment is that the directory line was uncommented, since I
// already had the zone files in /var/named.

options {
directory “/var/named”;
datasize 20M;
};

zone “localhost” IN {
type master;
file “localhost.zone”;
};

zone “0.0.127.in-addr.arpa” IN {
type master;
file “127.0.0.zone”;
};

zone “.” IN {
type hint;
file “root.hints”;
};
______________________________________________________________________

In directorul bind8/src/bin/named/test din distributia BIND 8
gasiti aceasta si copii ale fisierelor zona, pe care multi utilizatori
le pot instala si folosi ca atare. Formatele pentru fisierele root.hints
si fisierele zone sunt identice, ca si comenzile pentru actualizarea lor.

10 Intrebari si raspunsuri.

Va rog sa cititi aceasta sectiune inainte de a imi trimite e-mail.

1. named-ul meu “vrea” un fisier named.boot

Cititi un HOWTO gresit.Vedeti vechea versiune a acestui HOWTO, care
studiaza BIND4 la

2. Cum folosesc DNS-ul din interiorul unui firewall ?

Indicatie: forward-only . Sau puteti folosi

___________________________________________________________________
query-source port 53;

___________________________________________________________________

in sectiunea “options” a lui named.conf.

3. Cum fac DNS-ul sa se “plimbe” prin adresele disponibile, pentru
un serviciu, sa zicem www.busy.site, pentru a obtine un efect de
egalizare a incarcarii (loadbalancing), sau similar?

Faceti cateva inregistrari “A” pentru www.busy,site si folositi BIND
4.9.3 sau mai nou. Atunci, BIND va functiona ca perpetuum-mobile in
cautare de raspunsuri. Nu va functiona cu versiuni mai vechi de BIND.

4. Vreau sa configurez un DNS intr-un Intranet (inchis). Cum fac?

Lasati fisierul root.hints si ocupati-va numai de fisierele zone.
Asta inseamna de asemeni ca nu trebuie sa actualizati fiserul .hint
tot timpul

5. Cum configurez un server secundar (slave) ?

Daca serverul primar/master are adresa 127.0.0.1, puneti o linie ca
aceasta in named.conf-ul de la serverul secundar:

___________________________________________________________________
zone “linux.bogus” {
type slave;
file “sz/linux.bogus”;
masters { 127.0.0.1; };
};

___________________________________________________________________

Puteti lista si alte servere master de unde pot fi copiate zonele,
separate de punct si virgula “;”

6. Vreau sa rulez BIND cand sunt deconectat de la Internet.

Sunt patru chestiuni privind aceasta problema:

- Specific lui BIND 8, Adam L Rice mi-a trimis acest e-mail despre cum
sa rulezi DNS fara dureri de cap pe o masina dialup:

Am descoperit in noile versiuni ca acest fisier [ -ed/] nu mai este necesar. Exista o directiva “forward” pe linga
“forwarderi”, directiva care controleaza cum aceastia sunt
utilizati. Setarea implicita este “forward first”, care interogheaza intai
fiecare dintre “forwarderi”, apoi incearca abordarea normala
daca prima varianta esueaza. Aceasta face ca functia gethostbyname() sa se
comporte familiar, luand un timp foarte lung cand legatura
nu functioneaza. Dar daca “forward only” este setat, BIND renunta cand
nu primeste un raspuns de la forwarderi iar gethostbyname() raspunde
imediat.

In cazul meu, am adaugat liniile:

forward only;
forwarders { 193.133.58.5; };

in sectiunea options { } din fisierul meu named.conf. Functioneaza
foarte frumos, singurul dezavantaj este ca reduce o incredibil
de sofisticata masinarie software care este DNS la statutul de cache
chior. As fi preferat sa pot rula un cache simplu in loc, dar nu exita asa
ceva care sa inlocuiasca DNS pentru Linux.

- Am receptionat acest mail de la Ian Clark unde
el explica modul in care face aceasta:

Rulez named pe masina mea “masquerade” (cu mascaradare). Am doua fisiere
root.hints, unul numita root.hints.real care contine numele reale ale
root-serverelor si celalalt numit root.hints.fake care contine…

—-
; root.hints.fake
; this file contains no information
—-

cand inchid conexiunea (dialup), copii root.hints.fake peste root.hints si
restartez named.
Cand pornesc conexiunea, copii root.hints.real peste root.hints
si restartez named. Asta o fac din ip-up si ip-down. Prima data cand fac o
interogare offline pe un nume de domeniu, named nu are detalii de oferit
si pune o intrare ca aceasta in mesaje:

Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN

care nu ma deranjeaza.

Deci functioneaza cu siguranta. Pot folosi nameserverul pentru
masinile locale cand sunt deconectat de la Internet fara intarzieri de
timeout pentru interogarile domeniilor externe.

Peter Denison crede ca Ian nu a ajuns prea departe. El scrie:

Cand sunt conectat) alimenteaza toate intrarile din cache (si reteaua locala)
imediat, pentru intrarile reinregistrate in cache,
forward catre nameserver-ul ISP-ului

Cand nu sunt conectat) alimenteaza interogarile retelei locale
imediat, abandoneaza orice alte interogari IMEDIAT

Combinatia dintre schimbarea fisierului root cache si interogarile forward
nu functioneaza.

Deci am configurat (cu unele discutii pe Linux User Group-ul local) doua
named-uri, dupa cum urmeaza:

named-online: forwards to ISPs nameserver
master for localnet zone
master for localnet reverse zone (1.168.192.in-addr.arpa)
master for 0.0.127.in-addr.arpa
listens on port 60053

named-offline: no forwarding
“fake” root cache file
slave for 3 local zones (master is 127.0.0.1:60053)
listens on port 61053

Si combinand aceasta cu port-forwarding-ul, pentru a trimite portul
53 catre portul 61053 cand suntem off-line si catre portul 60053 cand
suntem online (folosesc noul pachet netfilter sub 2.3.18, dar si vechiul
mecanism ipchains functioneaza).

Observati ca aceasta nu va merge chiar “din tzeava” de vreme ce exista
un mic bug in BIND 8.2 pe care l-am semnalat dezvoltatorilor,
care impiedica un server slave sa aiba un master pe aceiasi adresa iP
(chiar si pe un port diferit).

- Am primit informatii despre cum BIND interactioneaza cu NFS si
portmapper-ul pe o masina mai mult off-line, de la Karl-Max Wanger :

Obisnuiesc sa rulez propriul meu named pe toate masinile care se
conecteaza ocazional la Internet prin modem. Nameserverul singur
actioneaza ca un cache, nu are nici o arie de autoritate, si
interogheaza serverele din fisierul root.cache. Ca de obicei in Slackware,
este pornit inainte de nfsd si mountd.

Cu una dintre masinile mele (un notebook Libretto 30) am avut probleme
ca adesea nu puteam sa il montez dintr-un sistem conectat la reteaua mea
LAN. Aceleasi probleme le aveam si din punct de vedere
al legaturilor PPP sau PLIP.

Dupa ceva timp de cercetari si experimente am constatat ca named s-a
incurcat in inregistrarea serviciilor initiate de nfsd si mountd precum si
cu portmapper-ul. Pornind named-ul dupa nfsd si mountd, am scapat complet
de probleme.

Cum nu sunt dezavantaje de asteptat in urma unei asemenea modificari
in ordinea de boot, recomand tuturor sa treaca la aceasta,
pentru a preintampina necazurile.

- In final, exista ceva informatii despre aceasta la Ask MR. DNS la
. Este despre BIND
4, asa ca trebuie sa faceti adaptari la BIND 8.

7. Unde stocheaza caching-nameserver-ul cache-ul si cum pot controla
dimensiunea acestuia?

Cache-ul este stocat complet in memorie, nu este scris pe disc in nici
un moment. De fiecare data cand dati kill lui named, cache-ul este
pierdut. Cache-ul nu este controlabil nicicum, named il controleaza dupa
cateva reguli simple, si cam asta e tot. Nu puteti controla cache-ul sau
dimensiunea acestuia nicicum si pentru nici un motiv. Daca
doriti neaparat, puteti incerca sa hackuiti named , dar nu este recomandat.

8. Named-ul salveaza cache-ul intre restart-uri? Pot sa il fac sa salveze?

NU, named nu salveaza cache-ul cand dispare. Aceasta inseamna ca
cache-ul trebuie reconstruit de la zero de fiecare data cand named
este repornit. Nu exista nici o metoda de a-l face pe named sa salveze
cache-ul intr-un fisier.

9. Cum imi procur un domeniu? Vreau sa imi configurez propriul
domeniu, denumit de exemplu linux-rules.net. Cum pot sa obtin domeniul
pe care il doresc alocat mie?

Va rog sa va contactati provider-ul. Ei va vor putea ajuta cu
aceasta. Aveti in vedere ca in cele mai multe parti ale lumii,
aceast lucru costa (obtinerea unui nume de domeniu).

10. Cum securizez serverul meu DNS? Cum configurez un DNS split? (separat)

Ambele sunt chestiuni avansate si sunt analizate in
. de aceea nu le voi
expune aici.

11. Cum sa devii un DNS de talie mare.

Documentatii si utilitare.

Exista documentatie “reala”. Online si tiparita. Citirea acesteia este
necesara pentru a face pasul de la un administrator DNS de mica anvergura
la unul de talie mare. Am tiparit Ghidul Concis al DNS si BIND
(Nicolai Langfeldt) publicata de QUE (ISDN 0-7897-2273-9). Cartea seamana
cu acest HOWTO. Doar mai multe detalii si mai multe despre toate aspectele.
Dar cartea standard este “DNS and BIND by C. Liu and P. Albitz
from O’Reilly & Associates (ISBN 0-937175-82-X). Este excelenta.
Faceti rost de editia a 3-a, care acopera BIND 8 ca si BIND 4. Exista de
asemeni o sectiune DNS si in TCP/IP Network Administration Guide. by Craig
Hunt from O’Reilly (ISBN 0-937175-82-X). O alta carte buna si pentru DNS
si pentru orice este Zen and the Art of Motorcycle Maintenance (Zen si
arta intretinerii motocicletei de Robert M. Pirsig ISBN 0688052304\
si altii.

Online veti gasi multe chestii la: (DNS
Resources Directory), ; FAQ si manual
de referinta (BOG; BIND Operations Guide) ca si documente si definitii de
protocol si “hack-uri” DNS (acestea – ma rog, nu toate- ca si RFC-urile
sunt continute in distributia BIND). N-am citit chiar toate aceastea,
dar nici mare administrator DNS nu sunt. Arnt Gulbrandsen pe de
alta parte a citit BOG (BIND Operation Guide) si este extaziat de acesta
Newsgrupul este despre DNS.
Pe langa asta, exista un numar de RFC-uri despre DNS, cele mai
importante sunt probabil cele listate aici. Cele care au BCP (Best Current
Practice) sunt cele mai recomandate.

RFC 2671
P. Vixie, Extension Mechanisms for DNS (EDNS0) August 1999.

RFC 2317
, BCP 20, H. Eidnes et. al. Classless IN-ADDR.ARPA delegation,
March 1998. This is about CIDR, or classless subnet reverse
lookups.

RFC 2308
, M. Andrews, Negative Caching of DNS Queries, March 1998.
About negative caching and the $TTL zone file directive.

RFC 2219
, BCP 17, M. Hamilton and R. Wright, Use of DNS Aliases for
Network Services, October 1997. About CNAME usage.

RFC 2182
, BCP 16, R. Elz et. al., Selection and Operation of Secondary
DNS Servers, July 1997.

RFC 2052
A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location
of services (DNS SRV), October 1996

RFC 1918
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
Address Allocation for Private Internets, 02/29/1996.

RFC 1912
D. Barr, Common DNS Operational and Configuration Errors,
02/28/1996.

RFC 1912 Errors
B. Barr Errors in RFC 1912, this is available at

RFC 1713
A. Romao, Tools for DNS debugging, 11/03/1994.

RFC 1712
C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of
Geographical Location, 11/01/1994.

RFC 1183
R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR
Definitions, 10/08/1990.

RFC 1035
P. Mockapetris, Domain names – implementation and specification,
11/01/1987.

RFC 1034
P. Mockapetris, Domain names – concepts and facilities,
11/01/1987.

RFC 1033
M. Lottor, Domain administrators operations guide, 11/01/1987.

RFC 1032
M. Stahl, Domain administrators guide, 11/01/1987.

RFC 974
C. Partridge, Mail routing and the domain system, 01/01/1986.

Web-site pentru afacerea ta pe Internet

admin — Mon, 31 Jan 2011 07:31:25 +0000

Epoca de pionierat a Internetului s-a terminat. In prezent asistam la inceputul unei revolutii in modul de a face afaceri la scara globala, 24 de ore din 24. Afacerile online ( e-business ), comertul electronic, magazinele electronice, etc. au devenit deja termeni consacrati in lumea financiara si bancara. Dupa un raport al Forrester Research vanzarile online au crescut de la 300 milioane USD in 1995, la peste 6 miliarde USD in 2000 si se asteapta sa depaseasca cifra de 90 miliarde USD in 2005. In ultimul deceniu, Internetul a evoluat intr-o unealta formidabila avand un impact major in toate aspectele vietii. La fiecare jumatate de an apar schimbari asa de importante incat este imposibil de prevazut unde se va ajunge in urmatorii 10 ani. Conform unor statistici, utilizatorul tipic de Internet este american (84%), alb (87%), vorbitor de limba engleza (93%), in varsta de 35 de ani, educat si avand un salariu bun. Astazi, din ce in ce mai multe firme si chiar persoane particulare au o pagina web. Pe Internet, se gasesc la dispozitia celor interesati toate mijloacele necesare pentru crearea de site-uri web. Se pot realiza atit site-uri simple, avand cateva pagini, cit si site-uri deosebit de complexe, de sute de pagini si care inglobeaza ultimele tehnologii in domeniul: Flash, Shockwave, Java, Javascript, etc. La momentul actual exista din ce in ce mai multe firme care se ocupa cu webdesign, dar preturile cerute pentru realizarea unei pagini web sunt destul de mari. Web-ul astazi, ca si cel de ieri si cel de maine se afla intr-o continua transformare si metamorfoza care pe cei mai multi fie ii lasa rece fie ii ameteste si ii descurajeaza in incercarea de a intelege mai mult. Scopul lucrarii date este de a-l pune in actualitate pe omul “studioso” cu posibilitatile oferite de internet la accesarea informatie si utilizarea ulterioara a acesteia in scopuri proprii. De asemenia, imi propun ca prin lucrarea data persoana fizica sa obtina o idee si informatie mai larga privind posibilitatile proprii de promovare personala si a unei afaceri prin intermediul internetului utilizind web-siturile. In cadrul primului capitol voi demonstra, pe cit e posibil, ca E-afacerile ocupa un segment important in piata afacerilor globale. In primul capitol voi prezenta prin intermediul unor exemple eficacitatea utilizarii internetului prin demonstrarea posibilitatilor largite ale E-learningului, care dupa cum se pare a avut un impact neastptat de mare asupra societatii contemporane. De asemeni voi aduce exemple ale utilizarii Internetului in realizarea unei afacere precum si utilizarea acestuia drept sursa principala de realizare ale bunurilor unui agent economic. Modalitatea de afisare a informatiilor pe internet are loc in mare parte prin intermediul Web-Siturilor, astfel ca in cadrul capitolului doi ma voi opri in mod special asupra acestora. O atentie deosebita o voi acorda clasificarii acestora din diferite puncte de vedere. Ulterior in acest capitol voi atrage atentia asupra principiilor de administrare a afacerilor pe internet. Datorita faptului ca aceasta lucrare va fi concentrata asupra eficientei economice a sit-urilor web, voi analiza unele modele business de sit-uri, oprindu-ma in mod special la modelul publicitar, cel de sustinere a unor afaceri existente precum si modele de lansare a unor noi afaceri cu toate efectele pozitive ulterioare lansarii acestuia, desigur in cazul unei lansari de succes. De asemeni voi prezenta perspectivele generale ale acestor modele de afaceri precum si pe zone geografice concrete, aducind drept exemplu dezvoltzarea in ultimii ani. Dupa ce voi da o explicatie privind tipurile existente ale web-sit-urilor si posibilitatile de utilizare ale acestora, ulterior ma voi opri asupra crearii in sine a acestuia, iar mai amanuntit asupra etapelor de creare a site-ului web, dat fiind importanta cu care trebuie tratat acest proces la fiecare din etapele crearii lui. Am structurat aceest capitol in patru parti care reprezinta, dupa parerea mea, etape absolut obligatorii in realizarea unui site-web care sa atraga vizitatorii. In literatura de specialitate sau pe siturile care furnizeaza informatii despre webdesign probabil aceste etape, precum si pasii necesari pentru parcurgerea lor, vor fi denumite altfel. Din considerente proprii de machetare a lucrarii si pentru a fi pe cit posibil cit mai concisa eu am gasit aceste denumiri. Poate ele nu sunt cele mai sugestive, dar intelegerea si parcurgerea lor in totalitate sunt esentiale daca dorim sa obtinem o audienta maxima pentru site.

1.Economia digitala si impactul ei asupra societatii

Utilizarea larga a tehnologiilor informatiei si comunicatiilor si progresul catre

Societatea Informationala asigura cresterea economica in conditii de protectie

sporita a mediului, accelerand reducerea consumului fizic in favoarea valorificarii

informatiei si a cunoasterii, deplasarea centrului de greutate de la investitii in

mijloacele fixe la investitii in capitalul uman. In acest mod,

Societatea Informationala integreaza si obiectivele dezvoltarii durabile,

bazata pe dreptate sociala si egalitatea sanselor, libertate, diversitate

culturala si dezvoltare inovativa, protectie ecologica, restructurarea industriei

si a mediului de afaceri.

Schimbarile majore din ultimii ani – cresterea exponentiala a comunicatiilor mobile

si a numarului utilizatorilor de Internet, contributia sectorului TIC (tehnologiile

informatiei si comunicatiilor) la cresterea economica si la crearea de locuri de munca,

restructurarea companiilor si a business-ului in general pentru a beneficia mai eficient

de noile tehnologii, dezvoltarea accelerata a comertului electronic – sustin tranzitia de

la era industriala la cea post – industriala.

Noile tehnologii digitale fac accesul, stocarea si transmiterea informatiei din ce in

ce mai facile si mai accesibile. Dispunand de informatia digitala, aceasta poate fi

transformata in noi valori economice si sociale, creand imense oportunitati pentru

dezvoltarea de noi produse si servicii. Informatia devine resursa-cheie pentru economia digitala.

Notiunea de “noua economie” (economia digitala) se refera in special la transformarile

actuale ale activitatilor economice ca rezultat al utilizarii tehnologiilor digitale,

care asigura accesul, prelucrarea si stocarea informatiei intr-o maniera mai ieftina

si mai facila. Noua economie este caracterizata de intensificarea inglobarii cunoasterii

in noile produse si servicii, cresterea importantei invatarii si a inovarii, a

globalizarii si a dezvoltarii durabile. Volumul enorm al informatiilor schimba modul

de functionare a pietelor, facand posibile restructurarea intreprinderilor si aparitia

de noi oportunitati pentru crearea de valoare prin exploatarea informatiilor disponibile.

In prezent, exista ample dezbateri in mass-media internationala si in mediile politice

asupra intrebarii daca aceste modificari sunt suficient de radicale pentru a merita

eticheta de “noua economie”. La originea acestor dezbateri stau performantele

exceptionale ale economiei americane: 8 ani de crestere continua, cresterea anuala

de peste 4% in ultimii ani, inflatia controlata sub 2%, somajul sub 5%.

Construirea noului model de societate ridica probleme socio-politice majore – atat

la scara nationala cat si internationala – de atenuare a fenomenului de “digital

divide” (excludere de la beneficiile noilor tehnologii a unor categorii sociale

si a unor regiuni/zone geografice) si de coeziune sociala, de conservare si promovare

a culturii specifice fiecarei natiuni si comunitati locale, de protectie a cetateanului

si consumatorului. Solutionarea acestor probleme nu se poate realiza decat printr-un

dialog larg intre autoritatile guvernamentale, reprezentantii mediului de afaceri, ai

mediului academic si societatea civila.

Download Web site pentru afacere