Blog despre resurse educaţionale din IT » tcp

Tehnologia satelitilor. HowTo.

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

Sat (Satellite Technology) HOWTO
Roberto Arcomano berto@fatamorgana.com, Florindo Santoro
flosan@hack-it.net
v1.3, 21 July 2001
Traducerea din limba engleza: Victor Plugaru vuk@go.ro
Cu scuzele de rigoare pentru eventualele greseli sau inadvertente.

Tehnologia satelitilor incepe sa devina o mare resursa pentru
utilizatorii de Internet, permitand largimi mari de banda pentru download,
precum si pentru multe alte servicii interesante. Acest document tine
de investigheze modalitatile de conectare a mediului Linux prin
satelit, cum sa obtineti viteze superioare si sa partajati aceasta cu alti
clienti. Puteti gasi ultimele versiuni ale acestui document la
http://www.fatamorgana.com/bertolinux/sat/english morgana.com/bertolinux/sat/english> si http://www.hack-it.net/How-
To/Sat-HOWTO.html .
______________________________________________________________________

Cuprins

1. Introducere

1.1 Introducere
1.2 Copyright

2. Cunostinte necesare

2.1 Despre sateliti
2.2 Cum lucreaza?
2.3 Alte tehnologii
2.4 Care este largimea de banda maxima?
2.5 Cat costa?
2.5.1 Costurile hardware
2.5.2 Costurile conturilor
2.6 Ce sateliti sunt folositi?
2.7 Ce ISP-uri ofera servicii de acces prin Internet?
2.8 Altceva?

3. Informatii tehnice

3.1 Functionare generala
3.2 Frecvente
3.3 Carduri receptoare DVB
3.4 Configurarea nivelului legaturii de date DVB
3.5 Functionarea TCP/IP
3.6 Autentificarea
3.7 Servicii pe care le pot folosi cu o conexiune prin satelit

4. Cerinte

4.1 Cerinte privind cunostintele
4.2 Hardware
4.3 Software
4.4 Software TV
4.4.1 Pentru Windows
4.4.2 Pentru Linux

5. Configurarea echipamentului

5.1 Montajul
5.2 Calibrarea
5.3 Double Feed (LNB-uri duble)
5.4 Reglajul nivelului legaturii de date

6. Configurarea sub Linux

6.1 Instalarea Driverelor
6.2 Configurarea fisierului /etc/dvbd.conf
6.3 Daemonul dvbd
6.4 Cum se configureaza serviciul EON
6.5 Cum se configureaza serviciul Netsystem
6.5.1 conexiuni VPN
6.5.2 Patch pentru pppd
6.5.3 setarea rutarii
6.5.4 Patch pentru dvbd.c
6.5.5 Testarea
6.5.6 Obtinerea unor performante superioare
6.5.7 Partajarea Netsystem cu mai multi clienti
6.6 Cum se utilizeaza serviciul Sat Node

7. Configurarea sub Windows

7.1 EON
7.2 Netsystem

8. Anexa A – Note
8.1 Translatarea IP dinamic -> Adrese MAC
8.2 Cadrul TCP
8.3 Download accelerator
8.3.1 Sub Linux
8.3.2 Sub Windows

9. Anexa B – Valori cunoscute pentru ISP-urile ce ofera servicii
prin satelit

9.1 EuropeOnLine
9.1.1 Transponder 113
9.1.2 Transponder 114
9.1.3 Transponder 115
9.1.4 Transponder 103
9.2 Netsystem
9.2.1 Transponder 119
9.3 Sat Node

______________________________________________________________________

1. Introducere

1.1. Introducere

Acest document intentioneaza sa explice cate ceva despre
tehnologia satelitara, cum functioneaza, de ce aveti nevoie, configuarea
si cum sa partajati accesul pentru mai multi clienti. Conexiunile prin
satelit sunt foarte diferite de cele terestre, cer mai mult atentie la
configuare si mai multa intretinere pentru a le mentine stabile (ninsoarea
sau ploaia intensa va pot impiedica sa aveti un semnal de calitate).

Opiniile Dumneavoastra sunt binevenite, nu ezitati sa
ne contactati: berto@fatamorgana.com si
flosan@hack-it.net .

1.2. Copyright

Copyright (C) 2000,2001 Roberto Arcomano, Florindo Santoro. Acest document
este gratuit; il puteti redistribui sau/si modifica sub
termenii GNU Licenta Publica Generala asa cum a fost publicata de Free
Software Foundation, de asemeni pentru versiunea 2 a licentei sau (conform
optiunii Dumneavoastra) conform oricarei viitoare versiuni. Acest document
este distribuit in speranta ca va fi folositor, dar

FARA NICI O GARANTIE, fara implicarea vreunei garantii
comerciale ori a FIABILITATII INTR-UN SCOP PREDEFINIT.
Consultati Licenta Generala Publica GNU pentru mai multe detalii.
Puteti obtine o copie a Licentei Generale Publice GNU la adresa

2. Cunostinte necesare

2.1. Despre sateliti

In ultimii cativa ani satelitii au inceput sa fie folositi
pentru comunicatia in Internet, in primul rand de catre ISP-uri medii-mari
(ISP= Internet Service Provider), dar am intalnit si utilizatori
individuali. Conexiunile prin satelit sunt un tip diferit de
cele terestre, cu temporizari (timing-uri) diferite, cum ar fi RTT
(Round Trip Time), dar si cu valori diferite ale largimii de banda, pana
la 2 Mb/s sau mai mult.

2.2. Cum functioneaza?

Sa ne imaginam o cale ca aceasta:

|||||| S A T E L I T ||||||||
/ /|\
Downl / | Upload
load / | de la
la /(4) | (3) server
client / |
/ |
SatCard(antena parabolica) |
| |
\|/ |
PC —-adreseaza cerere—–> SAT-SERVER<—extragere—> INTERNET
(1) (2)

In primul rand facem cererea (1) folosind conexiunea noastra
Internet catre Sat-SERVER, acesta va extrage informatiile din Internet (2)
si le va trimite catre satelit (3); in final vom receptiona datele de la
satelit (4) folosind o antena parabolica si cardul DVB pentru satelit.

Tipic exista 2 tipuri de cereri:

- http
- ftp

Ambele au un flux mic de date pentru cerere si un volum mare de date
pentru raspuns, asa ca satelitii lucreaza bine cu acestea, dar cu un
timp mai mare de raspuns. Aceasta este cea mai mare problema a conexiunior
prin satelit (ganditi-va la o distanta tipica la care orbiteaza satelitii
de cca 36000 km, asa incat veti avea un timp de acces de [ 36000
km / 300.000 km/s = 0.120 s = ] 120 ms pe care trebuie sa le adaugati de
la conexiunea clasica la Internet de doua ori pentru ca ISP-ul trimite odata
catre satelit iar clientul descarca de la satelit).

ISP-uri recente permit clientilor utilizarea si a altor servicii, ca:

-chat
-email
-news
si multe altele

Exita asa numitele servicii one-way (monosens), care constau in servicii
de mail, download la cerere (unde faceti rezervari de fisiere)
si site-download; aceste servicii sunt off-line (neconectate), asa incat
le puteti accesa fara modem, sau alt fel de conexiuni.

2.3. Alte tehnologii

Trebuie sa amintim si alte tehnologii satelitare: conexiunuea
dublu-sens (2-way). Acestea folosesc antena parabolica pentru conexiunea
la Internet in ambele sensuri. Costa mult mai mult decat
cele monosens. Asteptam mai multe in aceasta directie in vitorul apropiat,
la momentul actual permit o largime de banda de 4 Mb/s la download si 256k
la upload.

2.4. Care este largimea de banda maxima?

Depinde de multi factori: scopul ISP-ului, parametrul TCP window folosit,
aplicatiile folosite de clienti, si mai important decat toate,
“Congestia internet”. Va puteti astepta la o largime de banda maxima
de 1-4Mb/s si o medie de 10-30KBytes/s dar, repet, depinde de multi alti
factori.

Oricum, unele ISP-uri (Furnizori de Servicii Internet) pretind ca
va asigura “largime de banda maxima”, in timp ce media largimii de banda
poate fi mult mai mica, datorita congestiilor dintre ISP-uri.

Alte ISP-uri va garanteaza largimea de banda minima, ceea ce are o inteles
decat cea maxima, pentru ca este disponibila tot timpul.

Va rugam consultati Anexa A pentru a afla mai multe despre obtinerea
unor performante mai bune la download.

2.5. Cat costa ?

Noi am distins intre costurile hardware (ale echipamentelor)
si costurile conturilor. Primele sunt cunoscute, in timp ce ultimele
depind de ce servicii alegeti (garantate/negarantate, largime de banda
maxima).

2.5.1. Costurile hardware

Pentru a instala micul nostru sistem satelit avem nevoie de :

1. Cardul de acces
2. Antena parabolica
3. Unul sau mai multe convertoare (LNC-uri, LNB-uri)

trebuie utilizat un convertor digital pentru accesul Internet via satelit

Cardurile DVB costa intre 200$-300$ depinde de marca
Antena parabolica costa 50$
Convertorul LNB costa aproximativ 50$

Deci avem aproape 3-400$ costuri hardware (poate vreti sa adaugati
si costurile instalarii !!)

2.5.2. Costurile conturilor

Aici costurile depind de ce va ofera ISP-ul , care este largimea de banda,
daca exista largimi de banda garantate (care sunt mai importante decat
largimile maxime de banda), ce servicii puteti accesa, si asa mai departe.

Unele ISP-uri va ofera acces gratuit in schimbul vesnicei vizualizari a
unui banner (pe care nu il puteti minimiza), in acest caz veti plati
atunci cand veti cumpara ceva prezentat in banner.

Tipic, costurile conturilor se ridica la 100-150$ pe an pentru servicii
“negarantate” si 4-600$ sau mai mult pentru servicii “garantate” (va
garanteaza o largime de banda minima pe care o puteti folosi in momente de
congestie, evident congestii intre ISP-uri satelitare), cand ati “iesit”
catre Internet, nimeni nu va mai poate garanta nimic.

2.6. Care sunt satelitii utilizati?

Cand discutam de sateliti, ne referim la: Astra (19.2 grade SE), Hotbird
(13.2 grade SE), noul Europestar (45 grade SE), Eutelsat (8 grade
SV), Astra (26 E), Arabsat 3A (26E).

2.7. Ce ISP-uri ofera servicii Internet prin satelit?

In Europa cunoastem circa 8 ISP-uri care ofera acces Internet prin satelit:

1. EuropeOnLine – EON

2. Netsystem

3. Starspeeder

4. Sat Node

5. Eliosat

6. Falcon Stream

7. SkyDSL

8. OpenSky

9. DirecPC dar acesta foloseste un
card propietar (este unul dintre primele ISP-uri de acest tip)

EON ofera acces pentru aproximativ 150$ pe an fara largime
de banda garantata.

Netsystem ofera servicii la costuri nule, trebuie doar sa ii “suportati”
bannerele.

StarSpeeder ofera acces ???

Eliosat costa 350$ pe an cu 128k/s garantat (servicii minime, vedeti
site-ul web pentru mai multe informatii); pe langa aceasta, ofera si
tehnologia dublu-sens pentru a transmite si receptiona flux de date.

SkyDSL ofera acces pentru aproximativ 15$ pe luna cu 128k/s largime de
banda, dar permite largimi de banda mai mari pentru fiecare Mb downloadat
pe care il platiti (puteti selecta de la 256k la 4Mb/s),
pentru mai multe informatii vizitati site-ul web.

IMPORTANT: inainte de a va inregistra la vreunul dintre aceste servicii,
verificati aria de acoperire si diametrul necesar al antenei parabolice.

2.8. Altceva ?

Cu orice fel de card DVB puteti deasemeni receptiona si canale TV
digitale (doar cele gratuite), iar unele carduri au suport
pentru interfata comuna de decriptare a canalelor codate.

Urmeaza schema:

Smart-Card -> CAM -> Interfata Comuna -> Sat Card (cu suport C.I.)

Cardul CAM (sunt multe standarde folosite pentru decriptare: SECA, IRDETO,
VIACCESS si altele) este dispozitivul care permite decriptarea (pentru TV,
RADIO si date), in timp ce Interfata Comuna sau C.I. (ETSI EN
50221) permite conectarea intre CAM si cardul pentru satelit.

3. Informatii tehnice

Acum vom incerca sa intelegem cum functioneaza si in ce conditii, conexiunile
prin satelit.

Ne putem imagina legatura prin satelit ca o legatura fara fir
clasica, radio (wireless), intelegand prin asta o legatura intre
doua sisteme care nu folosesc un cablu pentru a comunica.

Legaturile fara fir sunt foarte diferite de cele cablate pentru ca
exista anumite probleme aditionale de rezolvat cum ar fi sensibilitatea,
problemele legate de securitate, s.a. Pot aparea si alte probleme legate
de vreme, in special in conditii de ploaie sau ninsoare.

Oricum, trebuie sa avem in vedere primul principiul al legaturilor fara
fir: vizibilitate directa libera de obstacole, care este IMPERATIVA si
fara de care nu putem comunica. Pentru mai multe informatii,
consultati documentul Wireless-HOWTO.
.

In conexiunile prin satelit folosim un tip special de antena, o antena
parabolica, care ne confera un castig mare la receptie, necesar pentru a
receptiona semnalul de la satelit. De fapt, satelitul are o orbita
geostationara la 36.000 km si singurul tip de antena pe care
il putem utiliza este antena parabolica.

3.2. Frecvente

Frecventele pe care le receptionam sunt de la 11Ghz la 12.7Ghz (de
la transponderul satelitului, emitatorul care ne trimite
date), o frecventa foarte inalta, dar fedderul (convertorul,
LNB-ul din centrul antenei parabolice) converteste acest semnal la
1-2Ghz asa incat putem trimite semnalul la receptor prin cablu (pana la
40m, depinde de pierderile cablului).

3.3. Cardul receptor DVB

1 GHz Signal –> |RX|–> |ADC| –> |Low Level Network| –> |O.S.TCP/IP Stack
|____________________________________|
DVB Card

Acum ne putem imagina un receptor clasic la 1Ghz receptionand semnale
analogice de la satelit, convertindu-le in semnale digitale si livrandu-le
catre nivelul de retea (ISO OSI 1,2): aici, codul firmware din
card genereaza pachete pe doua nivele (cam ca ethernet) pentru a
fi trimise catre pc-ul nostru cu linux, windows, sau alt sistem,
in final vom transforma aceste date in pachete TCP/IP.

3.4.Configurarea nivelului legaturii de date DVB

Aici avem de facut cateva setari la chiar la cartela DVB:

1. Frecventa de lucru, trebuie sa setam frecventa satelitului (ca in
reviste): este intre 11.8Ghz si 12.8Ghz de exemplu 12640000 Khz.

2. Rata simbolurilor, masurata in simboluri pe secunda, tipic 22 MS/s
(mega simboluri pe secunda)

3. Polarizarea, care este o setare a antenei, configurabila din software:
valorile posibile sunt H (orizontal) si V (vertical).

