LUCRAREA 3

Urmarirea conexiunilor (Partea 2)

1 Mecanismul de stare a conexiunii (continuare)


1.1 Conexiuni UDP

Conexiunile UDP sunt n sine conexiuni fara stare. Sunt cateva motive pentru care
ele sunt considerate astfel, principalul motiv fiind acela c ele nu includ etapele de
stabilire a conexi-unii sau nchiderea acesteia. Primirea a doua datagrame UDP ntr-o
ordine specific, nu ne spune nimic despre ordinea in care acestea au fost trimise. Cu
toate acestea este posi-bil setarea anumitor stri ale conexiunii n interiorul kernelului.
n continuare vom vedea cum se pot urmari astfel de conexiuni, i cum arat ele n
conntrack.



Figura 3.2

Dup cum se vede, conexiunea este realizat aproape la fel ca i n cazul conexi-
unii TCP. Acesta este ceea ce se poate observa din punctul de vedere al utilizatorului.
Intern ns, informaia conntrack arat puin diferit. S privim nainte de toate la o intrare
n baza de date conntrack dup ce a fost trimis pachetul UDP iniial:

udp 17 20 sr c=192. 168. 1. 2 dst =192. 168. 1. 5 spor t =137 dpor t =1025 \
[ UNREPLI ED] sr c=192. 168. 1. 5 dst =192. 168. 1. 2 spor t =1025 \
dpor t =137 use=1

Dup cum se poate observa, prima i a doua valoare indic faptul c este vorba
despre un pachet UDP. Astfel prima valoare este numele protocolului, i a doua este
numarul protocolului. A treia valoare valoare spune timpul de via al acstei stari. Dupa
aceasta, urmeaz sursa i destinaia pachetului precum i portul sursa respective cel
destinaie. n acest moment, flagul UNREPLIED spune c inca nu a sosit un rspuns la
acest pachet. Urmtoarea stare se atinge atunci cnd soseste un pachet ca raspuns la cel
trimis. Valoare de timeout n acest caz este de 30 de secunde.

udp 17 170 sr c=192. 168. 1. 2 dst =192. 168. 1. 5 spor t =137 \
dpor t =1025 sr c=192. 168. 1. 5 dst =192. 168. 1. 2 spor t =1025 \
dpor t =137 use=1

n acest moment, serverul a vzut rspunsul la pachetul ce a fost trimis, i acum
conexiunea va fi considerat ESTABLISHED (stabilit). Valoarea de timeout n acest
caz este de 160 de secunde. Pentru a de atinge urmatoarea stare, i anume aceea de
ASSURED, trebuie s se mai vehiculeze cateva pachete.

udp 17 175 sr c=192. 168. 1. 5 dst =195. 22. 79. 2 spor t =1025 \
dpor t =53 sr c=195. 22. 79. 2 dst =192. 168. 1. 5 spor t =53 \
dpor t =1025 [ ASSURED] use=1

n acest moment, conexiunea este asigurat. Dac conexiunea nu este utilizat timp de
180 de secunde, aceasta expir.


1.2 Conexiuni ICMP

Pachetele ICMP sunt considerate a fi pachete fara stare, deoarece ele sunt folosite
pentru controlul conexiunilor, i nu pentru a stabili conexiuni. Cu toate acestea exist
patru tipuri de ICMP care genereaz pachete de rspuns, i acestea au dou stari dferite.
Aeste mesaje ICMP pot lua starile NEW i ESTABLISHED. Tipurile de ICMP despre
care discutm sunt Echo request (cerere ecou), Echo reply (raspuns de tip ecou),
Timestamp request (cererea amprentei de timp), Timestamp reply (raspunsul la cererea
amprentei de timp), Information request (cererea de informaie), Information reply
(raspuns la cererea de informaie) si n cele din urm Address mask request (cererea
matii adresei) i Address mask reply (raspuns la cererea matii adresei). Cererea de
amprent i cea de informaie sunt mai vechi i nu se mai utilizeaz, deci acestea pot s
fie direct blocate prin firewall. Mesajele de tip ecou, sunt utilizate pentru verificarea
conexiunii, asa cum este cazul instructiunii ping, iar cererile de masca, sunt foarte
rarutilizate. O astfel de conexiune este reprezentat n figura urmtoare:



