Ident

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 3. december 2018; checks kræver 7 redigeringer .

Identifikationsprotokollen ( ident, Ident Protocol) er den protokol, der er beskrevet i RFC 1413 . Det giver en måde at identificere en bruger for en bestemt TCP -forbindelse . Ved at bruge numrene på et par indbyrdes forbundne TCP - porte som input returnerer protokollen en tegnstreng, der identificerer ejeren af ​​denne forbindelse på serversiden. Oprindeligt hed godkendelsesprotokollen Authentication Server Protocol (Server Authentication Protocol). Serveren, der implementerer ident-protokollen, kaldes identd ( ident de ́).

Gennemgå [1]

Protokollen er en tjeneste baseret på TCP-forbindelser. Serveren lytter efter TCP-forbindelser på port 113 (decimal). Efter at forbindelsen er etableret, læser serveren en datalinje, der indeholder information om formålet med forbindelsen. Hvis der findes et bruger-id for forbindelsen, sender serveren dette id som et svar. Serveren kan derefter lukke forbindelsen eller fortsætte dialogen med anmodning og svar. Serveren bør lukke forbindelsen efter den timeout, der er angivet i konfigurationsparametrene (60-180), hvis der ikke er nogen anmodninger. Klienten kan til enhver tid lukke forbindelsen, men for at kompensere for mulige netværksforsinkelser bør klienten vente mindst 30 sekunder efter anmodningen, før forbindelsen lukkes.

Begrænsninger

Videregivelse af anmodninger er kun tilladt for fuldt organiserede forbindelser. Forespørgslen indeholder numrene på et par porte (lokal - fjernbetjening), der bruges til at identificere forbindelsen og modtages med angivelse af lokal- og fjernadresse. Det betyder, at brugeren med adresse A kun kan bede server B om oplysninger om forbindelsen mellem A og B.

Arbejdsplan

Startbetingelser: identd kører på klientmaskinen. Klienten kontakter en ekstern server, der kan udføre en identitetskontrol.

  1. Kunden sender en anmodning.
  2. Før der sendes et svar, spørger serveren klientmaskinen på port 113 om navnet på den bruger, der lavede anmodningen, og specificerer portnumrene på forbindelsen på begge sider.
  3. identd-lytning på port 113 sender et svar.
  4. Serveren modtager svaret og gør noget med det (f.eks. skriver til loggen), hvorefter det igen sender svaret til klienten.

Format for anmodninger og svar

Serveren accepterer simple tekstanmodninger i formatet:

<port-on-server>, <port-on-client>

