Zabezpieczenia wywłaszczające z rejestrowaniem audytu dla MongoDB

Bezpieczeństwo bazy danych to szeroki temat, który rozciąga się od pomiarów wyprzedzających po zatrzymywanie niechcianych gości. Nawet jeśli byłbyś w stanie w pełni zabezpieczyć swoje serwery MongoDB, nadal chciałbyś wiedzieć, czy ktoś próbował włamać się do twojego systemu. A jeśli uda im się złamać twoje bezpieczeństwo i zainstalować hack do okupu MongoDB, będziesz potrzebować ścieżki audytu dla sekcji zwłok lub podjęcia nowych środków zapobiegawczych. Dziennik audytu umożliwiłby śledzenie każdego, kto próbował się zalogować i zobaczyć, co zrobił w Twoim systemie.

Wersja MongoDB Enterprise zawiera możliwość włączenia dziennika inspekcji, ale wersja społeczności nie ma tej funkcji. Percona stworzyła własną funkcjonalność rejestrowania audytu w swoim opartym na MongoDB serwerze Percona Server dla MongoDB. Podejścia MongoDB i Percona różnią się od siebie i wyjaśnimy, jak skonfigurować i używać ich obu.

Rejestrowanie audytu MongoDB

Dziennik kontroli MongoDB jest łatwy do skonfigurowania:aby włączyć logowanie kontrolne do pliku JSON, po prostu dodaj następującą sekcję do pliku konfiguracyjnego i uruchom ponownie MongoDB:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDB obsługuje pliki, konsole i syslog jako miejsca docelowe. W przypadku formatów plików istnieją dwie opcje:JSON i BSON. W JSON wiersze dziennika kontroli wyglądają podobnie do tego:

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

Powyższa konfiguracja umożliwiłaby rejestrowanie dziennika audytu dla każdej akcji wykonanej przez dowolnego użytkownika systemu. Jeśli masz wysoką współbieżność, drastycznie zmniejszyłoby to wydajność twojego klastra MongoDB. Na szczęście istnieje możliwość filtrowania zdarzeń, które mają być rejestrowane.

Filtry do rejestrowania inspekcji można umieścić na typie zapytania, zapytaniu użytkownika/roli lub na badanej kolekcji. Dokumentacja dotycząca rejestrowania audytów w MongoDB jest bardzo obszerna i obszerna z wieloma przykładami. Poniżej podamy niektóre z najważniejszych przykładów.

Uwierzytelnianie w określonej kolekcji:

    filter: '{ atype: "authenticate", "param.db": "test" }'

Dziennik dla wielu typów audytu:

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Rejestruj wszystkie sprawdzenia uwierzytelniania pod kątem wstawiania/aktualizacji/usuwania w określonej kolekcji:

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Jak widać, filtry mogą być dość elastyczne i będziesz w stanie filtrować wiadomości, których potrzebujesz do ścieżki audytu.

Serwer Percona do rejestrowania audytu MongoDB

Rejestrowanie kontrolne Percona Server for MongoDB jest ograniczone do pliku JSON. Większość użytkowników będzie logować się tylko do plików JSON, ale nie jest jasne, czy Percona doda w przyszłości inne funkcje rejestrowania.

W zależności od wersji Percona Server for MongoDB konfiguracja może być inna. W chwili pisania tego tekstu wszystkie wersje mają następującą składnię:

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Jednak ta różnica w konfiguracji została ostatnio rozwiązana, ale nadal musi zostać zwolniona. Po wydaniu powinien ponownie postępować zgodnie z dyrektywą MongoDB auditLog:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Format Percony jest nieco inny:

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

W przeciwieństwie do rejestrowania wszystkiego przez MongoDB, Percona wybrała rejestrowanie tylko ważnych poleceń. Sądząc po źródle wtyczki audytu Percona, obsługiwane są następujące zapytania:uwierzytelnianie, tworzenie/aktualizowanie/usuwanie użytkowników, dodawanie/aktualizowanie/usuwanie ról, tworzenie/upuszczanie bazy danych/indeksów i większość ważnych poleceń administracyjnych.

Również filtrowanie dziennika audytu Percona Server dla MongoDB nie wydaje się być zgodne z tym samym standardem, co MongoDB. Nie jest jasne, jaka jest dokładna składnia i opcje filtra, ponieważ dokumentacja Percony jest na ten temat bardzo zwięzła.

Włączenie dziennika kontroli bez filtrowania dałoby więcej niż wystarczającą liczbę wpisów w pliku dziennika. Stąd możesz zawęzić filtr, ponieważ jest on zgodny ze składnią JSON wpisów dziennika.

Korzystanie z dziennika audytu

Aby sobie to ułatwić, najlepszym rozwiązaniem może być wprowadzenie dziennika inspekcji do platformy analizującej dzienniki. Stos ELK to doskonałe środowisko do przeprowadzania analiz i umożliwia dość łatwe przechodzenie do bardziej szczegółowych poziomów. Korzystanie z mapowania pola pozwoliłoby nawet na wykonanie ścieżki audytu wewnątrz ELK.

Jak opisano we wstępie, dziennik audytu możemy wykorzystać do różnych celów bezpieczeństwa. Najbardziej oczywistym jest to, gdy potrzebujesz go jako odniesienia podczas sekcji zwłok. Dziennik kontroli MongoDB zawiera szczegółowy przegląd tego, co dokładnie się wydarzyło. Dziennik audytu Percony zawiera nieco mniej informacji, ale powinien wystarczyć w przypadku większości sekcji zwłok. Korzystanie z dziennika kontrolnego do sekcji zwłok jest świetne, chociaż wolelibyśmy przede wszystkim zapobiec temu problemowi.

Innym celem dziennika kontroli jest obserwowanie zachodzących trendów i można ustawić pułapki na określone komunikaty dziennika kontroli. Dobrym przykładem może być sprawdzenie wskaźnika (nieudanych) prób uwierzytelnienia i jeśli przekroczy on pewien próg, podejmij działania. W zależności od sytuacji podjęte działania mogą się różnić. Jednym z działań może być automatyczne zablokowanie adresu IP, z którego pochodzą żądania, ale w innym przypadku możesz skonsultować się z użytkownikiem, dlaczego zapomniano hasła. To naprawdę zależy od przypadku i środowiska, w którym pracujesz.

Innym zaawansowanym pomiarem z wyprzedzeniem byłoby użycie MongoDB jako pułapki honeypot i wykorzystanie dziennika audytu do wyłapywania niepożądanych użytkowników. Po prostu udostępnij MongoDB i pozwól każdemu połączyć się z serwerem MongoDB. Następnie użyj dziennika kontrolnego, aby wykryć, co zrobią użytkownicy, jeśli będą mogli robić rzeczy wykraczające poza ich normalne uprawnienia, i w razie potrzeby zablokować ich. Większość ludzi wybiera raczej łatwą niż trudną drogę, aby pułapka mogła odeprzeć atak, a haker przeniósłby się do następnego celu.

Wniosek

Oprócz wyjaśnienia, jak skonfigurować dziennik audytu zarówno dla MongoDB Enterprise, jak i Percona Server dla MongoDB, wyjaśniliśmy również, co możesz potencjalnie zrobić z danymi rejestrowanymi w dzienniku audytu.

Domyślnie ClusterControl nie włącza dziennika inspekcji, ale stosunkowo łatwo jest włączyć go w całym klastrze za pomocą naszego Menedżera konfiguracji. Możesz również włączyć go w szablonach konfiguracji przed wdrożeniem nowego klastra.

Miłego klastrowania!