Figura 3.3

Dup cum se vede din figura de mai sus, hostul timite un pachet echo request
calculatorului destinaie, pachet care este considerat de ctre firewall ca fiind NEW.
Calculatorul int raspunde printr-un pachet echo reply pe care firewallul l consider ca
fiind in starea ESTABLISHED. Cnd primul pachet echo request este vazut, n
ip_conntrack vom avea urmatoarea intrare:

i cmp 1 25 sr c=192. 168. 1. 6 dst =192. 168. 1. 10 t ype=8 code=0 \
i d=33029 [ UNREPLI ED] sr c=192. 168. 1. 10 dst =192. 168. 1. 6 \
t ype=0 code=0 i d=33029 use=1

Aceast intrare arata puin diferit fa de intrrile standard TCP si UDP. Avem n
aceast intrare protocolul, timeout-ul, sursa i destinaia. Pe lang acestea mai avem alte
trei cmpuri i anume type, code, i id. Campul type specifica tipul ICMP-ului, iar
campul code specific codul ICMP. Acestea se pot vedea n tabelul din anexa 2. Cmpul
id conine ID-ul pachetului ICMP. Fiecare pachet ICMP primete un ID cand acesta este
trimis, iar cnd receptorul primete mesajul ICMP, el seteaz acelai ID n pachetul pe
care l trimite, astfel nct emitorul l va recunoate.
n urmatorul camp recunoatem flagul UNREPLIED, care ca i mai nainte indica faptul
c urmarim o nexiune care nu a sesizat trafic n una din directii. Pachetul de rspuns este
considerat ca fiind n starea ESTABLISHED, dupa cum deja am vzut in seciunile
anterioare. Cu toate acestea, putem tii c dup ICMP reply, nu va mai fi nici un fel de
traffic n aceeai conexiune. Pentru acest motiv, intrarea n baza de date de urmarire a
conexiunii este distrus din moment ce pachetul de raspuns a traversat structura de
filtrare a reelei.
n cazurile ce urmeaz vom considera cererea (request-ul) ca fiind NEW, iar
rspunsul este considerat ca fiind ESTABLISHED. Cnd firewallul vede un pachet
cerere (request), l consider NEW, iar cnd hostul trimite un raspuns (reply), acesta este
considerat ca fiind ESTABLISHED.
Cererea ICMP are un timeout de 30 de secunde. Aceasta valoare poate fi modificata din
intrarea /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout.
O important majora a protocolului ICMP este aceea ca el este utilizat pentru a
spune hostului ce s-a intamplat cu anumite conexiuni TCP si UDP, sau cu anumite
ncercri de conexiune. Datorit acestui fapt, raspunsurile ICMP vor fi foarte des recu-
noscute ca fiind n stare RELATED cu ncercrile de conexiune originale. Un exemplu
simplu ar fi mesajele ICMP Host unreachable (host de neatins) sau ICMP Network
unreachable (reea de neatins). Aceste mesaje ar trebui s le primim tot timpul, dac
ncercarea de a ne conecta la un alt host eueaz datorit faptului c reeaua sau hostul
interogat ar putea fi inactive. Astfel ultimul ruter care ncearc s comunice cu entitatea
solicitat, va rspunde printr-un mesaj ICMP, spunandu-ne c ncercarea de conectare a
euat. n acest caz, raspunsul ICMP este considerat ca fiind un pachet RELATED cu
protocolul pe care am ncercat s l utilizm pentru a apela calculatorul destinaie. n
figura 3.4 se explic acest lucru.



Figura 3.4

