Ce este SSH și cum funcționează?

Secure SHell (SSH) este un protocol de securitate implementat frecvent cu o serie de utilizări diferite. Cea mai cunoscută aplicație permite utilizatorilor să accesați în siguranță computerele și serverele la distanță, dar poate fi folosit și pentru tunelare, redirecționarea porturilor, transferuri de fișiere sigure și multe altele.

În acest ghid, vom aborda ce este SSH, la ce se folosește, istoricul protocolului, detaliile sale tehnice, la fel de bine ca probleme de securitate care trebuie luate în considerare.

SSH este format din trei protocoale separate: stratul de transport, stratul de autentificare și stratul de conexiune. Împreună, acestea servesc la autentificarea celeilalte părți în conexiune, asigură confidențialitatea prin criptare și verifică integritatea datelor. SSH este acum cel mai frecvent implementat fie ca SSH-2 proprietar, fie ca iterație open-source, OpenSSH.

Utilizările SSH

SSH este un protocol versatil. Structura și caracteristicile sale de securitate îi permit să fie utilizat într-o serie de moduri, precum accesul la distanță, redirecționarea porturilor, tunelarea și transferurile de fișiere sigure.

Acces de la distanță

Accesul de la distanță oferă utilizatorilor o modalitate de a conectați-vă la un alt computer sau server de la propria mașină. Este folosit pentru a accesa fișierele locale ale mașinii vizate sau pentru a efectua servicii pe acesta, fără a fi nevoie să fiți acolo fizic.

Programele precum Telnet și rlogin au, de asemenea, această funcționalitate, dar nu au caracteristicile de securitate ale SSH. Măsurile de criptare și autentificare implicate în SSH permit utilizatorilor să se conecteze la un alt server sau computer într-un mod protejat, chiar și printr-o rețea intermediară potențial periculoasă.

Accesul de la distanță cu SSH este implementat în mod obișnuit pentru ca angajații să poată lucra de la distanță sau pentru a permite departamentului IT să îndeplinească sarcini fără a fi nevoie să meargă fizic la mașină. Poate fi utilizat pentru administrarea de la distanță, gestionarea infrastructurii de rețea, pentru a configura automatizarea, pentru a crea copii de rezervă și multe altele.

Port forwarding

Port forwarding este utilizat pentru a transfera cereri de la o adresă și număr de port la alt set. Aplică traducerea adreselor de rețea (NAT) pentru a redirecționa porturile între o rețea locală și un computer la distanță, permițându-vă să accesați un dispozitiv din afara rețelei.

Expedierea porturilor se poate face în trei moduri diferite:

• Local port forwarding – Transmiterea portului local vă permite să vă conectați clientul local și o rețea externă. Poate fi eficient pentru a face lucruri precum accesarea site-urilor web blocate local sau pentru conectarea la o bază de date care se află în spatele unui firewall.
• Redirecționarea portului de la distanță – Acest tip de redirecționare permite aplicațiilor din partea serverului să acceseze servicii din partea clientului. Redirecționarea porturilor de la SSH permite utilizatorilor să se conecteze în siguranță la serverele la distanță prin computerul local, redirecționând un port local către un server SSH de la distanță..
• Dinamic port forwarding – Acest lucru permite utilizatorilor să își trimită datele printr-un anumit port către un computer sau server de la distanță, folosind un număr de servere SSH care acționează ca proxies.

tunelurilor

Protocoalele de tunelare folosesc încapsularea pentru a muta datele între rețele. Tunelele pot fi implementate pentru a permite protocoalelor non-native să ruleze prin rețele care, în mod normal, nu le vor susține. O altă utilizare obișnuită este pentru asigurarea securității pe o rețea nesigură.

Protocoalele de tunelare înfășoară pachete critice în sarcina utilă a unui alt pachet. Tunelarea SSH permite utilizatorilor să obțină securitatea rețelei, să conecteze dispozitivele folosind un protocol de rețea nativ și să asigure datele care sunt transmise. Acestea sunt frecvent utilizate pentru a conecta utilizatorii la distanță la resursele online ale organizației lor într-o manieră sigură.

SFTP

Protocolul de transfer de fișiere SSH (FTP), cunoscut uneori sub numele de Secure Transfer Transfer Protocol (Protocole de transfer de fișiere sigure) oferă un mod sigur de accesare, transfer și gestionare a fișierelor. Este o alternativă sigură la FTP și folosește protocolul SSH pentru a trimite, primi și administra în siguranță fișierele.

SCP

Protocolul de copiere securizată (SCP) este similar cu SFTP, dar mai limitat în domeniul său de aplicare. Acesta permite transferuri de fișiere sigure, mai degrabă decât setul complet de caracteristici care permit SFTP să acționeze ca un protocol de sistem de fișiere la distanță.

platforme & aplicații care folosesc SSH

Proprietar SSH sau OpenSSH pot fi utilizate pe toate sistemele de operare majore. Este disponibil pe platformele bazate pe Unix, cum ar fi OpenBSD, macOS, Linux și Solaris, în timp ce utilizatorii Windows pot utiliza SSH prin PowerShell.

Istoria SSH

SSH a fost dezvoltat la Universitatea de Tehnologie din Helsinki în 1995 de către Tatu Ylönen, ca răspuns la un atac de respingere a parolei în rețeaua universității. Acesta a urmărit să ofere o alternativă la protocoale de genul FTP, TELNET, dur și rlogin, care nu a asigurat confidențialitatea sau autentificarea utilizatorilor într-o manieră sigură.

SSH a fost lansat gratuit publicului în 1995 și a fost bine primit. Pe fondul adoptării rapide, Ylönen a fondat SSH Communications Security până la sfârșitul aceluiași an pentru a continua dezvoltarea și comercializarea SSH.

În 1995, Ylönen a publicat, de asemenea, un proiect de Internet Engineering Task Force (IETF) a documentat protocolul SSH-1. Curând au fost găsite limitări în protocol și acestea nu au putut fi abordate fără a afecta compatibilitatea înapoi. Soluția a fost o nouă versiune a protocolului, iar SSH-2 a fost lansat de compania lui Ylönen în 1996.

SSH-2 a prezentat noi algoritmi, care au determinat IETF să creeze un grup de lucru care să urmărească standardizarea protocolului. Grupul a fost poreclit SECSH, pentru secure SHell, și a publicat primul său draft Internet pentru SSH-2 în 1997.

Software-ul pentru SSH-2 a fost lansat în 1998, dar nu a fost adoptat imediat într-o manieră largă din cauza licențelor sale mai restrictive. În 2006, IETF a făcut o versiune modificată a protocolului. Acest lucru a fost mai sigur, folosind coduri de autentificare a mesajelor pentru a verifica integritatea și schimbul de chei Diffie-Hellman pentru autentificare.

În 1999, proiectul OpenBSD a lansat OpenSSH. OpenSSH este o versiune gratuită a protocolului care se bazează pe modificările pe care Björn Grönvall le-a făcut la SSH 1.1.12. Dezvoltatorii au revenit la această versiune mai veche și au modificat-o puternic, deoarece a fost ultima versiune a SSH care a fost complet open source. OpenSSH este acum cea mai utilizată opțiune și de atunci a fost implementată într-o serie de sisteme de operare, cum ar fi Windows, macOS, Linux, Solaris și altele.

SSH-1 vs SSH-2 vs OpenSSH

După cum s-a menționat mai sus, SSH-1 este prima versiune a protocolului, care a fost lansată inițial sub un licență open-source. Este considerat nesigur și nu ar trebui pus în aplicare. Aceasta lasă versiunea proprie, SSH-2, și versiunea disponibilă liber, OpenSSH, ca alternative viabile.

SSH-2 și OpenSSH sunt, în esență, aceleași atunci când vine vorba de arhitectura lor și modul de funcționare. Principala diferență este că versiunea proprietară vine cu o serie de opțiuni de asistență, în timp ce cele care folosesc OpenSSH trebuie să se bazeze pe resursele create liber de comunitate.

SSH: Detaliile tehnice

SSH-1 a funcționat ca un protocol unic, dar nu vom intra în el aici, deoarece este învechit. În schimb, ne vom concentra pe SSH-2 și OpenSSH, care sunt alcătuite din trei protocoale separate:

• Protocolul de transport – Aceasta stabilește conexiunea și oferă securitatea de bază.
• Protocolul de autentificare – Acest strat este folosit pentru autentificarea clientului.
• Protocolul de conectare – Acest protocol gestionează canalele prin care se transmit date.

Fiecare dintre aceste protocoale îndeplinește un rol unic care lucrează la stabilirea și securizarea unei conexiuni, autentificarea celeilalte părți și transferul datelor. Portul de conexiune TCP implicit este 22 și conexiunile sunt configurate între un client SSH și un server SSH de-a lungul modelul client-server.

Procesul de conectare de la distanță al SSH se desfășoară în conformitate cu următoarea structură de bază (cu variații în funcție de configurație), pe care le vom descrie mai detaliat ulterior:

• Clientul contactează serverul SSH pentru a începe conexiunea.
• Apoi, serverul trimite cheia sa publică către client pentru a-și autentifica identitatea.
• Cele două părți negociază parametrii pentru conexiune, apoi stabilesc un canal sigur de-a lungul acestor linii.
• Utilizatorul se conectează apoi la sistemul de operare al gazdei serverului și acum își poate administra sarcinile la distanță.

Protocol de transport

Stratul de transport este un protocol de nivel scăzut care are grijă de următoarele sarcini.

• Autentificare gazdă server
• Schimb de chei
• Criptare pentru confidențialitatea datelor
• Verificări de integritate pentru a verifica dacă datele nu au fost modificate
• Stabilirea unui ID de sesiune care poate fi utilizat în celelalte protocoale

protocolul de transport autentifică doar serverul și nu clientul (autentificarea clientului se face în protocolul de autentificare, dacă este necesar).

În stratul de transport, conexiunea este inițiată de client și cele două părți negociază modul în care vor fi schimbate cheile, ce algoritm de cheie publică va fi utilizat, ce cifră cu cheie simetrică va cripta datele, ce algoritm de autentificare a mesajului va fi utilizat pentru a verifica datele și ce metodă de compresie (dacă există) va fi implementată.

Odată ce conexiunea începe, atât serverul cât și clientul trebuie să trimită printr-un șir de identificare, care include versiunea de protocol (2.0).

Negocierea algoritmului

Pentru a configura parametrii conexiunii, ambele părți trimit printr-un pachet care conține o listă cu următoarele opțiuni:

octet SSH_MSG_KEXINIT

byte [16] cookie (octeți aleatori)
chex_algorithms listă de nume
server de listă de nume_host_key_algoritmi
nume-listă encryption_algorithms_client_to_server
nume-lista encryption_algorithms_server_to_client
nume-listă mac_algorithms_client_to_server
nume-listă mac_algorithms_server_to_client
nume de listă compresie_algoritme_client_to_server
nume de listă compresie_algoritmele_server_to_clientului
limbi de listă de nume_client_to_server
limbi de listă de nume_server_to_client
booleanul primul_kex_packet_follows
uint32 0 (rezervat pentru extinderea viitoare)

Fiecare parte listează parametrii pe care sunt dispuși să le accepte în conexiune, separați prin virgule. Algoritmul preferat ar trebui să fie listat mai întâi.

Pentru schimb de chei (kex_algorithms), primul algoritm pe care ambele părți îl acceptă va fi ales pentru conexiune (pot exista și alți factori care trebuie îndepliniți, în funcție de algoritmul ales). Dacă cele două părți nu pot găsi un algoritm suportat reciproc care să satisfacă aceste cerințe, atunci conexiunea eșuează.

Algoritmi cheie gazdă server sunt algoritmii acceptati pentru cheia gazda serverului. Serverul prezintă algoritmii pentru care are chei gazdă, în timp ce clientul specifică algoritmii pe care este pregătit să-i accepte. Selecția va depinde dacă metoda de schimb de chei care a fost soluționată necesită o cheie gazdă capabilă să cripteze sau o semnătură digitală

Ambele părți prezintă lista algoritmi cu cheie simetrică că sunt dispuși să accepte, cu metodele preferate în vârf. Trebuie utilizată prima opțiune care apare pe lista clientului care se întâmplă să fie și pe lista serverului. Dacă nu se poate face niciun acord, conexiunea nu reușește.

Amandoua Algoritmul MAC si algoritm de compresie sunt negociate în aceeași manieră.

Schimb de chei

Schimbul de chei este responsabil pentru autentificare server, si el stabilește tastele care vor fi utilizate pentru a asigura conexiunea în etapele următoare. În general, începe cu părțile să-și trimită listele cu algoritmi susținuți unul altuia. În mod alternativ, fiecare parte poate ghici algoritmul preferat de cealaltă parte și trimite un pachet care se potrivește cu parametrii algoritmului respectiv la început.

Dacă presupunerea unei părți este corectă, acel pachet este folosit ca prim pachet de schimb de chei. Dacă nici una dintre presupuneri nu este corectă, atunci fiecare parte trebuie să facă un pas înapoi și să trimită listele lor de algoritmi preferați. Dacă mesajul de schimb de chei include semnătura digitală a serverului ca dovadă a legitimității serverului, se ia în considerare autentificare explicită a serverului. Dacă utilizează în schimb secretul partajat, acesta este denumit autentificare implicită a serverului.

Schimbul de chei este, de asemenea, responsabil pentru stabilirea unui secret comun și a unui hash. Valoarea hash din schimbul de chei inițial devine identificatorul unic pentru sesiune și este, de asemenea, utilizată ca parte a semnăturilor digitale care dovedesc că partidul este adevăratul proprietar al cheii sale private.

Funcția de hash folosită va depinde de metoda de schimb cheie decisă în negociere. Când schimbul de chei este finalizat, toate comunicațiile viitoare vor folosi noul set de chei și algoritmi.

Conform unei Schițe de Internet Engineering Task Force (IETF), următoarele metode cheie de schimb sunt considerate sigure:

• curve25519-SHA256
• curve448-SHA512
• Diffie-Hellman-group-exchange-SHA256
• Diffie-Hellman-group14-SHA256
• Diffie-Hellman-group15-SHA512
• Diffie-Hellman-group16-SHA512
• Diffie-Hellman-group17-SHA512
• Diffie-Hellman-group18-SHA512
• ECDH-SHA-2-nistp256
• ECDH-SHA-2-nistp384
• GSS-group14-SHA256
• GSS-group15-SHA512
• GSS-group16-SHA512
• GSS-group17-SHA512
• GSS-group18-SHA512
• GSS-nistp256-SHA256
• GSS-nistp384-sha384
• GSS-nistp521-SHA512
• GSS-curve25519-SHA256
• GSS-curve448-SHA512
• rsa2048-SHA256

Algoritmul cheii de gazdă a serverului

Aceste algoritmi cu cheie publică sunt utilizate pentru autentificarea serverului, precum și stabilirea sigură a ID-ului de sesiune partajat. De asemenea, pot fi utilizate opțional pentru autentificarea gazdei. SSH este proiectat să funcționeze cu o serie de algoritmi de chei publice, tipuri și formate de codificare:

• Utilizează algoritmi de chei publice pentru criptare și / sau semnături digitale.
• Poate fi implementată o serie de metode de codificare, care să permită configurarea cu diferite formate de date, umplere și ordine de octeți.
• Diferite formate de chei permit codarea tastelor în diferite moduri, precum și o serie de reprezentări ale certificatelor.

Algoritmii implicite includ următoarele, însă există și alte variații care pot fi de asemenea implementate:

• ssh-rsa
• ssh-rsa-SHA256
• ssh-dss
• ssh-dss-SHA256
• X509v3-sign-DSS
• X509v3-sign-DSS-SHA256
• X509v3-sign-rsa
• X509v3-sign-rsa-SHA256

Algoritmi de criptare

Se folosesc algoritmi cu cheie simetrică criptați datele și oferiți confidențialitate. Parametrii și cheia partajată care sunt utilizate în procesul de criptare sunt stabilite în fazele anterioare ale conexiunii. Algoritmul ales criptează sarcina utilă, lungimea pachetului, lungimea de umplere și câmpurile de umplutură.

O serie de algoritmi de criptare diferiți sunt acceptate în SSH, dar pentru securitate, cel mai bine este să rămâneți cu AES. Tastele trebuie să aibă minimum 128 biți, dar sunt preferate tastele mai mari.

Algoritmi MAC

Protocolul de transport verifică integritatea datelor prin adăugarea unui pachet de cod de autentificare a mesajelor (MAC). Acest MAC se bazează pe secretul comun (care este stabilit în schimbul de chei), numărul secvenței de pachete și conținutul pachetului. Se calculează înainte să aibă loc criptarea.

Implementările trebuie să ofere un algoritm independent pentru a rula în fiecare direcție, deși este ideal dacă același este folosit pe ambele părți. Poate fi implementată o mare varietate de algoritmi de autentificare a mesajelor, cu toate acestea SHA-256 și mai sus ar trebui să fie utilizate în majoritatea situațiilor pentru a asigura un nivel ridicat de securitate.

Comprimare

Compresia nu este obligatorie în protocolul SSH, iar implementările sale trebuie să permită conexiunilor să continue fără compresie. Compresia nu poate fi implementată decât ca opțiune, folosind scheme precum zlib. Dacă se utilizează compresie, aceasta afectează numai sarcina utilă. MAC și câmpul lungimea pachetului sunt apoi calculate pe baza sarcinii utile comprimate.

Transport pachet protocol

Pachetul de protocol de transport este formatat pentru a include următoarele informații (precum și unele detalii mai puțin pertinente care au fost lăsate în afara):

• Lungimea pachetului
• Lungimea căptușelii
• Sarcina utilă
• umplutură
• Un cod de autentificare a mesajelor (MAC)

Protocol de autentificare

Acest protocol este folosit de server pentru autentificați clientul. Poate face acest lucru cu o varietate de mecanisme diferite, multe dintre care se bazează pe ID-ul de sesiune stabilit în protocolul de transport. Unii utilizează verificările de criptare și integritate din protocolul de transport împreună cu ID-ul sesiunii, în timp ce alții folosesc acești algoritmi.

Serverul folosește politica sa locală pentru a decide ce metode de autentificare acceptă de la un utilizator individual. Deoarece serverul a fost deja autentificat în protocolul de transport, nu este necesară autentificarea serverului încă o dată.

Securitatea protocolului de autentificare depinde de protocolul de transport pe care îl parcurge. Dacă protocolul de transport nu poate garanta confidențialitatea sau verifică integritatea datelor, atunci aceasta limitează modul în care protocolul de autentificare poate fi utilizat în siguranță.

De exemplu, în cazul în care protecția integrității nu este aplicată prin protocolul de transport, atunci cererile precum schimbările de parole nu ar trebui să fie permise, deoarece acest lucru ar lăsa oportunitățile atacatorilor să modifice datele fără a fi observate.

Protocolul de autentificare folosește autentificarea cu cheie publică, în ipoteza că nici cheia privată a gazdei serverului, nici cheia gazdei client nu au fost compromise.. Dacă serverul a fost compromis, acest lucru poate duce la eliberarea utilizatorului și a parolei clientului către atacator.

Pentru ca autentificarea bazată pe gazdă să fie sigură, clientul nu trebuie compromis. Dacă aceasta este o posibilitate, atunci trebuie adăugate alte metode de autentificare. Este important să rețineți asta procesul de autentificare este la fel de puternic ca cea mai slabă metodă de schimb pe care o acceptă un server.

Procesul protocolului de autentificare

Protocolul de autentificare începe atunci când serverul trimite clientului o listă a metodelor sale de autentificare acceptate. Clientul poate apoi alege dintre aceste metode în orice ordine. Acest proces oferă control serverului, dar permite și suficientă flexibilitate, astfel încât clientul să poată aranja să utilizeze cea mai convenabilă metodă.

