F

irewalking w oryginalnym znaczeniu odnosi się do spaceru po ogniu / żarze. Od strony informatycznej stosuje się to pojęcie do dokładnej analizy sieci i zapory ogniowej od strony intruza. Analiza taka pozwala na ocenę stanu jej odporności i ukazania słabości. Można stwierdzić, że każdy audyt bezpieczeństwa sieciowego dotyczy przeprowadzania testów penetracyjnych. Wówczas idea opiera się na symulacji działań potencjalnego intruza. Testy penetracyjne lub tzw. pentesty przeprowadza się przy założeniu, że nie są znane: struktura oraz usługi badanej sieci.

Interesującą techniką umożliwiającą wykonanie takiej analizy sieci jest właśnie firewalking, czyli technika pierwotnie rozwinięta przez Mike’a Schiffman’a oraz Davida Goldsmith’a umożliwiająca skanowanie sieci chronionej zaporą ogniową (ang. firewall) oraz badanie konfiguracji samej zapory ogniowej, a dokładniej jej list kontroli dostępu (ang. ACL – Access Control List). Technika ta jest zbliżona do metody traceroute umożliwiającej badanie trasy pakietów w sieci. Pozwala sprawdzić, jakie rodzaje pakietów są przepuszczane przez firewall chroniący daną sieć – jakie porty są otwarte na zaporze (ang. open), a które są przekazywane do chronionej sieci (ang. pass throught). Wykorzystując firewalking można również odkryć topologię chronionej sieci (podsieci, routery i inne urządzenia).

Technika traceroute polega na wysyłaniu pakietów o rosnących wartościach TTL (ang. Time-To-Live) – z reguły zaczyna się od TTL=1 i inkrementuje o 1, a otrzymany ciąg odpowiedzi ICMP pozwala określić trasę do maszyny docelowej (czasami może istnieć wiele tras i odpowiedzi nie zawsze będą jednoznaczne), gdyż wartość pola TTL jest zmniejszana na każdym routerze pośredniczącym w transmisji. W momencie gdy osiągnie wartość 0, router gubi pakiet i zwraca komunikat ICMP Time Exceeded (wraz z swoim źródłowym adresem IP) informujący o tym, że host docelowy nie został jeszcze osiągnięty. Wartość TTL jest zwiększana dopóki nie zostanie zwrócony odpowiedni komunikat ICMP Destination Unreachable – jeśli host działa poprawnie jest to Port Unreachable , jeśli nie ma do niego sieciowego dostępu to generowany jest błąd Host Unreachable przez ostatni węzeł sieciowy. Możemy sprawdzić to na przykładzie:

agresor:~# traceroute 12.34.56.78
traceroute to 12.34.56.78 (12.34.56.78), 30 hops max, 40 byte packets
 1  agresor.pl (4.3.2.1)  0.330 ms  0.298 ms  0.285 ms
 2  router1.pl (66.666.666.1)  14.837 ms  15.755 ms  16.942 ms
 3  router2.pl (66.666.666.2)  17.552 ms  18.713 ms  20.156 ms
 4  router3.pl (66.666.666.3)  25.295 ms  26.736 ms  28.419 ms
 5  router4.pl (66.666.666.4)  29.615 ms  31.299 ms  32.260 ms
 6  router5.pl (66.666.666.5)  36.894 ms  37.583 ms  38.227 ms
 7  router6.pl (66.666.666.6)  39.929 ms  28.307 ms  29.118 ms
 8  target1.pl (12.34.56.78)   34.382 ms  33.379 ms  36.175 ms

Jak widać, aby traceroute dotarł do celu musiał zwiększać pole TTL, aż osiągnęło wartość 8. Zgodnie z założeniami, jeśli pakiet TTL miał wartość 7 to odpowiedź z routera nr 6 powinna zostać zwrócona w postaci komunikatu ICMP 11:

agresor:~# hping3 -V -1 -t 7 -c 1 12.34.56.78
using eth0, addr: 4.3.2.1, MTU: 1500
HPING 12.34.56.78 (eth0 12.34.56.78): icmp mode set, 28 headers + 0 data bytes
TTL 0 during transit from ip=66.666.666.6 name=66.666.666.6.isp.pl

--- 12.34.56.78 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Co potwierdza analiza pakietów:

ICMP echo req (28 bytes) from agresor.pl to 12.34.56.78 (src HWaddr 000347ac3f20) on eth0
ICMP time excd (56 bytes) from 66.666.666.6 to agresor.pl (src HWaddr 0018d1398393) on eth0

Zwiększając TTL do 8 oraz używając pakietu UDP zamiast ICMP, powinniśmy otrzymać odpowiedni komunikat ICMP Destination Unreachable:

agresor:~# hping3 -V -2 -t 8 -c 1 12.34.56.78
using eth0, addr: 4.3.2.1, MTU: 1500
HPING 12.34.56.78 (eth2 12.34.56.78): udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=12.34.56.78 name=12-34-56-78.isp.pl

--- 12.34.56.78 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Technika firewalking, podobnie jak traceroute, wysyła pakiety z odpowiednim polem TTL. Jest w pewnym sensie rozwinięciem traceroute – generowane pakiety mogą być różnych typów i z różnymi parametrami i numerami portów. W technice tej wymagane są trzy hosty – pierwszy, wykonujący firewalking, drugi pełniący rolę bramy / firewall’a oraz trzeci znajdujący się za bramą / firewall’em. Najpierw wyznaczana jest minimalna wartość TTL tak, aby pakiet mógł dotrzeć do bramy łączącej skanowaną sieć ze światem. Następnie badanie firewalla polega na wysyłaniu różnych rodzajów pakietów z polem TTL zwiększonym o 1 tak, aby pakiet mógł przeskoczyć firewall i zobaczyć jaki rodzaj hostu za nim stoi – kolejny router czy serwer. Przy badaniu pozostałych hostów w sieci również stosuje się wartość TTL zwiększoną o 1, przy badaniu zaś podsieci – wartości odpowiednio większe. Mike Schiffman i David Goldsmith w tym celu stworzyli aktywne narzędzie bezpieczeństwa sieciowego – firewalk, pozwalające na określenie jakie protokoły są przekazywane przez zaporę sieciową. Firewalk wysyła pakiety TCP lub UDP z zwiększonym TTL o 1 niż liczba routerów / bram do sprawdzanej zapory sieciowej. Jeśli firewall zezwala na tego rodzaju ruch – jest on przekazywany do celu znajdującego się wewnątrz chronionej sieci. Powodzenie tej metody zależy głównie od możliwości wychodzenia komunikatów ICMP Time Exceeded przez zdalną zaporę ogniową. Niestety firewalk nie jest już rozwijany dlatego bardzo prosty przykład zostanie zaprezentowany za pomocą takich narzędzi jak traceroute oraz hping. Pierwszym krokiem jest określenie minimalnej odległości do wybranego celu:

agresor:~# traceroute target2.pl
traceroute to target2.pl (12.12.21.21), 30 hops max, 40 byte packets
 1  agresor.pl (6.6.9.9)  0.619 ms  0.692 ms  0.702 ms
 2  router1.pl (212.25.5.69)  11.720 ms  12.877 ms  14.071 ms
 3  router2.pl (80.150.150.180)  15.522 ms  16.222 ms  17.441 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *

Brak odpowiedzi na wysyłane pakiety UDP sygnalizowany jest znakiem gwiazdki “*” i prawdopodobnie wynika z filtrowania pakietów. Możemy przełączyć traceroute na pakiety ICMP ECHO:

agresor:~# traceroute -I target2.pl
traceroute to target2.pl (12.12.21.21), 30 hops max, 40 byte packets
 1  agresor.pl (6.6.9.9)  0.593 ms  0.654 ms  0.650 ms
 2  router1.pl (212.25.5.69)  9.397 ms  10.603 ms  13.069 ms
 3  router2.pl (80.150.150.180)  13.129 ms  13.763 ms  15.474 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *

Jeśli efekt pozostaje ten sam to ostatnią próbą są pakiety TCP SYN:

agresor:~# traceroute -T target2.pl
traceroute to target2.pl (12.12.21.21), 30 hops max, 40 byte packets
 1  agresor.pl (6.6.9.9)  0.722 ms  0.681 ms  0.686 ms
 2  router1.pl (212.25.5.69)  29.681 ms  30.620 ms  31.052 ms
 3  router2.pl (80.150.150.180)  14.029 ms  15.226 ms  17.147 ms
 4  * * *
 5  * * *
 6  target2.pl (12.12.21.21)  59.753 ms  60.326 ms  61.914 ms
 7  target2.pl (12.12.21.21)  68.972 ms  58.191 ms  58.273 ms