S-a trimis un pachet SYN spre o anumit adres. Aceata este consider de firewall
ca fiind o conexiune NEW. Reeaua la care pachetul dorete s ajung, este de neatins,
asa ca un ruter trimite un mesaj ICMP de eroare (network unreachable). Programul de
urmarire a conexiunii recunoaste acest pachet ca fiind n relaie de nrudire cu protocolul
TCP astfel raspunsul ICMP este corect trimis la client care va abandona ncercarea de
conectare. n acest timp, firewallul renuna la intrarea de urmrire a acestei conexiuni din
moment ce tie ca acesta a fost un mesaj de eroare.
Aceeai comportare o observm i in cayul unei conexiuni UDP. Toate mesajele
ICMP trimise ca rspuns la conexiunea UDP sunt considerate ca fiind RELATED cu
protocolul UDP. S considerm urmtoarea figur:




Figura 3.5

De aceast dat un pachet UDP este trimis ctre un host. Aceast conexiune UDP
este considerat ca fiind NEW. Se poate ca reteaua s fie inhibat de un anumit firewall,
sau de un router pe care pachetul ar trebui s l strbat. n aceast situaie firewallul
nostru primeste ca raspuns la pachetul nostru un mesaj ICMP de eroare. Firewallul tie c
acest mesaj ICMP de eroare este inrudit cu conexiunea UDP deja deschis, i l trimite ca
pachet RELATED clientului. n acest moment firewalul va renuna la intrarea de
urmarire a acestei conexiuni, iar clientul primeste mesajul ICMP i abandoneaz
conexiunea.

3.1 Protocoale complexe i urmrirea conexiunii

Unele protocoale sunt mai complexe dect altele deci sunt mai greu de urmarit.
Astfele de protocoale sunt: IRC (Internet Relay Chat), FTP (File Transfer Protocol).
S privim de exemplu protocolul FTP. Iniial acest protocol, deschide o singur
conexiune numit sesiune de control FTP. Cnd emitem comenzi n aceast sesiune, se
deschid alte porturi pentru a transporta restul datelor provenite de la comanda respectiv.
Aceste conexiuni pot fi facute n doua moduri: activ i pasiv. Cnd o conexiune este
facuta activ, clientul FTP trimite serverului un port i o adresa IP la care acesta s se
conecteze. Dup aceasta, clientul deschide portul, i serverul se conecteaz la acel port de
pe popriul port 20 (cunoscut ca si port FTP de date) i trimite date prin acesta. Problema
aici este c, firewallul nu va ti despre aceste extraconexiuni, atta timp ct acestea sunt
negociate n pachetul actual al protocolului de date. Din aceast cauz, firewalul nu va ti
daca trebuie s lase serverul s se conecteze la client pe porturile specificate. Soluia la
aceast problem este s adaugm din kernel un ajutor special modulului de urmarire a
conexiunii, astfel nct n controlul conexiunii s se poat scana datele pentru a gsi
sintaxe i informaii speciale. Cnd se obtine informatia corect, aceasta se va considera
ca fiind RELATED cu protocolul FTP, iar serverul va fi capabil s urmreasca
conexiunea. Aceste lucruri se pot urmari si pe figura urmatoare.



Figura 3.6

Conexiunile FTP pasive funcioneaz exact invers. Clientul FTP spune serverului
c doreste o anume dat, la care serverul raspunde cu adresa IP i portul la care clientul se
poate conecta. Clientul va recepiona aceast informaie, se va conecta de la portul su
20 (FTP+data port) la acel port, si va prelua data pe care a solicitat-o. Dac avem un
server FTP n spatele unui firewall, este necesara utilizarea modulului FTP adiional
modulului iptables din kernel, pentru a lasa clienii de pe internet sa se conecteze la
serverul nostru. n figura 3.7 se prezint o conexiune FTP pasiv.


Figura 3.7
Intrebari LUCRAREA 3:

1) Care este diferenta intre starea ESTABLISHED si ASSURED a unei conexiuni?

2) Care este diferenta intre o conexiune FTP active si una pasiva?