hvor <port-on-server> angiver TCP-porten (decimalværdi) for destinationen (værten, hvor ident-serveren kører), og <port-on-client> angiver TCP-porten (decimalværdi) på klientsystemet. Det er vigtigt at bemærke, at hvis en klient på vært A ønsker at forespørge en server på vært B for en forbindelse defineret lokalt (på vært A) af portpar 23, 6191 (indgående TELNET-forbindelse), skal klienten forespørge efter par 6191, 23 (forbindelsesidentifikation set fra vært B's synspunkt). For eksempel:

6191, 23

Svaret har formatet:

<port-on-server>, <port-on-client> : <resp-type> : <add-info>

hvor <port-on-server> og <port-on-client> matcher portnumrene i anmodningen, identificerer <resp-type> svartypen, og <add-info> indeholder kontekstspecifikke data.

De returnerede oplysninger er relateret til TCP-forbindelsen specificeret af parametrene <server-adresse>, <klient-adresse>, <port-on-server>, <port-on-client> (<server-adresse> og <klient- adresse> - IP - adresser på begge sider af forbindelsen, og <port-on-server> og <port-on-client> er anmodningsparametre)

For eksempel:

6193, 23 : BRUGERID : UNIX : stjohns 6195, 23: FEJL: INGEN BRUGER

Svartyper

Svarene kan være af to typer:

BRUGERID

I dette tilfælde indeholder <add-info>-strengen navnet på operativsystemet (eventuelt inklusive det understøttede tegnsæt), efterfulgt af et ":"-skilletegn og en identifikationsstreng.

Hvis svaret indeholder et tegnsæt, adskilles tegnsættet fra operativsystemets navn med et komma (,). Standardidentifikatorer bruges til at udpege et sæt tegn. Hvis der ikke er angivet et tegnsæt, antages US-ASCII (se nedenfor).

Operativsystemidentifikatorer skal angives i overensstemmelse med RFC 1340 [2] , "Tildelte numre" eller dets "efterfølgere".

Ud over de OS-identifikatorer, der er angivet i "Tildelte numre", kan den særlige identifikator "OTHER" (Andet OS) bruges.

Hvis "ANDET" ikke returneres som operativsystemet, antages serveren at returnere den "normale" identifikation af brugeren, der ejer forbindelsen (en tegnstreng, der entydigt identificerer brugeren, såsom et brugernavn på systemet eller brugeren del af en e-mailadresse). Hvis et operativsystem er angivet (dvs. svarstrengen indeholder ikke "ANDET"), antages brugernavnet også at være meningsfuldt (for eksempel at blive brugt som et argument til en fingerkommando eller som en del af en postadresse) .

Værdien "OTHER" angiver, at følgende data er en uformateret streng af udskrivbare tegn fra det sæt, der bruges i systemet. Et "ANDET" svar SKAL returneres, hvis bruger-id'et ikke matcher kravene beskrevet ovenfor. For eksempel SKAL et sådant svar sendes, hvis et rigtigt navn eller telefonnummer fra en UNIX -brugerpost returneres i stedet for et brugernavn .

Det antages, at bruger-id'et kun indeholder printbare tegn fra det sæt, der bruges i systemet. Identifikationen er en oktetstreng, der ikke inkluderer tegnene (oktal) 000 (NUL), 012 (LF) og 015 (CR). Det er vigtigt at understrege, at mellemrumstegnene (040) efter kolon er en del af identifikationsstrengen og ikke bør ignoreres. Typisk slutter svarlinjen med en CR/LF-sekvens. Vi understreger, at strengen kan indeholde printbare tegn, men ikke kun behøver at indeholde dem.

FEJL

Hvis ejeren af ​​forbindelsen af ​​en eller anden grund ikke kan bestemmes, rapporterer <add-info>-linjen årsagen. Følgende <add-info> værdier er mulige:

  • INVALID-PORT - en af ​​portene er angivet forkert. Et sådant svar returneres, hvis en af ​​(eller begge) af portene er uden for rækkevidde (TCP-porte kan nummereres fra 1 til 65535) eller ikke er et heltal.
  • NO-USER - Forbindelsen specificeret af portparret er ikke i brug i øjeblikket eller ejes af en ukendt enhed.
  • SKJULT-BRUGER - Serveren kan identificere brugeren, men rapporterer ikke brugeren, når denne bruger anmoder om det.
  • UNKENDT-FEJL - Årsagen til fejlen kan ikke bestemmes (enhver årsag, der ikke er angivet ovenfor). Et sådant svar kan også returneres i tilfælde, hvor serveren kan fastslå årsagen til fejlen, men ikke ønsker at rapportere den. Hvis serveren implementerer denne funktion, skal den kunne konfigureres, og serveren skal som standard returnere en gyldig fejlmeddelelse.

Andre svarkoder kan blive tilføjet i fremtiden. Når du bruger ikke-standardsvar, skal de begynde med tegnet "X".

Ud over at returnere svar, KAN serveren afslutte forbindelser uden at returnere noget svar. En for tidlig afbrydelse af forbindelsen (klienten modtog ikke et EOL-tegn) SKAL behandles af klienten som et "FEJL : UKENDT-FEJL"-svar.

Formel syntaks

<request> ::= <port-pair> <EOL> <port-pair> ::= <heltal> "," <heltal> <reply> ::= <reply-text> <EOL> <EOL> ::= "015 012" ; CR-LF End of Line Indikator <reply-text> ::= <fejl-svar> | <ident-reply> <error-reply> ::= <port-pair> ":" "FEJL" ":" <fejltype> <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field> ":" <bruger-id> <error-type> ::= "UGYLDIG-PORT" | "INGEN BRUGER" | "UKENDT FEJL" | "SKJULT BRUGER" | <fejl-token> <opsys-field> ::= <opsys> [ "," <charset>] <opsys> ::= "ANDET" | UNIX | <token> ...osv.  ; (Se "Tildelte numre") <charset> ::= "US-ASCII" | ...etc.  ; (Se "Tildelte numre") <bruger-id> ::= <oktet-streng> <token> ::= 1*64<token-tegn> ; 1-64 tegn <fejl-token> ::= "X"1*63<token-tegn>  ; 2-64 tegn begyndende m/X <heltal> ::= 1*5<cifret> ; 1-5 cifre. <digit> ::= "0" | "1" ... "8" | "9" ; 0-9 <token-characters> ::= <Enhver af disse ASCII-tegn: AZ, AZ, - (bindestreg), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >  ; store og små bogstaver az plus  ; printables minus kolon ":"  ; Karakter. <oktet-streng> ::= 1*512<oktet-tegn> <oktet-karakterer> ::= <enhver oktet fra 00 til 377 (oktal) undtagen ASCII NUL(000), CR(015) og LF(012)>

Bemærkninger:

  1. For at sikre interoperabilitet mellem forskellige implementeringer med hensyn til fortolkning af blanktegn, bør man overholde det generelle princip: "vær konservativ, når du sender og liberal, når du modtager". Klienter og servere BØR ikke generere ekstra mellemrum, men de SKAL acceptere linjer med ekstra mellemrum fra andre. Ekstra mellemrum kan forekomme overalt undtagen selve tokens. Især kan der forekomme yderligere mellemrum i begyndelsen og slutningen af ​​anmodnings- og svarstrenge. Yderligere mellemrum er dog ikke tilladt i et svar med et bruger-id efter et kolon efter operativsystemnavnet, fordi de i dette tilfælde vil blive behandlet som en del af brugernavnet (brugernavnet betragtes som hele sekvensen af ​​tegn fra kolon til CR/LF-linjeterminatorerne). CR/LF-tegn bør ikke betragtes som en del af bruger-id'et.
  2. Uanset ovenstående BØR servere begrænse antallet af mellemrum mellem elementer (tokens) til det mindst mulige (nyttigt). Klienten kan afslutte forbindelsen, hvis der modtages mere end 1000 tegn uden <EOL>-linjetermineringssignalet.
  3. Bruger-id-størrelsen SKAL være begrænset til 512 tegn og tokenstørrelsen til 64 tegn, fordi: a) nye tokens (dvs. OPSYS eller ERROR-TYPE) vil være begrænset til 64 tegn, og b) serveren ikke må sende mere end 512 oktetter bruger-id, og klienten SKAL acceptere de første 512 oktetter af bruger-id'et. På grund af disse begrænsninger skal serveren returnere den væsentligste del af bruger-id'et i de første 512 oktetter .
  4. Kun de tegnsæt og tegnsætidentifikatorer, der er specificeret i RFC 1340, "Tildelte numre" og senere versioner af dette dokument, bør bruges. Tegnsæt-id'er gælder kun for brugeridentifikationsfelter, og alle andre felter skal bruge US-ASCII-tegnsættet.
  5. Selvom feltet <bruger-id> ovenfor blev defineret som <oktet-streng> (en oktetstreng), skal det matche i format og tegnsæt værdien af ​​feltet <opsys-felt>; beskrevet ovenfor.
  6. Tegnsætidentifikatoren giver klienten konteksten til at udskrive eller gemme brugerens identifikationsstreng. Hvis klienten ikke kan genkende eller bruge det angivne tegnsæt, SKAL den behandle identifikationsstrengen som en oktetstreng (OCTET), der med sig gemmer identifikatoren for det anvendte tegnsæt. Oktetstrengen SKAL i sådanne tilfælde udskrives, lagres og behandles i hexadecimal notation (0-9a-f) ud over den notation, der bruges af klientimplementeringen (dette tillader en standardnotation i forskellige implementeringer).