4. PID-urile. PID-ul este folosit pentru a selecta o transmisiune dintre
mai multe semnale ale aceleiasi frecvente.

5. Trebuie sa specificam si masca filtrului de biti care ne indica cat
de mare este grupul adreselor MAC destinatie (masca bitfilter este
similara netmaskului TCP/IP, singura diferenta este ca masca bitfilter
este pe 48 de biti, iar netmaskul TCP/IP este pe 32 biti. Intotdeauna,
datele Internet sunt transmise cu PID unicast, in timp
ce iformatiile video sunt transmise folosind PID multicast.

6. Calcularea adresei MAC: aici specificam care va fi adresa MAC a
cardului DVB. Trebuie facut acest lucru pentru ca unele ISP-uri folosesc
un algoritm (vezi anexa A pentru mai multe informatii) care va calculeaza
adresa MAC din adresa IP, alte ISP-uri folosesc propria dumneavoastra
adresa MAC.

3.5 Functionarea TCP/IP

Cum am aratat in sectiunea 2.2, trebuie sa facem o cerere folosind
interfata modem (de exemplu ppp0 sau orice alta interfata pe
care o folosim pentru a comunica cu Internetul), apoi raspunsul se
va intoarce la interfata noastra DVB (dvb0).

Sistemele de operare moderne ne permit sa receptinam datele printr-o
interfata de intrare diferita de cea prin care am facut cererea.
Pentru a face aceasta, e nevoie sa dezactivam controlul fluxului
pentru unele pachete, ca de exemplu cu comanda:

echo ” 0″ > /proc/sys/net/ipv4/conf/dvb0/rp_filter (pentru Linux).

3.6. Autentificarea

Ramane doar un singur lucru de completat in descrierea noastra: metoda de
autentificare.

Unele ISP-uri prin satelit folosesc asa-numita “autentificare prin proxy”:
cand folositi proxy-ul lor, trebuie sa indicati un nume de login si o
parola pentru a continua cererea (trebuie initial sa va inregistrati cu un
cont pentru a folosi serviciile lor prin satelit): odata facuta aceasta,
ISP-ul foloseste adresa IP a dumneavoastra pentru a calcula
adresa MAC (vezi anexa A) catre care va trimite raspunsul.

Alte ISP-uri va cer sa configurati o conexiune VPN intai (folosind login-ul
si parola dumneavoastra), apoi vor controla contul cu care sunteti
inregistrat (cand extrag adresa MAC) apoi vor trimite datele catre (si
numai) cardul dvs. DVB (adresa MAC).

Oricum, sa aveti in vedere ca puteti modifica valoarea filtrului DVB
pentru a fi capabil sa receptionati ORICE adresa MAC (raportata la o
frecventa data).

3.7 Servicii pe care le pot folosi cu o conexiune prin satelit

Tipic, serviciile pe care le puteti folosi cu o conexiune prin satelit
depind de tipul de autentificare folosit de ISP.

- cu clasica “autentificare proxy” puteti folosi doar serviciile HTTP
si FTP
- cu conexiunea VPN nu aveti (in principiu) nici o restrictie
la serviciile pe care le puteti folosi, singura limita este definita
de RTT (Timpul de acces) la satelit, aproximativ 500-1000ms in medie, asa
ca uitati de “voce” sau alte servicii in timp real !! (( Vedeti
documentul VoIP-HOWTO.

pentru mai multe informatii. Oricum, puteti totusi utiliza mail, chat,
telnet, ping, dns, si asa mai departe.

4. Cerinte

4.1 Cerinte privind cunostintele

Pentru aceste incercari aveti nevoie de ceva experienta in comunicatii
Internet si retele (continute in Net-HOWTO HOWTO/index.html> ) si o oarecare experienta practiva privind antenele
parabolice si sistemele pentru satelit (ar trebui sa stiti sa va orientati
antena, unghiurile corecte)

4.2 Hardware

Avem nevoie de:

1. Antena parabolica, de la un sistem analogic

2. Convertorul digital sa fie plasat in centrul antenei (LNB digital)

3. Cardul receptor compatibil DVB

4. Un PC cu care sa va conectati

4.3 Software

Aici aveti nevoie de :

1. Drivere pentru cardul DVB pentru a functiona sub sistemul dvs. de
operare (Linux, Windows sau altele)

2. Setarile corecte

3. Aplicatii externe, in anumite cazuri,ca si client VPN-PPTP pentru
ISP-uri ca Netsystem sau StarSpeeder

Pentru soft de Linux, puteti gasi drivere pentru Siemens DVB la Linux
TV Project .

4.4. Software TV

Tot astfel, exista software video pentru implementarea receptiei TV:

4.4.1 Sub Windows

1. MultiDec MultiDec 6.6b
(sursa gratuita
si cod)

2. TPREdit TPREdit (pentru Technotrend)

3. WinTV DVBs Hauppauge sau
Technotrend (pentru cardurile compatibile
Siemens, Hauppauge, Technotrend, Technisat, etc… )

4. WinDVB2000 WinDVB2000 (circa
19$).

4.4.2. Sub Linux

1. gVideo – aplicatie inclusa in driverul SIemens

2. Vdr Video Recorder (bun si pentru urmarit TV)

5. Configurarea echipamentului

5.1. Montarea

Primul lucru de facut este montarea antenei parabolice;

Dupa care trebuie sa o orientam (cautarea unghurilor corecte din diverse
reviste de specialitate): unghiurile sunt intotdeauna specificate de la sud
la est sau la vest pentru cele orizontale si de la sol catre linia
satelitului pentru cele verticale. Unealta clasica de orientare este
compasul.

5.2. Calibrarea

Cum putem sti daca ne-am orientat corect?

Dupa ce am stabilit plaja corecta de unghiuri, trebuie sa o ajustam masurand
nivelul de putere. Pentru aceasta putem

1. folosi de expemplu un receptor analogic (care este compatibil
cu convertorul digital) si sa trecem la cautarea unghiului corect.
Cand putem vedea imagine, inseamna ca l-am gasit. Va sugerez sa folositi
un convertor analogic pentru ca, poate aveti unul (pe care l-ati folosit
la o instalare anterioara) si pentru ca este mult mai simplu de calibrat
decat unul digital.

2. Folosit un instrument de masurare a puterii (vreo 20$) cu indicator
secvential (la putere maxima, toate ledurile se aprind).

5.3. LNB-uri duble

Puteti de asemeni sa folositi LNB-uri duble (unii comercianti vand
kituri complete cu distante standard de receptie,
de exemplu Astra (19.2 SE) cu Eutelsat (16 SE) sau cu Hotbird (13 SE).

Pentru montaj trebuie sa aveti in vedere, tot odata, ca satelitii sunt
in directii opuse ale convertorilor, ca in figura:

SAT1 SAT2
\ /
\ /
\ C1 C2 /
\ \ \ / / /
\ \ / \ / /
\____\ /___\ /_____/

Vedere de sus

C1 receptioneaza de la SAT2
C2 receptioneaza de la SAT1

5.4. Reglajul nivelului legaturii de date

Odata ce am obtinut semnalul analog, trebuie sa ajustam receptorul
nostru pe frecventa, PID-ul, rata de simboluri corecta, samd.

Prezint aici un exemplu de configurare pentru EON (EuropeOnline),
transponderul 114 pe satelitul Astra (19.2 SE)

Frecventa: 12640 MHz

Polarizarea: V (Vertical)

Symbol Rate: 22000 KS/s

PID:

· Unicast: 512 (decimal), 0×200 (hexadecimal)

· Multicast: 785, 786, 1041 (decimal), 0×311, 0×312, 0×411
(hexadecimal), dar sa aveti in vedere ca, in multe cazuri, Multicast
PID sunt alocate automat.

Mai avem nevoie de o informatie: ce adresa MAC sa ii alocam cardului DVB

Din nou, pentru EON (EuropeOnline) trebuie sa consultati anexa A
pentru a calcula adresa MAC din adresa IP dinamica.

Evident, aveti nevoie de login si de parola pentru respectivul
serviciu ISP

6. Configurarea sub Linux

In aceasta sectiune vom presupune ca folosim un card Siemens compatibil,
cum ar fi un card Hauppage WinTV DVB, pentru astfel de carduri
gasiti drivere la sau DVB PCI card
sub Linux .

6.1.Instalarea driverelor

Odata descarcate driverele, trebuie sa desfacem arhiva tar intr-un
director, intram in director si dam comanda “make” si “make insmod”.
Pentru aceasta, trebuie sa aveti sursele kernelului curent in directorul
/usr/src/linux (sau le descarcati de la http://www.kernel.org
si le recompilati.

Dupa comanda “make insmod”, sistemul dumneavoastra ar trebui sa aiba
modulele DVB incarcate. Pentru a le descarca, dati comanda “make rmmod”.

6.2. Configurarea fisierului /etc/dvbd.conf

Fisierul /etc/dvbd.conf este folosit pentru a configura
parametrii legaturii de date pentru cardul DVB. Aici sunt setarile
principale:

- “power” indica puterea pentru LNB, 1=ON, 0=off. De obicei o veti seta
1, doar daca nu folositi vreun fel de cascadare intre mai multe LNB-uri

- “symbolrate”, aceasta este rata simbolurilor pe secunda, de obicei
22.000.000

- “frequency” , frecventa la care se receptioneaza datele, cum ar fi
12.640.000

- “ttk” , semnalul de 22khz, aproape intotdeauna 1

- “diseqc”, folosit pentru controlul discriminarii, doar daca folositi
un discriminator pentru controlul mai multor LNB-uri, 0 daca nu e cazul

- “AFC” de obicei 1

- “polarization”, 1 pentru orizontal, 0 pentru vertical.

- ” filter_n ”, unde n este 0 pentru Unicast si
1-9 pentru Multicast; PID este exprimat in forma decimala, MAC
este adresa MAC valida doar pentru filtrul Multicast, iar BITFILTER este
numarul ai carui biti reprezinta bytes pentru masca ((de exemplu
10 = 2 (bit 1) + 8 (bit 3), asa ca masca va fi 00 00 FF 00 FF 00).

Exemplu:

——————————————

# standard location in /etc

# LNB power on=1/off=0

power 1

# symbol rate [symbol/sec]

symbolrate 22000000

# ASTRA TR 114

frequency 12640000

# 22 kHz signal on=1/off=0

ttk 1

# diseqc on=1/off=0

diseqc 0

# AFC on=1/off=0

AFC 1

# polarisation H=1/V=0

polarisation 1

# settings for MPE filter, PID and MAC filtering, valid MAC bytes

filter_0 512

filter_1 785 00:D0:5C:1E:96:01 48

filter_2 786 00:D0:5C:1E:96:01 48

filter_3 1041 00:D0:5C:1E:96:01 48

—————————————–

filter_0 nu are valori nici pentru MAC si nici pentru bitfilter pentru
ca adresa MAC potrivita este calculata din adresa IP (anexa A). Vom vedea
ca aceste setari sunt in regula numai pentru anumite ISP-uri,
pentru altele, va trebui sa modificam fisierul dvbd.c

6.3 Daemonul dvbd

Odata ce fisierul /etc/dvbd.conf este OK, puteti lansa aplicatia
dvbd care, executata fara optiunea -d scrie catre stdout nivelul calitatii
semnalului.

- Sync TREBUIE sa fie 127 sau pe-aproape

- Vber TREBUIE sa fie 0

doar daca nu cumva aveti o receptie slaba de la satelit (verificati cablul
si orientarea antenei)

Nota:

S-ar putea sa trebuiasca schimbat in dvbd.h aceasta linie:

#define network_device “eth0″

#define network_device “ppp0″

functie de ce interfata utilizati pentru a comunica cu Internetul,
eth0 sau ppp0, dati comanda “make” pentru a updata fisierul binar si
restartati dvbd.

6.4. Cum se configureaza serviciul EON (Europe Online)

Acum, daca aveti semnal bun, puteti incerca sa folositi un
serviciu Internet prin satelit.

Pentru EuropeOnline mergeti la setarea “proxy” din Netscape si setati la
HTTP si FTP:

proxy.xxx.europeonline.net

si, in “port” 8080 si FTP proxy cu ” port” 8090.

unde xxx este numarul transponderului (103,113,114 sau 115) pe care il
folositi (vedeti anexa B pentru mai multe informatii).

Acum va trebui sa puteti naviga cu browserul oriunde doriti…

Pentru a partaja serviciile EuropeOnline cu mai multi clienti, va trebui
sa folositi proxy-ul Squid , activand
cascadarea catre proxy-ul EON.

Pentru o mai complexa utilizare EON, cum ar fi o mai complexa cascadare a
proxy-urilor sau partajarea cu clientii, consultati EON Linux Masquerading
FAQ

6.5. Cum se configureaza serviciul Netsystem

Serviciul NetSystem este ceva mai complicat decat EON sub Linux, caz
in care, mai trebuie configurate:

1. conexiunea VPN

2. patch-ul pentru pppd (doar daca pppd <=2.4.0)

3. setarile de routere cu fisiere exemplu

4. patch-ul pentru dvbd.c

5. testarea

6. imbunatatirea performantelor

7. partajarea conexiunii NetSystem cu mai multi clienti

6.5.1 Conexiunea VPN

In primul rand trebuie sa descarcati aplicatia client VPN PPTP

Dupa desfacerea arhivei tar, compilare si instalare, trebuie sa
adaugati o intrare in fisierul /etc/ppp/pap-secrets si /etc/ppp/chap-secrets:

” login” * ” password” *

unde “login” si “password” sunt cele cu care v-ati inregistrat la NetSystem

6.5.2 Patch-ul pentru pppd

Asa cum se arata in descrierea PPTP
trebuie sa patch-uiti demonul pppd pentru a suporta conexiunile cu serverul
VPN NetSystem (server Linux).

Trebuie sa:

1. Descarcati o versiune recenta de pppd

2. Descarcati si dezarhivati patch-ul corespondent pentru pppd

3. dezarhivati pppd intr-un director

4. dati comanda “patch -p0 < nume_patch

5. intrati in directorul pppd

6. dati comanda “make” si “make install”

6.5.3. Setarile de routare

Acum pppd va fi capabil sa lucreze cu VPN-ul NetSystem. Puteti incerca cu

” pptp vpn.netsystem.com debug user ”

unde “login” este numele de login al contului dvs de la NetSystem;
veti vedea in /var/log/messages informatii de depanare de la interfata ppp1

Daca totul e OK ar trebui sa vedeti interfata ppp1 cu comanda “ifconfig”

Daca totusi aveti probleme cu atentificarea, adaugati “noauth” in fisierul
/etc/ppp/options

Odata ce interfata ppp1 a pornit, va trebui sa treceti la urmatoarele:

1. dati comanda “ifconfig ppp1″ si cautati adresa IP din dreapta
sirului “P-t-P:” (o voi numi in continuare IP)

2. stergeti-o din tabela de routare cu “route de IP”

3. adaugati-o la interfata ppp0 cu “route add IP dev ppp0″

4. stergeti gateway-ul implicit din ppp0 cu “route del default”

5. adaugati gateway implicit pentru ppp1 cu “route add default dev ppp1″

Punctele 1-3 sunt necesare pentru ca interfetele punct-la-punct sunt
administrate sub linux, adaugand gateway-ul la noua interfata (ceea ce
nu e o idee buna in cazul de fata, doar daca nu vreti sa
obtineti o bucla infinita, caz in care pachetul va circula la infinit,
icapsulandu-se in sine insusi ))

Punctele 4-5 sunt necesare pentru a face toate cererile de
date catre ppp1, adica vom avea contact cu lumea folosind conexiunea
VPN, aceasta nefiind solutia optima in anumite conditii, de exemplu pentru
interogarile DNS care ar putea fi trimise direct, pentru a evita
intarzierile prin satelit inutile.

In loc sa configurati manual rutarea, puteti incerca acest script:

” netsystem.on” script

______________________________________________________________________
route add IP_DNS1 dev ppp0
route add IP_DNS2 dev ppp0
route add -net 212.31.242.0 netmask 255.255.255.0 dev ppp0
pptp vpn.netsystem.com user
/bin/sleep 5
route add default dev ppp1
______________________________________________________________________

” netsystem.off” script

______________________________________________________________________
route del IP_DNS1 dev ppp0
route del IP_DNS2 dev ppp0
route del -net 212.31.242.0 netmask 255.255.255.0 dev ppp0
kill -9 ‘s x|grep “pppd”|grep “”|grep -v “ps”|tr ” ” “\n”|head -n
rm –force /var/lock/LCK..tty*
rm –force /var/run/pptp/*
route del -net 212.31.242.0 netmask 255.255.255.0 dev ppp0
kill -9 ‘s x|grep “pppd”|grep “”|grep -v “ps”|tr ” ” “\n”|head -n
rm –force /var/lock/LCK..tty*
rm –force /var/run/pptp/*
rm –force /var/run/ppp1.pid
killall -9 pptp
______________________________________________________________________

IP_DNS1 si IP_DNS2 sunt adresele IP ale serverelor dumneavoastra DNS
(primar si secundar), este numele de login al contului
dvs. Netsystem. L-am incercat sub kernelul 2.4.6 Redhat 7.1 si
functioneaza foarte bine (fara nici un fel de probleme legate de bucla
infinita ppp1 sau altele asemenea).

Aceasta linie ;

este folosita pentru a identifica PID procesului pppd care “discuta”
cu serverul VPN (interfata ppp1); notati ca nu puteti da comanda
“killall pppd” pentru ca ati inchide si interfata ppp0

6.5.4 Patch-ul pentru dvbd.c

Dupa rezolvarea problemelor legate de PPTP trebuie sa modificati
cateva linii in dvbd.c , in apropiere de finalul fisierului:

if (strcmp (v, “filter_0″) == 0) { if (s != NULL) { unsigned char ip[4];
dvbcfg[0].status = ON ;
dvbcfg[0].filter.data[0] = 0x3eff ;
dvbcfg[0].filter.pid = (__u16) atoi (s) ;
dvbcfg[0].filter.mode = 0x0c ;
if (ipget (ip, network_device)) { fprintf(stderr,”Can’t get local ip address.
syslog (LOG_NOTICE, “Local ip is %u:%u:%u:%u\n”, ip[0], ip[1],ip[2], ip[3]);
dvbcfg[0].filter.data[1] = (ip[3] << 8) | 0x00ff ;
dvbcfg[0].filter.data[2] = (ip[2] << 8) | 0x00ff ;
dvbcfg[0].filter.data[6] = (ip[1] << 8) | 0x00ff ;
dvbcfg[0].filter.data[7] = (ip[0] << 8) | 0x00ff ;
dvbcfg[0].filter.data[8] = (0×02 << 8) | 0x00ff ;
dvbcfg[0].filter.data[9] = (0×00 << 8) | 0x00ff ;
setmac (ip) ; }
else { dvbcfg[1].status = OFF ; } }

Urmatoarele linii:

dvbcfg[0].filter.data[1] = (ip[3] << 8) | 0x00ff ;

dvbcfg[0].filter.data[2] = (ip[2] << 8) | 0x00ff ;

dvbcfg[0].filter.data[6] = (ip[1] << 8) | 0x00ff ;

dvbcfg[0].filter.data[7] = (ip[0] << 8) | 0x00ff ;

dvbcfg[0].filter.data[8] = (0×02 << 8) | 0x00ff ;

dvbcfg[0].filter.data[9] = (0×00 << 8) | 0x00ff ;

vor fi inlocuite cu:

dvbcfg[0].filter.data[1] = (MAC[5] << 8) | 0x00ff ;

dvbcfg[0].filter.data[2] = (MAC[4] << 8) | 0x00ff;

dvbcfg[0].filter.data[6] = (MAC[3] << 8) | 0x00ff ;

dvbcfg[0].filter.data[7] = (MAC[2] << 8) | 0x00ff ;

dvbcfg[0].filter.data[8] = (MAC[1] << 8) | 0x00ff ;

dvbcfg[0].filter.data[9] = (MAC[0] << 8) | 0x00ff ;

Unde MAC[0]:MAC[1]:MAC[2]:MAC[3]:MAC[4]:MAC[5] sunt adresele noastre MAC
(conform contului Netsystem).

Dupa aceasta va trebui sa dati comanda “make” si noul dvbd va di creat.

NOTA: pentru a corecta cu succes dvbd.c trebuie sa folositi un driver dvb
versiune >=0.8.2 pentru ca versiunile mai vechi au probleme de
instabiliate

6.5.5 Testarea

In final, putem testa Netsystem de sub Linux. Putem da o comanda
“ping www.oricehostpingabil.com” si sa verificam timpul de raspuns. Ar
trebui sa fie intre 400 si 2000 ms.

Daca mai aveti probleme, va trebui sa verificati daca e totul OK
cu interfata VPN.

1. deschideti snifferul de retea preferat (de exemplu, Ethereal
si incepeti sa analizati interfata ppp0 (nu ppp1 !!!)

2. dati un ping

Daca VPN-ul e ok, ar trebui sa vedeti 2 (poate 1) pachete incapsulate-GRE
pe secunda. Daca nu vedeti nimic, VPN-ul nu merge corect. Opriti-l
si porniti-l din nou.

6.5.6. Imbunatatirea performantelor

Odata ce ati pus la punct lucrurile, TREBUIE sa folositi (in special cu
Netsystem) un download accelerator pentru a imbunatati performantele.
Vedeti anexa A pentru mai multe informatii.

6.5.7 Partajarea Netsystem cu mai multi clienti

Pentru aceasta puteti activa IP Masquerading-ul, permitand clientilor sa
foloseasca VPN ca o interfata Internet normala; principala problema
este ca, conexiunea noastra prin satelit este foarte buna pentru
download dar are performante slabe la navigarea in paginile web (sau
alte servicii mai interactive decat download-ul).

Va puteti gandi la utilizarea proxy-ului Squid
sau Socks , dar nu
veti rezolva problema pentru ca si acum toate cererile for fi trimise catre
aceiasi interfata VPN.

Solutia este sa folositi 2 tabele de rutare, una folosind interfata directa
de linie si cealalta interfata VPN. Asa ca puteti face cum urmeaza:

1. asigurati-va ca ati instalat comenzile “iproute2″ (de pilda
dati comanda “ip” in shell si verificati daca va spune ceva.
Pentru mai multe informatii, consultati Linux 2.4 Advanced Routing HOWTO
.

2. asigurati-va ca ati pornit serviciile NetSystem si notati-va adresa
IP a interfetei ppp1, pe care o vom numi acum LOCALIP.

3. tastati: ” echo ” 210 sat” >> /etc/iproute2/rt_tables” pentru a apela
cat mai confortabil regula 210 pentru satelit

4. tastati: ” ip rule add from LOCALIP table sat” , pentru a crea tabela
“sat”

raportata la toate cererile venind de la adresa IP LOCALIP

5. tastati: ” ip route add default dev ppp1 table sat”
pentru a trimite toate cererile “sat” (vezi mai sus) catre interfata ppp1

6. daca folositi proxy-ul Socks fiti siguri
ca ati setat in sockd.conf “external” pentru LOCALIP

7. daca folositi proxy-ul Squid fiti siguri
ca ati setat in squid.conf ” tcp_outgoing_address” ca LOCALIP

Odata ce ati facut toate acestea, veti observa ca aveti doua moduri de
lucru: fara proxy, clientii for adresa cereri catre linia directa, iar
in prezenta unui proxy (squid sau sockd) cererile vor fi inaintate
interfetei VPN si, in final, catre satelit.

Observati ca s-ar putea sa aveti nevoie de sockd in loc de squid pentru
ca cererile catre satelit sunt folosite in special pentru download, in
timp ce squid-ul este tipic folosit pentru browsing.

6.6. Cum se utilizeaza serviciul Sat Node

Trebuie sa urmati toate instructiunile de la NetSYstem.

Inainte de a activa conexiunea VPN , trebuie sa :

.
.
.
. pentru a va conecta la serverul vpn doar prin ppp0
?????? lipsesc parti din howto-ul in limba engleza?????????

Ce se schimba fata de Netsystem este ca nu fortam gateway-ul VPN
(212.56.224.34, IP-ul de la drepta lui ”P-t-P” in interfata ppp1) in
interfata ppp0, dar fortam un alt IP (212.56.224.36). Restul nu se schimba.

Multumiri lui Ricardo Santiago Mozos si Norberto Garcia Prieto.

7. Configurarea sub Windows

7.1. EON

Hauppage WinTV are aplicatii DVB-DATA care permit speficiarea setarilor
legaturii de date.

7.2 Netsystem

In primul rand e nevoie sa instalati resursele VPN. Aditional, e nevoie sa
descarcati software-ul Netsystem (intotdeauna cu banner) si sa il lansati.
Il puteti descarca de aici:

8. Anexa A – NOTE

8.1. Translatarea IP dinamic > adrese MAC

Translatarea folosita de unele ISP-uri pentru a calcula adresa MAC (pe
care cardul DVB trebuie sa o aiba pentru a receptiona pachete) este:

00 : 01 : IP[0] : IP[1] : IP[2] : IP[3]

unde

IP[0].IP[1].IP[2].IP[3] este adresa IP dinamica.

Aceasta caracteristica este folosita de exemplu de EON.

8.2 Cadrul TCP

Conexiunile prin satelit sunt un interesant exemplu de foarte mari RTT
(round trip time, timp de acces): un alt exemplu
este comunicatia Marte-Pamant sau Pamant-Luna.

Aceste conexiuni au o trasatura foarte proasta: foarte scazuta
interactivitate.

Conexiunile de retea tipice (sau digitale, in general) folosesc asa numita
transmisie in “cadre”, ceea ce inseamna ca bufferul de date poate fi
trimis inainte de a astepta un raspuns. In stiva
protocolului TCP/IP, “cadrul” TCP arata cam asa:

———————-
| – - – - – - – > poate continua |-|-|-|—->
| ———————-
| Buffer transmisibil inaintea confirmarii
|
| – - – - – - – <———————-
Confirmare

Acum, daca in comunicatia noastra avem un timp mare de acces si daca am
avea un cadru TCP mic, am pierde mult timp doar asteptand confirmarea
(ACK), asa incat largimea de banda reala ar scadea (de exemplu, daca avem
un cadru TCP de 16kb, tipic pentru sistemele Windows, si RTT de 400ms, nu
se pate depasi 16KB/0.4 = 40 KB/s)

Solutia este utilizarea unor cadre TCP foarte mari (ca 256kb sau cativa MB)

Din pacate, sub multe sisteme nu este posibil sa avem
un cadru TCP mare, asa ca in ultimii ani au aparut multe
aplicatii, asa numitele “download acceleratoare” care impart
in multe fragmente un fisier si le descarca pe toate simultan. Aceasta
este echivalent cu a descarca un singur fisier dintr-o singura bucata,
evitand problemele RTT-ului.

8.3 Download accelerator

Va indicat cateva link-uri catre asa numitele “download acceleratoare”,
aplicatii care fac doua lucruri:

1. managementul resuming-ului sesiunilor; permit oprirea download-ului
si continuarea lui (aceasta poate fi facuta multumita posibilitatii de
“resume” introdusa in serverele http si ftp, care permite specificarea la
ce numar de bit sa inceapa download-ul);

2. impartirea fisierului in multe fragmente si posibilitatea lor
de a “pleca” in maniera multithread;

Asa cum am vazut in sectiunea precedenta, download acceleratorul permite
cresterea largimii de banda

8.3.1 Sub Linux

· Aria

8.3.2 Sub Windows

· FlashGet

· GetRight

· Mass Downloader

9 Anexa B – Valori cunoscute pentru ISP-urile prin satelit

9.1 Europe Online

EON trimite date prin satelitul Astra (19.2 SE)

Adresa MAC este calculata din adresa IP (anexa A)

Foloseste autentificarea proxy

urmeaza setarile pentru cei 4 transponderi:

9.1.1. Transponder 113

· Frequency: 12633.250 MHz,

· SRate : 22 MS/s

· Polarization: Horizontal

· Unicast PID: 512 (decimal)

9.1.2. Transponder 114

· Frequency: 12640 MHz,

· SRate : 22 MS/s

· Polarization: Vertical

· Unicast PID: 512 (decimal)

9.1.3. Transponder 115

· Frequency: 12662.750 MHz,

· SRate : 22 MS/s

· Polarization: Horizontal

· Unicast PID: 512 (decimal)

9.1.4. Transponder 103

· Frequency: 12461 MHz,

· SRate : 27.5 MS/s

· Polarization: Horizontal

· Unicast PID: 512 (decimal)

9.2 Netsystem

Foloseste satelitul Astra (19.2 SE) pentru a trimite date.

Adresa MAC este adresa reala a cardului DVB.

Foloseste conexiune VPN.

urmeaza datele setarilor:

9.2.1. Transponder 119

· Frequency: 12721 MHz

· SRate: 22MS/s

· Polarization: Horizontal

· Unicast PID: 451 (decimal)

9.3. Sat Node

Sat Node foloseste satelitul Astra (19.2 SE).

· Frequency: 12603.750 MHz

· SRate: 22MS/s

· Polarization: Horizontal

· Unicast PID: 302

Folosirea lui iptables pentru filtrarea pachetelor in kernelurile versiunea 2.4

admin — Wed, 06 Apr 2011 12:47:32 +0000

traducere ver. 0.6 de catre Riddl

Multumiri tuturor celor care m-au ajutat. Lui Gushterul in special.
Deasemenea multumiri si lui Little Dragon.
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 mail me (Riddl) at
“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 aiurea in ro.
Pentru ultima versiune a acestui document verifica
.

Lecturare placuta!

______________________________________________________________________

Linux 2.4 Packet Filtering HOWTO
Rusty Russel, lista de discutii netfilter@lists.samba.org
$Revision: 1.2 $ $Date: 2002/02/19 11:33:43 $

Acest document descrie folosirea lui iptables pentru filtrarea pachetelor in
kernelurile versiunea 2.4.
______________________________________________________________________

Cuprins

1. Introducere
2. Care este site-ul oficial? Exista vreo lista de discutii?
3. Deci, ce inseamna filtru de pachete?
3.1 De ce as vrea sa filtrez pachetele?
3.2 Cum filtrez pachetele sub linux?
3.2.1 iptables
3.2.2 Crearea regulilor permanente
4. Cine dracu esti tu, si de ce te joci cu kernelul meu?
5. Ghidul intr-adevar rapid al lui Rusty pentru filtrarea de pachete
6. Cum traverseaza pachetele filtrele?
7. Folosirea iptables
7.1 Ce vei vedea cand porneste calculatorul
7.2 Operatii pentru o singura regula
7.3 Optiuni de filtrare
7.3.1 Specificarea IP-ului sursa si destinatie
7.3.2 Specificarea inversa
7.3.3 Specificarea protocolului
7.3.4 Specificarea unei interfete
7.3.5 Specificarea fragmentelor
7.3.6 Optiuni extinse la iptables: Noi potriviri
7.3.6.1 Optiuni extinse TCP
7.3.6.1.1 O explicatie pentru flag-urile TCP
7.3.6.2 Optiuni extinse UDP
7.3.6.3 Optiuni extinse ICMP
7.3.6.4 Alte optiuni extinse pentru potrivire
7.3.6.5 Potrivirea dupa stare
7.4 Argumente asupra tintei
7.4.1 Chain-uri definite de utilizator
7.4.2 Optiuni extinse la iptables: Noi tinte
7.4.3 Tinte speciale construite default
7.5 Operatii asupra unui intreg chain
7.5.1 Creearea unui nou chain
7.5.2 Stergerea unui chain
7.5.3 Stergerea tuturor regulilor unui chain
7.5.4 Listarea unui chain
7.5.5 Resetarea counter-elor
7.5.6 Setarea policy-ului

8. Folosirea ipchains si ipfwadm
9. Folosirea impreuna a NAT-ului si a filtrarii de pachete
10. Diferente intre iptables si ipchains
11. Sfaturi asupra designului filtrului de pachete

______________________________________________________________________

1. Introducere

Bine ai venit, cititorule. (:))

Se presupune ca stii ce este aceea o adresa IP, adresa de retea, netmask,
routare si DNS. Daca nu, se recomanda sa citesti Network Concepts Howto.
Acest HOWTO loveste intre o introducere draguta (care te poate lasa
increzator pentru moment, dar neprotejat in lumea reala) si o dezvaluire
total neprelucrata (care ii vor lasa pe toti, mai putin caracterele tari,
in confuzie, paranoici si in cautarea de arme grele).

Reteaua ta nu este sigura. Problema permiterii comunicarii rapide si
comode, in acelasi timp cu restrictia acesteia numai pentru bine si nu in
mod malefic, este asemanatoare cu alte probleme opuse cum ar fi permiterea
vorbirii libere in acelasi timp cu refuzarea unui strigat de “FOC!!” intr-un
teatru aglomerat. Nu va fi rezolvata aceasta problema in spatiul acestui
HOWTO.

Asa ca doar tu poti sa decizi unde va fi compromisul. Voi incerca sa te
instruiesc in folosirea unor comenzi disponibile si a unor vulnerabilitati
de care sa fii constient, in speranta ca vei folosi aceasta in mod pozitiv
si nu in scopuri malefice. Aceasta este o alta problema asemanatoare.

2. Care este site-ul oficial? Exista vreo lista 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:
.

3. Deci, ce inseamna filtru de pachete?

Un filtru de pachete este o bucatica de software care se uita la header-ul
pachetelor pe masura ce ele intra, si decid soarta intregului pachet. Acest
filtru poate decide sa ignore pachetul (DROP) (respinge pachetul ca si cum
nu l-ar fi primit niciodata), accepta (ACCEPT) pachetul (lasa pachetul sa
intre), sau alte decizii mai complicate.

Sub linux, filtrarea de pachete este construita in kernel (ca modul sau
construita in el), si sunt cateva lucruri complicate pe care le putem face cu
pachetele, dar principiul general de examinare al header-ului pachetului si
decidere asupra sortii pachetului este inca acolo.

3.1 De ce as vrea sa filtrez pachetele?

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-i 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.

3.2 Cum filtrez pachetele sub linux?

Kernelurile Linux au avut filtrare de pachete inca de la versiunile 1.1.
Prima generatie, bazata pe ipfw de la BSD, a fost portata de catre Alan Cox
spre sfarsitului anului 1994. Aceasta a fost dezvoltata de catre Jos Vos si
altii pentru Linux 2.0; comanda pentru utilizatori “ipfwadm” controla
regulile de filtrare ale kernelului. La mijlocului anului 1998, pentru Linux
2.2, am rescris puternic kernelul cu ajutorul lui Michael Neuling, si am
introdus comanda pentru utilizatori “ipchains”. In sfarsit, a patra generatie
de comenzi, “iptables”, si o noua rescriere a kernelului s-a intamplat la
mijlocul anului 1999 pentru Linux 2.4. Acest HOWTO este centrat pe iptables.

Ai nevoie de un kernel care are infrastructura netfilter in el: netfilter este
un cadru in interiorul kernelului Linux in care alte lucruri (cum ar fi
modulul de iptables) se pot introduce. Asta inseamna ca ai nevoie de kernel
versiune 2.3.15 sau peste, si sa raspunzi “Y” la CONFIG_NETFILTER in
configurarea kernelului.

Comanda iptables comunica kernelului si ii spune ce pachete sa filtreze.

3.2.1 iptables

Comanda iptables insereaza si sterge reguli din tabela de filtrare a
pachetelor din kernel. Asta inseamna ca orice vei seta, va fi pierdut dupa
rebootare; vezi “Crearea regulilor permanente” pentru cum sa fii sigur ca vor
fi restaurate data urmatoare cand va boota Linuxul.

iptables este un inlocuitor pentru ipfwadm si ipchains: vezi “Folosirea
ipchains si ipfwadm” pentru a afla cum poti evita fara probleme folosirea
iptables daca folosesti una din aceste comenzi.

3.2.2 Crearea regulilor permanente

Setarile firewall-ului tau curent sunt pastrate in kernel, si de aceea vor fi
pierdute la rebootare. Poti folosi scripturile iptables-save si
iptables-restore sa le salvezi, sau restaurezi dintr-un fisier.

O alte cale este sa pui comenzile cerute sa iti setezi regulile intr-un
script de initializare. Ai grija sa faci ceva inteligent in caz ca una din
comenzi nu ar reusi (de obicei “exec /sbin/sulogin”).

4. Cine dracu esti tu, si de ce te joci cu kernelul meu?

Sunt Rusty Russel; cel ce mentine Linux IP Firewall si doar un alt
programator care s-a intamplat sa fie in locul potrivit la momentul potrivit.
Am scris ipchains (vezi mai sus “Cum filtrez pachetele sub linux?” pentru a da
credit celor care au facut de fapt munca), si am invatat suficient sa fac
cum trebuie de data asta filtrarea de pachete. Sper.

WatchGuard , o compania excelenta de firewall-uri
care vinde chiar simpaticul plug-in Firebox, s-a oferit sa ma plateasca sa nu
fac nimic, pentru a-mi petrece tot timpul meu sa scriu asta, si sa imi
mentin munca anterioara. Am preconizat 6 luni, si mi-au luat 12, dar la
sfarsit am simtit ca l-am facut cum trebuie. Multe rescrieri, o cedare a
unui hardisk, un laptop furat, doua sisteme de fisiere corupte si un
monitor spart mai tarziu, asta este.

Cat sunt aici, vreau sa indrept niste idei gresite ale unor oameni: nu sunt
un guru al kernelului. Stiu asta, pentru ca munca mea pe partea din kernel
m-a adus in contact cu unii din acestia: David S. Miller, Alexey Kuznetsov,
Andi Kleen, Alan Cox. Oricum, sunt cu totii ocupati sa faca magia din
interior, lasandu-ma sa avansez cu greu prin superficialitate unde este
sigur.

5. Ghidul intr-adevar rapid al lui Rusty pentru filtrarea de pachete

Cei mai multi oameni au o singura conexiune PPP spre Internet, si nu vor ca
cineva sa intre inapoi in reteaua lor, iata firewall-ul:

## Se insereaza modulele pentru connection-tracking (nu este necesar
## daca sunt compilate in kernel)
# insmod ip_conntrack
# insmod ip_conntrack_ftp

## Se creeaza chain-ul care blocheaza conexiunile noi, cu exceptia celor
## venite din interior.

# iptables -N block
# iptables -A block -m state –state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state –state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP

## Se sare la acest chain din chain-urile INPUT si FORWARD
# iptables -A INPUT -j block
# iptables -A FORWARD -j block

6. Cum traverseaza pachetele filtrele?

Kernelul porneste cu trei liste de reguli in tabela de “filtrare”; aceste
liste sunt numite chain-uri ale firewall-ului sau pur si simplu chain-uri
(lanturi). Cele trei chain-uri se numesc INPUT, OUTPUT si FORWARD.

Pentru fanii ASCII, chain-urile sunt aranjate cam in felul urmator: (Nota:
acesta este un aranjament foarte diferit fata de cel din kernelurile ver.
2.0 si 2.2 !)

Cele trei cercuri reprezinta cele trei chain-uri despre care am vorbit
anterior. Cand un pachet ajunge la un cerc din diagrama, acel chain este
examinat pentru a decide soarta pachetului. In cazul in care chain-ul spune sa
ignore pachetul (DROP), este taiat acolo, daca insa chain-ul spune sa accepte
pachetul (ACCEPT), atunci pachetul continua sa parcurga diagrama.

Un chain este o lista de verificare cu reguli. 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
(lant) este examinata. In final, daca nu mai exista reguli de examinat,
kernelul se uita la politica acelui chain-ului pentru a decide soarta pachetului.
Intr-un sistem sigur, politica in chain-uri este de obicei sa taie pachetul
(DROP).

1. Cand un pachet vine (sa zicem, prin placa de retea) kernelul se
uita intai la destinatia pachetului: aceasta se numeste “routing”
(rutare).

2. Daca pachetul este destinat pentru aceasta masina, pachetul trece pe
diagrama in chain-ul INPUT. Daca trece de acest chain, orice proces care
asteapta acel pachet il va primi.

3. In caz contrar, daca kernelul nu are forwarding-ul pus, sau nu stie
cum sa forward-eze pachetul, acesta este ignorat. Daca este pus
forwarding-ul, si pachetul are ca destinatie o alta interfata de
retea (daca mai ai inca una), atunci pachetul se duce in diagrama
noastra direct catre chain-ul FORWARD. Daca este acceptat pachetul va
fi transmis.

4. In final, un program ce ruleaza pe sistem poate trimite pachete.
Aceste pachete trec direct in chain-ul OUTPUT: daca este acceptat
pachetul isi continua drumul fara sa conteze interfata spre care este
destinat.

7. Folosirea iptables

iptables are o pagina de manual destul de detaliata (man iptables), si daca
ai nevoie de detalii mai in amanunt. Aceia dintre voi familiarizati cu
ipchains vor dori poate sa se uite la “Diferente intre iptables si
ipchains”; sunt comenzi foarte similare.

Sunt mai multe lucruri pe care le poti face cu iptables. Pornesti la drum cu
trei chainu-ri default care nu pot fi sterse INPUT, OUTPUT si FORWARD. Sa
privim operatiile care se pot aplica pentru un intreg chain:

1. Creearea unui chain nou (-N).
2. Stergerea unui chain gol (care nu contine reguli) (-X).
3. Schimbarea politicii pentru un chain default (-P).
4. Listarea regulilor dintr-un chain (-L).
5. Stergerea tuturor regulilor dintr-un chain (-F).
6. Resetarea counter-elor de pachete si bytes pentru toate regulile
dintr-un chain (-Z).

Sunt mai multe moduri in care se pot manipula regulile intr-un chain:

1. Adaugarea in coada chain-ului a unei noi reguli (-A).
2. Insereaza o regula noua la o anumita pozitie in chain (-I). Daca
nu este precizata pozitia printr-un numar atunci regula este adaugata
la inceputul chain-ului.
3. Inlocuieste o regula la o anumita pozitie in chain (-R).
4. Sterge o regula la o anumita pozitie in chain, sau prima care se
potriveste (-D).

7.1 Ce vei vedea cand porneste calculatorul

Iptables poate fi un modul, numit (“iptable_filter.o”), care ar trebui sa fie
incarcat in mod automat cand rulezi prima oara iptables. Poate fi deasemenea
compilat in kernel in mod permament.

Inainte de rularea oricarei comenzi iptables (ai grija: unele distributii vor
rula iptables in scripturile lor de initializare), nu vor fi reguli in nici
una din chain-urile default (“INPUT”, “OUTPUT” si “FORWARD”), toate
chain-urile vor avea politica de acceptare a pachetelor (ACCEPT). Poti schimba
politica default al chain-ului FORWARD prin stipularea optiunii “forward=0″
modulului iptable_filter. (n.t. sau “echo 0 > /proc/sys/net/ipv4/ip_forward”,
depinde insa si de distributie, pe redhat default inseamna ca forward-ul
este 0)

7.2 Operatii pentru o singura regula

Aceasta este paine-si-untul, sarea si piperul, si ce mai vreti voi, a filtrarii
de pachete; manipularea regulilor. Cel mai obisnuit, vei folosi probabil
comenzile de adaugare (-A) si stergere (-D). Celelalte (-I pentru inserare
si -R pentru inlocuire) sunt doar extensii ale acestor concepte.

Fiecare regula specifica o multime de conditii pe care un pachet trebuie sa le
indeplineasca si ce sa faca daca acestea sunt indeplinite (o “tinta”
(target)). De exemplu, s-ar putea sa doresti sa ignori toate pachetele de
tip ICMP care vin de la adresa 127.0.0.1. Deci, in acest caz conditiile
noastre sunt ca protocolul sa fie ICMP si ca adresa sursa sa fie 127.0.0.1.
“tinta” noastra este DROP. 127.0.0.1 este interfata “loopback”, pe care o ai
chiar daca nu ai conexiune reala de 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 DROP
# 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 “DROP” (“-j DROP”).

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. (:)),
cat de DRAMATIC)

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 in chain-ul de 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:

# iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
#

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.

7.3 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.

7.3.1 Specificarea IP-ului sursa si destinatie

Adresele IP ale sursei (“-s”, “–source” sau “–src”) si destinatiei (“-d”,
“–destination” sau “–dst”) 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:

[ NOTA: "-s 0/0" este redundant aici. ]
# iptables -A INPUT -s 0/0 -j DROP
#

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

7.3.2 Specificarea inversa

Multe optiuni, inclusiv optiunile “-s” (sau “–source”) si “-d”
(“–destination”) 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.

7.3.3 Specificarea protocolului

Protocolul poate fi specificat prin optiunea “-p” (sau “–protocol”).
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.

7.3.4 Specificarea unei interfete

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

Pachetele care traverseaza chain-ul “INPUT” nu au o interfata de iesire, asa
ca orice regula care foloseste “-o” in acest chain nu se va potrivi
niciodata. In mod similar pachetele care travereseaza chain-ul OUTPUT nu au o
interfata de intrare, asa ca orice regula care foloseste “-i” in acest
chain nu se va potrivi niciodata.

Doar pachetele care travereseaza chain-ul FORWARD au o interata de intrare si
de iesire. 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 “!” cu spatii in jur, pentru a
corespunde cu pachetul care nu se potriveste cu intefata specificata, de
exemplu: -i ! ppp+.

7.3.5 Specificarea fragmentelor

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 primul fragment are campurile complete in
header (IP + TCP, UDP si ICMP) pentru a le examina, dar cele care urmeaza au
doar o submultime a header-elor (IP fara campurile protocolului aditional).
De aceea privirea in header-e dupa protocol in pachetelor care urmeaza (cum se
face in cazul TCP, UDP si ICMP) nu este posibila.

Daca faci connection tracking sau NAT, atunci toate fragmentele vor fi reunite
inainte de a ajunge la codul filtrului de pachete, asa ca nu trebuie sa te
ingrijorezi vreodata pentru fragmente.

Te rog sa retii de asemenea: chain-ul INPUT al tabelei de filtrare (sau a
oricarei alte tabele care depinde de NF_IP_LOCAL_IN) este traversat dupa
defragmentarea stivei principale IP.

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 –sport 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 –sport ! www.

Oricum, poti sa specifici o regula special pentru fragmentul al doilea si
urmatoarele, folosind optiunea “-f” (sau “–fragment”). 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 ignorate cand asemenea examinarii sunt incercate.
Astfel sunt si fragmentele TCP care pornesc de la pozitia 8.

Ca un exemplu, urmatoarea regula va ignora fragmentele care se duc spre
192.168.1.1:

# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP
#

7.3.6 Optiuni extinse la iptables: Noi potriviri

iptables este extensibil, asta inseamna ca amandoua, iptables si kernelul pot
fi extinse pentru a suporta noi optiuni.

Unele dintre aceste optiuni sunt standard, altele sunt mai exotice. Aceste
optiuni pot fi facute de catre alti oameni si distribuite.

Extensiile kernelului sunt gasite deobicei in subdirectorul de module ale
kernelului cum ar fi /lib/modules/2.4.0-test10/kernel/net/ipv4/netfilter. Ele
se incarca automat daca kernelul tau a fost compilat cu optiunea CONFIG_KMOD,
asa ca nu o sa fie necesar sa le incarci manual.

Extensiile la programul iptables sunt librarii shared care de obicei se gasesc
in /usr/local/lib/iptables/, deseamenea o distributie poate sa le puna in
directorul /lib/iptables sau /usr/lib/iptables.

Optiuniile vin in doua feluri: noi tinte si noi potriviri (vom vorbi despre
tinte ceva mai tarziu). Unele protocoale automat ofera noi teste pentru
pachete: in mod curent acestea sunt TCP, UDP si ICMP, cum sunt aratate mai jos.

Pentru acestea vei putea sa specifici noile teste in linia de comanda dupa
optiunea “-p”, care va pune la dispozitie automat optiunile extinse. Pentru
a preciza teste noi, foloseste optiunea “-m” pentru a incarca extensia, dupa
care optiunile extinse vor putea fi folosite.

Pentru a vedea help-ul pentru optiunile extinse foloseste optiunea de
incarcare (“-p”, “-j” sau “-m”) urmat de “-h” sau “–help”, de exemplu:

# iptables -p tcp –help
#

7.3.6.1 Optiuni extinse TCP

Optiunile extinse TCP sunt disponibile in mod automat daca se specifica
optiunea “-p tcp”. Aceste optiuni sunt urmatoarele (nici una dintre ele nu
se vor potrivi cu fragmente):

–tcp-flags
poate fi urmat de semnul optional “!”, apoi de doua siruri de
flag-uri, care permite filtrarea dupa anumite flag-uri. Primul sir de
flag reprezinta mask-ul, flag-urile pe care doresti a le examina. Al
doilea sir reprezinta care dintre acestea ar trebui sa fie prezente.
De exemplu:

# iptables -A INPUT –protocol tcp –tcp-flags ALL SYN,ACK -j DROP

Aceasta comanda spune ca toate flag-urile trebuiesc examinate (“ALL”
este sinonim cu “SYN,ACK,FIN,RST,URG,PSH”), dar doar SYN si ACK
trebuie sa fie setate. Exista de asemnea un argumente “NONE” similar
pentru nici unul dintre acestea.

–syn
In mod optional precedata de semnul “!”, este o prescurtare pentru
“–tcp-flags SYN,RST,ACK SYN”

–source-port
poate fi urmat de un optional “!”, si fie de un singur port, fie
de o sir de porturi. Porturile pot fi specificate fie folosind numere
fie folosind nume, asa cum sunt specificate in /etc/services.
sirurile se specifica prin doua porturi despartite de “:”, sau
(pentru a specifica o sir de porturi mai mare sau egal cu un port
dat) un port urmat de “:”, sau (pentru a specifica o lista de porturi
mai mica sau egala decat un port dat) un port precedat de “:”.

–sport este sinonim cu –source-port

–destination-port
si
–dport
sunt similare cu modul in care se specifica portul sursa numai ca in
loc de portul sursa se face potrivirea dupa portul destinatie.

–tcp-option
urmat de un optional “!” si un numar, se potriveste pentru un
pachet cu optiunea TCP egala cu acel numar. Un pachet care nu are un
header complet TCP este ignorat automat daca este facuta incercarea
de a se examina headerele TCP.

7.3.6.1.1 O explicatie pentru flag-urile TCP

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 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 “–syn” 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 –syn

Aceasta optiune poate fi inversat prin precedarea “–syn” cu semnul “!”.

7.3.6.2 Optiuni extinse UDP

Aceste optiuni sunt automat disponibile cand se specifica “-p udp”. Acestea
sunt: “–source-port”, “–sport”,”–destination-port” si “–dport” care au
fost detaliate mai sus.

7.3.6.3 Optiuni extinse ICMP

Aceste optiuni sunt automat disponibile cand se specifica “-p icmp”. Este
doar o singura optiune noua:

–icmp-type
urmat de un semnul optional “!”, apoi de numele tipului icmp (ex.
“host-unreachable”), sau tipul numeric (ex. “3″), sau tipul numeric
si codul separate de “/” (ex. “3/3″). O lista a numelor de tipuri de
pachete icmp este data folosind “-p icmp –help”.

7.3.6.4 Alte optiuni extinse pentru potrivire

Alte optiuni extinse in pachtetul de filtrare sunt optiuni demonstrative,
care (daca sunt instalate) pot fi invocate cu optiunea “-m”.

mac

Acest modul trebuie in mod explicit specificat prin optiunea “-m mac”
sau “–match mac”. Este folosit pentru a se potrivi cu pachetele ce au o
anumita adresa ethernet MAC, si de aceea este folositoare numai
pentru pachetele care traverseaza chain-urile PREROUTING si INPUT.
Este disponibila o singura optiune noua:

–mac-source
urmat de semnul optional “!”, apoi de o adresa ethernet in notatie
hexa separata prin “:”, ex. “–mac-source 00:60:08:91:CC:B7″.

limit

Acest modul trebuie in mod explicit specificat prin optiunea “-m limit”
sau cu “–match limit”. Este folosit pentru a restrange rata de
potriviri, ca de exemplu pentru reprimarea mesajelor in log-uri
(log-urile sunt fisierele in care sistemul scrie anumite date
considerate importante, in ideea de a putea fi accesate mai tarziu). Se
vor potrivi numai un numar dat de pachete pe secunda (default 3
potriviri pe ora, la un numar maxim de 5 potriviri). Sunt disponibile
doua optiuni:

–limit
urmat de un numar; specifica numarul maxim de potriviri permise pe
secunda. Numarul poate fi specificat pe unitati de timp explicite,
folosind “/second”, “/minute”, “/hour” or “/day”, sau parti din ele
(ex. “5/second” este la fel cu “5/s”).

–limit-burst
urmat de un numar, indica numarul maxim de potriviri dupa care limita
de mai sus intra in actiune.

Aceasta potrvire poate adesea fi folosita cu tinta LOG pentru a face
logare limitata dupa o rata. Pentru a intelege cum functioneaza sa ne
uitam la urmatoarea regula care logheaza cu parametri de limita default:

# iptables -A FORWARD -m limit -j LOG

Prima data cand se ajunge la aceasta regula, pachetul va fi scris in
log-uri, de fapt, deorece numarul limita este 5, primele 5 pachete vor
ajunge in log-uri. Dupa aceasta vor trece 20 de minute pana cand alt
pachet sa ajunga in log-uri datorita acestei reguli, fara sa conteze
numarul de pachete care ajung la regula. Dupa 20 de minute
limit-burst-ul, numarul de pachete care vor putea fi primite va fi unu,
dupa inca 20 de minute va mai creste cu o unitate, daca nici un pachet
nu s-a potrivit cu regula. Deasemenea, la fiecare 20 de minute care
trec fara ca pachete sa se potriveasca regulii, numarul limita va
creste cu o unitate; daca nici un pachet nu se potriveste cu regula dupa 100 de minute, numarul limita va fi din nou atins, inapoi de unde am
plecat.

Nota: nu poti crea o regula cu un timp de reincarcare mai mare de 59
de ore, asa ca daca pui o limita de 1/zi, atunci numarul maxim de
potriviri (burst-rate) trebuie sa fie mai mic decat 3.

Poti de asemenea sa folosesti acest modul pentru a te feri de
diferitele atacuri denial of service (DoS) cu o rata mai mare pentru a
creste sensibilitatea.

Protectie pentru syn-flood:

# iptables -A FORWARD -p tcp –syn -m limit 1/s -j ACCEPT

Pentru scannere de porturi clandestine:

# iptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST RST
-m limit –limit 1/s -j ACCEPT

Pingul mortii:

# iptables -A FORWARD -p icmp –icmp-type echo-request -m
-m limit –limit 1/s -j ACCEPT

Acest modul se comporta ca o “usa histeresis”, ca in graficul urmator:

Sa consideram ca avem o potrivire de un pachet pe secunda cu o
limita maxima de 5 pachete, dar pachetele vin cu o rata de patru pe
secunda timp de 3 secunde, apoi incep din nou sa vina peste 3 secunde.

<–Flood 1–> <—Flood 2—>

Se poate vedea ca primele 5 pachete sunt permise sa depaseasca limita
de un pachet pe secunda, apoi limit intervine. Daca este o pauza de o
secunda inca un pachet in plus va fi permis sa treaca. Intodeauna
insa, nu se va permite depasirea de un pachet/secunda dupa ca
numarul limita (burst-limit) este atins.

owner

acest modul incearca sa se potriveasca trasaturilor diferite ale
creatorului pachetului, pentru pachetele generate local. Este valid
numai in chain-ul OUTPUT, si chiar si atunci unele pachete (cum ar
fi raspunsurile de tip ICMP) pot sa nu aiba creator, si de aceea sa
nu se potriveasca.

–uid-owner userid
se potriveste daca pachetul a fost creat de catre un proces cu
acelasi id de user.

–gid-owner groupid
se potriveste daca pachetul a fost creat de catre un proces cu
acelasi id de group.

–pid-owner processid
se potriveste daca pachetul a fost creat de catre un proces cu
acelasi id de proces.

–sid-owner sessionid
se potriveste daca pachetul a fost creat de catre un proces in grupul
de sesiune dat.

unclean

Acest modul experimental trebuie sa fie in mod explicit specificat cu
optiunea “-m unclean” sau “–match unclean”. Realizeaza niste teste
variate de sanatate asupra pachetelor. Acest modul nu a fost testat,
si nu ar trebui sa fie folosit ca o unealta in securitate (probabil
ca inrautateste lucrurile din cauza ca el insusi s-ar putea sa aiba
buguri). Nu este disponibila nici o optiune.

7.3.6.5 Potrivirea dupa stare

Cele mai folositoare optiuni este furnizata de modulul “state”, care
interpreteaza analizele detectorului de conexiuni ale modulului
“ip_conntrack”. Aceasta este foarte recomandata.

Specificarea modulului “-m state” permite folosirea unei optiuni
aditionale de stare “–state”. Aceste stari sunt:

NEW
un pachet care creeaza o noua conexiune.

ESTABLISHED
un pachet care apartine unei conexiuni deja stabilite (un pachet
replica (replay), sau un pachet care pleaca al unei conexiuni care a primit
replayuri).

RELATED
Un pachet care este inrudit, dar care nu este parte a unei conexiuni existente,
cum ar fi o eroare ICMP, sau (cu modulul FTP introdus), un pachet care
stabileste o conexiune FTP.

INVALID
Un pachet care nu a putut fi identificat pentru niste motive: aceasta include
ramanerea fara memorie sau erori ICMP care nu apartin nici unei conexiuni
cunoscute. In mod normal aceste pachete ar trebui ignorate.

Un exemplu pentru aceasta puternica optiune de potrivire ar fi:

# iptables -A FORWARD -i ppp0 -m state ! NEW -j DROP

7.4 Argumente asupra tintei

Acum stim ce examinare poate fi facuta asupra unui pachet, avem nevoie de o
cale pentru a preciza ce sa facem cu pachetele care se potrivesc testelor
noastre. Aceasta este numita tinta unei reguli.

Exista doua foarte simple tinte incluse: DROP si ACCEPT. Ne-am intalnit deja
cu aceastea. Daca o regula se potriveste cu un pachet si tinta regulii este
una din aceste doua, nici una din regulile urmatoare nu sunt consultate,
soarta pachetului a fost decisa.

Mai sunt doua tipuri de tinte pe langa acestea incluse: tinte extinse si
chain-urile definite de catre utilizator.

7.4.1 Chain-uri definite de utilizator

O caracteristica puternica pe care iptables o mosteneste de la ipchains este
posibilitatea utilizatorului de a crea chain-uri noi, pe langa cele incluse
default (INPUT, OUTPUT si FORWARD). Prin conventie, chain-urile definite de
catre utilizator se scriu cu litera mica pentru a le deosebi (vom descrie
mai jos cum sa cream acest tip de chain-uri in “7.5 Operatii asupra unui
intreg chain”).

Cand un pachet se potriveste cu o regula a carei tinta este un chain definit
de catre utilizator, pachetul incepe sa traverseze chain-ul definit de catre
utilizator. Daca acel chain-ul nu decide soarta pachetul de indata ce
pachetul ajunge la sfarsitul chain-ului respectiv, pachetul continua
traversarea chain-ului initial.

Este timpul pentru niste arta ASCII. Considera doua chain-uri aiurea: INPUT
(chain-ul inclus default) si test (un chain definit de utilizator).

“INPUT” “test”
—————————- —————————-
| Rule1: -p ICMP -j DROP | | Rule1: -s 192.168.1.1 |
|————————–| |————————–|
| Rule2: -p TCP -j test | | Rule2: -d 192.168.1.1 |
|————————–| —————————-
| Rule3: -p UDP -j DROP |
—————————-

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

Chain-urile definite de catre utilizator pot sari la alte chain-uri definite
de catre utilizator (dar nu crea trasee in cerc, pachetele tale vor fi
ignorate daca intra in bucla).

7.4.2 Optiuni extinse la iptables: Noi tinte

Celalat tip de optiune extinsa este o tinta. O tinta extinsa este formata
dintr-un modul de kernel si o extensie optionala la iptables pentru a pune
la dispozitie noi optiuni in linia de comanda. Sunt mai multe optiuni
extinse in distributia default a netfilter-ului:

LOG

Acest modul permite log-area de catre kernel a pachetelor care se
potrivesc. Acest modul pune la dispozitie urmatoarele optiuni
aditionale:

–log-level
urmat de un numar al nivelului sau de un nume. Numele corecte sunt
(nu conteaza daca sunt scrise cu litera mare sau nu) “debug”, “info”,
“notice”, “warning”, “err”, “crit” and “emerg”, corespunzand numerelor
de la 7 la 0. Citeste man-ul de la syslog.conf pentru o explicatie
privind aceste niveluri de logare. Nivelul default este “warning”.

–log-prefix
urmat de un sir de caractere pana la 29 de caractere, acest mesaj
este pus in fata mesajului care este logat, pentru a-i permite
identificarea unica.

Acest modul este bun dupa o limita de potrivire, pentru a nu-ti
flooda fisierele de log.

REJECT

Acest modul are acelasi efect cu “DROP”, cu exceptia faptului ca
celui ce trimite pachetele ii este trimis mesaj de eroare ICMP “port
unreachable”. Bagati la cap ca mesajul de eroare ICMP nu este trimis
daca (citeste RFC 1122):
- pachetul de il filtrezi a fost de la inceput o eroare ICMP
sau alt tip de pachet ICMP necunoscut.
- pachetul ce este filtrat nu este un fragment de inceput.
- am trimis recent prea multe mesaje de eroare ICMP catre acea
destinatie ( cat /proc/sys/net/ipv4/icmp_ratelimit).
REJECT pune de asemenea la dispozitie o noua optiune
“–reject-with” care modifica pachetul folosit la replay: man
iptables.

7.4.3 Tinte speciale construite default

Sunt doua tinte speciale contruite default: RETURN si QUEUE.

RETURN are acelasi efect cu trecerea direct la sfarsitul chain-ului: pentru
o regula in chain-ul inclus default politica acelui chain-ului este executata.
Pentru o regula intr-un chain definit de catre utilizator, traversarea continua in
chain-ul anterior, exact dupa regula care a determinat trecerea la acest
chain.

QUEUE este o tinta speciala, care pune in rand pachetul pentru procesare de
catre programe utilizator. Pentru ca aceasta sa fie folositor doua urmatoare
componente sunt cerute:

- un “gestionar al cozii”, care se ocupa de mecanismele propriu-zise de
trecere a pachetelor intre kernel si modul utilizator; si

- un program in mod utilizator pentru a primi, posibil a manipula, si a
da verdicte in ceea ce priveste pachetele.

Gestionarul standard al cozii pentru iptables IPv4 este modulul ip_queue, care
este distribuit cu kernelul si considerat experimental.

Ceea ce urmeaza este un scurt exemplu despre cum sa folosesti iptables pentru
a pune in coada pachetele pentru procesare in mod utilizator:

# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE

Cu aceasta regula, pachetele ICMP generate local (care sunt create
, sa zicem, cu ping) sunt pasate modulului ip_queue, care apoi incearca sa
livreze pachetele unei aplicatii in mod utilizator. Daca nici o
aplicatie nu asteapta acele pachete, acestea sunt ignorate.

Pentru a scrie o aplicatie in mod utilizator, poti folosi libipq API. Acesta
este distribuit impreuna cu iptables. Cod exemplu poate fi gasit in programele
de testare (redirect.c) in CVS.

Starea lui ip_queue poate fi verificata prin:

/proc/net/ip_queue

Marimea maxima a unei cozi (i.e. numarul de pachete livrata modului utilizator
fara primirea inapoi a unei comfirmari) poate fi controlat prin:

/proc/sys/net/ipv4/ip_queue_maxlen

Marimea default pentru marimea maxima a cozii este 1024. Odata ce aceasta
limita este atinsa, noile pachete vor fi ignorate pana cand marimea cozii
scade sub nivelul limita. Protocoale bine gandite ca TCP interpreteaza
pachetele ignorate ca aglomerare, si din fericire va inceta livrarea de
pachete cand coada este plina. Cu toate acestea, va lua ceva experimente
pentru a determina valoare ideala pentru marimea cozii pentru o situatie data
daca valoarea default este prea mica.

7.5 Operatii asupra unui intreg chain

O foarte folositoare caracteristica a iptables-ului este posibilitatea de a
grupa mai multe reguli intr-un chain. Poti numi chain-urile cum doresti, dar
recomand folosirea literelor mici pentru a evita confuzia cu chain-urile
incluse default si tinte. Numele de chain-uri pot fi pana la 31 de litere in
lungime.

7.5.1 Creearea unui nou chain

Sa cream un nou chain. Pentru ca sunt un tip cu atata imaginatie o sa o
numesc test. Pentru aceasta folosim optiunea “-N” sau “–new-chain”:

# iptables -N test
#

Este atat de simplu. Acum poti introduce reguli in el cum am aratat mai sus.

7.5.2 Stergerea unui chain

Si sergerea unui chain este deasemenea simpla, prin folosirea optiunilor “-X”
sau “–delete-chain”. De ce “-X”? Pai toate literele bune au fost luate.

# iptables -X test
#

Sunt cateva restricitii la stergerea de chain-uri: acestea trebuie sa fie
goale (vezi “Stergerea tuturor regulilor unui chain” dedesubt) si nu trebuie
sa fie tinta nici unei reguli. Nu poti sterge nici unul dintre chain-rile
incluse default.

Daca nu specific numele chain-ului, atunci toate chain-urile definite de catre
utilizator vor fi sterse daca este posibil.

7.5.3 Stergerea tuturor regulilor unui chain

Exista un mod simplu de de sterge toate regulile dintr-un chain, folosind
optiunile “-F” (sau “–flush”).

# iptables -F FORWARD
#

Daca nu este specificat chain-ul atunci toate chain-urile vor fi sterse de
reguli.

7.5.4 Listarea unui chain

Poti lista toate regulile dintr-un chain prin folosirea optiunii “-L” (sau
“–list”).

“refcnt-ul”(reference count) listat pentru fiecare chain definit de catre
utilizator este numarul de reguli care au ca tinta acest chain. Acesta
trebuie sa fie zero (si chain-ul sa fie gol) inainte ca acest chain sa poata
fi sters.

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

Exista trei optiuni care pot fi adaugate la “-L”. Optiunea “-n” (numeric)
este foarte folositoare deoarece previne iptables in a incerca sa rezolve
IP-urile in nume, care (daca folosesti DNS ca majoritatea oamenilor) va cauza
mari intarzieri daca DNS-ul tau nu este setat corect, sau ai filtrat cererile
catre DNS. Determina deasemenea ca porturile TCP si UDP sa fie afisate ca
numere in loc de nume.

Optiunea “-v” arata toate detaliile regulilor, cum ar fi counter-ele pentru de
pachete si bytes, comparatiile TOS, interfata. Altfel aceste detalii sunt
omise.

Observa faptul urmator: counter-ele pentru pachete si bytes sunt afisate
folosind sufixele “K”, “M” sau “G” pentru 1000, 1,000,000 si respectiv
1,000,000,000. Folosirea lui optiunii “-x” (expandare a numerelor) afiseaza
numerele in formatul maxim, fara sa conteze cat sunt de mari.

7.5.5 Resetarea counter-elor

Este folositoare posibilitatea de a putea sa resetezi counter-ele. Aceasta
poate fi facuta cu optiune “-Z” (sau “–zero”).

Considera urmatoarele:

# iptables -L FORWARD
# iptables -Z FORWARD
#

In exemplul de mai sus, unele pachete au putut sa vina intre cele doua
comenzi. Pentru acest motiv, poti folosi cele doua optiuni “-L” si “-Z”
impreuna, pentru a reseta counter-ele in timp ce le afisezi.

7.5.6 Setarea policy-ului

Am explicat ce se intampla cand un pachet ajunge la capatul unui chain inclus
default si am discutat mai devreme cum parcurge un pachet chain-urile. In
acest caz, policy-ul chain-ului determina soarta pachetului. Doar chain-urile
incluse default (INPUT, OUTPUT si FORWARD) au policy-uri, deoarece daca un
pachet ajunge la capatul unui chain definit de catre utilizator, traversarea
continua in chain-ul anterior.

Politica poate fi fie ACCEPT, fie DROP, de exemplu:

# iptables -P FORWARD drop
#

8. Folosirea ipchains si ipfwadm

Sunt module in distributia netfilter pe nume ipchains.o si ipfwadm.o.
Insereaza unul dintre acestea in kernelul tau ( Observatie: aceste module
sunt incompatibile cu ip_tables.o). Apoi poti folosi ipchains sau ipfwadm ca
in vremurile de alta data.

Aceasta va fi suportata pentru inca un timp. Cred ca o formula rezonabila
este 2 * [nota inlocuirii - prima versiune stabila], dupa data cand o versiune
stabila a inlocuirii este disponibila.
Asta inseamna ca suportul va fi probabil abandonat in Linux 2.6 sau 2.8.

9. Folosirea impreuna a NAT-ului si a filtrarii de pachete

Este normal sa vrei sa faci NAT (vezi NAT HOWTO) si filtrare de pachete.
Veste buna este ca se pot folosi impreuna extrem de bine.

Faci filtrarea de pachete ingorand total orice NAT ai deja. Sursa si
destinatia vazute de catre filtrul de pachete vor fi sursele si destinatiile
reale. De exemplu daca faci DNAT pentru a trimite orice conexiune pentru
1.2.3.4 portul 80 spre 10.1.1.1 portul 8080, filtrul de pachete va vedea
pachetele ducandu-se catre 10.1.1.1 portul 8080 (adresa reala), nu 1.2.3.4
port 80. In mod similar poti ignora masquerading: pachetele vor parea ca vin
de la adresa lor IP interna reala (sa zicem 10.1.1.1), si replay-urile vor
parea ca se duc inapoi acolo.

Poti folosi optiunea extinsa de potrivire “match” fara sa pui filtrul de
pachete sa faca munca in plus, deoarece NAT cere detectarea de conexiuni
oricum. Pentru a dezvolta exemplul simplu de masquerading din NAT HOWTO pentru
a nu permite noi conexiuni pe interfata ppp0, vei face urmatoarele:

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

# refuzarea de pachete NOI sau INVALIDE forwardate sau care vin prin ppp0
iptables -A INPUT -i ppp0 -m state –state NEW,INVALID -j DROP
iptables -A FORWARD -i ppp0 -m state –state NEW,INVALID -j DROP

# se da drumu la IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

10. Diferente intre iptables si ipchains

o In primul rand, numele chain-urilor predefinite si-au schimbat scrierea din
litere mici in litere mari, deoarece chain-urile INPUT si OUTPUT primesc acum
doar pachete cu destinatie locala si pachete generate local. Ele obisnuiau
sa vada toate pachetele care intrau si respectiv care ieseau.

o Optiunea “-i” acum inseamna interfata de intrare si are sens numai in
chain-urile INPUT si FORWARD. Regulile in chain-urile OUTPUT si FORWARD care
foloseau inainte “-i” vor trebuie sa fie schimbate cu “-o”.

o Porturile TCP si UDP trebuie sa fie precizate folosind optiunile
–source-port sau –sport (sau –destination-port/–dport), si trebuie
puse dupa optiunile “-p tcp” sau “-p udp”, deorece acestea incarca optiunile
disponibile extensiilor TCP si respectiv UDP.

o Argumentul TCP -y a devenit acum –syn si trebuie pus dupa “-p tcp”.

o In cele din urma tinta DENY a deveni DROP.

o Resetarea counter-elor pentru un singur chain in timp concomitent cu
listarea acestuia este acum posibila.

o Resetara counter-elor pentru chain-urile predefinite resetezeaza desemenea
counter-ele policy-ului chain-urilor respective.

o Listarea counter-elor iti arata counter-ele instant.

o REJECT si LOG sunt acum tinte extinse, insemnand ca sunt module de kernel
separate.

o Numele pentru chain-uri pot fi pana la 31 de caractere in lungime.

o MASQ este acum MASQUERADE si foloseste o sintaza diferita. REDIRECT, desi
si-a pastrat vechiul nume, a suferit deasemenea o schimbare de sintaxa.
Citeste NAT-HOWTO pentru mai multe informatii despre cum sa le configurezi.

o Optiunea “-o” nu mai este folosita pentru a conduce pachetele in mod
utilizator (vezi -i de mai sus). Pachetele sunt trimise acum in mod utilizator
folosind tinta QUEUE.

o Probabil o gramada de alte lucruri pe care le-am uitat.

11. Sfaturi asupra designului filtrului de pachete

In domeniul securitatii cel mai bun lucru este sa blochezi totul, apoi sa
deschizi gauri acolo unde este necesar. Aceasta este deobicei spus “ceea ce nu
este in mod explicit permis este interzis”. Recomand aceasta daca securitatea
este grija ta cea mai mare.

Nu rula nici un serviciu de care nu ai nevoie, chiar daca ai blocat accesul la
el.

Recomand securitatea in adancime: combina tcp-wrappers (pentru conexiuni catre
insusi filtrul de pachete), proxy-uri (pentru conexiuni ce trec peste filtrul
de pachete), verificarea routei si filtrare de pachete. Verificarea routei
este cand un pachet care vine de la o interfata de la care nu poate veni este
ignorate: de exemplu, daca reteaua ta interna are adresele 10.1.1.0/24, si
un pachet care are ca sursa o adresa apartinand acelei clase vine pe
interfata externa, acesta va fi ignorat. Aceasta verificare a routei poate
fi activate pentru o interfata (ppp0) astfel:

# echo 1 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
#

Sau pentru toate interfetele existente si viitoare astfel:

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

Debian realizeaza acest lucru “by default” cand este posibil. Daca ai routare
asimetrica (te astepti sa primesti pachete din directii ciudate), vei
dori sa dezactivezi aceasta filtrare pe interfetele respective.

Logarea pachetelor este folositoare cand configurezi un firewall si ceva nu
merge, insa pe un sistem in productie, intodeauna foloseste aceasta in
combinatie cu limitare, pentru a preveni floodarea fisierelor cu log-uri.

Recomand pentru sistemele sigure depistarea conexiunilor (connection
tracking): determina o incarcare a sistemului, deoarece toate conexiunile sunt
depistate, dar este foarte folositoare pentru a controla accesul la retelele
tale. S-ar putea sa trebuiasca sa incarci modulul “ip_conntrack.o” daca
kernelul tau nu incarca in mod automat modulele si nu este compilat in
kernel. Daca vrei sa depistezi cu precizie protocoale complexe, va trebui sa
incarci modulul necesar pentru aceasta (ex. “ip_conntrack_ftp.o”).

# iptables -N no-conns-from-ppp0
# iptables -A no-conns-from-ppp0 -m state –state ESTABLISHED,RELATED -j ACCEPT
# iptables -A no-conns-from-ppp0 -m state –state NEW -i ! ppp0 -j ACCEPT
# iptables -A no-conns-from-ppp0 -i ppp0 -m limit -j LOG –log-prefix “Bad packet from ppp0:”
# iptables -A no-conns-from-ppp0 -i ! ppp0 -m limit -j LOG –log-prefix “Bad packet not from ppp0:”
# iptables -A no-conns-from-ppp0 -j DROP
# iptables -A INPUT -j no-conns-from-ppp0
# iptables -A FORWARD -j no-conns-from-ppp0

Construirea unui bun firewall este peste scopul acestui HOWTO, dar sfatul meu
este ca “intodeauna sa fii minimalist”. Citeste Security HOWTO pentru mai multe
informatii privind testarea si examinarea sistemului.

Ce este internetul. Conceptele de retea linux

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

traducere ver. 0.4 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 Networking-concepts HOWTO
HOWTO privind conceptele de retea linux
Rusty Russell
$Revision: 1.3 $ $Date: 2002/06/05 13:21:56 $

Acest document descrie ce este acea o retea (cum ar fi internetul), si foarte
primar cum functioneaza acesta.

______________________________________________________________________

Cuprins

1. Introducere
2. Ce este aceea o “retea de calculatoare”?
3. Ce este “Internetul”?
3.1. Cum functioneaza Internetul?
4. Aceast lucru numit IP
4.1. Grupuri de adrese IP: Netmask-uri
5. Nume de computere si Adrese IP
6. Servici diferite: Email, Web, FTP, DNS
7. Interfete dialup: PPP
8. Cum arata pachetele
9. Sumar
10. Multumiri
11. Index
______________________________________________________________________

1. Introducere

Bine ai venit!
Am scris in trecut un numar de howto-uri in ceea ce privesc retelele, si mi-a
venit in minte ca sunt in fiecare o multime de termeni jargonici. Am avut de
ales intre trei variante: celelalte doua ignorau problema si explicau
termenii peste tot. Nici una dintre ele nu era atractiva.

Scopul software-ului liber este faptul ca ar trebui sa ai libertatea sa
explorezi si sa te joci cu software-ul sistemului pe care il folosesti. Cred
ca dandu-le posibilitatea oamenilor sa experimenteze aceasta libertate este un
scop nobil; nu numai fac pe oameni sa se simt puternici printr-o ocupatie (cum
ar fi reconstruirea unui motor de masina) dar prin natura internetului si
software-ului liber ti se pune la dispozitie posibilitatea sa partajezi
experienta ta cu milioane de oameni.

Dar trebuie sa incepi de undeva, asa ca iata-ne.

2. Ce este aceea o “retea de calculatoare”?

O retea de calculatoare sunt mai multe materiale folosite pentru ca nodurile sa
schimbe informatie intre ele (prin “noduri” inteleg computere, imprimante,
masini de gatit si orice alceva doresti). Nu conteaza foarte mult cum sunt
interconectate: pot sa foloseasca fibra optica sau porumbei calatori.
E clar, unele alegeri sunt mai bune decat altele, mai ales daca ai prin casa
pisici.

In mod normal conectarea a doua calculatoare impreuna nu se poate numi
retea, este nevoie de trei sau mai multe pentru a deveni retea. Acest lucru
seamana cu cuvantul “grup”: doi oameni inseamna doar doua persoane, pe cand
trei persoane formeaza un grup. Deasemenea, retelele sunt adesea prinse
impreuna, pentru a forma retele mai mari, fiecare retea mai mica (deobicei
numita o “sub-retea”) poate fi parte dintr-o retea mai mare.

De fapt conexiunea intre doua computere este adesea denumita “legatura de
retea”. Daca este ceva cablu in spatele computer-ului tau catre alte
computere atunci aceea este legatura ta de retea.

Sunt patru lucruri despre care suntem interesati cand vorbim despre o retea de
calculatoare:

Marimea

Daca pur si simplu conectezi intre ele cele patru calculatoare de
acasa, ai realizat ceea ce se numeste LAN (Local Area Network – retea
locala). Daca totul este la distanta de mers pe jos, este denumit
deobicei LAN, oricate masini ar fi conectate, si din orice
infrastructura ar fi contruita reteaua.

La celalalt pol se situeaza WAN-ul (Wide Area Network – retea
intinsa). Daca ai un computer la Bucuresti, Romania, altul in New
York, SUA, si unul in Lhasa, Tibet, si reusesti sa le conectezi,
aceasta este atunci un WAN.

Topologia: Forma

Deseneaza harta unei retele: linile sunt “legaturile din retea”,
si fiecare nod este un punct. Poate ca fiecare linie duce intr-un
punct central ca o stea, insemnand ca fiecare vorbeste printr-un
singur punct ( o “topologie stea”):

o o o
\_ | _/
\|/
o—–o—–o
_/|\_
/ | \
o o o

Sau poate ca fiecare comunica in linie, astfel:

o——o——o——-o——–o
| |
| |
| o
| |
o |
o

Sau poate ca ai trei subretele conectate printr-un singur nod:

o
o | o–o–o
| | |
o–o–o–o–o o
\ |
o——o
/ |
o–o–o–o–o o
| | |
o | o–o
o

Vei vedea multe topologii ca acestea in realitate si multe altele mult
mai complicate.

Fizic: Din ce este facuta reteaua.

Al treilea lucru de care trebuie sa fim interesati este din ce este
constuita reteaua noastra. Cea mai ieftina este “sneakernet-u”, erau
oamenii care transportau diskete de la un computer la altul.
Sneakernet-ul este aproape intodeauna un “LAN”. Disketele costa mai
putin de 1$ si o pereche de skeakers (incaltaminte care nu face
zgomot) in jur de 20$.

Cel mai obisnuit sistem folosit pentru a conecta reteaua de acasa
catre alte retele mai mari este numit “modem”
(MODulator/DEModulator), care transforma o legatura telefonica intr-o
legatura de retea. Transforma ceea ce transmite calculatorul in
sunete, si asculta sunetele venite de la celalalt capat pe care le
transforma iar in informatie pentru calculator. Dupa cum iti
imaginezi acest lucru nu este din cale afara de eficient, deoarece
liniile telefonice nu au fost facute pentru genul acesta de lucruri, dar
este un sistem raspandit deoarece liniile telefonice sunt atat de
obisnuite si ieftine: modemurile costa sub 50$ si linia telefonica
200$ pe an.

Cel mai obisnuit sistem sa conectezi computerele intr-un LAN este sa
folosesti Ethernet. Ethernetul poate fi de trei tipuri (in ordinea
in care au fost realizate): Thinwire/Coax/10base2, UTP/10baseT si
UTP/100baseT. Gigabit ethernet (1000baseT incepe sa sune ciudat)
este in curs de a fi realizat. 10baseT este deobicei un fir coaxial
negru care are din loc in loc T-uri pentru a putea fi conectate la
computere, toti sunt conectati intr-o linie, linie care are la
capete terminatori speciali. UTP este deobicei un cablu de culoare
albastru deschis, care au doua capete prevazute cu terminatori din
plastic similari celor de la telefon, care sunt conectate in
dispozitivele fizice (placa ethernet, hub, etc.). Cablul costa cativa
dolari metrul, si placile de retea 10baseT/10base2 (multe au
connectori pentru ambele tipuri) sunt greu de gasit noi de firma.
100baseT sunt de 10 ori mai rapide decat 10baseT, sunt compatibile si
cu acestea, si costa cam 30$.

Tehnologia de varf este insa fibra optica; un fir de sticla subtire
in camasa protectoare care poate fi folosita pentru a lega in retea
continente. In general costa mii de dolari.

In mod normal numim fiecare conexiune la un nod “interfata de retea”
sau pe scurt “interfata”. Linux le numeste astfel “eth0″ pentru
prima interfata ethernet, si “fddi0″ pentru prima interfata de
fibra. Comanda “/sbin/ifconfig” ni le listeaza.

Protocol: Cum comunica.
Ultimul lucru care te intereseaza este limbajul pe care il folosesc
doua noduri interconectate. Cand doua modemuri comunica unul cu altul
printr-o linie telefonica, trebuie sa se puna de acord ce vor insemna
fiecare sunet, astfel pur si simplu nu vor comunica. Aceasta
conventie este denumita “protocol”. Pe masura ce oamenii au descoperit
noi posibilitati de codare astfel incat computerele sa spuna mai
multe in sunete mai scurte, noi protocoale s-au inventat; sunt cel
putin o duzina de protocoale diferite, si fiecare modem va incerca
cateva pana cand va gasi unul care sa fie inteles si de celalalt
modem.

Un alt exemplu este reteaua 100baseT mentionata mai sus. Aceasta
foloseste aceeasi legatura fizica “UTP” ca si 10baseT, dar
comunica de 10 ori mai rapid.

Aceste doua protocoale sunt denumite protocoale de nivel de legatura
(link level); care determina cum este transportata informatia intre
doua puncte pe conexiuni de retea individuale. Cuvantul “protocol” se
refera si la alte conventii dupa cum vom vedea mai jos.

3. Ce este “Internetul”?

Internetul este o retea de tip WAN, care impanzeste intre globul: este cea
mai mare retea de calculatorea existenta. “Internetworking” inseamna
conectarea mai multor retele pentru a crea una mai mare, prin urmare
internetul este connectarea a o mare ingramadire de subretele.

Asa ca acum uitandu-ne la lista de mai sus, ne punem intrebarea: care este
marimea Internetului, din ce este formata fizic si care sunt protocoalele
folosite?

Marimea am spus-o deja. Este globala.

Structura fizica este variata, fiecare subretea este conectata intr-un mod
diferit. Incercarea de a creea o harta folositoare este sortita deci esecului.

Protocoalele folosite de fiecare legatura este deasemnea diferita: toate
protocoalele de mai sus pentru nivel de legatura sunt folosite si multe
altele.

3.1. Cum functioneaza Internetul?

Atunci aceasta intrebare se pune: cum functioneaza? Cum poate fiecare nod sa
vorbeasca altor noduri daca folosesc protocoale de nivel legatura diferite?

Raspunsul este simplu: avem nevoie de un alt protocol care sa controleze cum
circula informatia prin retea. Protocolul pentru nivel de lagatura descrie
cum sa circule informatia intre doua noduri care sunt legate direct:
protocolul pentru nivel de retea face posibila transportul informatie intre
un nod si un altul peste oricat de mult legaturi de retea.

Pentru internet, protocolul la nivel de retea este INTERNET PROTOCOL
(versiunea 4) sau “IP”. Nu este singurul protocol existent (Apple”s
AppleTalk, Novell”s IPX, Digital”s DECNet and Microsoft”s NetBEUI fiind
altele), dar este cel mai adoptat. A aparut o noua versiune de protocol “IP”
numit IPv6, dar inca nu este atat de utilizat.

Asa ca pentru a transmite un mesaj dintr-un punct al globului in altul,
computerul tau foloseste protocolul IP, trimite informatia la modem, care
foloseste protocol pentru nivel de legatura pentru a trimite informatia
modemului din celalalt capat, modem care se afla probabil intr-un rack de
modemuri, care trimite informatia catre un alt nod, nod care la randul sau
trimite catre altul, si tot asa. Un nod care face lagatura intre doua sau
mai multe retele este denumit “ruter”: acesta va avea cate o interfata
pentru fiecare retea.

Numim aceast sir de protocoale o “stiva de protocoale”, de obicei desenata
asa:

[ Aplicatia: Primeste poze ] [ Nivelul aplicatie: transmite poze ]
| ^
v |
[ TCP: are grija de trasport ] [ TCP: are grija de trasport ]
| ^
v |
[ IP: are grija de routare ] [ IP: are grija de routare ]
| ^
v |
[ Link: doar pentru conexiune directa ] [ Link: doar pentru conexiune directa ]
| |
+——————————————+

Deci, in diagrama, vedem cum netscape (aplicatia din stanga sus) acceseaza
niste poze de pe un server web (aplicatia din dreapta sus). Pentru a face
acest lucru aplicatia noastra foloseste nivelul TCP, protocol pentru controlul
transportului: peste 90% din din traficul internet foloseste TCP, deoarece
este folosit mai ales pentru serviciile web si mail.

Deci, Netscape-ul trimite o cerere pentru o conexiune TCP catre serverul
remote: aceasta cerere este preluata la nivel de protocol de transport TCP,
care trimite mai departe cererea nivelului protocolului de retea IP, care la
randul lui transmite informatia mai departe catre nivelul protocolului de
legatura.

La celalat capat nivelul protocolului de legatura inainteaza informatia catre
nivelul protocolului IP, care vede ca informatia este destinata
computer-ului respectiv (daca nu va inainta informatia nivelului de legatura
pentru ca informatia sa ajunga la urmatorul nod), care inainteaza informatia
nivelului protocolului de transport TCP, care o inainteaza server-ului,
respectiv aplicatiei.

Deci avem urmatoarele trei puncte:

1. Aplicatia (Netscape, sau serveru din capatul celalalt) decide cu cine anume
doreste sa vorbeasca si ce anume doreste sa trimita

2. Nivelul de transport trimite pachete speciale pentru a incepe conversatia
cu celalalt capat si apoi impacheteaza informatia intr-un “pachet” TCP: un
pachet este doar un termen pentru o bucata de date care trece printr-o
retea. Nivelul de transport TCP paseaza acest pachet catre nivelul de retea
IP: apoi transmite in continuare pana cand celalat capat la nivel de
transport TCP transmite receptionarea pachetului. Acest mecanism este numita
“retransmitere”, si are o multime de reguli complexe care controleaza cand sa
transmita, cat sa astepte, etc. Ii da deasemenea fiecarui pachet o multime
de numere, pentru ca la celalalt capat sa fie sortate in ordinea corecta.

3. La nivel de retea IP se ia in considerare destinatia pachetului si
se decide urmatorul nod catre care sa se transmita pachetul. Aceasta operatie
este numita in mod simplu “rutare”(routing), si difera de la foarte simplu
(daca nu ai decat un singur modem si nici o alta interfata de retea,
pachetele ar trebui sa iasa numai prin acea interfata) pana la extrem de
complex (daca ai 15 retele complexe conectata direct prin tine).

4. Aceast lucru numit IP

Asadar rolul nivelului de legatura IP este sa realizeze cum sa “ruteze”
pachetele catre destinatia finala. Pentru ca acest lucru sa fie posibil,
fiecare interfata din retea trebuie sa aiba o “adresa IP”. Aceast adresa
este formata din patru numere separate prin puncte, cum ar fi
“167.216.245.249″. Fiecare numar trebuie sa fie cuprins intre 0 si 255.

Interfetele in aceeasi retea au tendinta sa aiba adrese Ip vecine. De
exemplu “1.1.1.19″ sta chiar langa sistemul cu adresa IP “1.1.1.20″. Deasemenea
nu uita ca un ruter este un nod cu interfete pentru mai mult de o retea,
asa ca ruter-ul va avea cate o adresa Ip pentru fiecare interfata.

Asa ca nivelul de retea IP al kernelului tine un tabel cu “rute” diferite,
punand la dispozitie calea pentru a ajunge la grupuri variate de adrese IP.
Cea mai simpla dintre rute este numita “ruta default”: daca nici o alta ruta
nu se potriveste aceasta este calea pe care o iau pachetele. Poti vedea o
lista a acestor rute cu ajutorul comenzii “/sbin/route”.

Rutele fie indica o legatura, fie un nod particular care este conectat la o
alta retea. De exemplu, cand suni la ISP, ruta default va fi catre legatura
cu modemul, deorece acolo este punctul de acces catre intreaga lume.

Modemul
Modemul lui ISP-ului ~~~~~~~~~~~~
Rusty { }
o——————o { Internetul }
{ }
~~~~~~~~~~~~

Dar daca ai un sistem care este in permanenta conectat la lumea din afara,
este putin mai complicat. In diagrama de mai jos, sistemul meu poate sa
comunica in mod direct cu computerele lui Paul si Tridge, si cu firewall-ul,
dar este necesar ca sistemul meu sa stie ca pachetele care trebuiesc livrate
restului lumii trebuie sa se indrepte catre firewall care le va pasa mai
incolo. Aceasta inseamna ca vei avea doua rute: una care sa zica “daca
destinatia este in reteaua mea trimite informatia direct acolo” si apoi o
ruta default care sa spuna “in caz contrar, trimite-o catre firewall”.

o Masina de lucru
| a lui Tridge ~~~~~~~~~~~~
Masina de lucru | { }
a lui Rusty o——–+—————–o–{ Internetul }
| Firewall { }
| ~~~~~~~~~~~~
o Masina de lucru
a lui Paul

4.1. Grupuri de adrese IP: Netmask-uri

Mai este un ultim detaliu: exista o notatie standard pentru grupuri de adrese
IP, uneori numita “adresa de retea”. La fel cum un numar de telefon poate fi
impartit in prefix si restul, la fel putem divide o adresa IP intr-un prefix
de retea si restul.

Oamenii obisnuiau sa vorbeasca despre “reteaua 1.2.3″, insemnand toate cele
256 de adrese de la 1.2.3.0 la 1.2.3.255. si daca asta nu era o retea destul
de mare ar fi putut sa vorbeasca despre “reteaua 1.2″ care inseamna toate
adresele de la 1.2.0.0 la 1.2.255.255.

In mod normal nu scriem “1.2.0.0-1.2.255.255″. In loc scriem prescurtat
“1.2.0.0/16″. Notatia ciudata “/16″ (numita netmask) cere o mica explicatie.

Fiecare numar despartit prin puncte intr-o adresa IP este defapt un numar
binar format din 8 cifre (00000000 la 11111111): le scriem in format zecimal
pentru a putea fi mai usor de citit. “/16″ inseamna ca primele 16 cifre
binare reprezinta adresa retelei, cu alte cuvinte partea “1.2″ este reteaua.
(tine minte fiecare numar reprezinta 8 cifre binare). Aceasta inseamna ca
orice adresa care incepe cu “1.2″ face parte din aceasta retea: “1.2.3.4″ si
“1.2.5.22″ fac parte din aceasta retea, dar “1.3.4.2″ nu.

Pentru a face viata mai usoara, in mod normal folosim retele care au
netmask “/8″, “/16″ si “/24″. De exemplu, “10.0.0.0/8″ este o retea imensa
care contine orice adresa de la 10.0.0.0 la 10.255.255.255 (peste 16 milioane
de adrese!). “10.0.0.0/16″ este mai mica, continand adresele doar de la
10.0.0.0 la 10.0.255.255. “10.0.0.0/24″ este si mai mica detinand adresele
de la 10.0.0.0 la 10.0.0.255.

Pentru a face lucrurile si mai confuze, mai este un mod prin care putem sa
scriem netmask-urile. Putem sa le scriem ca adrese IP:

10.0.0.0/255.0.0.0

In sfarsit, nu valoreaza nimic faptul ca cea mai mare adresa dintr-o retea
este rezervat ca “adresa de broadcast”, care poate fi folosita pentru a
transmite un mesaj catre toate host-urile din retea.

Mai jos este un tabel cu netmask-uri:

Forma Forma Numarul de Comentarii
scurta lunga masini maxim

/8 /255.0.0.0 16,777,215 numita in trecut retea de clasa A
/16 /255.255.0.0 65,535 numita in trecut retea de clasa B
/17 /255.255.128.0 32,767
/18 /255.255.192.0 16,383
/19 /255.255.224.0 8,191
/20 /255.255.240.0 4,095
/21 /255.255.248.0 2,047
/22 /255.255.252.0 1,023
/23 /255.255.254.0 511
/24 /255.255.255.0 255 numita in trecut retea de clasa C
/25 /255.255.255.128 127
/26 /255.255.255.192 63
/27 /255.255.255.224 31
/28 /255.255.255.240 15
/29 /255.255.255.248 7
/30 /255.255.255.252 3

5. Nume de computere si Adrese IP

In concluzie orice interfata de pe fiecare nod are o adresa IP. Foarte repede
s-a constatat ca oamenii retin destul de greu numerele, asa ca s-a hotarat
(la fel ca la numerele de telefon) sa avem un director cu nume. Dar cum
folosim computere oricum, este mai simplu sa punem computerele sa gaseasca
numele in mod automat.

Prin urmare avem DNS, sistemul de nume al domeniilor. Sunt noduri cu adrese IP
bine cunoscute pe care programele le pot interoga trimitand nume pentru a
primi adrese IP. Aproape toate programele pe care le folosesti pot realiza
aceasta interogare, de asta poti pune “www.linuxcare.com” in Netscape in loc
de “167.216.245.249″.

Bineinteles, ai nevoie de adresele de retea a cel putin unuia dintre aceste
“servere de nume”: in mod normal aceste adrese se gasesc in fisierul
“/etc/resolv.conf”.

Cum interogarile si raspunsurile DNS sunt relativ mici (1 pachet de fiecare),
protocolul TCP nu este folosit: acesta pune la dispozitia retransmisie
automata, ordonare a pachetelor si o siguranta a conexiunii, dar cu costul
trimiterii de pachete in plus in retea. De aceea folosim foarte simplul
protocol UDP (protocol pentru datagrame utilizator), care nu ofera extra
facilitatile pe care le ofera TCP si de care nu avem nevoie.

6. Servici diferite: Email, Web, FTP, DNS

Intr-un exemplu anterior, am arata cum Netscape trimite o cerere TCP catre un
server de web care ruleaza pe un alt nod. Dar sa ne imaginam ca acel nod care
este si server de web ruleaza si server de email, un server de ftp si un
server DNS, cum stie nodul pentru ce server este conexiunea TCP?

Aici TCP si UDP au conceptul de “port”. Fiecare pachet precizat in el “portul
destinatie” care spune pentru ce serviciu este destinat pachetul. De exemplu,
portul 25 TCP este pentru server-ul de mail, si portul 80 TCP este server-ul
de web (deasemenea cateodata poti sa intalnesti servere web pe porturi
diferite). O lista a porturile poate fi gasita in “/etc/services”.

Deasemenea, daca doua ferestre Netscape, amandoua acceseaza parti diferite din
acelasi site web, cum face sistemul linux pe care ruleaza Netscape sa sorteze
pachetele care se intorc de la server?

Aici intervine “portul sursa”: fiecarei conexiune noua TCP ii se atribuie un
nou port sursa, asa ca sunt separate, chiar daca se duc spre aceeasi
adresa destinatie IP si acelasi port destinatie. In mod normal primul port
sursa alocat va fi 1024 si creste odata cu trecerea timpului.

7. Interfete dialup: PPP

Cand suni cu modemul tau la un ISP, si se conecteaza la modemul lor, kernelul
nu incepe pur si simplu sa trimita pachete IP prin conexiune. Exista un
protocol numit PPP (point-to-point protocol), care este folosit pentru a
negocia cu celalalt capat inainte de a se permite trimiterea oricaror pachete.
Acesta este folosit de catre ISP pentru identificarea celui care a sunat: pe
sistemul tau linux, un program numit “daemon PPP” se ocupa cu partea ta de
negociere.

Pentru ca in lume sunt atatia utilizatori de dial-up, de obicei acestia nu
au propria lor adresa IP: cele mai multe ISP-uri iti vor aloca una din
adresele lor cand te vei conecta (daemonul PPP va negocia acest lucru). Aceasta
este adesea numita “adresa IP dinamica”, diferita fata de “adresa IP statica”
care este cazul normal cand ai propria ta conexiune permanenta. In mod normal
aceasta adresa este determinata de modem, data urmatoare cand te conectezi,
probabil ca vei nimeri alt modem, si astfel vei avea alta adresa IP.

8. Cum arata pachetele

Pentru cei foarte curiosi iata o descriere a structurii unui pachet. Sunt mai
multe aplicatii care captureaza pachetele care intra sau care ies dintr-un
sistem linux: cel mai comun este “tcpdump” (care intelege mai multe
protocoale decat TCP), dar unul mai fain este “ethereal”. Aceste aplicatii
sunt numite “snifere de pachete”.

Inceputul fiecarui pachet contine informatii cum ar fi destinatia, sursa,
tipul pachetului, si alte detalii administrative. Aceasta parte a unui pachet
este numita “header”. Restul pachetului, ce contine datele propriu-zise, este
in mod uzual numit “corpul pachetului”.

Asa ca orice pachet IP incepe cu un “header IP”: in marime de cel putin 20
bytes. Arata cam asa (aceasta diagrama fu furata cu nerusinare din RFC 791
(nu de catre traducator:))):

Campurile importante sunt Protocol, care indica daca pachetul este de tip TCP
(numarul 6), un pachet UDP (numar 17) sau alceva, adresa IP sursa, si adresa
IP destinatie.

Acum, daca acel camp referitor protocolului spune ca pachetul este TCP, atunci
imediat un header TCP va urma imediat header-ului IP: header-ul TCP este
deasemenea de cel putin 20 bytes marime:

.——————————-+——————————-.
| Source Port | Destination Port |
|——————————-+——————————-|
| Sequence Number |
|—————————————————————|
| Acknowledgment Number |
|——————-+-+-+-+-+-+-+——————————-|
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
|——-+———–+-+-+-+-+-+-+——————————-|
| Checksum | Urgent Pointer |
“—————————————————————”

Cele mai importante campuri sunt aici campurile reprezentand portul sursa si
portul destinatie care determina catre ce serviciu este destinat pachetul
(sau, in cazul pachetelor replica, de la care serviciu provine). Numerele
“sequence” si “acknowledgment” sunt folosite pentru a tine o ordine in
pachete si pentru a spune celuilalt capat ce pachete au fost primite.
Flag-urile ACK, SYN, RST si FIN (scrise pe verticala) sunt biti unici
folositi pentru negocierea deschiderii (SYN) sau inchiderii (RST sau FIN)
conexiunilor.

Dupa acest header urmeaza mesajul real pe care il trimite aplicatia (corpul
pachetului). Un pachet normal are pana la 1500 bytes: aceasta inseamna ca cel
mai mare spatiu pe care il poate ocupa datele este de 1460 bytes (20 bytes
header-ul IP, 20 bytes header-ul TCP): peste 97%.

9. Sumar

In concluzie internetul modern foloseste pachete IP pentru a comunica, si
cele mai multe dintre aceste pachete folosesc TCP pentru controlul conexiunii.
Noduri speciale denumite “rutere” conecteaza micile retele in retele mai
mari, si paseaza pachetele catre destinatia lor finala. Marea majoritatea a
computerelor sunt parte doar dintr-o retea (au doar o singura interfata),
spre deosebire de rutere.

Fiecare interfata are o adresa IP unica, care seamana cu “1.2.3.4″:
interfetele in aceeasi retea vor avea adrese IP inrudite, cu acelasi
inceput, la fel cum telefoanele dintr-o anumita zona au acelasi prefix.
Adresele de retea sunt asemanatoare adreselor IP, urmate insa de semnul “/”
si un numar pentru a se specifica portiunea din acea adresa care reprezinta
prefixul, de exemplu “1.12.0.0/24″ inseamna ca primele 3 grupuri de cifre
reprezinta adresa de retea, fiecare cifra reprezinta 8 biti.

Masinile au asignate nume de catre serviciul de nume pe domenii: programele
interogheaza serverele de nume adrese IP, furnizand acestora nume de genul:
“www.lug.ro”. Aceasta adresa IP este apoi folosita ca adresa IP
destinatie pentru a vorbi cu acel nod.

Rusty este destul de nepriceput pentru a scrie documente, in special pentru
incepatori.

Enjoy!

Rusty.

10. Multumiri

Multumiri lui Alison, pentru ca mi-a spus in cel mai frumos mod posibil ce
tampenii am scris in versiunile de inceput.

11. Index

o “100baseT”

o “10base2″

o “10baseT”

o “Broadcast address” – adresa de broadcast

o “Coax, Coaxial cable”

o “Computer network” – retea de computere

o “Default route” – ruta default

o “Destination port” – port destinatie

o “DNS, Domain Name Service” – serviciu de nume pe domenii DNS

o “Dynamic IP address”- adresa IP dinamica

o “Ethernet”

o “Fiber” – fibra

o “Gigabit Ethernet”

o “Hop”

o “Hub”

o “Internet”

o “IP, Internet Protocol”

o “IP address” – adresa ip

o “IP header” – header IP

o “IPv4, IP version 4″

o “IPv6, IP version 6″

o “LAN, Local Area Network” – retea locala

o “Link-level protocol” – protocol de nivel de legatura

o “Modem”

o “Name server” – server de nume

o “Netmask” – netmask

o “Network address, network mask” – adresa de retea, mask de retea

o “Network interface, interface” – interfata de retea, interfata

o “Network link” – legatura de retea

o “Network protocol, protocol” – protocol de retea, protocol

o “Node” – nod

o “Packet body” – corp al pachetului

o “Packet header” – header al pachetului

o “Packet sniffer” – snifer de pachete

o “Packet” – pachet

o “Port, TCP port, UDP port” – port, port TCP, port UDP

o “PPP, Point-to-Point Protocol”

o “PPP daemon” – daemon PPP

o “Protocol stack” – stiva de protocoale

o “Retransmission” – retransmitere

o “Route” – ruta

o “Router” – ruter

o “Routing” – rutare

o “Sneakernet”

o “Source port” – port sursa

o “Star-topology” – topologie in stea

o “Static IP address” – adresa IP statica

o “Sub-network” – sub-retea

o “TCP, Transmission Control Protocol” TCP, protocol cu controlul
transportului

o “TCP header” – header TCP

o “Terminator” – terminator

o “Topology” – topologie

o “UDP, User Datagram Protocol” – UDP, protocol pentru datagrame
utilizator

o “UTP, Unshielded Twisted Pair”

o “WAN, Wide Area Network” – retea intinsa

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).

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.

# 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

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″.

# 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.

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

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

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

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 “!”.

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 |
—————————-

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