Aplikacyjny IDS do ochrony baz danych

Aplikacje i ich zaplecze w postaci baz danych w coraz większym stopniu są narażone na ataki poziomu aplikacyjnego, takie jak SQL injection, cross-site scripting, czy dostęp nieautoryzowanych użytkowników.

Aplikacje i ich zaplecze w postaci baz danych w coraz większym stopniu są narażone na ataki poziomu aplikacyjnego, takie jak SQL injection, cross-site scripting, czy dostęp nieautoryzowanych użytkowników.

Takie ataki obchodzą zazwyczaj obwodowe systemy ochronne i atakują bazy danych u ich źródła.

W odpowiedzi na takie zagrożenia pojawił się nowy poziom ochrony - ochrona w warstwie aplikacyjnej, która wykorzystuje tradycyjną koncepcję - sieciową i hostową - systemu wykrywania wtargnięć (IDS) na poziomie , tj. aplikacyjnym. W odróżnieniu od rdzennych rozwiązań sieciowych i hostowych, aplikacyjny IDS zapewnia aktywną, specyficzną dla SQL ochronę i monitorowanie, chroniące zarówno gotowe aplikacje różnych dostawców, jak i własne aplikacje webowe. Aplikacyjny IDS monitoruje i chroni krytyczne dane przed atakami specyficznymi dla baz danych (np. przepełnienia bufora), a także prowadzi audyt takich zdarzeń.

System wykrywania wtargnięć na poziomie aplikacyjnym

System wykrywania wtargnięć na poziomie aplikacyjnym

Ochrona aplikacji różni się od ochrony sieci i hostów. Aplikacje są bardzo różne, ale cele ataków takie same - uzyskanie dostępu do bazy danych. Ponieważ aplikacje używają SQL do komunikacji z bazą danych, dobry aplikacyjny IDS powinien przeprowadzać analizę składniową wyrażeń SQL, zapewniając ukierunkowany poziom ochrony, który rozpoznaje ruch, pozostając jednocześnie niezależnym od aplikacji.

Większość aplikacyjnych IDS składa się z trzech komponentów. Pierwszym jest sensor sieciowy lub hostowy. Sensor sieciowy jest podłączony do przełączalnego portu analizatora, który skonfigurowany jest do "podglądania" całego ruch związanego z bazą danych. Sensor hostowy natomiast rezyduje bezpośrednio w aplikacji. Sensory monitorują transakcje SQL, interpretują je i określają, czy ruch daje podstawy do podniesienia alarmu. Jeżeli konieczne jest podniesienie alarmu, to przekazywany on jest do drugiego komponentu strukturalnego - serwera konsoli. Serwer ten przechowuje zdarzenia i jest centralnym punktem obsługi sensorów, odpowiedzialnym za ich konfigurowanie i uaktualnianie. Trzecim komponentem aplikacyjnego IDS jest przeglądarka, za pośrednictwem której administrator może modyfikować ustawienia IDS, monitorować zdarzenia w czasie rzeczywistym i generować raporty.

I tak np. atak SQL injection, w którym napastnik próbuje obejść zdefiniowane na serwerze webowym wyrażenia SQL w celu zaaplikowania swoich własnych. Załóżmy, że oczekiwane wprowadzenie to nazwa użytkownika Jan z hasłem trudnafraza.

Na podstawie zaprezentowanych danych wejściowych baza danych wyszukuje w tablicy WebUser pozycję zawierającą zgodne nazwę i hasło. W ten sposób aplikacja uwierzytelnia użytkownika. Atak SQL injection pozwala oszukać aplikacje przez zmodyfikowanie wyrażenia SQL "wstrzykniętą" treścią. Załóżmy, że atakujący użyje hasła w postaci: bleble' OR 'A'='A, tak więc wyrażenie SQL, utworzone w wyniku zastosowania takiego hasła, będzie miało postać: SELECT * FROM WebUser WHERE Username='Jan' AND Password= 'bleble' OR 'A'='A'.

Logiczną wartością wyrażenia 'A'='A' jest zawsze "prawda", dlatego klauzula WHERE ma wartość "prawda" dla każdej pozycji i zostanie zaakceptowana przez aplikację, nawet wtedy gdy nie będzie zawierać prawidłowej nazwy użytkownika i hasła. Serwer aplikacyjny zaakceptuje takie wprowadzenie i, w ten sposób oszukany, wpuści atakującego "obok bramki". Po takim "uwierzytelnieniu" serwer aplikacyjny zażąda danych z bazy danych za pośrednictwem komend SQL.

Stosując aplikacyjny IDS, sensor przejmuje komendy SQL, odszyfrowuje, które tabele i kolumny są dla nich celem w bazie danych oraz to, czy jest to zlecenie legalne czy też próba ataku. Jeżeli żądana akcja nie jest dopuszczana przez reguły polityki IDS, sensor określa poziom zagrożenia atakiem i podejmuje odpowiednią akcję, polegającą zazwyczaj na wysłaniu alarmu na konsolę administratora lub pocztą elektroniczną.

Jest to przykład jednej z możliwych form ataków na poziomie aplikacyjnym, z jakim można spotkać się dzisiaj. Implementując IDS poziomu aplikacyjnego, można obronić się przed tego typu atakami.


TOP 200