Splunk przeciwko SQL Injection - Printable Version +- Monitoring Serwerów - Forum o monitoringu infrastruktury IT (https://monitoringserwerow.pl) +-- Forum: MONITORING INFRASTRUKTURY IT (https://monitoringserwerow.pl/forumdisplay.php?fid=1) +--- Forum: Splunk (https://monitoringserwerow.pl/forumdisplay.php?fid=15) +--- Thread: Splunk przeciwko SQL Injection (/showthread.php?tid=26)

Splunk przeciwko SQL Injection - ArturB - 07-30-2019 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. 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.  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.  Zdecydowanie najciekawszym zestawieniem, jest tabela pokazująca adres IP klienta, typ ataku oraz pełen adres URL, który zawiera niebezpieczny fragment kodu SQL.  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. 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. 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.  Wybieramy tryb pracy w trybie rzeczywistym. Gdy zdarzenia pojawi się chociaż raz, operator zostanie natychmiast poinformowany.