Curs 2 - Aplicatii si protocoale

1. Mecanismul DNS

Vezi: RFC-1034 si RFC-1035

Problema: adresele IP nu sunt adecvate pentru ca utilizatorii umani sa lucreze direct cu ele:

Solutia: un asociem fiecarui calculator un nume, care sa nu depinda de structura fizica a retelei. Spatiul de nume este organizat ierarhic. Ierarhia spatiului de nume reflecta structura administrativa a retelei: un administrator are posibilitatea de-a crea nume noi in zona pe care o administreaza.

Mai trebuie organizata o "carte de telefon" care sa realizeze corespondenta intre numele unui calculator (nume dat de utilizatorul uman) si adresa IP (necesara mecanismelor din infrastructura retelei).

1.1.Spatiul de nume

Spatiul de nume este arborescent. Alocarea lui se face prin delegare: daca o institutie sau organizatie obtine un nume, de exemplu ubbcluj.ro, poate aloca singura, fara acordul vreunei organizatii centrale, nume subordonate, de exemplu zeus.ubbcluj.ro, cs.ubbcluj.ro, etc.

Domeniile din radacina sunt: com, edu, gov, net, mil, org, int, biz, info, name, pro, domeniile de tara, plus un domeniu special: arpa

Fiecarui nume i se asociaza inregistrari de forma
(nume, tip, clasa, valoare).

Clasa se foloseste pentru a distinge informatii necesare pentru mai multe tipuri de retele; In ceea ce ne priveste clasa este IN (internet).

Tipul arata ce informatie este furnizata. Exista urmatoarele tipuri:

Domeniul in-addr.arpa se foloseste pentru stabilirea corespondentei de la adresa IP la nume. Pentru a afla numele unei masini, se scrie adresa IP punand in ordine inversa grupele. De exemplu, pentru a afla numele masinii cu adresa 193.231.20.34 vom cauta o inregistrare cu tipul PTR pentru numele 34.20.231.193.in-addr.arpa.

1.2. Rezolvarea numelor

Server de nume este un proces care dispune de o baza de date ce cuprinde inregistrari DNS. In general, un server de nume raspunde de o zona de nume, detinand toate inregistrarile pentru numele din zona de responsabilitate, si in plus poseda inregistrari suplimentare, legate in general de zonele adiacente - zona parinte si zonele fii.

Serverul raspunde la cereri UDP (SOCK_DGRAM) pe portul 53.

Un program care are nevoie de adresa IP (sau alta informatie) pentru un nume aplica un algoritm de rezolvare a numelui; acest algoritm este implementat de functia de biblioteca standard gethostbyname().

Functia gethostbyname() are nevoie cel putin de o adresa IP pentru un server de nume. Serverul de nume poate sa fie responsabil pentru zona din care face parte numele cerut, caz in care da un raspuns direct; in caz contrar exista mai multe variante:

Se vede de aici ca un server de nume poate retine temporar inregistrari furnizate de alte servere si pentru care el insusi nu are autoritate. Pentru a sti cat timp le poate considera valide, fiecare inregistrare are atasata o perioada de valabilitate (TTL = Time To Live). In timpul perioadei de valabilitate inregstrarea este considerata corecta si furnizata ca raspuns la o noua cerere. Dupa expirarea perioadei de valabilitate, inregistrarea este stearsa, si o noua cerere duce la o noua cautare a raspunsului.

De retinut:

Trimiterea directa a cererilor pentru serverele de nume se poate face cu comanda unix nslookup.

2. Teleprelucrare

2.1. Telnet

Protocolul telnet serveste simularii unui terminal conectat la un sistem de calcul.

Terminalul adevarat:

Mecanismul telnet simuleaza pe un calculator din retea un terminal conectat la serverul telnet.

