Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CloudWatch zbiera dane monitorujące i operacyjne w formie logów/metryk/wydarzeń, zapewniając jednolity widok zasobów AWS, aplikacji i usług. CloudWatch Log Event ma ograniczenie rozmiaru 256KB na każdą linię logu. Może ustawiać alarmy o wysokiej rozdzielczości, wizualizować logi i metryki obok siebie, podejmować automatyczne działania, rozwiązywać problemy i odkrywać spostrzeżenia w celu optymalizacji aplikacji.
Możesz monitorować na przykład logi z CloudTrail. Monitorowane wydarzenia:
Zmiany w grupach zabezpieczeń i NACL
Uruchamianie, zatrzymywanie, ponowne uruchamianie i kończenie instancji EC2
Zmiany w politykach zabezpieczeń w IAM i S3
Nieudane próby logowania do konsoli zarządzania AWS
Wywołania API, które zakończyły się nieudanym autoryzowaniem
Filtry do wyszukiwania w cloudwatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Przestrzeń nazw to kontener dla metryk CloudWatch. Pomaga w kategoryzacji i izolacji metryk, co ułatwia ich zarządzanie i analizę.
Przykłady: AWS/EC2 dla metryk związanych z EC2, AWS/RDS dla metryk RDS.
Metryki to punkty danych zbierane w czasie, które reprezentują wydajność lub wykorzystanie zasobów AWS. Metryki mogą być zbierane z usług AWS, aplikacji niestandardowych lub integracji zewnętrznych.
Przykład: CPUUtilization, NetworkIn, DiskReadOps.
Wymiary to pary klucz-wartość, które są częścią metryk. Pomagają unikalnie zidentyfikować metrykę i dostarczają dodatkowego kontekstu, przy czym maksymalna liczba wymiarów, które można powiązać z metryką, wynosi 30. Wymiary pozwalają również na filtrowanie i agregowanie metryk na podstawie określonych atrybutów.
Przykład: Dla instancji EC2 wymiary mogą obejmować InstanceId, InstanceType i AvailabilityZone.
Statystyki to obliczenia matematyczne wykonywane na danych metrycznych w celu ich podsumowania w czasie. Powszechne statystyki to Średnia, Suma, Minimum, Maksimum i LiczbaPróbek.
Przykład: Obliczanie średniego wykorzystania CPU w ciągu jednej godziny.
Jednostki to typ pomiaru związany z metryką. Jednostki pomagają dostarczyć kontekst i znaczenie dla danych metrycznych. Powszechne jednostki to Procent, Bajty, Sekundy, Liczba.
Przykład: CPUUtilization może być mierzony w Procentach, podczas gdy NetworkIn może być mierzony w Bajtach.
CloudWatch Dashboards zapewniają dostosowywane widoki metryk AWS CloudWatch. Możliwe jest tworzenie i konfigurowanie dashboardów w celu wizualizacji danych i monitorowania zasobów w jednym widoku, łącząc różne metryki z różnych usług AWS.
Kluczowe funkcje:
Widgety: Bloki budujące dashboardy, w tym wykresy, tekst, alarmy i inne.
Dostosowanie: Układ i zawartość mogą być dostosowane do specyficznych potrzeb monitorowania.
Przykład zastosowania:
Jeden dashboard pokazujący kluczowe metryki dla całego środowiska AWS, w tym instancji EC2, baz danych RDS i kubełków S3.
Strumienie metryk w AWS CloudWatch umożliwiają ciągłe przesyłanie metryk CloudWatch do wybranego miejsca w niemal rzeczywistym czasie. Jest to szczególnie przydatne do zaawansowanego monitorowania, analityki i niestandardowych dashboardów przy użyciu narzędzi spoza AWS.
Dane metryczne w strumieniach metryk odnoszą się do rzeczywistych pomiarów lub punktów danych, które są przesyłane. Te punkty danych reprezentują różne metryki, takie jak wykorzystanie CPU, użycie pamięci itp., dla zasobów AWS.
Przykład zastosowania:
Wysyłanie metryk w czasie rzeczywistym do zewnętrznej usługi monitorującej w celu zaawansowanej analizy.
Archiwizowanie metryk w kubełku Amazon S3 do długoterminowego przechowywania i zgodności.
Alarmy CloudWatch monitorują twoje metryki i wykonują działania na podstawie zdefiniowanych progów. Gdy metryka przekroczy próg, alarm może wykonać jedno lub więcej działań, takich jak wysyłanie powiadomień za pośrednictwem SNS, uruchamianie polityki automatycznego skalowania lub uruchamianie funkcji AWS Lambda.
Kluczowe komponenty:
Próg: Wartość, przy której alarm się uruchamia.
Okresy oceny: Liczba okresów, w których dane są oceniane.
Punkty danych do alarmu: Liczba okresów z osiągniętym progiem potrzebna do uruchomienia alarmu.
Działania: Co się dzieje, gdy stan alarmu jest uruchamiany (np. powiadomienie za pośrednictwem SNS).
Przykład zastosowania:
Monitorowanie wykorzystania CPU instancji EC2 i wysyłanie powiadomienia za pośrednictwem SNS, jeśli przekroczy 80% przez 5 kolejnych minut.
Wykrywacze anomalii wykorzystują uczenie maszynowe do automatycznego wykrywania anomalii w twoich metrykach. Możesz zastosować wykrywanie anomalii do dowolnej metryki CloudWatch, aby zidentyfikować odchylenia od normalnych wzorców, które mogą wskazywać na problemy.
Kluczowe komponenty:
Szkolenie modelu: CloudWatch wykorzystuje dane historyczne do szkolenia modelu i ustalania, jak wygląda normalne zachowanie.
Pasmo wykrywania anomalii: Wizualna reprezentacja oczekiwanego zakresu wartości dla metryki.
Przykład zastosowania:
Wykrywanie nietypowych wzorców wykorzystania CPU w instancji EC2, które mogą wskazywać na naruszenie bezpieczeństwa lub problem z aplikacją.
Reguły spostrzeżeń pozwalają na identyfikację trendów, wykrywanie szczytów lub innych interesujących wzorców w danych metrycznych, wykorzystując potężne wyrażenia matematyczne do definiowania warunków, na podstawie których powinny być podejmowane działania. Te reguły mogą pomóc w identyfikacji anomalii lub nietypowych zachowań w wydajności i wykorzystaniu zasobów.
Zarządzane reguły spostrzeżeń to wstępnie skonfigurowane reguły spostrzeżeń dostarczane przez AWS. Są zaprojektowane do monitorowania konkretnych usług AWS lub powszechnych przypadków użycia i mogą być włączane bez potrzeby szczegółowej konfiguracji.
Przykład zastosowania:
Monitorowanie wydajności RDS: Włącz zarządzaną regułę spostrzeżeń dla Amazon RDS, która monitoruje kluczowe wskaźniki wydajności, takie jak wykorzystanie CPU, użycie pamięci i I/O dysku. Jeśli którakolwiek z tych metryk przekroczy bezpieczne progi operacyjne, reguła może uruchomić alert lub automatyczną akcję łagodzącą.
Pozwala na agregację i monitorowanie logów z aplikacji i systemów z usług AWS (w tym CloudTrail) oraz z aplikacji/systemów (CloudWatch Agent może być zainstalowany na hoście). Logi mogą być przechowywane bezterminowo (w zależności od ustawień grupy logów) i mogą być eksportowane.
Elementy:
Grupa logów | kolekcja strumieni logów, które dzielą te same ustawienia przechowywania, monitorowania i kontroli dostępu |
Strumień logów | Sekwencja zdarzeń logów, które dzielą to samo źródło |
Filtry subskrypcyjne | Definiują wzorzec filtru, który pasuje do zdarzeń w danej grupie logów, wysyłają je do strumienia Kinesis Data Firehose, strumienia Kinesis lub funkcji Lambda |
CloudWatch podstawowy agreguje dane co 5 minut (ten szczegółowy robi to co 1 minutę). Po agregacji sprawdza progi alarmów, aby zobaczyć, czy należy uruchomić jeden z nich. W takim przypadku CloudWatch może być przygotowany do wysłania zdarzenia i wykonania pewnych automatycznych działań (funkcje AWS lambda, tematy SNS, kolejki SQS, strumienie Kinesis)
Możesz zainstalować agentów wewnątrz swoich maszyn/kontenerów, aby automatycznie wysyłać logi z powrotem do CloudWatch.
Utwórz rolę i przypisz ją do instancji z uprawnieniami pozwalającymi CloudWatch na zbieranie danych z instancji oprócz interakcji z menedżerem systemów AWS SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
Pobierz i zainstaluj agenta na instancji EC2 (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Możesz go pobrać z wnętrza EC2 lub zainstalować automatycznie za pomocą AWS System Manager, wybierając pakiet AWS-ConfigureAWSPackage
Skonfiguruj i uruchom agenta CloudWatch
Grupa logów ma wiele strumieni. Strumień ma wiele zdarzeń. A w każdym strumieniu zdarzenia są gwarantowane w kolejności.
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmAtakujący z tymi uprawnieniami mógłby znacznie osłabić infrastrukturę monitorowania i powiadamiania organizacji. Usuwając istniejące alarmy, atakujący mógłby wyłączyć kluczowe powiadomienia, które informują administratorów o krytycznych problemach z wydajnością, naruszeniach bezpieczeństwa lub awariach operacyjnych. Ponadto, tworząc lub modyfikując alarmy metryczne, atakujący mógłby również wprowadzać administratorów w błąd fałszywymi powiadomieniami lub uciszać legalne alarmy, skutecznie maskując złośliwe działania i uniemożliwiając terminowe reakcje na rzeczywiste incydenty.
Dodatkowo, z uprawnieniem cloudwatch:PutCompositeAlarm, atakujący mógłby stworzyć pętlę lub cykl alarmów złożonych, gdzie alarm złożony A zależy od alarmu złożonego B, a alarm złożony B również zależy od alarmu złożonego A. W tym scenariuszu nie jest możliwe usunięcie jakiegokolwiek alarmu złożonego, który jest częścią cyklu, ponieważ zawsze istnieje jeszcze alarm złożony, który zależy od alarmu, który chcesz usunąć.
Przykład poniżej pokazuje, jak uczynić alarm metryczny nieskutecznym:
Ten alarm metryczny monitoruje średnie wykorzystanie CPU konkretnej instancji EC2, ocenia metrykę co 300 sekund i wymaga 6 okresów oceny (łącznie 30 minut). Jeśli średnie wykorzystanie CPU przekroczy 60% przez co najmniej 4 z tych okresów, alarm zostanie uruchomiony i wyśle powiadomienie do określonego tematu SNS.
Poprzez modyfikację progu na więcej niż 99%, ustawienie okresu na 10 sekund, okresów oceny na 8640 (ponieważ 8640 okresów po 10 sekund równa się 1 dzień) oraz punktów danych do alarmu na 8640, konieczne byłoby, aby wykorzystanie CPU było powyżej 99% co 10 sekund przez cały 24-godzinny okres, aby uruchomić alarm.
Potencjalny wpływ: Brak powiadomień o krytycznych zdarzeniach, potencjalne niezauważone problemy, fałszywe alerty, tłumienie prawdziwych alertów i potencjalnie pominięte wykrycia rzeczywistych incydentów.
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions, cloudwatch:SetAlarmStateUsuwając akcje alarmowe, atakujący może uniemożliwić uruchomienie krytycznych powiadomień i automatycznych odpowiedzi, gdy osiągnięty zostanie stan alarmu, na przykład powiadamianie administratorów lub uruchamianie działań auto-skalowania. Niewłaściwe włączanie lub ponowne włączanie akcji alarmowych może również prowadzić do nieoczekiwanych zachowań, zarówno przez reaktywację wcześniej wyłączonych akcji, jak i przez modyfikację, które akcje są uruchamiane, co może powodować zamieszanie i błędne kierowanie w odpowiedzi na incydenty.
Ponadto, atakujący z odpowiednimi uprawnieniami może manipulować stanami alarmów, mając możliwość tworzenia fałszywych alarmów, aby odwrócić uwagę i zdezorientować administratorów, lub wyciszać prawdziwe alarmy, aby ukryć trwające złośliwe działania lub krytyczne awarie systemu.
Jeśli użyjesz SetAlarmState na alarmie złożonym, alarm złożony nie ma gwarancji, że powróci do swojego rzeczywistego stanu. Powraca do swojego rzeczywistego stanu tylko wtedy, gdy którykolwiek z jego alarmów podrzędnych zmieni stan. Jest również ponownie oceniany, jeśli zaktualizujesz jego konfigurację.
Potencjalny wpływ: Brak powiadomień o krytycznych zdarzeniach, potencjalne niezauważone problemy, fałszywe alerty, tłumienie prawdziwych alertów i potencjalnie pominięte wykrycia rzeczywistych incydentów.
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetectorAtakujący mógłby skompromitować zdolność do wykrywania i reagowania na nietypowe wzorce lub anomalie w danych metrycznych. Usuwając istniejące detektory anomalii, atakujący mógłby wyłączyć krytyczne mechanizmy powiadamiania; a tworząc lub modyfikując je, mógłby albo błędnie skonfigurować, albo stworzyć fałszywe pozytywy, aby odwrócić uwagę lub przytłoczyć monitoring.
Przykład poniżej pokazuje, jak uczynić detektor anomalii metrycznych nieskutecznym. Ten detektor anomalii metrycznych monitoruje średnie wykorzystanie CPU konkretnej instancji EC2, a dodanie parametru „ExcludedTimeRanges” z pożądanym zakresem czasowym wystarczy, aby zapewnić, że detektor anomalii nie analizuje ani nie alarmuje o żadnych istotnych danych w tym okresie.
Potencjalny wpływ: Bezpośredni wpływ na wykrywanie nietypowych wzorców lub zagrożeń bezpieczeństwa.
cloudwatch:DeleteDashboards, cloudwatch:PutDashboardNapastnik mógłby skompromitować możliwości monitorowania i wizualizacji organizacji, tworząc, modyfikując lub usuwając jej pulpity nawigacyjne. Te uprawnienia mogłyby zostać wykorzystane do usunięcia krytycznej widoczności wydajności i stanu systemów, zmiany pulpitów nawigacyjnych w celu wyświetlania nieprawidłowych danych lub ukrywania złośliwych działań.
Potencjalny wpływ: Utrata widoczności monitorowania i wprowadzające w błąd informacje.
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule ,cloudwatch:PutManagedInsightRuleReguły insight są używane do wykrywania anomalii, optymalizacji wydajności i efektywnego zarządzania zasobami. Usuwając istniejące reguły insight, atakujący mógłby usunąć krytyczne możliwości monitorowania, pozostawiając system niewidomym na problemy z wydajnością i zagrożenia bezpieczeństwa. Dodatkowo, atakujący mógłby tworzyć lub modyfikować reguły insight, aby generować wprowadzające w błąd dane lub ukrywać złośliwe działania, co prowadziłoby do błędnych diagnoz i niewłaściwych reakcji ze strony zespołu operacyjnego.
Potencjalny wpływ: Trudności w wykrywaniu i reagowaniu na problemy z wydajnością oraz anomalie, błędne podejmowanie decyzji i potencjalne ukrywanie złośliwych działań lub awarii systemu.
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRulesDezaktywując krytyczne zasady wglądu, atakujący mógłby skutecznie oślepić organizację na kluczowe metryki wydajności i bezpieczeństwa. Z drugiej strony, włączając lub konfigurując mylące zasady, mogłoby być możliwe generowanie fałszywych danych, tworzenie szumów lub ukrywanie złośliwej aktywności.
Potencjalny wpływ: Zamieszanie w zespole operacyjnym, prowadzące do opóźnionych reakcji na rzeczywiste problemy i niepotrzebnych działań na podstawie fałszywych alertów.
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDataAtakujący z uprawnieniami cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream mógłby tworzyć i usuwać strumienie danych metrycznych, kompromitując bezpieczeństwo, monitorowanie i integralność danych:
Tworzenie złośliwych strumieni: Tworzenie strumieni metrycznych w celu wysyłania wrażliwych danych do nieautoryzowanych miejsc.
Manipulacja zasobami: Tworzenie nowych strumieni metrycznych z nadmiernymi danymi mogłoby generować dużo szumów, powodując błędne alerty, maskując prawdziwe problemy.
Zakłócenie monitorowania: Usuwając strumienie metryczne, atakujący zakłóciliby ciągły przepływ danych monitorujących. W ten sposób ich złośliwe działania byłyby skutecznie ukryte.
Podobnie, z uprawnieniem cloudwatch:PutMetricData, możliwe byłoby dodawanie danych do strumienia metrycznego. Mogłoby to prowadzić do DoS z powodu ilości niewłaściwych danych dodanych, czyniąc go całkowicie bezużytecznym.
Przykład dodawania danych odpowiadających 70% wykorzystania CPU na danej instancji EC2:
Potencjalny wpływ: Zakłócenie przepływu danych monitorujących, wpływające na wykrywanie anomalii i incydentów, manipulacja zasobami oraz wzrost kosztów z powodu tworzenia nadmiernych strumieni metryk.
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreamsNapastnik kontrolowałby przepływ danych metryk w strumieniach (każdy strumień danych, jeśli nie ma ograniczeń zasobów). Posiadając uprawnienie cloudwatch:StopMetricStreams, napastnicy mogliby ukryć swoje złośliwe działania, zatrzymując krytyczne strumienie metryk.
Potencjalny wpływ: Zakłócenie przepływu danych monitorujących, wpływające na wykrywanie anomalii i incydentów.
cloudwatch:TagResource, cloudwatch:UntagResourceNapastnik mógłby dodać, zmodyfikować lub usunąć tagi z zasobów CloudWatch (obecnie tylko alarmy i zasady Contributor Insights). Może to zakłócić polityki kontroli dostępu w Twojej organizacji oparte na tagach.
Potencjalny wpływ: Zakłócenie polityk kontroli dostępu opartych na tagach.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
