Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Bezpieczeństwo bazy danych - weryfikacja (1)

Bezpieczeństwo bazy danych - weryfikacja (1)

Tekst jest kontynuacją artykułu Bezpieczeństwo baz danych.

Weryfikacja bezpieczeństwa bazy danych

Bezpieczeństwo bazy danych może być zagrożone na różne sposoby, poniżej omówimy kilka kategorii zagadnień, na które naszym zdaniem warto zwrócić uwagę. Pamiętajmy, że kompromitacja zabezpieczeń tylko z jednej grupy jest w stanie poważnie zagrozić bezpieczeństwu całej bazy danych - zatem weryfikacja bezpieczeństwa tego typu systemu powinno być wykonywana całościowo.
Każda z poniższych kategorii zawiera wypunktowane zalecenia, umożliwiające zaplanowanie we własnym zakresie audytu bezpieczeństwa czy testów penetracyjnych bazy danych.

Ekspozycja na poziomie sieci

Baza danych często udostępniana jest w sieci (czy to lokalnej, czy np. Internecie) – na bezpieczeństwo bazy danych można więc spojrzeć jak na bezpieczeństwo każdej innej usługi sieciowej (jak np. serwer webowy, serwer DNS, itd.).

Zalecenia

Sugerujemy zweryfikować takie elementy jak:

  1. Na jakich interfejsach sieciowych / portach nasłuchują usługi bazodanowe ? (niekiedy nie jest konieczne nasłuchiwanie bazy danych na wszystkich interfejsach sieciowych ani na interfejsie dostępnym do Internetu).
  2. Czy istnieje możliwość ataku na usługę z poziomu sieci ? – mamy tutaj na głównie myśli podatności w obsłudze protokołu komunikacyjnego (w lokalizacji tego typu podatności przydatny może być tzw. skaner podatności; skuteczne ataki w tym miejscu mogą wynikać również z braku wykonywania aktualizacji bezpieczeństwa w systemie, o czym piszemy w dalszej części tekstu)
  3. Czy w wykorzystywanej przez nas bazie, znane są inne specyficzne elementy, charakterystyczne dla komponentu nasłuchującego ? (np. ochrona za pomocą hasła komponentu nasłuchującego).