Cele mai frecvente metode de autentificare a clientului includ:

• Cheia publică – Această metodă folosește algoritmi precum RSA, DSA și ECDSA pentru a autentifica clientul prin intermediul criptografiei cu cheie publică. Unele implementări folosesc și certificate x.509. Serverul verifică semnătura digitală a clientului pe baza cheii sale publice pentru a verifica identitatea clientului.
• Parola – Parolele pot fi de asemenea utilizate pentru autentificarea clientului. Clientul trimite prin parola sa (care ar trebui să fie criptată prin protocolul de transport). Dacă parola se potrivește cu valoarea stocată a serverului, aceasta este acceptată și autentificarea merge mai departe.
• GSSAPI – În cadrul acestei metode, se pot folosi scheme externe, precum Kerberos, pentru conectare unică.
• Tastatură interactivă – Această tehnică furnizează o singură dată autentificarea prin parolă prin solicitarea serverului de către client a informațiilor.

Protocol de conectare

Protocolul de conexiune este stabilit modul în care mai multe canale de date vor fi combinate pe stratul de transport sigur. De asemenea, se ocupă de parametrii care sunt folosiți pentru a accesa subsistemele sigure pe gazda serverului, precum și de redirecționare proxy și accesarea shell-urilor..

Protocolul de conexiune se află deasupra stratului de transport și a protocoalelor de autentificare. Permite executarea comenzii la distanță, precum și conexiunile X11 și TCP / IP transmise. Dacă fie serverul, fie clientul a fost compromis, atunci protocolul de conectare nu este securizat.

canale

Canalele sunt căile de comunicare de bază și pot fi deschise de oricare dintre părți. Canalele pot include sesiuni terminale, conexiuni transmise și alte forme de comunicare. Când există mai multe canale, acestea sunt multiplexate într-o singură conexiune.

Deschiderea canalelor

Fiecare canal este numerotat pe ambele capete, deși numerele pot fi diferite pe ambele părți. Când o parte solicită să deschidă un canal, acesta trimite numărul canalului său ca parte a mesajului, precum și informații despre dimensiunea inițială a ferestrei si dimensiunea maximă a pachetului.

Mărimea inițială a ferestrei indică câte date poate primi partea care deschide canalul. Dacă trebuie trimise mai multe date, fereastra trebuie mai întâi ajustată. De asemenea, dimensiunea maximă a pachetului specifică cât de mare poate fi primit un pachet.

Când o parte solicită să fie deschis un canal, cealaltă parte va deschide canalul dacă îl poate găzdui. Dacă nu, acesta va trimite printr-un mesaj de eșec. Canalele nu pot fi deschise din următoarele motive:

• Interzis de administrație
• Conexiune eșuată
• Tip de canal necunoscut
• Lipsa resurselor

Dacă oricare dintre părțile conexiunii dorește să trimită mai multe date decât permite fereastra în prezent, pot trimite un mesaj care solicită adăugarea mai multor octeți.

Închiderea canalelor

Odată ce o parte a unei conexiuni și-a încheiat transmisia de date, ar trebui să trimită un mesaj care să indice că a terminat de utilizat canalul. În ciuda acestui fapt, canalul este menținut deschis, iar datele pot fi trimise în continuare de către cealaltă parte. Dacă o parte dorește să încheie complet canalul, o face cu un mesaj de reziliere separat.

Securitate SSH

Diferitele versiuni ale SSH au avut fiecare propriile probleme de securitate, deși configurațiile actuale SSH-2 și OpenSSH sunt considerate mult mai sigure decât SSH-1.

SSH-1

SSH-1 este în general considerat a fi defect, cu o serie de vulnerabilități diferite. Acestea includ o eroare în SSH 1.5 care a permis utilizatorilor neautorizați să insereze conținut în fluxul de date SSH. Acest atac a profitat de protecția minimă a integrității datelor algoritmului CRC-32.