Anvendelse af ident

  • På IRC : Nogle IRC-servere kræver et obligatorisk svar fra identd på login-brugerens side.
  • For at filtrere spam , der kommer fra den lokale computer (for eksempel på hosting-websteder ): sendmail spørger identd, hvem der sendte e-mailen og tilføjer afsenderens rigtige navn til e-mailen. Hvis en "signeret" spam-e-mail derefter kommer til en anden computer under samme administrative kontrol, vil den lokale spammer øjeblikkeligt blive identificeret og (efterfølgende) blokeret.
  • Til autentificering inden for én computer i de operativsystemer, hvor det ikke er muligt at kontrollere afsenderen af ​​en besked via en UNIX-socket (det såkaldte unix-legitimationsskema).

Sikkerhedsproblemer

  • Du bør aldrig stole på data, der kommer fra en andens ident-servere (det vil sige dem, som du ikke har konfigureret), fordi de kan forfalskes / skjules. Under ingen omstændigheder bør identd bruges til netværksgodkendelse, selv med betroede klienter, da hacking af klientmaskinen vil hacke den server, der har tillid til den (se også intersystem trust ).
  • Nogle gange er det uønsket for en klient at "stråle" på internettet. Et eksempel på dette ville være forskellige bots , der af en eller anden grund kører med root-rettigheder . Nogle ident-servere giver mulighed for kontrol med at maskere nogle brugere.