Przykładowe dalsze informacje

  • Weryfikację nasłuchiwania na określonych interfejsach sieciowych można wykonać np. linuksowym poleceniem: # netstat -tulpn

    W tym przypadku poniżej, usługa mysqld nasłuchuje jedynie na interface lokalnym (127.0.0.1):

    tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      28852/mysqld
  • Informacje o robaku Slammer (atakującego SQL Server)
  • Przykład alertu zgłaszanego przez oprogramowanie klasy IDS (intrusion detection system) - snort

    [**] [1:2003:8] MS-SQL Worm propagation attempt [**]
    [Classification: Misc Attack] [Priority: 2]
    04/19-23:16:14.032636 202.x.x.x:3352 -> x.x.x.x:1434
    UDP TTL:116 TOS:0x0 ID:55339 IpLen:20 DgmLen:404
    Len: 376
    [Xref => http://vil.nai.com/vil/content/v_99992.htm][Xref => http://cgi.nessus.org/plugins/dump.php3?id=11214][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0649][Xref => http://www.securityfocus.com/bid/5311][Xref => http://www.securityfocus.com/bid/5310]

Poprawki bezpieczeństwa

Jak wspomnieliśmy wyżej, często udane ataki na bazę danych związane są z brakiem aktualizacji samej bazy danych. W tym przypadku idea ataku może być następująca:

  • W  oprogramowaniu bazy danych znajdowana jest krytyczne luka, umożliwiająca zdobycie pełnej kontroli nad bazą danych z poziomu sieci.
  • W Internecie udostępniony jest exploit (program umożliwiający zautomatyzowane zaatakowanie systemu).
  • Producent bazy danych udostępnia aktualizację. Po jej wgraniu, ewentualne uruchomienie ww. exploitu nie powiedzie się, jednak gdy aktualizacja nie zostanie wykonana, wrogi kod może umożliwić przejęcie kontroli nad bazą.

Zalecenia
Rozważając kwestię aktualizacji bazy danych warto zadać sobie pytania:

  1. Czy posiadamy wykupiony pakiet umożliwiający instalowanie tego typu poprawek ? (w przypadku niektórych baz danych – np. Oracle – stanowić to może spory koszt)
  2. Czy aktualizacje bazy danych są wykonywane?
  3. Czy baza instalowana jest jako pakiet systemu operacyjnego, czy niezależnie?
  4. Czy weryfikowana jest integralność aktualizacji ? (czy wiemy skąd pochodzą aktualizacje?  jeśli udałoby się dostarczyć nam wrogą aktualizację – istnieje możliwość zdalnego przejęcia kontroli nad bazą)
  5. Czy aktualizacje wykonywane są ręcznie czy automatycznie? (niekiedy same aktualizacje mogą spowodować niepoprawne działanie całej bazy danych  - manualne aktualizacje pozostawiają administratorowi możliwość szybkiej reakcji na ewentualne problemy)
  6. Czy aktualizacje sprawdzane są wcześniej na serwerach testowych?

Przykładowe dalsze informacje

Użytkownicy z wykorzystaniem których działa baza danych

Aby ograniczyć wpływ negatywnych skutków naruszenia bezpieczeństwa na cały system, warto rozważyć uprawnienia użytkownika systemu operacyjnego, z wykorzystaniem którego uruchomiona jest baza.

Przykład: W Internecie dostępna jest aplikacja umożliwiająca dostęp do poczty elektronicznej w firmie. System działa w oparciu o bazę danych MySQL. Baza działa z uprawnieniami użytkownika systemu operacyjnego root (administrator), a aplikacja wykorzystuje użytkownika bazodanowego posiadającego uprawnienia administracyjne w bazie danych. Skuteczny atak z poziomu Internetu na aplikację prowadzi do:

  • możliwości odczytu e-maili dowolnego użytkownika,
  • możliwości odczytu innych danych znajdujących się w bazie danych na tym serwerze,
  • możliwości pełnego dostępu do systemu operacyjnego i atakowanie dalszych systemów w firmie

Zalecenia

  • Czy użytkownik systemu operacyjnego, z wykorzystaniem którego uruchomiona jest usługa bazodanowa, posiada uprawniania administracyjne? (należy unikać takiej sytuacji)
  • Czy powyższy użytkownik posiada dodatkowe uprawnienia, niewymagane koniecznie do działania bazy danych ? (np. uprawniania w systemie plików do wielu zasobów w systemie operacyjnym)
  • Czy istnieje możliwość interaktywnego zalogowania się na użytkownika bazodanowego - np. z wykorzystaniem SSH ? (nie powinniśmy oferować takiej możliwości)

Przykładowe dalsze informacje

Użytkownicy bazodanowi

Kolejnym istotnym elementem przy weryfikacji bezpieczeństwa bazy danych jest określenie uprawnień użytkowników definiowanych na poziomie bazy danych. Ogólna zasada mówi, że powinniśmy działać zgodnie z tzw. zasadą least privileges, wg. uprawnienia użytkowników bazodanowych powinny być najmniejszymi, które są wymagane do prawidłowego działania całości systemu.

Zalecenia

  1. Czy wybrani użytkownicy bazodanowi nie posiadają nadmiernych uprawnień ? (np. uprawnienia administracyjne do bazy dla użytkownika bazodanowego skonfigurowanego w aplikacji webowej).
  2. Czy w systemie wykonane jest mapowanie użytkowników bazodanowych na użytkowników systemu operacyjnego (popularne szczególnie w systemach Windows). Jeśli tak, to czy mapowanie jest poprawne? 
  3. Jakie konta bazodanowe mają uprawnienia administracyjne?
  4. Którzy użytkownicy posiadają dostęp anonimowy do bazy danych ? (konta dzielone bez hasła – mamy tu na myśli konta typu guest).
  5. Czy możliwy jest dostęp do bazy za pomocą użytkowników / haseł domyślnych ? (np. kombinacja DBSNMP/DBSNMP w bazie Oracle)
  6. Czy użytkownicy bazodanowi posiadają wystarczająco złożone hasła dostępowe?

Przykładowe dalsze informacje

Czytaj dalej

 

--Michał Sajdak (michal.sajdak@securitum.pl)

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS