Monitoring Serwerów - Forum o monitoringu infrastruktury IT
Splunk przeciwko SQL Injection
#1
Wykorzystanie Splunk przeciwko SQL Injection 

Splunk w wielu obszarach przetwarzania danych IT ma duże zastosowanie. Typowe wyszukiwanie tekstu w zdarzeniach to dziś stanowczo za mało to prowadzenia skutecznej analizy bezpieczeństwa. Splunk pozwala na śledzenie skomplikowanych wzorców, które mogą pojawić się w naszych logach. Jednym z takich zastosowani jest analiza bezpieczeństwa portali WWW.
Zobaczmy, jak na przykładzie wpisów z Apacha, sprawdzi się aplikacja Splunk SQL Injection.
Wymagane parametry aplikacji to rodzaj źródła oraz analizowane pole. W naszych przypadku będą to wyrażenia odpowiednio: access* oraz uri_query.
[Image: image001.png]

Silnikiem tej aplikacji jest rozbudowane zapytanie pozwalające na detekcję wstrzykiwanego kodu w polu url. Po wypełnieniu danych oraz wybraniu okresu analizy system prezentuje nam kilka tabeli z wynikami. Na wykresie kołowym widzimy statystkę najczęstszych wzorców, które są wykorzystywane w atakach. 
[Image: image003.png]

Pozwala to na szybką ocenę skali ataku i charakteru atakującego. Sam fakt pojawienia się wyrażenia Union Select w adresie URL budzi duże wątpliwości. 
Kolejny diagram, to umiejscowienie wzorców ataków w czasie. Widzimy tu częstotliwość z jaką atakujący wykonuje wstrzyknięcie kodu. 
[Image: image005.png]

Zdecydowanie najciekawszym zestawieniem, jest tabela pokazująca adres IP klienta, typ ataku oraz pełen adres URL, który zawiera niebezpieczny fragment kodu SQL. 
[Image: image007.png]

Wybierając dowolne pole, możemy przenieść się w Splunk z okna naszej aplikacji do paska wyszukiwania. Podążając zatem za adresem 109.62.240.186 zobaczymy wszystkie ataki SQL Injection, które próbował wykonać atakujący.
[Image: image009.png]

Analizując te zdarzenia dochodzimy do wniosku, że atak nie był przypadkiem i dotyczył konkretnych czterech domen WWW naszego serwera. Splunk jest zasilany danymi z tak zwanych źródeł i dzięki takiemu podejściu od razu wiemy skąd pochodzą nasze logi, z jakiego źródła i jakiego systemu CMS dotyczą. Posiadając już taką wiedzę, możemy przyjrzeć się samemu systemowi CMS, w jakiej pracuje wersji, jaka jest jako podatność na takie ataki i jak się zabezpieczyć na przyszłość. 
Jeżeli wiemy już, że atak był skierowany na obszar WEB powstaje pytanie, jak wyglądała cała komunikacja z tym adresem IP. Wpiszmy zatem 109.62.240.186 w pole wyszukiwania Splunka.
[Image: image0011.png]

Analizując ten fragment, również widzimy ważne dane. Poza samym atakiem, widzimy reakcję jednego z naszych systemów CMS’a poprzez wbudowany moduł bezpieczeństwa. Można mieć zatem nadzieję, że ta witryna obroniła się sama, ale co z resztą ? 
Widok ataków SQL Injection w kierunku własnych systemów elektryzuje prawdopodobnie każdego administratora, dlatego trudno kwestionować przydatność Splunka do takiej analizy. Skoro już ujrzeliśmy ten niemiły widok w tabeli, postarajmy się na przyszłość o to, aby fakt takiego włamania został nam zakomunikowany, gdy tylko się wydarzy. Ustawmy powiadomienia email o zajściu co najmniej jednego przypadku ataku. 
[Image: image013.png]
Wybieramy tryb pracy w trybie rzeczywistym. Gdy zdarzenia pojawi się chociaż raz, operator zostanie natychmiast poinformowany.
Reply


Messages In This Thread
Splunk przeciwko SQL Injection - by ArturB - 07-30-2019, 09:30 AM

Forum Jump:

User Panel Messages