Nivelul de securitate a informațiilor sistemelor corporative de astăzi a crescut în mod semnificativ, iar erorile tipice sunt din ce în ce mai rare - administratorii instalați în mod regulat actualizări și să pună în aplicare cerințele politicii parolei pe servere Windows, efectuați cerințele de control al accesului pe segmentul de echipamente de rețea a rețelei. Cu toate acestea, există o serie de probleme care nu au fost încă date din cauza atenție, iar unul dintre ei - securitatea sistemelor corporative de gestionare a bazelor de date. În acest articol vreau să analizez vulnerabilitățile cele mai critice prin exemplul sistemelor construite pe baza de date Oracle.
Accesați serverul devine destul de dificil cu instalate cele mai recente actualizări de securitate și parole puternice, astfel încât vectorii de atac sunt deplasate astăzi spre aplicații, dintre care cele mai importante sunt baza de date, cu atât mai mult acest tip de informații în baze de date este de multe ori scopul final al atacatorului . Baza de date Oracle este unul dintre cele mai comune sisteme din mediul enterprise, deci a fost ales ca exemplu, sau mai degrabă Oracle Database 9i și 10g. Luați în considerare numărul de vulnerabilități critice care pot fi exploatate fără a avea drepturi de acces logic la baza de date Oracle.
Accesul de la distanță la baza de date furnizează serviciul Oracle TNS Ascultător rulează pe implicit TCP-portul 1521, iar majoritatea atacurilor vizează în mod specific serviciului. Listener - componenta de acces la rețea Oracle Systems, clientul primește cereri de conectare și le direcționează către procesul de server de procesare corespunzătoare. Ascultător este de obicei văzută ca primul pas spre invazia bazelor de date și alte servicii atât de prost configurate și listener nesigur infractorului diferitele posibilități de atacuri, inclusiv o execuție de comandă la distanță și de negare a serviciului.
În afara lacunelor
- obțineți informații detaliate despre sistemul atacat - numele bazei de date (SID), versiunea sa, calea către fișierele jurnal, versiunea sistemului de operare etc .;
- să lanseze un atac de negare a serviciului;
- executa comenzi SQL în numele administratorului bazei de date;
- obțineți acces de la distanță la sistem.
Toate aceste acțiuni pot fi efectuate utilizând utilitățile standard furnizate împreună cu baza de date (vezi ecranul 1) și numai în unele cazuri este posibil să aveți nevoie de scripturi suplimentare disponibile pe Internet.
Stația de așteptare 192.168.55.16
Toate acestea indică faptul că sistemul este nesigur când se utilizează setările implicite, iar atacatorul nu ar trebui să aibă alte instrumente software suplimentare decât cele standard.
Protecția perimetrului exterior
Pentru a proteja serviciul Listener, în fișierul LISTENER.ORA există următorii parametri:
- PASSWORDS_ (ascultător nume) = (ascultător_password) - un parametru care este responsabil pentru stabilirea unei parole pentru conectarea la Listener. După setarea parolei, utilizatorul nu va putea să oprească serviciul, precum și să efectueze atacuri legate de schimbarea numelui fișierului jurnal. Cu toate acestea, comenzile de stare și versiune sunt executate și vă permit să obțineți informații despre versiunea Listenerului, numele directorului de instalare și versiunea sistemului de operare.
- ADMIN_RESTRICTIONS_ (nume ascultător) - .. Un parametru care este pornit ADMIN_RESTRICTIONS_ (numele ascultătorul) = ON (implicit OFF) interzice orice modificare fișier de configurare de la distanță, de exemplu, schimbarea numelui directorului fișier jurnal este posibilă numai în cazul în care există acces local la dosar ascultător .ora
- LOCAL_OS_AUTHENTICATION_ (nume ascultător) - un parametru care este activată (dezactivată în mod implicit) vă permite să gestionați serviciul Listener doar la nivel local - în orice încercare de a efectua comenzi de la distanță vor primi un mesaj de eroare. Singura comandă care poate fi executată este versiunea, va scoate versiunea bazei de date instalate Oracle și versiunea sistemului de operare. În versiunea de Oracle 10g R1 și peste Ascultător protejat prin parametrul LOCAL_OS_AUTHENT instalarea la ON în mod implicit, care vă permite să controlați doar sistemul local, însă, și previne o serie de atacuri, dar încă permite accesul la gestionarea serviciului Listener în prezența oricărui cont neprivilegiați înregistrări pe server. Din perspectiva unui sistem mai larg de administrare, de preferință, să fie în continuare posibilitatea de a administra de la distanță Ascultător, atât de mulți administratori dezactiva LOCAL_OS_AUTHENT, care afectează imediat securitatea bazei de date.
Un exemplu de rulare a utilitarului Oracle 10g cu setările implicite poate fi văzut pe ecranul 2. După cum puteți vedea, setările implicite în Oracle 10g sunt mai sigure decât Oracle 9, dar au încă un număr de dezavantaje.
Conectarea la baza de date
Dacă utilizați protecția prin parola Listener, există încă câteva moduri de a obține numele bazei de date (SID):
Astfel, chiar și fără acces la Listener, se poate găsi SID-ul bazei de date - practica arată că în 90% din cazuri, într-un fel sau altul, SID-ul bazei de date a fost obținut.
După ce a primit SID-ul bazei de date sau prin detectarea unui port Listener neprotejat, un atacator poate încerca să acceseze baza de date selectând conturi de utilizator. Oracle în timpul instalării creează multe conturi de sistem cu parole standard. În mod obișnuit, atunci când instalați în mod implicit folosind Asistentul de configurare a bazei de date după un proces de succes, majoritatea acestor conturi sunt blocate automat. Cu toate acestea, în cazul în care baza de date este configurat manual, sau pentru orice motiv, instalarea este finalizată în mod corespunzător, conturile sunt încă deschise, iar administratorii tind să uitați să le ștergeți, dezactivați, sau cel puțin pentru a schimba parolele lor. De exemplu, atunci când instalați Oracle bază de date 9 program de instalare R2 vă solicită o nouă parolă pentru conturile de utilizator SYS și de sistem, dar parolele de cont DBSNMP și SCOTT (versiunea 9 se adaugă R1 pentru a le OUTLN) la setarea standard neschimbată, iar aceste conturi Nu blocați după instalare.
Când instalați Oracle 10g R1, programul de instalare solicită parole noi pentru conturi: SYS, SYSTEM, DBSNMP și SYSMAN. Restul intrărilor sunt blocate în mod prestabilit, ceea ce asigură o configurație sigură.
În ceea ce privește ultima versiune de Oracle 11g. acesta are din nou conturi cu parole implicite care nu sunt blocate: DIP, MGMT_VIEW, SYS, SYSMAN, SYSTEM.
În plus față de conturile standard de mai sus, există mai multe aplicații, cum ar fi sistemele Oracle si SAP, care sunt integrate cu baza de date; ei au propriile lor conturi de sistem standard, care, de asemenea, pot fi folosite pentru a penetra sistemul. Lista de conturi de utilizator standard include aproximativ 600 de nume și este disponibil pe Web (www.petefinnigan.com/default/default_password_list.htm). Pentru a verifica baza de date pentru conturile cu parole setate în mod implicit, puteți utiliza utilitarul oscanner, care poate verifica o listă dată de conturi standard. Exemplu de funcționare utilitate oscanner pentru a verifica versiunea instalată a Oracle 9 R2 este prezentat în figura 3. Aici vedem că utilizator DBSNMP, SCOTT, SYS și SYSTEM sunt parolele implicite, astfel încât orice atacator poate avea acces la distanta la baza de date.
Chiar dacă toate conturile de sistem neutilizate sunt șterse sau blocate și parolele standard sunt modificate, nimic nu împiedică un atacator să utilizeze parolele în conturile de cont. Există mai multe puncte care fac căutarea parolelor pentru baza de date Oracle în unele cazuri reușită:
- multe nume de utilizator ale sistemului sunt cunoscute, ceea ce vă permite să selectați numai parole;
- în mod implicit, nu există restricții privind lungimea și complexitatea parolei;
- Parola nu este blocată implicit.
Problema politicii de parole se aplică și altor baze de date, aceasta este în continuare principala problemă a oricărui sistem. Practica arată că în 80% din cazuri căutarea parolelor se termină cu succes și rareori durează mai mult de 10-15 minute.
Securitatea internă a bazei de date Oracle
Spre deosebire de sistemul de operare în cazul în care procesul de actualizare nu cauzează dificultăți și a efectuat aproape în mod automat, cu Oracle, lucrurile sunt mult mai rău. În primul rând, actualizări vin rar, și în al doilea rând, încă instalarea lor este non-trivial și de multe ori provoca defecțiuni grave în cazul în care Oracle este utilizat în conjuncție cu orice sistem de terță parte pentru a lucra cu anumite versiuni ale Oracle. În cele din urmă, chiar dacă actualizările sunt instalate corect, aceasta încă nu oferă o garanție completă de securitate, deoarece, potrivit statisticilor, mai mult de jumătate din vulnerabilități rămân neînchise.
Principalele atacuri efectuate de utilizatorii bazei de date Oracle vizează sporirea privilegiilor acestora. Folosind vulnerabilitățile din funcțiile încorporate, un atacator poate efectua următoarele acțiuni:
- Pentru a ridica privilegiile în rolul de administrator;
- efectuați un atac de refuz al serviciului sau executați un cod arbitrar pe server;
- Citiți șirurile de parole ale utilizatorilor și încercați să le descifrați mai târziu;
- Schimbați parolele pentru conturile de utilizatori, inclusiv administratorii;
- fișiere de sistem de acces;
- accesați linia de comandă a serverului.
Toate aceste capacități necesită cunoștințe și software suplimentare, însă sunt foarte populare și au apărut în aproape toate sistemele bazate pe Oracle. Și, având în vedere că, în Windows, baza de date Oracle rulează implicit în numele contului de administrator, accesarea liniei de comandă a serverului prin procedurile interne Oracle amenință să obțină acces administrativ la sistemul de operare cu toate consecințele care decurg din acesta. Prezența vulnerabilităților interne de un grad ridicat de critică, împreună cu erorile de configurare și parolele slabe, reprezintă o adevărată amenințare la adresa securității companiei.
Recomandări pentru protecție
Iată câteva recomandări necesare pentru a îmbunătăți nivelul securității Oracle, multe dintre acestea fiind aplicabile altor baze de date.
1. La instalarea sistemului într-un mediu de lucru:
- setați numai componentele necesare pentru procesul de afaceri. Nu instalați scheme de eșantioane de testare;
- Schimbați parolele în conturile administrative SYS și SYTEM pentru acelea care îndeplinesc cerințele de securitate;
- atunci când alegeți nume de baze de date (SID), folosiți nume care constau din cel puțin opt caractere, inclusiv litere și caractere speciale, dar nu același lucru cu numele gazdei din DNS sau Netbios;
- instalați cele mai recente actualizări critice înainte de punerea în funcțiune a sistemului.
2. La configurarea sistemului după instalare:
- crearea unui cont de utilizator în sistemul de operare în numele căruia va fi lansată baza de date Oracle, stabilirea unei parole puternice pentru aceasta și refuzarea privilegiilor sale administrative;
- setați parola pentru a accesa serviciul Listener. Utilizarea LOCAL_OS_AUTHENT nu este recomandată, deoarece nu protejează accesul local la serviciu și complică administrarea de la distanță (a se vedea Lista 1);
- Activați înregistrarea tuturor încercărilor de conectare la Listener pentru a detecta încercările de parolă (consultați Lista 2);
- cât mai mult posibil să restricționeze accesul la fișierele de configurare locale tnsnames.ora, lăsând dreptul de a citi numai utilizatorul în numele căruia este pornită baza de date, deoarece parola pentru conectarea la Listener este stocată în fișierul de configurare;
- Limitați accesul la aplicații prin intermediul cărora puteți afla SID-ul sau puteți modifica informațiile afișate de aceste aplicații;
- Dezactivați conturile neutilizate și schimbați parolele pentru conturile implicite;
- introduceți atât restricții administrative, cât și restricții software referitoare la lungimea și complexitatea parolei. Acest lucru se poate face programabil prin setarea profilurilor utilizatorilor în baza de date Oracle. Principalii parametri de profil care afectează securitatea poate fi configurat prin modificarea parametrilor, cum ar fi FAILED_LOGIN_ATTEMPTS (numărul de încercări nereușite de login), PASSWORD_LIFE_TIME (parola de expirare, se recomandă să se schimbe o dată la două luni), PASSWORD_VERIFY_FUNCTION (numele funcției pentru a verifica lungimea parolei și complexitatea) .
Exemplu de setare a numărului de încercări de conectare eșuate de cinci:
modificați profilul DEFAULT
limita FAILED_LOGIN_ATTEMPTS 5;
modificați utilizatorul SCOTT
profilul DEFAULT;
3. Verificări periodice:
Link-uri conexe
Articole similare
Trimiteți-le prietenilor: