Ochrona PostgreSQL przed kampaniami cryptojackingu w Kubernetes

PostgreSQL to potężny, open-source’owy system zarządzania bazą danych relacyjnych (RDBMS). Ze względu na swoją solidność i skalowalność, PostgreSQL jest szeroko stosowany w chmurze. Większość dostawców publicznych usług chmurowych, w tym AWS, Azure i GCP, udostępnia swoim klientom usługi bazodanowe oparte na PostgreSQL.

Według raportu Google „Threat Horizons” ze stycznia 2023 roku, PostgreSQL jest jedną z najczęściej atakowanych aplikacji w przypadku ataku na klientów Google, zajmując trzecie miejsce pod względem częstotliwości (17%), ustępując miejsca SSH (26%) i Jenkins (22%). Słabe hasła nadal stanowią najczęstszy wektor w przypadku uzyskania początkowego dostępu, odgrywając rolę w 41% obserwowanych przypadków naruszeń. Atakujący często poszukują słabo skonfigurowanych lub niezabezpieczonych instancji PostgreSQL wdrożonych w chmurze, środowisku Kubernetes lub na infrastrukturze lokalnej.

Wielu chciwych aktorów zagrożeń związanych z kryptojackingiem, w tym TeamTNT i Kinsing, wykorzystuje źle skonfigurowane instancje PostgreSQL do wydobywania kryptowalut. W tym artykule omówione są najpopularniejsze błędy konfiguracyjne, które są wykorzystywane przez tych cyberprzestępców.

Niezabezpieczona konfiguracja PostgreSQL umożliwia kryptojacking

Wspólne usługi PostgreSQL hostowane przez dostawców usług chmurowych (takie jak Amazon RDS dla PostgreSQL, Azure Database dla PostgreSQL lub GCP Cloud SQL dla PostgreSQL) nie zezwalają na dostosowanie kontroli uwierzytelniania, które mogłyby prowadzić do takiego nadużycia. Jednak podczas ręcznego wdrażania PostgreSQL mogą wystąpić różne błędy konfiguracyjne dotyczące metod uwierzytelniania, ról użytkowników, dostępu i uprawnień, które mogą spowodować narażenie na ryzyko, które można wykorzystać.

PostgreSQL obsługuje wiele metod uwierzytelniania, gdy jest wdrażany ręcznie. Spośród nich najmniej bezpieczne jest uwierzytelnianie „trust”, które umożliwia dostęp bez konieczności podawania hasła, co prawdopodobnie jest powodem, dla którego grupy kryptominingowe lubią atakować instancje chmurowe PostgreSQL z włączonym uwierzytelnianiem typu „trust”. Istnieją dwa sposoby włączenia uwierzytelniania „trust”:

1. Za pomocą pliku pg_hba.conf
2. Za pomocą zmiennej środowiskowej POSTGRES_HOST_AUTH_METHOD=trust

Na rysunku 1 przedstawione jest uwierzytelnianie „trust” za pomocą pliku pg_hba.conf, w którym dowolny użytkownik z dowolnego adresu IP może połączyć się z serwerem PostgreSQL bez hasła. Nazwa użytkownika może być nazwą superużytkownika, w takim przypadku atakujący odziedziczy wszystkie uprawnienia superużytkownika PostgreSQL.

<img class=”alignnone size-full wp-image-7710″ trust” można również włączyć, ustawiając zmienną środowiskową POSTGRES_HOST_AUTH_METHOD=trust wewnątrz poda Kubernetes lub serwera. Po ustawieniu tej zmiennej dowolny adres IP lub użytkownik może połączyć się z bazą danych bez hasła.

Dodatkowo, uwierzytelnianie „trust” w połączeniu z ryzykownymi domyślnymi rolami użytkowników PostgreSQL (opisanymi poniżej) stanowi doskonałą okazję dla atakujących do nadużywania baz danych w celu odczytywania lub zapisywania poufnych plików w systemie plików, modyfikacji konfiguracji i eskalacji uprawnień.

1. pg_read_server_files (umożliwia odczyt plików systemowych)
2. pg_write_server_files (umożliwia zapis plików systemowych)
3. pg_execute_server_program (umożliwia uruchamianie binarnych plików systemowych)

W przypadku ataku na źle skonfigurowany PostgreSQL, zdalny atakujący może uwierzytelnić się jako superużytkownik lub użytkownik posiadający odpowiednie role – pg_execute_server_program pozwala im na pobieranie i uruchamianie podejrzanych plików w celu wydobywania kryptowalut. Na rysunku 2.A przedstawiono atakujących korzystających z polecenia COPY do pobrania i uruchomienia xmrig, który wydobywa cyfrową walutę, taką jak Monero; na rysunku 2.B pokazano proces xmrig działający wewnątrz kontenera i skutecznie wydobywający kryptowalutę.

<img class=”alignnone size-full wp-image-7712″ off”. Oznacza to, że baza danych nie będzie tymczasowo ograniczać przychodzących połączeń z danego adresu IP po kilku nieudanych próbach logowania, co chroni bazę danych przed atakami typu brute force.

AzurePostgreSQLInformationalBaza danych PostgreSQL ma wyłączony parametr punktów kontrolnych dziennikaZidentyfikowano bazę danych PostgreSQL z parametrem rejestrowania punktów kontrolnych ustawionym na „wyłączony”. Bez tego typu rejestrowania nie będziesz miał wglądu w proces punktu kontrolnego, który może zakłócać wydajność bazy danych i niezawodność połączenia.AzurePostgreSQLInformationalBaza danych PostgreSQL ma wyłączony parametr logowania połączeńZidentyfikowano bazę danych PostgreSQL z parametrem rejestrowania połączeń ustawionym na „wyłączony”. Bez tego typu rejestrowania nie będziesz mieć wglądu w próby połączenia z bazą danych. Dzienniki połączeń mogą pomóc w identyfikacji prób ataków siłowych na bazę danych i mogą pomóc w śledzeniu przeciwników podczas dochodzenia.AzurePostgreSQLInformationalBaza danych PostgreSQL ma wyłączony parametr rejestrowania rozłączeńZidentyfikowano bazę danych PostgreSQL z parametrem rejestrowania rozłączenia ustawionym na „wyłączony”. Bez tego typu rejestrowania nie będziesz mieć wglądu w sesje połączeń z bazą danych, które mogą zawierać szczegóły, takie jak długość sesji i czas rozłączenia.AzurePostgreSQLInformationalBaza danych PostgreSQL ma wyłączony parametr czasu trwania dziennikaZidentyfikowano bazę danych PostgreSQL z parametrem rejestrowania czasu trwania ustawionym na „wyłączony”. Bez tego typu rejestrowania nie będziesz mieć wglądu w czas potrzebny na wykonanie zapytań do bazy danych. Może to pomóc w identyfikacji, kiedy baza danych jest obciążona lub jeśli występują inne problemy z wydajnością zapytań i/lub bazy danych.GCPCloud SQLInformationalFlaga Cloud SQL for PostgreSQL „log_checkpoints” jest wyłączonaWłączenie log_checkpoints powoduje, że punkty kontrolne i punkty restartu są rejestrowane w dzienniku serwera. Niektóre statystyki są zawarte w komunikatach dziennika, w tym liczba zapisanych buforów i czas ich zapisu. Ten parametr można ustawić tylko w pliku postgresql.conf lub w wierszu poleceń serwera. To zalecenie dotyczy instancji bazy danych PostgreSQL.GCPCloud SQLInformationalFlaga Cloud SQL dla PostgreSQL „log_connections” jest wyłączonaPostgreSQL domyślnie nie rejestruje prób połączeń. Włączenie ustawienia log_connections spowoduje utworzenie wpisów dziennika dla każdej próby połączenia, a także pomyślnego zakończenia uwierzytelniania klienta, co może być przydatne w rozwiązywaniu problemów i określaniu nietypowych prób połączenia z serwerem. To zalecenie dotyczy instancji bazy danych PostgreSQL.GCPCloud SQLInformationalFlaga Cloud SQL dla PostgreSQL „log_ disconnections” jest wyłączonaPostgreSQL domyślnie nie rejestruje szczegółów sesji, takich jak czas trwania i zakończenie sesji. Włączenie ustawienia log_disconnections spowoduje utworzenie wpisów dziennika na końcu każdej sesji, co może być przydatne w rozwiązywaniu problemów i określaniu nietypowej aktywności w danym okresie czasu. Log_disconnections i log_connections działają ręka w rękę i ogólnie rzecz biorąc, para powinna być włączona / wyłączona razem. To zalecenie ma zastosowanie do instancji bazy danych PostgreSQL.GCPCloud SQLInformationalFlaga Cloud SQL dla PostgreSQL „log_lock_waits” jest wyłączonaLimit czasu zakleszczenia określa czas oczekiwania na blokadę przed sprawdzeniem jakichkolwiek warunków. Częste przekraczanie limitu czasu blokady może wskazywać na podstawowy problem. Rejestrowanie takiego oczekiwania na blokady poprzez włączenie flagi log_lock_waits może być wykorzystane do zidentyfikowania niskiej wydajności z powodu opóźnień blokowania lub jeśli specjalnie spreparowany SQL próbuje głodzić zasoby poprzez utrzymywanie blokad przez zbyt długi czas. To zalecenie dotyczy instancji bazy danych PostgreSQL.GCPCloud SQLInformationalFlaga Cloud SQL dla PostgreSQL „log_temp_files” jest wyłączonaFlaga log_temp_files jest wyłączona. Pliki tymczasowe nie są rejestrowane, więc może być trudniej zidentyfikować potencjalne problemy z wydajnością, które mogą być spowodowane celowymi próbami głodu zasobów.GCPCloud SQLInformationalFlaga Cloud SQL dla PostgreSQL „log_min_ duration_ statement” jest włączonaLogowanie instrukcji SQL może zawierać poufne informacje, które nie powinny być rejestrowane w dziennikach. To zalecenie dotyczy instancji bazy danych PostgreSQL.GCPCloud SQLMediumInstancja bazy danych SQL w chmurze nie wymaga protokołu SSLPołączenia z bazą danych SQL, jeśli zostaną pomyślnie przechwycone (MITM), mogą ujawnić poufne dane, takie jak poświadczenia, zapytania do bazy danych, wyniki zapytań itp. Ze względów bezpieczeństwa zaleca się, aby zawsze używać szyfrowania SSL podczas łączenia się z instancją. Zalecenie to dotyczy instancji PostgreSQL, MySQL generacji 1 i MySQL generacji 2.GCPCloud SQLInformationalWystąpienie Cloud SQL nie jest skonfigurowane do tworzenia kopii zapasowychKopie zapasowe umożliwiają przywrócenie instancji Cloud SQL w celu odzyskania utraconych danych lub rozwiązania problemu z tą instancją. Automatyczne kopie zapasowe muszą być ustawione dla każdej instancji zawierającej dane, które powinny być chronione przed utratą lub uszkodzeniem. To zalecenie dotyczy instancji SQL Server, PostgreSQL, MySQL generacji 1 i MySQL generacji 2.GCPVPCHighVPC umożliwia dostęp do PostgreSQL ze wszystkich sieciZezwolenie na przychodzący ruch sieciowy z globalnej przestrzeni IP (0.0.0.0/0) naraża niepotrzebne, powszechnie wykorzystywane usługi na ataki w Internecie. Ten port wysokiego ryzyka jest często skanowany przez atakujących, a pojedyncza błędna konfiguracja lub nieaktualny serwer może stanowić poważne zagrożenie dla organizacji. Dostęp uzyskany przez atakującego może skutkować naruszeniem danych lub dalszym wykorzystywaniem w sieci obsługującej narażone usługi.

