Elementarz bezpieczeństwa, czyli najprostsze sposoby zabezpieczania bazy

Jadwiga Gnybek Jadwiga_Gnybek@nofer.lodz.pl

Bezpieczeństwo systemów informatycznych to temat-rzeka. Sprawa bowiem jest niezwykle ważna. Z jednej strony dlatego, że nasze bazy danych przechowują naprawdę cenne informacje, z drugiej zaś choćby dlatego, że pokusa złamania zabezpieczeń systemu jest kwestią honoru dla wielu młodych adeptów informatyki.

Tak więc realna konieczność ochrony informacji stawić musi czoła nie tylko popytowi na nielegalną ich dystrybucję, ale również często bezinteresownej młodzieńczej „ciekawości świata”.

Niezależnie od pobudek kierujących hakerami, zabezpieczać bazy trzeba. Na całym świecie zajmują się tym tysiące ludzi. Daleko nie szukając, w naszym periodyku co kwartał drukujemy informacje o kolejnych dziurach załatanych patchami Oracle.

Jednak śledząc światowe doniesienia o zaawansowanych technologicznie metodach ataków hakerskich, nie należy zapominać o sprawach najprostszych. O zabezpieczeniach, które wdrożyć możemy od ręki. Oto kilka takich prostych „domowych” sposobów możliwych do wdrożenia w niemal każdej instalacji.

Po pierwsze: nie używajmy haseł domyślnych

Nikomu udowadniać nie trzeba, że korzystanie z haseł domyślnie zakładanych podczas instalacji bazy, to jak zostawianie nie zamkniętych drzwi i to na dodatek drzwi frontowych. Wszyscy mniej i bardziej zaawansowani użytkownicy bazy danych wiedzą, że jak użytkownik SCOTT – to hasło TIGER, jak SYS, to pewnie CHANGE_ON_INSTALL albo ORACLE. Nie wszyscy jednak wiedzą, że z takimi domyślnymi hasłami na głównych kontach administracyjnych pracuje produkcyjnie tysiące baz.

Toteż właśnie hasłami domyślnymi zajmiemy się na samym początku. Od czego zacząć? Od znalezienia użytkowników bazy używających domyślnych haseł. Jak tego dokonać? Na przykład dokonując próby logowania się na poszczególne konta z wykorzystaniem takich właśnie haseł. Pomysł tak samo prosty co niewygodny. Jego realizacja wymaga bowiem sporo pracy i czasu. Zaproponujmy więc coś dla administratorów nieco bardziej leniwych. Sprawdźmy, czego o zapisanym w bazie haśle możemy się dowiedzieć przy pomocy SQLa:
SQL> select username, password
2 from dba_users
3 where username = 'SCOTT';
USERNAME PASSWORD
---------------- ---------------------------
SCOTT F894844C34402B67

Brzmienie hasła oczywiście zaszyfrowane zostało do postaci ciągu znaków alfanumerycznych, ale my wiemy, że ten pan SCOTT używa hasła domyślnego czyli TIGER. Wiemy już zatem, że jeśli userid + scott, to zahaszowana wartość hasła ma postać F894844C34402B67. Jeśli natomiast użytkownik konta SCOTT postanowi zmienić hasło, wydane przed chwilą zapytanie zwróci nam zupełnie inny ciąg znaków. Będzie to zatem dowód na to, że hasło domyślne zostało zmienione. Ale czy reguła ta działa w obie strony? Czy – jeśli inny użytkownik bazy zabezpieczy dostęp do swojego konta hasłem TIGER – będzie ono widoczne w perspektywie DBA_USERS pod postacią tego samego ciągu znaków? Sprawdźmy! Popatrzmy, co stanie się, gdy do bazy wprowadzimy innego pana SCOTTa:
SQL> create user scott2 identified by tiger;
User created.
SQL> select username, password
2 from dba_users
3 where username = 'SCOTT2';
USERNAME PASSWORD
---------------- ---------------------------
SCOTT2 C44C11D4C34DB67D

