Ident

Versiunea actuală a paginii nu a fost încă revizuită de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită la 3 decembrie 2018; verificările necesită 7 modificări .

Protocolul de identificare (ident, Ident Protocol) este protocolul descris în RFC 1413 . Oferă o modalitate de a identifica un utilizator pentru o anumită conexiune TCP . Folosind numerele unei perechi de porturi TCP interconectate ca intrare , protocolul returnează un șir de caractere care identifică proprietarul acestei conexiuni pe partea serverului. Inițial, protocolul de autentificare a fost numit Authentication Server Protocol (Protocol de autentificare server). Serverul care implementează protocolul ident se numește identd ( ident de ́).

Recenzie [1]

Protocolul este un serviciu bazat pe conexiuni TCP. Serverul ascultă conexiunile TCP pe portul 113 (zecimal). După ce conexiunea este stabilită, serverul citește o linie de date care conține informații despre scopul conexiunii. Dacă există un ID de utilizator pentru conexiune, serverul trimite acel ID ca răspuns. Serverul poate închide apoi conexiunea sau poate continua dialogul cerere-răspuns. Serverul ar trebui să închidă conexiunea după expirarea timpului specificat în parametrii de configurare (60-180) în absența oricăror solicitări. Clientul poate închide oricând conexiunea, însă, pentru a compensa eventualele întârzieri ale rețelei, clientul ar trebui să aștepte cel puțin 30 de secunde după solicitare înainte de a închide conexiunea.

Restricții

Trecerea solicitărilor este permisă numai pentru conexiuni complet organizate. Cererea conține numerele unei perechi de porturi (local - la distanță) folosite pentru identificarea conexiunii și primite cu indicarea adreselor locale și la distanță. Aceasta înseamnă că utilizatorul cu adresa A poate cere doar serverului B informații despre conexiunea dintre A și B.

Schema de lucru

Condiții inițiale: identd rulează pe computerul client. Clientul contactează un server extern care poate efectua o verificare de identificare.

  1. Clientul trimite o cerere.
  2. Înainte de a trimite un răspuns, serverul solicită computerului client de pe portul 113 numele utilizatorului care a făcut cererea și specifică numerele de porturi ale conexiunii pe ambele părți.
  3. ascultarea identd pe portul 113 trimite un răspuns.
  4. Serverul primește răspunsul și face ceva cu el (să zicem, scrie în jurnal), după care, la rândul său, trimite răspunsul către client.

Formatul cererilor și răspunsurilor

Serverul acceptă solicitări simple text în formatul:

<port-pe-server>, <port-pe-client>

unde <port-on-server> specifică portul TCP (valoarea zecimală) pentru destinație (gazda unde rulează serverul de identificare) și <port-on-client> specifică portul TCP (valoarea zecimală) pe sistemul client. Este important de reținut că, dacă un client de pe gazda A dorește să interogheze un server de pe gazda B pentru o conexiune definită local (pe gazda A) de perechea de porturi 23, 6191 (conexiune TELNET de intrare), clientul trebuie să interogheze perechea 6191, 23 (identificarea conexiunii din punctul de vedere al gazdei B). De exemplu:

6191, 23

Răspunsul are formatul:

<port-pe-server>, <port-pe-client> : <tip-resp> : <info-adăugare>

unde <port-on-server> și <port-on-client> se potrivesc cu numerele de port din cerere, <resp-type> identifică tipul de răspuns și <add-info> conține date specifice contextului.

Informațiile returnate sunt legate de conexiunea TCP specificată de parametrii <adresa-server>, <adresa-client>, <port-pe-server>, <port-pe-client> (<adresa-server> și <client- adresa> - IP - adresele ambelor părți ale conexiunii, iar <port-on-server> și <port-on-client> sunt parametri de cerere)

De exemplu:

6193, 23 : USERID : UNIX : stjohns 6195, 23 : EROARE: FĂRĂ UTILIZATOR

Tipuri de răspuns

Răspunsurile pot fi de două tipuri:

USERID

În acest caz, șirul <add-info> conține numele sistemului de operare (incluzând eventual setul de caractere acceptat), urmat de un delimitator „:” și un șir de identificare.

Dacă răspunsul conține un set de caractere, setul de caractere este separat de numele sistemului de operare printr-o virgulă (,). Identificatorii standard sunt utilizați pentru a desemna un set de caractere. Dacă nu este specificat niciun set de caractere, se presupune US-ASCII (vezi mai jos).

Identificatorii sistemului de operare trebuie să fie specificati în conformitate cu RFC 1340 [2] , „Numerele atribuite” sau „succesorii” acestuia.

Pe lângă identificatorii OS specificati în „Numere atribuite”, poate fi utilizat identificatorul special „OTHER” (Alt OS).

Dacă „OTHER” nu este returnat ca sistem de operare, se presupune că serverul returnează identificarea „normală” a utilizatorului care deține conexiunea (un șir de caractere care identifică în mod unic utilizatorul, cum ar fi un nume de utilizator pe sistem sau utilizatorul). parte a unei adrese de e-mail). Dacă este specificat un sistem de operare (adică șirul de răspuns nu conține „OTHER”), se presupune că numele de utilizator este, de asemenea, semnificativ (de exemplu, pentru a fi folosit ca argument pentru o comandă cu degetul sau ca parte a unei adrese de corespondență) .

Valoarea „OTHER” indică faptul că următoarele date sunt un șir neformatat de caractere imprimabile ale setului utilizat în sistem. Un răspuns „ALT” TREBUIE returnat dacă ID-ul utilizatorului nu corespunde cerințelor descrise mai sus. De exemplu, un astfel de răspuns TREBUIE trimis dacă un nume real sau un număr de telefon dintr-o intrare de utilizator UNIX este returnat în loc de un nume de utilizator .

Se presupune că ID-ul utilizatorului conține doar caractere imprimabile ale setului utilizat în sistem. Identificatorul este un șir de octet care nu include caracterele (octal) 000 (NUL), 012 (LF) și 015 (CR). Este important de subliniat faptul că caracterele de spațiu (040) după două puncte fac parte din șirul de identificare și nu trebuie ignorate. De obicei, linia de răspuns se termină cu o secvență CR/LF. Subliniem că șirul poate conține caractere imprimabile, dar nu trebuie să le conțină doar pe acestea.

EROARE

Dacă dintr-un motiv oarecare nu poate fi determinat proprietarul conexiunii, linia <add-info> raportează motivul. Următoarele valori <add-info> sunt posibile:

  • INVALID-PORT - unul dintre porturi este specificat incorect. Un astfel de răspuns este returnat dacă unul dintre porturi (sau ambele) este în afara intervalului (porturile TCP pot fi numerotate de la 1 la 65535) sau nu este un număr întreg.
  • NO-USER - Conexiunea specificată de perechea de porturi nu este utilizată în prezent sau este deținută de o entitate necunoscută.
  • HIDDEN-USER - Serverul poate identifica utilizatorul, dar nu raportează utilizatorul atunci când este solicitat de acel utilizator.
  • EROARE NECUNOSCUT - Cauza erorii nu poate fi determinată (orice motiv care nu este enumerat mai sus). Un astfel de răspuns poate fi returnat și în cazurile în care serverul poate determina cauza erorii, dar nu dorește să o raporteze. Dacă serverul implementează această capacitate, ar trebui să fie configurabilă și serverul ar trebui să returneze un mesaj de eroare valid în mod implicit.

Alte coduri de răspuns pot fi adăugate în viitor. Când se utilizează răspunsuri nestandard, acestea trebuie să înceapă cu caracterul „X”.

Pe lângă returnarea răspunsurilor, serverul POATE opri conexiunile fără a returna niciun răspuns. O întrerupere prematură a conexiunii (clientul nu a primit un caracter EOL) TREBUIE să fie tratată de către client ca un răspuns „EROARE: EROARE NECUNOSCUT”.

Sintaxă formală

<cerere> ::= <pereche-port> <EOL> <port-pereche> ::= <integer> "," <integer> <răspuns> ::= <text-răspuns> <EOL> <EOL> ::= "015 012" ; Indicator de sfârșit de linie CR-LF <text-răspuns> ::= <răspuns-eroare> | <ident-răspuns> <eroare-răspuns> ::= <port-pereche> ":" "EROARE" ":" <tip-eroare> <ident-reply> ::= <port-pereche> ":" "USERID" ":" <opsys-field> „:” <user-id> <tip-eroare> ::= „PORT-INVALID” | „NICIUN UTILIZATOR” | "EROARE NECUNOSCUTĂ" | „UTILIZATOR ASCUNS” | <semnal de eroare> <opsys-field> ::= <opsys> [ "," <charset>] <opsys> ::= „ALTELE” | UNIX | <jeton> ...etc.  ; (Consultați „Numerele atribuite”) <charset> ::= „US-ASCII” | ...etc.  ; (Consultați „Numerele atribuite”) <user-id> ::= <octet-string> <token> ::= 1*64<token-characters> ; 1-64 de caractere <indicativ-eroare> ::= "X"1*63<caracterele-semnificative>  ; 2-64 de caractere începând cu X <intger> ::= 1*5<cifra> ; 1-5 cifre. <cifră> ::= „0” | „1” ... „8” | "9"; 0-9 <caracterele-jeton> ::= <Orice dintre aceste caractere ASCII: AZ, AZ, - (liniuță), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >  ; majuscule si minuscule az plus  ; imprimabile minus două puncte „:”  ; caracter. <octet-șir> ::= 1*512<octet-caractere> <octet-caractere> ::= <orice octet de la 00 la 377 (octal), cu excepția ASCII NUL(000), CR(015) și LF(012)>

Note:

  1. Pentru a asigura interoperabilitatea între diferite implementări în ceea ce privește interpretarea caracterelor spațiilor albe, ar trebui să se respecte principiul general: „fii conservator la transmitere și liberal la recepție”. Clienții și serverele NU TREBUIE să genereze spații suplimentare, dar TREBUIE să accepte linii cu spații suplimentare de la alții. Spații albe suplimentare pot apărea oriunde, cu excepția jetoanelor în sine. În special, pot apărea spații suplimentare la începutul și la sfârșitul șirurilor de solicitare și răspuns. Cu toate acestea, spații suplimentare nu sunt permise într-un răspuns cu un ID de utilizator după două puncte după numele sistemului de operare, deoarece în acest caz ele vor fi tratate ca parte a numelui de utilizator (numele de utilizator este considerat întreaga secvență de caractere din două puncte la terminatorii de linie CR/LF). Caracterele CR/LF nu trebuie considerate parte din ID-ul utilizatorului.
  2. Fără a aduce atingere celor de mai sus, serverele TREBUIE să limiteze numărul de spații dintre elemente (jetoane) la minimum posibil (util). Clientul poate termina conexiunea dacă sunt primite mai mult de 1000 de caractere fără semnalul de terminare a liniei <EOL>.
  3. Dimensiunea ID-ului utilizatorului TREBUIE să fie limitată la 512 caractere și dimensiunea token-ului la 64 de caractere deoarece: a) token-urile noi (adică, OPSYS sau ERROR-TYPE) vor fi limitate la 64 de caractere și b) serverul nu trebuie să trimită mai mult de 512 octeți ID-ul utilizatorului, iar clientul TREBUIE să accepte primii 512 octeți ai ID-ului utilizatorului. Din cauza acestor restricții, serverul trebuie să returneze cea mai semnificativă parte a ID-ului utilizatorului în primii 512 octeți .
  4. Trebuie utilizate numai acele seturi de caractere și identificatori de seturi de caractere specificate în RFC 1340, „Numerele atribuite” și versiunile ulterioare ale acestui document. Identificatorii setului de caractere se aplică numai câmpurilor de identificare a utilizatorului, iar toate celelalte câmpuri trebuie să utilizeze setul de caractere US-ASCII.
  5. Deși câmpul <user-id> a fost definit mai sus ca <octet-string> (un șir de octet), trebuie să se potrivească în format și setul de caractere cu valoarea câmpului <opsys-field>; descris mai sus.
  6. Identificatorul setului de caractere oferă clientului contextul pentru a imprima sau a stoca șirul de identificare al utilizatorului. Dacă clientul nu poate recunoaște sau utiliza setul de caractere specificat, TREBUIE să trateze șirul de identificare ca un șir de octet (OCTET), stocând împreună cu acesta identificatorul setului de caractere utilizat. Șirul octet în astfel de cazuri TREBUIE să fie tipărit, stocat și procesat în notație hexazecimală (0-9a-f) în plus față de notația utilizată de implementarea client (acest lucru permite o notație standard în diferite implementări).