MITRE dla obrony infrastruktury jako usługi (IaaS)

Crowdstrike nawiązał współpracę z MITRE Engenuity Center for Threat-Informed Defense w celu opracowania ATT&CK Defense dla IaaS. Celem tego projektu było opracowanie skutecznych metod i strategii obrony przed atakami przeciwników na infrastrukturę IaaS w chmurze, kontenerach i usługach Linux aaS. Ponieważ najpopularniejszą techniką wykorzystywaną przez atakujących do uzyskania początkowego dostępu do infrastruktury chmurowej jest wykorzystanie publicznie dostępnego aplikacji, takiego jak postgreSQL, ważne jest ocenienie narażenia twojej aplikacji przedsiębiorstwa na działanie zewnętrzne i następnie stosowanie najlepszych praktyk w celu ich zabezpieczenia.

Najlepsze praktyki w zakresie zabezpieczania PostgreSQL

Aby zabezpieczyć środowisko PostgreSQL, konieczne jest zastosowanie odpowiednich praktyk konfiguracyjnych oraz regularne monitorowanie. Oto kilka ogólnych wskazówek dotyczących bezpiecznego wdrożenia PostgreSQL w środowiskach chmurowych i Kubernetes:

1. Używaj najnowszej wersji PostgreSQL i instaluj niezbędne łatki.
2. Używaj silnego hasła przy korzystaniu z uwierzytelniania opartego na haśle.
3. Zastosuj odpowiednie uprawnienia, aby zabezpieczyć pliki konfiguracyjne, takie jak pg_hba.conf.
4. Włącz SSL/TLS, aby zabezpieczyć połączenie między klientem a usługą PostgreSQL.
5. Audytuj użytkowników i ich role bezpieczeństwa, stosując zasadę najmniejszych uprawnień.
6. Używaj tajemnic przestrzeni nazw Kubernetes.
7. Uruchamiaj usługę PostgreSQL jako użytkownik nie będący rootem, co dodatkowo zwiększa ochronę w przypadku kompromitacji.
8. Ogranicz zasoby kontenerów dostępne dla usługi PostgreSQL do odpowiedniego poziomu.
9. Monitoruj hosty i kontenery pod kątem podejrzanej aktywności.
10. Użyj mechanizmu Zero Trust, aby umożliwić wymagany dostęp do usługi w klastrze.
11. Użyj proaktywnego rozwiązania bezpieczeństwa do identyfikacji nieprawidłowej konfiguracji i podatności.

Podsumowanie

Bezpieczeństwo PostgreSQL, popularnej aplikacji w chmurze, jest kluczowe dla zapobiegania atakom na infrastrukturę. Błędy konfiguracyjne w PostgreSQL mogą stanowić punkt wejścia dla atakujących, jak w przypadku grup zajmujących się kryptowalutami, które wykorzystują takie podatności do wydobywania kryptowalut w celach zysku. Aby chronić się przed takimi naruszeniami, ważne jest przestrzeganie najlepszych praktyk zabezpieczania PostgreSQL, aktywne monitorowanie błędów konfiguracyjnych i utrzymanie silnego ogólnego poziomu bezpieczeństwa.

Jednym z sposobów osiągnięcia tego jest korzystanie z kompleksowej platformy bezpieczeństwa w chmurze, takiej jak platforma ochrony aplikacji w chmurze CrowdStrike, która oferuje połączenie bezpieczeństwa w czasie rzeczywistym i proaktywnych działań, w tym ocen wskaźników IOM i wskaźników ataku (IOA), a także sprawdzania zgodności. Platforma ta wykrywa i zapobiega naruszeniom ze strony różnych rodzajów aktorów, w tym grup zajmujących się kryptowalutami, cyberprzestępców i aktorów państwowych, zapewniając kompleksowe i solidne rozwiązanie do zabezpieczania Twojej infrastruktury w chmurze.

Należy jednak pamiętać, że iIT Distribution jest dystrybutorem i promotorem rozwiązań CrowdStrike w Polsce oraz zapewnia profesjonalne wsparcie w zakresie projektowania i wdrażania tych rozwiązań. Zawsze zapewniamy niezbędne wsparcie informacyjne dla naszych partnerów i klientów dotyczące każdego produktu, a nasi eksperci są gotowi udzielić porad w zakresie poprawy wydajności Twojej infrastruktury IT i jej ochrony.