Acest atac a fost atenuat cu detectorul de atac SSH Compensation Attack, care a fost integrat în majoritatea implementărilor mai noi. Această soluție a venit cu o nouă vulnerabilitate, care a avut puterea de a executa cod arbitrar cu privilegii root.

Există, de asemenea, o vulnerabilitate care permite adversarilor să schimbe ultimul bloc dintr-o sesiune care folosește criptarea IDEA, precum și unul care permite unui server compromis să redirecționeze procesul de autentificare a clientului către un server diferit.

Din cauza acestor probleme de securitate, SSH-2 trebuie utilizat în schimb. Pentru a vă asigura implementarea sigură, ar trebui, de asemenea dezactivează renegocierea la SSH-1, deoarece atacurile pot profita de acest lucru pentru a accesa datele dvs. prin nivelul mai slab de protecție al SSH-1.

SSH 2

SSH-2 este vulnerabil la un atac teoretic împotriva modului său de criptare implicit, CBC. Permite atacatorului să recupereze până la 32 de biți din textul complet dintr-un bloc criptat. Acest lucru poate fi atenuat folosind modul Counter (CTR) și transformând în loc cifrarea blocului într-o cifră de flux.

La sfârșitul anului 2014, Der Spiegel a lansat documente NSA care presupuneau că NSA poate uneori rupe SSH. Acest filtru NSA PowerPoint precizează că NSA poate „Recuperați eventual numele de utilizator și parolele”, Deși nu se oferă alte detalii. Nu se știe ce metode a folosit agenția pentru a face acest lucru, dar pare puțin probabil să se bazeze despre capacitățile sale în propria documentație internă.

În scurgerea Vault 7 din [year], a fost dezvăluit că CIA avea două instrumente care ar putea fi folosite pentru a intercepta și a fura autentificările SSH și parolele. BothanSpy a vizat clienții Windows Xshell, în timp ce Gyrfalcon a fost folosit împotriva clientului OpenSSH pe o serie de distribuții Linux diferite.

Aceste instrumente sunt capabile să fure acreditările și apoi să le transmită înapoi la un server CIA. Nici unul dintre aceste atacuri nu poate rupe protocolul în sine; ei folosesc doar alte atacuri de canale laterale care pot fi ocolite în anumite implementări.

În ciuda acestor atacuri, SSH-2 este considerat sigur în majoritatea situațiilor, atât timp cât este implementat în mod corespunzător. Ținte de mare valoare sau cei care utilizează implementări depășite sau slabe ar trebui să ia în considerare alte opțiuni.

OpenSSH

În versiunea 2 a OpenSSH, a fost descoperit un atac care a profitat de o slăbiciune în pachetul binar SSH. Atacul a permis cercetătorilor de la Universitatea din Londra să recupereze 14 biți din textul de pe un bloc criptat. Acest lucru a fost atenuat în versiunea 5.2, făcând protocolul să citească integralitatea unei lungimi de pachet nevalide sau a unui cod de autentificare a mesajului, în loc să încheie conexiunea.

În versiunile 6.8 și 6.9, Linux ar putea fi utilizat pentru a executa comenzi arbitrare pe terminalele altor utilizatori. Acest lucru a fost realizat printr-o vulnerabilitate de escaladare a privilegiilor care a permis atacatorilor să injecteze caractere cu controlul de intrare / ieșire TIOCSTI.

Este SSH în siguranță?

Deși poate părea că SSH are o mulțime de probleme de securitate, este relativleste normal să se regăsească o serie de vulnerabilități în diferitele implementări ale unui protocol. Aceasta nu înseamnă că protocolul SSH este nesigur. În schimb, înseamnă doar asta trebuie implementat corect.

Atâta timp cât folosești SSH-2 sau OpenSSH și este configurat într-un mod adecvat pentru utilizarea dvs., ar trebui să vă simțiți încrezători în protecția oferită de SSH pentru conexiunea dvs.. Acesta este motivul pentru care este încă un protocol utilizat frecvent, în special pentru acces la distanță și tunelare.

Vedeți și: Tipurile de criptare comune explicate

Istoric tehnologic rețea cyber de TheDigitalArtist licențiat sub CC0