Aplicarea ident

  • Pe IRC : Unele servere IRC necesită un răspuns obligatoriu de la identd din partea utilizatorului.
  • Pentru a filtra spamul care vine de la computerul local (de exemplu, pe site-uri de găzduire ): sendmail întreabă identd cine a trimis e-mailul și adaugă numele real al expeditorului la e-mail. Dacă un e-mail de spam „semnat” ajunge apoi pe alt computer sub același control administrativ, atunci spammerul local va fi identificat instantaneu și (ulterior) blocat.
  • Pentru autentificare într-un singur computer în acele sisteme de operare în care nu este posibilă verificarea expeditorului unui mesaj prin intermediul unui socket UNIX (așa-numita schemă de acreditări Unix).

Probleme de securitate

  • Nu trebuie să aveți încredere niciodată în datele care provin de la serverele de identificare ale altcuiva (adică în acelea pe care nu le-ați configurat), deoarece acestea pot fi falsificate/ascunse. Sub nicio formă nu trebuie utilizat identd pentru autentificarea rețelei, chiar și cu clienți de încredere, deoarece piratarea mașinii client va sparge serverul care are încredere în el (vezi și încredere intersistem ).
  • Uneori nu este de dorit ca un client să „strălucească” pe Internet. Un exemplu în acest sens ar fi diferiți roboți care rulează din anumite motive cu privilegii de rădăcină . Unele servere de identificare oferă posibilitatea de a controla mascarea unor utilizatori.

Nivelul de valabilitate al informațiilor returnate de acest protocol depinde de setările gazdei solicitate și de politica organizației care menține gazda . De exemplu, un PC folosit într-un laborator deschis poate returna orice informații despre sine pe care utilizatorul dorește să le furnizeze. În plus, gazda poate returna informații special distorsionate (false).

Protocolul de identificare nu este destinat pentru autorizare (autentificare) sau controlul accesului. În cel mai bun caz, acest protocol oferă câteva informații suplimentare despre conexiunile TCP , în cel mai rău caz, returnează informații eronate, incorecte sau distorsionate în mod deliberat.

Utilizarea informațiilor returnate de protocol în orice alt scop decât auditul este puternic descurajată. În special, utilizarea Protocolului de identificare pentru a lua decizii de acces ca mijloc primar (adică, în absența altor verificări) sau secundar poate reduce semnificativ nivelul de securitate al unei gazde.

Serverul de identitate poate colecta informații despre utilizatori, obiecte și procese, care pot conține adesea date private. Serverul de identitate oferă servicii similare cu serviciile CallerID suportate de unele companii de telefonie, iar cerințele pentru informațiile raportate de server sunt formate în același mod ca și pentru datele CallerID. Dacă nu doriți să susțineți serviciul finger din motive de restricționare a accesului la informațiile utilizatorului, nu doriți să utilizați protocolul de autentificare.

Implementări

Protocolul de identificare este cel mai popular subiect de facto pentru „ Ho, World ” avansat (adică cea mai bună direcție de luat atunci când învățați serios să programați). În acest sens, numărul demonilor care îl implementează este uriaș. Mai jos sunt link-uri către cele mai comune și mai frecvent utilizate servere din această clasă.


Note

  1. ↑ M. St. Johns. Protocol  de identificare . tools.ietf.org. Preluat la 16 ianuarie 2019. Arhivat din original la 8 iulie 2017.
  2. ↑ J. Postel, J. Reynolds. Numere  atribuite . tools.ietf.org. Preluat la 16 ianuarie 2019. Arhivat din original la 29 noiembrie 2019.