Etape:

  1. La pornirea sistemului server se porneste demonul de telnet, care asculta pe portul TCP 23
  2. Se porneste clientul telnet pe masina locala. Acesta trimite o cerere de conexiune catre server pe portul 23
  3. Demonul accepta conexiunea si creaza un nou proces server care va gestiona doar acea conexiune; demonul continua sa asculte portul 23 pentru a trata noi clienti
  4. Noul proces server aloca un pseudo-terminal. Pseudo-terminalul este un fel de pereche de tevi (pipe) in ambele sensuri, dar la unul din capete simuleaza un terminal adevarat.
  5. Serverul telnet lanseaza un proces login, cu intrarea si iesirea redirectate catre pseudo-terminal
  6. Procesul login trimite prompterul de login prin pseudo-terminal, serverul telnet si conexiune catre clientul telnet care il afiseaza pe masina locala
  7. Utilizatorul tasteaza numele de login catre clientul telnet; acesta il trimite prin conexiune, serverul telnet si pseudo-terminal catre procesul login
  8. la fel se transmite parola (procesul login transmite cererea de inhibare a ecoului catre pseudo-terminal, care o trimite mai departe prin serverul telnet si conexiune catre clientul telnet; acesta din urma o onoreaza)
  9. dupa autentificare procesul login lanseaza shell-ul pentru utilizator

De remarcat ca, datorita pseudo-terminalului, procesele login, shell, precum si comenzile utilizator, se comporta exact ca si cand ar fi lansate de pe un terminal adevarat.

2.2. rlogin si rsh

rlogin este un sistem similar cu telnet-ul, difera prin schema de autentificare folosita. Astfel, se presupune ca utilizatorul este deja autentificat pe masina pe care ruleaza comanda client (rlogin), si ca masina server are incredere in autentificarea realizata de masina client. Se presupune in cele ce urmeaza ca ambele masini, client si server, ruleaza sisteme de operare de tip Unix.

Desigur, este necesar ca masina server sa afle din ce cont (de pe statia locala) a fost lansata comanda rlogin. In acest scop nu se poate folosi de informatiile transmise de comanda rlogin, deoarece utilizatorul ar fi putut sa scrie propriul program care sa "vorbeasca" protocolul rlogin, iar serverul nu are posibilitatea de a deosebi comanda rlogin "adevarata" de un program oarecare scris de utilizator. In acest scop, pe masina client se ruleaza un program server numit identd care ofera informatii cu privire la procesul care detine un anumit port.

Autentificarea efectuata de serverul rlogin decurge deci dupa cum urmeaza:

  • clientul se conecteaza la server; serverul recupereaza adresa IP si portul de pe care s-a deschis conexiunea
  • serverul contacteaza DNS-ul pentru a obtine numele masinii de pe care s-a incercat conectarea
  • serverul contacteaza serverul identd de pe masina client, si cere UID-ul si numele de utilizator al procesului care detine portul de pe care s-a initiat conexiunea
  • clientul rlogin furnizeaza serverului numele contului in care doreste sa se conecteze
  • daca masina client se gaseste in lista masinilor date ca "echivalente" (din punctul de vedere al conturilor de utilizator), si daca contul solicitat coincide (ca nume) cu contul din care s-a cerut conexiunea, cererea este acceptata
  • daca perechea (nume-cont, nume-masina) din care s-a initiat conexiunea se gaseste pe o lista speciala asociata contului destinatie (lista data in prealabil de acel utilizator), cererea este de asemenea acceptata
  • in caz contrar, se cere parola ca la telnet

    Comanda rsh actioneaza ca si comanda rlogin, dar determina serverul sa nu comunice cu shell-ul printr-un pseudo-terminal, ci direct printr-o pereche de legaturi pipe, si in plus paseaza shell-ului o comanda specificata ca argument comenzii rsh.

    Avantajul rlogin/rsh fata de telnet este faptul ca autentificarea nu necesita transmiterea unei parole, care sa riste sa "transpire". Dezavantajul este ca un intrus care fie sparge masina client fie reuseste sa-i falsifice adresa IP are automat acces la toate conturile de pe masina server. La ora actuala, atat telnet-ul cat si rlogin-ul sunt considerate prea nesigure pentru a fi folosite in orice context cu exceptia poate a unei retele mici, izolate bine de exterior, si in care utilizatorii au incredere unul in altul - conturile servind doar pentru protectia contra greselilor.

    Retele de calculatoare
    11 Oct 2003
    Radu-Lucian LUPSA