În ultima zi de Patch Tuesday, Microsoft a lansat actualizarea de securitate MS12-020 pentru a închide două defecte descoperite recent în implementarea de către Microsoft a RDP (Remote Desktop Protocol). Una dintre ele, Microsoft o cataloghează drept „critică” deoarece ar putea permite hackerilor să obțină controlul LocalSystem pe o boxă Windows cu RDP activat.
După cum probabil ați auzit până acum, aceasta este o situație de mare risc – una care ar putea duce la o epidemie la fel de gravă ca cea provocată de Code Red, Melissa sau SQL Slammer. Aplicați patch-uri sau remediați acum!
Microsoft vă va ajuta să le faceți pe amândouă. Puteți fie să instalați patch-ul, fie să rulați un script online Fix It pentru a atenua problema până la aplicarea patch-ului. Scriptul activează Network Level Authentication, care necesită autentificare înainte ca un sistem la distanță să se poată conecta.
Dar am un alt sfat. Așa cum recomand de mai bine de un deceniu, administratorii ar trebui să ia în considerare rularea serviciilor conectabile la Internet pe porturi care nu sunt predefinite, dacă este posibil. În acest caz particular, RDP ar trebui să fie rulat pe un alt port decât portul 3389.
Acest sfat se extinde și la alte domenii. Site-urile web de administrare nu ar trebui să fie rulate pe portul 80 sau chiar 443. SSH nu ar trebui să fie ascultat pe portul 22. Gazdele Telnet nu ar trebui să asculte pe portul 23. Singurul serviciu comun larg răspândit pe care nu am reușit să-l fac să funcționeze în mod fiabil pe un port care nu este implicit este FTP: folosește porturile 21 și 22 (în modul pasiv), și chiar și modul său activ (în care puteți indica alte porturi) nu funcționează bine prin firewall-uri.
În cazul RDP, puteți schimba portul implicit urmând aceste îndrumări. Totuși, atunci când schimbați portul implicit, trebuie să indicați portul care nu este implicit în șirul de conexiune (de exemplu, mstsc.exe 192.168.1.12:50045).
Recomandarea mea de a schimba portul de ascultare implicit pe un serviciu la nivelul întregii întreprinderi este adesea întâmpinată cu critici. Argumentul meu central este următorul: În cele mai multe cazuri, o întreprindere poate schimba portul de ascultare implicit, ceea ce nu cauzează probleme dincolo de educația administratorilor și reconfigurarea unică a unor scripturi și instrumente, și diminuează în mod semnificativ riscul de atac armat.
Deși hackerii și programele malware pot folosi un scaner de porturi precum Nmap pentru a găsi noul port, niciun exploit armat nu a făcut vreodată scanarea porturilor, deși ar putea cu ușurință. Doar acest fapt vă oferă o mulțime de protecție.
Câteva persoane numesc acest tip de recomandare „securitate prin obscuritate”, ca și cum ar fi un lucru rău. Dacă mă întrebați pe mine, securitatea prin obscuritate este una dintre cele mai bune apărări. Altfel, fiecare națiune ar face public locul unde se află rachetele și submarinele sale nucleare, în loc să țină informația secretă.
Pentru mine, viermele SQL Slammer este unul dintre cele mai bune argumente pentru a pune serviciile comune pe porturi nondefault. Lansat în 2003, acesta a exploatat în 10 minute aproape toate serverele SQL posibile, neprotejate și fără patch-uri, conectate la internet. S-a declanșat devreme într-o duminică dimineața, iar până când majoritatea administratorilor s-au trezit, pagubele se produseseră deja de aproape o zi întreagă de lucru.
În principiu, până când ne-am șters sarea încrustată de pe ochi, se terminase – apoi ne-am petrecut următoarele 48 de ore (sau mai mult) încercând să curățăm mizeria. A fost un semnal de alarmă.
Nimeni dintre cei care au activat SQL pe un port nondefault (adică un port în afară de 1433 și 1434) nu a trebuit să facă nimic — în afară de a privi cu calm cum ceilalți se ocupă de dezastrele lor. Cei care au schimbat porturile nu au fost nevoiți să curețe o mizerie imensă. Nu au trebuit să se grăbească să lanseze patch-uri. Nu au avut servere exploatate. O singură schimbare cu un impact operațional minim și au putut evita tone de riscuri.
Cert este că și alte măsuri de atenuare funcționează la fel de bine, cum ar fi solicitarea unei conexiuni VPN valide înainte de conectarea la serviciu, solicitarea unei combinații de contacte anterioare ale portului înainte de a activa serviciul sau solicitarea unei autentificări reușite înainte ca serviciul să răspundă (aceasta este soluția Fix It de la Microsoft) și orice altceva care v-ar putea proteja împotriva atacurilor cu arme.
Dar nu mă pot gândi la nicio altă soluție simplă de securitate care să diminueze riscul atât de eficient decât schimbarea portului implicit, atunci când este posibil. Dacă urmați acest sfat, mutați portul la un număr destul de mare, peste 10.000 sau 12.000, pentru a evita eventualele conflicte de porturi cu alte servicii existente. Testați toate echipamentele de producție și actualizați toate firewall-urile sau proxy-urile necesare. Cititorii care au urmat acest sfat în trecut nu se grăbesc prea tare în această săptămână.
.