Problemem, w tym przypadku wynika z firewalla umieszczonego prawdopodobnie na piątym i czwartym węźle, który filtruje pakiety typu UDP i ICMP uniemożliwiając tym samym dokładne zbadanie trasy pakietów. W wielu przypadkach jednak zapory pozwalają na przejście pakietów inicjujących połączenie TCP SYN do konkretnych portów, za którymi kryją się nasłuchujące usługi serwerów chronionych przez firewall. Na przykładzie powyżej widać, że dzięki tego rodzaju metodzie traceroute “automatycznie” wykrył, że za portem 80 (standardowy port w trybie -T, który można zmienić dzięki opcji -p [nr portu]) szóstego hosta (według numeracji traceroute) “chowa” się kolejny host. Jest to również dla nas podpowiedź, by w poszukiwaniu reszty otwartych portów używać skanowania typu TCP SYN:

agresor:~# nmap -PN -sS -p 1-80 target2.pl

Starting Nmap 4.62 ( http://nmap.org ) at 2010-05-03 17:44 CEST
Interesting ports on target2.pl (12.12.21.21):
Not shown: 78 filtered ports
PORT   STATE  SERVICE
21/tcp open   ftp
80/tcp open   http

Nmap done: 1 IP address (1 host up) scanned in 2.931 seconds

W tym zakresie portów została wykryta również usługa FTP. Ostatnią czynnością jest sprawdzenie “topologicznego” rozmieszczenia tych usług – zaczynając od portu FTP oraz minimalnego TTL równego 5 odpowiadającego ostatniemu filtrowi sieciowemu. Omijamy w ten sposób filtr pakietów na 4 węźle i sprawdzamy czy usługa FTP nie znajduje się już na 5‘tce:

agresor:~# hping3 -V -S -t 5 -c 1 -p 21 12.12.21.21
using eth0, addr: 6.6.9.9, MTU: 1500
HPING 12.12.21.21 (eth0 12.12.21.21): S set, 40 headers + 0 data bytes

--- 12.12.21.21 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Brak odpowiedzi na pakiet SYN sugeruje, że drugi Firewall nie udostępnia usługi FTP. Daje nam to tymczasowy obraz sieci:

[Router1]-[Router2]-[Firewall/Router]-[Firewall/Router]
                                              |
                                            21/80 TCP
                                              |
                                      [Router ? Serwer]
                                              |
                                      [Router ? Serwer]

Sprawdzamy czy usługa FTP nie znajduje się na 6‘tce:

agresor:~# hping3 -V -S -t 6 -c 1 -p 21 12.12.21.21
using eth0, addr: 6.6.9.9, MTU: 1500
HPING 12.12.21.21 (eth0 12.12.21.21): S set, 40 headers + 0 data bytes
len=46 ip=12.12.21.21 ttl=59 DF id=0 tos=0 iplen=44
sport=21 flags=SA seq=0 win=5840 rtt=39.9 ms
seq=379077794 ack=114171087 sum=5b5a urp=0

--- 12.12.21.21 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 39.9/39.9/39.9 ms

W odpowiedzi otrzymaliśmy pakiet SYN/ACK, co oznacza, że usługa FTP znajduje się na szóstym węźle liczonym według listingu traceroute. W dodatku TTL=59, który pokonał 5 węzłów sieciowych sugeruje, że usługa znajduje się na serwerze Linuksowym (TTL=64 – 5 = 59). W ten sam sposób możemy sprawdzić czy serwer FTP nie jest zarazem serwerem WWW:

agresor:~# hping3 -V -S -t 6 -c 1 -p 80 12.12.21.21
using eth0, addr: 6.6.9.9, MTU: 1500
HPING 12.12.21.21 (eth0 12.12.21.21): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=12.12.21.21 name=target2.pl

--- 12.12.21.21 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Otrzymaliśmy komunikat ICMP Time Exceeded, co oznacza, że węzeł 6 przekazuje pakiety kierowane na port 80 dalej do węzła 7, co potwierdza zwiększenie TTL o 1:

agresor:~# hping3 -V -S -t 7 -c 1 -p 80 12.12.21.21
using eth0, addr: 6.6.9.9, MTU: 1500
HPING 12.12.21.21 (eth0 12.12.21.21): S set, 40 headers + 0 data bytes
len=46 ip=12.12.21.21 ttl=58 DF id=0 tos=0 iplen=44
sport=80 flags=SA seq=0 win=5840 rtt=44.1 ms
seq=27375734 ack=1918260500 sum=7956 urp=0

--- 12.12.21.21 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 44.1/44.1/44.1 ms

Daje nam to następujący obraz sieci:

[Router1]-[Router2]-[Firewall/Router]-[Firewall/Router]
                                              |
                                            21/80 TCP
                                              |
                                   [Router 80 / Serwer 21]
                                              |
                                         [Serwer 80]

W celu ochrony przed skanowaniem tą metodą można filtrować wychodzące pakiety ICMP 11. Większość zapór sieciowych powinna zawierać reguły całkowicie blokujące ruch komunikatów ICMP używanych przy poleceniach ping i traceroute do Internetu (w przypadku małych sieci ze względu na możliwości skanowania hostów za pomocą protokołu ICMP warto rozważyć blokadę wszystkich rodzajów wychodzących komunikatów ICMP). Wyjątkiem mogą być objęte tylko zaufane systemy, z których możemy przeprowadzić szybką diagnostykę. Efekt ten możemy uzyskać na przykład poprzez odpowiednie wpisy iptables:

iptables -A INPUT -p icmp --icmp-type 8 -s [zaufane IP] -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 0 ! -d [zaufane IP] -j DROP
iptables -A OUTPUT -p icmp --icmp-type 11 ! -d [zaufane IP] -j DROP

Należy również pomyśleć o odpowiednich regułach dla adresatów IP znajdujących się wewnątrz chronionej sieci tak, aby nie zablokować im możliwości używania narzędzia traceroute. Blokada wychodzących komunikatów ICMP 11 spowodowała również blokadę wykrywania przez traceroute w trybie TCP SYN przekazywania ruchu na porcie 80’tym:

agresor:~# traceroute -T target2.pl
traceroute to target2.pl (12.12.21.21), 30 hops max, 40 byte packets
 1  agresor.pl (6.6.9.9)  0.684 ms  0.657 ms  0.712 ms
 2  router1.pl (212.25.5.69) (213.25.2.66)  12.479 ms  14.224 ms  16.832 ms
 3  router2.pl (80.150.150.180)  20.494 ms  20.681 ms  20.893 ms
 4  * * *
 5  * * *
 6  target2.pl (12.12.21.21)  66.721 ms  57.522 ms  57.994 ms

Dodatkowym maskowaniem dla blokady wychodzących komunikatów ICMP 11 jest filtrowanie wszystkich pakietów z niską wartością TTL (np. < 5) i zwracanie odpowiedniego komunikatu ICMP 3:

iptables -A INPUT -i eth0 -p all -m ttl --ttl-eq 0 -j DROP
iptables -A INPUT -i eth0 -p all -m ttl --ttl-lt 5 ! -s [zaufane IP] -j REJECT --reject-with icmp-port-unreachable
iptables -A FORWARD -p all -i eth0 -o eth1 -m ttl --ttl-eq 0 -j DROP
iptables -A FORWARD -p all -i eth0 -o eth1 -m ttl --ttl-lt 5 ! -s [zaufane IP] -j REJECT --reject-with icmp-port-unreachable

W przypadku wpisu dotyczącego przekazywania pakietów (łańcuch FORWARD) eth0 jest interfejsem zewnętrznym (publicznym), a eth1 jest interfejsem wewnętrznym (lokalnym). Dodatkowo blokujemy pakiet z wartością TTL 0. Tego rodzaju pakiet może istnieć jedynie wtedy, gdy router przekazujący pakiet do naszej sieci działa wadliwie lub pakiet pochodzi z komputera w tej samej podsieci. Oprócz podjęcia kroków utrudniających łatwe wykonanie tej techniki sam firewall powinien być wyposażony w system IDS/IPS (ang. Intrusion Detection System / Intrusion Prevention System) umożliwiający wykrywanie i blokowanie jednej z głównych faz tego ataku, czyli skanowania portów za pomocą różnych technik i protokołów.

Więcej informacji: K. Folga, Firewalking, czyli spacer po zaporze ogniowej, Networld 1 czerwca, 2005, hping, Parametry jądra i protokołów sieciowych