Kłopotliwe pytania techniczne

Oddzielnym zagadnieniem do rozważań byłaby wewnętrzna konstrukcja agentów. Zdecydowana większość robaków internetowych wykorzystuje zwykle jedną wadę konstrukcyjną systemu, usługi lub aplikacji. Konsekwencją tej specjalizacji są niewielkie rozmiary. Niewielka objętość pozwala skutecznie rozprzestrzeniać się w sieciach o słabej przepustowości. Umożliwia także zmieszczenie kopii robaka w jak najmniejszej liczbie pakietów, co również wpływa na zdolność do propagacji.

Aby zminimalizować rozmiary robaków, ich autorzy posługują się językiem C, a często także asemblerami. Ostateczny efekt to zaledwie kilka kilobajtów. Małe rozmiary to zawsze zaleta - również wtedy, gdy robak ma działać jako agent strzegący bezpieczeństwa w firmie. Szkopuł w tym, że w związku z mnogością błędów i jeszcze większą liczbą dostępnych dla nich eksploitów, agent z definicji nie może być bardzo wyspecjalizowany, to zaś musi przełożyć się na jego rozmiary.

Rasowy robak internetowy zajmuje się wyłącznie poszukiwaniem podatnych na jego działanie hostów i ściśle określonymi działaniami złośliwymi, np. wywoływaniem ataku DoS (Denial of Service) oraz powielaniem samego siebie. Daje mu to możliwość - zwłaszcza w przypadku robaków atakujących usługi "socketowe" (jak np. Blaster) działania bez potrzeby jakiejkolwiek akcji ze strony użytkownika.

Powstaje więc pytanie, czy przed próbą "infekcji" powinien on poinformować użytkownika, że za chwilę dokona "najazdu" na jego komputer, czy też, jak prawdziwy robak, powinien zrobić to bez jego zgody? Jeśli robak musi wchodzić w jakiekolwiek interakcje, objętość kodu rośnie. Druga sprawa to rzeczywisty zakres działania. Aby być w stanie przetestować stosunkowo rozsądny zakres luk, agent musi mieć repozytorium wiedzy oraz logikę interpretującą - im większy zakres, tym więcej miejsca potrzeba. Wielozadaniowy, pokaźnych rozmiarów robak-agent przestaje być efektywny, w szczególności zajmuje więcej pasma i pochłania więcej mocy obliczeniowej.

Działanie agenta może okazać się uciążliwe i niebezpieczne dla systemu i działających w nim właśnie aplikacji. Robak internetowy nie dba, czy zawiesi docelowy system operacyjny, pozostawiając użytkownika sfrustrowanego z powodu utraty efektów pracy. Agent nie może działać jak wandal, ale z drugiej strony, ostrzeżenie o potencjalnie niebezpiecznych konsekwencjach pracy z aplikacjami podczas skanowania może zostać zignorowane. W rezultacie agent musi mieć dodatkową logikę, która pozwoli ograniczyć potencjalnie szkodliwe konsekwencje jego działania, np. zapis stanu systemu, wykonanie zapisu w tle otwartych dokumentów itp.

Aby uniknąć sytuacji, w której agent jest nazbyt "rozdęty", można próbować zastosować architekturę częściowo scentralizowaną, z centralnym zbiorem wiedzy o podatnościach. Przynajmniej teoretycznie można by także rozważać sukcesywne doładowywanie odpowiednich informacji w trakcie skanowania różnych elementów środowiska. Problem polega na tym, że zamiast ruchu w sieci generowałyby nie pokaźne pliki agentów-omnibusów, lecz płynące w ślad za nimi aktualizacje.

Tu i teraz: nie!

Gdy rozważy się wszystkie istotne aspekty "dobrych robaków", trudno nie dojść do wniosku, że pomimo atrakcyjności samej koncepcji, nie jest to pomysł do realizacji w firmowej sieci. Elementem bezpieczeństwa sieci i systemów, oprócz poprawności konfiguracji i braku luk, jest stabilność i przewidywalność. To między innymi z tego powodu w wielu firmach, które mają i środki, i kadry, by utrzymać systemy w możliwie aktualnym stanie, nie wszystkie łaty są aplikowane. Bywa, że luki w pewnych systemach istnieją miesiącami, a nawet latami. Owszem, zdarzają się sytuacje, w których łata nie może być zaaplikowana - to jednak wyjątki.

Częściej okazuje się, że administratorzy zwyczajnie nie są świadomi zagrożeń lub nie mają kompetencji, by je stwierdzić. Gdy tak się sprawy mają, wdrożenie rozwiązania opartego na agentach mogłoby wywołać skutki odwrotne do zamierzonych. W takich wypadkach lepiej jest po prostu polegać na standardowych, automatycznych lub półautomatycznych aktualizacjach (np. WSUS). Jako dodatkowy środek zaradczy można stosować prosty skaner podatności niewprowadzający "zamieszania" do firmowej sieci.

Nieocenione korzyści może przynieść globalna konfiguracja ustawień filtrów pakietów na stacjach roboczych, blokująca dostęp do niewykorzystywanych usług i zasobów. Bardzo dobrze sprawdza się także odbieranie użytkownikom wszystkich ważniejszych uprawnień systemowych oraz ograniczenie możliwości korzystania z zewnętrznych usług innych niż proste przeglądanie Internetu. W praktyce jest to stosowane rzadko - zbyt rzadko, i stąd być może właśnie coraz to nowe pomysły na podwyższenie bezpieczeństwa.