Wykrywanie nowych zagrożeń przy użyciu usługi Microsoft Sentinel z zaporą aplikacji internetowej platformy Azure
Aplikacje internetowe napotykają częste złośliwe ataki wykorzystujące znane luki w zabezpieczeniach, takie jak wstrzyknięcie kodu i ataki przechodzenia ścieżki. Te ataki są trudne do uniknięcia w kodzie aplikacji, ponieważ wymagają stałej konserwacji, stosowania poprawek i monitorowania na wielu poziomach architektury aplikacji. Rozwiązanie zapory aplikacji internetowej (WAF) może zapewnić szybsze i scentralizowane zabezpieczenia, stosując poprawki znanej luki w zabezpieczeniach dla wszystkich aplikacji internetowych, zamiast zabezpieczać je pojedynczo. Usługa Azure Web Application Firewall to natywna dla chmury usługa, która chroni aplikacje internetowe przed typowymi technikami hackingu internetowego. Można go szybko wdrożyć, aby uzyskać pełny wgląd w ruch aplikacji internetowej i zablokować złośliwe ataki internetowe.
Dzięki integracji zapory aplikacji internetowej platformy Azure z usługą Microsoft Sentinel (natywnym rozwiązaniem SIEM w chmurze) można zautomatyzować wykrywanie i reagowanie na zagrożenia/zdarzenia/alerty oraz zaoszczędzić czas i nakład pracy na aktualizowanie zasad zapory aplikacji internetowej. W tym artykule pokazano, jak utworzyć reguły analityczne/wykrycia w usłudze Microsoft Sentinel pod kątem ataków, takich jak iniekcja kodu.
Wykrywanie zapytań dotyczących ataków na aplikacje internetowe
Repozytorium GitHub zabezpieczeń sieci platformy Azure zawiera następujące wstępnie utworzone zapytania, których można użyć do tworzenia reguł analitycznych w usłudze Microsoft Sentinel. Te reguły analityczne pomagają w automatycznym wykrywaniu i reagowaniu na ataki, takie jak wstrzyknięcie kodu, przechodzenie ścieżki i ataki oparte na skanerze.
Ataki iniekcji kodu (application gateway i zapora aplikacji internetowej usługi Front Door)
Atak polegający na wstrzyknięciu kodu to rodzaj cyberataku, który polega na wstrzyknięciu złośliwego kodu do aplikacji. Następnie aplikacja interpretuje lub uruchamia kod, wpływając na wydajność i funkcję aplikacji.
Ataki przechodzenia ścieżki (Application Gateway i Zapora aplikacji internetowej usługi Front Door)
Atak przechodzenia ścieżki jest typem cyberataku, który polega na manipulowaniu ścieżkami plików aplikacji w celu uzyskania dostępu do plików i katalogów przechowywanych poza folderem głównym sieci Web. Osoba atakująca może używać sekwencji znaków specjalnych, takich jak
…/
lub…\
, do przenoszenia hierarchii katalogów i uzyskiwania dostępu do poufnych lub poufnych danych, takich jak pliki konfiguracji, kod źródłowy lub pliki systemowe.Ataki oparte na skanerach (zapora aplikacji internetowej usługi Application Gateway)
Atak internetowy oparty na skanerze to rodzaj cyberataku, który polega na użyciu skanera luk w zabezpieczeniach internetowych w celu znalezienia i wykorzystania słabych stron zabezpieczeń w aplikacjach internetowych. Skaner luk w zabezpieczeniach internetowych to narzędzie, które automatycznie skanuje aplikacje internetowe pod kątem typowych luk w zabezpieczeniach, takich jak wstrzyknięcie kodu SQL, XSS, CSRF i przechodzenie ścieżki. Osoba atakująca może użyć skanera do zidentyfikowania narażonych obiektów docelowych i uruchomienia ataków w celu ich naruszenia.
Konfigurowanie reguł analitycznych w usłudze Sentinel na potrzeby ataków na aplikacje internetowe
Do skonfigurowania reguł analitycznych wymagane są następujące wymagania wstępne:
- Działająca zapora aplikacji internetowej i obszar roboczy usługi Log Analytics skonfigurowany do odbierania dzienników z odpowiedniej bramy aplikacja systemu Azure lub usługi Azure Front Door. Aby uzyskać więcej informacji, zobacz Dzienniki zasobów dla usługi Azure Web Application Firewall.
- Ponadto usługa Microsoft Sentinel powinna być włączona dla obszaru roboczego usługi Log Analytics, który jest tutaj używany. Aby uzyskać więcej informacji, zobacz Szybki start: dołączanie usługi Microsoft Sentinel.
Wykonaj poniższe kroki, aby skonfigurować regułę analizy w usłudze Sentinel.
Przejdź do usługi Microsoft Sentinel i wybierz kartę Analiza . Wybierz pozycję Utwórz , a następnie wybierz pozycję Zaplanowana reguła kwerendy.
Taktyka i techniki podane w tym miejscu są tylko informacyjne i pochodzą z bazy wiedzy MITRE Attack Knowledgebase To jest baza wiedzy taktyki i technik przeciwników w oparciu o rzeczywiste obserwacje.
Możesz użyć kreatora reguł analizy, aby ustawić poziom ważności dla tego zdarzenia. Ponieważ są to poważne ataki, wybrano opcję Wysoka ważność.
Na stronie Ustawianie logiki reguły wprowadź następujące wstępnie utworzone zapytanie iniekcji kodu: to zapytanie można znaleźć w repozytorium GitHub zabezpieczeń sieci platformy Azure. Podobnie możesz użyć dowolnego innego zapytania dostępnego w repozytorium, aby utworzyć reguły analityczne i wykryć odpowiednie wzorce ataków.
let Threshold = 3; AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | where action_s == "Matched" | where Message has "Injection" or Message has "File Inclusion" | where ruleGroup_s == "REQUEST-932-APPLICATION-ATTACK-RCE" or ruleGroup_s == "REQUEST-931-APPLICATION-ATTACK-RFI" or ruleGroup_s == "REQUEST-932-APPLICATION-ATTACK-RCE" or ruleGroup_s == "REQUEST-933-APPLICATION-ATTACK-PHP" or ruleGroup_s == "REQUEST-942-APPLICATION-ATTACK-SQLI" or ruleGroup_s == "REQUEST-921-PROTOCOL-ATTACK" or ruleGroup_s == "REQUEST-941-APPLICATION-ATTACK-XSS" | project transactionId_g, hostname_s, requestUri_s, TimeGenerated, clientIp_s, Message, details_message_s, details_data_s | join kind = inner( AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | where action_s == "Blocked") on transactionId_g | extend Uri = strcat(hostname_s,requestUri_s) | summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated), TransactionID = make_set (transactionId_g,100), Message = make_set(Message,100), Detail_Message = make_set(details_message_s, 100), Detail_Data = make_set(details_data_s,100), Total_TransactionId = dcount(transactionId_g) by clientIp_s, Uri, action_s | where Total_TransactionId >= Threshold
Uwaga
Przed utworzeniem tej reguły analitycznej należy upewnić się, że dzienniki zapory aplikacji internetowej znajdują się już w obszarze roboczym usługi Log Analytics. W przeciwnym razie usługa Sentinel nie rozpozna niektórych kolumn w zapytaniu i trzeba będzie dodać dodatkowe dane wejściowe, takie jak
| extend action_s = column_ifexists(“action_s”, “”), transactionId_g = column_ifexists(“transactionId_g”, “”)
dla każdej kolumny, która daje błąd. Te dane wejściowe ręcznie tworzą nazwy kolumn i przypisują im wartości null. Aby pominąć ten krok, najpierw wyślij dzienniki zapory aplikacji internetowej do obszaru roboczego.Na stronie Zdarzenie Ustawienia włącz tworzenie zdarzeń z alertów wyzwalanych przez tę regułę analizy. Grupowanie alertów można skonfigurować zgodnie z potrzebami.
Opcjonalnie możesz również dodać dowolną automatyczną odpowiedź na zdarzenie w razie potrzeby. Zobacz Automatyczne wykrywanie i reagowanie na potrzeby zapory aplikacji internetowej platformy Azure za pomocą usługi Microsoft Sentinel , aby uzyskać bardziej szczegółowe informacje na temat automatycznej konfiguracji odpowiedzi.
Na koniec wybierz pozycję Zapisz na karcie Przeglądanie i tworzenie .
Ta reguła analitycy umożliwia usłudze Sentinel utworzenie zdarzenia na podstawie dzienników zapory aplikacji internetowej, które rejestrują wszelkie ataki iniekcji kodu. Zapora aplikacji internetowej platformy Azure domyślnie blokuje te ataki, ale tworzenie zdarzenia zapewnia większą obsługę analityka zabezpieczeń w celu reagowania na przyszłe zagrożenia.
Reguły analityczne można skonfigurować w usłudze Sentinel pod kątem różnych ataków aplikacji internetowych przy użyciu wstępnie utworzonych zapytań wykrywania dostępnych w repozytorium GitHub zabezpieczeń sieci platformy Azure. Te zapytania zostaną dodane bezpośrednio do szablonów wykrywania usługi Sentinel. Po dodaniu te zapytania będą dostępne bezpośrednio w sekcji Szablony reguł analitycznych usługi Sentinel.
Następne kroki
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla