<<TableOfContents: execution failed „] (vezi și jurnalul)>>
OpenSSH (sau Secure SHell) a devenit un standard de facto pentru accesul la distanță, înlocuind protocolul telnet. SSH a făcut ca protocoale precum telnet să devină redundante datorită, în cea mai mare parte, faptului că conexiunea este criptată și că parolele nu mai sunt trimise în text simplu pentru a fi văzute de toată lumea.
Cu toate acestea, o instalare implicită a ssh nu este perfectă, iar atunci când se execută un server ssh există câțiva pași simpli care pot întări în mod dramatic o instalare.
Utilizați parole/ nume de utilizator puternice
Unul dintre primele lucruri pe care le veți observa dacă aveți ssh în funcțiune și expus lumii exterioare este că veți înregistra probabil încercări ale hackerilor de a vă ghici numele de utilizator/parola. De obicei, un hacker va scana portul 22 (portul implicit pe care ascultă ssh) pentru a găsi mașinile cu ssh în funcțiune și apoi va încerca un atac prin forță brută împotriva acestuia. Cu ajutorul unor parole puternice, să sperăm că orice atac va fi înregistrat și observat înainte de a reuși.
Sperăm că folosiți deja parole puternice, dar dacă nu o faceți atunci încercați să alegeți parole care să conțină:
- Minimum 8 caractere
- Mix de litere majuscule și minuscule
- Mix de litere și cifre
- Caractere nealfanumerice (de exemplu, caractere speciale cum ar fi ! ” £ £ $ % ^ etc.)
Beneficiile parolelor puternice nu sunt specifice pentru ssh, ci au un impact asupra tuturor aspectelor securității sistemelor. Informații suplimentare despre parole pot fi găsite în documentația CentOS:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Dacă nu puteți absolut deloc să vă împiedicați utilizatorii să aleagă parole slabe, luați în considerare utilizarea de nume de utilizator generate aleatoriu sau greu de ghicit pentru conturile de utilizator. Dacă băieții răi nu pot ghici numele de utilizator, atunci nu pot folosi forțarea brută a parolei. Cu toate acestea, este vorba tot de securitate prin obscuritate și trebuie să fiți conștienți de scurgerile de informații ale numelor de utilizator, cum ar fi e-mailurile trimise de la conturile de utilizator.
Disable Root Logins
Setările serverului SSH sunt stocate în fișierul /etc/ssh/sshd_config. Pentru a dezactiva logările root, asigurați-vă că aveți următoarea intrare:
# Prevent root logins:PermitRootLogin no
și reporniți serviciul sshd:
service sshd restart
Dacă aveți nevoie de acces root, conectați-vă ca utilizator normal și utilizați comanda su.
Limitați intrările utilizatorilor
Intrările SSH pot fi limitate doar la anumiți utilizatori care au nevoie de acces la distanță. Dacă aveți multe conturi de utilizator pe sistem, atunci are sens să limitați accesul de la distanță doar la cei care au cu adevărat nevoie de el, limitând astfel impactul unui utilizator ocazional care are o parolă slabă. Adăugați în /etc/ssh/sshd_config o linie AllowUsers urmată de o listă de nume de utilizatori separate prin spații, de exemplu:
AllowUsers alice bob
și reporniți serviciul sshd.
Disable Protocol 1
SSH are două protocoale pe care le poate utiliza, protocolul 1 și protocolul 2. Protocolul 1, mai vechi, este mai puțin sigur și ar trebui să fie dezactivat, cu excepția cazului în care știți că aveți nevoie de el în mod specific. Căutați următoarea linie în fișierul /etc/ssh/sshd_config, decomentați-o și modificați-o după cum se arată:
# Protocol 2,1Protocol 2
și reporniți serviciul sshd.
Utilizați un port non-standard
În mod implicit, ssh ascultă conexiunile primite pe portul 22. Pentru ca un hacker să determine că ssh rulează pe mașina dumneavoastră, cel mai probabil va scana portul 22 pentru a determina acest lucru. O metodă eficientă este de a rula ssh pe un port non-standard. Orice port nefolosit este suficient, deși este de preferat unul peste 1024. Mulți oameni aleg 2222 ca port alternativ (deoarece este ușor de reținut), la fel cum 8080 este adesea cunoscut ca fiind portul HTTP alternativ. Tocmai din acest motiv, probabil că nu este cea mai bună alegere, deoarece orice hacker care scanează portul 22 va scana probabil și portul 2222, ca să fie o măsură bună. Este mai bine să alegeți un port înalt la întâmplare care nu este folosit pentru niciun serviciu cunoscut. Pentru a face această modificare, adăugați o linie ca aceasta în fișierul /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
și reporniți serviciul sshd. Nu uitați să faceți apoi toate modificările necesare la redirecționarea porturilor în router și la orice reguli de firewall aplicabile. De exemplu, pe CentOS 7 (și versiunile ulterioare), puteți modifica serviciul ssh al firewalld făcând un duplicat al fișierului său de servicii în /etc/firewalld/ și schimbând linia portului său:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Apoi schimbați linia portului din /etc/firewalld/services/ssh-custom.xml astfel încât portul să fie același cu cel din fișierul de configurare ssh:
<port protocol="tcp" port="2345"/>
În cele din urmă, eliminați serviciul ssh, adăugați serviciul ssh-custom și reîncărcați firewalld pentru ca modificarea să aibă efect:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Sau, pe CentOS 6, adăugați o regulă iptable pentru a deschide noul port ssh:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Nu uitați să închideți și vechiul port.
Pe CentOS 6 și mai sus ar trebui, de asemenea, să actualizați selinux, etichetând corect portul ales, altfel sshd va fi împiedicat să îl acceseze. De exemplu:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Pentru că ssh nu mai ascultă conexiuni pe portul standard, va trebui să spuneți clientului dumneavoastră pe ce port să se conecteze. Utilizând clientul ssh din linia de comandă, putem specifica portul folosind comutatorul -p:
$ ssh -p 2345 myserver
sau dacă folosiți protocolul fish în konqueror, de exemplu:
fish://myserver:2345/remote/dir
Dacă vă gândiți că acest lucru sună ca o pacoste, trebuind să specificați portul de fiecare dată când vă conectați, pur și simplu adăugați o intrare care să specifice portul în fișierul local ~/.ssh/config:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Și fișierul: ~/.ssh/config trebuie să aibă următoarele permisiuni:
$ chmod 600 ~/.ssh/config
Filtrează SSH la firewall
Dacă aveți nevoie doar de acces la distanță de la o singură adresă IP (de exemplu, de la locul de muncă la serverul de acasă), luați în considerare filtrarea conexiunilor la firewall fie prin adăugarea unei reguli de firewall pe router sau în iptables pentru a limita accesul pe portul 22 doar la acea adresă IP specifică. De exemplu, în iptables, acest lucru ar putea fi realizat cu următorul tip de regulă pentru iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
sau folosind firwalld (CentOS 7) folosiți rich-rules pentru a permite ssh doar pe un anumit port. Adresa sursă poate fi o singură adresă sau o adresă de bază cu o mască de biți:
SSH suportă, de asemenea, în mod nativ wrappers TCP și accesul la serviciul ssh poate fi controlat în mod similar folosind hosts.allow și hosts.deny.
Dacă nu sunteți în măsură să limitați adresele IP sursă și trebuie să deschideți portul ssh la nivel global, atunci iptables poate ajuta în continuare la prevenirea atacurilor de forță brută prin înregistrarea și blocarea încercărilor repetate de conectare de la aceeași adresă IP. De exemplu, cu iptables
Prima regulă înregistrează adresa IP a fiecărei noi încercări de accesare a portului 22 folosind modulul recent. A doua regulă verifică dacă acea adresă IP a încercat să se conecteze de 4 sau mai multe ori în ultimele 60 de secunde, iar dacă nu, atunci pachetul este acceptat. Rețineți că această regulă ar necesita o politică implicită de DROP pe lanțul de intrare.
Nu uitați să modificați portul în mod corespunzător dacă rulați ssh pe un port non-standard. Acolo unde este posibil, filtrarea la nivelul firewall-ului este o metodă extrem de eficientă de securizare a accesului la un server ssh.
Pentru sistemele care utilizează serviciul FirewallD (CentOS 7 sau superior), utilizați firewall-cmd:
Prima comandă elimină regula mai permisivă a serviciului, a doua instaurează o regulă pentru a accepta doar 4 conexiuni într-un minut și înregistrează toate conexiunile.
Utilizați chei publice/private pentru autentificare
Utilizarea cheilor criptate pentru autentificare oferă două avantaje principale. În primul rând, este comodă, deoarece nu mai este nevoie să introduceți o parolă (cu excepția cazului în care criptați cheile cu protecție prin parolă) dacă utilizați chei publice/private. În al doilea rând, odată ce autentificarea cu pereche de chei publice/private a fost configurată pe server, puteți dezactiva complet autentificarea prin parolă, ceea ce înseamnă că fără o cheie autorizată nu puteți obține acces – deci nu mai există încercări de spargere a parolei.
Este un proces relativ simplu să creați o pereche de chei publice/private și să le instalați pentru a le utiliza pe serverul dvs. ssh.
În primul rând, creați o pereche de chei publice/private pe clientul pe care îl veți folosi pentru a vă conecta la server (va trebui să faceți acest lucru de pe fiecare mașină client de pe care vă conectați):
$ ssh-keygen -t rsa
Dacă nu doriți să vi se ceară în continuare o frază de trecere (care este practic o parolă pentru a debloca o anumită cheie publică) de fiecare dată când vă conectați, apăsați enter atunci când vi se cere o frază de trecere la crearea perechii de chei. Rămâne la latitudinea dvs. să decideți dacă doriți sau nu să adăugați criptarea de protecție a frazei de acces la cheia dvs. atunci când o creați. Dacă nu vă protejați cheia cu o frază de pasivitate, atunci oricine obține acces la computerul dvs. local va avea automat acces ssh la serverul de la distanță. De asemenea, root de pe mașina locală are acces la cheile dvs. deși se presupune că, dacă nu puteți avea încredere în root (sau root este compromis), atunci aveți probleme reale. Criptarea cheii adaugă o securitate suplimentară în detrimentul eliminării necesității de a introduce o parolă pentru serverul ssh, doar pentru a fi înlocuită cu introducerea unei fraze de acces pentru utilizarea cheii. Acest lucru poate fi simplificat și mai mult prin utilizarea programului ssh_agent
Acum setați permisiunile pentru cheia dvs. privată:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Copiați cheia publică (id_rsa.pub) pe server și instalați-o în lista authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Nota: după ce ați importat cheia publică, o puteți șterge de pe server.
și, în final, setați permisiunile fișierelor pe server:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Autorizațiile de mai sus sunt necesare dacă StrictModes este setat la yes în /etc/ssh/sshd_config (implicit).
Asigurați-vă că sunt setate contextele SELinux corecte:
$ restorecon -Rv ~/.ssh
Acum, când vă conectați la server, nu vi se va cere o parolă (cu excepția cazului în care ați introdus o frază de trecere când ați creat perechea de chei). În mod implicit, ssh va încerca mai întâi să se autentifice folosind chei. Dacă nu se găsește nicio cheie sau dacă autentificarea eșuează, ssh va reveni la autentificarea convențională cu parolă.
După ce ați verificat că vă puteți conecta cu succes la server folosind perechea dvs. de chei publice/private, puteți dezactiva complet autentificarea prin parolă adăugând următoarea setare în fișierul /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Întrebare frecventă (FAQ)
Q: CentOS utilizează versiunea X a OpenSSH, iar cea mai recentă versiune este versiunea Y. Versiunea X conținea un defect de securitate grav, ar trebui să o actualizez?
A: Nu. Furnizorul din amonte are o politică de backporting a patch-urilor de securitate din cele mai recente versiuni în versiunea curentă de distribuție. Atâta timp cât aveți cele mai recente actualizări aplicate pentru distribuția CentOS, sunteți complet protejat. Consultați aici pentru mai multe detalii despre backporting-ul patch-urilor de securitate:
http://www.redhat.com/advice/speaks_backport.html
Întrebare: Cum pot face ca ssh să permită autentificarea bazată pe cheie fără parolă între mașinile care împart directoarele personale ale utilizatorilor prin NFS?
A: SElinux blochează accesul root la directoarele și fișierele partajate prin NFS care nu pot fi citite la nivel mondial în mod implicit și astfel sshd nu poate citi fișierele de chei ale utilizatorilor din ~/.ssh. Pentru a permite accesul, modificați setarea use_nfs_home_dirs prin rularea următoarei comenzi ca superutilizator:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html
.