Tym razem hasłu TIGER przypisany został inny ciąg znaków. Jaki z tego morał? Wczytywana z DBA_USERS wartość kolumny PASSWORD jest nie tylko zależna od faktycznego brzmienia hasła, ale i od nazwy użytkownika. Szukając jednego ciągu znaków zahaszowanego hasła, nie znajdziemy zatem listy wszystkich użytkowników takiego hasła używających. Szukajmy zatem w przeciwną stronę. Zróbmy sobie tabelę nazw kont użytkowników i odpowiadających im ciągów znaków reprezentujących zahaszowane hasło. Teraz tylko trzeba porównać te informacje z zawartością perspektywy DBA_USERS w naszej bazie. Aby nie wyważać drzwi otwartych, możemy skorzystać z przygotowanych już narzędzi. Od stycznia 2006 dostępne jest na MetaLiku odpowiednie narządko. Można też sięgnąć po opisujący ten problem dokument ID 340009.1

Problem domyślnych haseł na głównych kontach administracyjnych został częściowo usunięty poprzez mechanizm odpytywania administratora o brzmienie tych haseł podczas instalacji bazy. W wersjach starszych od 10g, hasła te były ustawiane automatycznie na wartości domyślne.

Może warto w tym miejscu zastanowić się również, które z tych kont tworzonych podczas instalacji bazy jest nam naprawdę potrzebne. Oczywiście, nieśmiertelny SCOTT jest wdzięcznym materiałem do szkoleń, ale nie koniecznie musi towarzyszyć nam w bazie produkcyjnej. Z nieco bardziej skomplikowaną sytuacją mamy do czynienia w przypadku kont takich jak CTXSYS, DMSYS czy OLAPSYS. Potrzebne są one naszej bazie do pracy narzędzi Oracle i nie zawsze mamy śmiałość je usunąć. W takim przypadku najlepiej je zablokować, pozostawiając w bazie przypisane im zasoby tak, aby w razie konieczności można było je bez trudu ponownie uruchomić. W tym celu użyć możemy polecenia:
alter user dmsys account lock expire password;

Polecenie to nada kontu DMSYS status EXPIRED & LOCKED, co w praktyce uniemożliwia zalogowanie się do bazy z wykorzystaniem tego konta.

Porządkując dalej konta – nazwijmy je „techniczne” – spotkamy także i takie, których usunąć nie możemy, ale dla których bez konsekwencji dla pracy bazy możemy pokusić się o zmianę hasła. Do kont takich należy między innymi DBNSMP.

Po drugie: dostęp do binariów

Każda instalacja serwera bazy danych wiąże się z założeniem katalogu binariów serwera. Zwyczajowo znajduje się on w katalogu $ORACLE_HOME/bin i jest zwykle własnością użytkownika o jakże oryginalnej nazwie ORACLE. Przyglądając się wnętrzu tego katalogu stwierdzamy, że do części folderów jesteśmy w stanie bez trudu dopisać przeznaczenie, zawartość innych pozostaje dla nas zagadką. Wiedza o przeznaczeniu każdego z tych katalogów jest nam jednak niezbędna do prawidłowego ich zabezpieczenia. Nietrudno bowiem tak wspaniale zabezpieczyć binaria, aby nie mogły się w ogóle uruchomić. Przyznając, że jest to być może jedna z najwyższych form zabezpieczenia, poszukajmy jednak jakiegoś innego rozwiązania.

Poszukajmy plików potencjalnie niebezpiecznych, czyli w tym przypadku posiadających ustawiony parametr SUID. Parametr ten sprawia, że ich uruchomienie zawsze odbywa się z uprawnieniami właściciela pliku – bez względu na to, kto aktualnie uzyskał dostęp do jego uruchomienia.

Z poziomu unixopodobnego systemu operacyjnego wydajmy w tym celu następujące polecenie:
$ cd $ORACLE_HOME
$ find . -type f ( -perm -2000 -o -perm -4000 ) -exec ls -l {} ;

Lista plików, jaką otrzymamy w odpowiedzi, zależy od wersji bazy jaką mamy obecnie zainstalowaną. Na przykład dla bazy 10g release1 lista może mieć następującą postać:
-rwsr-s--x 1 orasoft dba 93300507 Jan 10 12:10 ./bin/oracleO
-r-sr-s--- 1 root dba 0 Jan 10 12:15 ./bin/oradism
-rwsr-s--x 1 orasoft dba 94492 Jan 10 12:22 ./bin/emtgtctl2
-rwsr-s--- 1 root dba 18944 Jan 10 12:22 ./bin/nmb
-rwsr-s--- 1 root dba 20110 Jan 10 12:22 ./bin/nmo
-r-sr-sr-x 1 nobody nobody 58302 Jan 10 12:23 ./bin/extjob

Czy wiemy do czego służą te