Należy zaznaczyć, że skanowanie zostanie zakończone natychmiast, gdy port docelowy będzie przepuszczony przez zaporę ogniową. Po udanej próbie (przy dalszym zwiększaniu numeru portu w każdej próbie) następna zostaje niezwłocznie odrzucona przez ACL na zaporze. Możliwa jest taka modyfikacja traceroute, że inkrementacja portu zostanie zatrzymana, a wtedy każda próba osiąga docelowy port. Przydatna okaże się nam w tym łatka na kod źródłowy traceroute napisana przez autorów tej techniki.

Jeżeli odpytujemy maszynę za zaporą ogniową i próba jest zablokowana przez filtr ACL, w większości przypadków pakiet zostanie odrzucony. Możemy wówczas określić tylko ostatnią zaporę ogniową (firewall), która odpowiada. Ten firewall może być dobrym punktem wyjściowym do ataku.

Wykonując traceroute do maszyny umieszczonej za zaporą ogniową, sprawdzając różne protokoły i otrzymując odpowiedzi, możemy dojść do kilku wniosków:

• konkretny typ ruchu jest przepuszczany przez zaporę ogniową;
• znamy hosty umiejscowione za zaporą ogniową (jeżeli nie jest przeprowadzana translacja adresów). Nawet jeżeli nie wyjdziemy poza punkt wyjściowy (czyli zaporę), znamy typ filtrowanego ruchu.

To decyduje o prostocie techniki firewalking.

Podstawy metody firewalking

Firewalk jest aktywnym narzędziem bezpieczeństwa sieciowego, które pozwala określić, jaki protokół modelu sieciowego jest przekazywany przez zaporę sieciową. Narzędzie wysyła pakiet TCP lub UDP z polem TTL o jeden większym niż liczba hopów do sprawdzanej zapory. Jeżeli zapora zezwala na ruch, będzie przekazywała pakiety do następnego hopa, aż trafimy na blokadę i otrzymamy komunikat ICMP_TIME_EXCEDED. Jeżeli brama nie odpowiada na ruch hosta, to prawdopodobnie odrzuciła pakiet i nie otrzymamy odpowiedzi.

Aby utworzyć prawidłowy IP TTL, należy obliczyć liczbę hopów do miejsca przeznaczenia. Robimy to w podobny sposób, w jaki robi to traceroute. Jeżeli znamy liczbę hopów do zdalnej zapory, możemy rozpocząć audyt zdalnej sieci. Należy zaznaczyć, że docelowy host czasami może nie zostać osiągnięty. Atakujący host może zostać odrzucony w dowolnym miejscu zdalnej sieci.

Użycie bramy sieci zdalnej do zbierania potrzebnych informacji wymaga znajomości kilku informacji:

• adres IP ostatniej znanej bramki/zapory ogniowej przed sprawdzaną siecią;
• adres IP hosta umieszczonego za zaporą ogniową.

Jeżeli nie otrzymamy odpowiedzi od bramy/zapory, może to oznaczać, że sprawdzany protokół jest blokowany. Adres IP hosta jest używany jako docelowy dla przepływających pakietów. Przykładową strukturę sieci możemy zobaczyć na rys. obok.

Narzędzie firewalk pozwala określić typ wysyłanych pakietów. Można na przykład wysłać pakiet TCP na port 80 serwera WWW lub pakiet UDP na port 53 serwera DNS. Pozwala to przeniknąć transmitowanemu pakietowi przez filtr pakietów, dostarczając informacji o udostępnionych na zaporze ogniowej portach/hostach.

Zaletą techniki jest możliwość sprawdzenia wszystkich routerów pomiędzy filtrem pakietów oraz miejscem przeznaczenia. Koniecznością jest udostępnienie transmisji wychodzących komunikatów ICMP Time Exceeded przez zdalną zaporę ogniową.

Używając tej techniki, można otrzymać kilka różnych informacji poprzez symulację pojedynczego zbiorowego ataku. Narzędzie pozwala przesłać pakiety na wszystkie porty i protokoły oraz monitorować odpowiedzi. Drugim potencjalnym zadaniem jest zaawansowane mapowanie sieci. Poprzez wysłanie pakietu do każdego hosta za pakietem filtrów, atakujący potrafi stworzyć dokładną mapę topologii sieciowej.

Test praktyczny - opis przykładowego użycia narzędzia firewalk

Poprzez wysyłanie prób oraz sukcesywne raportowanie może zostać dokładnie określona lista dostępu ACL na zdalnej bramie/zaporze ogniowej.

Firewalk ma dwie fazy: odkrywania sieci oraz skanowania. Wysyła pakiet TCP lub UDP i ustawia timeout. Jeżeli otrzyma odpowiedź, zanim czas minie, port jest zazwyczaj otwarty, w przeciwnym razie - przeważnie zamknięty. Przykład użycia narzędzia przedstawia Listing 5.

Wolna sieć

Pakiet w sieci IP może zostać odrzucony z różnych powodów. Powody inne niż blokada na filtrze pakietów to straty uboczne. W celu zwiększenia wydajności i poprawnego działania narzędzia firewalk należy ograniczyć liczbę tego typu strat. Najlepszym rozwiązaniem jest zwiększenie liczby wysyłanych prób.

Problem pojawi się jednak, gdy wysyłane przez nas próby będą filtrowane lub odrzucane na innej bramie niż ta, która trasuje bezpośrednio do zdalnej wewnętrznej sieci. Będzie to wyglądało tak, jakby docelowa zapora blokowała pakiet, co nie jest prawdą. To nie są uboczne straty, więc wysłanie większej liczby pakietów na nic się nie zda. Aby zapobiec temu, musimy użyć metody nazwanej slow walk, czyli skanowania każdego hopa na trasie do celu.

Jak zmniejszyć ryzyko?

Podatności na traceroute lub firewalk nie można lekceważyć. Obie techniki mogą być skuteczne nawet w przypadku niektórych zapór ogniowych działających w trybie stateful inspection!

Jak się zabezpieczyć? Najłatwiejszym rozwiązaniem tego problemu jest zablokowanie opuszczania wewnętrznej sieci przez wiadomości ICMP TTL Exceeded. Daje to jednak efekt uboczny, uniemożliwiając wykonanie komendy traceroute użytkownikom naszej sieci. Prowadzi to często do problemów w diagnozie sieci wewnętrznej.

Inną metodą obrony przed firewalk jest użycie serwera proxy. Translacja adresów sieciowych (NAT) i/lub serwer proxy mogą zapobiec próbom skanowania. Gdy systemy wykrywania intruzów będą potrafiły wykryć ten rodzaj ataku, możliwe jest stworzenie wersji narzędzia firewalk, która będzie generowała pakiety wyglądające prawidłowo dla każdej usługi. Obecnie firewalk wypełnia tylko nagłówek i nie wstawia żadnych danych w pakiet. Bardziej zaawansowana wersja mogłaby emulować znane usługi, przechodzące przez maskaradę jak prawidłowy ruch, oraz losowo dobierać czas skanowana.

Mylne jest stwierdzenie, że zapora ogniowa zawsze działa bezbłędnie. Wiele firm produkujących urządzenia ochraniające sieć zakłada, że komunikaty ICMP error (typu Host Unreachable, Time Exceeded) są w zupełności bezpieczne. Pozwala to na wprost nieograniczone i niezauważalne użycie opisywanych narzędzi.

Artykuł opracowano na podstawie dokumentu: David Goldsmith, Michael Schiffman, "Firewalking - A Traceroute-Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists", Cambridge Technology Partners' Enterprise Security Services, October 1998