Gyldighedsniveauet for de oplysninger, der returneres af denne protokol, afhænger af indstillingerne for den anmodede vært og politikken for den organisation, der vedligeholder værten . For eksempel kan en pc , der bruges i et åbent laboratorium, returnere enhver information om sig selv, som brugeren ønsker at give. Desuden kan værten returnere særligt forvrængede (falske) oplysninger.

Identifikationsprotokollen er ikke beregnet til autorisation (godkendelse) eller adgangskontrol. I bedste fald giver denne protokol nogle yderligere oplysninger om TCP -forbindelser , i værste fald returnerer den fejlagtig, forkert eller bevidst forvrænget information.

Det frarådes på det kraftigste at bruge de oplysninger, der returneres af protokollen til andre formål end revision. Især brug af identifikationsprotokollen til at træffe adgangsbeslutninger som primære (dvs. i mangel af andre kontroller) eller sekundære midler kan reducere sikkerhedsniveauet for en vært betydeligt.

Identitetsserveren kan indsamle oplysninger om brugere, objekter og processer, som ofte kan indeholde private data. Identitetsserveren leverer tjenester svarende til de CallerID -tjenester, der understøttes af nogle telefonselskaber, og kravene til informationer, der indberettes af serveren, er udformet på samme måde som for CallerID-data. Hvis du ikke ønsker at understøtte fingerservicen af ​​hensyn til at begrænse adgangen til brugeroplysninger, ønsker du heller ikke at bruge autentificeringsprotokollen.

Implementeringer

Ident-protokollen er det de facto mest populære emne for avancerede " Hej, verden " (dvs. den bedste retning at tage, når man seriøst lærer at programmere). I denne henseende er antallet af dæmoner , der implementerer det, enormt. Nedenfor er links til de mest almindelige og mest brugte servere i denne klasse.


Noter

  1. ↑ M. St. Johns. Identifikationsprotokol  . _ tools.ietf.org. Hentet 16. januar 2019. Arkiveret fra originalen 8. juli 2017.
  2. ↑ J. Postel, J. Reynolds. Tildelte numre  . tools.ietf.org. Hentet 16. januar 2019. Arkiveret fra originalen 29. november 2019.