Większość ataków nie dotyczy wyłącznie protokołów TCP i UDP, lecz wykorzystuje luki w systemach zabezpieczeń systemów i aplikacji korzystających ze stosu IP. Dlatego od profesjonalnego systemu IDS należy również oczekiwać umiejętności analizowania ataków realizowanych na poziomie protokołów, takich jak SMTP, HTTP, FTP, POP, IMAP itd. System IDS musi umieć uporządkować i "złożyć" pakiety zawierające dane adresowane do tych usług sieciowych i przeanalizować je pod kątem poprawności przeprowadzanej sesji komunikacyjnej (tzw. stream-based signatures). W ten sposób może on wychwycić np. ataki na serwer internetowy IIS, polegające na wpisaniu jako docelowy adresu strony o długości przekraczającej kilkaset znaków.

Oczywiście analiza typu stateful inspection, związana z nią konieczność porządkowania pakietów sieciowych i podtrzymywania informacji o stanie sesji nakładają na system IDS znacznie większe wymagania pod względem wydajności niż w przypadku analizy typu stateless.

Atak i co?

Dawno już minęły czasy, gdy od systemów IDS wymagano wyłącznie wykrycia, czy pracujące w sieci komputery i serwery są atakowane, oraz rejestrowania przebiegu ataku. Obecnie wymaga się od nich również zautomatyzowanej reakcji na atak: zakończenia (określanego jako TCP reset lub RSKill) sesji komunikacyjnej wykorzystywanej do przypuszczenia ataku, przesłania do zapory informacji o źródle i typie ataku, tak by mogła nastąpić zmiana konfiguracji broniąca przed niepożądanymi pakietami (oczywiście wymaga to zapewnienia współpracy z popularnymi zaporami), a także ewentualnie przejścia w wyższy stan gotowości systemu IDS, aby był on bardziej czuły na ataki (wtedy gdy są one przypuszczane seryjnie). Jeśli IDS monitoruje ataki inicjowane z sieci wewnętrznej, to należy wymagać, by był on w stanie po zidentyfikowaniu włamywacza zablokować jego konto.

Od systemu IDS wymaga się zaawansowanego systemu rejestrowania zdarzeń (log jest jedynym miejscem, w którym można prześledzić przebieg ataku i uzyskać informacje o jego źródle), rozbudowanych możliwości raportowania o przebiegu pracy, dokładnych opisów poszczególnych rodzajów ataków, częstego udostępniania przez producenta aktualizacji bazy sygnatur ataków, a także intuicyjnego interfejsu użytkownika pozwalającego na szybkie uzyskanie dostępu do najważniejszych funkcji aplikacji (szczególnie przydatne w przypadku manualnego analizowania ataku i odpierania go w czasie rzeczywistym).

Krytycznym elementem systemu IDS jest wbudowany w rozwiązanie motor bazy danych lub mechanizm komunikacji z zewnętrzną bazą danych, która jest wykorzystywana do zapisu wszystkich informacji dotyczących realizowanych transmisji, anomalii w pracy sieci, ataków itd. Przy dużym natężeniu ruchu (szczególnie w czasie ataków) komunikacja z bazą danych może okazać się wąskim gardłem systemu IDS.

Niewidzialny przyjaciel

Nie należy zapominać, że i system IDS może stać się celem skutecznych ataków - szczególnie wtedy gdy jest to IDS sieciowy przeznaczony do monitorowania włamań w obrębie sieci korporacyjnej. Zabezpieczeniem przed "wścibskimi", a także wszelkimi próbami "ogłupiania" systemu IDS przez jego bezpośrednie atakowanie jest praca sond sieciowych IDS w trybie stealth, w którym karta sieciowa zajmująca się obserwacją sieci w całości jest pozbawiona stosu sieciowego. W żaden sposób nie poddaje się ona wtedy atakom na wyższe niż fizyczna warstwy stosu sieciowego, a jednocześnie może prowadzić pełny "nasłuch" segmentu sieciowego, do którego jest podłączona. Taka karta nie odpowiada również na próby jej odpytywania przez inne stacje sieciowe. Jedynymi pakietami, jakie może samodzielnie wysyłać, są pakiety TCP reset wykorzystywane do kończenia sesji naruszających politykę bezpieczeństwa zdefiniowaną w systemie IDS.

Praca w takiej konfiguracji wymaga, aby sonda była również wyposażona w drugi interfejs sieciowy (z pełnym stosem IP) przeznaczony do komunikacji z centralną konsolą IDS. Interfejs ten powinien jednak należeć do wydzielonego segmentu zarządzania, z którego mogą korzystać wyłącznie sondy IDS i administratorzy.